riscv-rust / e310x-hal Goto Github PK

I'm trying to use spi in the HAL. However, my board is wired such that the CS pin is used to switch between command and data mode between transfers. I don't think this is currently possible as spi.csid is only written in the constructor. Or is there something I'm missing?

• gpio
• uart
• clint
• clock
• pwm (wip)
• plic (wip)
• spi
• rtc
• wdog
• pmu

portable-atomic added a new feature that is particularly well-suited for e310x targets. It allows us to compile over riscv32imc-unknown-none-elf while leaving AMOxxx instructions with no emulation. Once portable-atomic releases a new version, we can benefit from it. The downside is that we should bump MSRV to 1.72.

flush() should check whether FIFO is empty.

The macros for the various peripherals create a new type for each instance of the same hardware. These types share the general embedded_hal traits, but I need something that provides the hardware-specific methods. I'd like to write some code that is general and doesn't care, say, what SPI device (for example) is passed in.

I have code like this, for example:

use hifive1::hal::spi::{Spi, Mode, Polarity, Phase};
...

// SPI backend trait for display interface
pub trait SPI {
    fn send(&mut self, data: u8);
    fn complete(&mut self);
    fn mode_data(&mut self);
    fn mode_cmd(&mut self);
}

pub struct Hifive1SPI<X, Y, DC> where
    DC: OutputPin {
    hwspi:  Spi<X, Y>,
    dc:    DC,
}

impl <Y, DC> Hifive1SPI<QSPI1, Y, DC> where
    Y: hifive1::hal::spi::Pins<QSPI1>,
    DC: OutputPin {
    pub fn new(hwspi: Spi<QSPI1, Y>, dc: DC) -> Hifive1SPI<QSPI1, Y, DC> {
        Hifive1SPI {
            hwspi,
            dc,
        }
    }
}

impl <Y, DC> SPI for Hifive1SPI<QSPI1, Y, DC> where
    Y: hifive1::hal::spi::Pins<QSPI1>,
    DC: OutputPin {
    fn complete(&mut self)
    {
        // Wait for send FIFO to drain
        while !self.hwspi.tx_wm_is_pending() {
            // IDLE
        }
    }

    fn send(&mut self, data: u8)
    {
        while let Err(_) = self.hwspi.send(data) {
            // IDLE
        }
    }

    fn mode_data(&mut self)
    {
        self.complete();
        self.dc.set_high();
    }

    fn mode_cmd(&mut self)
    {
        self.complete();
        self.dc.set_low();
    }
}

Currently this specializes on QSPI1 because I don't see a way to generalize it over all SPI devices, as tx_wm_is_pending is not on a trait.

(I had a similar situation with GPIO pins in the board setup, where I wanted to make it possible to pass in arbitrary pins to configure, but there is no trait that provides into_output into_inverted_output. There's OutputPin of course, but that's only useful when the pin is already set up)

I'm fairly new to Rust, entirely new to using Rust for embedded programming, so I may be missing something.

Volume II: RISC-V Privileged Architectures V1.10 p.31 contains an example for more reliable mtimecmp update sequence.

Currently the SPI driver assumes bidirectional communication. To use a peripheral that is send-only or receive-only, a dummy pin needs to be sacrificed.

Hello, as mentioned here: riscv-rust/riscv-rust-quickstart#22 im moving this issue.

Im trying to use HiFive rev b board with DHT22 sensor. It needs "open-drain" output option to work. I asked on Matrix - Rust Embedded channel and what i get from there its not supported by this chip or library. As solution for this they gave me as example this link:

https://github.com/rp-rs/rp-hal/blob/main/rp2040-hal/examples/dht11.rs#L55-L88

"At a lower level, you could set input_en=1, output_val=0, pue=1 and then set output_en=1 to actively pull the line down, output_en=0 to pull it up using the weak pull-up resistor, and read input_val to read back the DHT response. But it seems like that mode is not implemented by the HAL. (Same situation as with the RP2040 and its HAL)"

Please could you update your library with such feature? To make it more useful for others.

Someone can start executing the firmware with clock tree initialized (e.g. via gdb).

I've been studying the riscv-rt, e310x and e310x-hal crates for a while, and I'm currently exploring different interruption modes. As far as I know, riscv-rt leaves you the MachineExternal function for dealing with all the machine external interrupts. The e310x crate allows you to define specific interrupt handlers for each interrupt source (e.g., a GPIO) with the interrupt macro. However, I don't see a clear connection between MachineExternal and these functions (I mean, which part of the code does the trick to identify the source and call the proper interrupt handler if exists).

I managed to catch GPIO interruptions by defining a common MachineExternal function and analyzing the interrupt source, but I wonder if it's possible to define custom handlers for a given GPIO using the interrupt macro and forget about the MachineExternal common handler.

Changing 1000 by 1000000 could do it for Sleep ?

What is the reason for the following macro to be so complicated?

Can it be changed to this simple one line macro?

macro_rules! read64 {
    ($hi:expr, $lo:expr) => { (($hi as u64) << 32) | $lo as u64 }
}

As discussed in yesterday's WG meeting, saying that the E310x chip supports atomic operations is... arguable, as LR/WC operations are not supported at all. I think we should remove dependencies to the core::sync::atomic module to allow compilations with the riscv32imc target and use atomic emulation such as atomic-polyfill when needed. Users can still compile for riscv32imac and use atomics if they want (provided that they only use simple load/store operations).