No, I get it. That's what I was thinking. I like that design too, once I mulled it over a bit....ala KISS.
...that was part of the epifany.
Why worry about addr change? Let it read the addr and write the data as fast as it wants or add some NOPs or equivalant.
When the /CE does go low it might write the pins with the same data dozens of times before the CE is released. As long as the outputs dont "blink" ,should be no harm no foul.
All the uC's I've seen overadvertize the I/O. Once you muddle thru the cant use this if that, avoid using the other when your doing something else......
Looks like the Pico is plenty fast to multiplex addr lines via latches or use a parallel to serial scheme but that increases parts count/complexity..there goes KISS.
One thought is to mirror the codeplug data in RAM at boot time and serve the codeplug data from RAM.
Probably helps speed a bit too, but mainly it will let PH II data manipulation occur in the EEPROM at will without interfering with the read operation, or serve a partial edit of frequency values.
The last step of the data modification routune would be to pause the state machine, refresh the RAM with the new data and restart the state machine.
Also, the radio is going to expect to read and calc the checksum first thing on it'd bootup. The emulator needs to online serving data before that.
