Tock: Wanted: 15.4 Driver for the nRF52

[bradjc]

A major selling point of the Nordic nRF52 series of SoCs is that they support both BLE and 802.15.4. Currently, we only have a BLE driver. To help with testing the UDP/6lowpan stack, it would be helpful to have multiple chips providing the radio HIL.

This implementation would not need to be necessarily interoperable with the BLE stack. It is fine for now if the supported radio is chosen at compile time.

[alevy]

Looking through the NRF52 datasheet, this looks fairly straight forward _except_ for the fact that some of the details of the Radio HIL are undocumented (e.g. whether the payload is a MAC or PHY payload), so there will need to be either some redesign of the HIL or trial-and-error to see what was meant.

Also putting here that we should rename the Radio HIL to something more specific, e.g. Ieee802154Phy or something.

[phil-levis]

I think that the comments in the file are pretty clear on what the buffer passed to transmit is, although those comments are not actually on the transmit method itself. Regardless, this trait definitely needs a redesign: it isn't a generic 802.15.4 PHY HIL, in that its buffer layout makes assumptions on the underlying SPI bus protocol.

[dcellucci]

Hi all,

I'm taking a crack at this (at https://gitlab.com/cellu_cc/tock/tree/bt840-802154) using the imix setup as a reference - is there a version of the framer that doesn't require an AES implementation?

best,
DC

[alevy]

@dcellucci there isn't, but (a) there is an AES CCM controller on the NRF52 and (b) a reasonable hack for now might be to just implement a dummy AES driver (that just returns SUCCESS and either never callsback with the encrypted/decrypted payload, or calls back passing the plaintext as is). As long as the stack sets the security level to None, it won't be used in practice anyway.

I suspect implementing this _with_ AES CCM on the NRF52 might result in suggestions for changing the internal interfaces, since the NRF52 has more efficient ways of plugging the AES controller in on the fly with packet reception/transmission.

[dcellucci]

I figured writing a dummy AES was in my future :)
I agree on the idea of taking advantage of nordic's hardware features, but how would that factor into a framer that allows for both automatic and manual AES integration? This is more farther afield, but could we make AES an optional component of the framer?

DC

[alevy]

@dcellucci that's a good question. @hudson-ayers might have thoughts (though he may not have many cycles to think about it until after SenSys next week).

[hudson-ayers]

@dcellucci I don't think there is any particular reason we shouldn't make AES an optional component of the framer -- looking at the code, I don't think it would require more than a few dozen lines of code modifications. We would probably want to change the syscall interface for the 15.4 driver to include a check for availability of AES, but I don't think that's a big deal.

[dcellucci]

Hi all

Updates:

I have TX working- or at least it says it is. The latest commit is here: https://gitlab.com/cellu_cc/tock/tree/bt840-802154

Now working on RX, and I need to make an architecture decision. The Bluetooth Advertising Driver for the NRF52 has an explicit command call that has the radio wake up after a random interval and look for a signal in addition to a callback, while the current 802154 driver just registers the callback. I assume the latter occurs because it's assumed that the radio is always in RX mode. Is there a reason I shouldn't do this?

Best,
DC

[phil-levis]

The 15.4 driver doesn't assume the radio is on; it's trying to abstract away whatever the underlying energy saving mechanism is. The assumption is that low-power modes are configured through a separate interface. E.g., there are low-power approaches that sample the channel, that use scheduled time slots, and which use short packet chirps for receiver-initiated MAC layers. We have a low-power MAC layer for the RF233, based on the X-MAC protocol. I'd suggest keeping with the current 15.4 APIs/traits.

In a perfect world, BLE would have a similarly abstract interface. But chipsets are very geared towards timeslots and BLE timing, so integrating wakeup intervals into the datapath is OK.

[dcellucci]

I think I see what you're saying. Hence the PowerClient? Or is that what AwakeMac is supposed to handle but doesn't right now?

Side note: We might have to integrate wakeup intervals anyway, to deal with CCA collisions during transmit.

[phil-levis]

Usually you want to abstract out the media access control (MAC) at the link layer (i.e., the 802.15.4 abstraction). Bluetooth is a bit different because its layers are integrated a bit more tightly. The standard programmatic way to do this is to either have a control interface for the MAC layer (e.g., that allows you to control duty cycle, wake intervals, etc) or to pass per-packet metadata. The former is useful when you want to apply uniform settings across all packets, while the latter is useful when per-packet settings are needed by higher protocols.

Usually, stuff like wakeups and intervals aren't passed in these per-packet settings, because composition becomes really difficult. I.e., it works when your application knows and controls everything, but if you want to build clean layers and not re-invent the wheel every time, you want a general approach.

Here's a detailed discussion of a particular 802.15.4 stack we did in TinyOS:

http://www.btnode.ethz.ch/static_docs/tinyos-2.x/txt/tep126.txt

[dcellucci]

Thanks for the document- it's probably the clearest read I've found on how 802.15.4 works. Is there an equivalent document for TockOS's stack? If not I can help fix that.

RX works now, so at least at the hardware level things are working. It's not handling ACKs or channel collisions right now, but that's next. :)

[alevy]

The best thing we have right now for a design doc for 802.15.4 is https://github.com/tock/tock/blob/master/doc/Networking_Stack.md, but it focuses on the layers above 802.15.4, mostly.

I think extending this with lower layers would be great!

[alevy]

RX works now, so at least at the hardware level things are working. It's not handling ACKs or channel collisions right now, but that's next.

This is really awesome. (@nealjack FYI, seems like nRF52 802.15.4 isn't that far away)

[hudson-ayers]

I think this was completed with https://github.com/tock/tock/pull/1878