#avr Logs

Oct 24 2017

12:10 AM day__ is now known as daey
01:44 AM rue_bed: politics, hah, now it all makes sense
01:45 AM rue_bed: #define IsHigh(BIT, PORT) (PORT & (1<<BIT)) != 0
01:45 AM rue_bed: #define IsLow(BIT, PORT) (PORT & (1<<BIT)) == 0
01:48 AM Casper: again those 2 lines?
01:48 AM Casper: didn't you pasted them yesterday and the day before and the day before and the day before and the day before and the day before and the day before and the day before and the day before and the day before ... ?
01:49 AM ohsix: twice in my buffer
01:49 AM ohsix: maybe he is scrolled up
01:50 AM Casper: maybe he just lost his mind
01:50 AM Casper: too much magic smoke
01:54 AM Ameisen: Any one have thoughts on why -fno-short-enums would _increase_ codesize drmatically?
01:54 AM Ameisen: I can't think of a reason
02:01 AM ohsix: thinking is limited, get gcc to dump optimizer passes
02:01 AM ohsix: see how the order changes or what stages are missing with the option on
03:03 AM ohsix: https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html
03:04 AM ohsix: there's also https://gcc.godbolt.org/ which makes it easy to try many variants
03:04 AM ohsix: the 'short' in no-short-enums might not mean 16bit
03:08 AM Ameisen: -fno-short-enums is defined to alter the type of all enums so that the type is the smallest type that can fit all values that are defined for it
03:08 AM ohsix: just looking at the map file will give you enough places to investigate
03:08 AM Ameisen: meaning that almost all enums should go from being int (int16_t) to int8_t
03:09 AM ohsix: then you can do the last = 2^n entry to make it arbitrary sizes then
03:13 AM Ameisen: Yes, but in this case, they should be uint8_t
03:13 AM Ameisen: but it's bloating
03:14 AM Ameisen: Even if I go through and manually type the enums (c++), it bloats the same way
03:14 AM Ameisen: Which makes no sense off-hand - why would enums being uint8_ts make avr8 code larger? substantially so?
03:15 AM Emil: -no-short-enums is highly preferable
03:15 AM Emil: Lambda_Aurigae: LeoNerd so on: share your compile options
03:16 AM Ameisen: Emil - but why?
03:17 AM Ameisen: I would think uint8_t enums would create smaller code than int-sized enums
03:18 AM Emil: Ameisen: Oh
03:18 AM Emil: I meant
03:18 AM Emil: -f short-enums
03:18 AM Emil: That's highly preferable
03:18 AM Emil: Ameisen: you are correct
03:19 AM Ameisen: Yeah, in my case, -fshort-enums is increasing code size substantially
03:19 AM Ameisen: -fno-short-enums is smaller
03:19 AM Ameisen: for another test, I went through and changed _all_ enums to uint8_t (enum blah : uint8_t) and got the same result - code bloat
03:21 AM Emil: http://www.keil.com/support/man/docs/armclang_ref/armclang_ref_chr1411640303038.htm
03:21 AM Ameisen: for arm, yeah. However, on AVR where registers are 8-bit...
03:21 AM Ameisen: smaller data sizes are generally always preferable.
03:21 AM Emil: I was referring to the compile flags
03:21 AM Ameisen: yeah
03:21 AM Ameisen: I set them.
03:22 AM Ameisen: I checked binary size with -fshort-enums, -fno-short-enums, and manually changing the type of all enums
03:22 AM Ameisen: -fshort-enums and manual sizing both gave me code bloat
03:22 AM Ameisen: which is counterintuitive
03:22 AM ohsix: https://godbolt.org/g/QEtmYu you can change the options & the value of last to see what is happening
03:23 AM Emil: How many enum values are you storing?
03:23 AM Emil: If you are storing more than 256 then it
03:23 AM Emil: it's more efficient code size wise to always use 16-bit enums
03:23 AM Emil: if I'm not mistaken
03:23 AM Ameisen: none of them are > 0xFF
03:23 AM Emil: if you use them often
03:24 AM Emil: Ameisen: manually assigning values to enums is CANCER
03:24 AM Ameisen: that's why I'm confused.
03:24 AM Ameisen: those parts aren't my codebase :|
03:24 AM ohsix: you need to lock the size
03:24 AM ohsix: it is abi
03:24 AM Ameisen: if any values were > 0xFF, : uint8_t would throw a compiler error
03:24 AM Emil: no, it wouldn't
03:24 AM Emil: and I didn't ask about values stored
03:24 AM Emil: I asked about how many
03:25 AM ohsix: it will just grow them
03:25 AM Ameisen: in all of the enums put together?
03:25 AM Emil: how many enums and enum values there are
03:26 AM Ameisen: ~10 enums, each one has between 3 and 10 enumerators
03:26 AM Ameisen: https://ideone.com/52AfV7
03:26 AM Ameisen: just a sanity check on my part
03:26 AM Emil: So all of them fit in the 8-bit range
03:26 AM Ameisen: yes
03:26 AM Emil: what kind of fucking syntax is that
03:26 AM Ameisen: typed enumerators
03:27 AM ohsix: numerators
03:28 AM ohsix: if you assign the type, of course it will tell you
03:28 AM Ameisen: I've tried it both with -fshort-enums _and_ assigning the type explicitly to each enum
03:28 AM Ameisen: I get the same result with both
03:29 AM Ameisen: a substantial code-size increase compared to -fno-short-enums
03:30 AM ohsix: http://www.coding-guidelines.com/cbook/cbook1_2.pdf dang i keep forgetting this exist and is freely available
03:31 AM ohsix: Ameisen: need more info than that, like code that actually changes size
03:31 AM ohsix: it isn't changing with a minimized demo
03:33 AM Ameisen: I know; it makes it difficult
03:33 AM Ameisen: tying everything together from all the different object files, plus LTO
03:33 AM Ameisen: makes finding such things annoying
03:33 AM ohsix: use the map file to find top 5 function bodies by size
05:08 AM Jartza: luckily I mostly code to AVR with assembly :D
05:09 AM Jartza: I can make my own optimizing mistakes
05:35 AM Lambda_Aurigae: I just use large AVRs and don't optimize.
05:35 AM Emil: lol
10:23 AM LeoNerd: Emil: CC=avr-gcc -std=gnu99 -Wall -Os -DPRIMARY_$(PRIMARY) -DF_CPU=$(CLOCK) -mmcu=$(DEVICE) -flto -ffunction-sections -I$(HOME)/electronics/avr-common $(CFLAGS)
01:52 PM wondiws: I have a problem with snprintf, I'm doing "snprintf(buf, 20, "%x\r\n", 0x12345678);" but I only get the 5678
01:53 PM wondiws: ofcourse it does work as expected on the linux64 platform
01:59 PM atk is now known as t-
02:02 PM t- is now known as atk
02:21 PM LeoNerd: on AVR, 'int' is 16bits
02:22 PM LeoNerd: If you want the full thing you'll need "%lx\r\n", 0x12345678L
03:31 PM Emil: LeoNerd: hmm, no enum
03:31 PM Emil: s
03:31 PM Emil: but lto and only function-sections
03:32 PM Emil: Also what is primary
03:36 PM Emil: -E Preprocess only; do not compile, assemble or link.
03:36 PM Emil: -S Compile only; do not assemble or link.
03:36 PM Emil: -c Compile and assemble, but do not link.
03:36 PM Emil: I should study these flaghs
04:03 PM LeoNerd: enums?
04:03 PM LeoNerd: Emil: Oh, PRIMARY is an artefact of my "maybe we're making multiple targets" makefile
04:03 PM LeoNerd: It just relates to a few bits of my C code
04:04 PM Emil: ah
04:04 PM LeoNerd: So... every time I reflash my 328PB, it forgets the EEPROM
04:04 PM Emil: enum size optimisation
04:05 PM Emil: enums are by default int sized, so 16 bits
04:05 PM LeoNerd: I thought I'd adjusted the EESAVE fuse, but in either setting, it clears
04:05 PM Emil: but you can ask gcc kindly to use 8 bits
04:05 PM LeoNerd: Ah, is there a gcc flag to ask to.. nice
04:05 PM LeoNerd: avrdude: safemode: Fuses OK (E:F7, H:D1, L:3F)
04:06 PM LeoNerd: ^-- is what my fuses claim to be
04:07 PM Emil: LeoNerd: -fshort-enums
04:07 PM Emil: http://www.nongnu.org/avr-libc/user-manual/using_tools.html
04:07 PM Emil: Ooh
04:10 PM Emil: polprog:
04:11 PM ohsix: still talking about enums eh
04:14 PM Emil: https://emil.fi/jako/kuvat/2017-10-24_23-43-24_bAPnpxqb.png
04:14 PM Emil: YES
04:15 PM Emil: I knew the compiler wasn't that stupid
04:15 PM Emil: wait
04:15 PM Emil: it's only for literals
04:15 PM Emil: fuck that
04:47 PM LeoNerd: Anyone any idea on EESAVE and avrdude?
04:57 PM LeoNerd: The EEPROM seems to be reset to 0xFF after an avrdude upload of the flash into my 382PB, regardless of my fiddling of the EESAVE fuse
05:04 PM thardin: FF is what a erase cycle gets you
05:05 PM thardin: I haven't had to poke any fuses to get eeprom to write
05:05 PM LeoNerd: Yah
05:05 PM LeoNerd: .. hmm? It's not about writing
05:05 PM LeoNerd: My program can write the EEPROM just fine
05:05 PM LeoNerd: It preserves across reboots.
05:05 PM LeoNerd: But when I 'avrdude' to upload new flash, it all disappears
05:06 PM thardin: aha. maybe tell avrdude not to erase the entire device, just the flash?
05:06 PM thardin: -D I think
05:06 PM thardin: then erase flash manually with some other flag I am guessing
05:06 PM thardin: workaround if that doesn't work: download eeprom before programming
05:19 PM LeoNerd: DOH I am an idiot
05:19 PM LeoNerd: ... I forgot to type "CAL SAVE" into my console, thus telling the device to -actually- store its calibration values
05:24 PM thardin: here's a question: how do you all do testing?
05:24 PM thardin: automated testing that is
05:28 PM LeoNerd: Ah, I don't really... not for AVR things
05:30 PM thardin: kinda want to test my text UI
05:30 PM thardin: most of the stuff can be cross-compiled with some trickiness
05:30 PM LeoNerd: Yeah... I've vaguely thought about it but notsure how to simulate the nontrivial bits of external hardware
05:31 PM LeoNerd: OLED, ADC/sensor chips,...
05:34 PM thardin: yes. maybe a bash script that send stuff over serial and checks that it gets expected values back at least. that requires hardware of course
11:29 PM polprog: Emil: that's useful
11:29 PM polprog: but that particular strlen() on literals makes sense - as long as it calls real strlen on variables
11:31 PM Ameisen: easy enough to implement a strlen that can determine if the size is known at compile-time in C++
11:33 PM Ameisen: constexpr template <unsigned N> unsigned strlen (const char (&str)[N]) { return N; }
11:33 PM Ameisen: if it's not known at compile-time, it won't match the type and will overload to default strlen
11:34 PM Ameisen: note that that can work odd if you have something like char foo[5] = { 'a', '\0', '\0' }
11:34 PM Ameisen: though it can be implemented to handle that too, I just didn't feel like writing it