Skip to content
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.

Sign up for GitHub

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

Jump to bottom

The weekly driver initiative #39

Closed
japaric opened this issue Jan 18, 2018 · 236 comments
Closed

The weekly driver initiative #39

japaric opened this issue Jan 18, 2018 · 236 comments
Labels
community

Comments

@japaric
Copy link
Member

japaric commented Jan 18, 2018 •
edited
Loading

There's now a HAL published on crates.io: embedded-hal (Introduction blog post). 🎉

To put it to test and to expand the crates.io ecosystem I'm starting the weekly driver initiative.

The goal is to release a new no_std, generic, embedded-hal based driver crate every one or two
weeks. Driver crate here means a library crate that lets you interface an external component like a
digital sensor or a wireless transceiver. A driver release consists of (a) publishing a library
crate on crates.io (*) and (b) presenting your driver to the community via any means: a blog post,
a tweet, a reddit post, a u.r-l.o https://users.rust-lang.org post, etc.

(*) Make sure you tag your crate with the embedded-hal-driver keyword!

If you'd like to participate leave a comment here stating the driver you'll be working on. If you
can post a link to the repo where the (WIP) driver code is or will be, even better! If you don't
have a personal blog to present your driver to the community you can do a guest post on my blog.

For a list of released and WIP drivers check the awesome-embedded-rust list. If you'd like your crate to be added to that list simply send a PR to that repo!

TODO (potentially):

These are components that @japaric has at hand:

  • DHT22 - temperature + humidity sensor (1-wire)
  • ENC28J60 - ethernet controller (SPI)
  • HC-06 - bluetooth (AT)
  • HC-12 - wireless transceiver (AT)
  • HC-SR04 - ultrasonic sensor
  • L298N - Motor driver
  • NEO-6M - GPS (USART)
  • NEO-M8N - GPS (USART)
  • PCA9685 - 16 channel Servo driver (I2C)
  • PCF8574 (+ 16x2 LCD) - 8-bit I/O expander (I2C)
  • PN532 - NFC (SPI)
  • RA-02 - Long-range Radio (SPI)
  • SN65HVD230 - CAN
  • SSD1306 - 128x64 OLED (I2C)
  • Servomotor (?)
  • WS2812B - smart LED
  • nRF24L01 - wireless transceiver (SPI)
@niklasad1
Copy link

I can probably help porting some NRF51/NRF52 drivers from TockOS that I have been involved in. I think the BLE driver could be interesting to have in a separate crate.

Let me know if you think it is a good idea!

@thejpster
Copy link
Contributor

thejpster commented Jan 18, 2018 via email

@dbrgn
Copy link

dbrgn commented Jan 18, 2018 •
edited
Loading

If I find time I could try to do a DS18B20 (dallas one-wire) temperature sensor driver implementation.

Current stumbling blocks so far (I'm developing on the LPC11UXX):

(In both cases, what @rnestler wrote)

@astro astro mentioned this issue Jan 18, 2018
Closed
@therealprof
Copy link
Contributor

I've tons of devices at hand and I might write drivers for them but first I need to get the device crates and HALs up to snuff.

Apart from the usual Serial/I2C/SPI suspects what I'd like to see is whether the HAL approach is also viable for bit-banged GPIO, potentially even timing critical devices, some of which are also in @japaric's list, like the Neopixels. Something that would be really killer to have is support for multiplexed and charlieplexed LED matrices.

@alevy
Copy link

alevy commented Jan 18, 2018

If TockOS starts using this HAL internally then new chip support should be easier to add in the future. I found the LM4F120 port fairly hard going.

I'd personally be highly supportive of that, but would need some convincing that it would fit the capsule architecture (that hasn't seemed to be the case for previous iterations). Perhaps @niklasad1 can report some insights if he ports his BLE stack from Tock.

@therealprof
Copy link
Contributor

@japaric Is there going to be a registry for embedded stuff and especially drivers? crates.io is becoming more and more useless to find interesting crates...

@thejpster
Copy link
Contributor

The LM4F120 crate now implements embedded_hal::serial::{Read, Write}. It was pretty straightforward.

@japaric
Copy link
Member Author

japaric commented Jan 18, 2018

@niklasad1

Let me know if you think it is a good idea!

More drivers is a good idea, IMO. :-)

porting some NRF51/NRF52 drivers

Just to clarify: Is this driver about interfacing an external pre-flashed nRF5x device, or is it some BleRadio trait on top of which a generic BLE stack con be built? In the later case you implement the BleRadio trait for, say, a nrf51 device crate and you get a BLE stack for free (ideally).

@therealprof

I'd like to see is whether the HAL approach is also viable for bit-banged GPIO

At the very least we'll want to add a digital::OutputPort trait whose API changes the state of a whole port (8 or 16 pins) atomically (single register op). And maybe another trait to change the state of N pins that belong to the same port atomically.

potentially even timing critical devices, ..., like the Neopixels

The words Neopixels and bit banging reminded me of an Arduino library I saw. It implemented the protocol using assembly and was fully blocking (nop delays) to meet the timing constraints. I hope that our neopixels driver provides a DMA based (asynchronous) mode, apart from a bit banged mode.

Is there going to be a registry for embedded stuff and especially drivers?

I meant to include this in the issue description: I'm using the embedded-hal keyword for my driver crates. That makes them easier to find. Perhaps we can just use crates.io and keywords instead of creating another registry / list. We can bikeshed the keywords to use in this thread: perhaps embedded-hal (or embedded-hal-driver) for the driver crates, embedded-hal-impl for the HAL impl crates, like the stm32f30x-hal crate, and svd2rust for the svd2rust generated device crates?

@therealprof
Copy link
Contributor

@japaric

Just to clarify: Is this driver about interfacing an external pre-flashed nRF5x device, or is it some BleRadio trait on top of which a generic BLE stack con be built? In the later case you implement the BleRadio trait for, say, a nrf51 device crate and you get a BLE stack for free (ideally).

Coincidentally I'm working on a micro:bit crate (which is based on the NRF51822, as I'm pretty sure you're aware of 😉). I planned on adapting the BLE code from the Zephyr project, since Nordic is quite active there providing a BLE implementation for their devices without the humongous softdevice blob.

It's not quite ready for primetime yet since the documentation is somewhat lacking and reversing Zephyr somewhat time consuming due to the many layers of abstraction and indirection.

But your recent work and post kind of beat me to adapting what I have to the new singleton approach and also use the embedded-hal (which I previously haven't), so I'm trying to put some more time in.

At the very least we'll want to add a digital::OutputPort trait whose API changes the state of a whole port (8 or 16 pins) atomically (single register op). And maybe another trait to change the state of N pins that belong to the same port atomically.

Yeah, that's going to be interesting. But the reason I mentioned this is that there somehow (and I'm not sure what this will might look like just yet) should be a way to facility the required high speed updates.

The words Neopixels and bit banging reminded me of an Arduino library I saw. It implemented the protocol using assembly and was fully blocking (nop delays) to meet the timing constraints. I hope that our neopixels driver provides a DMA based (asynchronous) mode, apart from a bit banged mode.

Some of those WS controllers can be driven by abused SPI peripherals provided by some MCUs but that can't be taken for granted. AFAIR that doesn't work on the RasPi and that one also cannot do the required timing via bitbanging the GPIOs.

I meant to include this in the issue description: I'm using the embedded-hal keyword for my driver crates. That makes them easier to find. Perhaps we can just use crates.io and keywords instead of creating another registry / list. We can bikeshed the keywords to use in this thread: perhaps embedded-hal (or embedded-hal-driver) for the driver crates, embedded-hal-impl for the HAL impl crates, like the stm32f30x-hal crate, and svd2rust for the svd2rust generated device crates?

That might work but has quite a number of disadvantages:

  • It relies on people knowing how to correctly tag the crates and actually do it
  • crates.io doesn't tracking of crates so one doesn't get notified about new crates of interest or updates
  • The quality of the entries varies a lot and investigating potentially relevant crates consumes a lot of time with a strong tendency to becoming even worse
  • The amount of search results is often overwhelming and there's virtually no support narrow down the search. Just for fun I just tried this query and I didn't find the result very encouraging...

crates.io is okay for larger std crates but for the hundreds or even thousands of embedded crates we're going to have, this is going nowhere fast... Originally I was counting on japaric.io or rust-embedded becoming the authoritative source for everything embedded in Rust but somehow this didn't quite happen. ;)

My hopes are still that we can establish a lively community around those topics, with a comprehensive catalog of relevant crates (architectural, register mapping, MCU HAL, peripheral HAL, BSP and specific implementations), articles on the use of any of that and general development topics, guides for embedded Rust development and support (development tools and debugging software/hardware to use) and potentially even general MCU howtos (selecting and connecting peripherals to an MCU, developing your own hardware...)...

@jacobrosenthal
Copy link

jacobrosenthal commented Jan 19, 2018 via email

@therealprof
Copy link
Contributor

@jacobrosenthal

Another open source nrf ble stack to check out is mynewt's nimble, which is
the rtos im currently using in my daily work.
https://github.com/apache/mynewt-core/tree/master/net/nimble

I am aware, I tried everything I could find for that MCU, including (but not limited to) Mynewt, RIOT and Zephyr. Most ecosystems rely on the softdevice while some others provide their own (but often very limited) BLE stack. The Zephyr stack is written by the vendor Nordic themself and has been certified so it is known to be feature complete and (somewhat) correct.

Im hoping to try out rust for the first time, and ble on the microbit would
be a great reason for me to finally dig in as 'full' functionality
(bootloading over ble mainly) on nrf51822 devices is tough to come by with
every other rtos out there due to the low memory. Curious how rust could
stand up.

Rust allows for ridiculously small firmwares on those MCUs (compared to other ecosystems that is) so I'm confident that there won't be any space issues per se. Of course if you add a BLE capable bootloader for DFU that whole situation changes a good deal because that will take a sizeable amount of flash by itself. I wouldn't hold my breath for that to materialize. ;)

https://github.com/runtimeco/mcuboot/

Bootloaders don't have a very high priority for me at the moment but adding support for mcuboot might be straight forward. Question is what the benefits would be, especially on the micro:bit but I'll have a look, thanks.

@whitequark
Copy link

Rust allows for ridiculously small firmwares on those MCUs (compared to other ecosystems that is) so I'm confident that there won't be any space issues per se.

Is that really true? The generated format! code is very bloated, for example, with its myriad of vtables, tables, floating point...

@therealprof
Copy link
Contributor

@whitequark

Is that really true? The generated format! code is very bloated, for example, with its myriad of vtables, tables, floating point...

That's true, format! is relatively expensive due to the incapability to properly see the used types and monomorphize; however (unless there's another bug I'm not aware of, not using format! too much in my code) it should be a one-time overhead which is comparable to printf() formatting in C and no-one forces you to use formatters; outputting strings using write_str() as well as "manually" formatting numbers e.g. using the NumToA crate.

Here I have an example rendering a counter triggered by USART input onto an I2C driven SSD1306 OLED display:

File .text Size Name
0.2% 28.4% 604B USART1
0.2% 26.5% 564B main
0.1% 17.9% 380B [41 Others]
0.1% 11.3% 240B compiler_builtins::int::udiv::__udivsi3
0.0% 5.5% 116B i2c_ssd1306::ssd1306_print_bytes
0.0% 3.9% 84B stm32f042::peripherals::i2c::write_data
0.0% 3.0% 64B cortex_m_rt::reset_handler
0.0% 1.4% 30B __udivmodsi4
0.0% 0.8% 18B __aeabi_memcpy
0.0% 0.8% 18B __aeabi_uidivmod
0.0% 0.5% 10B __aeabi_uidiv
0.7% 100.0% 2.1KiB .text section size, the file size is 310.9KiB

This (a bit older example) includes write_str use and an implementation on the serial port and an somewhat similar implementation for the display rendering...

@fmckeogh
Copy link

I have both an HC05 and HC06 pair and a tricolour e-ink display. I should be able to start work on these pretty soon.

@Kixunil
Copy link

Kixunil commented Jan 19, 2018

I already have (incomplete) PN532 Rust implementation based on i2cdev crate. I'd love to adapt it to HAL, but I don't expect to have time soon. In case anyone else wants to do it, I'm willing to help.

@Kixunil
Copy link

Kixunil commented Jan 19, 2018 •
edited
Loading

@whitequark, @therealprof check out fast_fmt crate. It was specifically designed to avoid this overhead.

@whitequark
Copy link

@Kixunil any documentation would be helpful.

@mneumann
Copy link

would be great to have USB support, i.e. some library interfacing for instance FTDI chips. seems like tock os got some generic USB code.

@therealprof
Copy link
Contributor

@mneumann Not sure I follow. Why would you use an USB<->Serial interface? Some MCUs have USB peripherals built-in but providing an HAL for creating an USB endpoint is a somewhat complex and very specific.

@mneumann
Copy link

@therealprof : if the MCU has a built-in USB peripheral then I'd of course use that, given that it's easy to use from Rust ;-). But those devices I have at hand, need an external USB chip. Regardless of whether it's on or off-chip, I'd love to be able to use USB from Rust. This is just the last (big) missing piece to make use of Rust on embedded for me.

@lnicola
Copy link

lnicola commented Jan 20, 2018

@mneumann There's a couple of posts about implementing USB Serial in Rust here, but the series is unfinished.

@japaric
Copy link
Member Author

japaric commented Jan 20, 2018

I have created a separate issue for tracking progress on a generic USB stack: #40. Please continue USB discussions over there; let's keep this thread focused on drivers built on top of embedded-hal. (I'm of the opinion that USB is complex and specialized enough that it should go into its own crate separate from embedded-hal.)

@Kixunil
Copy link

Kixunil commented Jan 21, 2018

@whitequark what exactly are you missing?

@hannobraun
Copy link
Member

DHT22 - temperature + humidity sensor (1-wire)

I already had the DHT22 working with Rust at some point, although not in the form of a reusable driver library. If anyone is interested, I can dig up the code. Caveats: It's messy code, integrated into an application, built on top of other messy unpublished code. I'm not sure how useful it's going to be, but as a starting point, it may be better than nothing.

@japaric

I meant to include this in the issue description: I'm using the embedded-hal keyword for my driver crates. That makes them easier to find. Perhaps we can just use crates.io and keywords instead of creating another registry / list. We can bikeshed the keywords to use in this thread: perhaps embedded-hal (or embedded-hal-driver) for the driver crates, embedded-hal-impl for the HAL impl crates, like the stm32f30x-hal crate, and svd2rust for the svd2rust generated device crates?

I'm in full agreement. Not sure what the best keywords would be, but we should have them. I'm already using the svd2rust keyword for lpc82x.

@therealprof

That might work but has quite a number of disadvantages:
[...]

I think your points are valid, and I would love to see a community resource like the one you describe. However, someone has to build this, and it's going to be a lot of work. crates.io is already here, and we can start using the suggested tags to ease the problems that it has right now.

@JJJollyjim
Copy link

I'm gonna have a go at building something for a HD44780-style (S6A0069 in my case) 16x2 LCD. @japaric I see you mention an LCD in the context of an IO expander: would a potential IO expander API expose digital::OutputPins such that the LCD module could operate generically over either the uC's pins or the expander's?

@therealprof
Copy link
Contributor

@hannobraun

I think your points are valid, and I would love to see a community resource like the one you describe. However, someone has to build this, and it's going to be a lot of work. crates.io is already here, and we can start using the suggested tags to ease the problems that it has right now.

I totally agree. One doesn't preclude the other. I fully expect that crates.io will remain the official source for all crates, including embedded ones. I was hoping we could at least get something like https://github.com/brson/stdx up.

@kunerd
Copy link

kunerd commented Jan 22, 2018

@JJJollyjim: clerk might be of interest for you. Here are some tickets from embedded-hal
rust-embedded/embedded-hal#29
rust-embedded/embedded-hal#30

@japaric
Copy link
Member Author

japaric commented Jan 22, 2018

@JJJollyjim

I see you mention an LCD in the context of an IO expander

It's just that the LCD I have has an I2C port expander attached to it and the only interface that the module exposes in I2C. But ideally the port expander driver, say PCF8574<I2C> itself would implement the digital::* traits and then you be able to plug that in the LCD driver, say LCD<PCF8574<I2C1>>, but an LCD abstraction right on top of I2C would still be a good start.

@dbrgn
Copy link

dbrgn commented Jan 22, 2018

For HD44780 compatible LCDs, there are mainly two I²C port expanders used: The PCF8574 and the MCP23008.

In case it helps, here's my Python driver for those LCDs: https://github.com/dbrgn/RPLCD/blob/master/RPLCD/i2c.py

@eldruin
Copy link
Member

eldruin commented Oct 27, 2019

It would be interesting to know what the shortcomings of using shared-bus in @Windfisch's case would be.

@Windfisch
Copy link

Most importantly (apart from the added complexity for which I did not understand the reason; but the trait issue you mentioned is though indeed):
I don't want a Mutex because I don't need a Mutex. I am concerned about WCET because I am doing orecise time measurements, and locking the interruots as part of a cortex-m-mutex for each spi access is not an option in my case.

However, do you think this was solvable and even zero-cost (due to inlining) if I just provided a dummy mutex that does a no-op on lockvand unlock? (Surely I must ensure that no such driver peripheral may be handed out to a different ISR, all must stay in the same thread/execution context)

@Rahix
Copy link

Rahix commented Oct 27, 2019 •
edited
Loading

However, do you think this was solvable and even zero-cost (due to inlining) if I just provided a dummy mutex that does a no-op on lockvand unlock? (Surely I must ensure that no such driver peripheral may be handed out to a different ISR, all must stay in the same thread/execution context)

I think this should be possible if your (fake) mutex type is !Send + !Sync + !SingleCoreSync, because there is no way to produce concurrent access with that.

@leshow
Copy link

leshow commented Nov 3, 2019

I published a rotary encoder lib that works with embedded-hal, not sure if it qualifies for the driver initiative, but I've been using it in my own little projects. Feedback/PRs/etc welcome, here

@therealprof
Copy link
Contributor

@leshow Absolutely, feel free to add it to all the various resources.

@burrbull
Copy link
Member

burrbull commented Nov 4, 2019

Can you add link on github repository in Cargo.toml?

@burrbull
Copy link
Member

burrbull commented Nov 4, 2019

More examples also are needed. How to use this with interrupts? How to calculate frequency?

@leshow
Copy link

leshow commented Nov 4, 2019

@burrbull

With interrupts you just do the update calculation inside your interrupt handler. At least, that's what I've been doing. Feel free to suggest any changes in the repo. And yes thank you, I will add the github link in cargo

@burrbull
Copy link
Member

burrbull commented Nov 4, 2019 •
edited
Loading

I think I understood. You forgot delay in loop.

@dotcypress
Copy link

@leshow also will be great to implement Quadrature encoder interface trait(Qei)

@leshow
Copy link

leshow commented Nov 4, 2019 via email

@eldruin
Copy link
Member

eldruin commented Nov 9, 2019

I just released the OPT300x ambient light sensor driver. See the blog post here :)

@eldruin
Copy link
Member

eldruin commented Dec 4, 2019

In case you want to listen to some good ol' FM radio with Rust, I just released the Si4703 FM radio receiver driver. See the intro blog post here.

@MathiasKoch
Copy link

MathiasKoch commented Dec 6, 2019 •
edited
Loading

I am on the lookout for an example of a properly implemented AT command based driver, and also looking for guidance on the correct way to address implementing such driver.

Optimally I think we would have some sort of generic AT crate, with some interface traits for commands and response, that would consume an embedded_hal::serial, and then expose functions for sending blindly, sending and waiting for proper response (with timeout) etc.

This should make it easy to implement AT based drivers, by just referencing some struct or enum of commands and expected responses? How does this sound? Would an intermediate crate like that make sense, or would it end up being too driver specific anyways?

Wrt. the example I am looking for something a bit more advanced than the HC-06 example out there.. maybe someone has a WiFi driver or a modem or the likes? Something with both req/resp based model and event driven commands (client connected, connection lost, etc?)

EDIT:
The main motivation behind an actual AT crate, would be to b able to with with commands and responses as actual rust types, and thus hiding away all the underlying string manipulation. E.g.

pub enum Command {
    AT,
    GetManufacturerId,
    GetModelId,
    GetFWVersion,
    GetSerialNum,
    SetEcho { enable: bool },
    GetEcho,
    SetStartMode { start_mode: Mode },
    GetStartMode,
}

pub enum Response {
    ManufacturerId {
        id: String,
    },
    ModelId {
        id: String,
    },
    FWVersion {
        version: String,
    },
    SerialNum {
        serial: String,
    },
    Echo {
        enable: bool,
    },
    StartMode {
        start_mode: Mode,
    }
}

With an example trait implementation as:

impl ATCommandInterface<Response> for Command {
    fn get_cmd(&self) -> String {
        let mut buffer = String::with_capacity(45);
        match self {
            Command::AT => String::from("AT"),
            Command::GetManufacturerId => String::from("AT+CGMI"),
            Command::GetModelId => String::from("AT+CGMM"),
            Command::GetFWVersion => String::from("AT+CGMR"),
            Command::GetSerialNum => String::from("AT+CGSN"),
            Command::SetEcho { ref enable } => {
                write!(buffer, "ATE{}", *enable as u8).unwrap();
                buffer
            }
            Command::GetEcho => String::from("ATE?"),
            Command::SetStartMode { ref start_mode } => {
                write!(buffer, "AT+UMSM={}", *start_mode as u16).unwrap();
                buffer
            }
            Command::GetStartMode => String::from("AT+UMSM?"),
    }

    fn parse_resp(&self, responses: &mut Vec<String>) -> Response {

    }
}

I have the send working properly, with a heapless spsc queue, uart IRQs and a spin function. But parsing the response(s) into a Response enum, and implementing functions for blocking send while waiting for a response is still lacking.

The end goal would be to make an AT interface, where one would implement

pub trait ATCommandInterface<R> {
    fn get_cmd(&self) -> String;
    fn parse_resp(&self, response: &mut Vec<String>) -> R;
}

for a Commands enum, with a corresponding Response enum.

The general idea would then be to have an AT crate along the lines of

pub struct ATParser<Serial, C, R>
where
    Serial: serial::Write<u8> + serial::Read<u8> + core::fmt::Write,
    C: ATCommandInterface<R>,
    R: core::fmt::Debug,
{
    serial: Serial,
    prev_cmd: Option<C>,
    rx_buf: Buffer,
    cmd_c: Consumer<'static, C, U4, u8>,
    resp_p: Producer<'static, Result<R, ATError>, U4, u8>,
}

that would impl send, spin, handle_irq etc.

I have also considered using serde for the commands, would that be a better approach?

Any feedback is greatly appreciated!

@TheZoq2
Copy link

TheZoq2 commented Dec 7, 2019

I am on the lookout for an example of a properly implemented AT command based driver, and also looking for guidance on the correct way to address implementing such driver.

This might not qualify for properly implemented, but I have a crate for using At commands with esp-01 wifi modules here: https://github.com/TheZoq2/esp01-rs

@eldruin
Copy link
Member

eldruin commented Dec 10, 2019

I just finished the PCA9685 16-channel PWM LED/Servo controller driver, in time for your Christmas decorations. See the blog post here.

@MathiasKoch
Copy link

In reference to #39 (comment) i have now published my attempt at a generalised Component abstraction crate for AT command based serial device drivers. You can find it here: https://github.com/MathiasKoch/at-rs and it comes with examples for usage with cortex-m-rt and with RTFM, as well as unit tests.

I will publish my driver crates built ontop of this AT crate as well, as soon as they are somewhat working. The crate is also available at https://crates.io/crates/at-rs

Any comments and/or contributions are more than welcome!

@dbrgn
Copy link

dbrgn commented Dec 19, 2019

@MathiasKoch you missed the chance to name your crate AT-AT 😉

@eldruin
Copy link
Member

eldruin commented Dec 20, 2019

I just released a driver for Vishay's VEML6030 ambient light sensor. On the announcement post you can see some pictures of the device on the PCB of a commercial product where the application is written in Rust 😃

@almindor
Copy link
Contributor

I've released a driver for the MAX7219 chip for segmented and LED matrix displays.

The driver has been originally developed by Maikel Wever and later picked up by me.

It's been on crates.io for some time but I never really announced it.

Here's the new announcement blog post

@almindor
Copy link
Contributor

Released a driver for the ST7789 display.

Driver originally developed by Paul Sajna and Anna Scholtz.

The github repo contains an example video of the driver in action. There's also a repo with examples using the PineTime watch.

@lonesometraveler
Copy link

A new embedded Rustacean here. Thank you all for your work in developing a great ecosystem.

I have released a driver for MAX6955 LED display driver. Here is a blog post.

I am now working on LSM9DS1 driver.

@eldruin
Copy link
Member

eldruin commented Aug 9, 2020

I have released 2 libraries that might be of interest here:

  • embedded-crc-macros defines macros implementing portable CRC (only CRC-8 ATM) algorithms and a macro to generate lookup tables on build time (i.e. build.rs) (no dependencies).
  • smbus-pec: Minimal portable System Management Bus Packet Error Code (CRC-8-ATM HEC) calculation algorithm (uses embedded-crc-macros).

(I use that already in my MLX9061x Infrared thermometer driver)

@therealprof
Copy link
Contributor

I think it's time to close this issue and look into resurrecting the newsletter. Nominating for discussion in the next meeting.

@therealprof
Copy link
Contributor

Thanks everyone for contributing to this thread.

I'm closing this issue due to becoming unwieldy long and going somewhat unnoticed.

But fret not, our well respected https://github.com/rust-embedded/awesome-embedded-rust list and the revitalized https://github.com/rust-embedded/blog will continue and happily report about all of your great driver work!

@jannic jannic mentioned this issue Feb 18, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
community
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests