16.5 MHz internal clock speed

[ivoras]

Hello,

The Digispark Digistump Android core has a special board definition (which is also their default) which uses a 16.5 MHz internal clock. Their code is here:

• https://github.com/digistump/DigistumpArduino/blob/master/digistump-avr/boards.txt
• https://github.com/digistump/DigistumpArduino/blob/master/digistump-avr/cores/tiny/wiring.c

The reason for doing this is that it works well for their libraries for USB communication. I've confirmed this by building a simple USB keyboard emulation sketch for ATTiny85 with ATTinyCore at 16 MHz and with their Digispark core at 16.5 MHz. The 16 MHz build desynces with USB after a couple of minutes, while the build with the Digispark core's 16.5 MHz works fine after a couple of hours. Both were programmed directly over ICSP, the Digispark USB loader was not used.

I don't know enough about USB to claim that that's the only difference - as those are very different cores - but it looks likely that the USB communication problems could be because of the frequency difference.

Would it be possible to have the 16.5 MHz clock option in ATTinyCore?

[SpenceKonde]

That code relies on the OSCCAL having been set for 16.5MHz by the bootloader previously... which in turn is derived from... the USB timing itself? https://github.com/micronucleus/micronucleus/blob/80419704f68bf0783c5de63a6a4b9d89b45235c7/firmware/osccalASM.S This is outside my area of expertise - to implement that, you'd need to do the same thing in this core as micronucleus does to figure out the right oscillator calibration from the USB clocks...

[ivoras]

I programmed the chip with the Digispark core with ICSP, which (unless I'm misunderstanding how it works) should mean it doesn't pull in the boot loader, right?

[SpenceKonde]

Does it work with the digispark core programmed by ICSP?

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: spencekonde@gmail.com

On Sun, Sep 1, 2019, 03:31 Ivan Voras notifications@github.com wrote:

I programmes the chip with the Digispark core with ICSP, which (unless I'm misunderstanding how it works) should mean it doesn't pull in the boot loader, right?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/ATTinyCore/issues/349?email_source=notifications&email_token=ABTXEW5H4XOTDYWZGWTC253QHNVTZA5CNFSM4ISMLTN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5T4NUI#issuecomment-526894801, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTXEW6HINEQVK2EMBJBMHLQHNVTZANCNFSM4ISMLTNQ .

[ivoras]

Yes, that's what I'm saying - I programmed both the ATTinyCore version (16 MHz) and the Digispark version (16.5 MHz) with ICSP. This is why I think it can be done.

[SpenceKonde]

So here's what they do... They START with F_CPU already set to 16.5MHz by the bootloader

 #if F_CPU != 16500000L
    if (OSCCAL != read_factory_calibration()) {
      // adjust the calibration down from 16.5mhz to 16.0mhz
      if (OSCCAL >= 128) {
        // maybe 8 is better? oh well - only about 0.3% out anyway
        OSCCAL -= 7;
      } else {
        OSCCAL -= 5;
      }
    }
  #endif 

I suspect the solution here is to do the opposite to get 16.5MHz

[sleemanj]

Haven't followed this discussion, but

F_CPU already set to 16.5MHz by the bootloader

F_CPU is a constant define passed into the compiler, it's not modified by the bootloader, see build.f_cpu in boards.txt of course for where it is set in Arduino-land.

[sleemanj]

Ok so a quick skim. The file @SpenceKonde linked to does appear to be what calibrates the oscillator (against USB frames)m this is in the bootloader. The calibration is also saved into flash just below the bootloader.

If you uploaded using ICSP but you did not perform an erase in doing so, then maybe you got lucky and that saved calibration byte was still there and got read by wiring.c. Second thought, no the saved calibration byte is only read by the bootloader again to avoid recalibrating each time, wiring.c only reads the default factory calibration when it doesn't want to use the special one (that is, for anything other than 16.5MHz), so unless you uploaded by ICSP and somehow the bootloader survived and was still called... it must be the second option below I can't think of any other way it worked.

It's also possible you just got lucky and your OSCCAL factory default was close enough to work just by setting F_CPU to 16.5Mhz without changing OSCCAL.

[ivoras]

I've tried with multiple chips, none of which were ever programmed with Digispark's bootloader, and in every case, the firmware bult with the Digispark's core managed to successfully maintain USB communication.

If it's not the frequency, maybe it's something else Digispark's core does.

[SpenceKonde]

How simple can you get the sketch to demonstrate this?

I'm wondering if there's some other library function that's causing the issue?

Also, using two boards that do not have a bootloader, one on my core at 16MHz, and the other at 16.5MHz with the digispark core, if you put blink on both of them, do they blink at the same speed, or do they slowly get out of sync with eachother (indicating that even though compiled for 16.5MHz, it's actually running at 16). If the F_CPU=16500000 part with their core blinks at the same speed as the F_CPU=16000000 part compiled with my core, that would imply that somehow, despite that, OSCCAL os getting nudged to run it at 16.5.

I would also test on my core if at the start of sketch, doing this fixes USB.

if (OSCCAL >= 128) {
    OSCCAL += 7;
  } else {
    OSCCAL += 5;
}

[ivoras]

The minimum sketch can be the Digispark example named "Keyboard":

#include "DigiKeyboard.h"

void setup() {
}

void loop() {
  DigiKeyboard.sendKeyStroke(0);
  DigiKeyboard.println("Hello Digispark!");
  DigiKeyboard.delay(2000);
}

But you'll need either a Digispark board for it or a custom board (as in my case) to run it.

I'll try and have 2 boards with different clocks, but I don't know how successful will that be since I can't ensure both of them get powered up at the same time.

[SpenceKonde]

I'll try and have 2 boards with different clocks, but I don't know how successful will that be since I can't ensure both of them get powered up at the same time.

You don't need to power them up simultaneously.. If they are drifting relative to eachother, sometimes they will blink the same time, sometimes they will blink at opposite times.

[SpenceKonde]

Were you able to perform either of the tests I suggested?

Does doing this:

if (OSCCAL >= 128) { OSCCAL += 7; } else { OSCCAL += 5; }

in setup() (with my core) change USB behavior?

[SpenceKonde]

I added this clock option, against my better judgement.