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 internal-clock feature #443

Closed
wants to merge 1 commit into from
Closed

Add internal-clock feature #443

wants to merge 1 commit into from

Conversation

maxkofler
Copy link

This feature allows to use the 'internal-clock' feature to define a lower clock speed.

@Rahix
Copy link
Owner

Rahix commented Apr 1, 2024

Hi, thanks for the contribution and sorry for the very late response...

This is an interesting idea, but I do wonder why you would need this? The boards have a crystal of the defined frequency, why would you not want to use it?

Is this about supporting the use of a bare microcontroller instead of an Arduino/SparkFun/etc. board? If yes, you should not be using arduino-hal in the first place - you should use atmega-hal directly (see #524).

@maxkofler
Copy link
Author

Hi,

Basically, it is indeed about supporting bare microcontrollers, yes. The main reasoning behind this is that there are certainly some people that start out working with a fully integrated Arduino board for development but switch to a custom board or setup.

But as I see, there isn't that much interest in that feature, so I don't know about the importance of merging it.

This feature allows to use the 'internal-clock' feature to define a
lower clock speed.
@maxkofler maxkofler changed the title Add 'internal-clock' feature Add internal-clock feature Apr 1, 2024
@Rahix
Copy link
Owner

Rahix commented Apr 1, 2024

start out working with a fully integrated Arduino board for development but switch to a custom board or setup

Hmm, that is an interesting situation. In an ideal world, people would then rebase their application onto atmega-hal. But I know just as much as you do that most people won't...

My problem is that I don't really see what we can do about this:

  • On one side, I really don't want to encourage the "wrong" behavior by providing things that make it easier. The right things to do should always be the path of least resistance.
  • On the other side, it isn't really possible to make a switch from arduino-hal to atmega-hal simpler to perform. arduino-hal is supposed to hide some things from you by design, to allow quickly getting started with rust-on-arduino projects. These things need to be added manually when working with atmega-hal directly.

I guess the only thing that is left is providing much better documentation on how such a transition could be performed.

@maxkofler
Copy link
Author

I totally agree with you in that people should rebase on atmega-hal, which is the obvious thing to do in my opinion, too.

After some thinking, I think, we should assume that once someone is on the level of building a custom board / circuit, he should be able to work with atmega-hal. Using the internal clocks on AVRs requires programming fuses, which requires some knowledge by itself, so one should be able to make the switch.

I do not want to force changes onto this project that make no sense, so I will abandon this PR.

@Rahix
Copy link
Owner

Rahix commented Apr 2, 2024

In any case, I've opened #532 for documenting these things.

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

Successfully merging this pull request may close these issues.

2 participants