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

Support external clock on 48/88, document external clock for other parts #355

Closed
prandeamus opened this issue Oct 2, 2019 · 9 comments
Closed

Comments

@prandeamus
Copy link

I have an ATTINY88 board with a 16MHz external clock in hardware. I can install the ATTinyCore in Arduino and program it via a USBISP, but there seems to be only the option to use the internal clocks at 8MHz, 1MHz or the WDT. This does seem a little restrictive, can support for external clocks be added for this kind of arrangement?

(As it happens the board in question is described here. http://mh.nodebb.com/topic/47/mh-et-live-tiny88-16-0mhz. The manufacturer does provide what is 16MHz support, apparently, with its own configuration specific to that board, but insists I use the Micronucleus bootloader. I would prefer to use ISP programming given the option).

It's not a deal-breaker but will you be adding support for external clocks on the ATTINY88?

@SpenceKonde
Copy link
Owner

Historically, the reason that there is no "external clock" option is that if an external clock is selected without one being present, the chip will be soft-bricked, and unprogramable until a clock is supplied. Since the external clock is almost never used in arduino-land (this is the first case I've heard of where a hobbyist-targeted dev board used the external clock), I felt that an "external clock" option amounted to a trap for the unwary to brick their boards. This is also why I don't have options for reset pin as GPIO.

With the developments on megaTinyCore, where in the next release I will be putting out a version of the core which has an option that can brick a chip such that it requires HV programming to recover, I need to revisit how I present these "dangerous" options to users; my tentative plan is to include a warning in the menu entry, for example:

16MHz external clock (danger - see docs)

I welcome feedback on how to present this option while minimizing the risk of unwary users accidentally bricking their parts and then complaining to me. You would be surprised how often users contact me and say that they have tried every option from a tools submenu without any clue what the option means (essentially "I don't know what the correct option is, so I tried every option, but none of them worked", almost universally in situations where the menu in question was entirely unrelated to the issue at hand).

@SpenceKonde SpenceKonde added this to the 1.3.3 release milestone Oct 3, 2019
@SpenceKonde SpenceKonde changed the title Support for ATTINY88 with 16MHz external clock? Support external clock as clock source Oct 3, 2019
@SpenceKonde
Copy link
Owner

Renamed issue to reflect the scope of this change, as I don't think it makes sense to limit this to 16MHz on the ATTiny88.

@prandeamus
Copy link
Author

Thanks for the thoughtful feedback. Users can be dumb as rocks sometimes, as well as charming and wise. And you don't want to have too many traps for the unwary. I am still a novice myself.

Tech question #1 Is this different from the Attiny25/45/85 clock options, where external clock options do appear? I presume the possibility of soft-bricking is there too.

I guess there's no easy way for an MCU to determine the clock rate of an attached source while running on the internal clock? You'd have to set the fuses for (say) 8MHz operation and use the clock source pin as an input. Given that the internal clock is likel slower than external clocks, you would not get even close to measuring the input frequency in a way which was accurate and cross platform.

If you wanted a warning, can you configure Arduino to put up an "This will brick your MCU if you don't have the clock rate that you promised dialog?" That would be a start but yeah, some people will ignore it. OR how about displaying I dialog to say "I won't program the fuses for you but you can set the avrdude command line like this..... but take responsibility!!!"

On the whole maybe it's best left as it is!

@prandeamus
Copy link
Author

I may have answered my own question - Attiny 25/45/85 is a crystal not a clock?

@SpenceKonde
Copy link
Owner

That's correct - and this points to yet a further complication in communicating this - until now, "external" was used to describe external crystal, and the external clock option wasn't present (and as it happens, the external crystal fuses work with an external clock too - though setting the fuses for external clock is needed to make the other crystal pin available as GPIO).

And as I think about it more - for all parts other than the x8 and the 43 (for which nobody would want to use an external clock source - it's a part that is very unappealing unless you want to run it off a single alkaline battery, in which case using an external clock source would be very strange), using an external clock would be a matter of choosing the external crystal option with the desired speed when compiling/uploading, but using avrdude manually to set the fuses instead of "burn bootloader". So maybe we don't need to add support for that to normal parts, but just add a description of what to do, so that the few advanced users who need external clock can do that. But on the 48/88, since it doesn't support external crystal, there's no option to compile for speeds that aren't supported by the internal oscillator. So that brings the scope back to the 48/88, and expanded documentation.

I can't make a dialog box appear - the only customization I can do of the IDE is changing the name of the option in the menu, and changing options within the board/platform configuration based on that.

@SpenceKonde SpenceKonde changed the title Support external clock as clock source Support external clock on 48/88, document external clock for other parts Oct 3, 2019
@sleemanj
Copy link

sleemanj commented Oct 3, 2019

FWIW, this is how I do it in my fork, menues which override the defaults which are initially put in place by the "Processor Speed" menu.

umu13

umu15

umu14

SpenceKonde added a commit that referenced this issue Oct 7, 2019
SpenceKonde added a commit that referenced this issue Oct 7, 2019
Optiboot bootloaders need to be built for the newly supported clock speeds. 
Impacted parts are 48, 88, 828 - the parts with no crystal support. 
Also discovered and fixed a bug relating to burn bootloader with ULP on 828.
@SpenceKonde
Copy link
Owner

This should be working in the github version now (though no optiboot bootloader hex files yet - I'll get those built later tonight).

@prandeamus
Copy link
Author

I took a look at the documentation and it looks clear enough. As luck would have it, my programmer has just died so I can't try it out just yet. I am impressed by your speed, though, and your thoughtfulness.

@SpenceKonde
Copy link
Owner

Pending Travis results, this should now be sorted.

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

No branches or pull requests

3 participants