From: sean@netcom.com (Sean Burke22)
Subject: Question: OS, devel tools for 68332, flash system?
Keywords: Realtime OS, SBC, 68332
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 17 Dec 1992 02:00:36 GMT


Hello comp.sys.m68k'ers,

  Here I am, once again looking for some free net.consultation.  :^}
In return, I will post a summary of the wisdom I obtain.

  I'm going to do an embedded software project on an SBC that is very
similar to the 68332 EVB (tho I'm not familiar with the EVB, so this
is second hand).  We've got the '332,  with a serial port, the BDM
port, 64K of flash eprom, and 4k of DRAM, plus the A/D and D/A channels
that do the work.  We have the DOS development tools, including the 
C-compiler, and we have DIBUG. I am not satisfied.

  What do I want?  What do you recommend?  

  Can I get an operating system/boot monitor running on this system?
Freeware would be nice, but if you are using a commercial product you
like, let me know.  Can I get the source for the motorola 680x0 debugger,
I think it was called Macsbug or Maxbug on the Macintosh?  If I do a
simple boot monitor, it would be nice to include debugging features,
particularly ones that could run at serial-port interrupt time, so that
we don't have to unduly disturb a realtime control application?

  Can I develop on a Unix workstation, namely a sun3 or sun4 running
sunos 4.1.1?  Will Moto supply development tools for these platforms?
  Will gcc work?  If gcc, how can I generate S-records, or load directly from
coff or a.out files? Can I put a loader on the board to support incremental
linking/loading? I already noted the posting about connecting gdb to BDM,
thanx.

  How do i equip this little system with a development and debugging
environment that will be useful in hard-realtime applications?  We've
gotten a couple applications running on this board before I became
involved,  but it seems like we're really doing things the hard way.
I'm not very familiar with tiny-computer OSes; Macs are the smallest thing
I'm familiar with.  I'd very much like to develop on UNIX, so any help
here will be especially appreciated.

  Up to this point, we've been compiling and linking the entire program,
before downloading it to flash.  The interrupt vector table is compiled
as part of the program, with the entry point as the reset vector, so we
boot right into the application.  This means that every application needs
to include all of the system code as well, which is ugly.  I could write
a boot monitor that is able call an arbitrary address to invoke other
functions.  That would not be too hard,  but how about loading application
code that would link to utility functions in the boot monitor?  Is this
doable, given the small amount of RAM in this system?  Should I use traps,
as in MacOS, to access system calls instead?  Does anyone know what the 
trap overhead is (CPU context save/restore) on a 16MHz 020,030,CPU32? 
Anything over 5 microseconds would be cause for concern.  Does anyone
have a code fragment which shows how arguments are passed and values 
returnd from a trap handler?  I'm a beginner with 68k assembly.

  What's a good way to manage the flash?  One thing we now have to do 
is link twice: once with the initialized data section in its runtime
location in DRAM,  to generate a correct code section,  and a second
time with initialized data in flash to generate S-records to program
the flash.  We combine the code S-records from the first link with the
data S-records from the second link to program the flash memory.  If
the initialized data contains pointers to other data, this method 
loses big, right?  The only other method I can think of is to write
a program which munges the S-records from the first compile to relocate
the data section.  Any better ideas?  None of the special section types
in the Moto linker seemed to do exactly what i want.  Can gld do a better
job?

  A second problem is that I have to keep track of which areas of flash
are in use by hand.  The nice thing about have the monitor do relocation
at download time is that it could keep track of which areas of flash were
free,  so that I could keep a number of programs on the system without
conflict.  And, I could load stuff into RAM for testing, which would be
faster than programming the flash,  and also make it easier to insert
breakpoints into the code (which is tough when executing from flash).
Would this be very hard to do?  

  These are some points to get you thinking.  I'm mostly an application
programmer, and I've never had to confront  system-programming issues like
these,   (Unfortunately, neither has anyone else in my company :-) )
so feel free to raise any topic you think I've overlooked.  

Sean Burke



-- 

sean@netcom2.netcom.com