开云体育

My plan is to have an area in RAM that mirrors the EEPROM data.  The
PIO state machine would DMA data from the RAM buffer to the GPIO pins
automagically.  The CPU would have nothing to do except montor the
serial port for commands (CI-V or SB9600).  If a command came in that
modified the VFO it would just update the bytes in RAM.   No need to
stop the state machine, if the Syntor happens to read at the exact
microsecond it might get inconsistent data, but that's no worse than
no data if the state machine were stopped.

The reason for only updating the data output on address change was
just to optimize the response time... probably something that's not
even needed.

I don't like losing functionality that the legacy Xcat has, but I have
no idea if anyone ever used it or now (Doug Hall "user functions"
primarily).  I put a digital pot in my 2 meter radio for squelch.  I
tested it with the PC control program, but I never really used it for
lack of control system support. "Back in the day" there were WAY more
than a few trips to the hill to tighten or loosen 2 meter and 6 meter
squelches!

73's Skip WB6YMH

On Tue, Aug 9, 2022 at 3:35 PM swguest via groups.io
<swguest@...> wrote:

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.