Bill,
If a 328 is used and the Bitlash code takes 14.4K, that leaves over 17K spare. My code will probably fit in 2-3K including the pixel data and stuff (freaky assembler code). This will still leave a whopping 14 to 15K left.
A few thoughts regarding the use of spare flash ROM for storing macros -
As the EEPROM is small by comparison, would it make sense to actually keep most of the macros in the flash ROM, and just use the EEPROM as a kind of scratch-pad area where the user enters and edits their program?
This would allow a much larger and more powerful system - I assume. Also, it would be nice to have a lot of routines, macros and so on just there so you could call on them.
In this case, could the macros be encoded in the EEPROM as byte or word tokens which simply called a macro in ROM without having to be parsed each time, so that you would get much more room in there? I don't think I understand your software well enough to really see into this, but I'm looking at it from a space point of view (must be my assembler leanings here).
From an interpreter point of view, I can't understand why tokens would be a bad thing. I have not written a compiler or an interpreter, and don't actually know what I'm talking about here, I'm just trying to understand your software and how it works.
As well as taking up less space than a character string, once a function has been translated into a token, the interpreter could just load the token into a jump table (or whatever you call it in C) and execute the code immediately.
I'm sure there's at least one reason why you are not using tokens, sorry to be nosey and actually want to know how it works and so on... not really relevant to getting it working but I'm just a curious sort.
To start with I will do some code to just read and write from the standard serial port, and leave the USB handling as a "to do".
I'm not too sure I need to worry too much about integrating Bitlash with my code as long as I understand what bits it interfaces through.
As long as I can compile the Bitlash code it will stay more or less constant and I will be erasing and re-programming my code and interface software until I get it right, so I will probably use a fixed location to call Bitlash and leave it where it is.
My aim is to get Bitlash up and running with just a basic serial port communication on an ATM328. From this I can start playing around and work out how to run my code fired off interrupts, while Bitlash runs as the main program loop.
It would probably be of great interest to many AVR Freaks to be able to get a ready compiled hex file which could be uploaded to a blank ATM328 via AVRDude, to let people play with Bitlash via the serial port. This would only need a couple of connections (Rx, Tx) to have a working system that could be experimented with.
I can't put any time into this right now as I have a development job which is late, but I will look at doing it as soon as I can unless someone else beats me to it!
Thanks all,
Zadok.