Hi,
just wanted to link my self in.
I am currently working on a port for the openmote, but I am only making
slow progress so far,
as I have only limited time unfortunately.
You can find my fork here: https://github.com/AnonMall/RIOT/tree/network
Right now the driver for the RF is sending out data, but receiving is
still work in
progress. I have to finish the radio port until end of February for work
and for my
bachelor thesis so until then it should be working.
Cheers,
Anon Mall
Am 14.12.2015 um 11:24 schrieb Hauke Petersen:
Hi Aaron,
good to hear you want to put some work into the OpenMote! Let me try
to answer your questions best to my knowledge:
On 13.12.2015 04:06, Aaron Sowry wrote:
Hi,
I'd like to try and improve RIOT OS support for the OpenMote platform
in general, and the TI cc2538 MCU specifically. The most pressing item
for me currently is RF support, but I would also like to see support
for the ROM API and a few other things (including the sensors on the
OpenBattery board, eventually).
I'm new to RIOT and thought I'd try to clear up a few things before
getting my hands dirty, so you'll have to excuse me if some of these
questions seem obvious/stupid/irrelevant:
1) TI provide open-source firmware for the cc2538, but I can't find
any trace of it in the RIOT tree. It seems like there are a few
cherry-picked bits and pieces but not in the same format/layout as the
original firmware. Is there a reason for not including TI's firmware
in the tree verbatim (I'm thinking licensing/re-distribution issues,
architectural or coding-style differences, etc)? It seems like this
would make fully supporting the MCU a lot easier.
You can't find it because we are not using it... The main reason for
this is manifold: TI's firmware is bloated, in-efficient and I am not
sure about the licensing (though this might not be an issue).
Personally I also doubt, that it makes porting so much easier - in the
end you have to read the ref manual in any case to understand the MCU,
so why not program the registers directly without overhead through
some vendor library...
2) To avoid duplication of effort, is there anyone else already
working on RF support for this chip?
Not sure, did you search the mailing list archive? There might have
been something on this in the past...
3) Where should a hypothetical RF driver for the cc2538 live in the
tree? Since it's on-chip should it live in the cpu subdir? Or
programmed as a "module" the same way as for peripherals?
If I see it right, the radio is register mapped on this SoC, right? In
that case the radio driver should reside in the cpu subdir.
4) Are there any guidelines or example code for this kind of work? The
only other on-chip RF driver I could find to use as a reference is for
the nrf51. Perhaps this will do to get me on the right track, but just
thought I'd check if there's something I missed.
Not yet. You saw it right, that the NRF51 is the only SoC with
register mapped radio at the moment in RIOT. But you should not 100%
trust that implementation, as it is not quite up to the current
'state-of-the-art' in RIOT, ergo it does not implement the netdev2
interface.
Let us know if you need more information!
Cheers,
Hauke
Thanks!
/Aaron
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
