Nice work Attilio. I was just starting to explore into this board from TI and this is going to be helpful.
Did you create a pull request for this port ?
Meanwhile, a point that points you can look into.
For flashing/debugging CC3200, you can use openocd as well as cc3200.cfg configuration file is already available.
You can put that in the board/dist. I am not sure but I think cc3200prog binary may be license limited.
More over it will be helpful even for debugging
Before creating a PR I need just some confirmation, the most important is that driverlib from TI is license compatible with RIOT (cpu/cc32000/driverlib and cpu/cc3200/inc files used as HAL for the drivers).
I suppose there is no problem but it is better to have a confirmation from RIOT community leaders.
Under cc3200-launchxl/dist there is already a debug.sh using openocd that should work as a debugging tools:
make BOARD=cc3200-launchxl debug
For flashing I don’t know how to flash the external SD card with openocd, do you or someone else know how to flash with openocd or in some other ways?
Greetings
Attilio
ps. for Arvind: if cc3200 TI driverlib is RIOT license compatible, the equivalent driverlib for msp320 could be a good starting point for your chip?
I will let others also weigh their opinion on this, but driverlib has lot of TI license code which may not acceptable since it has a clause for limited usage. But you can use the header files which are under /inc folder which have BSD license.
Thanks a lot for your effort on getting this board supported!
I need just some confirmation, the most important is
that driverlib from TI is license compatible with RIOT
(cpu/cc32000/driverlib and cpu/cc3200/inc files used as HAL for the
drivers).
I just took a quick look, but it seems like "driverlib" is TI's own
hardware abstraction C code.
Our philosphy here was always to not use vendor-supplied HAL code and
instead rewrite hardware support from scratch.
While that requires a little more effort for a new port in the
beginning, we usually end up with a lot cleaner, smaller, more-to-the
point code that can more easily be shared between platforms.
(The license used by driverlib looks fine actually.)
I agree with RIOT philosophy, so a rewrite could be a nice thing, but I also think that this is not a top priority now, at least for me …
If someone else wants to contribute it would be great!
One more thing to consider is that cc3200 has:
256 Kb of RAM
an external SD serial flash card memory where to flash the image
an internal ROM memory burned into the chip that hosts the bootloader and the driverlib “ROM version” (directly from factory)
So from version ES1.33 it seems possible to link to the ROM version of driverlib for resource optimizations (so could be a waste to throw away the driverlib API?)
I have not tested this setup yet, but I think could be a trail to do.
IMHO that is exactly what we do! @kaspar: in this particular case (as for the LM4F120 launchpad board) it makes very much sense to use the provided hardware abstraction to implement RIOTs periph interfaces, as the code used by this HAL layer is burned into read-only ROM directly on the CPU and thus does not use any additional memory… Cheers, Hauke
I’m proud to announce that I have just completed a working version for cc3200 chip on launchpad board.
There are a mqtt client and an httpserver demo, ported from TI SDK original examples, under RIOT/examples directory (for sure not the right place but I don’t know a better place for the cc3200 specific examples app)
.