drivers/cc110x: Complete rewrite from scratch#10340
drivers/cc110x: Complete rewrite from scratch#10340PeterKietzmann merged 7 commits intoRIOT-OS:masterfrom
Conversation
|
@PeterKietzmann: Would you mind reviewing this PR and test on the MSB-A2? |
maribu
force-pushed
the
cc110x_rewrite
branch
2 times, most recently
from
7a856a3 to
0082028
Compare
|
I think it won't hurt if I already sqaush the last to fix commits into the first commit to make travis happy. |
maribu
force-pushed
the
cc110x_rewrite
branch
from
b930e93 to
f6c550e
Compare
|
@maribu The gnrc_networking size with the CC1101 is too large for the bluepill. I am going to remove some things and try it again. |
|
@Citrullin: Thanks for the feedback. Let me rebase this PR against the current master, than the flash hack documented in section "Additional Flash" in the boards docu will work with this PR as well. Please keep in mind that "make flash" will still check the against the official flash size reported by the MCU, so this will fail without modification of the OpenOCD config. Maybe it will be easier to use the st-flash with the hack and flash manually, or flash over UART using stm32flash which (if I remember correctly) also does not verify the flash size. |
maribu
force-pushed
the
cc110x_rewrite
branch
from
f6c550e to
1109067
Compare
|
@maribu I just used now the gnrc_minimal version. At least it doesn't crash with the initialization and IP address. :) I hope that I have the time today to check if I can send a package. I will also check the flash hack then :) |
|
BTW: If you have a second blue pill, you could convert that to a Black Magic Probe, which is super nice :-) You could that flash directly from GDB using "load" and that will also work for 128 KiB flash. Quick start with Black Magic Probe: You can connect to the UART via For debugging or flashing run A few hints:
|
|
BMP integration into RIOT would be also super-super nice :-) I hope I can have a look at that some time soon. |
PeterKietzmann
added
Type: enhancement
I don't think I'll find time for a proper review. But I could give it a try on the msba2 once you the code converges |
Ahh, thanks. Didn't know this. I bought 2 maple pies, because of the 64kb. Yes, I will try this hack then :) |
Sure. This PR got surprisingly big... @kaspar030: You already started to give valuable feedback. Do you mind to review this PR? |
For reliable operation this might be a good choice. The BluePill's "secret additional 64kB" flash is not guaranteed to work and there are cases known when it didn't. (But I personally never hat any issues and the success rate seems to be something like 99%.) |
|
I flashed it on two boards and tried your example. There is some traffic on the 433 ISM band. As you can see in the screenshot. But the seconds board isn't responding to the ping. I also tried it on the other one. I take a look into it. Maybe I did something wrong. @maribu Is that a wanted behavior that a ping is resulting only in one data transmission? Haven't checked it yet, but are all 3 pings sent at once? |
|
Here a screenshot about the ping6 result. Node 1: Node 2: |
|
@Citrullin: Thanks for testing
No, they should be send out right away. Maybe the spectrum analyzer cannot listen on all channels at the same time and walks the channels up an down. When the transmission is done on one channel while the analyzer is tuned in to another, it would miss the transmission. Maybe that is what happens? Channel 0 for the default configuration on the blue pill would be at 433.225 MHz (center frequency) and should be about 300 kHz wide. I hope this is not an instance of the "works on my machine"-syndrome where everything works just fine on the developers PC, but no where else :-D I had some trouble myself with the cheapest 433 MHz breakout boards that use a "spiral" as antenna. For some reason the signal is not detected when the sender is less than about half a meter away, but as soon the distance is higher than half a meter it gets 100% reliable. I believe this to be an antenna issue... Maybe you CC1101 breakout boards have the same antenna issue. Could you try if it works with some more distance? Could you check if your break out boards are intended for the 433 MHz band? Thank you very much! |
|
@maribu It really was the distance. Interesting. Never had this issue in the 868 band with Lora. Good to know. Maybe a little thing we can put in some FAQ or something. Here some screenshots. I recognized that there is some traffic on the 433 band on power on. So, the device is sending something after it woke up. Is the node advertising its IP address? Haven't looked into the network stack & driver so far. |
|
I really should add the documentation about that anomaly with the range. I hoped that was just me having bad luck with the antennas, as all other modules did not had those issues. (But the other ones were all 868 MHz - maybe it is not the antenna but the base band. Maybe this even is an obvious thing which is to be expected for 433 MHz transceivers and I'm simple unaware, as I have pretty much zero knowledge about the physical layer.) |
|
@maribu So, I ask somebody who is better in this topic. He told me that this is a result of the transmitting power. So, if the nodes are too near to each other, the nodes are receiving nearly the whole transmitting power of each other. Since the nodes are really sensitive in detecting the electromagnetic fields, it is just too much power for the receiver. So it reaches the maximum of its detecting capability. So the wave doesn't look like a sinus waveform anymore, more like rectangle. And this is simply an incorrect signal for the node. That's the whole story :) |
I think that RPL sends those packets. |
|
@maribu I see that there is a function to set the tx power. Which is really helpful, since the 433 band also has some restrictions. So, I wanted to know what you set in the driver as default value? I would think 1mW would be great, since there is no restriction on the 433 band in case of duty-cycle with 1mW. |
|
@Citrullin: I can confirm that too high TX power prevents the communication when the devices are too close: Reducing TX power on both nodes to 0dBm solves the problem :-) Regarding the default TX power value: This sounds like a good idea to allow setting it via |
|
@maribu Is it fine for you if I put everything in this PR? Or should it be another feature request instead? |
|
OK, I missed some boards on the first try at blacklisting. I also previously added some boards to I squashed right away. The diff on the "force-pushed" link should only show updates to |
@PeterKietzmann: Ping :-) |
|
@kaspar030, @kYc0o @miri64 I am about to merge this PR this afternoon / evening after I had a final look over the code and passed last tests. It has +4,100 −2,240 so of course not everything is perfectly reviewed but the code is in very good shape, it is well documented and even stressful tests passed -> it improves the current state by means! If you have any concerns, speak out now! |
+1 for merging! |
|
So once again I ran tests/drivers_cc110x with @Citrullin from the hearts you gave our comments I interpret that everything still runs ok on your side? @maribu I have only two things left before merging. The following is just a proposal. Please note that I slightly changed the commit order. pick 615e25f drivers: Removed driver for CC110x transceivers |
The cc110x driver has been re-written from scratch to overcome the limitations of the old driver. The main motivation of the rewrite was to achieve better maintainability by a detailed documentation, reduce the complexity and the overhead of the SPI communication with the device, and to allow to simultaneously use transceivers with different configuration regarding the used base band, the channel bandwidth, the modulation rate, and the channel map. Features of this driver include: - Support for the CC1100, CC1101, and the CC1100e sub-gigahertz transceivers. - Detailed documentation of every aspect of this driver. - An easy to use configuration API that allows setting the transceiver configuration (modulation rate, channel bandwidth, base frequency) and the channel map. - Fast channel hopping by pre-calibration of the channels during device configuration (so that no calibration is needed during hopping). - Simplified SPI communication: Only during start-up the MCU has to wait for the transceiver to be ready (for the power regulators and the crystal to stabilize). The old driver did this for every SPI transfer, which resulted in complex communication code. This driver will wait on start up for the transceiver to power up and then use RIOT's SPI API like every other driver. (Not only the data sheet states that this is fine, it also proved to be reliable in practise.) - Greatly reduced latency: The RTT on the old driver (@150 kbps data rate) was about 16ms, the new driver (@250 kbps data rate) has as RTT of ~3ms (depending on SPI clock and on CPU performance) (measured with ping6). - Increased reliability: The preamble size and the sync word size have been doubled compared to the old driver (preamble: 8 bytes instead of 4, sync word: 4 byte instead of 2). The new values are the once recommended by the data sheet for reliable communication. - Basic diagnostic during driver initialization to detect common issues as SPI communication issues and GDO pin configuration/wiring issues. - TX power configuration with netdev_driver_t::set() API-integration - Calls to netdev_driver_t::send() block until the transmission has completed to ease the use of the API (implemented without busy waiting, so that the MCU can enter lower power states or other threads can be executed).
With the increase of the message queue size from 8 to 16 in 946b06e, the default stack became too small. This changes the stack size to grow with the message queue size.
- Added required logic to provide correct L2 netstats when the module netstats_l2 is used. - Refactored code to use gnrc_netif_hdr_set_netif() over manually setting the pid to ease future refactoring.
The test application provides: - RIOT's basic network utilities such as `ping6` - A custom `cc110x` shell command that can be used print the low level device and driver state. This is mostly useful for debugging.
Done.
|
|
@maribu thanks! However, changing the way |
done |
|
It is ok for me in the actual state. I'll add my concerns on the tracking issue and so we can advance together on this. I'll try to make a PR asap. Thanks a lot @maribu for your huge efforts! |
|
Thanks. I ran a final test using tests/driver_cc110x on one, and examples/default on an other msba2 board. I changed the |
PeterKietzmann
added
Reviewed: 1-fundamentals
PeterKietzmann
left a comment
PeterKietzmann
left a comment
There was a problem hiding this comment.
ACK. Test reports have been posted earlier. Thanks to all contributors!
Just happy to see this in the mainline. It has been a while when I checked it the last time. But if there are any issues, we can fix them :) Kaizen style. |
|
Hooray! @PeterKietzmann, @miri64, @kYc0o, and @Citrullin: Thanks for reviewing, testing and helping with the driver :-) |
|
Grats! This was a big one... 🎉 |
9 participants
Contribution description
The cc110x driver has been re-written from scratch to overcome the limitations of the old driver. The main motivation of the rewrite was to achieve better maintainability by a detailed documentation, reduce the complexity and the overhead of the SPI communication with the device, and to allow to simultaneously use transceivers with different configuration regarding the used base band, the channel bandwidth, the modulation rate, and the channel map.
Features of this driver include:
4.9ms to 5.4msabout 3ms with header compression enabled (depending on SPI clock and on CPU performance) (measure with ping6).Testing procedure
On the MSB-IoT
E.g. by using
examples/gnrc_networking: Flash this on two MSB-IoTs and runping6 <ADDR>on one device with being replaced by the address of the other. I could ask one of my co-workers to perform this test, as there are no MSB-IoT boards left except the ones in my office. (I also tested myself, but maybe it is better to check if this is reproducible on someone else's machine.)On the MSB-A2
Same as MSB-IoT, but add
CFLAGS += -DCC110X_PARAM_L2ADDR=13to the Makefile and change the address (the 13) before flashing it on the second MSB-A2. (The MSB-A2's MCU has no unique ID (no CPUID, no unique MAC address in the embedded (but not broken out) Ethernet controller, no unique address in the CAN controller, no nothing) to use to derive a unique layer 2 address from. The on-board FTDI TTL-USB adapter has a unique ID, but that is not accessible from the TTL side. One could hack the flash tool to read that ID via USB and modify the uploaded image to include that ID on some location in the flash, but this seems to be much effort and unrelated to this PR...)
On the bluepill / blackpill
Connect a CC1101 breakout board with 433 MHz base band (I could not fine breakout boards for other base bands, so any random breakout board will likely be fine) to the pill like this:
Add to
board/bluepill/include/board.h(orboard/blackpill/include/board.h):Add
USEMODULE += cc1101to the Makefile and use the same steps as on the MSB-IoTEdit 1: Removed trailing line break to improve readability
Edit 2: Added space between "@" and "250 kbps" so that github user "250" is not linked
Edit 3: Adapted testing on Bluepill/blackpill, as no default configuration will be provided anymore
Issues/PRs references