atmega328 (no p) support?

[cherrydev]

I'm uncertain if this omission is because nobody (else) has wanted to use rust with one or that there's no need for explicit support because it is so similar to the 328p? I guess I'm particularly surprised because the vanilla atmega328 is the only atmega with built-in support for the (nightly) toolchain. Is there some simple configuration option that would allow me to use this chip with rust libraries that depend on avr-device? In particular I'm wanting to use atmega-hal. I apologize if the solution to this is obvious and trivial but I'm new to rust and wanting to try it with a MC project.

[Rahix]

From my understanding, the ATmega328P is essentially the successor to the ATmega328 so there aren't many reasons to explicitly choose the older one. From a programming perspective, you won't find a difference for any normal application. So just build for ATmega328P, it will work just fine on ATmega328 as well.

[cherrydev]

The information I’d been reading had been clear that while atmega328 compiled code was guaranteed compatible with ‘P’ variants the reverse was not true since they had a few extra instructions, but I will give it a try. I did go through the process of forking my own copy of avr-device and following the instructions on how to add a new chip and after some struggles I did eventually get it working under the atmega_hal. That said, I’ve been struggling to figure out even simple stuff such as the console ( atmega_hal::usart::Usart0<atmega_hal::clock::MHz8> results in errors about missing traits ) so it's definitely going to be easier to treat it as an arduino (with an 8Mhz clock speed). That said, I've already made the additions to avr-device for the atmega328. Should I make a PR for it?

[stappersg]

On Thu, Apr 13, 2023 at 11:55:55AM -0700, cherrydev wrote:

.... That said, I've already made the additions to avr-device for the atmega328. Should I make a PR for it?

That is up to you :-)

Just posting the URL of the git clone (and branch) would be "good enough"

Groeten Geert Stappers -- Silence is hard to parse

[cherrydev]

It's at #125

[stappersg]

On Thu, Apr 13, 2023 at 12:31:18PM -0700, cherrydev wrote:

It's at #125

So this issue can be closed?

Groeten Geert Stappers -- Silence is hard to parse

[cherrydev]

Sure!

[Rahix]

No, let's not close this issue yet.

The information I’d been reading had been clear that while atmega328 compiled code was guaranteed compatible with ‘P’ variants the reverse was not true since they had a few extra instructions.

Ah, sorry, I missed this while checking the datasheet yesterday. It's been a while since I looked into this stuff more closely.

But these two additional instructions seem to be the only relevant difference, so I think the only change that is really necessary is adding a new spec file in the avr-hal repository.

I'm not in favor of adding the ATmega328 as a separate chip in avr-device - the crate is already quite huge and the generated register structs are just duplication of the ones for ATmega328P (except for the BODS and BODSE bits in MCUCR). I'd be open to add some sort of module&feature alias for the other name, though.

[cherrydev]

Just to make sure I have this clear: the specs from avr-device don't have anything to do with the specific instruction set of the avr devices, so therefore if aliased there isn't risk of a compiler suddenly generating the 'P'-specific instructions on a 'non-P' chip as long as whatever compiled code has the correct CPU target selected?

[Rahix]

yes, avr-device just defines the peripheral register layout as of now. The instruction set is "chosen" as part of the target you build for. And that's defined by the json-target files here: https://github.com/Rahix/avr-hal/tree/main/avr-specs

[Rahix]

Added the target spec for ATmega328 over in avr-hal: https://github.com/Rahix/avr-hal/commit/aed6b9a08eba96e64cb6816d9f1ef4b774a0ea96