On Sun, Aug 14, 2022 at 11:10 AM, Skip Hansen wrote:
Another fairly easy project would be a radio protocol converter for our TBD odd ball SB9600 commands.
@ Skip,
Thank you for all your efforts to put this together.
I really hate the idea of loosing the legacy protocols.
If there is a way to save at least I2C and maybe even CI-V that would make interfacing other devices much easier.
I've been researching the project needs vs the GPIO limits to see what alternatives there may be.
A few things come to mind, but it does become clear KISS is relative,
"Another fairly easy project would be a radio protocol converter for our TBD odd ball SB9600 commands."
I think I'm reading that as a? sub-proccesor or co-processor to handle ?
Here's some stuff I've mulled over:
Freeing up some I/O
1 - What can the onboard USB 1.1 be used for under uC program control?
2- Ideally we want to have RS232(can drive the BT radio?), SB9600, CI-V, Doug Hall, I2C, others?
Are any mutually exclusive or need I/O at all times in all mode of operation?
Could some of these protocols share the physical com line pins releasing them for another protocol when their task is done?
A wireless SB9600 interface is a nice idea but definately falls at PH II or PH III.
The only "have to have" SB9600 command is something to force the uC to read the EEPROM mode data as commanded by the Pico.
For that matter a dedicated ATTiny or PIC F8x could get a "send it" cmd via I2C, RS232 etc. and, with respect to the radio's busy line protocol, spit out the pre-formed packet(s). t's not going out of the radio so it could even be tied to the single ended side of the bus.
?
3 - With properly manipulated zero page values, it *may* be possible, for the X9000 to functionally operate in a 4k space with a 128 mode limit.
?The PL/MPL mapping is the challenge. I need to dig back into the details of that to verify.
Regardless it will operate in 2k space with 64 modes. Again PL management is a thing if >16 MPLs are expected, but I think that could be addressed in code with a form of expanded memory/page swapping routine.
None of these custom codeplugs would be compliant with RSS/OEM OS and if we tell the radio it has an 8k codeplug, it will need to see 8k of correct data to perform checksum verification.
We could free up to 2 I/O pins with this method.
4- It looks like GPIO 28 is the only free pin left as drawn?
...and what's up w/GPIO25? Waste a GPIO just to have an on board LED to flash?
An onboard LED is a good feature. Not providing access (that I can find any reference to) and consume a General Purpose I/O just to flaxh an LED isnt.
Leaving KISS in the rear view mirror, for me, I'd tack a wire on that sucker and put it to work.
5- Again, deviating from KISS, recapturing I/O? by doing serial to parallel for the data lines would not even be a blip as fast as this thing runs. Actually I think it would have to be slowed down a bit.
A 595 takes 3 I/O to load and clear. That give us back 5 of the d0-d7 lines. The 595 comes in a DIP and may have a level translation version (I've never looked for one). If so, that would be a zero net gain of components by eliminating a 244.
I dont know how much driving serial vs parallel data, plus control lines would impact state machine/DMA code.
