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

Add support for ATmega8 #384

Merged
merged 8 commits into from
Feb 23, 2023
Merged

Add support for ATmega8 #384

merged 8 commits into from
Feb 23, 2023

Conversation

Rutherther
Copy link
Contributor

@Rutherther Rutherther commented Dec 23, 2022

Adds support for ATmega8 (Rahix/avr-device#112 has to be resolved first for this to work correctly).

ATmega8 is more challenging in some ways, because it does not work like the atmegas that were already implemented

  1. EEPROM does not have modes (erase, erase and write), completely different mechanism is required.
  2. WDT registers have different names "s" is missing from wdtcsr.
  3. Does not have DIDR for ADCs
  4. USART does not have "0" at end. It's just USART, not USART0. It has registers UBRRL, UBRRH instead of just one UBRR. I don't think it's possible to merge into just one register using patches as the UBRRH is shared with UCSRC and it's not directly next to UBRRL.
  5. WDT does not have the same prescalers. It also does not support 4k ms and 8k ms. The rest of the prescalers does not exactly match the values.

My current solutions

  1. I implemented a new macro that is named impl_eeprom_atmega_old. I am not sure if this name fits.

  2. I added paste macro and passed in a string name of the register

  3. I created a no_didr macro that does not contain anything in the relevant method. I don't think there is anything else to be done in that method, but I may be wrong here. I have not used ADCs that much.

  4. as ATmega8 looks very specific regarding USART, I decided to not even create a macro, but instead implement it directly in atmega-hal/wdt.rs. There is a few differences to usart macro, namely UCSRC and UBRRH are functions, UCSRC has to have set URSEL to one (that says UCSRC should be set instead of UBRRH as they share the same location in memory). UBRR is set by UBRRH and UBRRL instead of just UBRR.

  5. I have used the closest values and put panic!() to 4k ms and 8k ms. I think there should be a better solution than this...

What do you think about these changes? Do you have better idea how to implement ATmega8?

I have tested EEPROM, USART, ADCs (and using ports of course) so far. I will try to test the rest in short time.

@Rahix
Copy link
Owner

Rahix commented Jan 5, 2023

I released a new version of avr-device (0.5.0) and already updated avr-hal for it (#389). Your ATmega8 patches are included in the release. You can rebase your commits ontop of latest main to move this PR forward.

@Rahix Rahix linked an issue Jan 5, 2023 that may be closed by this pull request
This was referenced Jan 5, 2023
@Rutherther
Copy link
Contributor Author

Rutherther commented Jan 5, 2023

Thank you for that.

You can rebase your commits ontop of latest main to move this PR forward.

So, this PR is functionally already done. The thing is that I am not happy with the design choices I made, do you have any better idea on how to proceed?

I am mainly not happy about the watchdog panic!()'s and usart without a proper macro.

Copy link
Owner

@Rahix Rahix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, sorry for only getting back to this PR now... Thanks for your work on ATmega8 support, anyway!

I've left some comments below, regarding the design topics you mentioned. For USART I do not see a great solution right now either, especially considering additional requirements which now came up for ATmega128A in #397...

mcu/atmega-hal/src/wdt.rs Outdated Show resolved Hide resolved
avr-hal-generic/src/wdt.rs Outdated Show resolved Hide resolved
avr-hal-generic/src/adc.rs Outdated Show resolved Hide resolved
mcu/atmega-hal/src/usart.rs Show resolved Hide resolved
mcu/atmega-hal/src/usart.rs Outdated Show resolved Hide resolved
@Rahix Rahix added the mcu-support Support for a new Microcontroller label Feb 23, 2023
@Rahix Rahix marked this pull request as ready for review February 23, 2023 03:08
@Rutherther
Copy link
Contributor Author

Rutherther commented Feb 23, 2023

Thank you for these comments, it's no problem at all that you could get to this PR now and not sooner. I think I have made all the changes you suggested.

@Rahix Rahix self-requested a review February 23, 2023 22:45
Copy link
Owner

@Rahix Rahix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mcu-support Support for a new Microcontroller
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support of Atmega8
2 participants