#avr Logs
Mar 05 2017
#avr Calendar
12:09 AM daey_ is now known as daey
06:51 AM antto: is an interrupt-driven usart gonna work in a bootloader while you're writing a flash page?
07:06 AM antto: your macbook never sleeps, it watches you
07:07 AM antto: it doesn't even blink!
07:07 AM Thrashbarg: always watching, always plotting
07:24 AM NoHitWonder: is there some reading resource for bootloaders with avrs?
07:24 AM NoHitWonder: application note or something
07:25 AM specing: ofc
07:25 AM NoHitWonder: do you have a link
07:29 AM Lambda_Aurigae: antto, yes....read up on the movable interrupt vector setting...the bootloader has its own interrupt vector table.
07:31 AM antto: Lambda_Aurigae no no.. i already got interrupt-driven usart (with FIFO) working in the bootloader
07:31 AM Lambda_Aurigae: oh..you mean during the write.
07:31 AM Lambda_Aurigae: that could be a problem...
07:32 AM antto: i was asking whether the actual process of "writing a page into flash" would cause the usart to skip a char or something
07:32 AM antto: because i assumed it won't
07:33 AM antto: basically, i have modified a bootloader to accept MIDI, which is rather slow
07:33 AM antto: and only in one direction
07:33 AM NoHitWonder: what youre doing with midi?
07:33 AM antto: so the program on the computer dumps the data without any pauses between the packets
07:33 AM NoHitWonder: synth ?
07:34 AM antto: and the time it takes for a whole flash page to be sent via MIDI is plenty enough for a page to be written, but i wonder if during writing some chars may be lost or something
07:34 AM antto: which i haven't checked
07:35 AM antto: NoHitWonder yeah-ish
07:36 AM NoHitWonder: cool
07:36 AM NoHitWonder: i have a similar project
07:36 AM antto: ehm, it's not mine.. it's adafruit's x0xb0x
07:36 AM NoHitWonder: oh
07:36 AM NoHitWonder: i have that too
07:36 AM antto: but we pimped up the cpu and changed the bootloader
07:36 AM NoHitWonder: almost all the parts
07:37 AM NoHitWonder: i have pcbs + rare parts
07:37 AM NoHitWonder: need to put that thing together some day
07:37 AM antto: cuz the atmega162 is just too f*ckin' small for that thing
07:37 AM NoHitWonder: yeah
07:38 AM Lambda_Aurigae: there's interrupt driven bootloaders where you have an interrupt created by the SPM instruction.
07:38 AM Lambda_Aurigae: not sure.
07:38 AM Lambda_Aurigae: it shouldn't
07:38 AM antto: in my case iirc the flash writing is blocking
07:39 AM antto: it's based on stk500v2
07:40 AM NoHitWonder: i actually looked the xoxbox midi source code for my project
07:41 AM antto: i'm developing my own firmware, so i've changed many of the things from the stock firmware
07:42 AM antto: including the midi, now it's interrupt driven in both directions
07:43 AM antto: NoHitWonder http://antonsavov.net/cms/projects/n0nx0x2.html
07:44 AM NoHitWonder: nice
07:45 AM NoHitWonder: why does that firmware take so much space?
07:45 AM NoHitWonder: or is it a not enough RAM issue?
07:46 AM NoHitWonder: how many kBs is the original firmware?
07:46 AM antto: the original firmware pretty much maxes out the 15.5KB it has
07:47 AM antto: and yet it is very basic, has bugs, and lacks funky features
07:47 AM antto: mine is huge cuz it does a ton of nice things
07:48 AM NoHitWonder: yeah
07:49 AM antto: lots of code space actually goes into LED blinking code ;P~
07:50 AM Thrashbarg: pah! Use a 555 and some passives! </analogue greybeard>
07:51 AM antto: oh yeah, i got some funky 64bit integer division math going on too, and crazy button debouncing
07:51 AM antto: ;P~
07:51 AM Thrashbarg: hehehe
07:52 AM Thrashbarg: the thing is I was only half joking ._.
07:52 AM antto: one of my last "improvements" was to actually double-buffer the 4KB eeprom into RAM
07:52 AM NoHitWonder: so did you re-write it completly?
07:52 AM antto: initially i didn't touch the stuff i didn't understand, so i only added my stuff "around"
07:54 AM antto: but i've been going around the fundamental code and checking it out.. so yeah, there's not much left from the stock firmware anymore
07:54 AM antto: i changed the EEPROM handling, the button debouncing, the LED control, the tempo generation
07:55 AM NoHitWonder: its good that someone works on that very important project. maybe you can fork the project and make a new version of xoxbox, and design a new version with new pcb and the MCU replaed to bigger one.
07:55 AM antto: and i'm not finished yet, there are a few things missing still and room for improvement
07:56 AM antto: well.. let's just say that we're onto something similar ;P~
07:56 AM NoHitWonder: that current firmware is from 2005 so it needs an update
07:56 AM xentrac: Thrashbarg: I'm trying to remember where I saw the advice to debounce buttons with an RC filter
07:56 AM antto: lots of x0xb0xes have been made, so we can't just forget it and make a mk2 pcb
07:56 AM Thrashbarg: xentrac: probably loads of places
07:57 AM xentrac: I only saw it one place
07:57 AM antto: xentrac i'd vote for a RC peakfollower with slow release time
07:57 AM NoHitWonder: is there a pin compatible replacement for that atmega162
07:57 AM NoHitWonder: that you wouldnt need to modify the pcb
07:57 AM antto: NoHitWonder no idea, we use an atmega2561 on an adapter pcb
07:58 AM NoHitWonder: why adapter board? why not just atmega256 DIP package
07:58 AM NoHitWonder: or 128
07:58 AM antto: uhm.. no idea
07:59 AM xentrac: antto: is that where you use a diode to charge the capacitor?
07:59 AM iwancoppa: NoHitWonder: What do you mean by replacement?
07:59 AM antto: i didn't know sh*t about choice of mcus when the adapter was being designed, i only knew i wanted more flash space
08:00 AM xentrac: I feel like the advice to use two or three more circuit board components instead of three to ten more lines of code is very "analogue greybeard"
08:00 AM NoHitWonder: bigger flash, otherwise the same iwancoppa
08:00 AM antto: xentrac yeah or anything similar.. so that it reacts fast when you press it, but rejects noise when you release it
08:00 AM iwancoppa: NoHitWonder: I'd probably suggest that the 164/324/644/1284 are all the same family of MCU
08:01 AM antto: xentrac it will trigger immediately on the first transients of noise when you press the button
08:01 AM iwancoppa: Yep, they are.
08:01 AM NoHitWonder: iwancoppa yes but they must be pin compatible with 162
08:02 AM iwancoppa: Oh derp, 162
08:02 AM antto: are you guys saying there's a pin-compatible atmega to the 162 with more flash and DIP40?
08:02 AM iwancoppa: I read that as 164, might be time to go to bed
08:02 AM NoHitWonder: pheriperals in same pins
08:02 AM NoHitWonder: antto there might be
08:02 AM antto: anyways, the choice has been made, it's too late now.. we're using atmega2561 and it's okay
08:03 AM NoHitWonder: yeah but you can replace that later
08:03 AM NoHitWonder: if you find a match
08:03 AM antto: i managed to put almost everything i wanted, even the whole EEPROM into RAM, and i still got flash space
08:05 AM Thrashbarg: Fact: Hardware is cheaper than software.
08:05 AM Thrashbarg: Contradicting fact: It's cheaper to do hardware stuff in software.
08:06 AM NoHitWonder: it seems that 162 is very different from new avrs
08:06 AM NoHitWonder: so i doubt there is a direct replacement
08:07 AM NoHitWonder: so adapter board is the best choice for now
08:07 AM antto: the folks who had to do this spend quite some time looking for the right chip
08:07 AM antto: so i really think there wasn't a direct DIP40 replacement
08:07 AM iwancoppa: I think the 162 was one-off replacement design for the 16
08:08 AM iwancoppa: doesn't appear to be an AVR family associated with it, so you might need an adapter board
08:08 AM Lambda_Aurigae: 162 is an old style chip.
08:08 AM iwancoppa: I'm sure you can find something in 44QFN that will suit your needs
08:09 AM NoHitWonder: he does have a new mcu, 2561
08:09 AM antto: yeah
08:10 AM antto: if we have to ever switch to yet another chip for some reason, i'd vote for xmega \o/
08:10 AM xentrac: not LPC11xx?
08:10 AM antto: uh..
08:10 AM iwancoppa: NoHitWonder: http://www.microchip.com/wwwproducts/en/ATMEGA1284 is a 44 pin QFN micro with 128kb flash
08:10 AM antto: who's gonna code for that?
08:11 AM NoHitWonder: yeah i have 1284 DIP
08:11 AM iwancoppa: any particular reason for using 40-dip?
08:11 AM NoHitWonder: but antto already has a adapterboard with 2561
08:11 AM NoHitWonder: i like dips
08:12 AM NoHitWonder: i would recommend stm32's, maybe F0
08:12 AM NoHitWonder: they are 5v tolerant
08:14 AM NoHitWonder: new mcu, new pcb and firmware comletely re-written. that would be nice.
08:16 AM NoHitWonder: it feels so wrong to look atmegas on microchip site
08:16 AM xentrac: yeah :(
08:16 AM xentrac: a lot of the appnotes are missing
08:29 AM antto: NoHitWonder i don't speak ARM
08:41 AM * Lambda_Aurigae can speak armpit farts.
08:41 AM Tom_L: ewww
08:44 AM antto: i can do that too
08:44 AM antto: i can even.. fart with my neck
08:44 AM * antto hides
08:47 AM xentrac: ARM is reasonably straightforward, though not quite as nice as AVR
08:47 AM Lambda_Aurigae: setup on arm,,,software wise,,,is waaay more complex.
08:47 AM Lambda_Aurigae: configuring peripherals can be a pain.
08:48 AM Lambda_Aurigae: once you get past that they aren't bad.
08:48 AM antto: i once looked into it.. it requires some crazy a$$ asm stuff
08:52 AM NoHitWonder: it isnt that different from AVRs
08:52 AM NoHitWonder: putting data to registers, same as with AVRs
08:53 AM antto: i don't think i've had anything code-related easier than AVR
08:54 AM antto: i mean.. i hadn't even heard about AVR or embedded stuff, i bought a synth, figured the "program" can be modified - found a page which said "you need these tools here" .. grabbed them, installed them, recompiled the thing, got some "hex" file out of the whole thing.. flashed it - boom it worked
08:55 AM antto: i still can't believe how easy it was given that i had no clue what i'm doing
08:55 AM NoHitWonder: cool :D
08:57 AM antto: wow.. it's been 7 years since then
08:57 AM * antto == old fart
09:11 AM NoHitWonder: i started with AVRs in 2006
09:12 AM NoHitWonder: we used them at school
09:12 AM NoHitWonder: it was cool to do ASM projects with them
09:27 AM xentrac: I think I started with them in 2004 or 2005
09:27 AM xentrac: but there are probably people here who started with them last year who know more than I do
09:27 AM NoHitWonder: i doubt that
09:28 AM NoHitWonder: it takes time to learn MCUs properly
09:28 AM xentrac: yeah, but I've been spending that time on other things
09:29 AM NoHitWonder: i have too, but its like riding a bicycle
09:29 AM antto: i don't talk ASM either
09:29 AM NoHitWonder: once you learn them...
09:30 AM antto: i come from mIRC scripting.. that's the first "language" i learned
09:30 AM NoHitWonder: i wrote my first code with Basic on C64
09:30 AM xentrac: I did http://canonical.org/~kragen/light_sensing in 2006
09:30 AM NoHitWonder: but back then i didnt understand what i was doing
09:31 AM NoHitWonder: ASM and C were my first languages
09:31 AM xentrac: yeah, I spent a lot of years programming very badly
09:32 AM NoHitWonder: xentrac nice
09:33 AM NoHitWonder: antto AVR ASM its pretty easy to learn
09:34 AM NoHitWonder: i would recommend doing a simple project with it
09:34 AM antto: i don't have time for playing around tho
09:34 AM xentrac: you won't learn anything ever then
09:34 AM antto: i play around with C++
09:35 AM xentrac: good!
09:35 AM antto: i can't learn every language there is
09:35 AM antto: and afaik ASM is not one single thing
09:35 AM xentrac: no. some assembly language would be a good idea for understanding C++ though
09:36 AM xentrac: there isn't that much difference at the user level between AVR assembly and, say, amd64 asembly
09:36 AM antto: i understand NOP ;P~
09:36 AM antto: nop nop nop nop
09:36 AM xentrac: was your synth an x0xb0x?
09:37 AM antto: yez
09:37 AM antto: there's some NOPs in the C code ;P~
09:38 AM xentrac: that's cool
09:38 AM xentrac: I think the x0xb0x actually predates adafruit as a company
09:38 AM antto: yes.. it was "ladyada x0xb0x"
09:39 AM xentrac: yeah
09:41 AM NoHitWonder: i think ladyada gave the project to this guy http://willzyx.com/index.php?
09:42 AM NoHitWonder: but you should update it antto
09:43 AM NoHitWonder: (that willzyx is maintained by some taiwanese guy)
09:43 AM NoHitWonder: (i think)
09:43 AM antto: NoHitWonder nah.. they didn't "give" the project to anyone.. the project is MIT licensed
09:43 AM NoHitWonder: i think they did
09:44 AM antto: they just at one point decided to no longer make kits, and gave their existing parts to that guy and gave him an official thumbs up to make kits
09:44 AM xentrac: hmm, I think the MiniPOV2 was products_id=1 on the adafruit site
09:44 AM antto: but anyone can make kits
09:44 AM NoHitWonder: yes that's what i meant
09:44 AM xentrac: which was a bit before the x0xb0x
09:44 AM xentrac: but I think that was before the company
09:48 AM antto: i don't know much about adafruit and the other projects, i'm all about the synth, which isn't any old synth.. it's a clone of a legendary synth..
09:49 AM NoHitWonder: yeah that's why the project is important
09:49 AM NoHitWonder: soon you cant find 303s anymore
09:49 AM NoHitWonder: or they will be so expensive
09:52 AM antto: well there are a pile of 303 clones available today, besides this one
09:52 AM antto: but this one is the only open-source one
09:53 AM NoHitWonder: only that matters
09:54 AM NoHitWonder: open source one
09:54 AM antto: well that means it's gonna stay for as long as anyone wants it
09:55 AM NoHitWonder: yeah but someone should update it to new MCU's
09:55 AM NoHitWonder: like youre doing
09:55 AM antto: we've done that..
09:55 AM antto: folks can buy the cpu and plug it in if they want
09:56 AM NoHitWonder: yeah
10:02 AM NoHitWonder: but i dont think its a long term solution
10:03 AM NoHitWonder: xoxbox v2 would be nice
10:03 AM antto: it won't help the existing hundreds of x0xb0xes
10:03 AM NoHitWonder: yeah but for new builds
10:04 AM antto: well, we may be onto something in that direction
10:04 AM antto: but it's still early to say
10:04 AM NoHitWonder: yeah
10:06 AM xentrac: :)
10:08 AM NoHitWonder: man im waiting for next fall
10:09 AM NoHitWonder: so antto youre not paul?
10:10 AM NoHitWonder: paul is someone you work with?
10:10 AM antto: wat?!
10:10 AM antto: paul?
10:11 AM * antto is antto
10:12 AM NoHitWonder: that youtube video
10:12 AM NoHitWonder: is on paul's channel
10:12 AM NoHitWonder: cpu replacement video
10:12 AM NoHitWonder: or is he just a customer?
10:12 AM antto: oh.. pulsar?
10:13 AM NoHitWonder: ?
10:14 AM antto: what video then
10:14 AM NoHitWonder: you have a video of cpu replacement in your website and its made by paul
10:14 AM antto: then that must be pulsar256
10:15 AM NoHitWonder: http://antonsavov.net/cms/projects/x0xb0x-cpumod.html
10:15 AM antto: he's one of the "happy customers"
10:15 AM NoHitWonder: ok
10:15 AM antto: he helped too
10:21 AM antto: he also hangs at the channel
10:22 AM NoHitWonder: ok cool
10:49 AM _abc_: .
10:50 AM Chillum: ..
10:50 AM _abc_: Okay, I am miffed by avr-gcc. Without using uint64_t anywhere, code compiles to ~2.5kBytes, with ONE instance of uint64_t ll = ( x * y + const1 ) / const 2; it is 6.6 kBytes. Anyone care to comment?
10:51 AM _abc_: Note the 2.5k code already contains a lot of other things, just this change is made, from uint32_t to uint64_t calculation. Suddenly, boom, huge flash consumption. I assume the compiler pulls in a large math lib?
10:51 AM _abc_: Comments on how this can be improved a bit, if at all?
10:51 AM _abc_: If I write out the 64 bit op by hand the code resulting is much smaller.
10:54 AM antto: x and y are variables?
11:48 AM _abc_: one of them is a constant. ( x * const1 + const2 ) / const3 actually
11:48 AM _abc_: Which makes the sting of the extra size so much more obvious
11:48 AM _abc_: @ antto
11:49 AM _abc_: I can't justify 4000 bytes of code for one uint64_t mult, one add, one divide, even if written in java and compiled to brainf* but what do I know
11:51 AM LeoNerd: _abc_: gcc is similarly stupid on attiny when it comes to multiplication
11:51 AM LeoNerd: x*2 => turns into a single SHL
11:51 AM LeoNerd: x*4 => turns into two SHL
11:51 AM LeoNerd: x*3 => becomes a call to the __mult function that takes 3 as an argument and runs the entire generic multiply algorithm
11:52 AM LeoNerd: I rewrite that as x+(x*2) and suddenly it's a SHL+ADD pair
11:53 AM LeoNerd: Though that doesn't save much code, when I have an array of structs, whose elements are 3 bytes long. The /implicit/ multiplcation that it performs with arr[i] is still implemented as a call to __mult and I can't do a thing about it
11:53 AM LeoNerd: If I add a stupid padding byte to my struct, making it 4 bytes long, then the flash code becomes smaller, faster, but I waste RAM. RAM I can ill afford on such an ATtiny
11:55 AM cehteh: huh? on avr?
11:56 AM cehteh: i thought there are no alignment issues on avr's
12:00 PM Ad0: LeoNerd: ASM time? :)
12:38 PM _abc_: 19:30 < Ad0> LeoNerd: ASM time? :)
12:38 PM _abc_: 20:05 < _abc_> LeoNerd: what Ad0 said, for me too
12:38 PM _abc_: 20:05 * _abc_ groans
12:40 PM * _abc_ groans more after the /title hackaday.io url drives his firefox load to 3.0+
12:43 PM specing: _abc_: no NoScript?
12:44 PM _abc_: NoScript is on. The background images are uncropped etc. HUGE load
12:44 PM _abc_: size-wise.
12:44 PM _abc_: People forgot what cropping and scaling is since there are 14MP cameras on every corner.
12:44 PM specing: Lol
12:44 PM _abc_: http://www.dailymail.co.uk/news/article-4283330/Smart-metres-said-customers-charged-33-000-day.html wow someone made a coding mistake
12:45 PM specing: s/mistake/"mistake"/
12:45 PM _abc_: Yeah, so what if you upload a 14MP pic of a speck of dirt on your structured design patterned table? Just <img src="..." height=1024 width=768> and it's someone else's problem.
12:46 PM _abc_: And since one works, do this with all 14 pics in your project, and a few more from the theme
12:46 PM _abc_: specing: that was probably a legit mistake.
12:47 PM _abc_: It's fun to read a consumption in the 2GWh range per day... just imagine the cables that would require to enter the premises and the heat - the relevant housing unit would glow blue white hot
12:50 PM specing: maybe it is just a coverup for fusion reactor testing
12:50 PM _abc_: specing: then it would have to indicate negative consumption in case of success?
12:51 PM _abc_: Anyway, back to numbers. uint64_t stuff emulated using uint32_t ? Anyone done it?
12:52 PM specing: gcc does it every day
12:52 PM rue_house: yea, there is nothing like over-the-wire auto software updates
12:52 PM rue_house: just put on a blind fold and push 'em out
12:53 PM rue_house: _abc_,
12:53 PM rue_house: isn't long long unsigned int 64 bit?
12:53 PM _abc_: yes. And adds 4000 bytes to the code size.
12:54 PM rue_house: naaa, the 4k is cause you used a floating point math fucntion
12:54 PM _abc_: No
12:54 PM rue_house: ?
12:54 PM _abc_: uint64_t
12:54 PM rue_house: long long unsigned int
12:54 PM _abc_: Can you scroll up and see or do I report?
12:55 PM rue_house: let me try to just prove you wrong
12:55 PM _abc_: I literally use uint64_t. The following operation is the only one used: uint64_t y = ( (uint64_t) x * (uint64_t) const1 + (uint64_t)const2 ) / (uint64_t) const3 )
12:56 PM rue_house: its prolly the divide that did it to you
12:56 PM _abc_: This grows the code from 2.4KB with uint32_t y to 6.5kB with the above
12:56 PM rue_house: mutiply might have too
12:56 PM _abc_: rue_house: dividing with a constant is expensive since when?
12:56 PM _abc_: *by a
12:56 PM rue_house: since lazy coders use generic functions to do it
12:57 PM rue_house: (in glib)
12:57 PM _abc_: ... okay show me a better way? Or link?
12:57 PM _abc_: Oh that. Yes.
12:57 PM rue_house: whats your constant?
12:57 PM rue_house: wait asec
12:57 PM * rue_house aquints
12:57 PM _abc_: constant1 is ~80000 currently const2 is 50 const3 is 100
12:57 PM rue_house: whats the REASULT of your constants
12:57 PM _abc_: The what?
12:58 PM _abc_: Basically x * const1 can reach a range of 44 bits
12:58 PM rue_house: so, x*80000+(50/100)
12:58 PM _abc_: under some circumstances. Normally it is ~40 bits.
12:58 PM _abc_: rue_house: no, (x*80000+50)/100
12:58 PM rue_house: so x*40000
12:58 PM rue_house: oh
12:59 PM _abc_: But those are just nice round numbers I put up here for example. The real numbers are ugly calibration constants
12:59 PM rue_house: so, x*800+0.5
12:59 PM _abc_: nope, this is integer only, no floats
12:59 PM rue_house: right
12:59 PM rue_house: so, x*800+1
12:59 PM _abc_: ...
01:00 PM _abc_: nope...
01:00 PM rue_house: 80000x/100 + 50/100
01:00 PM _abc_: in integer math the +50 above serves to compensate for rounding.
01:00 PM rue_house: 800x/1 + 0.5
01:00 PM rue_house: mmm
01:00 PM _abc_: You are not to remove it from there. And stop writing anything with a decimal dot, those things are not existing in integer math
01:01 PM rue_house: your doing fixedpoint aren't you
01:01 PM * _abc_ bright lightbulb flash
01:02 PM _abc_: I can write it from scratch, no problem, but... why. Also, this begs for an asm solution.
01:02 PM rue_house: so how about (x*51200+32)/128
01:02 PM _abc_: https://www.motherboardpoint.com/threads/need-c-source-for-64-bit-integer-math-have-32bit-limit-on-my-compiler.240260/
01:02 PM rue_house: so how about (x*51200+32)/128
01:02 PM rue_house: sadkjfhkasdf
01:02 PM rue_house: er
01:03 PM rue_house: damnit
01:03 PM rue_house: so how about (x*51200+32)/64
01:03 PM _abc_: again, ignore my numbers. They are examples. It could be 51765+73/93
01:03 PM _abc_: So no point in optimizing. It won't work.
01:03 PM rue_house: instead of using decimal floating (of 100) on a binary computer, use 64
01:03 PM _abc_: I need to deal with hundredths.
01:04 PM rue_house: the divide by 64 will just be a shift
01:04 PM antto: if your divisor is a constant, then there's a chance for optimization
01:04 PM _abc_: Division is not a problem. Optimization beyond the point shown above is not possible, sorry.
01:04 PM _abc_: My spreadsheet would not lie to me.
01:04 PM rue_house: do you actaully need the dicimal places?
01:05 PM _abc_: Let's concentrate on the real question: How does one mage avr-gcc implement uint64_t y = ( x * c1 + c2 ) / c3; without growing code size by 4000 bytes
01:05 PM _abc_: *make
01:05 PM rue_house: no
01:05 PM rue_house: look at the asm
01:05 PM rue_house: it adds a bunch of ugly math functions to do it
01:05 PM _abc_: I will, lacking choices.
01:06 PM _abc_: *lacking realistic choices
01:06 PM _abc_: https://www.motherboardpoint.com/threads/need-c-source-for-64-bit-integer-math-have-32bit-limit-on-my-compiler.240260/ please take a look in here before continuing the discussion.
01:07 PM rue_house: damnit Icant type worth &&&&& this morning
01:07 PM rue_house: kjasdfhkoasjdhf ******
01:07 PM _abc_: Oh you're still waking up? Wait for the joey effect.
01:07 PM rue_house: I dont know if gcc will filter out what I'm about to try
01:08 PM specing: gcc is really retarded when it comes to integers
01:09 PM antto: tell him to use Ada ;P~
01:09 PM * _abc_ makes antto write his next 10 projects in Python
01:09 PM antto: noooooooooooo
01:09 PM antto: that hurts :~(
01:10 PM _abc_: man who sleep with snake sleep long time (seen on the internet)
01:10 PM antto: i sleep with cat ;P~
01:11 PM rue_house: damnit, its being too smart
01:11 PM specing: antto: the best compiler for Ada is GCC
01:11 PM specing: antto: the problem persists
01:11 PM _abc_: rue_house: you mean stupid.
01:11 PM specing: even in Ada
01:11 PM antto: hm
01:11 PM specing: Python actually has proper integers
01:11 PM specing: unlimited
01:11 PM antto: does Ada compile into C and then the C is compiled as usual?
01:11 PM rue_house: no, it knows the value I'm trying to do the math on dosn't change and its just using the reasulting constant
01:11 PM _abc_: rue_house: every time compiler optimizations wins when I pit my wits against it, I am reminded of space oddisey 2001: HAL: "Dave, I can't let you do that"
01:11 PM specing: antto: no
01:12 PM antto: then does C compile into Ada? ;P~
01:12 PM specing: no
01:12 PM _abc_: antto: no.
01:12 PM _abc_: Everything gcc understands is converted into RTL language and then turned into asm or whatever by a back end compiler tool part of gcc
01:12 PM antto: i guessed wrong two times, but each time differently >:)
01:13 PM antto: hah
01:13 PM _abc_: RTL is not a bad thing to learn but it seems to change a bit between versions
01:13 PM antto: i thought i read that llvm works like that?
01:13 PM antto: and i had the impression that llvm is the only such compiler
01:13 PM _abc_: antto: all multi front end multi back end compilers do
01:13 PM antto: funky then
01:14 PM rue_house: _abc_, are you compiling with -lm ?
01:14 PM antto: ouch
01:14 PM _abc_: no!
01:15 PM rue_house: 807 main.hex <-- without maths
01:15 PM _abc_: ??
01:15 PM rue_house: 823 main.hex
01:15 PM rue_house: eith maths
01:15 PM antto: i hate to say this but.. can you look at the asm code and find any answers there?
01:15 PM rue_house: maybe if I try long long
01:15 PM _abc_: https://gcc.gnu.org/onlinedocs/gccint/RTL.html antto have fun
01:15 PM _abc_: antto: there are compiler flags to make it dump RTL
01:15 PM _abc_: see man gcc
01:16 PM rue_house: I only get a 23 byte difference in the hex file when I do a multiply
01:16 PM _abc_: antto: I did not, am not about to read 6.5k of code without asking others 1st. I will, if all else fails.
01:16 PM rue_house: your getting 4k?
01:16 PM _abc_: rue_house: yes, but did you cast the inputs to uint32_t ? And made them volatile so they do not get optimized out?
01:17 PM _abc_: Wait, I'll provide a bit of sample code to play with.
01:17 PM _abc_: Give me a few minutes
01:17 PM rue_house: I'm just putting math into a program I have that flashes an led
01:18 PM antto: _abc_ i use uint64_t math with ugly division and sh*t in my firmware, but i don't know/care if the size grew
01:18 PM rue_house: oh here we go
01:18 PM antto: so i don't think i can help
01:18 PM rue_house: a 2k jump
01:18 PM rue_house: <__umoddi3>
01:18 PM rue_house: <__udivdi3>
01:18 PM rue_house: <__udivdi3_umoddi3>
01:18 PM rue_house: <__udivmod64>
01:18 PM rue_house: <__ashldi3>
01:19 PM rue_house: <__adddi3>
01:19 PM rue_house: <__adddi3_s8>
01:19 PM rue_house: <__subdi3>
01:19 PM rue_house: that added 2k
01:19 PM rue_house: (to the ihex file)
01:20 PM rue_house: _abc_, so WHAT are you doing with the result, your not using it as a x100 fixed point number
01:20 PM rue_house: so what does it matter if you do the fixed point as x64 instead of x100
01:21 PM rue_house: (a*k+(k/2))/k
01:21 PM rue_house: it wont matter much if k is 100 or 64
01:21 PM rue_house: and 64 should reduce it down to shift operations
01:21 PM rue_house: YES!?NO?!
01:22 PM rue_house: (a*320*k+(k/2))/k
01:22 PM * rue_house clears throat
01:24 PM _abc_: http://188.27.65.62:8881/mypaste/bb6c38eabb49c833db73 rue_house
01:24 PM _abc_: rue_house: I'm using the 32 bit result as is, and yes it is a fixed point x100 number.
01:25 PM _abc_: I can try what you suggest but I have a hunch it won't change much. Add 2000 bytes instead of 4000 maybe?
01:25 PM _abc_: Please see the paste
01:25 PM rue_house: no because your dividing back by the 100
01:25 PM rue_house: it will if you use >> and << instead of / and *
01:25 PM _abc_: So I'll try /64 as you say. Need to plug it into the spreadsheet, to see how it affects error. Even then, 64 bit multiply will be present
01:26 PM rue_house: with a k of 64 or 128 instead of 100
01:26 PM rue_house: theres no multiply or divide tho, just shift
01:26 PM rue_house: there is an add, if gcc cant work that out, we should all go back to assembler
01:27 PM rue_house: and your goal is to use 64 bits or 32 bits?
01:28 PM antto: he needs 32bits but he needs more precision to calculate that 32bit value
01:28 PM antto: i have the same sort of problem too
01:28 PM antto: but.. i did not actually care if the code grew or not
01:29 PM rue_house: zippo:/files/programming/c/tests# calc "(88765/100)*64"
01:29 PM rue_house: (88765/100)*64 -->> 56809.6
01:30 PM _abc_: Ok found the mistake, and good idea with /64. The mistake was I was doing & 0xFFFFFFFFL <- some place. Should be 'U' not 'L'.
01:30 PM _abc_: rue_house: the range of x * K1 is up to 41 bits or so, reduces to 32 bits after the computation.
01:31 PM _abc_: Now I get from 2.4k to 3.3k. Very acceptable.
01:31 PM antto: i got a bunch of ugly 32bit int math and finally uint32_t x = (uint64_t)(some_const) / (a/b);
01:31 PM rue_house: I was going to suggest 128, but I dont know if that overflows anything
01:31 PM _abc_: So, again, the fix was 0xFFFFFFFFU instead of 0xFFFFFFFFL
01:31 PM antto: where a is 64bit, b is 32bit
01:31 PM rue_house: did you use << and >>
01:31 PM _abc_: not yet
01:31 PM rue_house: it should take 1 or 2k off it
01:31 PM antto: FFFFFFFFFFUUUUUUUUUUU
01:32 PM antto: y u no use (uint32_t)(-1) btw?
01:36 PM rue_house: _abc_, I ran the calc from x=0 to 32768 with that k factor of 100 and 64, there was no difference in the results
01:36 PM _abc_: you were right, 0xFFFFFFFFL makes no difference, /64 does.
01:36 PM _abc_: No need to code a shift, gcc gets it as is
01:36 PM _abc_: rue_house: ^
01:36 PM rue_house: ok
01:36 PM _abc_: thanks for the tip, it shows you woke up ;)
01:37 PM rue_house: maybe a little
01:37 PM _abc_: So now code goes from 2.4k 32bit to 3.2k 64 bit as above, all is well
01:37 PM rue_house: ok...
01:37 PM _abc_: Interesting what a rabbithole this is. Not fun at all to discover in the middle of a project
01:37 PM rue_house: still sounds like there is an evil math op
01:37 PM _abc_: What if I have to divide by a prime? Sigh
01:38 PM _abc_: I tested it, just going from the /64 to /100 code, same thing elsewhere, gets me to +4k
01:38 PM _abc_: So you may be right, some lazy coder will have pulled in some non integer lib to divide with
01:39 PM rue_house: http://paste.debian.net/918243/
01:39 PM rue_house: on the PC with the output catd' to a file between const3 = 64 and 100
01:39 PM rue_house: with diff
01:40 PM _abc_: rue_house: the paste contains the source code only
01:40 PM _abc_: Oh I see what you dud
01:40 PM _abc_: *did
01:42 PM _abc_: Strange happenings. Anyway, thanks all. Done for tonight. Will test the /64 code 2morrow.
01:44 PM _abc_: fwiw the compiler outputs exactly the same code for /64 and >> 6
01:45 PM rue_house: yea I just ran it on the pc to get the numbers
01:45 PM rue_house: hah it was apt, go figure
01:48 PM _abc_: .lst file shosw things like ' call 0x91e ; 0x91e <__muldi3>' and 'call 0xab2 ; 0xab2 <__lshrdi3>'
01:49 PM _abc_: Where are the sources for these libs? Online, unpacked? lshrdi3() looks interesting, I think it shifts both ways?
01:49 PM _abc_: hmm it should shift right not left. Wtf
01:50 PM _abc_: https://www.student.cs.uwaterloo.ca/~cs350/common/os161-src-html/doxygen/html/lshrdi3_8c_source.html ok
01:51 PM _abc_: Nice. I assume gcc uses an asm version of that. I hope.
01:53 PM * _abc_ notes that gcc's RTL is LISPish. What was that about every computer program hiding a small, incomplete, and buggy LISP interpreter? (old saying)
01:54 PM _abc_: I am willing to bet all future languages will embed a secret, incomplete Java interpreter, or Javascript, since that's what kids learn now.
01:54 PM Lambda_Aurigae: _abc_, did you know that the avr32 chips had a java bytecode interpreter in hardware?
01:55 PM _abc_: Lambda_Aurigae: had? /me shudders.
01:55 PM Lambda_Aurigae: dunno if they are still made
01:55 PM Lambda_Aurigae: might be...
01:55 PM Lambda_Aurigae: haven't looked recently
01:56 PM _abc_: Testing more rue_house : with /100 mode, the .lst has 'call 0x932 ; 0x932 <__muldi3>' 'call 0xac6 ; 0xac6 <__udivdi3>' '
01:56 PM _abc_: rue_house: so that __udivdi3() must be one piece of hooey. Also the compiler calls those funcs but does the +const2 in place, all 64 bit glory, inline code. 8*10~=80 bytes for that alone
01:57 PM _abc_: Lambda_Aurigae: Sun/Oracle had a tiny embedded thing with native Java bytecode runner on it, very expensive
01:59 PM _abc_: https://en.wikipedia.org/wiki/Java_processor Lambda_Aurigae fyi
01:59 PM _abc_: I think the picojava was the eye poppingly expensive one
01:59 PM Lambda_Aurigae: fun fun
01:59 PM _abc_: The devel kit board was like $250 or so. Insane
02:00 PM _abc_: https://en.wikipedia.org/wiki/Jazelle this is much more relevant now
02:00 PM _abc_: Probably in every phone out there
02:01 PM _abc_: BXJ is fun
02:03 PM _abc_: So the 64 bit inline gcc asm for +100 is ~60 bytes not 80
02:10 PM Rickta59: are you running out of code space _abc_ ?
02:10 PM _abc_: It looks like I will have to spend a lot more time checking out -Ox optimization effect on my code. Will probably autmate it since it is boring to watch
02:11 PM _abc_: Rickta59: nowhere near that, but I always keep tabs on the "fat". That /100 thing increases code size by 3.3k, essentially doubling it.
02:11 PM _abc_: Development is being done on a 328 so no problems but later it will matter
02:12 PM _abc_: buy 100 '8 or '16 is different from 100 '328
02:33 PM Tachyon` is now known as Tachaway
03:10 PM julius: hi
03:11 PM julius: what are some common reasons for a voltage drop from ~3.2v to ~1.7v when a led is connected via a 50ohm resistor to a stm32 output pin
03:12 PM Tom_L: resistor wrong value?
03:12 PM Tom_L: bad pin
03:12 PM Tom_L: pin set to input instead of output
03:15 PM specing: resistor too small
03:16 PM specing: 70 mA at 3v3 for 50 ohm
03:16 PM specing: stm32 pin cannot output 70 mA so the voltage drops
03:17 PM plouf: but if its in series with a led
03:17 PM plouf: led has 1,7 votlage drop
03:18 PM plouf: therefore there is 1,5/50 =
03:18 PM plouf: 30mA
03:18 PM plouf: dont know how stm32 works however
03:19 PM specing: magic smoke I tell ya
03:30 PM Ad0: lol
03:30 PM Ad0: transistor time?
03:32 PM julius: according to google the green led needs 2,1V, so i need to get rid of ~1V on the output. so: (3.3-2.1)/0.03
03:33 PM julius: which would be 40ohm...50 isnt that far away...still the led is very dark, barely going on
03:33 PM julius: the port can output 25maA
03:37 PM cehteh: pin wrong configured? do you only enable pullup?
03:38 PM cehteh: also stm32 isnt that robust driving much load on i/o pins, you cant compare that with a avr
03:38 PM cehteh: better use a driver
03:39 PM Ad0: just use a transistor
03:46 PM julius: ok
03:47 PM julius: cehteh, first example...let me check the docs
04:03 PM julius: fuck im to tired right now
04:03 PM julius: gonna do that tomorrow
04:04 PM antto: docs: i'm f*ckin' tired of your sheetz!
04:25 PM pitastrudl: if you use the INCREASE instruction on a register that is full, the Carry bit does not trigger
04:25 PM pitastrudl: but does the extra bit get removed or does the increased register contain a 1
04:28 PM Ad0: antto: haha
04:28 PM NoHitWonder: i think it does contain 1
04:28 PM NoHitWonder: if i remeber correctly
04:40 PM _abc_: Just one thing: I referenced Greesnpun's tenth rule indirectly today, wrt LISPish RTL in avr-gcc. https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule . This is the full ref. And, there's another mini LISP inside avrdude. The command *list* to be ...
04:41 PM _abc_: ... processed is built using lisp like primitives...
04:41 PM * _abc_ quits again
05:59 PM daey_ is now known as daey
06:11 PM JanC is now known as Guest33463
06:11 PM JanC_ is now known as JanC
08:12 PM rue_house: pitastrudl, I think if you want a carry flag you might have to use ADD
08:44 PM Thrashbarg_ is now known as Thrashbarg
10:33 PM Thrashbarg_ is now known as Thrashbarg
11:49 PM daey_ is now known as daey