drivers/cc110x: Allow packet sizes up to 255 bytes#2237
drivers/cc110x: Allow packet sizes up to 255 bytes#2237fnack wants to merge 1 commit intoRIOT-OS:masterfrom
Conversation
|
Please note that for packets <= 64 bytes the driver implementation is still interoperable with devices using the cc110x_legacy driver. |
|
What is the use-case? How do you handle proper reassembly? Personally, I feel like this is not something the driver should do. A packet is a unit that the device gets over the air and this should be presented as such to higher layers. Everything else should be left to the higher layers (e.g. 6LoWPAN and/or IPv6) |
|
I don't really understand your comment. Maybe my description was confusing. What is the use-case: How do you handle proper reassembly: |
This is not a use-case IMHO, but a nice-to-have feature. If someone wants to send packets as large as this she should use an upper layer that can deal with this (6LoWPAN e.g.). In particular, 6LoWPAN also actually deals with out-of-order arrivals (which your implementation does not, if I see that correctly) and overlapping fragments, so I'm not convinced, that we need this. |
|
I don't understand your concerns with this pull request. Yes, my explanation might only describe a feature but I think we are talking at cross purposes. An application simply exchanging a full set of Sensor data between two nodes is an easy example. This data could easily grow larger than 58 bytes. Why should you force the developer to use upper layer mechanisms so that data fragmentation is handled if for such an easy application this would only introduce computational and data overhead (for multiple packets). It especially confuses me that your don't like the idea of extending a current device implementation to use the (full) capabilities of this device. If you don't want to use this feature, simply don't use it. The CC110X device does no processing of an incoming packet but simply hands it to its upper layer. Of course there is no handling of out of order arrivals. How should the CC110X know which order is the correct one? That is always in the scope of upper layers. |
|
I hope that @OlegHahm jumps to the rescue soon and gives his opinion because I don't think we'll come to a conclusion with our discussion ;) |
|
@authmillenon Maybe you missed that this PR is actually implementing something the device supports (i.e. not some hack)? |
|
After reading a little bit into the related datasheets I see that you're right @LudwigOrtmann. Is there a way of getting this to run on MSBA2? |
|
First possibility - Adapt the legacy driver: Second possibility - Use the new driver on MSBA2: Second possibility should be the goal for the future! |
|
The first possibility should not be considered in my opinion ;) |
|
Is this now dependent on #2398? |
|
Yes, the CC110x driver has to be adapted to the new ng_netdev interface. I'm waiting for Thomas' PR for the adapted at86 radio driver to get an impression on what needs to be done. But the basic rx and tx functionality from this PR won't change with the adaption. |
|
Rebased. @OlegHahm: I changed this PR so that it no longer touches any netdev stuff and only changes the rx and tx routines of the driver to allow packets of up to 255 bytes. As we are still missing a working implementation of the ng_netdev interface for any device, I think this is the better approach. Therefore, the PR is ready for review! |
59b8450 to
9f184dd
Compare
|
Sorry for the long delay. The problem that I have is that reviewing device specific code without having the device is a bit difficult. Does anyone can get his hands on at least two MSB-IoTs? |
|
@haukepetersen, maybe you? |
|
I will have a look, but I will not get to it this week... |
|
@kaspar030, @haukepetersen, can we close this? |
|
I guess so, the driver has been obsoleted, and I have a netdev2-version ready that also supports large packets. |
This PR extends the current cc110x driver implementation to allow packet sizes up to 255 bytes (maximum for Variable Packet Length Mode)
and adapts the netdev receive mechanism to handle packet reception not in the interrupt but in the event handling thread.(UPDATE: Old netdev is deprecated, therefore no longer handled in this PR).Both, the RX and the TX FIFO of the cc110x can only store 64 bytes. Therefore, for packet sizes > 64 bytes consecutively reading/pushing bytes is necessary.
For transmission of packets > 64 bytes the TX FIFO is filled with the first 64 bytes and afterwards the remaining bytes are consecutively pushed to the TX FIFO when space is available until all the bytes are transmitted (necessary because a TXFIFO underflow would result in a corrupted packet).
For reception of a packet, two interrupts are used. The first interrupt is triggered, when the RX FIFO is filled with more than 4 bytes (RX FIFO threshold, packets with less bytes are not valid). Subsequently, the available bytes in the RXFIFO are consecutively read until the whole packet is received. This is necessary to avoid a RX FIFO overflow. The second interrupt is triggered when the cc110x signals that the whole packet was received. This results in reading the remaining two status bytes in the RXFIFO. Afterwards the packet either gets dropped (CRC wrong) or gets processed further.
The PR is depending on #2163 (introduction of event handler pid member variable in netdev_t).(UPDATE: Old netdev is deprecated, this PR no longer relies on netdev changes).