[riot-notifications] [RIOT-OS/RIOT] drivers/cc110x: Complete rewrite from scratch (#10340)
notifications at github.com
Wed Jul 24 21:13:28 CEST 2019
> This is not actually the case: The driver is not over the air compatible with 802.15.4. (I believe it is impossible to get the CC1101 compatible, but I'm not 100% sure. (E.g. not only needs the same modulation format be supported with the same mapping (e.g. in binary phase shift keying, which phase is 0, which is 1?), but also the preamble format and length, the sync word and length etc. have to be identical.) But even if it would be theoretically possible, it with prevent hardware address filtering (tied to one byte L2 addresses on the CC110x) and other features. I don't think that trying to send/receive 802.15.4 is fruitful with the CC110x, even if it could be done.).
My bad, my statement was on the direction of the packet format, on which you specify the expected shape of the frames. As I stated before, it was not "so difficult" to use this driver for my purpose, however then I don't see the point of copying/pasting the whole files to just modify what is needed.
> This is more of a layer which provides backwards compatibility. IPv6 based networking for older hardware. Similar to what IPv6 over BLE does. A standard for this would be really nice though.
I'm afraid I disagree on this point. The CC1101 was deployed, and is being deployed, for too many more use cases. The point I want to make is that the added value of this driver into RIOT, as it is right now, is narrowed to your IPv6 case, which unfortunately is not the main usage for the chip so far. Of course, that's already the case, but I was hoping to make usage of this driver as a generic cc110x driver which can be used for a wide range of applications.
I'll make a "review" of the changes I see could make this driver generic, but I won't make any blocking comment. However, I'm afraid I can't review the IPv6 part since I don't have the time for it.
A more generic comment: This implementation removed the sleeping (power off) algorithm, which IMHO is a bad idea. I tried to add it but I'm not succeeding, so I'd be super thankful if you can bring it back and check if it works. As a hint, I think is related to the fact that this driver never de-selects the chip, which is required to go to sleep (Table 42, SPWD command).
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications