[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MC68EZ328



On Tue, 10 Aug 1999, Jake Janovetz wrote:

>    This depends on how you want to load RTEMS.  For example, if you
> put the code in Flash, you can have the '328 run directly out of
> Flash.  In this way, there is no boot loader because RTEMS does not
> need to be 'loaded' at all; it runs in place.
>    On the other hand, sometimes running out of ROM can slow things
> down.  Code on my 68360 board runs about 1/8th speed in ROM than in
> RAM, mainly due to the 8-bit width of RAM.  So, I wrote a very small
> piece of code (completely independent of RTEMS) that runs on boot.
> I place this code in Flash.  I build RTEMS to run out of RAM at
> a certain RAM address (specified in the linkcmds script).  I then
> place this image after the short boot code.  The boot code looks
> for the image and begins copying the RTEMS code, section by section
> into RAM.  Once complete, the code begins executing RTEMS.

i'm beginning to understand the scheme of things, and found the spot
just after ".global start" in start68k.c (of the efi68k BSP) to put
in my initialisation code.

luckily the efi68k board has turned out to be very similar in basic
features to mine, so i haven't had to make too many radical changes,
my port should be available to anyone that wants it as soon as i'm
happy that it works well.

So now i have another question, the EZ328 has the facility to stop the
core's clock, or AND it with a square wave of varied period and duty
cycle to lower power consumption.

now the most obvious place to set a slow, low power mode would be the
idle thread, but it would be nice to be able to control power
usage/speed in the scheduler, is there an easy way to do this?

the L4 micro kernel (a local OS research favorite), for example, is
supposed to provide (ie. not yet implemented) a preempted exception to
tell you when threads are not finishing in their timeslice. 

as an aside, the effect of not implementing this preempted exception
yet means that real time operating systems can't be contructed over L4
until they do.

>    Sounds fun!  We have a Solar Racing team here at the University
> of Illinois.  It's good to hear someone going out there and 
> investigating new controller stuff.  Most everyone here is in 
> mechanics and power and they spend very little time on the embedded
> system.

do you know if your team will be participating in the World Solar
Challenge here in october? 

>  Out of curiosity, won't that much SRAM dwarf everything else
> in power consumption?  I suppose it all depends on the speed and
> such, but when I last checked, most state-of-the-art SRAMs were
> pretty power intensive.

Our system from the 1996 race was a beast, it had relays that made
constant ticking noises, weighed several kilos and consumed over
14watts. On top of all that, it had no facilities for control, or
simple calculations. 

So it's not hard to beat, but we have chosen low power srams and have
focused on low power operation, rather than raw speed.  

Marc

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Marc Salem
m.salem at unsw.edu.au
0416 304 180 

UNSW Solar Racing Team          School Of Computer Science & Engineering
http://www.sunswift.com/        http://www.cse.unsw.edu.au/