Quote:
|
The other idea is to write a python or C application to connect to the low level API across the serial link and drive the programmer without having to upload anything.
|
That brings with it the problem of having to support at a minimum Windows, MacOS and ideally Linux versions of the 'support software'. I can appreciate that Python in particular is very portable and will even run on a Raspberry Pi, so quite a good choice if you were going to go that way. I think you would have to have some way for the program / script to know which OS it was being run under so that for example it could use the correct terminology for serial ports (TTYsx for Linux, COMx: for Windows etc).
When I made my version of the Arduino keypad injection loader which does take in Intel Hex files sent from a terminal I wanted a highish baud rate so that two or three K of Intel Hex would seem to transfer almost instantly but to achieve that I had to add a cheap SPI SRAM as a serial RAM buffer and I also had to use block write mode when writing received bytes to the SRAM because writing individual bytes (write command, address high, address low, data) each time was slowing things down too much.
I could have done it without the SRAM if I had been prepared to drop the baud rate right down and for this project where the maximum file size is 512 nibbles (although rather more if an ASCII hex format is used to represent those nibbles) it may be acceptable for it to send the code over more slowly.
An LCD display need not take up too many resources, you could use the same 9 bits being used to drive the PROM address lines to drive the 8 * display data lines plus the display R/S line, with only one uP I/O pin dedicated to the display EN pin, R/W being assumed to be tied low so that the display operates in Write-Only mode.