[Discussion] Further Abstract out the hardware via firmware
howard0su opened this issue · comments
I would like to further abstract the hardware and make the extio not getting to the details of hardware. As we are working on the new revision of hardware, it will be painful to get the PC software to adopt the changes in order to support it.
My proposal, (i actual have some code locally)
- Remove radio type from pc hardware, instead of having a set of capability structure to describe the hardware. For example, Frequency Range (like 0.1M - 64M etc), Att range ( -32db to 100 db), AGC support (like yes/no), Hardware Sampling Rate( for example, RX888 can support from 32M to 128M, other may fixed 64M, etc)
- Change the interface of USB to more functional orientated. Remove GPIO support, replaced with LED update, ATT update, etc.
- Still keep the concept HF and VHF, but replace it with the new concept of ZIF mode and IF mode. In the item 1, we will return each mode frequency range, bandwidth, ATT range.
In the new revision of hardware, we plan to change the tuner with big bandwidth, add dedicate chip for ATT/LNA, has the CMOS switch for HF and VHF. all above items are some sort of requirement in order to keep most of current EXTIO investment.
not sure, how much has to be moved into firmware.
independent of hardware, integration into other SDR Software like SDR# or other Operating Systems like Linux is important.
the point is, one user can't oversee / operate with the full spectrum of > 32 MHz. think the limit for one user is around 1 MHz bandwidth in a waterfall. thus, the device makes more sense for multiple users/DDCs.
thus a 'driver' only basis library, as Franco's https://github.com/fventuri/RF103 would be quite important .. especially for Linux and also for Windows .. and ExtIO should use such a library.
..Random thoughts.?
We have now a software architecture of this kind
(FX3ARM , GPIFII) <=> Driver (Cypress) <=> ExtIO.dll <=> HDSDR.
The Si5351c and R820T2 programming moved to the FX3Arm code. It obtains faster response and simplifies ExtIO code. Up to now the FX3Arm firmware.img is loaded by ExtIO.dll using CyApi.lib and driver.
The Driver is not open source. If we 'move out' from Cypress 'streamer example' PID/VID in the USB descriptor, are we able to manage the driver code and configuration in Linux and Windows ?
A big step will be use the more general driver library interface.RX103.lib:
(FX3ARM , GPIFII) <=> Driver <=> RF103.lib <=> ExtIO or any user application.
At that time the library will take care the control of driver, hardware configuration and FX3 Arm code.
@Horward: your proposal is a nice opportunity to improve the existing code and to have an integration of the new hardware development into today architecture and to debug it.- The only practical problem I see is in debugging of FX3Arm code as it uses now a serial port connected to FX3 superspeed kit uart. That is possible to BBRF103, I'm not sure it could be made easily in a RX888 wired patch, maybe another solution have to be found (via USB ?).
Oscar, Howard,
last night I took a first stab at adding the USB Debug console to the SDDC_FX firmware. I already made the changes to the USB descriptors file and to 'StartStopApplication.c'
I pretty much followed the code from the book 'SuperSpeed Device Design by Example' by John Hyde (Chapter 6) - John's examples are under the book's web page here: https://www.cypress.com/documentation/other-resources/superspeed-device-design-example-john-hyde - the specific example I am referring to is in the folder 'FX3 Firmware Projects/CDC_BulkLoop'.
I just pushed the work I've done so far to this new repository I created: https://github.com/fventuri/SDDC_FX3 - the intent is to work on this separately, make sure it works, and then merge the modified firmware back with the original (if you are OK with this plan, of course).
One thing left for me to work on is the code in 'DebugConsole.c' - before I started working on that, I wanted to discuss with you what is the best way to detect if the SDR has the UART "connected" or not (if there is a way to tell): in other words, if the UART is accessible and connected, I'd like the DebugConsole code to behave the same way as John's code (both UART and USB consoles are available and the command 'switch console' allows to switch between them); but if the UART is not accessible and connected, the DebugConsole is always connected to the USB interface, and the command 'switch console' does not attempt to switch to the UART (or even better, is completely disabled).
Franco
Franco,
I'm very happy is you collaborate at the code ! Thanks for ideas and support.
I like your proposal to add the USB for debugging if UART is not accessible,
Oscar
Thanks Oscar.
I just created a new branch called 'DebugConsole_over_USB', and pushed all my changes from last night there.
I'll remove my repo and keep working on that branch until it is ready to be tested.
I need to figure out a good way to be able to tell if the UART is connect or not - I'll look at the rest of the firmware code tonight to try to figure out, and if not, I'll just select it based on the HW type.
Franco
Thanks Franco and Howard,
By the way, Detection of BBRF103 using GPIO54 LED on FX3 kit sometimes failed to me and RX888 was detected. On my BBRF103 I added a 500 Ohm pull up resistor on FX3 Superspeed kit from GPIO54 and V3P3 on header J7. That works fine to me.
Andrew G4XZL made its own BBRF103 and he noticed problem with the detection too. We are investigating.
Howard proposal seems fine to me.
Oscar, Howard,
I just pushed the remaining (hopefully) code changes so that the debug console could also be available over USB (the two main files I changed today were USBhandler.c and DebugConsole.c) to the branch 'DebugConsole_over_USB' (I already merged that branch with the latest changes to 'master' by Howard).
The firmware code compiles without errors, so you should be able to compile it, give it a try and let me know how it goes.
As you suggested, I added the variable 'glIsUartAttached', with the following values:
- 0 -> no UART attached
- 1 -> UART attached
- -1 -> tries to figure out if the UART is attached or not attached based on the HWconfig variable (the first few lines in 'InitializedDebugConsole' show how I did it)
Have fun!
Franco
The current code abstracts most hardware difference into Hardware classes. I love to hear the option if we want to push down the hardware implementation into the firmware.
Yes, hardware implementation in the firmware is very fine.
The debugging of firmware maybe can use some ''trace" messages in the communication protocol with the firmware instead of uart that at the moment I'm not able to solve in windows driver ?
Oscar, Howard,
if you are interested, tonight after work I can refresh that code in the 'DebugConsole_over_USB' branch (I haven't touched it in a week or so), to bring it up to date with all the latest changes that you have made to the SDDC_FX3 firmware.
This way we can try to figure out where the problems are (of course if you are interested and have time to look into it; no offense at all if you prefer a different approach).
Franco
Oscar,
I just merged all the changes from master into the 'DebugConsole_over_USB' branch, and push that commit so you should be able to run some more tests with it (the USB descriptor has still the temporary VID/PID of 4242/ABAB, so hopefully it should not cause any conflict with your existing SDRs).
Franco