#avr Logs

Feb 11 2019

02:04 PM Maya-sama is now known as Miyu
02:29 PM jancoow: Ugh. I keep ketting an ld returned 1 exit status when using the sprintf function :/
02:30 PM LeoNerd: when linking your avr code?
02:30 PM LeoNerd: I tend to just shove all my .c files together in a single avr-gcc run and generate the output .elf file directly
02:31 PM LeoNerd: Especially when you're using -flto, there's no point doing a whole lot else
02:31 PM LeoNerd: Also AVR programs are /tiny/ as compared the typical development workstation
02:32 PM jancoow: oh nvm I see. I think sprintf is using 40% !!! of my memory
02:33 PM jancoow: So I don't have enouggh memory ugh. I just want to debug it :/
02:33 PM polprog: rofl. thats *printf for ya :D
02:33 PM jancoow: ?
02:33 PM polprog: puts and a dedicated print hex function is better imo, if you are short on memory
02:34 PM polprog: printf family functions just take a ton of program memory because it takes some code to parse and format the messages
02:34 PM jancoow: ah right
02:34 PM jancoow: yeah I just wanna debug something because it's not working :)
02:35 PM jancoow: But I will comment some code out so I can still debug it
02:43 PM cehteh: whats 40% for you?
02:45 PM cehteh: i have my own formated output lib, but havent checked how much space that takes, i'd bet 1kb at least
02:48 PM vmt: how about get a real mcu and have real debugging?
02:48 PM vmt: 0 bytes additional code
02:49 PM vmt: owait you can always do proprietary atmel but that doesn't fit into the communist world view. atmel in general, however does... makes me curious.
02:49 PM jancoow: I don't wanna buy that expensive atmel programmer
02:50 PM vmt: exactly.
02:50 PM cehteh: just dont write bugs solves the problem as well
02:50 PM vmt: so how about get some stm32s and $5 debugger
02:50 PM jancoow: cehteh: yeah I don't understand what is going wrong ugh..
02:50 PM vmt: communists are safe because you can debug with openocd
02:50 PM cehteh: anyway ... i am using the serial for real output not only debugging :D
02:51 PM cehteh: jancoow: time to step back isolate the bug and think about it
02:51 PM vmt: time to ebay stm32
02:51 PM jancoow: cehteh: yeah that's what I'm trying to do now :)
02:51 PM cehteh: vmt: this is #avr :D
02:51 PM jancoow: but it's already going wrong in step 1 lol. Simply writing to an array seems to be going wrong
02:51 PM vmt: cehteh: the last topic set had stm32 in it
02:52 PM vmt: not to mention the people over at the stm32 channel are morons
02:52 PM vmt: but that's another topic
02:52 PM vmt: jancoow: show some code then
02:52 PM cehteh: jancoow: thne fix that :D .. do you have any casts? do you check for array bounds? is your array base ptr sane?
02:52 PM jancoow: yes it's something with float to uint8 cast I think
02:53 PM cehteh: dont use floats ... lalalla
02:53 PM vmt: you *think*?
02:53 PM vmt: and seriously using floats with an avr. You're doing something horribly, horribly wrong
02:53 PM cehteh: and yes debugging by guessing is the wrong approach ...
02:53 PM vmt: even if it's sp
02:54 PM jancoow: sorry that I'm not an expert as anyone else here..
02:54 PM cehteh: there may be some reasons to use floats .. but i havent had any yet
02:54 PM cehteh: jancoow: first rule: never ever use floats unless you exactly understand and know that you must use them
02:54 PM cehteh: i mean really understand, not just 'think'
02:54 PM vmt: get something with an fpu then. cm4f namely.
02:55 PM jancoow: vmt: I'm not getting anything else.
02:55 PM vmt: and jesus f mf christ, the code is right in front of you? do you see a cast or not. it's not a question of what you think or how you feel
02:56 PM vmt: to me it sounds like you're trying to port something
02:56 PM vmt: presumably something which shouldn't be ported to an avr
02:56 PM jancoow: vmt: why are you talking to me like that?
02:56 PM vmt: because your answer of "i think" it's just so... lacking
02:56 PM cehteh: vmt: floats are perfectly ok when you 1) have the space 2) its not performance ciritical 3) you need to to cover the whole magnitude/range of the floating space 4) inexactness is ok 5) ... fill in another reason ...... ...
02:56 PM cehteh: all together
02:57 PM cehteh: and this never ever happend to me yet :D
02:57 PM vmt: i agree with 1, 2, and 4
02:57 PM cehteh: jancoow: anyway remove floats .. then start over
02:58 PM vmt: but still a general guesstimation is that an application requiring floats is something best done on a diff platform
02:58 PM vmt: or hey, you can get some 80s fpus from amd or w/e from ebay probably, or from rue, as he lives in the past
02:58 PM cehteh: vmt: i once read a noice article about using floats for time, which had some point, at least for explaining floats to other people
02:59 PM vmt: sure but for time it's not required, you can use integer arithmetic
02:59 PM cehteh: like with floats you can handle time spans closeby very high precision and as well define that the dinosaurs got extinct 80mio years ago
02:59 PM jancoow: vmt: okay well mr. genius. Maybe not everyone is as smart as you are. But that doesn't mean you can't talk to me like I'm just an idiot and doing everthing wrong.. Sorry that I'm not on your level, but sometimes people are just trying to learn things..
02:59 PM cehteh: but you cant define at what millisecond they got extinct
03:00 PM vmt: well... technically you can
03:00 PM jancoow: vmt: and if I'm doing something wrong, you can tell / explain it just normally to me. Instead on the way you are talking right now..
03:00 PM vmt: well i asked you to show code like 10 minutes ago
03:01 PM cehteh: well befroe so, remove floats ...
03:01 PM vmt: you haven't even defined your problem
03:01 PM cehteh: you dont need em
03:01 PM cehteh: still your led project right?
03:01 PM jancoow: vmt: yes, but like I said I was trying to debug myself first, so I can learn from it..
03:01 PM vmt: jancoow: i'm happy to co-operate, but you need to give us something to work with here
03:02 PM jancoow: cehteh: yeah.. Most thing where working pretty good :D I just wanted to implement some fade thingy. I will show you in a sec
03:02 PM cehteh: do the calculations in integer .. even 32bit integers are better than floats (but if you can use 16bit)
03:02 PM cehteh: fixedpoint math
03:02 PM cehteh: either binary or decimal
03:03 PM vmt: ternary, hex
03:03 PM vmt: what's base-4
03:03 PM cehteh: BCD math
03:03 PM cehteh: lolz
03:03 PM vmt: quaternary
03:05 PM vmt: pretty sure even 64 bit integers are better than sp and definitely better than dp
03:06 PM jancoow: cehteh: okay so this is the code ATM: https://jancokock.me/f/69023/ this is fully working
03:06 PM jancoow: cehteh: working pretty fast so far;
03:07 PM vmt: indentation needs some love
03:09 PM jancoow: what I want to implement is some kind of fade; So when a current channel is 255, and 100 is received over uart, it has to fade from 255 to 100 on x speed.
03:10 PM jancoow: how I currently solved it on another platform is simply calculate the steps needed. So 100-255 = -155. -155/10000 steps = -0.0155
03:10 PM jancoow: and then update the channel a 1000 times in the mainloop
03:11 PM jancoow: with this the fade speed can be different for all 9 channels
03:11 PM jancoow: that was the idea :)
03:11 PM vmt: i take it the step count is bounded?
03:12 PM jancoow: For now yes; but later on it can be set through uart
03:12 PM jancoow: but first wanna make it work with a fixed value
03:12 PM vmt: i mean it's bound to a range [min, max]
03:13 PM vmt: well, it certainly is then. anyway, scale up and work with integers
03:14 PM jancoow: yeah that's fine
03:16 PM vmt: the more upscaling the more precision, ... the precision required really kind of depends on the bounds of the stepcount
03:16 PM jancoow: yeah understand! Well the longest fade really needed is like ~10 seconds
03:16 PM jancoow: well even 5 would be enough
03:17 PM jancoow: but I guess I need a slower timer for that
03:17 PM jancoow: because that's way to many steps for the mainloop
03:18 PM vmt: well you would be blocking for 5 seconds:D
03:18 PM jancoow: nah not really
03:18 PM vmt: well no, not exactly
03:19 PM jancoow: uart is interupt handled
03:19 PM jancoow: as is the software pwm
03:19 PM vmt: in fact doing that you wouldn't even know how long you'd fade
03:19 PM samantaz__ is now known as samantaz
03:19 PM vmt: unless you don't do it "in the mainloop" and have a timer for it
03:19 PM jancoow: yeah I know :)
03:20 PM jancoow: but it doesn't have to be second precise
03:20 PM vmt: again, resolution but it isn't probably ultra-critical
03:20 PM jancoow: not at all
03:21 PM vmt: obviously you can do it with like sp, but integer math will be faster. faster execution for running more nodejs modules
03:21 PM jancoow: but if I call "recalculate_steps" repeatably the main loop should have the same execution time
03:21 PM jancoow: nodejs? lol
03:22 PM vmt: well more like recalculate_brightness
03:22 PM jancoow: yeah function/var naming isn't really good :D
03:23 PM vmt: you set up counters and speeds for all the channels and the function calculates the new brightness values for each of them
03:25 PM jancoow: anyhow making led_output_values a long and scale it with 1000000 or something?
03:26 PM vmt: well, all you really have to do is upscale the value(s), perform arithmetic and then downscale
03:30 PM cehteh: when you do that clever then you can leave out the dowscale step
03:30 PM vmt: well, you can have them upscaled at all times obviously, but the values for pwm you downscale by a factor of, whatever
03:30 PM cehteh: divisions are pretty expensive
03:30 PM vmt: well, sure
03:30 PM vmt: implementation is left as a homework exercise
03:30 PM jancoow: so why not use a double then? ;p
03:30 PM cehteh: also i'd poll the uart, having only the timer isr spinning, then uart handling will not interrupt the pwm
03:30 PM vmt: because avrs don't have a fucking doule-precision floating-point unit
03:30 PM vmt: double*
03:30 PM vmt: let alone a single-precision one.
03:30 PM jancoow: cehteh: well I don't see any flickering as long as I don't do to much in uart :D
03:30 PM cehteh: or at least make the uart isr smaller, have a small queue (few bytes) and push data on that in the uart isr
03:30 PM vmt: they do have a software library for floating-point math, which is sloooww
03:30 PM cehteh: sure, but i meant to see no flickering at all :)
03:30 PM jancoow: cehteh: I do see flickering when sending something back over uart in that isr hehe
03:30 PM vmt: keep the data small or then do what cehteh suggests
03:30 PM jancoow: the uart isr is pretty small now.
03:30 PM cehteh: while i admit for a stepper drvieri have some massive isr as well
03:30 PM vmt: apparently not small enough if you flicker
03:30 PM jancoow: I DONT see flicker :)
03:32 PM cehteh: doing io from ISR is receipe for desaster, you almost always introduce race conditions and new bugs with that
03:32 PM cehteh: apart from overhead and performance impact
03:33 PM vmt: needs more mutex
03:33 PM cehteh: mutex isr haha
03:33 PM vmt: :DD
03:33 PM vmt: mutex avr, "haha"
03:33 PM polprog: i usually set up some form of a state machine and the isr just changes the next state variable
03:34 PM vmt: polprog: hiello. how's that demo project going on?
03:34 PM cehteh: depebds, someteims when its RT time critical you have to do more
03:34 PM polprog: hey vmt, i added some munching squares code
03:35 PM polprog: havent got around to capturing it
03:35 PM polprog: plus, tons of other stuff on my head rn, like school :?
03:35 PM polprog: :/*
03:35 PM cehteh: hey i dont even change states for my statemachine form ISR .. the ISR schedules a function which will change the state :D
03:35 PM polprog: schedules a function
03:35 PM polprog: dont you mean a FunctionFactory
03:35 PM polprog: :P
03:36 PM vmt: java for avrs
03:36 PM polprog: actually someone did that
03:36 PM vmt: isr schedules a functionfactory singleton to create a function and place it into a queue
03:36 PM cehteh: lol
03:36 PM polprog: if only avr could execute code from memory
03:36 PM cehteh: bytecode interpreter :D
03:37 PM vmt: exactly
03:37 PM cehteh: if only avr's has more flash
03:37 PM vmt: well doesn't have to be java exactly
03:37 PM jancoow: mmh okay.. so this is already giving me weird behaviour
03:37 PM jancoow: maybe you guys see what's wrong
03:37 PM cehteh: did you removed the floats?
03:37 PM jancoow: https://jancokock.me/f/73603/
03:37 PM vmt: all object-oriented languages treat "design patters" as some kind of a bible
03:37 PM jancoow: yes (and yes, there is something more in the uart ISR now but it's just for testing)
03:38 PM cehteh: integer overflow?
03:39 PM jancoow: unsigned long?
03:39 PM cehteh: i havent checked, just guessed
03:40 PM cehteh: your description 'weird behaviour' isnt very helpful
03:40 PM cehteh: figure out whats wrong then where that can go wrong
03:40 PM jancoow: oh sorry :D Well the color output isn't working as expected. I see the wrong colors appearing
03:41 PM cehteh: aka wrong values .. which sounds like integer overflow/underflow/truncation etc
03:41 PM cehteh: sometihng in that math
03:41 PM cehteh: #define LED_OUTPUT_SCALE 1UL
03:41 PM cehteh: welll :D
03:41 PM jancoow: yep then it's workin fine
03:41 PM jancoow: but not at 100
03:42 PM cehteh: so you overflow or dopnt scale back properly or loose some bits on the go
03:42 PM jancoow: (uint8_t)(led_output_values[i-1] / LED_OUTPUT_SCALE);
03:43 PM jancoow: led_output_values[i] = wanted_led_output_values[i] * LED_OUTPUT_SCALE;
03:43 PM jancoow: :/
03:43 PM LeoNerd: I'm only loosely skimming, but... is someone trying to do double-precision floating point maths in a UART ISR??
03:43 PM vmt: LeoNerd: nah we're past that I think
03:43 PM jancoow: no.
03:43 PM LeoNerd: Ah, good
03:43 PM cehteh: lol
03:43 PM * LeoNerd returns cluebat to holster
03:43 PM vmt: jancoow: not having read the whole code, aren't you setting the pwn with the wrong values?
03:44 PM vmt: pwm, even
03:44 PM jancoow: vmt. Well. What I'm basicly do is: first scale it up: led_output_values[i] = wanted_led_output_values[i] * LED_OUTPUT_SCALE;
03:44 PM vmt: as in you are setting it up with the scaled values
03:44 PM jancoow: and then scale it down: (uint8_t)(led_output_values[i-1] / LED_OUTPUT_SCALE);
03:44 PM cehteh: LeoNerd: printf("%g") in PWM overflow isr :)
03:44 PM jancoow: when I set the scale value to = 1 it works fine
03:44 PM LeoNerd: cehteh: *groan*
03:44 PM vmt: ...as expected
03:45 PM jancoow: yes
03:45 PM LeoNerd: cehteh: also hi: how's the 328PBs treating you?
03:45 PM jancoow: indeed
03:46 PM cehteh: LeoNerd: prototype is done but i am working on the firmware still more than 20kb code w/o much data/strings .. and growin
03:46 PM vmt: led_output_values is an array of uint8_t, isnt' it
03:46 PM LeoNerd: cehteh: mmm.. I have code like that. avr-gcc is really pissing me off for its total inability to let me put anonymous structures in program space :(
03:46 PM vmt: so... that will overflow by a shit ton
03:46 PM LeoNerd: PSTR() works great for strings, but you can't put anything else like that ;( it's a specialcase
03:46 PM jancoow: vmt: no, it's a unsigned long array
03:46 PM cehteh: the timer workaround was a downer, but working now and i'll sodler a usb cable with diode later :D
03:47 PM vmt: oh wait i misread
03:47 PM jancoow: vmt: https://jancokock.me/f/73603/ :)
03:51 PM vmt: wait wait
03:51 PM jancoow: vmt: weird, isn't it?
03:54 PM jancoow: wait omg.
03:54 PM jancoow: I'm so stupid..
03:56 PM vmt: well i'm deciphering the structure of this because the things aren't named very aptly
03:56 PM jancoow: xD
03:56 PM jancoow: yeah it's in the calculate_steps function
03:56 PM jancoow: I'm also using the led output values a bit further down
03:58 PM jancoow: fixed
04:31 PM jancoow: vmt: okay next problem..
04:31 PM jancoow: vmt: led_output_fade_steps_values[i] = (wanted_led_output_values[i] * LED_OUTPUT_SCALE)-led_output_values[i];
04:31 PM jancoow: led_output_fade_steps_values[i] = (wanted_led_output_values[i] * LED_OUTPUT_SCALE)-led_output_values[i]; *
04:32 PM jancoow: this isn't working properly.. It giving me... values which aren't right at all
05:42 PM JanC_ is now known as JanC
05:53 PM grawlinson|afk is now known as grawlinson
06:04 PM rue_mohr: hmm
10:13 PM Thrashbarg_ is now known as Thrashbarg
11:02 PM rue_ is now known as rue_mohr