AVR-Chat

> From: Dave McLaughlin
> 
> Hi Chuck,
> 
> Well done on the progress. Good to hear you went straight to CAN.

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

> I have one comment on using interrupts that you might need to be aware of.
> This won't apply if all your code for the MCP2515 is done in the interrupt
> handler and you are not using SPI for anything else.
> 
> The issue you have is when you want to send CAN data. If you have interrupts
> setup for receive, which is the most likely case, then you can't be checking
> the MCP2515 in any of your foreground code to send data unless you have some
> form of critical section around the SPI stuff. My first attempt at writing
> this was long and messy, I'll try again.
> 
> The reason for his is that if you might be in the middle of sending an SPI
> command to the MCP2515 in your foreground code to setup the register to read
> or write to.
> ....

Thanks for pointing this out.  On my current boards the MCP2515 is the only thing
using the SPI.

I'm currently planning on doing the transmit buffer transfers to the MCP2515 at the
task (FreeRTOS) level with the task yielding the processor in the 'wait for SPI'
loop while waiting for the SPI transfers to complete**.  

** 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).

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.

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'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.

Thanks again ...
 
Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844 http://www.whitetrout.net/Chuck