#avr Logs

Dec 16 2018

01:16 AM [1]MrMobius is now known as MrMobius
04:49 PM cehteh: anyone of you has a very fast unsigned 32 bit division routine, no frills, dont need remainder, could be slightly inprecise .. but must be fast
04:53 PM timemage: cehteh, i don't, but i have used the thing of doing (somewhat imprecise) division by multiplication, mostly with constant. basically fixed multiplication to perform division.
04:54 PM timemage: s/fixed/fixed point/
04:55 PM cehteh: i should check the value ranges if thats viable
04:58 PM timemage: cehteh, yeah, it may not be practical. iirc division of 16bit numbers by small integer constants like 3 or 5 work okay.
04:58 PM cehteh: its rather much larger
04:58 PM timemage: cehteh, yeah, well, you'll have to investigate.
04:59 PM cehteh: but how fast is 64 bit multiplication compared to 32 bit division ... maybe i can even doctor some 48bit thing
05:00 PM cehteh: interestingly the final result is only 16 bit
05:00 PM timemage: cehteh, i expect a fair bit faster.
05:01 PM cehteh: i mean guranteed to be its 32/32 with both 32bit numers in a range that the result never exceeds 16 bit
05:02 PM cehteh: while 64bit integers needs shitloads of memory on a avr :D
05:03 PM timemage: cehteh, what are you calculating?
05:03 PM cehteh: still revisiting the stepper slope generation
05:04 PM cehteh: https://public.pipapo.org/stepper2.png
05:05 PM cehteh: red is position, blue is speed
05:07 PM cehteh: i am at about 10khz pulses now .. thats barely enough, faster would be better
05:08 PM timemage: cehteh, hmm, i wasn't part of whatever conversation you might have had before on this.
05:08 PM cehteh: i talked with rue about it
05:09 PM timemage: cehteh, i'm sure i should just know this, but what is being divided?
05:12 PM cehteh: basically its 1/speed = accel_factor/(position-start) + decel_factor/(end-position)
05:12 PM cehteh: w/ some adjustments
05:14 PM timemage: cehteh, think i got you. i haven't really played with steppers much. but you're motion planning or whatever so as not to lose steps or something yeah?
05:14 PM cehteh: positions are 32 bit .. length to travel can exceed 64k steps, speed and accel/decel factors are 16 bit
05:14 PM cehteh: motion planning later, for now just acceleration/deceleration profilesa
05:15 PM cehteh: i pretty much think this works, just the caclulation could be optimized/faster
05:23 PM timemage: cehteh, you pretty much just have to stay under the curve right?
05:23 PM timemage: cehteh, the blue, i mean.
05:23 PM cehteh: yep
05:24 PM cehteh: well i am running that curve
05:24 PM cehteh: no sharp changes in speed
05:25 PM cehteh: accelerating, the faster youi go the less acceleration then running at somewhat constant speed and finally decelerate
05:26 PM cehteh: as yoiu see the constant speed isnt 100% constant, but thats not bad, counters resonances as well and doesnt affect the overall time to cover the distance
05:29 PM timemage: cehteh, something has me wondering if there isn't a dda/cordic method type thing you could do. i'm not really thinking that clearly now though.
05:30 PM cehteh: i am not that good with math thati know that stuff
05:30 PM cehteh: i know cordic exists :D
05:32 PM cehteh: i doubt that codic can simplify that ... reading about it
05:32 PM cehteh: its only a division
05:33 PM timemage: cehteh, yeah, i'm wondering if there insn't a way to avoid division though. i know cordic methods are sometimes used to calculate things where you otherwise might calculate taylor series out to so many terms, iirc involving division.
05:33 PM timemage: cehteh, anyway, just a weird idea.
05:34 PM cehteh: i am fine with one division instead 2
05:35 PM cehteh: i started implementing it in an iterative/algorithmic way dividing the slope in 3 parts accel/constant/decel
05:35 PM cehteh: that needs only one division, but the slope is not as nice and matching the ends of these formulas is PITA
05:36 PM cehteh: https://public.pipapo.org/stepper5.png
05:37 PM cehteh: got that far even with different start and end speeds, but as soon there is no constant part in the middle things become ugly
05:37 PM cehteh: because the begin of the acceleration shall stay constant (thats where it can gain speed safely)
05:38 PM cehteh: also when snanging the factors things start to look ugly in some or another way
05:38 PM cehteh: changing
05:47 PM timemage: heh, i have articles on this stuff that i'd bookmarked sometime before early 2016. so, i was reading about it at some point.
05:49 PM cehteh: there is this 'austin' thing which does some fancy 24/8 fixed point math .... but has one division too in the example code and does not so nice ramping (the example code) the article about it describes ramping, but implementing it would need more divisions as well
05:49 PM cehteh: i wonder what its worth :)
05:49 PM cehteh: smoothing i mean
05:50 PM cehteh: https://www.embedded.com/design/mcus-processors-and-socs/4006438/Generate-stepper-motor-speed-profiles-in-real-time#
05:50 PM cehteh: that one
05:50 PM timemage: yup. that's marked
05:51 PM cehteh: it failed to make some impression to me :D
05:51 PM timemage: cehteh, i have a weird custom system for tracking those things i sort of call bookmarking. for a long time i didn't have dates on the entries. and that's one of the ones that has no date. so it's been in there for a while. isn't marked as read though.
06:22 PM cehteh: timemage: using multiplication instad of division means i need to calculate the reciprocal of the dividend ... no win, unless you know a clever way to to that
06:24 PM timemage: cehteh, right, when i've done this it's been with fixed number or where that can be done once.
06:25 PM timemage: cehteh, erm, by fixed there i mean constant.
06:25 PM timemage: cehteh, in other words, where you don't have to do that, or where you do but it's amortized by however many times you do the multiplication instead after having done that.
06:27 PM cehteh: so wont work
06:29 PM cehteh: could think if the caclulation could be done in reciprocal form the whole way
06:29 PM cehteh: but i have some doubts
07:08 PM rue_mohr: what you trying to calc?
07:20 PM cehteh: a = b/c + d/e
07:21 PM rue_mohr: are any of the values constant?
07:21 PM cehteh: no
07:21 PM rue_mohr: how many bits?
07:21 PM cehteh: b and d can be prepared, doing that already
07:22 PM cehteh: a = b/c + d/e +f ... forgot about f :D
07:22 PM rue_mohr: so, its a = b*(1/c) + d*(1/e) + f
07:22 PM cehteh: well its bit more b c d e are single simple expressions with additions and multiplications
07:23 PM cehteh: yes
07:23 PM rue_mohr: 1+1 = 3 for large values of 1
07:23 PM cehteh: well the divisions nagging me
07:23 PM rue_mohr: so, tell me the actual formula your workin on!
07:24 PM cehteh: its pretty much that
07:24 PM rue_mohr: how many bits?
07:24 PM rue_mohr: are they complex numbers?
07:24 PM cehteh: a is 16 bits, the others are 32 bits ..
07:24 PM cehteh: no
07:25 PM cehteh: we still talking about the stepper thing
07:25 PM rue_mohr: why would you prefer to do c/b instead of b/c?
07:26 PM cehteh: timer_ocra = acceleration_factor/position + deceleration_factor/(endpoint-position) + minimum_ocra
07:28 PM cehteh: the 2 factors can be prepared ... but are not constant
07:28 PM cehteh: of course you can inverse the whole thing .. but that wont remove a division
07:29 PM rue_mohr: you can reduce it to one division if your ok with more multiples
07:29 PM cehteh: how?
07:29 PM rue_mohr: (be+dc)/ce
07:29 PM rue_mohr: (be+dc)/ce +f
07:30 PM rue_mohr: but, overflow
07:30 PM cehteh: yeah
07:30 PM cehteh: been there
07:30 PM cehteh: remember few days ago i saied i could try 64 bit division
07:30 PM cehteh: do you tihnk 1 64 bit division is cheaper than 2 32 bit?
07:30 PM rue_mohr: you must have a huge machine to need 32 bits
07:31 PM cehteh: nah, 24 bit may do (but still overflow)
07:31 PM cehteh: 16bit wont do
07:32 PM rue_mohr: zippo:/files/programming/c/motif/cam# units 4294967296thou inch
07:32 PM rue_mohr: * 4294967.3
07:32 PM cehteh: w/ microstepping you have shitloads of steps 0,005mm per step
07:33 PM rue_mohr: huh, something sounds off key with that statement
07:33 PM cehteh: also to get to decent speeds i need a lot steps per sec
07:33 PM rue_mohr: so your machine units are the same as your driver units
07:33 PM rue_mohr: uh
07:34 PM cehteh: i just tell you that you get the idea
07:34 PM rue_mohr: mhm
07:34 PM rue_mohr: what is the resolution of the machine going to be
07:34 PM cehteh: i dont understand?
07:35 PM rue_mohr: wait, is this a threaded drive?
07:35 PM cehteh: belt drive
07:35 PM rue_mohr: ah
07:36 PM cehteh: for 50mm/sec i need 10khz pulses
07:38 PM cehteh: coudl go slower, but i have 2 axis so when my code now reaches 10khz on one axis that would be 2x5khz for 2 axis (well i will do some resource allocating) usually it will move long lanes on one axis and only small correction movements on the other axis
07:39 PM cehteh: so i 'barely' hit the goal now
07:39 PM rue_mohr: hmm, what chip did that.. fat angus?
07:39 PM cehteh: but there is no much headroom for other calculations when going full speed
07:39 PM cehteh: currently i play with 328p
07:40 PM cehteh: eventually we'll portthis whole stuff to m0 or so
07:40 PM rue_mohr: erp, no Paula
07:40 PM cehteh: paula?
07:40 PM rue_mohr: yea, you need a paula
07:40 PM rue_mohr: I think their out of production now tho
07:40 PM cehteh: wtf
07:43 PM rue_mohr: pulse coprocessor
07:43 PM cehteh: https://raw.githubusercontent.com/ridiculousfish/libdivide/master/libdivide.h
07:43 PM cehteh: mhm .. if that has any benefit on avr's ? :)
07:44 PM cehteh: doesnt lookso
07:44 PM rue_mohr: coprocessor you load with what you need to do and it takes care of it for ya
07:44 PM cehteh: totall wrong one forget it
07:45 PM cehteh: putting the whole thing on a cortex would solve it as well
07:45 PM cehteh: but i want to get a proof of concept going asap on the avr .. mkay not full speed then
09:28 PM cehteh: ok .. run my own division code -- 15khz, i am good now
09:28 PM cehteh: still C not asm optimized :D
09:40 PM cehteh: lol just reordered a a&&b to b&&a .. 17khz :D
11:31 PM day__ is now known as day