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

Question: 3.3V vs. 16Mhz crystal #11

Open
lanmarc77 opened this issue May 14, 2019 · 7 comments
Open

Question: 3.3V vs. 16Mhz crystal #11

lanmarc77 opened this issue May 14, 2019 · 7 comments

Comments

@lanmarc77
Copy link

Hi,
the schematics state that the Lora Mini is running with a 16Mhz crystal and the module is powered by 3.3V. The datasheet of the Atmega328p states under speed grades that for 16Mhz a minimum of 4.5V are needed. While it still might work it seems out of the specified range and might not work under e.g. different temperature/pressure conditions. Isn't it?

@lanmarc77
Copy link
Author

After analyzing a factory default module I can confirm that the module is used outside of specification if you use VCC lower than 4.5V. As the lora module can only handle 3.9V the module can not be operated according to specification.
This is a pretty heavy design flaw.
It can be fixed though. One needs a programmer e.g. an mkII and enable the CKDIV8 fuse. This will lower the cpu clock frequency by 8 to 2Mhz. You then need to upload your sketches with 14.400bps or you upload a different bootloader e.g. mighty core. When using an external programmer like the mkII make sure you pull the NSS line high, as the lora module shares the SPI pins with the atmega328p. I was able to reprogram the bootlader and fuses and could successfully work with low voltages.
If you need more processing power you could increase the clock speed right after your program starts to a fitting prescaler and VCC needs.

@Donderda
Copy link

Donderda commented Jun 7, 2019

That’s really heavy.
By reprogramming and setting the fuse: do you mean the atmegas CKDIV8 fuse? I was going to use the atmega328 with the internal 8Mhz crystal. Do you have any experience with this constellation?

@lanmarc77
Copy link
Author

@Donderda Yes the atmega fuse. This division by 8 also applies to the internal RC oscillator. So you get 1MHz at bootup. Your program could then increase the clockspeed e.g. to 4 Mhz by changing the clock prescaler to 2. This will be in specification until 1.8V and allows maximum CPU power.
The RC oscillator precision is not very good though. Especially if used in different temperature environments (e.g. outside). I always used an external crystal. You would need to test if the precision is good enough to fit to the LoRaWAN specifications. It isn't if downlinks are not working which includes OTAA.

@Donderda
Copy link

Donderda commented Jun 9, 2019

A great, thank you for your hints, they will surely help me :-).

If I got this correctly, I will have to:

  • use an external crystal (e.g. 8MHz) (it will be placed outside, battery powered)
  • burn the minicore with fitting settings (external 8Mhz)
  • change the fuse with an programmer
  • in my sketches I will somehow increase the clockspeed in my setup() routine
  • use my code as before
  • ...
  • Profit!

Thank you again for your help 😊

@lanmarc77
Copy link
Author

Almost.
If you choose to set/program the CKDIV8 fuse I suggest you use a bootlader that already works with the resulting CPU clock. For an external 8Mhz crystal this would then be a bootlader with 1Mhz.
If you choose to increase clock speed later in your program you might get a problem (depending on your program). The Arduino IDE takes the macro F_CPU from the boards.txt, where also the upload speed is defined. This macro tells all libraries what the actual clock speed of the controller is. All the libraries are then compiled (based on your example) with a clock speed of 1Mhz (millis(), Serial.begin(xx)...). Clock speed needs to be known as it needs to be used for calculating the prescalers for timers and uarts and...
So if you then increase clock speed later in your program lets say to 2Mhz millis() will run double as fast as it was compiled with timer prescalers based on 1Mhz.
If that is the case for your example you need to make a new entry in the boards.txt for your specific setup.

@Donderda
Copy link

Donderda commented Jun 9, 2019

Ah thank you for your clarification!

So my approach was correct, but I don’t need to increase the clockspeed manually in my code, right?

@lanmarc77
Copy link
Author

No it is not neccessary if 1Mhz is enough for you. It certainly avoids a lot of additional work.

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

No branches or pull requests

2 participants