The debug monitor / serial connection works with 57600 instead of 115200,
Same with the upload - I had to update boards.txt to half the bit rate.
Things that run based on clock cycles like SPI or IIC work
The "Delay" command - does not delay by the programmed time, but twice as much.
This is not completely unexpected for me, although I had hoped for an internal logic, which reduces the "wait"-cycles by 50%, if Arduino runs with 8 instead of 16 MHZ.
But currently I have to consider this:
If I want to let 328p sleep for one second, I have to encode a delay of 500 ms.
If I have a "Serial.begin(115200);" in the program, this means 57600 external.
Hmm.
How do I get 328p to run at 8 MHz on one side but behave normally on the other side?
Use a core which supports 8 MHz clock, like MiniCore - that is a much better method than what that ArduinoToBreadboard guide describes (it also omits necessary components and depicts poor part placement. It's as if they had a vested interest in people not rigging up their own Arduino boards or something!
Thanks for the hint using the Minicore .
I'll give it a try for sure.
The link
has a sibling
Two issues prevented me from following it.
How does a bootloader influence the timing of e.g. the delay command?
On 16 MHz system it has to delay for 16 M clock cycles, in an 8 MHz system it has has to delay for 8 M only.
How does a bootloader influence the timing for serial connection and brings it to the value in Serial.begin()?
Optiboot is a small one. 512 bytes- great. Considering program size I have just 1.5 K left.
Let us assume, I deploy my programs to Breadboard Atmel without Bootloader, via SPI using "ArduinoISP".
What is the experienced way to deal with the timing issue?
Additional Options in the boards.txt, may be?
Martin, please believe us. Forget the software/firmware aspects of those tutorials. Use minicore. Problems gone.
But to answer your questions:
The bootloader does not fix the timing issues, the Arduino core does. You are trying to use an Arduino core, designed for a chip running at 16MHz, at 8MHz. The Arduino core is a set of functions that hide the differences between different speeds, even different mcus, from the Arduino user. The Arduino core makes delay() or digitalWrite() work apparently the same on an atmega328 at 16MHz or 8MHz, or an ATtiny85 at 1MHz, or an esp8266 at 80MHz. Each chip and speed needs a slightly different core. The Minicore boards package contains cores for various atmega chips like 168, 328, 328P, 328PB at various speeds like 1MHz, 8MHz, 16MHz, 20MHz. You just select the right chip and desired speed, hit Burn Bootloader, and it sets the appropriate fuses, installs the correct bootloader and sets up the appropriate core ready for your sketch.
Sounds like you are confusing ram memory with flash memory. Atmega328 has 2K ram memory and 32K flash memory. The bootloader lives in the flash memory. The ram memory contents are lost when you disconnect the power or press reset. Flash memory is normally only written when you upload your sketch or burn a new bootloader, and retains its contents when there is no power.
Thanks.
In first step I followed an own idea, at a second stage I used minicore.
Both works.
I fixed the problems on my own primarily by a modification of
e:\ProgramPortable\arduino-1.8.10\hardware\arduino\avr\board. txt, arduino section, changing
It fixed all my problems with internal timings and sleep and interface speed.
The
uno.upload.speed=115200 --> uno.upload.speed=57600
is of still required, but no surprise, as long no one changes the bootloader
MINICORE
I first tried the "Manual Installation" but it seems the instruction is not valid anymore or not valid to my environment.
It asks to copy to
~/Documents/Arduino/hardware, what was at least on my end of no success. Boardmanager installed it to
~\AppData\Local\Arduino15\packages\MiniCore\
MiniCore boards menu looks great!
The only thing, upload tried an 38xxx speed. I changed it to 57600 in boards.txt, done.
Having LTO enabled, it looks like this:
Sketch uses 27182 bytes (84%) of program storage space. Maximum is 32256 bytes.
Global variables use 1653 bytes (80%) of dynamic memory, leaving 395 bytes for local variables. Maximum is 2048 bytes.
Questions:
Assuming the bootloader is "a well adapted to clock frequency" one, it should be possible to have uploads "always" with 115200?
Minicore uses a modified version of optiboot, and for the atmega328 should be 512 bytes, same as the default bootloader. The fact that you have a maximum of 32256 bytes of flash memory available for your code, out of the actual 32768 bytes, would imply that 512 bytes are reserved for the bootloader.
Since you obviously have the ability to burn the bootloader, minicore will let you choose "No bootloader", making all the flash memory available for your code, but requiring an ISP programmer to load the code.
There are a few clock frequencies that do not have 115200 baud available in the pre-compiled bootloaders, the minicore boards.txt file has a chart in the comments detailing what is available. The baud rate is derived from the system clock, so any inaccuracies in the clock frequency will affect the baud rate, the timing generally be more critical at higher baud rates.