#avr Logs

Feb 20 2019

#avr Calendar

12:00 AM rue_mohr: no idea, sorry, did anyone here know?
12:04 AM rue_mohr: irc died with the login wall too
03:28 AM con3|2 is now known as con3
07:49 AM splud: rue_mohr (from 10 hours ago or so) - flash size of firmware: avr-size --mcu=(your mcu) --format=avr YourProgamName.elf
07:51 AM splud: I use makefiles, not an IDE. I have a target defined for "size" which belts out the program size (actually, invoked avr-size twice with different parameters so as to get two different sets of data)
07:53 AM splud: I prefer the output without the --format=avr, but that requires a bit of simple math. to arrive at the flash space (text+data) and ram (bss+data, but doesn't include stack usage which can be significant)
07:54 AM splud: the --mcu parameter specified your target MCU and is used to compute use percentage.
08:00 AM splud: Back onto my project issue this morning. Remains puzzling. To debug the TIM0_OVF_vect, I toggle an output (in one build, just on every interrupt, and on another, during the uSec -> millis rollover), and on a scope, the output is as expected (the per-interrupt toggling is nice and stable, and is at the expected rate, the millis rollover has some jitter, but that's totally expected, since the interrupt isn't at an even mS interval).
08:02 AM splud: for code speed, the OVF handler updates a uint16 value with the number of uSec per interrupt (based on compile-time math). When that is > 1000, then it increments a uint32 for millis.
08:04 AM splud: I should probably work out the total cycles necessary for each interrupt and see if I'm actually saving any cycles - at 213uS/interrupt, it's basically uint16 increment and uint16 compare on most interrupts, then that and a uint32 increment and uint16 when the uint16 is > 1000 (mostly every 5 interrupts, but sometimes 4)
08:06 AM cehteh: why dont you just increment a number in the interrupt and nothing else (possibly uint32_t) .. and do the math when you query the time
08:06 AM splud: Just so I'm not adding to a uint32 on every interrupt. The overhead is more painful when the interrupt rate is faster.
08:08 AM cehteh: in my interrupt code i just run timers until MAX 255 or 65535 depending if its configured on 8 or 16 bit timers
08:08 AM cehteh: works pretty well
08:09 AM splud: Presently, I run to max, yes, based on clock speed and prescaling (both CPU and the timer), that results in a different amount of time per interrupt, which is that compile time constant I add to the counter.
08:10 AM splud: However, a 32-bit millis gives a longer runtime than a 32-bit uSec
08:10 AM splud: (for tracking elapsed time, etc).
08:10 AM cehteh: i made some table ..
08:11 AM splud: 1K code, 64 bytes ram. Table gets ugly quick, unless it's for a state machine <g>
08:11 AM cehteh: https://git.pipapo.org/?p=muos;a=blob;f=PLAN.org;h=198cb6f359f12dbcfdee28ba0344538c061e50a1;hb=refs/heads/example
08:11 AM cehteh: w/ diffferent timer configs
08:12 AM splud: You should add 9.6MHz and its prescalers to that table.
08:13 AM splud: Some of the small Tiny devices don't even have a 16 bit timer (such is the case with the Tiny13A)
08:14 AM splud: For this project, the ONE 8-BIT TIMER is being used with a cpu prescaler, and timer prescaler and FAST PWM mode to generate a circa 4.7KHz PWM signal. Thus, elapsed time tracking is based on that timer overflow rate.
08:16 AM splud: And, I have commented in my code (for a reminder to me) that the particulars of the millis overflow are more than sufficient for the purposes of that project since I'm really only concerned with event timing in the sub-30 minute intervals or so.
08:17 AM splud: rue_mohr (again in response to old scrollback) - re: what the PWM is for. This particular case, it's for a 2HP DC motor speed control, and is being 2-stage RC filtered (component values based on the PWM _frequency_) and driven into an OPAMP to provide a continuously variable 0-12V output signal.
08:19 AM splud: Prior projects using PWM with an ATTiny include a food smoker (driving a power mosfet to switch current through a heater filament), a hot wire (for cutting foam), and a small exhaust fan speed control.
08:21 AM cehteh: i made my timers pretty configurable
08:23 AM splud: I've got some compile-time defines that do the math to determine the specific interrupt timing (F_CPU, clock prescale, timer prescale, /256 for full count -- really should extend to deal with TCNT0 as well)
08:24 AM splud: Frees me up from having to do the math if I tweak a prescaler, or use a Tiny85 (for example), which has a different internal oscillator. Or running something at a lower voltage.
08:24 AM cehteh: i do that mostly at compiletime too, but note that querying a timer has some surprising corner cases when you want to do that correctly
08:25 AM splud: cli ; copy millis into local variable ; sti, return value
08:26 AM cehteh: aka you have to integrate the interrupt bit in the calculation and stop interrupts (at last for that timer) while you read it
08:26 AM cehteh: ok when you only query the overflows then its that simple, but when you want to be more exact including the hardware counter as well
08:27 AM cehteh: which on the other hand allows you to run the timer much slower and generate far less interrupts
08:33 AM splud: <gnrk> Damn.
08:34 AM splud: millis code all good and well. The code (outside of timer handling) that sets a target delay is good.
08:34 AM splud: The code that checks to see if we've reached it was inverted logic.
08:34 AM splud: Checked my other projects, and it's correct there. Gaaa.
08:35 AM * cehteh gtg
08:38 AM splud: Thanks for the exchange.
09:33 AM paulo_ is now known as Guest29331
12:27 PM gsi__ is now known as gsi_
02:01 PM paulo_ is now known as Guest72499
09:36 PM rue_shop3: --
11:17 PM day_ is now known as day