Add atmega164pa support

[tronje]

This requires a bump of the avr-device dependency, which is not included here. Also specifically depends on Rahix/avr-device#139

[Rahix]

Commit 1a0040d bumped avr-device so now the ATmega164PA should be available.

[tronje]

Commit 1a0040d bumped avr-device so now the ATmega164PA should be available.

Thanks Rahix! I've fixed the first commit of this series to use the changed definition of avr_hal_generic::impl_port_traditional!, and I re-ran avr-specs/sync-from-upstream.py atmega164pa and fixup'd the second commit of the series.

I'd say this is now ready for review and, if you have no comments, to be merged.

[LuigiPiucco]

Hi @tronje, I'll take this opportunity to ask about avr_hal_generic::impl_port_traditional!, since you had to adapt your PR to it. What do you think about the re-design, and about applying the same ideas to the other modules? I ask because I plan to continue refactoring (#457 is up as we speak), and having feedback is always good.

[tronje]

Hi @tronje, I'll take this opportunity to ask about avr_hal_generic::impl_port_traditional!, since you had to adapt your PR to it. What do you think about the re-design, and about applying the same ideas to the other modules? I ask because I plan to continue refactoring (#457 is up as we speak), and having feedback is always good.

I like it, it's a lot more concise than before. Based on existing usage of the macro, it was easy to figure out what I needed to do. Maybe a short explanatory doc comment with an example would be nice to have, anyway.

I should point out that I may not be the best person to quiz about this. We just needed support for the atmega164pa, I don't have particularly good knowledge of avr-hal.

In any case, thanks for your work 🙂

[tronje]

@Rahix friendly ping 🙂

I've rebased this onto the latest main branch.

[Rahix]

Thanks for the ping and sorry for my slow responses...

Code looks good, thanks a lot!

I do see your EEPROM fix. I think we should merge it to ensure the EEPROM code is not completely wrong but I'd like to understand why the current implementation is broken... Do you have any insight into this?

[tronje]

Thanks for the ping and sorry for my slow responses...

No worries!

Code looks good, thanks a lot!

Thanks 🙂

I do see your EEPROM fix. I think we should merge it to ensure the EEPROM code is not completely wrong but I'd like to understand why the current implementation is broken... Do you have any insight into this?

Unfortunately, not really. All that I do know, I know from #406.

[Rahix]

Unfortunately, not really. All that I do know, I know from #406.

Fair enough, then let's merge as is and look more into the EEPROM topic another time.

[tronje]

Thanks @Rahix! Really appreciate your work 🙂