antoinevg / daisy_bsp Goto Github PK

Hi!

Unfortunately, the sound examples in the daisy_bsp crate don't seem to work on my Seed. I'm not completey sure why yet, but I think I can narrow it down. All other examples work great without a problem. I got one of the latest boards, with the WM8731 codec. It might have something to do with swap due to the ongoing chip shortage.

What I am sure of:

• codec works fine when I upload C++ compiled binaries
• codec doesn't receive any serial data on pin 4 (DACDAT) with Rust compiled binaries (could confirm with oscilloscope)
• MCLK_A, FS_A, SCK_A and SD_B behave as expected
• TX_BUFFER in audio.rs gets passed and stores the right values
• DMA1 interrupts behave as expected

I'm not sure if:

• DMA1 performs properly between memory and peripheral
• one needs to setup the SAI differently (but I will investigate on that)
• it is Rust version specific error/bug

or I could have messed up completely and just overlooked something very obvious

The examples on Daisy Web Programmer work fine, but the cargo build binary does not work. Any idea on what might be the problem?

Hi, thanks so much for this crate and for your ADC talk!

I've done some Arduino and some Rust, but I'm new to embedded Rust, so I'm not used to the lower levels of abstraction. I'm having a hard time understanding how to use analog-to-digital converters to sample values from knobs. I think I should be using stm32h7xx_hal::adc::Adc but I'm getting lost in the docs as to how to do that. Could you point me in the right direction?

EDIT: I have a Daisy Pod so I believe POT 1 maps to board.pins.SEED_21 in the board support crate.

It looks like you need the alloc/nightly feature because you manage interrupts in the library code and you need a concrete struct for your statics.

I wonder if it would make sense to do that handling behind a feature flag and allow for a non alloc version with generics and exposed methods that do all the interrupt handling work but don't actually implement the interrupt callback?

I guess I also have a larger question about what a board support crate should include and not. For instance, if you initialized the board by only passing in the peripherals you needed, instead of basically owning all the peripherals, you wouldn't need to do unsafe steal like in #1 But I'm not 100% on what the "philosophy" of a board support crate is in general, or this one in particular.

Hi!
First thanks for this awesome crate.
My problem is, that when i compile audio_midi example it works.

cargo build --example audio_midi --features="alloc, uses_num"

I copied necessary files (including Cargo.toml) to my own project that i started using hello daisy and cargo generate as per readme in daisy_bsp

cargo generate \
    --git https://github.com/antoinevg/hello-daisy \
    --name hello-daisy

When i try to compile it this way i'm getting error:

error: no global memory allocator found but one is required; link to std or add `#[global_allocator]` to a static item that implements the GlobalAlloc trait

error: `#[alloc_error_handler]` function required, but not found

note: use `#![feature(default_alloc_error_handler)]` for a default error handler

error: `#[panic_handler]` function required, but not found

error: could not compile `daisy-midi` due to 3 previous errors

I don't really understand why, as the code is the same and so are the dependencies and features. I'm using rustc 1.67.0-nightly (c97b539e4 2022-11-30) and target thumbv7em-none-eabihf.

Hope someone can help, thanks.

I'm trying to run an example this way:

cargo run --example audio_passthrough

It starts gdb, then says it can't find openocd.gdb. I copied openocd.gdb from https://github.com/antoinevg/hello-daisy, and now I see this:

    Finished dev [optimized + debuginfo] target(s) in 0.13s
     Running `arm-none-eabi-gdb -q -x openocd.gdb target/thumbv7em-none-eabihf/debug/examples/audio_passthrough`
Reading symbols from target/thumbv7em-none-eabihf/debug/examples/audio_passthrough...

And I get no audio passthrough.

Is there a way to simply flash the Dasiy Seed, without using gdb?

The code itself appears to be correct, but I think the associated comment for both lines is accidentally swapped?
I could be completely wrong bc I'm still very new to the embedded world and if so I'll close this asap!

But based off looking at the pinout diagram, it looks like SPI1 MISO is PIN_10/SeedPin9 and SPI1 MOSI is PIN_11/SeedPin10 yeah? If the comments are swapped, no big deal they're just comments, but can clear up some confusion and despair like a nub like me 🥲

Daisy Seed Pinout Reference

Spent the entire weekend trying to configure an SSD1306 display via SPI and unfortunately no luck, however it's forced me to study this codebase a lot and the pin out diagram relentlessly lmao.