AVR-Chat

Most of my questions on the list over the last year or so have had to do with an
ATMega32-based railroad signal controller for ride-on hobby railroads that I am
developing.  With the help of the list I have:

- Finalized the design of the PCB

- Made a prototype PCB (using Eagle and isolation milling with the help of
pcb-gcode)

- Run basic tests on the design and all was well

- Sent the design off to Advanced Circuits with an order for 100 boards.  Before I
placed the order, I studied their pricing structure and made up a spreadsheet
showing cost per board .vs. number of boards ordered.  It turned out that board #'s
51 -> 100 were almost free.  Above 100, the cost per board started going up again -
strange, I expected it to go down.  The board is 2.750" x 2.375", double-sided,
w/solder mask and silk on both sides, no cutouts.  Since this was my first
experience with a PCB house I was very nervous that I might have messed something up
such that I would have 100 "coasters" to give away as Christmas presents.  To my
relief, the boards came back on-time and looked great with very small (intended),
but legible, silkscreen print, etc.  I had set it up to "tent" the vias (vias 0.024"
drill, mask limit of 0.025") so that the silkscreen print would be uninterrupted but
most of the vias were coated (on the ring), some filled in, but few had a flat
surface over them.  Not as I had expected, but no big deal.  I plan on calling
Advanced and asking them what I should expect in this area.  BTW: My rep at Advanced
was very helpful in the whole process and followed up to see if I was happy with the
boards - I was.

- We stuffed one board and it passed basic tests so we stuffed 29 more while we were
at it (mostly SMT).

- I am now writing the firmware.  My two challenges have been that I am using
FreeRTOS for the first time and, due to the recommendations of list members, I
bypassed my initial plan (start with RS-485 and switch to CAN later) and went right
to CAN.  I included an MCP2515 CAN controller (SPI interface) and MCP2551 CAN bus
driver on the board.  It took me about 4 days to get the MCP2515 to cooperate -
mostly due to a dumb (aren't they all?) programming error of course.  On the
positive side, I have lot of 'instrumentation' in place as a result of the "bug
chase".  I now have simple test messages (w/o interrupts) going between two
controllers (over 5" of wire :-) ).  In the process I have gained a basic
understanding of how to work with the MCP2515 and I'm about to convert it to
interrupt driven.  So far I have not discovered any connections (traces) I needed
that I did not include in the board design, so, so far, the boards won't have any
ugly "cut/reroute" of traces.

- Observation: Since the MCP2515 was added after the prototype stage I wasn't sure
about how to drive the MCP2515 clock.  I ended up adding a "solder jumper" (3 small
pads) to the board so that I could use either OC2 (Timer 2 output) or XTAL2 from the
ATMega32.  It works fine using OC2 but the processor dies when I connect the MCP2515
clock to XTAL2 (14.7456MHz xtal).  In re-reading the ATMega32 datasheet just now I
realized that I don't have CKOPT programmed.  I'll try programming CKOPT later today
and see if there is enough drive to connect the MCP2515 so I can free up the OC2 pin
for other possibilities and run the MCP2515 at the full 14.7456 MHz (datasheet says
that it can go up to 40 MHz).


Now a question:  I'm currently using AVRStudio W/WinAVR but I would like to find a
(Windows based) debugger that has things like stack-traceback (AVRStudio does not,
as far as I can tell) and, if possible, is 'extensible' so that I could add code
that 'knows' how to display the FreeRTOS stacks, data structures, etc.  

I evaluated CodeWorks which supports Java extensions and had a nice looking debugger
but, unlike tools such as AVRStudio, GDB, etc., they do not support elf/croff2
files, etc., they only support debugging of object files that are generated by their
CodeWorks Studio tool chain.  I have too much invested in WinAVR code to re-target
it all so I have stopped looking at CodeWorks.  Plus, I was less than happy with the
response I got from CodeWorks support on several 'novice' (to CodeWorks) questions.

I'm now looking at using GDB and avr-insight (graphical interface for GDB) ...

Any other suggestions for a (preferably) graphical debugger (does not have to be
free, just 'hobby' affordable) for use with WinAVR that supports extensions that
would allow customization for things like FreeRTOS data structures or other "user"
data structures, such as the ability to follow linked lists, etc.?  I suppose I
could download the stuff required to re-build my own copy of Insight/GDB but, as
interesting as that might be, I'd rather spend my time working on my controller code
:-)

... sorry to be so long-winded ... anyway, thanks to all for the help getting me
this far.
 
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

I am interesting how you coming on your project. I would like to see it.

reid

On Tue, Jan 4, 2011 at 3:52 PM, Chuck Hackett <egroupscdh@up844.us> wrote:

>
>
> Most of my questions on the list over the last year or so have had to do
> with an
> ATMega32-based railroad signal controller for ride-on hobby railroads that
> I am
> developing. With the help of the list I have:
>
> - Finalized the design of the PCB
>
> - Made a prototype PCB (using Eagle and isolation milling with the help of
> pcb-gcode)
>
> - Run basic tests on the design and all was well
>
> - Sent the design off to Advanced Circuits with an order for 100 boards.
> Before I
> placed the order, I studied their pricing structure and made up a
> spreadsheet
> showing cost per board .vs. number of boards ordered. It turned out that
> board #'s
> 51 -> 100 were almost free. Above 100, the cost per board started going up
> again -
> strange, I expected it to go down. The board is 2.750" x 2.375",
> double-sided,
> w/solder mask and silk on both sides, no cutouts. Since this was my first
> experience with a PCB house I was very nervous that I might have messed
> something up
> such that I would have 100 "coasters" to give away as Christmas presents.
> To my
> relief, the boards came back on-time and looked great with very small
> (intended),
> but legible, silkscreen print, etc. I had set it up to "tent" the vias
> (vias 0.024"
> drill, mask limit of 0.025") so that the silkscreen print would be
> uninterrupted but
> most of the vias were coated (on the ring), some filled in, but few had a
> flat
> surface over them. Not as I had expected, but no big deal. I plan on
> calling
> Advanced and asking them what I should expect in this area. BTW: My rep at
> Advanced
> was very helpful in the whole process and followed up to see if I was happy
> with the
> boards - I was.
>
> - We stuffed one board and it passed basic tests so we stuffed 29 more
> while we were
> at it (mostly SMT).
>
> - I am now writing the firmware. My two challenges have been that I am
> using
> FreeRTOS for the first time and, due to the recommendations of list
> members, I
> bypassed my initial plan (start with RS-485 and switch to CAN later) and
> went right
> to CAN. I included an MCP2515 CAN controller (SPI interface) and MCP2551
> CAN bus
> driver on the board. It took me about 4 days to get the MCP2515 to
> cooperate -
> mostly due to a dumb (aren't they all?) programming error of course. On the
> positive side, I have lot of 'instrumentation' in place as a result of the
> "bug
> chase". I now have simple test messages (w/o interrupts) going between two
> controllers (over 5" of wire :-) ). In the process I have gained a basic
> understanding of how to work with the MCP2515 and I'm about to convert it
> to
> interrupt driven. So far I have not discovered any connections (traces) I
> needed
> that I did not include in the board design, so, so far, the boards won't
> have any
> ugly "cut/reroute" of traces.
>
> - Observation: Since the MCP2515 was added after the prototype stage I
> wasn't sure
> about how to drive the MCP2515 clock. I ended up adding a "solder jumper"
> (3 small
> pads) to the board so that I could use either OC2 (Timer 2 output) or XTAL2
> from the
> ATMega32. It works fine using OC2 but the processor dies when I connect the
> MCP2515
> clock to XTAL2 (14.7456MHz xtal). In re-reading the ATMega32 datasheet just
> now I
> realized that I don't have CKOPT programmed. I'll try programming CKOPT
> later today
> and see if there is enough drive to connect the MCP2515 so I can free up
> the OC2 pin
> for other possibilities and run the MCP2515 at the full 14.7456 MHz
> (datasheet says
> that it can go up to 40 MHz).
>
> Now a question: I'm currently using AVRStudio W/WinAVR but I would like to
> find a
> (Windows based) debugger that has things like stack-traceback (AVRStudio
> does not,
> as far as I can tell) and, if possible, is 'extensible' so that I could add
> code
> that 'knows' how to display the FreeRTOS stacks, data structures, etc.
>
> I evaluated CodeWorks which supports Java extensions and had a nice looking
> debugger
> but, unlike tools such as AVRStudio, GDB, etc., they do not support
> elf/croff2
> files, etc., they only support debugging of object files that are generated
> by their
> CodeWorks Studio tool chain. I have too much invested in WinAVR code to
> re-target
> it all so I have stopped looking at CodeWorks. Plus, I was less than happy
> with the
> response I got from CodeWorks support on several 'novice' (to CodeWorks)
> questions.
>
> I'm now looking at using GDB and avr-insight (graphical interface for GDB)
> ...
>
> Any other suggestions for a (preferably) graphical debugger (does not have
> to be
> free, just 'hobby' affordable) for use with WinAVR that supports extensions
> that
> would allow customization for things like FreeRTOS data structures or other
> "user"
> data structures, such as the ability to follow linked lists, etc.? I
> suppose I
> could download the stuff required to re-build my own copy of Insight/GDB
> but, as
> interesting as that might be, I'd rather spend my time working on my
> controller code
> :-)
>
> ... sorry to be so long-winded ... anyway, thanks to all for the help
> getting me
> this far.
>
> 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
>
> 
>


[Non-text portions of this message have been removed]

--- In AVR-Chat@yahoogroups.com, "Chuck Hackett" <egroupscdh@...> wrote:
> I'm currently using AVRStudio W/WinAVR but I would like to find a
> (Windows based) debugger that has things like stack-traceback 
I could be wrong but I believe that avr-gcc doesn't provide the necessary debug information to implement backtrace.  Moreover, not every function has a frame pointer anyway - only those that require local stack frame allocation get a frame pointer.  It might be possible force the compiler to generate a frame pointer for each function but you'll pay a penalty in code size and speed for this.

There may have been a thread or two recently on this topic at avrfreaks.net.  If not, it may be fruitful to post the question there.

I understand why you'd like this capability (I would, too).  I have debugged multi-task applications using the AVR Studio debugger without it.  You do need to be clever and resourceful on occasion to get the job done.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

> From: Reid
> 
> I am interesting how you coming on your project. I would like to see it.
> 
> reid

I don't have anything in "publishable" form yet (especially the software).  

What would you like to see?

Do you have a railroad you'd like to add signals to?
 
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

--- In AVR-Chat@yahoogroups.com, wagnerj@... wrote:
> I think this is an inherent limit due to JTAG debugging.
> You don't get history information out of JTAG.
Some ICE debuggers implement an execution trace buffer (JTAG does not) but that is not what the OP was referring to.  If the stack frames are set up to support it, the debugging software can "walk" the stack to determine the calling context, e.g. A called B called C called D where it hit the breakpoint and stopped execution.  Microsoft VisualStudio does this very well for C/C++, showing the parameter values passed, the point at which each nested invocation was called, etc.

Breakpoints aren't particularly useful for debugging some types of realtime systems, e.g. one in which you can't afford to stop the processor for any significant amount of time.  In these situations you have to instrument your code to allow it either to record important data to be examined at the end of a "run" or to output important data for analysis in real time by another computer, e.g. a PC.  Indicator LEDs and other types of information displays may be useful as well when the system cannot be stopped.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

Agree, but....

I think this is an inherent limit due to JTAG debugging. You don't get
history information out of JTAG. You just get the current state at the
breakpoint. The "alternative" would be single-step operation, which would
hardly be "real-time", due to the less than speedy traffic on the JTAG
link.

Jim Wagner
Oregon Research Electronics

> --- In AVR-Chat@yahoogroups.com, "Chuck Hackett" <egroupscdh@...> wrote:
>> I'm currently using AVRStudio W/WinAVR but I would like to find a
>> (Windows based) debugger that has things like stack-traceback
> I could be wrong but I believe that avr-gcc doesn't provide the necessary
> debug information to implement backtrace.  Moreover, not every function
> has a frame pointer anyway - only those that require local stack frame
> allocation get a frame pointer.  It might be possible force the compiler
> to generate a frame pointer for each function but you'll pay a penalty in
> code size and speed for this.
>
> There may have been a thread or two recently on this topic at
> avrfreaks.net.  If not, it may be fruitful to post the question there.
>
> I understand why you'd like this capability (I would, too).  I have
> debugged multi-task applications using the AVR Studio debugger without it.
>  You do need to be clever and resourceful on occasion to get the job done.
>
> Don Kinzer
> ZBasic Microcontrollers
> http://www.zbasic.net
>
>

> --- In AVR-Chat@yahoogroups.com, wagnerj@... wrote:
>> I think this is an inherent limit due to JTAG debugging.
>> You don't get history information out of JTAG.
> Some ICE debuggers implement an execution trace buffer (JTAG does not) but
> that is not what the OP was referring to.  If the stack frames are set up
> to support it, the debugging software can "walk" the stack to determine
> the calling context, e.g. A called B called C called D where it hit the
> breakpoint and stopped execution.  Microsoft VisualStudio does this very
> well for C/C++, showing the parameter values passed, the point at which
> each nested invocation was called, etc.
>
> Breakpoints aren't particularly useful for debugging some types of
> realtime systems, e.g. one in which you can't afford to stop the processor
> for any significant amount of time.  In these situations you have to
> instrument your code to allow it either to record important data to be
> examined at the end of a "run" or to output important data for analysis in
> real time by another computer, e.g. a PC.  Indicator LEDs and other types
> of information displays may be useful as well when the system cannot be
> stopped.
>
> Don Kinzer
> ZBasic Microcontrollers
> http://www.zbasic.net
>
>
>
>
I have handled this by implementing a "real time trace buffer". I write
certain information into the buffer (a constant indicating the function
identity, and perhaps a key variable), and maybe a key variable on exit.
It has been crucial to debugging protocol state machines for me.

Jim Wagner

Hi Chuck,
 
Well done on the progress. Good to hear you went straight to CAN.
 
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.
 
Then as you are about to read the register with the next command the
interrupt handler fires and changes the register pointer to get the received
data and then it exits the interrupt handler.
 
Now when you came back out, your foreground task would be looking at the
same register the interrupt handler just accessed and not the one you wanted
or had previously setup.
 
The issue I faced with the controller was the fact that I didn't get a
transmit interrupt until I actually sent something and it fired the
interrupt when that data was transmitted. I ended up switching off
INTERRUPTS whilst I was writing to the device which was only when I needed
to send data which on the design at the time was once per second. It only
had to be disabled for the SPI calls.
 
Hope this info helps.
 
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---

From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Chuck Hackett
Sent: 05 January 2011 05:53
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Project status report and question ...
 
  
- I am now writing the firmware. My two challenges have been that I am using
FreeRTOS for the first time and, due to the recommendations of list members,
I
bypassed my initial plan (start with RS-485 and switch to CAN later) and
went right
to CAN. I included an MCP2515 CAN controller (SPI interface) and MCP2551 CAN
bus
driver on the board. It took me about 4 days to get the MCP2515 to cooperate
-
mostly due to a dumb (aren't they all?) programming error of course. On the
positive side, I have lot of 'instrumentation' in place as a result of the
"bug
chase". I now have simple test messages (w/o interrupts) going between two
controllers (over 5" of wire :-) ). In the process I have gained a basic
understanding of how to work with the MCP2515 and I'm about to convert it to
interrupt driven. So far I have not discovered any connections (traces) I
needed
that I did not include in the board design, so, so far, the boards won't
have any
ugly "cut/reroute" of traces. 


Cheers,

Chuck Hackett




[Non-text portions of this message have been removed]

> 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

> From: wagnerj@proaxis.com
> ....
> I think this is an inherent limit due to JTAG debugging. You don't get
> history information out of JTAG. ....

Hi Jim, 

As I think someone pointed out, I'm not interested in an 'execution history' (i.e.:
what I would call 'tracing') but rather a display showing the current function call
chain that resulted in reaching the current code location.  I use this all the time
in MS Visual C# for my Windows code.  You can even set your context in any of the
callers to examine variables, etc.

I have very limited (aka: about zip) knowledge of how WinAVR constructs the frame
markers so I don't know if the data is even available without help from the symbols
or somehow adding to the code emitted by the compiler for call/return.

I was very familiar with these issues on the machine that I spent most of my carrier
on (Tandem Computers, Non-Stop I, Non-Stop II, and TXP) including writing debuggers,
etc. (even found a bug in one of the machine's hardware instructions) but, to my
discredit, I have let WinAVR shield me from this and other processor specifics on
the AVRs - hanging my head in shame ... :-)


> From: Don Kinzer
> ....
> Breakpoints aren't particularly useful for debugging some types of realtime
> systems ....

The problem I seem to run into a lot is when (in AVRStudio) when I do a 'step out'
of a function, I find myself in an interrupt handler.  I would have expected the
debugger to set a breakpoint at the return code location contained in the stack
frame and run but apparently it's doing something else (single-stepping out?).
Oddly enough, it doesn't seem to happen if I single-step (F10) out of the function.


> From: wagnerj@proaxis.com
> ....
> I have handled this (trace) by implementing a "real time trace buffer". I write
> certain information into the buffer (a constant indicating the function
> identity, and perhaps a key variable), and maybe a key variable on exit.
> It has been crucial to debugging protocol state machines for me.

Depending on the situation I'll just do 'wait loop' writes to the UART or, if timing
is more sensitive, do the writes via a circular buffer to an interrupt-driven UART
send function.  I haven't dealt with anything yet whose timing couldn't stand the
addition of the later - but I know such cases exist ...

As I mentioned in my other email, I'm evaluating Code::Blocks and CodeLite.  If
anyone has had experience with extensions available for either of these that
supports dealing with the FreeRTOS data structures in the debugger (Task lists,
TCBs, etc.) I'd appreciate hearing about them - even ugly, home grown, unsupported
stuff :-)
 
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

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




[Non-text portions of this message have been removed]

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

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