AVR-Chat

Resent as Yahoo messed up the formatting...............
----------------------------------------------------------------------------
----

Yea, I kind of took a "Leap of faith" :-)

[>] Good for you. I often use my hobby time to learn new devices or
programming 
[>] and it pays dividends at the office later.

** at the moment I'm using a fairly slow SPI transfer rate but, after I get
the
firmware checked out I'll step up the transfer rate until it starts failing
and back
off a bit (14.7456MHz cpu clock).

[>] The SPI on the device is capable of 5MHz operation so you should be able
to 
[>] get it pretty quick.

Receive: To keep things simple I'm currently planning on fielding the
interrupt in
the interrupt service routine, disabling that interrupt, and queuing the
fact that
there is a receive message available to the task for it to process. After
the task
has processed the message I'll re-enable the interrupt to field the next
(possibly
already received) message. This may slow down the message handling a little
but it
means that the task won't have to turn off interrupts to do the SPI
transfers and
the code will be more straight-forward (I believe in KISS). My expected
message
rate will be fairly low and this will allow me to use the queuing in the
chip rather
than creating one in the (getting cramped) ATMega32 SRAM.

[>] Why not just process the data in the interrupt? Your only concern is
when you 
[>] come to transmit. If the RTOS you are using allows task aware interrupts
then 
[>] simply set a critical section or semaphore when you want to access the
SPI in 
[>] any other task. I have done this very successfully with Netburner and
Rabbit 
[>] devices. I have a CAN based heating and power monitoring solution that
does 
[>] this very thing. It has been running now for 2 months with no adverse
effects 
[>] and is both transmitting and receiving data at a rate of 10ms for the
fastest 
[>] message on the bus. I expect it to run forever like this.

This task can run at the highest priority since other processing is not time
critical. As long as the controller can respond within maybe 500ms things
will be
fine - of course faster is always better :-)

[>] I would say much faster. Your only issue is how your tasks are arrange
and 
[>] how quick the one that services the SPI will run. If the RTOS is
pre-emptive 
[>] then with this task being the highest priority then you have no issues
with 
[>] losing data, in theory!!

I'm fine so far on code space but the stack/heap situation could be better.
I
probably should have gone with the ATMega64 to give myself headroom - live
and
learn. Knowing what I know now, next time I might even go to an AT90CANxxx.
It
took me a bit to "get my head wrapped around" the MCP2515 but I feel better
now that
I have two of them talking. I wasn't confident that I'd be able to digest it
all in
time. I have to get this next version done by Feb. 13th to get in a bunch of
new
signals we want ready for a large railroad meet.

[>] If you need help with the AT90CAN in the future let me know. I have this

[>] working using the code from Atmel which I ported to the Codevision
compiler. 
[>] I have yet to implement interrupt handling but at the moment the 10ms is

[>] working with polling.


Thanks again ...
 
Cheers,

Chuck Hackett