He's just going to have to learn this the hard way. He doesn't even seem to want to discuss details of how his own approach can be made more likely to succeed.

Perhaps it's just a cry for attention.

In a way, I'm happy to see him sticking to his guns, however silly his approach. However, I'm concerned that he's not chosen, or even considered, the most efficient/effective way to move data from the PC to the MCU circuit.

So far, there's been no detailed discussion of how he intends to move the data into his MCU, and from there into the EEPROM. At one point, he was intending to synchronize the data transfer between his PC and his MCU by using an interrupt. I don't think he ever considered interrupt latency. At another point, he intended to stop the oscillator in order to allow for the PC-generated delays, but never considered the rather lengthy start-time for the oscillator.

I'm convinced it would be easier for him simply to program the EEPROM from the PC while holding the MCU in reset. I'm not interested enough in this project to learn how to program his ATMEL (yechhh!) EEPROM so I'm not getting involved in that, but I do know it would be quite straightforward for him to load the code into his 8KB SRAM, and map the SRAM into code space on RESET, and under configuration control from the parallel port. That would allow him to load code into the SRAM without any synchronization issues, then program the EEPROM, block-by-block with data loaded successively, block-by-block, into the SRAM's upper half. That doesn't "fire his rocket" either.

I'm beginning to believe that he's after the attention, negative or not, as opposed to being ignored.

RE