Open kb1lqc opened 6 years ago
RIOT-OS failed to work out because we could not program a radio easily in Linux where RIOT-OS is compiled. It's possible to compile in Linux and program on Windows but this is a slow development process and we still need to develop radio control firmware. Solutions for Linux would be to write a new TI BSL in C. Python libraries with existing libFTDI libraries has a bug that prevents proper use of CBUS lines when programming. We unfortunately use CBUS lines to toggle BSL mode on the CC430.
Texas Instruments licensing is a bit weird and it's unclear that we actually can easily use this for Faraday as an open source project even in TI's source code is available. RF protocol is possibly proprietary however it is openly specified. We would still need to command radio from scratch. It's unclear if a full IP packet can easily be sent over the protocol. A lot of the hard work is done for us however.
To our understanding it's pretty big but could work. There is potentially a compile code size limitation workaround using GNU compilers and even then any programming needs to be done in Windows to get debugging/JTAG installation.
This is a whole project in itself. It appears to not fit on the CC430 and is not really ported to it.
This could work though Google searches show that one barely fits FreeRTOS onto the CC430 with most functionality disabled. Then we still need to implement the radio.
This is looking nice again. Bluntly, we are limited by the CC430 and it's becoming an issue. We in the end need a extremely simple way of passing bytes around over RF and connecting the radios to pass IP traffic. Achieve usefulness and possibly improve hardware to open up our ability to leverage an actual OS such as Linux. This figure hardware may not be backwards compatible but we don't know and can't stop ourselves from moving forward now.
If we want to implement a super simple peer to peer radio link with IP traffic then what would be the necessary work? The following items are questions we need to answer as well as known work we know we need to do.
Where possible, use TI generated code here to speed up development
Next up is @kb1lqd and myself clearly defining expected data interfaces in good documentation for the Faraday TUN adapter and the new firmware. The firmware will be simplified as much as possible to help us move fast and efficiently.
I wonder if we should consider including unit testing for the C code as well. This is one area I could help out with on the side once the TUN is defined as a client.
Possible Firmware Options
RIOT-OS