at the strategy meeting today the (bigger) topics of what is still on
my plate came up. So this is my list from most complex to least time
consuming, to least:
* Network layer/NDP overhaul: expect a model proposal and of July.
Let's discuss this then and I'll provide an actual implementation
after some(TM) time (To re-iterate an old Meme: "The border router
will be ready soon!")
* Further improve doc (DocTF), collecting all the input from the
mailing lists (and e.g. the summit) into some kind of requirement doc
for the doc and find something that makes new users really happy. No
time table for this ATM, would appreciate some help in that effort.
* Implement the new conn for all supported stacks (GNRC, lwIP, emb6)
as soon as the API discussions [1,2] are at an agreement. From there
on the actual implementations should only take less then a week.
in the comments of the Pull-Request 5099 it seems that Tobias Fredersdorf stops now his efford in implementing the MRF24J40 driver.
What is the status of the MRF24J40 driver development? Is there more code available as stored in GitHub?
If not - I have some additional important hints about that driver (depending especially the hardware access of this radio chip).
Who will be the follower of Frederic? Is it Peter Kietzmann?
the PR was closed because it was outdated but Tobias Fredersdorf promised to open a new one with more up to date code -> so there is more code but not available until now. I will meet him f2f in the next week and report the status, in case there is no PR to await soon.
At the RIOT summit several people stated their interest and we agreed on blocking that work about two more weeks for Tobias. In case there is no progress, someone else will take this over (probably me).
Which hints do you have about hardware access?
And who is Frederic? At least I'm not aware to be his follower.
sorry for the mistake - Frederic? I thought about Tobias Fredersdorf.
Here is my hint about the hardware access to the MRF24J40.
The SPI-Interface of the MRF24J40 is a little bit tricky.
If you take a look onto the diagram of the chip datasheet (chapter 2.14.2) you see that the bit which makes the decision between read and right access is not on a 8bit border but rather in the middle if you have a SPI-controller which is 8bit oriented.
Therefore you have to introduce a MRF24J40_ACCESS_WRITE_LONG bit to set the write bit correct.