Some boards, e.g. the ItsyBitsy M4, have a flash chip onboard which they use QSPI to communicate with. It'd be real nice to support those. I'll start work on those once I have a chance if no one else has, but that won't be for a while, so if someone else would like to implement it in the mean time, I'm happy to test on my board.

I'm seeing general flakiness when using the display on pygamer.
All the other examples seem to work fine.

Issues I have seen when tweaking the ferris_img demo:

• If I try to add a delay after drawing ferris, I get no display output
• If I change the background color when clearing the screen to something other than black or blue (a small number), I get no display output
• The board sometimes gets into a "bad state" where the ferris_img demo does not run. If I flash another example, then go back and flash the same ferris_img demo again then that sometimes fixes it.

Has anyone else seen these or similar issues?
Does anyone have tips/guidance on how to set up low-level debugging for pygamer? I'm new to this. Is it possible to use OpenOCD with VSCode/Cortex-Debug extension?

Discovered in #113

Its possible for user and or library subsystems to both attempt to take the same clock causing panic.

We should look at how to have the clock tree hand out gclk 3-11 just like we do for glck0 and gclk1

Heya,

In trying to get the GPIO's passed through for the bitbang'ed dotstar LED I ran into issues converting the embedded_hal v1 GPIO's into v2 GPIOs. I could only get it to work with the unproven feature flag.

I think this is the culprit:

#[cfg(feature = "unproven")]
impl<MODE> InputPin for $PinType<Input<MODE>> {
  // TODO: switch to ! when it’s stable

v2 seems well established. Can we pull this out of the feature flag?

Wanted to try out the metro_m0 examples, but compiling fails:

error[E0432]: unresolved import `crate::hal::Pwm`
 --> /atsamd-rs/hal/src/samd21/pwm.rs:2:18
  |
2 | use crate::hal::{Pwm, PwmPin};
  |                  ^^^ no `Pwm` in the root

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `atsamd-hal`.

I'm using the gcc-arm-embedded from the ppa and rust 1.40 as described in the README

Hi,

I would like to extend Rust support for SARA Arduino Form Factor boards made by @SodaqMoja.
Link: Sodaq Sara_AFF

They feature the ATSAMD21J18. I looked around in the repo but it seems support is not yet available for this particular MCU. They also feature a range of sensors and AT command based cellular modules that support LTE-M and NB-IoT.

I could try building the necessary files myself but I am not an experienced developer nor do I have any experience with Rust. It would therefore be great if somebody could provide support for this board or guide me in the process.

Hello, I'm debugging some bidirectional UART issues with a simple serial loopback example for a Trinket M0 board. However, I'm unable to read any RX data over UART. The serial.read() call blocks forever, maybe because the RXC bit is never set.

I've verified that the Trinket M0 board and USB to UART adapter are working correctly with an Arduino sketch. I'll try to get my hands on a samd21 board with a SWD debug header so I can poke things with gdb. But for now, could someone let me know if I've initialized the UART0 device correctly?

New file boards/trinket_m0/examples/uart_loopback.rs, built on top of commit 53f8d84.

#![no_std]
#![no_main]

#[macro_use(block)]
extern crate nb;
extern crate panic_halt;
extern crate trinket_m0 as hal;

use hal::clock::GenericClockController;
use hal::prelude::*;
use hal::{entry, CorePeripherals, Peripherals};

#[entry]
fn main() -> ! {
    let mut peripherals = Peripherals::take().unwrap();
    let mut core = CorePeripherals::take().unwrap();
    let mut clocks = GenericClockController::with_internal_32kosc(
        peripherals.GCLK,
        &mut peripherals.PM,
        &mut peripherals.SYSCTRL,
        &mut peripherals.NVMCTRL,
    );
    let mut pins = hal::Pins::new(peripherals.PORT);
    let mut red_led = pins.d13.into_open_drain_output(&mut pins.port);

    let mut serial = hal::uart(
        &mut clocks,
        9600.hz(),
        peripherals.SERCOM0,
        &mut core.NVIC,
        &mut peripherals.PM,
        pins.d3,
        pins.d4,
        &mut pins.port,
    );

    serial.bwrite_all(b"ready\r\n").unwrap();
    loop {
        let byte = block!(serial.read()).unwrap();
        red_led.toggle();
        block!(serial.write(byte)).unwrap();
    }
}

Would like to see what everyone thinks about changing the type to Option, so that you can do one way SPI and UART without wasting pins.

Also the github.io keeps crashing my tabs.

Embedded-hal has an ADC trait, we have an ADC, let's figure out how to use it.

I see the repo says "atsamd", but can't find something similar for the Microchip ATSAME54P20A - the chip I'm targeting.

Will this be fine place to submit any chip/HAL support for this MCU?

If a pin is not set High before being switched from Input to OpenDrainOutput, it will default to Low.

This is unexpected behavior.

If a pin is being used as e.g. a interrupt trigger output on a common rail, the switch is enough to trigger the external interrupt during startup!

Either the pin.into_open_drain_output(&mut port); should set the pin high before switching, or we should have an extra method with the option for doing so!

Hello all,

I'm not sure if I'm missing something, but I'm having trouble setting up multiple PWM pins on an ATSAMD11C14. I need a total of 4 PWM pins. Would this require adding support for TC2, or maybe TCC0?

I've been playing with the ATSAMD11C14A and decided to take a swing at adding HAL support for this device.

https://github.com/jessebraham/atsamd11-rs

I copied the hal/src/common/ directory verbatim to my project, then modified the hal/src/samd21 directory to reflect the new samd11 device. Everything seems to build except the USB module, which I can't get to build in this project either for some reason, so that has been omitted for the time being.

All I've tested on hardware so far is a basic blinky demo I hacked together, but that seems to be working; I plan on doing some further testing.

Any interest in integrating this into the project, or was the goal to stay focused on the samd21/samd51?

Are there any plans for Zero support?

I see there's MKRZERO support, but I'm unsure regarding how similar the pin assignments are on these boards. [EDIT]: I see Bobbin seems to feature crates for support of this board, but frankly I'd rather not stray there.

Love all your neopixel code and have been cargo culting it for pygamer as you can tell with all my noise in issues.

One more for @tarcieri @sajattack
The wheel boiler plate were all using just feels too C for me, and I could barely understand it

const NUM_LEDS: usize = 5;
let mut data = [RGB8::default(); NUM_LEDS];

loop {
    for j in 0..(256 * 5) {
        for i in 0..NUM_LEDS {
            data[i] = wheel((((i * 256) as u16 / NUM_LEDS as u16 + j as u16) & 255) as u8);
        }
        let _ = neopixel.write(brightness(data.iter().cloned(), 32));
        delay.delay_ms(5u8);
    }
}

Im thinking of PRing a cleanup to all of us. Wondering if anyone has a preference. I got a huge win in just doing this I think

const NUM_LEDS: usize = 5;
let mut data = [RGB8::default(); NUM_LEDS];

loop {
    for j in 0..255u8 {
        for i in 0..NUM_LEDS {
            // stagger the color changes across all 5 leds evenly, 255/5=51
            // and have them safely wrap over when they go above 255
            let step = j.wrapping_add(51 * i as u8);
            data[i] = wheel(step);
        }
        let _ = neopixel.write(brightness(data.iter().cloned(), 32));
        delay.delay_ms(5u8);
    }
}

but maybe fully iterators teaches better.. is it as clear though?

const NUM_LEDS: usize = 5;

loop {
    for j in 0..255u8 {
        let _ = neopixel.write(brightness(
            (0..NUM_LEDS).map(|i| {
	        // stagger the color changes across all 5 leds evenly, 255/5=51
	        // and have them safely wrap over when they go above 255
                wheel(j.wrapping_add(51 * i as u8))
            }),
            32,
        ));

        delay.delay_ms(5u8);
    }
}

or maybe just go for 100% clarity and lose the inner loop ? Also no preallocation for better or worse

loop {
    for j in 0..255u8 {
        let colors = [
            // stagger the color changes across all 5 leds evenly, 255/5=51
            // and have them safely wrap over when they go above 255
            wheel(j),
            wheel(j.wrapping_add(51)),
            wheel(j.wrapping_add(102)),
            wheel(j.wrapping_add(153)),
            wheel(j.wrapping_add(204)),
        ];
        neopixel
            .write(brightness(colors.iter().cloned(), 32))
            .unwrap();
        delay.delay_ms(5u8);
    }
}

I have a usb commit in #104 here for pygamer When you open the port with screen /dev/blah 115200 and type nothing is printed on screen and Ive checked and the characters arent even received. I thought it was maybe interrupts, but I implemented the polling to upper case echo example and it has the same behavior.

So maybe my implementation is broken, but wait I noticed as you close screen, the led example will trigger and In the case of the polling to upper case example when you reopen screen you'll see your previous chars printed to screen.

So the act of closing is triggering for some reason. I can't confirm on itsy but I presume its the same. So maybe its my setup for some reason. I checked with stm32-usb and a upper case polling bluepill example and can confirm those characters are echoed immediately using screen so its not my setup.

I have a feeling using the stty as given in directions in Itsy, opens and closes and is thus triggering a flush somehow and so this hasnt been noticed until now.

Im not yet familiar with the usb device implementation but I think it would lie in there somewhere. Any thoughts @sajattack ?

Having a bit of a strange problem here. I also have no idea what I'm doing so hopefully I'm just missing something silly.

I was able to build the blinky_basic example from the repository for the Trinket M0 no problem by following the instructions in the readme. So far so good.

I then created a new project using cargo new, added trinket_m0 = "0.3.0" and panic-halt = "0.2.0" to my dependencies, and copied the blinky_basic.rs file verbatim into my main.rs.

Running cargo build, I'm presented with the following warnings and errors (duplicated for both set_high() and set_low(), omitting the latter for brevity):

warning: use of deprecated item 'hal::prelude::_embedded_hal_digital_OutputPin::set_high': Deprecated because the methods cannot return errors. Users should use the traits in digital::v2.
--> src\main.rs:30:17
|
30 | red_led.set_high().unwrap();
| ^^^^^^^^
|
= note: #[warn(deprecated)] on by default

error[E0599]: no method named unwrap found for type () in the current scope
--> src\main.rs:30:28
|
30 | red_led.set_high().unwrap();
| ^^^^^^

Anybody have any idea what I'm missing here?

As of embedded_hal 0.2.3, there is a new fallible (returns a Result) version of the digital traits and the non-fallible version we are using is deprecated. It looks like there are compatibility shims to upgrade v1 (the version we're using) to v2, but I don't know all the details. As usual, probably a good idea to see what other HALs like stm32f1xx and nrf52 are doing.

The most common way for Adafruit to flash programs to their devices is through a protocol called UF2. This protocol is part of the bootloader Adafruit ships on their boards, and it makes flashing firmware as easy as dragging and dropping a file to an emulated Mass Storage Device. I've written a UF2 converter in rust here. The question is how do you want to incorporate it into the workflow? One suggestion I've received is to write a script that runs the linker, does the objcopy and invokes my converter and use that script as the linker field of a .cargo/config file.

Hi, I'm a rust beginner so it is very probable that I am doing something silly, but on
pragun@lubuntu-vm:~/rust_experimentation/atsamd/boards/metro_m0$ cargo build --example usb_serial

I get

Compiling atsamd-hal v0.7.4 (/home/pragun/rust_experimentation/atsamd/hal) error[E0433]: failed to resolve: could not findusbinhal--> examples/usb_serial.rs:9:15 | 9 | use hal::hal::usb::usb_device::bus::UsbBusWrapper; | ^^^ could not findusbinhal
which of course brings up a host of other compile errors.

It'd be great if someone could point me down the right path here, thanks!

I've been eyeing the ItsyBitsy M4 lately, because I already know I can deploy to M4 but I want something smaller. Are there any plans to add support for it?

I'm happy to do it myself. There's one slight issue, which is that I don't know how. I could go through the other M4 and M0 crates and try to adapt itsybitsy_m0, but I'm not sure if that'd miss something important or not, and I likely won't use enough of the HAL to catch subtler issues.

Adafruit's Feather line has something like 5-10 M0 variations depending on how you want to count the different radio variations. Should there just be one board module for all Feather M0 boards or should there be a new board folder for every single one?

The docs for cortex-m-rt 0.5 are no longer available on docs.rs. Also it looks like 0.6 improves exception handling.

OpenOCD seems to be the standard these days for rust-embedded. See the rust-embedded book for example. Until we get UF2 working I think it makes more sense to use OpenOCD rather than JLink.

There appears to be a mismatch between the TCC.CCBUF register definition found in the D5x/E5x datasheet (Revision E) and what is generated for SAMD51x family PACs.

In the case of the DITH4 resolution, the CCBUFn.CCBUF should occupy bits [23:4], and the CCBUFn.DITHERBUF occupies bits [3:0]. However, the PAC says that CCBUFn.CCBUF occupies [3:0] and the CCBUFn.DITHERBUF occupies [23:4]. The field offset and size has been swapped for CCBUF and DITHERBUF.

This seems to be an error present in the SVD files used to generate this crate, so that will have to be corrected for the PAC to generate correctly. So far I've checked SAMD51J19A and SAMD51G18A SVD's and they seem to both have the error.

I am currently trying to drive the Circuit Playground's Neopixels using SPI. For doing so @david-sawatzke started writing an experimental crate. However, while trying to use it, I noticed the first pixel to always display #008000 instead of #000000. As we were able to determine with a logic-analyzer, the reason is that the SPI is IdleHigh and this is being interpreted as the first bit being one (ws2812 uses green-red-blue). My code:

let mut peripherals = Peripherals::take().unwrap();
let core = CorePeripherals::take().unwrap();
let mut clocks = GenericClockController::with_internal_32kosc(
    peripherals.GCLK,
    &mut peripherals.PM,
    &mut peripherals.SYSCTRL,
    &mut peripherals.NVMCTRL,
);
let mut pins = hal::Pins::new(peripherals.PORT);

let spi_pinout = hal::sercom::SPI5Pinout::Dipo2Dopo2 {
    miso: hal::sercom::Sercom5Pad2::pb0(pins.foo, &mut pins.port),
    mosi: hal::sercom::Sercom5Pad3::pb23(pins.neopixel, &mut pins.port),
    sck:  hal::sercom::Sercom5Pad1::pb17(pins.bar, &mut pins.port),
};

let gclk = clocks.gclk0();
let spi = hal::sercom::SPIMaster5::new(
    &clocks.sercom5_core(&gclk).unwrap(),
    3_000_000.hz(),
    embedded_hal::spi::Mode {
        polarity: embedded_hal::spi::Polarity::IdleLow,
        phase: embedded_hal::spi::Phase::CaptureOnFirstTransition,
    },
    peripherals.SERCOM5,
    &mut peripherals.PM,
    spi_pinout,
);

let mut ws = ws2812_spi::Ws2812::new(spi);

(The pins pins.foo and pins.bar are PB0 and PB17 respectively, I just added them to get the SPI peripheral working ...)

Is there something wrong on my side or is this an issue in the hal?

Another SVD mismatch with the reference manual.

Pretty much what it says on the tin. The DMAOS field of the CTRLA register for TC peripherals is not present in the SVD files for all processors in the SAMD5x/E5x family, but is present in the Reference Manual. All possible TC mode configurations (COUNT8, COUNT16, COUNT32) in the associated PACs are missing this field.

This code fails to compile on feather_m0 0.5.0, while it worked on 0.4.0:

#![no_std]
#![no_main]

extern crate panic_halt;  // panic handler

use feather_m0 as hal;
use hal::clock::GenericClockController;
use hal::delay::Delay;
use hal::prelude::*;
use hal::{entry, Peripherals, CorePeripherals};

With this error:

error[E0432]: unresolved imports `hal::Peripherals`, `hal::CorePeripherals`
  --> src/main.rs:18:18
   |
18 | use hal::{entry, Peripherals, CorePeripherals};
   |                  ^^^^^^^^^^^  ^^^^^^^^^^^^^^^ no `CorePeripherals` in the root
   |                  |
   |                  no `Peripherals` in the root

Is this expected? I'm not sure how to remedy this error.

I think there are enough folks contributing to enough boards that this makes sense to do, and it should streamline progress. We recently went through a similar process for the nrf-rs family of boards.

Here's what I'm proposing:

• I'll create the organization and move this repo into it, so that it ends up being named something like atsamd-rs/atsamd (I've omitted the 21 because I have an atsamd51 that I think we can support with basically the same HAL).
• I'll create a github team for the purpose of owning the crates on crates.io, with members comprising the folks that contributed the boards and published to crates.io
• We each add that team as an owner of the various crates which we have access, so that any of us are now able to push to the repo (but see below!) and publish to crates.io
• Members of the team will need to enable 2FAC for their github account; this will be enforced through githubs existing controls such that github will automatically remove you from the team if 2FAC is disabled.

While we'll all have the ability to push, I'd like to encourage the use of pull requests to solicit input and feedback before unilaterally pushing. I'm generally in favor of making forward progress, so if you do have push access and haven't had feedback within a reasonable time, or if in your best judgement the change you want to push is non-controversial and/or low risk, then I think it's fine to push. As a reviewer, if you'd like to have a chance to weigh in but don't currently have time then communicating that and a rough ETA on the pull request is a good idea.

Thoughts? Concerns?

@zklapow @djmcgill @BenBergman @sajattack @bfritz

If I've understood correctly, the 1010 would work with the mkrzero code. But I need to use bluetooth, which works differently than on any other board on the 1010. How would I port that to Rust?

Arduino MKR 1000 Support

The Arduino MKR1000 is a Wifi connected board build on SAMD21. It is very similar to the MKRZERO which this crate currently supports.

It would be great if support could be added for the MKR1000 either by extending the arduino_mkrzero crate or creating a new arduino_mkr1000 crate that supports the MKR1000.

Thanks in advance!

Best,

Avery

Hello,

I've seen some mentions you're working on ATSAMD51 support:

• #19
• rust-embedded/wg#286

I'm interested in working on a Rust project targeting ATSAMD51, and was curious what the present state of that looks like.

ATSAMD21/51 both support I2S. Is there a plan to add this to the HAL?

edit: should this issue be named "Implement I2S abstraction"?

Unless I'm mistaken, there is no standard embedded-hal trait for I2S just yet.

Hello there, I really like this project and I am working on description of Arduino Nano 33 IOT. I am new to Rust world, but there is not implemented Copy trait on pins. Is there any way to actually have multiple names for one PIN, as some pins are digital and also TX. It is just for abstraction.

And I think I might have rewritten my bootloader. So now I have chip without software to be able to write to it. If I would be successful on restoring the bootloader, I might actually try to release this board here.

The embedded-hal crate provides a trait for an RNG but I don't believe it is implemented yet. I haven't had a chance to research it yet but wanted to get the feature tracked.

https://docs.rs/embedded-hal/0.2.2/embedded_hal/blocking/rng/trait.Read.html

I'm using a feather_m0 board and the AD8495 thermocouple amplifier. The ADC HAL seems to be working great, except that it returns values exactly 2x of what is expected.

I've tried debugging this, but haven't gotten far. The gain settings are being written in the HAL code, and I don't see any other obvious ways we can get a 2x gain error. I'm reading from pin A5 for the record (pin B2 it seems).

Here's a trimmed down version of my code:

#![no_std]
#![no_main]

const ADC_FULLSCALE: u32 = 4095; // 12 bit ADC

extern crate cortex_m;
extern crate panic_halt; // panic handler

use feather_m0 as hal;
use hal::adc::Adc;
use hal::clock::GenericClockController;
use hal::delay::Delay;
use hal::entry;
use hal::pac::{CorePeripherals, Peripherals};
use hal::prelude::*;

#[entry]
fn main() -> ! {
    // cortex_m::Peripherals::take().unwrap()
    let mut peripherals = Peripherals::take().unwrap();
    let core = CorePeripherals::take().unwrap();
    let mut clocks = GenericClockController::with_external_32kosc(
        peripherals.GCLK,
        &mut peripherals.PM,
        &mut peripherals.SYSCTRL,
        &mut peripherals.NVMCTRL,
    );

    let mut pins = hal::Pins::new(peripherals.PORT);

    let mut i2c = hal::i2c_master(
        &mut clocks,
        400.khz(),
        peripherals.SERCOM3,
        &mut peripherals.PM,
        pins.sda,
        pins.scl,
        &mut pins.port,
    );  // used for a display

    let mut adc = Adc::adc(peripherals.ADC, &mut peripherals.PM, &mut clocks);
    let mut a5 = pins.a5.into_function_b(&mut pins.port);

    loop {
        let data: u16 = adc.read(&mut a5).unwrap();
        let data: u16 = data / 2;
        let temp_c: f32 = (((data as f32 / ADC_FULLSCALE as f32) * 3.3) - 1.25) / 0.005;
        let temp: f32 = temp_c * (9. / 5.) + 32.;  // print to display
        delay.delay_ms(1000 as u32);
    }
}

Good news and bad news:
I found a crate (mashup) which lets you generate identifiers, so the macro call now looks like

define_pins2!(
    struct Pins,
    target_device: atsamd21g18a,

    /// Digital 0: PWM, TC
    pin d0 = a22,

But the macro now looks like https://github.com/djmcgill/atsamd21-rs/blob/mashup-iden-test/arduino_mkrzero/src/lib.rs

Is this a solution you'd be interested in or are we tying ourselves in knows just to save a small amount of duplication (which gets compile checked anyway)?

This issue is tracking the implementation of USB.

• USB Device crate atomics don't compile on thumbv6m rust-embedded-community/usb-device#2
• Can we do better than Mutex around the inner portion of the UsbBus impl? This currently satisfies the 'Sync' requirement but may to too coarse
• Move buffer allocation off the stack. Either do something custom as a static or look at an existing heap allocation crate for this purpose
• Prune out some of the ep! helper macro invocations. Likely don't need so many of these now
• implement the is_stalled method
• Can we do better than all these globals? https://github.com/wez/atsamd21-rs/blob/usb/metro_m0/examples/usb_serial.rs#L23-L25

In arduino_mkrzero, I just copied the same structure of pub use etc that existed in the other board libraries.

However now I'm actually trying to use them in an application I'm running into difficulties. Theatsamd_hal and embedded_hal modules aren't actually exported, only their contents which behaves oddly. You can see in this search that the only OutputPin type exported by the board library is arduino_mkrzero::prelude::_embedded_hal_digital_OutputPin.

The problem goes away if the user includes embedded_hal directly in their own Cargo.toml but if that's the expected case then the re-exports are still useless.

Any suggestion? The simplest solution would be to drop all the re-exports and the user is expected to import the embedded_hal crate themselves in order to use the board crate. Or we could pub use atsamd21_hal as hal (i.e. NOT a glob import) and then users could access arduino_mkrzero::hal::digital::OutputPin.

In short the current solution doesn't really suit our (users') needs and we should think about a better one :)

Either that or I'm using the board library wrong in which case I suggest that the documentation be improved to make things clearer.

We'll probably have to switch these all to using panic-halt instead.

Adafruit has a Feather board with an ATWINC1500 WiFi module onboard. I'm wondering what it would take to get a driver written for that chip. I've never written a driver before, but I'm at least considering it. I looked around on the awesome-embedded-rust repo, and there aren't really any other WiFi module drivers listed on that page. It makes me wonder if there's a reason i.e. it's a ton of work, there's a bunch of hidden complexities related to network connections, etc. Does anyone have any insight here?

[xxx@xxx]:~/projects/cck> ./cck-dev build
   Compiling cck v0.2.0 (/home/xxx/projects/cck)
error[E0433]: failed to resolve: use of undeclared type or module `SpinTimer`
  --> src/main.rs:33:70
   |
33 |     let mut rgb = hal::dotstar_bitbang(pins.dotstar, &mut pins.port, SpinTimer::new(20));
   |                                                                      ^^^^^^^^^ use of undeclared type or module `SpinTimer`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0433`.
error: Could not compile `cck`.

To learn more, run the command again with --verbose.

sajattack pushed new crates, so I'm guessing we need to bump the version in the itsybitsy crate to >=0.7.1 ?

I'm a bit confused by the structure of the repo - the crates are entirely separate according to the rust/cargo model right?

Do you have any plans to publish the arduino_mkrzero crate as the owner of the repo or shall I as its primary author?

I tried following instructions in Readme, but only get these build errors (Feather M0):

error[E0557]: feature has been removed in #![feature(panic_implementation)] (build-all.sh)

Compiling current master (and it seems also the releases) for the samd21e18a target with the unproven feature errors out

atsamd/hal [master] λ cargo build --features unproven,samd21e18a
[...]
   Compiling atsamd-hal v0.7.4 (/home/soryio/usr/proj/181127-embedded_rust-69/atsamd/hal)
error[E0432]: unresolved imports `crate::gpio::Pb0`, `crate::gpio::Pb1`, `crate::gpio::Pb2`, `crate::gpio::Pb3`, `crate::gpio::Pb4`, `crate::gpio::Pb5`, `crate::gpio::Pb6`, `crate::gpio::Pb7`, `crate::gpio::Pb8`, `crate::gpio::Pb9`
 --> src/samd21/adc.rs:3:57
  |
3 |     Pa10, Pa11, Pa2, Pa3, Pa4, Pa5, Pa6, Pa7, Pa8, Pa9, Pb0, Pb1, Pb2, Pb3, Pb4, Pb5, Pb6, Pb7,
  |                                                         ^^^  ^^^  ^^^  ^^^  ^^^  ^^^  ^^^  ^^^ no `Pb7` in `common::gpio`
  |                                                         |    |    |    |    |    |    |
  |                                                         |    |    |    |    |    |    no `Pb6` in `common::gpio`
  |                                                         |    |    |    |    |    no `Pb5` in `common::gpio`
  |                                                         |    |    |    |    no `Pb4` in `common::gpio`
  |                                                         |    |    |    no `Pb3` in `common::gpio`
  |                                                         |    |    no `Pb2` in `common::gpio`
  |                                                         |    no `Pb1` in `common::gpio`
  |                                                         no `Pb0` in `common::gpio`
4 |     Pb8, Pb9, PfB,
  |     ^^^  ^^^ no `Pb9` in `common::gpio`
  |     |
  |     no `Pb8` in `common::gpio`
help: a similar name exists in the module
  |
3 |     Pa10, Pa11, Pa2, Pa3, Pa4, Pa5, Pa6, Pa7, Pa8, Pa9, Pa0, Pb1, Pb2, Pb3, Pb4, Pb5, Pb6, Pb7,
  |                                                         ^^^
help: a similar name exists in the module
  |
3 |     Pa10, Pa11, Pa2, Pa3, Pa4, Pa5, Pa6, Pa7, Pa8, Pa9, Pb0, Pa1, Pb2, Pb3, Pb4, Pb5, Pb6, Pb7,
  |                                                              ^^^
help: a similar name exists in the module
  |
3 |     Pa10, Pa11, Pa2, Pa3, Pa4, Pa5, Pa6, Pa7, Pa8, Pa9, Pb0, Pb1, Pa2, Pb3, Pb4, Pb5, Pb6, Pb7,
  |                                                                   ^^^
help: a similar name exists in the module
  |
3 |     Pa10, Pa11, Pa2, Pa3, Pa4, Pa5, Pa6, Pa7, Pa8, Pa9, Pb0, Pb1, Pb2, Pa3, Pb4, Pb5, Pb6, Pb7,
  |                                                                        ^^^
help: a similar name exists in the module
  |
3 |     Pa10, Pa11, Pa2, Pa3, Pa4, Pa5, Pa6, Pa7, Pa8, Pa9, Pb0, Pb1, Pb2, Pb3, Pa4, Pb5, Pb6, Pb7,
  |                                                                             ^^^
help: a similar name exists in the module
  |
3 |     Pa10, Pa11, Pa2, Pa3, Pa4, Pa5, Pa6, Pa7, Pa8, Pa9, Pb0, Pb1, Pb2, Pb3, Pb4, Pa5, Pb6, Pb7,
  |                                                                                  ^^^
help: a similar name exists in the module
  |
3 |     Pa10, Pa11, Pa2, Pa3, Pa4, Pa5, Pa6, Pa7, Pa8, Pa9, Pb0, Pb1, Pb2, Pb3, Pb4, Pb5, Pa6, Pb7,
  |                                                                                       ^^^
help: a similar name exists in the module
  |
3 |     Pa10, Pa11, Pa2, Pa3, Pa4, Pa5, Pa6, Pa7, Pa8, Pa9, Pb0, Pb1, Pb2, Pb3, Pb4, Pb5, Pb6, Pa7,
  |                                                                                            ^^^
help: a similar name exists in the module
  |
4 |     Pa8, Pb9, PfB,
  |     ^^^
help: a similar name exists in the module
  |
4 |     Pb8, Pa9, PfB,
  |          ^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `atsamd-hal`.

To learn more, run the command again with --verbose.

This is a tracking issue for supporting the ATSAMD51's DAC. I'm primarily interested in supporting the AdaFruit NeoTrellis M4 (see rust-embedded/wg#286). Wiring it into an ADC abstraction (#35) sounds cool, but for now I'd be happy just getting it working with the low-level API.

The main thing I have to go off of is AdaFruit's port of the Teensy audio engine to these platforms. Here are a few relevant commits:

• "DM: working w/ dual dac only" adafruit/Audio@6d1ee58
• "DM: interrupts fix and update synthesis examples for SAMD51" adafruit/Audio@4a8bc71
• "DM: fix DMA interrupt structure for DAC output, other SAMD51 updates" adafruit/Audio@8f43258

Is DMA going to be an issue?

For what it's worth, I'd like to attempt to port this PureData synthesis engine to this platform:

https://github.com/mhroth/ZenGarden

I started a project to do that here:

https://github.com/neobirth/zengarden.rs

This project supports NEON acceleration, although I'm not sure if it's compatible with the subset of NEON (DSP instructions) supported by the ATSAMD51(G19A?). Otherwise it appears to be an easy-to-embed PureData engine that runs inside of an external event loop written in C++ that presents a C interface.

I cannot figure out how to use the RTC.

19.5.3 The RTC bus clock (CLK_RTC_APB) can be enabled and disabled in the Power Manager, and the default state of CLK_RTC_APB can be found in the Peripheral Clock Masking section. A generic clock (GCLK_RTC) is required to clock the RTC. This clock must be configured and enabled in

16.6.2.6 shows that CLK_RTC_APB is enabled by default, and the apbamask shows that is is on.

peripherals.PM.apbamask.read().rtc_().bit() // true

I tried writing RTC enable bit but it blocks forever.

let rtc = peripherals.RTC.mode0();
rtc.ctrl.write(|w| w.enable().clear_bit()); // <- this blocks forever

I know that I need to enable a clock generator, but I don't know how to connect a generator to the RTC peripheral.

Thanks for writing this crate, it helped me build this calculator. Now I want to use the RTC to seed the PRNG.

I'd like to have a discussion on this. Currently, our board support crates are quite light, basically just pin definitions. @tarcieri is looking to integrate drivers for sensors, and possibly additional abstractions based on those drivers for trellis_m4. I'm wondering if we should add neopixel support via smart-leds to all the board support crates with neopixels. Any comments for or against are appreciated.

Title kinda speaks for itself. I'll try to work on this but will probably need help.