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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

The weekly driver initiative #39

Open
japaric opened this Issue Jan 18, 2018 · 176 comments

Comments

Projects
None yet
@japaric
Member

japaric commented Jan 18, 2018

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

This comment has been minimized.

niklasad1 commented Jan 18, 2018

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

This comment has been minimized.

Collaborator

thejpster commented Jan 18, 2018

@dbrgn

This comment has been minimized.

dbrgn commented Jan 18, 2018

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 referenced this issue Jan 18, 2018

Closed

Upstream updates #1

@therealprof

This comment has been minimized.

Contributor

therealprof commented Jan 18, 2018

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

therealprof commented Jan 18, 2018

@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

This comment has been minimized.

Collaborator

thejpster commented Jan 18, 2018

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

@japaric

This comment has been minimized.

Member

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

This comment has been minimized.

Contributor

therealprof commented Jan 19, 2018

@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

This comment has been minimized.

jacobrosenthal commented Jan 19, 2018

@therealprof

This comment has been minimized.

Contributor

therealprof commented Jan 19, 2018

@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

This comment has been minimized.

whitequark commented Jan 19, 2018

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

This comment has been minimized.

Contributor

therealprof commented Jan 19, 2018

@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...

@chocol4te

This comment has been minimized.

chocol4te commented Jan 19, 2018

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

This comment has been minimized.

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

This comment has been minimized.

Kixunil commented Jan 19, 2018

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

@whitequark

This comment has been minimized.

whitequark commented Jan 19, 2018

@Kixunil any documentation would be helpful.

@mneumann

This comment has been minimized.

mneumann commented Jan 19, 2018

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

This comment has been minimized.

Contributor

therealprof commented Jan 19, 2018

@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

This comment has been minimized.

mneumann commented Jan 20, 2018

@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

This comment has been minimized.

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

This comment has been minimized.

Member

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

This comment has been minimized.

Kixunil commented Jan 21, 2018

@whitequark what exactly are you missing?

@hannobraun

This comment has been minimized.

Member

hannobraun commented Jan 22, 2018

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

This comment has been minimized.

JJJollyjim commented Jan 22, 2018

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

This comment has been minimized.

Contributor

therealprof commented Jan 22, 2018

@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

This comment has been minimized.

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

This comment has been minimized.

Member

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

This comment has been minimized.

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

@nordmoen

This comment has been minimized.

nordmoen commented Mar 27, 2018

Here is the hc-sr04 crate. It is currently blocked on embedded-hal:59 for it to be fully agnostic, but that should be a quick fix.

@ReeceStevens

This comment has been minimized.

ReeceStevens commented Mar 30, 2018

Here is a WIP crate for the afe4400, a pulse oximeter chip made by TI. It uses embedded-hal and nb, although I am currently unable to use the ? operator until the From impl makes its way into nb 0.1.2.

@jamwaffles I'm also going to eventually start working on a display driver and would love to contribute to a generic graphics library like your embedded-graphics crate. Is there a consensus on where we should focus our efforts for building a generic graphics driver? (I'll eventually be writing a driver for the RA8875).

There's exciting work being done over here in embedded rust-- looking forward to contributing :)

@susu

This comment has been minimized.

susu commented Mar 30, 2018

This is an awesome initiative!

Here is my contribution: SX1278 (WIP). It is the chip in many LoRa boards, like the Ra-02 mentioned in the description. I have Ra-01 (not sure about the differences, but Ra-02 has SMA connector for sure).

@lolzballs

This comment has been minimized.

lolzballs commented Mar 30, 2018

I'm working on a driver for the RFM69. It's incomplete right now but I'm wondering if implementing Read and Write traits would be the best way the sending and receiving api.

@dbrgn

This comment has been minimized.

dbrgn commented Mar 31, 2018

@susu @lolzballs very nice to see something being done for LoRa devices.

Your two drivers will give us only LoRa though, no LoRaWAN, right?

(I'm thinking of writing a Rust driver for the RN2483 module, that wouldn't be too hard since it contains a microcontroller that does LoRaWAN and communicates over UART.)

@lolzballs

This comment has been minimized.

lolzballs commented Mar 31, 2018

@dbrgn The RFM69 isn't a LoRa module, so no 馃槢.

@susu

This comment has been minimized.

susu commented Apr 1, 2018

@dbrgn: My driver will give you only the LoRa driver, purely what the chip can do. With this, essentially you can broadcast packets, or receive one, or receive continuously.

The LoRaMAC / LoRaWAN implementation would worth another crate, on top of my sx1278. However I will not use LoRaWAN for now.

@jamwaffles

This comment has been minimized.

jamwaffles commented Apr 1, 2018

@ReeceStevens No consensus at the moment, but of course that leaves the niche open for embedded_graphics to fill ;). It doesn't support colour yet but it's a feature I'd love to add so I'm all open for accepting some swish PRs!

@dbrgn

This comment has been minimized.

dbrgn commented Apr 1, 2018

The RFM69 isn't a LoRa module, so no

Oh, sorry, confused it with the RFM95.

The LoRaMAC / LoRaWAN implementation would worth another crate, on top of my sx1278.

A pure-rust LoRaWAN stack implementation (ideally device-agnostic) would be amazing 馃檪

@dbrgn

This comment has been minimized.

dbrgn commented Apr 1, 2018

SGP30 driver is complete and published: https://blog.dbrgn.ch/2018/4/1/rust-sgp30-driver/

@byronwasti

This comment has been minimized.

byronwasti commented Apr 1, 2018

I have a WIP Memory LCD driver working: https://github.com/byronwasti/ls010b7dh01

My next steps are to abstract away some of the details and to make it screen-size independent. I also just discovered the embedded-graphics crate from this thread, so I will be working on making my driver compatible with that as well.

@japaric

This comment has been minimized.

Member

japaric commented Apr 1, 2018

Hiya folks!

I've deprecated the list of drivers in the issue description in favor of the awesome-embedded-rust list. That list contains not only the list of drivers we had here but also list of device crates, board support crates and HAL implementation crates.

This rationale of this change is that (a) it's better to have a single place to go and find embedded / no-std crates (ideally crates.io should be this place but it's still lacking in domain specific discoverability); and (b) it makes the maintenance of the list easier: you can now send a PR to add your crate to the list instead of waiting for me to notice your comment in this thread.

So, please go ahead and send PRs to that list if I forgot about you (sorry) or if you would like to move your driver crate from the WIP list to the "released" list.

I also would love some help maintaining the list and merging PRs. If you are interested leave a comment in rust-embedded/awesome-embedded-rust#3.

@mbacch

This comment has been minimized.

mbacch commented Apr 2, 2018

New WIP for the MAX31855 driver. This is a thermocouple digital converter for temperature sensing applications. Per @japaric message above, I just sent a PR to add to the WIP list. I'm excited about this WG and am looking forward to helping out more. :)

@TheZoq2

This comment has been minimized.

TheZoq2 commented Jun 3, 2018

I wrote a driver for the dht11 and dht22 temperature/humidity sensors for one of my projects: https://github.com/TheZoq2/weather/blob/master/stmhardware/src/dhtxx.rs. There are some issues with it however

  • Because there is no way to change between an input and output pin at runtime, it is not generic over embedded_hal pins and uses types from the hal implementation crate
  • In order to avoid having to pass a bunch of timing values when using the struct, I use my own time hal crate
  • It also relies on my fork of the f103-hal crate for implementation of those traits
@JoshMcguigan

This comment has been minimized.

JoshMcguigan commented Jul 1, 2018

After completing the Discovery book I started writing a very basic shift register driver.

struct ShiftRegister<Pin1, Pin2, Pin3>
    where Pin1: OutputPin,
          Pin2: OutputPin,
          Pin3: OutputPin,
{
    clock: Pin1,
    latch: Pin2,
    data: Pin3,
}

impl<Pin1, Pin2, Pin3> ShiftRegister<Pin1, Pin2, Pin3>
    where Pin1: OutputPin,
          Pin2: OutputPin,
          Pin3: OutputPin,
{
    fn new(clock: Pin1, latch: Pin2, data: Pin3) -> Self {
        ShiftRegister { clock, latch, data }
    }

    fn update(&mut self, output_state: [bool; 8]) {
        self.latch.set_low();

        for i in 1..=8 {
            if output_state[output_state.len()-i] {self.data.set_high();}
                else {self.data.set_low();}
            self.clock.set_high();
            self.clock.set_low();
        }

        self.latch.set_high();
    }
}

I am very new to embedded development (and relatively new to Rust in general), so I'd like to ask a few questions:

  1. Is a shift register driver something that makes sense as a crate?
  2. Would this type of abstraction (clock, latch, data) work across all SIPO shift registers? I do know they come in various number of outputs (and are chainable), so that'd be a separate thing to take care of somehow.
  3. Related to the questions above, if this were a driver crate, would it make sense to name it generically (like shift-register-driver) or more specifically based on the chip I am using?
  4. I think it would be great if there was a method to build a ShiftRegister and then decompose it back into 8 (or however many) OutputPin like fn decompose(Self) -> [OutputPin; 8]. The OutputPin trait is very simple, but I wonder if the actual behavior of this would fit the meaning of the trait. For example, someone getting an OutputPin from a shift register may not realize that changing the state of that pin actually causes the controller to toggle the state of the three control outputs (clock, data, latch) 20+ times.
  5. If a method like fn decompose(Self) -> [OutputPin; 8] is desirable, I'd be really stretching my Rust skills to actually create it (not that that is a bad thing). Are there any other driver crates that do something like this that I could reference? Specifically I am talking about a method on the ShiftRegister struct which would consume the ShiftRegister and return 8 OutputPin. (edit - I think I see a way to accomplish this using Rc<RefCell>. Has anyone ported those to nostd?)

I want to say thanks to @japaric for putting together the Discovery book, and to the embedded-wg community for sharing so many drivers. This has been a great learning experience so far, and I look forward to being able to contribute back.

@JoshMcguigan

This comment has been minimized.

JoshMcguigan commented Jul 3, 2018

I've fleshed out the driver above a bit more and created shift-register-driver. It is still a simple implementation, but it does accomplish the fn decompose(Self) -> [OutputPin; 8] goal specified above (mostly).

Any feedback is appreciated!

@therealprof

This comment has been minimized.

Contributor

therealprof commented Jul 3, 2018

@JoshMcguigan This is a great idea. There're probably more small functionalities like this which can be implemented in a somewhat generic way. I was already thinking of creating a crate that bundles these kind of GPIO adapter for general consumption; other adapters I can imagine from the top of my head:

  • OutputInverter
  • InputInverter
  • Splitter
  • Logical functions providing N outputs (AND, OR, XOR)
  • Segmented digit display en-/decoder
  • Decimal<->binary encoder

Of course all of the adapters would be stackable, so if you wanted to drive a segmented display using a shift-register which requires a the latch to have an inverted signal -- you can do that.

NB: Don't forget to add a release function so someone could can get their moved GPIO pins back.

@JoshMcguigan

This comment has been minimized.

JoshMcguigan commented Jul 3, 2018

@therealprof Thanks for the feedback. I've added the release function in this commit.

I do like your idea of building up those types of abstractions.

@JoshMcguigan

This comment has been minimized.

JoshMcguigan commented Jul 7, 2018

I've added a pull request to add the shift register driver to the list. The intro blog post is up as well. Thanks again for the feedback.

@johnthagen

This comment has been minimized.

Contributor

johnthagen commented Jul 9, 2018

Has anyone tried doing CAN with the STM32F3DISCOVERY (or any microcontroller)? It looks like this Discovery Shield has a SN65HVD230 CAN transceiver on it (listed in @japaric's original post).

@jamesmunns

This comment has been minimized.

Member

jamesmunns commented Jul 9, 2018

Hey @johnthagen, you might want to check out the discussion on the embedded-hal project: rust-embedded/embedded-hal#53

@kjetilkjeka

This comment has been minimized.

kjetilkjeka commented Jul 9, 2018

@johnthagen I've used can in rust with NXP S32K and socketcan on rpi (if it qualifies as a MCU).

@eldruin

This comment has been minimized.

eldruin commented Aug 6, 2018

Hi, I have a WIP driver for AT24Cx EEPROM ICs almost feature complete here. I have just sent a PR here.
Any comments and design ideas are very welcome.

@eldruin

This comment has been minimized.

eldruin commented Aug 8, 2018

I have created a topic in the rust users forum asking for design and implementation feedback and ideas about my serial EEPROM driver.
I would very much appreciate input from you guys.

@eldruin

This comment has been minimized.

eldruin commented Sep 10, 2018

Hi, my 24x serial EEPROM driver is now finished and my PR here was just merged. The intro blog post is also here.
Any feedback is appreciated.

@eldruin

This comment has been minimized.

eldruin commented Sep 26, 2018

Hi, my DS1307 real-time clock driver is now finished and my PR here was just merged. The intro blog post is here.
Soon I will also finish my driver for PCF8574/A and PCF8575 I/O expanders, including a split() method to get the pins as separate structures.
Any feedback is appreciated.

@e-matteson

This comment has been minimized.

e-matteson commented Sep 26, 2018

I just put in a PR for my released keypad matrix driver. It's a bit different in that it's for a generic sort of circuit, rather than a device, but I think it fits here. @JoshMcguigan and @therealprof, your discussion here about adding abstractions around GPIOs is super interesting, so I applied that to reading from a keypad. I'd be happy to hear any feedback on the design!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment