#avr Logs

Mar 08 2018

#avr Calendar

12:10 AM rue_shop3: like when people move in beside a sewer processing plant, and then think they can complain about the smell?
12:20 AM Casper: fun thing is: airport are federal stuff, the city have zero right to do anything
12:20 AM Casper: in fact, the airport can even give 'orders' to the city, but the city can not
12:21 AM Casper: for example, the airport use the city firefighters and can request to have upgraded equipment
12:48 AM rue_shop3: however the city probably determines the tax 'rate' for the airport
12:49 AM rue_shop3: property value * tax rate * municipal share goes back into the city
12:50 AM sebb: Maybe this is just 8 bit guys here, but is there anyone that knows a cheap programmer for SAMD MCUs ?
12:52 AM rue_shop3: samd?
12:55 AM nuxil: microchip
01:00 AM sebb: Lol... yeah, that´s right, Not Atmel anymore...
01:01 AM polprog: sebb: have you tried openocd?
01:02 AM polprog: it can use raspi's gpio to program stuff
01:03 AM sebb: ahh... i will look into that..
01:04 AM polprog: [06:23] <nuxil> this is the road into my island :D https://www.vegvesen.no/Trafikkinformasjon/Reiseinformasjon/Trafikkmeldinger/Webkamera?kamera=100105&zoom=7 you have your own island? cool! :^)
01:04 AM nuxil: ehh. not excatly :p
01:04 AM polprog: all the snow melted here already
01:05 AM nuxil: snow will be gone by begining/mid may :p
01:06 AM polprog: you can go outside without thermal underwear, long johns
01:06 AM polprog: it was nicer when it was -10
01:06 AM polprog: now theres mud everywhere :(
01:07 AM nuxil: since i live by the sea it doesnt get so cold here. its rarte that its passed -10. but if you a bit inland they get -20 all the time.
01:13 AM nuxil: time to do some asm coding.
01:13 AM polprog: have fun
01:13 AM nuxil: one thing i hate about mixing C and asm, is that a uint8 uses same about of registers as a uint16.
01:13 AM nuxil: *amount
01:13 AM polprog: mm
01:14 AM nuxil: yea. example pass 2x uint8 to your asm function, and the values will be in r24 and r22 r25 and r23 will be empty.
01:15 AM Xark: nuxil: You can try -mint8 to fix that.
01:16 AM nuxil: oh,
01:16 AM polprog: huh
01:17 AM Xark: Not strictly C kosher, but it works nicely. See https://gcc.gnu.org/wiki/avr-gcc down by Deviations from the Standard:8-bit int with -mint8
01:18 AM Xark: You need to make sure you always use proper prototypes, and you can still pass int16_t, int32_t etc.
01:20 AM nuxil: you have tried this ?
01:20 AM Xark: Sure. It does tighen up the C calling conventions nicely (no needless 2nd reg, or sign/zero extension)
01:21 AM Xark: It is basically making int = char
01:21 AM Xark: However, if you use proper intXX_t types, then nothing changes except default cast to int16 is gone.
01:22 AM Xark: Obviously this will break code expecting int to be a certain size.
01:23 AM nuxil: yea but uint8 is same size as char on avr.
01:23 AM Xark: So?
01:23 AM Xark: int is 16-bit and C standard mandates everything smaller than int is promoted to int.
01:24 AM Xark: By making "int" 8-bit, this is a NOP
01:24 AM Xark: (so, uint8 or char is actually 8 bits)
01:25 AM Xark: In my experience, with code using all sized types it makes a significantly tighter (with few issues).
01:25 AM Xark: ^tighter executable
01:25 AM nuxil: im using uint8, uint16 and uint32 in my code.
01:26 AM Xark: (smaller, less wasted regs, less pointless sign/zero extension)
01:26 AM Xark: nuxil: Well, do a avr-size (or disassembly), then recompile with -mint8 and see if you like the difference
01:26 AM polprog: i cant imagine how one would code for micros *without* stdint types
01:27 AM Xark: polprog: Agreed. :)
01:30 AM polprog: i should take a break from low level programming though...
01:30 AM nuxil: polprog, really? you lack imagination.. how about a simple led flasher :p
01:31 AM polprog: nuxil: i dont want to inagine such terrible things :(
01:31 AM nuxil: :D
01:32 AM Ameisen: what about uint24?
01:32 AM polprog: struct led { int* port; int* pin; void flash.....
01:32 AM polprog: is there one
01:32 AM nuxil: Ameisen, what about it ?
01:32 AM Ameisen: you're not using it?
01:32 AM Ameisen: D:
01:32 AM nuxil: there is no uint24
01:32 AM polprog: why would you use a 3 byte int
01:32 AM nuxil: :p
01:32 AM Ameisen: err
01:32 AM Ameisen: __uint24 is absolutely part of the GCC extensions for AVR
01:32 AM Ameisen: and __int24
01:32 AM nuxil: really?
01:32 AM Ameisen: yes
01:33 AM polprog: https://github.com/calccrypto/uint256_t
01:33 AM nuxil: i thought it was not a real uint34. and used the same size as a uint32 does.
01:33 AM nuxil: *uint24
01:33 AM Ameisen: nope
01:33 AM Ameisen: sizeof(__uint24) == 3
01:33 AM polprog: how about a 32 byte int? avr has just enough registers for it :D
01:34 AM polprog: rip stm8 being an accumulator machine
01:34 AM Ameisen: I use uint24 quite heavily
01:36 AM nuxil: huu?
01:40 AM polprog: apparently openvpn can transmit data even without any cellular access
01:40 AM nuxil: emm-.
01:40 AM nuxil: when did we get 24bit ints ?
01:40 AM polprog: just walked down the basement and it still shown 1 kbps
01:40 AM nuxil: https://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html#ga33594304e786b158f3fb30289278f5af
01:40 AM Ameisen: It's been part of GCC for a long time afaik.
01:41 AM nuxil: cant find it
01:41 AM Ameisen: __uint24
01:41 AM Ameisen: it's not a typedef.
01:41 AM Ameisen: __int24 and __uint24
01:41 AM polprog: whats fast uint
01:42 AM nuxil: Ameisen, dis 24bit int of yours in C++
01:42 AM nuxil: ?
01:43 AM Ameisen: It's in C++ as well.
01:43 AM Ameisen: it's one of the few AVR extensions in gcc and g++
01:43 AM polprog: plot twist, Ameisen wrote it and forgot its his own extension ;)
01:44 AM Ameisen: https://gcc.gnu.org/wiki/avr-gcc#Types
01:44 AM Ameisen: there's no uint48 though, so uint24*uint24 only fits in uint64
01:45 AM Ameisen: though if you use __assume and constrain it to 48-bits, doesn't matter much
01:55 AM nuxil: Ameisen, alright. so this is a avr spesific extension.
01:55 AM Ameisen: [01:31:40] <Ameisen> __uint24 is absolutely part of the GCC extensions for AVR
01:55 AM Ameisen: yes
01:56 AM Casper: what?
01:56 AM Casper: since when?
01:56 AM Ameisen: GCC 4.7
01:58 AM Casper: interessing if true
01:58 AM Ameisen: https://gcc.gnu.org/wiki/avr-gcc#Types
01:58 AM nuxil: yea. i will actually rewrite some code now. :D
01:58 AM Ameisen: could implement [u]int40 and [u]int48 easily enough in C++
01:59 AM Ameisen: just nice when the compiler supports it
01:59 AM Casper: yeah little mention about them, very little...
02:00 AM Ameisen: my firmware uses it heavily
02:01 AM nuxil: well. i learnt something new today :)
02:01 AM Ameisen: that's why I'm here
02:01 AM nuxil: ^^
02:01 AM Ameisen: also to teach people about constexpr
02:01 AM nuxil: go away :p
02:03 AM nuxil: C is hard enuf. no need to complicate it more :p
02:04 AM Ameisen: I like autogenerating data at compile time :)
02:04 AM Casper: got natt
02:05 AM nuxil: god natt :)
02:06 AM Ameisen: gode niht
02:16 AM nuxil: so. why isnt there a typedef for uint24 ?
02:19 AM nuxil: we can write uint8_t, uint16_t, uint32_t uint64_t, but not uint24_t but must write it as __uint24, is this because its a none standard int and thus does not belong in the stdint ?
06:09 AM Jartza: nuxil: well, stdint has no such thing as uint24, so it would violate standard
06:10 AM Jartza: that's gcc extension
06:15 AM enh: Mornin'
06:17 AM nohitzwork: morning
06:18 AM nohitzwork: how is your project , enh ?
06:40 AM polprog: you can typedef or macro it tho
07:05 AM nuxil: ofc
07:11 AM arduiko: Hello, does someone have a PC steering wheel controller ? it's for retrieve its HID descriptor
07:11 AM nuxil: lol.. here we go again :d
07:12 AM arduiko: x)
07:12 AM arduiko: well I made progress
07:12 AM arduiko: I no more ask for logitech mouse :D
07:12 AM arduiko: because I had it days ago :p
07:12 AM arduiko: from me xD
07:13 AM arduiko: I search into my stuff and I found one
07:13 AM arduiko: but it miss the PC steering wheel :/
07:31 AM polprog: bored, 2 h to go
07:31 AM polprog: https://puu.sh/zDcgW/6b3c20e354.jpg
07:32 AM polprog: enjoy a pic of the whitebored i just solved a problem on
07:32 AM polprog: blackbored*
07:38 AM arduiko: and you was right for the scroll left/right, but at least, I got my anwser :D
07:38 AM arduiko: nuxil
07:39 AM arduiko: and I am happy with that x)
10:44 AM day__ is now known as day
10:46 AM polprog: workplace goal: pinpong table in the server room
11:24 AM day__ is now known as day
12:15 PM Ameisen: Apparently, ST makes POWER-based MCUs
12:17 PM polprog: like
12:17 PM polprog: powerpc?
12:17 PM Ameisen: powerpc is based on POWER
12:18 PM Ameisen: POWER is an ISA
12:18 PM Ameisen: http://www.st.com/content/st_com/en/products/automotive-microcontrollers/spc5-32-bit-automotive-mcus/spc5-mcus-for-interior-networking-and-low-power-applications/spc58-g-line-mcus/spc58ng80c3.html
12:18 PM polprog: huh
12:18 PM Ameisen: their clock rate is lower than their best ARM MCUs
12:18 PM Ameisen: but triple-core
12:18 PM Ameisen: so...
12:18 PM polprog: very interesting
12:45 PM The_CooIest is now known as The_Coolest
12:54 PM polprog: i feel like messing around
12:54 PM polprog: ill burn some unix and run it on the pentium box
12:54 PM polprog: just for fun
12:55 PM polprog: dont wanna reconnect the monitors so ill use a serial console
12:56 PM polprog: or not
01:22 PM polprog: actually
01:22 PM polprog: i have a netbsd vm on this box
01:23 PM polprog: nice
01:23 PM polprog: so i went ahead and reset the password on it
03:41 PM Xark: polprog: BTW, for all the fast, least etc. standard types -> http://en.cppreference.com/w/c/types/integer
03:42 PM Xark: polprog: (and perhaps easier answer https://stackoverflow.com/questions/35055042/difference-between-uint8-t-uint-fast8-t-and-uint-least8-t )
03:45 PM polprog: Xark: thanks, that was interesting to read
03:45 PM polprog: SO having great explanations as usual :)
03:45 PM polprog: niters for now
03:45 PM Xark: polprog: Right on, my pleasure.
03:45 PM Xark: Goodnight!
05:27 PM nuxil: never seen the usage of uint fast & uint least irl.
05:29 PM nuxil: Xark, on AVR would uint8 would be the same as uint8 least and uint8 fast ?
05:35 PM Xark: nuxil: Yeah, all identical for AVR I believe.
05:35 PM Xark: nuxil: Mostly useful for wacky systems (12 bit byte or other oddball sizes).
05:36 PM Xark: (However, there is the issue that C forces int8 -> int16 quite often)
05:37 PM Xark: nuxil: You also have the problem that e.g., int16_t might not exist (then you would need to use int_least16_t)
05:38 PM nuxil: yea. well im not into exsotic architectures. :)
05:39 PM Xark: One of the nice things about AVR is it was designed to be decent for C.
05:39 PM Xark: (compare vs some small PICs, e.g.)
05:40 PM nuxil: i cant tell. i have only messed around with atmel chips. atiny13, atiny85, atmega88 and atmega324 ..
05:40 PM nuxil: im a noob you know :p
05:41 PM Xark: PIC8 has a super clunky architecture (which makes C compilers do backflips - and not super efficient)
05:41 PM Xark: Banked registers, non linear memory etc.
05:41 PM nuxil: when i started looking into mcu's, google was basically spitting out pic's & avr's for me. after reading abit about the toolchain i whent for atmel :)
05:42 PM Xark: Yep
05:43 PM nuxil: btw. i havent tried that -mint8 you suggested yet.
05:44 PM nuxil: been busy rewriting stuff that used uint32 bit and only used 24bits-. i had no idea there was a __uint24 extension for avr gcc :D
06:04 PM day__ is now known as day
06:38 PM day__ is now known as day
07:13 PM * nuxil has fell in love with directory opus.
07:15 PM nuxil: this fm is real nice. it even rembers the history in the 2nd window. so its real nice when working with files in different directorys :)
07:16 PM nuxil: this what i mean :) https://i.gyazo.com/d1071dc4e1b3585d1a9e3b2a99cf038d.mp4
07:16 PM nuxil: it cost money tho. but there is a 60day trail. just reinstall it after 60days :p
07:31 PM Ameisen: -mint8 can often generate really, really shitty code
07:31 PM Ameisen: the optimizer tends to presume that int fits a pointer
07:44 PM nuxil: well. the only reason i want to try that out. is because Xark suggested it, and it should fix the issue when mixing C and asm.
07:44 PM nuxil: problem now is that a uint8 takes 2 registers when only 1 is needed.
07:46 PM Ameisen: that's why if I need asm, I use inline asm :|
07:46 PM nuxil: inline is awefull :p
07:46 PM Ameisen: wish the compiler had more intrinsics
07:46 PM Ameisen: Honestly, I feel like that should be a requirement for any target to be 'supported'
07:46 PM Ameisen: every instruction must have a compiler intrinsic
07:47 PM nuxil: i tried using some inline. but my brain took a big dump.. i found it much much easyer to just call a asm fnc and write the code in pure asm.
07:47 PM Ameisen: you can get better code from inline asm since you can let the compiler decide register allocation for you
07:47 PM Ameisen: which may be better contextually
07:48 PM nuxil: for this project i do NOT want the compiler to choose any registers for me.
07:48 PM nuxil: :)
07:48 PM Ameisen: That's rather specific.
07:49 PM nuxil: yea. i need full manual control
07:49 PM Ameisen: why?
07:49 PM Ameisen: The compiler knows what registers are in use
07:50 PM Xark: Inline asm is very useful, but it is ugly, tedious and bug-prone. I used mostly that for my "AVR sprite engine" stuff. https://www.youtube.com/watch?v=Imk5ony8JHI
07:50 PM Ameisen: I'd rather just have compiler intrinsics
07:51 PM Ameisen: syntax is much much much cleaner then
07:51 PM nuxil: Ameisen, still working on my dds. and i need to have registers for forward tuning work. accumulator etc. and i like to choose these manualy.
07:51 PM nuxil: *ftw (forward tuning word)
07:51 PM Xark: Ameisen: Well, you can just make a bunch of inline static functions with one inline asm opcode, if you want. However, not good enough for "tight" AVR code (like bit-banging video).
07:51 PM Ameisen: evne with inline asm, you can explicitly tell the compiler not to use certain registers
07:52 PM Ameisen: or to use certain registers
07:52 PM Ameisen: or you can let it allocate them itself
07:52 PM Xark: Ameisen: Yep.
07:52 PM nuxil: i just dont like inline and the cobber list.
07:52 PM nuxil: i find it confusing as f***
07:52 PM nuxil: :D
07:53 PM Ameisen: I do recall that this firmware had a math function written entirely in inline asm
07:53 PM Ameisen: I replaced it with equivalent C++... which ended up faster. And smaller.
07:53 PM Ameisen: :|
07:53 PM nuxil: so that just proves its fully possible to write shitty "asm" aswell :p
07:54 PM Ameisen: Also proves that a lot of people are really bad at writing good C / C++, or don't know how to actually help the compiler.
07:54 PM Ameisen: The code I've seen in this firmware...
07:54 PM Ameisen: :(
07:54 PM Ameisen: A lot of it wouldn't even be acceptable as desktop code, let alone MCU code
07:55 PM * Xark links to AVR sprite code FYI (with lots of inline asm) https://hastebin.com/kivexolaja.cpp
07:57 PM Ameisen: https://github.com/ameisen/Tuna-i3-Plus/blob/master/Tuna/stepper.cpp#L139-L149
07:58 PM Ameisen: This is the original
07:58 PM Ameisen: https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/stepper.cpp#L129-L168
07:58 PM nuxil: Xark, __SFR_OFFSET 0 and you dont need to use _SFR_IO_ADDR . you can put the port directly there. atleast in pure asm.
07:59 PM Xark: nuxil: I had some issues getting it to work in a "string" (and this is what I ended up with).
07:59 PM Xark: nuxil: The other thing is port is a #define
08:00 PM Ameisen: the simpler C++ version ends up way better
08:00 PM Ameisen: also easier to read
08:07 PM nuxil: Xark, http://msoe.us/taylor/tutorial/ce2810/candasm that was helpfull for me when getting started with mixing C & asm. some usefull info there
08:11 PM Xark: nuxil: Thanks. I believe I've seen that (I've been doing gcc inline asm since 68000 days).
08:11 PM nuxil: :D
08:11 PM Xark: nuxil: The tricky part was all the AVRisms (but quasi documented).
08:12 PM Ameisen: A big annoynace with AVR's headers is that they really love defines, &, and turning things into points randomly from integers
08:12 PM Ameisen: which... breaks constexpr.
08:12 PM Ameisen: pointers*
08:12 PM Xark: Ameisen: Yes. Pain with inline asm too (needing to stringize things).
08:13 PM Ameisen: That's somewhere that having actual intrinsics would help
08:14 PM Ameisen: I really don't understand why they just don't make an intrinsic for every instruction
08:14 PM Ameisen: for x86 I can see that being problematic
08:14 PM Ameisen: but for avr?
08:14 PM Xark: Ameisen: That is almost how it is for SSE/AVX etc.
08:14 PM Ameisen: yeah
08:14 PM Ameisen: a lot of instructions randomly have intrinsics in x86
08:14 PM Ameisen: though not all
08:14 PM Ameisen: SIMD ones do because inline asm for SIMD, well, sucks
08:14 PM Ameisen: you separate it too far from the copmiler contextually and the codegen suffers
08:15 PM Xark: Ameisen: I suspect because most AVR instructions are too low-level and simple to be useful by themselves.
08:16 PM Ameisen: Also true. Intrinsics do make it very easy to use them with the rest of the code though
08:16 PM Ameisen: They're the proper solution to not hamfisting in asm into code, or requiring external calls to asm which cannot be inlined
08:16 PM Ameisen: since they actually interact properly with the C/C++ VM
08:16 PM Ameisen: without requiring clobbers/etc
08:17 PM Ameisen: unfortunately, as said, not all instructions have intrinsics
08:25 PM Ameisen: been doing ARM work
08:25 PM Ameisen: won't say I miss the separate address space
08:25 PM Ameisen: 'especially in C++ where they didn't add __flash'
09:09 PM nuxil: haha, -mint8 broke it all :D
09:11 PM Xark: nuxil: Whoopsie. Not too shocked, somewhere assuming type size...
09:12 PM arduiko: Why we need a delay between each HID send report ?
09:12 PM Xark: nuxil: But did it get smaller? :)
09:12 PM arduiko: below 3ms, the device is no more recognized
09:12 PM arduiko: oO
09:12 PM nuxil: Xark, a few bytes :p
09:12 PM nuxil: 3510 vs 3492
09:13 PM Xark: arduiko: Low speed USB keyboard, probably only expects 1 packet per 10ms.
09:13 PM arduiko: I only work with full speed
09:13 PM arduiko: https://social.msdn.microsoft.com/Forums/en-US/61eec8af-c602-4a89-afff-de8ef4e4dc32/why-need-a-delay-between-each-usb-report-data-send-?forum=wdk
09:14 PM Xark: nuxil: I see, so only a few likely places it broke... are you using -flto, BTW?
09:14 PM arduiko: but it make no sense that 1 packet is except per 10 ms
09:15 PM Xark: arduiko: Sure it does. That is speed of USB 1.1
09:15 PM arduiko: because you can set the time between packet sending
09:15 PM arduiko: as I said I don't working with USB 1.1
09:15 PM arduiko: I work with USB 2.0 full speed
09:15 PM nuxil: Xark nop
09:15 PM nuxil: https://pastebin.com/5kdzLTuA
09:15 PM nuxil: my c flags
09:16 PM arduiko: What is your delay ?
09:17 PM arduiko: but even if such rules exist in HID protocole
09:17 PM arduiko: where can we read it into USB documentation
09:17 PM arduiko: I haven't read such rules
09:18 PM Xark: arduiko: In my experience, Windows likes to send 10 USB frames per second.
09:18 PM arduiko: 10 USB frames ?
09:19 PM arduiko: scanning 10 USB device per second ?
09:19 PM Xark: (or 100 with hub and split frames - or whatever they are called)
09:19 PM arduiko: so it's a OS spec
09:19 PM arduiko: ok so msdn forum will be able to anwser why
09:19 PM arduiko: thanks
09:21 PM arduiko: I wonder what is the delay in linux
09:21 PM arduiko: to compare who is the faster x)
09:22 PM Xark: nuxil: Try removing -mint8 and see what -flto does for you...
09:24 PM nuxil: wow.
09:24 PM nuxil: from 3510 to 3378 bytes
09:24 PM nuxil: :D
09:24 PM nuxil: now we are talking :D
09:29 PM Xark: nuxil: Probably didn't break things too much either. :)
09:30 PM Xark: lto = Link Time Optimization (so linker can bake out unneeded crud)
09:30 PM nuxil: nice.
09:33 PM nuxil: was looking for what it meant.
09:33 PM nuxil: https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Option-Summary.html#Option-Summary
09:33 PM nuxil: found it tho
09:34 PM nuxil: i also see. -fmerge-all-constants
09:34 PM nuxil: isnt that a good thing ?
09:36 PM nuxil: meh. no effect.
10:07 PM Xark: nuxil: May already be on, or they already all got merged.
11:17 PM nuxil: Xark, i compiled another code with -flto, this time it gives warnings for my ISR.
11:17 PM nuxil: warning: '_vector_19' appears to be a misspelled signal handler [enabled by default]
11:17 PM nuxil: ISR(SPI_STC_vect) {
11:19 PM Xark: nuxil: I believe that is an ignorable warning. I think it may be fixed in a newer AVR toolchain.
11:20 PM Xark: https://www.avrfreaks.net/forum/use-lto-causes-misspelled-signal-handler-warning
11:20 PM nuxil: ah
11:21 PM nuxil: i got 4.8.1, and its fixed in 4.8.3
11:22 PM Xark: I remember for a while every Arduino sketch was giving me that. :)
11:52 PM day__ is now known as day