#avr Logs
Aug 28 2017
#avr Calendar
02:27 AM Thrashbarg_ is now known as Thrashbarg
05:32 AM twnqx: pwgen -s 32
06:57 AM hetii: Hi :)
06:57 AM polprog: hi
06:58 AM hetii: I have such simple timer0 configuration that should produce me 1ms delay: https://pastebin.com/kt8tCNZC
06:59 AM hetii: its atmega8@12Mhz
06:59 AM hetii: but the led blinks something aroung 2~3 time per second so what I do wrong... ?
07:04 AM dsalychev: Do you really want your led to blink 1000 times per second?
07:05 AM hetii: well I will use this timer for other purpose but now I use leds to see that it works not as I expect to.
07:09 AM hetii: even here: https://sites.google.com/site/qeewiki/books/avr-guide/timer-on-the-atmega8 we can see that formula is OCRn = [ (clock_speed / Prescaler_value) * Desired_time_in_Seconds ] - 1 so (((12000000[Mhz]/8[prescaler])⋅0.001[seconds])−1) == 1499
07:09 AM dsalychev: you'd better to use a simulator (software side) to obtain timing diagram or logical analyzer (hardware side) to do the same, imho
07:10 AM polprog: you are redefining timer0_overflows i think...
07:10 AM hetii: its static so should not change while isr calls
07:11 AM polprog: oh, youre right
07:11 AM hetii: I even put it outside and this also don`t change anything..
07:11 AM dsalychev: you may try this one https://github.com/buserror/simavr with gtkwave
07:12 AM polprog: i see what's erong
07:12 AM polprog: wrong*
07:13 AM hetii: feel free to share :)
07:13 AM polprog: 12mhz/8 = 1.5 mhz
07:13 AM polprog: that /255 = 5882.something overflows per sec
07:14 AM polprog: your isr executes 5000 times a second
07:15 AM polprog: then you toggle the led every 1449 ISRs, that gives you 4 toggles per sec
07:16 AM hetii: and this is what I see on led...but how this stand to formula above...
07:17 AM polprog: it does not
07:18 AM polprog: because the formula may be wrong or youre using 1449 in a wrong way
07:18 AM polprog: remind me, that timer is 8 or 16 bit?
07:18 AM hetii: its 8 bit
07:18 AM polprog: it's frequency is F_CPU/prescaler and we found out that in your case it's 1.5 mhz
07:19 AM hetii: yep
07:19 AM polprog: how i do timers is i select a combo of prescaler and a value i write to the timer count
07:20 AM polprog: for example, if you write 127 to the timer value every ISR, then it will take the timer only 128 ticks to overflow
07:20 AM dsalychev: keep it simple, start from 0 :)
07:20 AM polprog: why
07:20 AM dsalychev: to explain it clearly
07:21 AM polprog: good point
07:21 AM polprog: if you dont write anything to the counter, it will take it 255 tick to overflow
07:22 AM hetii: that`s clear.
07:22 AM polprog: if you write some value X to the count,it will take (255-X) ticks
07:22 AM hetii: also clear
07:24 AM dsalychev: taking into account your frequency, there will be 1.5 millions of tick per second, thus 15,000,000/(255-X)
07:25 AM dsalychev: 15,000,000/255 ~ 5882 overflows per second
07:25 AM hetii: to much zeros
07:25 AM dsalychev: sorry yes
07:26 AM dsalychev: 1,500,000/255 ~ 5882 overflows per second
07:26 AM dsalychev: however
07:26 AM polprog: prescaler /8 is too fast because it would take (1.5MHz * 0.001 sec = 1500 ticks) to overflow
07:26 AM polprog: and we cant count that high :P
07:27 AM hetii: not by timer itself thats why I use additional variable.
07:29 AM hetii: so this formula should look like ?(((12000000/8/255)⋅0.001)−1) ?
07:29 AM hetii: to get 1ms ?
07:30 AM polprog: 1 ms is 1khz
07:30 AM polprog: your timer is 5.882 khz
07:30 AM polprog: to get a closest possible to 1ms you need to toggle every 5 ISRs
07:31 AM polprog: every six isrs*
07:31 AM polprog: but you wont get exactly 1khz
07:31 AM dsalychev: ah... we're digging deep
07:31 AM dsalychev: just change if (timer0_overflows >= 1499) to if (timer0_overflows >= 5882)
07:32 AM polprog: close, but no
07:32 AM hetii: hmm
07:32 AM polprog: the isr executes 5882 times a second
07:32 AM polprog: you need to toggle 1000 times a sec
07:32 AM polprog: so youneed to count 5.882 ISRs... which is 6 isrs
07:33 AM polprog: because you cant count a fraction of an ISR
07:33 AM dsalychev: agree, I thought that there should be one blink per second
07:34 AM hetii: but I could do something like: (((12000000/8/250)⋅0.001)) == 6
07:34 AM hetii: and then add 5 to TNC0
07:34 AM hetii: or
07:34 AM hetii: ...
07:35 AM hetii: I mean TCNT0
07:36 AM dsalychev: ok, let me return back :) What do you want to achieve? Blink your led 1000 times per second?
07:36 AM polprog: if you add 5 to TCNT0 every interrupt, then it will overflow every 250 ticks
07:36 AM polprog: that's how you fine tune the values
07:36 AM polprog: brb
07:36 AM hetii: I want to have a timer that run some code every 1ms
07:38 AM hetii: moreover I want to know how to calculate this properly cause I read many tutorials and always when I back to this subject I do something wrong...
07:38 AM polprog: it's complicated
07:38 AM polprog: i had to write everything down to find the proper prescaler and initial value
07:39 AM polprog: because i think you can make it tick every 1ms
07:39 AM polprog: you just need to make it overflow in a freqency that is a multiple of 1khz
07:39 AM polprog: and the count the isrs
07:40 AM polprog: (damnit, if you could prescale like /1 /10 /100 etc, it would be so much easier!)
07:40 AM dsalychev: yeah :)
07:41 AM polprog: you can make it overflow in a nice, round frequency
07:42 AM polprog: your timer is 1500 khz, so if you make it overflow every 150 ticks, it will overflow with a frequency of 10 khz
07:42 AM polprog: so, the initial value is (255-150) = 105
07:43 AM polprog: cos it will count upwards, and it will have to increment it 150 times to overflow
07:43 AM polprog: then you toggle every 15th ISR and voila
07:43 AM hetii: By what wrong with setting TCNT0 to 5 in each intterupt and then raise my code on every 6 iteration?
07:44 AM hetii: *s/By/But
07:44 AM polprog: TCNT 0 is the counter state
07:44 AM polprog: it increments with every *tick* and causes ISR every time it gets to 255
07:45 AM polprog: so in this case you wanna write 150 to TCNT0 every time at the beginning of ISR
07:45 AM polprog: get it?
07:46 AM hetii: don`t get it, why 150 not 5 ? 255-5 give us 250
07:46 AM polprog: what would 250 give us
07:46 AM hetii: (((12000000/8/250)⋅0.001)) == 6
07:46 AM polprog: forget that formula
07:46 AM hetii: hmm
07:46 AM polprog: read what i wrote
07:49 AM hetii: ok sorry for that but what`s wrong with my formula?
07:51 AM polprog: what's 250 in there?
07:51 AM polprog: and what's 6
07:52 AM hetii: 250 is to max amount of ticks that the timer need count
07:52 AM hetii: and the 6 is how many such overflow need happen
07:54 AM hetii: so 6*250 == 1500
07:54 AM polprog: where did you get that formula
07:56 AM hetii: its like here: https://sites.google.com/site/qeewiki/books/avr-guide/timer-on-the-atmega8
07:57 AM polprog: ahhh
07:57 AM polprog: that's for timers which have compare mode i guess
07:57 AM polprog: it says later:
07:57 AM polprog: "Timer0 is fairly neutered counter, it does not have a OCR0 register therefore it is only capable of running in normal mode."
07:58 AM polprog: if you look at the diagram of timer1 it has OCRn
07:59 AM polprog: and that is used for the *compare* interrupt
07:59 AM polprog: your code uses the *overflow* interrupt
07:59 AM hetii: but the calculation should be the same or?
07:59 AM polprog: no
08:00 AM polprog: that formula is for timers which can work in compare mode
08:00 AM polprog: so not timer0
08:00 AM polprog: but timer1
08:00 AM polprog: (in case of atmega8 )
08:02 AM hetii: but to honest I don`t see difference, on first case we can compare actual TCNT0 register with some value or set it to speed up execution of ISR, on second scenario we set internal register that is compared with TCNT
08:02 AM hetii: so no such huge difference.
08:02 AM polprog: in timer0 we are not comparing but writing to the value
08:03 AM hetii: sure, bot both way decide when ISR will be called.
08:03 AM polprog: yes
08:04 AM polprog: the difference is that timer0 interrupts when it gets to 255, so we need to write a new value (if we dont it's 0) at every interrupt if we want to change how ofter in triggers.
08:04 AM polprog: in timer1 we can just write the compare value and trigger at a compare interrupt (not overflow interrupt like in timer0)
08:05 AM dsalychev: You may try to leave this formula, and try to understand what's going on there, inside. It's more important, I guess. See, you have a timer which is incremented 1,500,000 times per second. You programmed an ISR which is called when overflow of the timer's counter happened. Let's say we have to increment our counter 150 times. It'll produce 1500000/150 = 10000 overflows per second. You'll have to count 1000 times
08:05 AM dsalychev: inside ISR before doing something useful.
08:05 AM polprog: to increment our counter 150 times, we need to make it start not from 0 but from 255-150
08:06 AM dsalychev: it's why you'll have to write 105 to TCNT0
08:07 AM polprog: we make the timer think it already counted 105 times!
08:07 AM polprog: :)
08:07 AM dsalychev: sounds good :)
08:08 AM APic: ☺
08:10 AM hetii: ok time for break, I will eat something and back with fresh mind:)
08:11 AM polprog: i think ill eat something too :D
09:04 AM hetii: Ok i`m back
09:04 AM hetii: so here is my code: http://paste.ubuntu.com/25417540/
09:04 AM hetii: and my led blink something around 5 times per second
09:05 AM hetii: so its definitively no 1ms timer.
09:07 AM polprog: you have to toggle it ebery 15th interrupt
09:07 AM polprog: read ! :D
09:08 AM polprog: every*
09:09 AM hetii: polprog, so why dsalychev wrote: "You'll have to count 1000 times
09:09 AM hetii: <dsalychev> inside ISR before doing something useful."
09:10 AM polprog: it was another context
09:10 AM polprog: i think
09:10 AM polprog: yeah, it was in the context of your formula which works only for timer1
09:22 AM hetii: ehh
09:23 AM hetii: main.c: http://paste.ubuntu.com/25417653/ task.c: http://paste.ubuntu.com/25417655/
09:24 AM hetii: in this case led should be on 1 second, but its 3s
09:25 AM hetii: task.h: http://paste.ubuntu.com/25417668/
09:26 AM polprog: it must be the task sys imo
09:26 AM polprog: check all the timer setup with the datasheet
09:27 AM hetii: Of course I double check it.
09:29 AM hetii: the task just decrement value of internal variable and when it is zero then call callback so this should work fine as I used it on other project without issues.
09:29 AM polprog: can you try blinking the led directly by changing a pin state?
09:29 AM hetii: sure
09:30 AM polprog: i gotta go, have dinner
09:30 AM polprog: good luck
09:30 AM hetii: good apetite
09:39 AM JanC is now known as Guest96910
09:39 AM JanC_ is now known as JanC
09:45 AM hetii: polprog, now I test such code: http://paste.ubuntu.com/25417776/
09:46 AM hetii: and by using your values my led is ON by 1.5s
09:47 AM polprog: why are you counting to 1000 in line 26
09:47 AM hetii: to be able to see any changes on led side
09:47 AM polprog: just do
09:47 AM polprog: ah
09:48 AM polprog: it's close.
09:48 AM hetii: now I use my values from formula that you claim is not oright,so: http://paste.ubuntu.com/25417796/
09:48 AM hetii: and get led ON by 1s
09:49 AM polprog: hmm
09:49 AM polprog: if it works, then great :D
09:50 AM hetii: haha, but not the point... one of us do it wrong and I whant to know why ;)
09:51 AM polprog: the clock signal is divided several times, first in hardware (prescaler and counter) and then in software
09:51 AM polprog: it's just complicated
11:07 AM enh: hi
11:10 AM enh: I read its raining a lot on Texas. I hope they recover fast from that problem.
11:18 AM dsalychev1: yeah, hope so
11:29 AM polprog: the forecasts look not promising, although the storm is expected to move east from houston
11:30 AM polprog: good luck everybody in tx
11:32 AM APic: ktnx
11:34 AM polprog: APic: you anywhere near TX?
12:50 PM enh: What is the storm's next stop, after TX? Any forecast?
01:00 PM polprog: going NE
01:00 PM polprog: any news channel shows forecasts every 15 mins or so
01:00 PM polprog: i watch CBS on a stream
01:19 PM enh: I wonder why most of US houses are made of wood. They are easier to build, but are very light. Here we use bricks and concrete most of the time, but we do not have hurricanes
01:19 PM enh: Concrete houses survive hurricanes?
01:20 PM polprog: that's odd too, if you live in a hurricane area the last thing you want it to make a house a fart would blow away :P
01:20 PM Tom_itx: very few encounter hurricanes
01:20 PM polprog: maybe it's so they dont spend much and they can rebuild after the hurricane?
01:21 PM enh: I 've seen a page about dome houses. One of them received a touch down and is still there.
01:22 PM enh: They could be easily built if made with pre molded structures
01:28 PM enh: If you want to build underground, building an inverted piramid with these angles can be cheaper than building vertical walls: http://www.landscapeinfoguide.com/articleFiles/201011071159ANGLESOFREPOSEOFSOILS.pdf
01:30 PM enh: Water can be kept on the bottom and your shelter above it. On the surface, a normal house.
01:30 PM enh: or a dome one.
01:31 PM enh: http://www.monolithic.org/homes
01:34 PM bss36504: enh: Traditional concrete blocks also don't always stop wind-driven projectiles. I saw a video of a simulated cat. 4 tornado launching a 2x4 through through a concrete block wall
01:35 PM enh: lots of violence
01:35 PM enh: probably the blocks should be filled
01:36 PM bss36504: Also, wood houses are easy and cheap to build as well as modify. The wood is more compliant than, say, masonry for aesthetic reasons. Modification and maintenance is likely more in reach for the average homeowner as well. And, as Tom said, very few people (relative to the population of the US) encounter the extreme weather seen in hurricanes and to
01:36 PM bss36504: rnados
01:36 PM enh: and you can add materials to concrete to make it stronger
01:36 PM bss36504: Yeah, but we're not trying to build a storm shelter, people want nice livable homes. This isn't exactly an every day or even every year occurance
01:36 PM MacGeek: ancient roman concrete was crazy strong
01:36 PM MacGeek: they added volcanic ashes to it
01:37 PM enh: I believe the ashes are part of the chemical process
01:37 PM enh: masonry houses are a pain in the ass to modify
01:38 PM MacGeek: pretty much every house is masonry here
01:38 PM enh: but you can built masonry outside only, and dry walls inside.
01:38 PM MacGeek: we don't do the whole wood/drywall thing
01:38 PM MacGeek: here being italy
01:38 PM enh: where, MacGeek?
01:38 PM enh: ah, ok
01:39 PM enh: in brazil it is mainly masonry
01:40 PM enh: i dream to build a dome house. Concrete panels outside, dry walls inside.
01:40 PM MacGeek: I'd like a house completely underground
01:40 PM bss36504: no you don't haha
01:40 PM bss36504: no sun?
01:40 PM bss36504: water...forever
01:40 PM bss36504: mildew
01:41 PM MacGeek: just needs to be properly built
01:41 PM bss36504: artificial ventilation
01:41 PM bss36504: lots of money for little benefit IMO. Humans are a terrestrial species, we aren't designed to live underground. I refuse to believe anyone would want to live under the earth for an extended period of time before they are physiologically compelled to go to the surface
01:42 PM enh: https://smile.amazon.com/Fifty-Dollar-Underground-House-Book/dp/0442273118/ref=sr_1_1?ie=UTF8&qid=1503943889&sr=8-1&keywords=underground+houses+50
01:42 PM enh: Good book
01:46 PM MacGeek: also it would have to have a giant garage
01:46 PM Emil: Hmm
01:46 PM enh: I have this book. It is very nice.
01:46 PM Emil: I wonder why the fuck SPI doesn't want to work on my nodemcu v1
01:47 PM enh: I'm having an affair with SPI here too.
01:48 PM enh: "If you look for something long enough and still can't find it, it is probably because that thing is lost."
01:48 PM enh: amazing statement
01:49 PM MacGeek: https://s-media-cache-ak0.pinimg.com/originals/e6/39/0d/e6390d44b8fb2320693f56a6c938d647.jpg <-- not wrong
01:52 PM enh: I do not agree. My garage wouls be smaller. And it is missing a big workshop.
01:53 PM MacGeek: think of the garage as a man cave, it doesn't need to be filled to the brim with cars
01:53 PM enh: Near the kitchen
01:54 PM enh: I moves the SPI protocol class from the stack to the heap and the code hanged. I love that. On the stack it is not working well. On the heap, not working at all.
01:54 PM enh: moved
02:34 PM robinak is now known as robink
02:36 PM Emil: GAH
02:37 PM Emil: A fucking smidgen of a copper thing remain
03:23 PM polprog: yay
03:23 PM polprog: i can embed binary files into my c code
03:23 PM polprog: so far only on PC
03:24 PM polprog: but if i am right about this it inserts the data into the executable itself, which could mean it's gonna be like PROGMEM
03:48 PM Tom_itx is now known as Tom_L
04:00 PM polprog: https://puu.sh/xlNLF/f72a1c2bbd.png
04:20 PM antto: multi-window h4x0r detected
04:22 PM antto: taskbar on the top x_x
04:22 PM antto: UGH!
04:24 PM dsalychev: it looks ok :)
04:25 PM dsalychev: polprog, you're from Poland, nice!
04:29 PM day_ is now known as daey
04:48 PM ohsix: sup, anyone know where in the documentation the sram address is for a part? i have the linker script, so i have the value; but i'm really interested in where it came from
04:48 PM ohsix: since i'm having such a hard time finding it in the datasheet i suspect it's in something for teh series
04:52 PM antto: uhm.. check for a chapter "Memory" in the datasheet?
04:53 PM ohsix: yea, it doesn't have the sram base
04:53 PM ohsix: it just shows it as 0x0000+size
04:54 PM ohsix: base on the 328 is 0x800000
04:54 PM ohsix: tbh i didn't think to look for just the number before now, but it's also nowhere in there
04:55 PM antto: sram "base" ?
04:55 PM antto: doesn't it begin from 0 ;P~
04:56 PM antto: or maybe close to 0
04:57 PM dsalychev: to be precise... internal SRAM starts from 0x0060 for ATmega8A, for instance
04:57 PM dsalychev: Register File starts from 0x0000 (32 registers)
04:57 PM antto: isn't that because the lower addresses are for the PORTs and sh*t?
04:58 PM dsalychev: then I/O registers (from 0x0020 to 0x005F, 64)
04:58 PM antto: and 0x800000 is a huge number
04:58 PM dsalychev: then internal SRAM (from 0x0060 up to 0x045F)
04:58 PM antto: my calculator can't even..
04:59 PM antto: that's 8.00MB
05:00 PM antto: that's an unthinkable amount of ram
05:00 PM antto: microchip's gonna have a heart attack
05:01 PM dsalychev: ohsix, try to find "AVR Memories -> SRAM Data Memory" in your datasheet
05:09 PM ohsix: it doesn't though
05:09 PM ohsix: heh
05:09 PM ohsix: verbatim, that would have it stuck in the middle of the flash, which it isn't
05:10 PM ohsix: eeprom base is 0x810000
05:13 PM ohsix: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=ld/emulparams/avr5.sh;h=64e9d66de43894a8cfe0cc9350f49d7bbd8ecb32;hb=HEAD here's where it's ultimately sourced for the 168/328
05:15 PM ohsix: and it's plugged into here https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=ld/scripttempl/avr.sc;h=7a146b7777e2d20d85880051f29a8175c5f3f79f;hb=HEAD
05:15 PM ohsix: since this stuff is from atmel i could probably just assume this was the origin of tha tinfo, but it really should be in a datasheet somewhere
05:17 PM ohsix: ahh i see an old thread that suggests a thing
05:22 PM polprog: dsalychev: indeed :)
05:22 PM polprog: antto: the only correct way to have the taskbar
05:23 PM ohsix: nope, there isn't enough information about address decoding to infer it either
05:27 PM dsalychev: ohsix, in spite of the fact that it's not clear for what you really want to achieve, just do not assume that 0x800000 means anything useful for MCU itself. It seems like a valid base address somewhere in ELF file, no more.
05:30 PM dsalychev: even 64k EEPROM looks weird... ATmega328 has only 1k
05:32 PM polprog: internal eeprom is for some small config data and notwhat, if you need to store a lot of stuff get external eeprom, or fram
05:32 PM * polprog is messing around with a sweet spi fram chip
05:33 PM ohsix: i think i've been pretty clear, i wanna know the source of the information
05:34 PM polprog: avr-libc homepage (and docs) have a nice explanation of data spaces
05:34 PM polprog: let me find that cos its buried in the maze of odd html documents
05:35 PM polprog: http://www.nongnu.org/avr-libc/user-manual/mem_sections.html
05:35 PM polprog: this explains the "8 megabyte" offset
05:36 PM LeoNerd: It's a totally arbitrary number made up in agreement between the compiler and linker, to account for the fact that ELF doesn't understand how to do split data/program memory spaces
05:36 PM polprog: http://www.nongnu.org/avr-libc/user-manual/malloc.html
05:36 PM LeoNerd: It's entirely artificial outside of the chip
05:37 PM polprog: read both throughly, the latter one first
05:37 PM ohsix: right, so the programmer just reads 0x81 as eeprom
05:37 PM polprog: read that lol
05:38 PM LeoNerd: "the programmer"?
05:39 PM ohsix: Not that addr must be offset by adding 0x800000 the to real SRAM address so that the linker knows that the address is in the SRAM memory space.
05:39 PM ohsix: heh
05:39 PM ohsix: yes, who decides the convention for the high order bit marking the section
05:39 PM LeoNerd: Someone ranodmly
05:39 PM LeoNerd: doesn't matter
05:39 PM LeoNerd: It's an arbitrary number that everyone agrees to
05:39 PM ohsix: i'm glad it doesn't matter
05:40 PM ohsix: but i still want to know
05:40 PM LeoNerd: You could pick whatever number you want as long as all points in the toolchain agree
05:40 PM ohsix: they've still got the offset in the elf
05:40 PM LeoNerd: yes that is exactly why
05:40 PM ohsix: i haven't checked if memory references keep the high order bits, but it would also need to, and be patched when put in the correct section
05:40 PM LeoNerd: ELF files can't cope with split flash + RAM
05:40 PM LeoNerd: So one has to be offset
05:41 PM LeoNerd: This offset just makes two "spaces" in the file
05:41 PM LeoNerd: (Well, three given the eeprom one)
05:41 PM ohsix: you mean two segments with the same base?
05:41 PM LeoNerd: The entire toolchain could instead have been taught how to have three ELF files, or use a different format, or whatever
05:41 PM LeoNerd: But this was the way that was chosen, because probably it was easiest
05:41 PM LeoNerd: I have no idea the histor
05:41 PM ohsix: there are other arch' that use high order address bits to distinguish sections
05:42 PM LeoNerd: OK, so probably it has precident there
05:42 PM ohsix: it's not even weird, and some of those even use those bits in the alu/pointer references to know which region on the chip itself
05:42 PM LeoNerd: These bits don't come out on the chip
05:42 PM ohsix: arm uses the lsb for thumb switching
05:42 PM LeoNerd: There aren't enough bits on the chip to remember it
05:42 PM LeoNerd: They don't exist there
05:42 PM LeoNerd: They are purely 100% inside the compiler and linker and ELF file
05:42 PM ohsix: i picked up on that the first time
05:43 PM LeoNerd: gcc invents them, them avr-objdump throws them away
05:43 PM LeoNerd: After avr-objdump has extracted the .hex files to fill in flash and eeprom, nobody cares any more
05:43 PM LeoNerd: As long as gcc (well, not even gcc but avr-libc) and objdump agreed you could pick any other number you liked
05:44 PM ohsix: you mean objcopy?
05:44 PM LeoNerd: Er whatever it's called
05:44 PM LeoNerd: I'd have to spend the ~5 seconds to open my makefile and remindmyself the abitrary words used in the process
05:44 PM LeoNerd: Or I could just handwave on the principles and leave you to fill in the finer detail
05:44 PM ohsix: yes, everything seems very arbitrary
05:45 PM LeoNerd: I also couldn't remember which name of Harvard or Von Neunman I meant above, so I didn't say it
05:45 PM LeoNerd: But that is the general reasoning behind - ELF is built for one, AVRs are the other
05:45 PM polprog: but as you can see it can be coped with
05:50 PM ohsix: hex doesn't seem to need any special address markers to put the text section in the right place
05:51 PM LeoNerd: That's because it's already been extracted to the right place
05:51 PM LeoNerd: The .hex files relating to flash and eeprom are already correctly zero-based
05:51 PM LeoNerd: So they're suitable to go into avrdude et.al. immediately
05:51 PM dsalychev: ohsix, I wrote a small cmake template to compile C code and prepare .hex file for AVR. It can be shared if you want to tinker with.
05:51 PM ohsix: it even does the right thing if you don't pass -j .text/data when you do it
05:52 PM ohsix: dsalychev: nah i already have lots of samples to play with, thanks tho
05:53 PM polprog: a hex file contains the data to be written to one type of mem hence you need to pass the destination when invoking avrdude
05:56 PM polprog: goodnight
06:06 PM ohsix: polprog: avr-libc docs do look like they contain a lot of stuff that was missing
06:07 PM ohsix: hrm i'd swear iwas just using avrdude with elf files and it was working
06:08 PM ohsix: one avenue for figuring all of this junk out was adding write support for elf files in avrdude
07:37 PM ohsix: avrdude doesn't even know about flash, it looks like it just jams instructions over for self programming
08:07 PM Casper: avrdude I think knows the page size, via config, and that's about it
09:13 PM enh: Lambda_Aurigae: have you got kids?
09:17 PM enh: I love when things restart working well and I do not know what I did to fix them.
09:22 PM enh: IF anybody here ever needs a protocol to transfer data via SPI, I believe I do have a working one. It can transfer longs, floats and bytes.
09:24 PM ohsix: /m #avr like this? https://jpa.kapsi.fi/nanopb/
09:25 PM ohsix: oof
09:49 PM enh: ohsix: Mine is much smaller than 20k
10:03 PM day is now known as daey
11:51 PM day_ is now known as daey