You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
67 lines
2.5 KiB
Plaintext
67 lines
2.5 KiB
Plaintext
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.
|
|
|