#avr Logs

Aug 06 2019

01:36 AM rue_bed: what value worked for what baud rate?
01:41 AM rue_bed: cause, you need to be sure of your clock rate
03:55 AM Smidge204: rue_bed: Final values are BAUDH = 0x00, BAUDL = 0x93
03:57 AM Smidge204: Which is 1.296875 if I'm doing the fractional part right. The math says it should be 144.171875
08:30 AM rue_bed: hmm
08:33 AM Thrashbarg: hmm?
08:38 AM Fuchikoma: indeed
08:49 AM Fuchikoma: rue_bed: (I'm Smidge204 at another location, BTW) this is the table I came up with last night based on calculated and measured frequencies. It's kind of all over the place and I'm not really sure what the issue is.
08:50 AM Fuchikoma: Nothing explains the huge dsiparity in the final and calculated values in the BAUD register, though.
09:44 AM cehteh: did you verify that your chip runs really at the desired frequency?
09:47 AM Fuchikoma: Nope
09:48 AM cehteh: thats most likely the case
09:49 AM cehteh: you know that by default the clkdiv/8 fuse is in effect, dividing the main clock by 8
09:49 AM Fuchikoma: I should* have overridden that
09:51 AM Fuchikoma: Based on bigbanging the peripheral clock was 347KHz which is close to the theoretical 333kHz for 16MHz main and 48x prescale. That's nothing like the settings I was actually trying though
09:51 AM cehteh: i usually add some startup code that changes the prescaler (better than relying on fuses)
09:51 AM Fuchikoma: I tried BOTH!
09:52 AM cehteh: make some loop with definitive delay, meaure that
09:52 AM Fuchikoma: That's exactly what I did, effectively
09:53 AM Fuchikoma: https://i.imgur.com/hWRp1CP.png Columns A thuogh E are based on the datasheet's formulas. Column G is measured from bitbanging one of the pins and everythnig to the right of that is calculated based on that
09:53 AM cehteh: well then i dont know any other case, usually baud rate cacls are correct here, the only problem are these clocksource fuckups
09:53 AM Fuchikoma: Yeah it's really wild
09:54 AM cehteh: you did asm only or C?
09:54 AM Fuchikoma: asm
09:56 AM Fuchikoma: I used a string of SBI/CBI instructions to toggle a pin, knowing that they take 1 clock to execute, and measured that
09:56 AM cehteh: no idea i would do something like label: toggle_pin, jmp label ...
09:56 AM cehteh: scope the pin
09:57 AM cehteh: yeah
09:57 AM Fuchikoma: https://i.imgur.com/KJGf0s6.png
09:57 AM Fuchikoma: Like that? :p
09:57 AM cehteh: you can toggle in hardware hwen you write a bit tp PIN not to PORT
09:57 AM Fuchikoma: It's still 1 clock per instruction though?
09:57 AM cehteh: add a nop to stuff it to 4 cycles .. easier divider
09:58 AM cehteh: yes
09:58 AM cehteh: well i dont know anything else, there must be something wrong
09:58 AM Fuchikoma: So it *shouldn't* matter... I was using "SBI VPORTA, 7"
09:59 AM cehteh: prolly something really stupid, mixed up byte order when setting the baudrate registers or so (not blaming your, telling from experience :D)
09:59 AM Fuchikoma: Unless there's something fucky with the virtual port stuff
09:59 AM cehteh: but uart/baudrate getisters on AVR's are pretty well understood and usually work on spot as described on datasheets/examples
10:00 AM Fuchikoma: I don't doubt it, which just makes things more puzzling
10:00 AM cehteh: so i am almost 99% sure you overseen something embarsingly stupid :D
10:00 AM Fuchikoma: Indeed!
10:01 AM cehteh: hey i recently had a bug here that survived reset
10:01 AM Fuchikoma: I mean, I spent all weekend trying to get the USART working only to realize I was probing the wrong pin for two days straight
10:01 AM cehteh: and later found out it even survived reflashing the firmware
10:01 AM cehteh: never found the cause, just worked around
10:01 AM Fuchikoma: wow nice
10:02 AM Fuchikoma: It's not a feature
10:02 AM Fuchikoma: now*
10:02 AM cehteh: well brb ,,
01:14 PM Fuchikoma: "Rd ? Rd + Rr" I choose to believe this is an intentional joke
03:18 PM djph: Fuchikoma: ouch ...
11:50 PM day__ is now known as day