AVR-Chat

Resent as Yahoo messed up the formatting (AGAIN!!!!)...........
---------------------------------------------------------------

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