arduino-0018-windows

arduino-0018-windows/hardware/tools/avr/doc/simulavr/TODO

@@ -0,0 +1,66 @@
+During 0.1.x:
+
+  - complete simulation of 8515 device.
+
+  - external peripheral device connection interface.
+
+  - write, read and access watchpoints
+
+  - documentation
+
+During 0.2.x:
+
+  - add support for all at90s**** devices (Is this too ambitious?)
+
+  - speed improvements (optimization)
+
+During 0.3.x:
+
+  - add support for megas and tiny's (This might require some redesign
+    work to get the atmega128 like devices right)
+
+Misc TODO's:
+
+The conversion to autoconf/automake configuration is working, but still needs
+to have the actual porting issues worked into the project. Also, the autoconf
+macros (the config/*.m4 files) could be robustified. For instance, the
+TROTH_PROG_AVR_CC macro really should do more than just checking if avr-gcc is
+in yout $PATH. It should also make sure that avr-gcc works. Like wise for the
+other macros. It's a start at least.
+
+Build the virtual hardware harness and gui. I'm thinking it be able to plug a
+device into something like the Atmel stk200 board thus giving the user LEDs
+for visual feed back and push buttons for supplying inputs to the ports. Also,
+I'd like to simulate the analog comparators and ADCs if possible. It might
+also be interesting to simulate a popular LCD display.  More interesting might
+be the potential for custom user designed virtual peripherals which could be
+plugged into the virtual board. I wonder if I can use the same interface as
+gpsim, thus allowing the sharing of modules between the two projects?
+
+Make a python module out of the library.
+
+Need to write functions for loading/dumping eeprom from/to files.
+
+Add support for ihex, srec, elf, and whatever else input file formats.
+
+The interrupt code looks like it needs a major re-thinking. It doesn't handle
+the interrupt flag mechanism and doesn't support automatic vectoring into ISRs
+that occurred when the interrupt occured and was disabled either globally or
+by the specific control register and then the interrupt was subsequently
+enabled. This looks like it might be yucky. I'm seriously thinking that
+interrupts need to be handled via some asyncronous mechanism like unix
+signals. Also, some way to implement the interrupt response time needs to be
+thought out.
+
+Add code to output number of instructions executed (and per second) and total
+number of clocks (and per second). Should go in main.c.
+
+There's a bunch of FIXME comments in the code in places where someone needs to
+give more thought to the logic.
+
+These io registers still need to be implemented:
+  GIMSK
+  GIFR
+  All the timer/counter 1 stuff.
+  Lots of others too.
+