#avr Logs

Feb 25 2021

#avr Calendar

04:15 AM ruel is now known as lvlinux
04:22 AM abcminiuser214 is now known as abcminiuser21
04:22 AM dan3wik is now known as dan2wik
04:29 AM _nexxus__ is now known as _nexxus_
04:42 AM Helle_ is now known as Helle
04:57 AM skz81_ is now known as skz81
07:20 AM Sadale_ is now known as Sadale
08:49 AM fstd: so the 16 bit timers on ATtiny/mega that can do phase-correct PWM work by counting up, and then counting down, and so forth, right?
08:50 AM fstd: is there a way to reset (inbetween timer runs) the direction of this counting?
08:50 AM fstd: so the timer always starts in a defined state when i enable its clock
08:59 AM mouseghost: isnt there some bit to flip?
09:02 AM fstd: no. it's mentioned as a internal signal 'direction' in the block diagram, and the datasheet talks about how that signal changes when the timer reaches top/bottom, but no apparent way to manipulate it with the timer stopped
09:03 AM fstd: i guess i could figure it out by running the timer for a few cycles, but i'm already struggling with available program memory so that'd suck
09:03 AM fstd: mabe since it's sort of a slave MCU i'll just reset the whole thing every time for now
09:37 AM skz81: You can just write the counter value register before starting it... Can't you ?
09:38 AM skz81: fstd, ^ if you start at bottom, it's forced to go in increasing direction
09:41 AM cehteh_: somewhere is the bit if its in up or downward mode and depending on wgm mode writes to the counter might be latched, at least i remember something like that
09:42 AM cehteh_: one needs to read the datasheet very carefully to deciper those parts
09:49 AM fstd: skz81: that's... hell of a good point
09:49 AM fstd: thanks!
09:50 AM fstd: (afaik writes to the counter happen immediately but inhibit a compare match)
09:50 AM fstd: while writes to OCRxy are sometimes buffered
09:52 AM cehteh_: yeah something like that, just read datasheet, also order in which you write the 16bit registers hi/lo parts
09:52 AM skz81: <<The OCR0x registers are double buffered when using any of the pulse width modulation (PWM) modes. For the normal and clear timer on compare (CTC) modes of operation, the double buffering is disabled. The double buffering synchronizes the update of the OCR0x compare registers to either top or bottom of the counting sequence. The synchronization prevents the occurrence of odd-length, non-symmetrical PWM pulses, thereby making the output glitch-free.>>
09:53 AM skz81: fstd, I would not be surprized if the counter always start by increamenting when you enable it or something like that
09:54 AM fstd: skz81: i doubt it since 'disabling/enabling' merely means gating its clock IIRC
09:54 AM fstd: why would its internal state change by that
10:11 AM skz81: fstd, maybe. It was a wild guess...
10:11 AM fstd: still appreciated :)
10:57 AM cehteh_: have you tried to look at the problem from another angle? could it be solved otherwise? what exactly do you want to do?
11:03 AM fstd: cehteh_: i have three 16 bit PWMs from 3 separate (similarly clocked) attinys and i need them all in phase with each other. i set them up separately and then start them all at the same time with one of the external interrupt signals
11:03 AM fstd: so to that end i need to make sure that they're all in the same state when starting, but while i haven't tested it yet i think setting the counter to 0 should do the job
11:04 AM fstd: (and it's maybe a stretch to call it pwm because i vary the frequency and keep the duty cycle fixed, but it's using the phase-and-frequency-correct PWM mode)
11:05 AM cehteh_: by how much can the phase differ?
11:05 AM fstd: to be honest it doesn't matter that much, but since it can be theoretically brought to about 0, i figure why not
11:06 AM fstd: (the big picture is i'm driving a CNC mill so i try to not introduce any inaccuracies that could be avoided)
11:06 AM cehteh_: i mean there are avr's with more pwm's on a single mcu, and there is a way to start all timers absolutely synchronously
11:06 AM fstd: if i'm going say a 45 degree toolpath, one axis starting up slightly too late would mean i'm a couple thou off
11:07 AM fstd: cehteh_: alas the AVRs i have/know don't ever have three independent 16bit pwms
11:07 AM cehteh_: also you can drive some timers from external clocks, once set up you can start that clock and keep all in perfect sync
11:07 AM fstd: (8 bit is a little too coarse for my purpose)
11:07 AM fstd: cehteh_: no, there's more. i don't start up all PWMs and then call it a day. timers get stopped/restarted inbetween, directions get changed
11:08 AM fstd: sometimes there's unpredictable stop if driving it into one of the limit switch
11:08 AM fstd: so timers may get stopped at arbitrary points in time
11:08 AM cehteh_: steppers?
11:08 AM fstd: yes
11:08 AM fstd: (i output PWM and count the steps with an external IRQ pin to be accurate to that end)
11:09 AM cehteh_: i made my stepper stuff each axis have its own timer, but long time plan is to dive multiple steppers from a single timer
11:09 AM cehteh_: why do you count externally?
11:10 AM cehteh_: also sometimes i thought "would be nice to do that on a fpga"
11:10 AM fstd: paranoia. i want to count the amount of steps i'm actually putting out. i'm more robust wrt potential bugs that way and i have the pins available
11:10 AM fstd: it's still the same AVR that's counting though
11:10 AM cehteh_: huh what :D nah
11:11 AM fstd: i just bridged the pwm output with one of the INTx pins
11:11 AM fstd: why not?
11:11 AM cehteh_: just sum up the steps yoiu drive and good
11:12 AM cehteh_: when your signals are not clean for other reasons then better fix that
11:12 AM fstd: i have no reason to assume my steps aren't clean. but "just summing up the steps i drive" already implies having some way to count them
11:12 AM fstd: and i'd rather not poll TCNT1 repeatedly
11:12 AM cehteh_: you have a counter there
11:13 AM cehteh_: why not
11:13 AM fstd: if i used the timer to count steps, i would have to enable one of its interrupts
11:13 AM fstd: in PWM mode that would fire twice per step
11:13 AM fstd: and in that ISR i would make sure to ignore every 2nd invocation
11:13 AM fstd: and then do exactly what i'm already doing on the INT0 interrupt
11:13 AM fstd: namely, bump my step counter
11:14 AM fstd: so it's really just one extra step
11:14 AM fstd: and this way i can keep the timer itself IRQ-free
11:14 AM fstd: /and/ i am still more robust towards *software* bugs
11:14 AM fstd: (software bugs != unclean signals)
11:16 AM fstd: this really isn't my first day (or decade) of writing software, i do like robustness
11:16 AM cehteh_: here it fires once per step and thats what i wanted, mostly because i load the value for accel/decel for the next step and compare position and schedule actions. the accel/decel calcs are then scheduled to be out of isr and double buffered
11:16 AM fstd: as an extra benefit, suppose something else causes a step, the machine controller itself or so
11:16 AM fstd: i want to know it, and this way i get it
11:16 AM fstd: do you have encoders on your axis or how/why do you check position every step?
11:16 AM cehteh_: for that i can probe the machine at end switches or do some other calibration (actually optically here)
11:16 AM fstd: i just translate distance into amount of steps once and then let it loose
11:16 AM fstd: (i still ramp the velocity tho)
11:17 AM cehteh_: i dont have encoders, that machine is calibrated to be in some sane speed range not to loose steps
11:17 AM fstd: i see. if you get one timer IRQ per step then you're not using phase-correct mode btw
11:18 AM fstd: so you might have glitches in your pwm
11:18 AM cehteh_: works for me
11:18 AM fstd: ok maybe that's where we're different then
11:18 AM cehteh_: https://public.pipapo.org/20190411_112616.mp4
11:18 AM fstd: i hope my thumbs you have a bullet proof way of detecting end of travel though :D
11:19 AM fstd: hold*
11:19 AM cehteh_: well that was over a year ago, scanning microscope for a customer
11:19 AM cehteh_: that pretty much craps out when it looses steps because the steps are already way bigger than the pixels
11:28 AM fstd: well at least that doesn't sound like something that's going to disassemble itself if driven out of bounds
11:29 AM cehteh_: there are hardwired end-switches doing a emergency braking still
11:30 AM cehteh_: dunno what you are doing, if for some reason there is a chance that the steppers loose steps/stall then yes i'd sense position externally
11:32 AM fstd: as said i'm driving a CNC mill, but the end switches are only advisory, i.e. they're reference switches and there's nothing stopping me from going beyond
11:32 AM fstd: i'm also not driving the steppers directly, but interfacing the controller of a cnc mill, so to say
11:32 AM fstd: and i have a way to detect lost steps, so that's not an issue
11:33 AM fstd: why i want to synchronize the timers is, ultimately, accuracy. if one starts slightly late, that's going to put me off a bit
11:33 AM fstd: even if they do the same amount of steps
11:33 AM cehteh_: yes sure
11:34 AM cehteh_: might be bit challenging with AVR's
11:34 AM fstd: counting it with as little software involved as possible really is just robustness. what do i know, maybe the machine runs on mars next year :)
11:35 AM fstd: if a gamma ray causes a step, i want to know it
11:35 AM fstd: otherwise my spaceship might not be made to spec
02:52 PM _nexxus__ is now known as _nexxus_
03:38 PM skz81_ is now known as skz81
03:39 PM skz81 is now known as H40m4RU
03:39 PM H40m4RU is now known as skz81
04:47 PM fstd: can you guys help me solve a mystery with the 16 bit timer/counter1?
04:48 PM fstd: i realize it seems pointless but i'm after inverted 50% duty cycle phase-and-frequency-correct PWM, but it should be possible and i'm at a point where i'm no longer ruling out the hardware being wrong
04:48 PM fstd: http://paste.pr0.tips/QZ?c
04:49 PM fstd: ^ that should give me PWM, but doesn't. only when i leave out COM1A1, and i don't understand why
04:49 PM fstd: i've read the datasheet front to back and then again and then i ate some of the datasheet too
04:49 PM fstd: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2543-AVR-ATtiny2313_Datasheet.pdf
04:50 PM fstd: what am i doing wrong? :o
04:58 PM lvlinux is now known as ruel