If you are interested in some interesting tools that are designed
for
the AVR then I suggest that you look into Avrora:
<http://compilers.cs.ucla.edu/avrora/>
Among basic simulation it also has: profiling utilities,
instrumentation
capabilities, control flow graph tool, and a stack checker. Note,
however, that I have not tried Avrora so I cannot comment on its
efficacy.
That I will check out.
Avrora would be much better because of the static checking that it
can do. Rather than implement the SD card interface.
Avrora can also do dynamic checking on your code too, with its
instrumentation capabilities. There is a description of its
capabilities in "Nonintrusive Precision Instrumentation of
Microcontroller Software" in LCTES 2005 (linked on the webpage).
We originally wanted to do a lot of static analysis on AVR code, and
there are still people in our group working on the project, but the
static checking capabilities of Avrora are superseded by its dynamic
capabilities.
Could you be a bit more specific with what you would like to see?
Well, medical, automotive, and aeronautical systems usually require a
higher standard of testing. Often it's done with the .elf file on a
simulator, but given a filesystem, it can be done on the target. As
far as boundschecking, I find most bugs in embedded systems are
pointer/array bounds accidents. Instrumented code could give line
numbers over the uart when detecting bounds overflows.
- If you're talking about simple instrumented code with a UART
interface, then that is easier than implmenting the full SD Card
interface. And it would probably be faster than trying to use these
other projects.
You can also have your instrumented code output to the UART, just as
you would with a hardware device, in Avrora. You can then have the
UART interface connected to a socket so that the program running in
simulation outputs to the simulated UART, which in turn outputs to a
socket that you can dump or debug on.
There is a monitor for doing serial connections that a number of
people at UCLA have been using to debug their code in both simulation
in hardware, so if you want a solution that works in both situations,
then it is possible.
Hope this helps,
-B
_______________________________________________
AVR-chat mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-chat