-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement nRF24L01 driver #1
base: main
Are you sure you want to change the base?
Conversation
2bndy5
commented
Jul 9, 2024
•
edited
Loading
edited
- add source code to drive the nRF24L01
- add a build/test/lint CI workflows; no release CI for crates.io (yet)
- add unit tests using embedded-hal-mock (and activate codecov)
- add (Linux only) FFI bindings (consider FFI bindings #2)
- python binding
- node binding
- add examples
includes - CI workflow - funding info - dependabot config
- prefer to `use rf24_rs::radio::prelude::*` in user code to pull in all the required radio traits. - support LNA_CUR bit in non-plus/clones - prefer to `use rf24_rs::radio::{RF24 Nrf24Error}` in user code because namespaces will be very important in the future
Welcome to Codecov 🎉Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests. Thanks for integrating Codecov - We've got you covered ☂️ |
- add badges - tick first milestone in roadmap
rust is so cool! This new macro generates rust code at compile time and then compiles everything with the generated code in place of the macro calls.
removes the need to construct a mutable byte
This is just an informative collection of my thoughts, and reasons why I paused this development. ExamplesHere's the chips I'm looking to support (initially) in the examples:
Writing the examples is tough. The embedded-hal implementations for various chips are not conformed like the Arduino Cores for various chips families. Writing an example for the RP2040 will look significantly different from an example for the ATSAMD21. Due to this complexity, I've decided to try and put the examples in its own "crate" (a rust term for a library) in a sub-directory named "examples". This way I can allow users to control which chip to compile for using cargo features defined in examples/cargo.toml. Furthermore, flashing the compiled binary to a board requires a separate dependency called probe.rs. This is another reason why the examples need to use a separate crate. Embassy ProjectThere is an embassy project that focuses on some SoC (System on Chip) that employ an RTOS. This seems useful for multi-processing, but it is ultimately unnecessary for simple examples. Nonetheless, I could use this embassy project for ESP32, RP2040, and nRF5x chips because they seem to have a somewhat unified API for those chips (I think). No STD libs in embedded-halSee the embedded-hal book about rationale. Basically, driver libraries for embedded-hal projects cannot use rust's standard libraries. This includes This will be a problem down the road when I get around to implementing the Mesh layer because we need a way to dynamically allocate memory as Logical Addresses are assigned to a mesh node's ID. There are third party libs that aim to accommodate this shortcoming, but I'll cross that bridge when I get there. Tip The embeded-hal implementations on Linux and ESP32 boards can use the std libs. 🎉 The embedded-hal framework (which doesn't impose embedded-hal implementations use uniformed API names for data structures) had been in beta for years. It only reached a stable release in Jan 2024. This fact has caused a side effect that can be seen in many embedded-hal implementations; they still support embedded-hal framework v0.2.x (the last beta release) as an optional cargo feature. This driver library will only support v1+ of the embedded-hal framework (unless requested otherwise). |
aec4db1
to
6031361
Compare
introduce supplemental docs (using mkdocs) and WIP examples (incomplete at this time) migrate to using [just](https://just.systems) as a task runner and utilize it in CI jobs.
f974aaf
to
aef9f61
Compare
I have added python and node.js bindings 🎉 . I have also tested them on my RPi4, but there are no complete examples (yet). Python bindingThe python binding will be published to PyPI as Using REPL after build-from-source
Activate a python venv and (from repo root)
Then play around with it > from rf24_py import RF24
> r = RF24(22, 0)
> # for RPi5
> r = RF24(22, 0, dev_gpio_chip = 4)
> # reduce SPI speed
> r = RF24(22, 0, spi_speed=4000000) The API is almost the same as pyRF24 with a few exceptions. There's no undocumented camelCased API because it is unconventional in python (and increases binary size significantly). See below for more differences. Node.js bindingThe node binding will be published under the name
The using REPL after build-from-source
Then play around > const native = require('./bindings/node/index.js')
> r = new native.RF24(22, 0)
> // if using RPi5
> r = new native.RF24(22, 0, {devGpioChip: 4})
> // to lower the SPI speed
> r = new native.RF24(22, 0, {spiSpeed: 4000000})
> r.begin()
> r.openRxPipe(1, Buffer.from("1Node"))
> r.openTxPipe(Buffer.from("2Node"))
> r.stopListening()
> r.send(Buffer.from("a msg"))
true
> r.startListening()
> r.available()
true
> r.availablePipe()
{ available: true, pipe: 1 }
> rxBuf = r.read(32)
<Buffer 61 6e 6f 74 68 65 72 20 6d 73 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>
> rxBuf.toString()
'another msg\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
> r.getStatusFlags()
{ rxDr: true, txDs: false, txDf: false }
> r.update()
> r.getStatusFlags()
{ rxDr: false, txDs: false, txDf: false } Please beware of API differencesSince I'm writing this lib from scratch, I figured it was a good opportunity to revise the API observed in C++. Actually, it is like a mix of the CircuitPython API and C++ behavior; the best of both experiences IMO. API differences include
There also isn't any |
I ported the examples from the pyRF24 project and did some comparisons... rf24-py (this lib's python binding) runs nearly as fast as pyRF24 (C++ bindings) 🎉 There seems to be a little more runtime overhead in rf24-py than in pyRF24, but there's a lot more error checking (and probably more type checking) in rf24-py during runtime. Still, rf24-py is easier to build/maintain than pyRF24 and is considerably faster than a pure-python implementation (like the CircuitPython-nRF24L01 lib). Now to add rust examples and node.js (preferably typescript) examples, (& more docs about bindings). |
- implements print_details() - adds 1 example in typescript - more WIP on rust example - rename enums.rs to types.rs - move all bindings to bindings folder - rename lib folder to library (for gitignore reasons) - add a new CI related to examples only
send() doesn't work in a loop?