Skip to content
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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiling for ATmega4809; "no register group defined for this port" #33

Open
timwalls opened this issue Oct 26, 2020 · 2 comments
Open

Comments

@timwalls
Copy link

Hiya,

First of all, thanks all for all the work on Rust/AVR, it's awesome :).

Secondly though, I'm trying to get Rust working with the Arduino Nano Every board (electrically (and cost-wise) it's perfect for my project), which uses the ATmega4809 chip...

It turns out this is quite tricky and I've been going round in a few loops, but right now I'm stuck at getting ruduino to build. avr-mcu seems to load the packfile OK, but ruduino doesn't like what it sees:

[Sasha:rust/rust-arduino-blink] timwa% cargo build
   Compiling rustc-std-workspace-core v1.99.0 (/Users/timwa/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling ruduino v0.2.6
   Compiling compiler_builtins v0.1.35
error: failed to run custom build command for `ruduino v0.2.6`

Caused by:
  process didn't exit successfully: `/Volumes/Development/Arduino/rust/rust-arduino-blink/target/debug/build/ruduino-1f365ea4228ae98b/build-script-build` (exit code: 101)
  --- stdout
  loading pack '/Users/timwa/.cargo/registry/src/github.com-1ecc6299db9ec823/avr-mcu-0.3.4/packs/atmega/ATmega4809.atdf'

  --- stderr
  [warning]: cannot find target JSON file 'atmega4809.json' - due to limitations it needs to be in the crate root - is it?
  [warning]: assuming a target CPU name of 'atmega4809' from the file name of the target spec JSON file
  thread 'main' panicked at 'no register group defined for this port', /Users/timwa/.cargo/registry/src/github.com-1ecc6299db9ec823/ruduino-0.2.6/core_generator/gen.rs:65:22
  stack backtrace:
     0:        0x1044d20a4 - std::backtrace_rs::backtrace::libunwind::trace::hb4ff9014ec5817b3
                                 at /rustc/7bade6ef730cff83f3591479a98916920f66decd/library/std/src/../../backtrace/src/backtrace/libunwind.rs:100:5
     1:        0x1044d20a4 - std::backtrace_rs::backtrace::trace_unsynchronized::h0d03cf0f7c5d8d01
                                 at /rustc/7bade6ef730cff83f3591479a98916920f66decd/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
     2:        0x1044d20a4 - std::sys_common::backtrace::_print_fmt::h5b2bf2921eea85ae

Before I start digging too deep attempting to work out the problem myself, does this seem to have an obvious cause to anyone (and thus an obvious solution? :-D.)

Thanks in advance,
Tim

@harpekar
Copy link

I'm getting a similar error trying to compile for the atmega32u4, did you figure out what's going on?

@timwalls
Copy link
Author

timwalls commented Dec 1, 2020

Hey, hi.

To be honest, I gave up with ruduino - I was making no progress. I switched to @Rahix's Rahix/avr-hal, which seems to be under more active development, at least for devices other than the standard '189.

In the case of the 4809, smarter people than I are already working on it, but even without that being ready yet I found it much easier to adapt the underlying Rahix/avr-device package to get something working.

If anyone comes to this wondering about the ATmega4809/Nano Every in particular - you can find a fork of avr-device/avr-hal which at least gives you basic working pin access at timwalls/avr-device:ATmega4809 and timwalls/avr-hal:arduino-nano-every respectively. I've not done anything about getting things like UARTs working yet because, as I say, other smarter people are working on that and eventually I expect to go back to the mainline once 4809 support is rolled in. But even if that doesn't happen, I'm confident this is a much easier place to start getting those things to work than ruduino.

For your specific needs @harpekar, it looks like avr-device/avr-hal already has ATmega32u4 support in there - so I'd definitely suggest taking a look there :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants