Hello everyone, I have a problem with a basic blink program (LED on and off after one sec.) The problem is that the LED is turning on and off much slower (like 4 sec). I’m guessing that I did not configure the platformio.ini file correctly? The setup is an ATmega 328 P (internall 8MHz osc.) and USBtiny as programmer.
Here is the platformio.ini:
[env:program_via_USBtinyISP]
platform = atmelavr
board = ATmega328P
upload_protocol = custom
upload_flags =
-C
; use “tool-avrdude-megaavr” for the atmelmegaavr platform
$PROJECT_PACKAGES_DIR/tool-avrdude/avrdude.conf
-p
$BOARD_MCU
-c
usbtiny
-Ulfuse:w:0x62:m ;fuses for 8mhz internall
-Uhfuse:w:0xd9:m
-Uefuse:w:0xff:m
upload_command = avrdude $UPLOAD_FLAGS -U flash:w:$SOURCE:i
I’ve added board_build.f_cpu = 8000000L but it did not help.
Any help would be much appreciated. Cheers!
I’ve got a couple of “Normduinos” running crystal free on the internal 8 MHz oscillator. My fuses are set to the following:
low=0xE2
high=0xDA
extended=0x05
By the way, the default Arduino extended fuse setting is incorrectly setting the BOD level to a voltage incompatible with the board running at 16 MHz! The system will have crashed, most likely, before BOD kicks in.
My settings are very different to yours which appear to be the factory defaults, and as such should give you the 8 MHz oscillator. However, the default fuses also enable the CKDIV8 divide clock by 8 option, hence your problem.
Try my settings which will give you:
Low Fuse
SUT0
CKSEL3
CKSEL2
CKSEL0
High Fuse
SPIEN
BOOTSZ1
BOOTRST
Extended Fuse
BOD LEVEL 1
But absolutely no divide by 8!
Cheers,
Norm.
Thank you so much! Plus very informative about the BOD. Could you tell me what UART speed does the 8 MHz internal osc support? 
Sorry for the late feedback I was on a road trip.
Hi @aleksandar.jevtic666
no worries on the delay, not a problem.
The USART is mostly hidden when using the Arduino Language. The internals of the USART are very definitely hidden!
However, there is a register (UBRR0) which is used to calculate the baud rate as follows:
(F_CPU / (8 * baud)) -1
The 8 is for high speed transmissions, in low speed, it uses a 16 instead. I’ll stick with low speed here.
So the baud rate is calculated based on the CPU frequency. The result of the calculation must fit into 12 bits as the top 4 bits of the (16 bit) UBRR0 register are ignored.
TL;DR: You should be fine with whatever baud rate you want as everything is based on the CPU clock speed.
HTH
Cheers,
Norm.
1 Like
Update: This image is taken from the data sheet and shows the UBRR0 setting for the various baud rates. You need to avoid all those where the error percentage is higher than 0.5% or more negative that -0.5%.
The last columns (where U2Xn = 1) are used by the Arduino unless the CPU frequency is 16 MHz and the baud rate selected is 57600, whereupon it switches to the columns with U2Xn = 0 instead. It also does this if it calculates a UBRR0 which is higher than 4095, as the UBRR0 register is only 12 bits.
HTH
Cheers,
Norm.
1 Like
Hm, I’ve seen this but never quite understood why? But this explains it.
1 Like
A further update on this.
I’ve written some USART code for a new book I’m writing and all baud rates tested, except 115200, worked perfectly. 115200 produced complete garbage on the monitor.
I was originally sticking with low speed, and at low speed, 115200 has an error percentage of 8.5% – way above the recommended 0.5%. I amended the code to use high speed, where it could, and 115200 works fine now.
At high speed the table above gives an error percentage -3.5%, still way above advisable limits, but it works.
Comms are “fun”! 
Cheers,
Norm.
1 Like
Well I am certainly looking forward to that book. 
Will you be posting the release on some topic here on the Platformio site? Good luck! 
Thanks for the good luck wishes. I’ve been writing for about 18 months. My previous book was over two years.
I might mention the new one, if it ever gets finished, if it is relevant but I won’t be spamming the forum!
Cheers,
Norm.
1 Like
