Hello,

I have tried to implement the Write trait for the Serial struct and I haven't succeed making the write_fmt work.
Both write_str and write_char works well and I can't seem to understand why the write_fmt doesn't work. I don't have many experience with rust so maybe you can figure out what is not working. I though since write_str is working well and as write_fmt is implemented in Write trait, it should be working.

Here is the simple implementation I did :

impl Write for Serial {
    fn write_str(&mut self, s: &str) -> core::fmt::Result {
        for &b in s.as_bytes() {
            transmit(b);
        }
        Ok(())
    }
}

Thanks in advance

I recently got a shiny new keyboard from https://shop.keyboard.io/ :)

I am truly loving the hardware, but given that all of the configuration is done in arduino c it makes me a bit sad. I have been spending some time looking into rust and enjoying the zero cost abstractions and the convenient type systems. This all got me thinking that I would really love to be able to program for my keyboard in rust. The existing firmware for it is highly plugin based which would be a great fit for rusts crate system and is currently pretty annoying to get working in arduino c/c++.

All of this lead me to this repo and organization. I am pretty new to arduino/avr programming however so I have a couple of questions.

First: How likely is using something like avr-rust on an arduino leonardo to be successful? Will I need to be extra careful with progmem when compared to a c version? Does rust have a large standard library which will take up too much space or is it relatively bare bones? My guess is that this is entirely up to me as I will have to recompile core anyways, but I'm not sure.

Second: What is the status of rust on avr. I saw a couple of threads in the main repo indicating that rust was updated to the correct version of LLVM, but I also saw that there are some outstanding bugs with LLVM which makes things difficult including i128 types not working. Are these insurmountable at the moment or is there a happy path for ignoring them?

Third: I saw a separate issue and pull request related to adding support for different boards, I think, this would be necessary for building firmware for my keyboard as it is based on the leonardo instead of the uno. Is this still something for which progress is being made or am I left in the dark?

I'm not sure if this is the correct place to ask these questions. Sorry if not. Clearly I am not super experienced with microcontroller programming, so any assistance in this project would be greatly appreciated!

It should be possible to do something like this

extern crate arduino;
use arduino::{Pin, HardwareSpi};
use arduino::cores::atmega328p;

trait Netlist {
    type PushButton: Pin;
    type Led: Pin;
    type Spi: HardwareSpi;
}

struct ATmega328p;

impl Netlist for ATmega328p {
    type PushButton = atmega328p::PORTB3;
    type Led = atmega328p::PORTB4;
    type Spi = atmega328p::SPI;
}

fn start<N: Netlist>() {
    N::PushButton::set_input();
    N::Led::set_output();
    N::Spi::setup_master();

   loop {
        // delay
        M::Led::set_high();
        // delay
        M::Led::set_low();
    }
}

This would allow users to easily mix-and-match supported microcontrollers, provided the microcontroller has enough GPIOs, etc.

The old llvm_asm! has been removed. Therefore, it doesn't compile on new rustc anymore.

In addition to this, an updated avr-delay dependency is needed to compile successfully: https://github.com/avr-rust/delay/pull/18

I can't seem to get documentation for any version newer than 0.1.2 because "docs.rs failed to build ruduino-0.2.0"

This seems to be the same issue as here: https://github.com/avr-rust/blink/issues/25, I did a quick test and was able to confirm build failure and was able to get it working using the same fix I suggested there (included below for your reference).

Cargo.toml

[profile.dev]
opt-level = "s"
debug-assertions = false

[profile.release]
opt-level = "s"

It never makes sense to call a function for these two instructions.

Additionally, I use this at system boot time to configure the stack pointer itself. If this becomes a function call, then everything is broken!

I don't seem to find a way to read analog input using this library. I suppose that it is either not currently supported or considered too high level for this library.

Is there an example on to achieve this (read and possibly write analog values) using Rust?

I was writing a small programs that uses the internal EEPROM of the ATmega328P, when I noticed that no writing was occuring. I was using

EECR::set(EECR::EEMPE);
EECR::set(EECR::EEPE);

to start writing to the EEPROM, but the memory was unchanged.

When I replaced the above code with the following:

EECR::write(EECR::EEMPE);
EECR::write(EECR::EEPE);

it worked like a charme.

I might be mistaken, but after digging through the Register code, I noticed that Register::set is not using volatile_write https://github.com/avr-rust/ruduino/blob/302095dca22f63a160d44c1fdcdc0fdf1db4072d/src/register.rs#L53-L57 while Register::unset, Register::write, etc are doing so. Is there a particular reason for this, that I may not understand yet? https://github.com/avr-rust/ruduino/blob/302095dca22f63a160d44c1fdcdc0fdf1db4072d/src/register.rs#L70-L74

Thanks!

Hi! I finally managed to build this project using the branch avr-use-correct-addrspace from https://github.com/dylanmckay/rust.git Now I have the .elf file, but how can I upload it to my arduino nano?

I’m trying to compile a basic program that blinks my ATmega328p, but whenever I compile my code I get the following error message:

error[E0557]: feature has been removed
 --> /Users/ryan/.cargo/registry/src/github.com-1ecc6299db9ec823/ruduino-0.3.2/src/lib.rs:8:12
  |
8 | #![feature(unwind_attributes)]
  |            ^^^^^^^^^^^^^^^^^ feature has been removed
  |
  = note: use the C-unwind ABI instead

This problem seems to be close to the #![feature(const_fn)] has been removed problem, but that could be solved by just removing the #![feature(const_fn)] line from the imported crate. Yet, If I delete the #![feature(unwind_attributes)] line, I’ll get the following error:

error: language item required, but not found: `eh_personality`

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

error: could not compile `avr-projects` due to 2 previous errors

When trying to compile an example program, I get this error from the ruduino crate:

error[E0557]: feature has been removed
 --> /home/ggsvr/.cargo/registry/src/github.com-1ecc6299db9ec823/ruduino-0.3.2/src/lib.rs:4:12
  |
4 | #![feature(const_fn)]
  |            ^^^^^^^^ feature has been removed
  |
  = note: split into finer-grained feature gates

I get another error from LLVM "Not supported instr", but I don't think they're related.

I'd like to configure a timer for CTC mode with polling instead of interrupts. Unfortunately, this is not possible at the moment because setting the comparator target is coupled with turning on interrupts:

    pub fn configure(self) {
        T::ControlA::write(self.a);
        T::ControlB::write(self.b);
        T::ControlC::write(self.c);

        // Reset counter to zero
        T::Counter::write(0u16);

        if let Some(v) = self.output_compare_1 {
            // Set the match
            T::CompareA::write(v);

            // Enable compare interrupt
            T::InterruptMask::set(T::OCIEA);
        }
    }

I think these should be exposed as two orthogonal features.

My Rust code is peak "I have no idea what I'm doing" territory so please feel free to improve especially the implementation of collect_register_bitfields

I'd like to use Rust to develop for the ArduBoy, which uses an ATmega32U4, which I believe is the same mcu as used on the Arduino Leonardo. So there should be quite a lot of boards out there using it.

Ruduino's core_generator chokes on the 16u4 and the 32u4 as-is because they have PDI and PDO pins in their SPI definition. I think these can be safely ignored as they are only used for in-circuit programming.

However, if we get over this hump, we get a more severe problem: registers that are defined "piecewise" at multiple locations in the packfile. For example, on the 32u4 ADCSRB is defined in two modules, in AC and in ADC. With core_generator's naive handling of registers, these end up as duplicate definitions in atmega32u4.rs:

#[allow(non_camel_case_types)]
pub struct ADCSRB;

impl ADCSRB {
    pub const ACME: RegisterBits<Self> = RegisterBits::new(0x40);
    pub const ACME0: RegisterBits<Self> = RegisterBits::new(1<<6);

}

impl Register for ADCSRB {
    type T = u8;
    const ADDRESS: *mut u8 = 0x7b as *mut u8;
}

#[allow(non_camel_case_types)]
pub struct ADCSRB;

impl ADCSRB {
    pub const ADHSM: RegisterBits<Self> = RegisterBits::new(0x80);
    pub const ADHSM0: RegisterBits<Self> = RegisterBits::new(1<<7);

    pub const MUX5: RegisterBits<Self> = RegisterBits::new(0x20);
    pub const MUX50: RegisterBits<Self> = RegisterBits::new(1<<5);

    pub const ADTS: RegisterBits<Self> = RegisterBits::new(0x17);
    pub const ADTS0: RegisterBits<Self> = RegisterBits::new(1<<0);
    pub const ADTS1: RegisterBits<Self> = RegisterBits::new(1<<1);
    pub const ADTS2: RegisterBits<Self> = RegisterBits::new(1<<2);
    pub const ADTS3: RegisterBits<Self> = RegisterBits::new(1<<4);

}

impl Register for ADCSRB {
    type T = u8;
    const ADDRESS: *mut u8 = 0x7b as *mut u8;
}

Currently this

$ AVR_CPU_FREQUENCY_HZ=8_000_000 cargo +nightly publish --target ./avr-atmega328p.json -Z build-std=core
    Updating crates.io index
   Packaging ruduino v0.4.0 (/home/gs0604/src/rust/RustAVR/ruduino)
error: failed to prepare local package for uploading

Caused by:
  failed to select a version for the requirement `avr_delay = "^0.4.0"`
  candidate versions found which didn't match: 0.3.2, 0.3.1, 0.3.0, ...
  location searched: crates.io index
  required by package `ruduino v0.4.0 (/home/stappers/src/rust/RustAVR/ruduino)`

I think the

  failed to select a version for the requirement `avr_delay = "^0.4.0"`
  candidate versions found which didn't match: 0.3.2, 0.3.1, 0.3.0, ...

means that https://github.com/avr-rust/delay/issues/21 has to fixed first ...

... similar to the current without_interrupts() helper.

What do you think about this?

I renamed the existing disable/enable API to with_irqs_disabled(). The new API for suspend/restore is with_irqs_suspended(). The old without_interrupts remains as deprecated alias.

I'm not so sure about the naming. Suggestions for better naming are welcome. :)

This is completely untested. Just for discussion.