My plans for 2016.10 release

Hi, 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.

Cheers, Martine

[1] https://github.com/RIOT-OS/RIOT/issues/5091 [2] https://github.com/RIOT-OS/RIOT/pull/5533

Curious - what is meant by “network layer overhaul”?

Cheers, Aaron

Hello developers, 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?

Best regards Neo

Hi Neo,

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.

Best regards Peter

Hello Peter, 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.

/**   * @brief SPI access specifiers   *@{   */ #define MRF24J40_SHORT_ADDR_TRANS (0x00) #define MRF24J40_LONG_ADDR_TRANS (0x80) #define MRF24J40_ACCESS_READ (0x00) #define MRF24J40_ACCESS_WRITE (0x01) #define MRF24J40_ACCESS_WRITE_LONG (0x10) #define MRF24J40_ADDR_OFFSET (0x01) /** @} */

void mrf24j40_reg_write_long(const mrf24j40_t *dev, const uint16_t addr, const uint8_t value) {      uint8_t reg1,reg2;      reg1 = MRF24J40_LONG_ADDR_TRANS | (addr>>3);      reg2 = (addr<<5) | MRF24J40_ACCESS_WRITE_LONG;      spi_acquire(dev->params.spi);      GPIOB->BRR = (1 << 12);      spi_transfer_byte(dev->params.spi, reg1, 0);      spi_transfer_byte(dev->params.spi, reg2, 0);      spi_transfer_byte(dev->params.spi, value, 0);      GPIOB->BSRR = (1 << 12);      spi_release(dev->params.spi); }

Without this bit you will never achieve a working write access.

Best regards, Neo

Hi Neo,

thanks for the hint. AFAIK reading/writing at long addresses already worked in Tobias' implementation, though I don't remember how he handled it. I will keep it in mind.

Best Peter

Hi,

* Network layer/NDP overhaul: expect a model proposal and [sic] of July.

I did this as promised about a week ago btw [1]. Might have been got lost in the mail storm during the release ;-).

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!") [snip]

Cheers, Martine

[1] RFC: network layer API · Issue #5704 · RIOT-OS/RIOT · GitHub