Dear RIOT developers,
- Which radio driver is the most up to date with regards to the
network stack restructuring work being done in #2278?
- How stable is the radio device API currently? Are there any more
API changes coming?
- Would it be wise to wait until the restructuring todo list is
mostly checked off until starting work on implementing a new radio
device driver?
- Which driver would be best to use as an example of a fully
compliant radio driver?
I am looking at implementing a driver for a new radio chip, but I do
not want to have to redo the work again in a couple of weeks because
of the network refactoring...
I think it will be the at86rf231-driver (in near future). @thomaseichinger is currently working on the refactoring according to the network restructuring. There is still no PR but as far as I know the progress is well. I think it's wise to wait at least until this driver is merged, as it acts as a proof-of-concept for network devices. I assume there won't be many changes to the netdev API. So if you cannot wait with this for time reasons, the potential adoptions might be small (I hope ).
Thank you for the prompt response. I will start reading the existing drivers but I think I will wait at least until there is a PR for the rf231 before I begin my implementation work.
Thank you for the prompt response. I will start reading the existing
drivers but I think I will wait at least until there is a PR for the rf231
before I begin my implementation work.
As Peter mentioned I'm working hard on refactoring the rf2xx driver. As we
want to use it on EmbeddedWorld on Tuesday you can expect a PR for this
soonish.
How is the new rf2xx driver coming along?
I have been seeing some memory corruption problems on my platform and
I think it originates somewhere in the radio stack, but I have not
managed to pinpoint it further. I would like to test the new driver
before I spend more time chasing down a bug that might have already
been fixed in the refactoring process.
Is there any WIP branch we can look at?
Do you have any ETA for a PR?
sorry for the silence on this. The driver is almost ready I’ll open a
PR for it by Thursday at latest. I was discussing with Hauke the initialisation
process for the network stack and also initialisation in general.
I saw these memory corruptions too, but didn’t manage to identify the
source neither as I focused on the driver refactoring.
as of today, I PRed a new version of the Xbee S1 radio driver[1], which is build 100% on the new netdev interface. I think it makes a good reference implementation for radio drivers, even if it is through it's UART interface a little different from others drivers we are supporting...
So to my opinion, the netdev interface can be considere as stable (I expect only very minor changes). So if you want to go ahead implementing your new driver, now is a good time as any!
).