Back
[02:43:22] <zulusbg> Hello im trying to run atmega328p to 1.8volt operation .. i have to connect all the vcc and gnd and Avcc for that kind of low voltage oprations
[03:14:57] <claes> not an AVR question but SAMD if someone has any idea. I accidently turned of main clock and now openocd can't program it anymore since reset doesn't seem to work.. any ideas?
[03:17:12] <claes> I didn't it before also but forgot to write down how to solve it =(
[04:27:48] <A124> claes Use another clock the one that is accessible... Or.. high voltage programming
[04:44:29] <claes> A124: SAMD ARMs doesn't do HVP and the problem seem to be that I must tell openocd do to a hardware reset somehow instead of issuing the MCU a reset request since it can't answer to that
[07:37:49] <Bushman> hi everyone.
[07:38:52] <Bushman> silly question... have anyone of you upload their non-arduino machine code using the arduino bootloader? or is it to much incompatible?
[07:40:59] <Bushman> i have some of those cheap nano knock-offs and of course i can program them with ISP, but since there's a working USB connector and a bootloader that handles code uploading... i was wondering if anyone done that for non-arduino programs?
[08:23:18] <A124> Bushman : Nab :P
[08:23:42] <A124> Sorry to be late... but if you use avrdude or even IDE with empty core you basically have it.
[08:23:43] <Bushman> ?
[08:24:16] <Bushman> have what?
[08:24:21] <A124> What I noticed, is that some... bootloaders at least set the UART in UART mode and do not set it back, so... might want to do that in code if you want to use those pins as IO.
[08:24:33] <A124> Have what what?
[08:24:39] <A124> Your code via Arduino bootloader.
[08:25:01] <A124> Its not Arduino bootloader, its just Optiboot most often, used for Arduino.
[08:25:10] <Bushman> ok.
[08:25:26] <A124> Empty core meaning boards.txt and creating empty structure.
[08:25:47] <A124> Which is just three or four defines in files and duplicit code.
[08:25:48] <Bushman> my specific question now is what arguments to pass to avrdude for it to take my hex and feed it to the bootloader?
[08:26:03] <A124> Same as Arduino does.
[08:26:49] <A124> I guess you can figure that out yourself or from readme. Usually its just STK I/II and right baud rate.
[08:27:31] <A124> Do not have IDE here, you will have to look at that yoursel.f
[08:28:43] <Bushman> i'm trying right now... but IDE doesn't want to talk to the board... for some reason it thinks i have no serial ports :D
[08:35:32] <rue_school> if your running linux I can give you a makefile that will compile and upload using gcc and avrdude
[08:44:51] <A124> Bushman That is problem of user rights on your distro.
[08:44:54] <A124> Not the IDE.
[08:49:09] <Bushman> yup, it was my fault
[08:49:21] <Bushman> but i was lazy, didn't want to close all my programs so instead of loging out from X, i just ssh localhost and work from there lol
[08:49:30] <Bushman> this one console window had proper permisions but all the others didn't
[08:49:58] <Bushman> * this first ->few days ago i've added myself to dialout group...
[08:50:18] <Bushman> took me a while to recall what i did back then
[09:48:54] <BusError> Hrm. is it atmel that maintain avr-libc, or is it someone else?
[09:52:52] <BusError> I'm embarassed for whomever did that bit:
http://pastebin.com/vfAghL9z
[10:46:58] <osteri> BusError: why?
[11:09:28] <Jartza> hehe
[11:09:37] <Jartza> I need to do one project with attiny5
[11:10:05] <Jartza> today, setting up the dev.env. I tried quickly the "hello world" - flashing leds
[11:10:18] <Jartza> flashing two leds and delaying, with simple code - 20% of flash used :D
[11:10:20] <LeoNerd> A chip sooooo tiny there wasn't even room enough on the package to print *two* digits
[11:10:41] <Jartza> the actual product will be made with as
[11:10:45] <Jartza> oops, asm
[11:11:30] <Jartza> needs 2 adc, one digital input, one digital out
[11:11:42] <Jartza> adc interrupts and pin change interrupt
[11:11:54] <Jartza> that 512 bytes of flash might get quite full
[11:12:23] <LeoNerd> Eh.. people have written entire x86 bootloaders in the 512byte MBR
[11:12:33] <LeoNerd> And that even excludes the signature bytes and the partition table space :)
[11:18:29] <Jartza> sure
[11:34:33] <Bushman> i need an advice: i need to read 2 or 3 channels of PWM inputs (from hobby RC reciever) with m328p
[11:35:08] <Bushman> then output 2 voltages (also could be PWM)
[11:36:03] <Bushman> what is my best option to do that?
[11:36:52] <A124> Bushman hobby rc receivers are PPM not PWM.
[11:37:38] <A124> Just use timers and interrupts probably.
[11:41:15] <Bushman> A124: the signal out of TX is ppm but the single outputs from the RX are PWM
[11:41:43] <Bushman> because only one channel is on each output the effective signal is PWM.
[11:42:39] <Bushman> anyway... we both know how the waveform looks like and which part is important. the 2ms at the begining of each frame
[11:43:11] <Bushman> so if i'll use interrupts, how many inputs can i handle?
[12:37:10] <BusError> osteri, didn't find something rather strange in the bitfield?
[12:41:04] <A124> Bushman As many as you can in terms of speed in code.
[12:41:21] <A124> But if its PWM aka analog... you can lowpass filter it and use ADC as well.
[12:50:43] <osteri> BusError: what's wrong then?
[12:51:47] <osteri> it's not obvious to me
[12:53:44] <BusError> What does the '&' operator do in C?
[12:54:05] <osteri> invert bitfield
[12:54:20] <osteri> i mean and bitfields
[13:17:52] <Jartza> ohh
[13:17:52] <Jartza> true
[13:17:58] <Jartza> didn't even notice that
[13:18:09] <Jartza> should be | of course
[13:35:17] <vpeter> Hi guys. I asked few days back for help and now I will do again:
http://www.avrfreaks.net/forum/xmega256d3-rev-e-twic-problem
[13:35:24] <vpeter> If anone has any thoughs.
[13:38:56] <learath> vpeter: I'd bet there is some resource contention between the debugger and the twic port
[13:39:03] <learath> but that's just me speaking out my ass
[13:41:22] <vpeter> But if you read carefully there are 2 devices connected on same bus. One device works but other doesn't when debugger is attached.
[13:44:53] <antto> BusError is that from some of the xmega headers?
[13:45:04] <osteri> BusError: I think it's correct, since they are inverting bitfield and then masking with &, fuses are 0 when programmed
[13:45:35] <antto> of course it's correct
[13:46:07] <antto> fuses are inverted logic, thus the bitmasks are inverted, and AND'ed instead of OR'ed
[13:46:11] <osteri> that is in every header
[13:47:36] <osteri> fuse.h, which is inlcuded in io.h
[13:48:10] <antto> i know there are such things for xmegas, but i didn't know there are also for atmegas and others
[14:32:26] <mr_snowf1ake> hey guys, i was wondering about why when running a clock frequency at 8 MHz a 28.8k serial bit rate has a higher error rate than with 38.4k.
[14:33:38] <mr_snowf1ake> on an atmega328 i mean
[14:38:19] <aandrew> mr_snowf1ake: probably becuase the closest divider you can get to is less close
[14:47:43] <mr_snowf1ake> aandrew: ah, okay
[14:47:45] <mr_snowf1ake> thanks
[14:51:42] <aandrew> think of it this way: in integer math, 25/4 gives you an imprecise answer although 100/4 gives you an exact answer
[14:52:47] <aandrew> you're dividing by 4 both times. it's the same way with baudrate calculations. If the desired baudrate can be divided down and the answer falls "nicely" into an integer, you get no error. as the number gets farther away from ideal you get more and more error
[14:53:03] <Xark> mr_snowf1ake: This site will let you know with precision ->
http://wormfood.net/avrbaudcalc.php
[14:58:05] <FL4SHK> Uh, so
[14:58:20] <FL4SHK> I have a particular problem
[14:58:42] <FL4SHK> https://github.com/fl4shk/arduinogbdump I want to convert the AVR side of this to not use the Arduino IDE; however, I don't know how I can keep USB serial stuff
[15:00:34] <FL4SHK> I heard somewhere that it's possible to use the Arduino libraries without using the IDE; while I'm familiar with using GCC from the command line (I write my own makefiles and whatnot), I'm not familiar with AVR stuff from teh command line
[15:01:39] <FL4SHK> The main thing that concerns me is writing the code to the Arduino board, and also being able to USE the code, which relies on the Arduino libraries
[15:02:36] <FL4SHK> I'd also love to be able to write AVR code in assembly as well
[15:02:56] <FL4SHK> also, I don't write code with the IDE itself; I just upload code with it
[15:15:53] <FL4SHK> Anyone?
[15:16:31] <Xark> FL4SHK: Nothing special about Arduino libs. You can build them in Atmel studio or whatever. Arduino people did not write the USB stuff (AFAIK).
[15:17:07] <Xark> FL4SHK: Full lib source is under Arduino IDE folder, so party on. :)
[15:17:18] <FL4SHK> Okay
[15:17:55] <Xark> FL4SHK: I believe there is info about this around. I just saw this today ->
http://hackaday.com/2015/10/01/arduino-development-theres-a-makefile-for-that/
[15:18:05] <FL4SHK> good!
[15:31:36] <FL4SHK> Xark: got it
[15:31:37] <FL4SHK> Thanks
[15:31:43] <FL4SHK> got it installed, I mean
[18:31:40] <Chillum> is there a specific channel for the teensy?
[18:32:34] <twnqx> unlikely
[18:32:37] <Lambda_Aurigae> Chillum, have you checked out the teensy's website to see?
[18:32:47] <Lambda_Aurigae> it's just an avr on a board with a special bootloader on it.
[18:32:47] <Chillum> yes
[18:32:54] <Lambda_Aurigae> nothing particularly special about it really.
[18:33:37] <Chillum> I am wondering which is faster to talk between a teensy and a raspberry pi, the serial via USB or the serial directly
[18:33:59] <Lambda_Aurigae> serial via usb being the usb-CDC?
[18:34:21] <twnqx> my random guess would be usb
[18:34:33] <twnqx> i went up to 2mbit/s serial with a uart
[18:34:59] <Chillum> that seems right twnqx
[18:35:00] <Lambda_Aurigae> usb-cdc might get that fast but I doubt it.
[18:35:11] <Lambda_Aurigae> dunno if the rPI serial port can do 2Mb/s though.
[18:35:47] <Chillum> SPI may be faster
[18:35:51] <twnqx> no
[18:36:02] <twnqx> well, not from the avr :P
[18:36:04] <Lambda_Aurigae> depending on what you are doing, usb bulk transfer might be faster.
[18:36:20] <Chillum> looking to stream a butt load of pixel data to a teensy that will be controlling ~1000 ws2812s
[18:36:33] <Chillum> pi to teensy only, 1 directional
[18:36:52] <twnqx> uhhhh
[18:37:09] <twnqx> doubt you'll be able to.
[18:37:18] <Chillum> it has been done before
[18:37:24] <Lambda_Aurigae> why not do it directly with the rPI?
[18:37:30] <Lambda_Aurigae> why put another processor in the mix?
[18:37:34] <twnqx> 'cause > timing
[18:37:41] <Bushman> hmm.. i think i'm doing something wrong... the interrupt is getting called but it's not exiting it untill i won't change the pin state back to high
[18:37:43] <Chillum> the pi is iffy at best at handling ws2812s
[18:37:44] <twnqx> need cycle exact bit-bang
[18:37:49] <Chillum> and fails outright with large numbers
[18:38:03] <Bushman> "Any logical change on INT1 generates an interrupt request."
[18:38:20] <Bushman> doea that mean any transition from hi to lo and lo to hi?
[18:38:26] <Lambda_Aurigae> that's what it says.
[18:38:30] <twnqx> Chillum: it's probably possible to drive 1k ws from the teensy
[18:38:50] <twnqx> but as a device in the middle? you don't have much cpu time left with that
[18:38:59] <twnqx> probably not enough to read from serial
[18:39:20] <Bushman> EICRA |= (1 << ISC00); this is what i came up with by reading the datasheet
[18:39:38] <Chillum> the OctoWS2811 library can run 8 channels of ws2812 lights at full frame rate using hardly any CPU using DMA and PWM
[18:39:50] <Chillum> uses hardware features to accomplish it
[18:40:04] <twnqx> dma?
[18:40:08] <twnqx> on... what hardware?
[18:40:11] <Chillum> direct memory access
[18:40:16] <Chillum> on the teensy
[18:40:30] <Chillum> https://www.pjrc.com/teensy/td_libs_OctoWS2811.html
[18:40:49] <Chillum> it is probably the best way to drive a huge number of addressable leds
[18:41:09] <Chillum> the pi is just there to play mp3s and stream pixel data
[18:41:20] <Bushman> Can someone help me with properly setting up those interrupts?
[18:41:36] <Lambda_Aurigae> teensy 3.0 is not avr.
[18:41:40] <Lambda_Aurigae> it's an arm processor.
[18:41:41] <Chillum> I know that
[18:41:50] <Chillum> that is why the first thing I asked is if there was a better channel
[18:41:58] <Lambda_Aurigae> try an arm channel?
[18:42:05] <Chillum> brilliant!
[18:42:43] <Chillum> any idea where that is? The ones I saw were mostly about running linux on arm
[18:42:49] <Chillum> not mcu style
[18:42:56] <Lambda_Aurigae> no clue.
[18:43:02] <Lambda_Aurigae> I do pic32 instead of arm.
[18:43:21] <Bushman> Can someone help me with properly setting up interrupts?
[18:43:26] <twnqx> doubt there are many
[18:43:40] <twnqx> but if you find one, tell me :P
[18:43:57] <Chillum> I generally stick to AVR, but the teensy has hardware specific libraries for the addressable leds that lets it rock
[18:44:15] <Lambda_Aurigae> http://www.engineersgarage.com/embedded/avr-microcontroller-projects/external-hardware-interrupts
[18:44:24] <Lambda_Aurigae> http://www.avrfreaks.net/forum/tut-newbies-guide-avr-interrupts?page=all
[18:44:25] <LeoNerd> I really should finish my mixed WS2801 + DMX code sometime
[18:44:32] <Lambda_Aurigae> http://www.avr-tutorials.com/interrupts/about-avr-8-bit-microcontrollers-interrupts
[18:44:47] <Lambda_Aurigae> Bushman, there ya go...
[18:45:16] <Bushman> Lambda_Aurigae: well, i was reading some examples, the datasheet...
[18:45:33] <Bushman> and i came up with this:
[18:45:36] <Bushman> EICRA |= (1 << ISC00);
[18:46:17] <Bushman> this should interrupt whenever the pin state changes
[18:47:05] <Bushman> but it is actingas if the bit was not set
[18:47:13] <Lambda_Aurigae> http://www.protostack.com/blog/2010/09/external-interrupts-on-an-atmega168/ check that out.
[18:47:18] <Lambda_Aurigae> it's closer to what you are doing.
[18:47:33] <Lambda_Aurigae> are you also enabling int0?
[18:47:38] <Bushman> the interrupt keeps geting called untill i bring the pin back high
[18:47:41] <Lambda_Aurigae> with the EIMSK ?
[18:48:01] <Lambda_Aurigae> without seeing more of your code, kinda hard to see what's happening all around.
[18:48:04] <Bushman> no no the hardware pin
[18:48:22] <Bushman> ok, but i need to warn you it's a mess...
[18:48:30] <Bushman> i'm still learning
[18:49:24] <Lambda_Aurigae> use pastbin.com or something,,,don't paste it all here.
[18:49:51] <Bushman> lol, i know
[18:49:51] <Bushman> XD
[18:49:53] <Bushman> http://pastebin.com/qMjec1vH
[18:51:08] <Bushman> so basically what it should do: blink two fast and long pause by default...
[18:51:47] <Bushman> on interrupt 0 blink 1 long and long pause and on int1 1 short and short pause
[18:51:56] <Bushman> and the interrupts are being called.
[18:52:09] <Bushman> the LED is blinking exactly as i coded it...
[18:52:34] <Lambda_Aurigae> so what is it doing wrong?
[18:52:44] <Bushman> tho i wanted the interrupt to be called on each CHANGE of the input pi
[18:52:46] <Bushman> *pin
[18:53:23] <Bushman> it acts as if the ISC00 and ISC10 were zero and not one.
[18:53:57] <Lambda_Aurigae> you have it set to trigger on any change...high to low or low to high.
[18:54:04] <Bushman> atmega datasheet page 71
[18:54:10] <Lambda_Aurigae> now...circuit...do you have pullups on the interrupt lines?
[18:54:33] <Lambda_Aurigae> how are they wired up?
[18:54:39] <Bushman> well, the pullups are enabled
[18:54:48] <Bushman> (at least should be)
[18:54:52] <Lambda_Aurigae> you have a button on the lines?
[18:55:00] <Lambda_Aurigae> so when you push the button it goes low?
[18:55:03] <Bushman> but the input is operational
[18:55:05] <Valen> Bushman: you can check that with a multimeter
[18:55:08] <Bushman> yes
[18:55:32] <Bushman> the wireing is ok cuase the interrupt IS being called
[18:55:47] <Bushman> and it stops when i release it
[18:55:54] <Bushman> but that's now what i intended
[18:55:59] <Bushman> *not
[18:56:25] <Bushman> i wanted "Any logical change on INT0 generates an interrupt request."
[18:56:41] <Bushman> -- atmega datasheet page 71
[18:56:44] <Lambda_Aurigae> so when you push the button it triggers and when you release the button it triggers?
[18:56:55] <Bushman> no
[18:57:03] <Lambda_Aurigae> what do you want it to do then?
[18:57:07] <Valen> if my reading is right, your code will flash fast, then when you push the button say int0 it'll stay on for a while
[18:57:17] <Bushman> when i push it it triggers and keeps triggering as long as i hold it
[18:57:28] <Valen> thats not how it works
[18:57:36] <twnqx> *should work :P
[18:57:38] <Valen> odds are you will see 3 triggers or so
[18:57:45] <Bushman> which is ISC01 = 0 and ISC00 = 0.
[18:57:57] <Bushman> and i clearly changed ISC00 to 1
[18:58:12] <Valen> unless you have debouncing when you hit the button you will trigger the interrupt, then it'll bounce and trigger again then when you release it'll trigger again
[18:58:20] <Bushman> which should result in triggering ONLY when there is a CHANGE
[18:58:44] <Bushman> it's not rebounce.
[18:58:45] <twnqx> really, 1s delay in an interrupt handler?
[18:58:48] <Valen> it cant "keep triggering" unless it keeps getting a new signal
[18:59:00] <Valen> twnqx: I'm guessing this is a proof of concept ;->
[18:59:20] <Valen> I'd really suggest wiring up another LED btw, leave your main loop flasher running
[18:59:27] <Bushman> twnqx: this is learning process... i'm debuging by LED... what did you expect?
[18:59:39] <Valen> actually theres a question, does _delay_ms turn interrupts off?
[18:59:47] <twnqx> that you'd do it RIGHT the first time :P
[19:00:05] <twnqx> interrupts will be disabled anyway
[19:00:11] <twnqx> 'cause he's in ISR
[19:00:23] <Valen> fair point
[19:00:36] <twnqx> fast flashing can only happen if he exceeds the maximum size in _delay_ms
[19:01:11] <twnqx> can't remember if you can stay in _delay for 1 full s or if you overrun the code
[19:02:03] <Bushman> i've used _delay_ms(); with values of 5000 without any problem
[19:02:11] <Valen> oh, a thing to check, you don't have your button wired to reset or one of the jtag pins or something do you?
[19:02:26] <Bushman> heh, no
[19:02:28] <Valen> I've done that far too often
[19:02:30] <Bushman> it's not a button
[19:02:45] <Bushman> it's a wire on a breadboard
[19:02:45] <twnqx> Bushman: weird.
[19:02:49] <twnqx> The maximal possible delay is 262.14 ms / F_CPU in MHz.
[19:03:00] <Bushman> it's either IN or OUT
[19:03:09] <twnqx> straight from /include/avr/util/delay.h
[19:03:21] <Bushman> hmm...
[19:03:33] <Bushman> then why does it work lol?
[19:03:44] <twnqx> If the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long)
[19:03:44] <twnqx> support, maximal possible delay is 4294967.295 ms/ F_CPU in MHz. For
[19:03:44] <twnqx>
[19:03:52] <twnqx> probably ou use a different toolchain then
[19:04:07] <Bushman> heh
[19:04:13] <Bushman> yea, most likely
[19:04:39] <Bushman> i use the avr-gcc that was provided by debian repos
[19:05:03] <Bushman> but let's get back to the interrupt behaviour
[19:05:05] <twnqx> also because of other things
[19:06:03] <Xark> Bushman: I believe that one is somewhat out of date...
[19:06:12] <Bushman> can someone verify i'm using correct registers and bit names?
[19:06:26] <Bushman> Xark: "somewhat" ?
[19:06:36] <twnqx> i'll rather go to sleep
[19:06:38] <twnqx> good night folks
[19:06:48] <Bushman> g'nite twnqx
[19:06:55] <Xark> Bushman: 4.8.1 or later is good.
[19:07:34] <Xark> Bushman: I believe latest supported from Atmel.
[19:07:40] <Bushman> umm... how does that influence interrupts handling?
[19:08:15] <Xark> Bushman: I am not saying it does. :) Just that older Debian AVR toolchain is often a minor source of grief. :)
[19:09:34] <Bushman> i have 1:4.8.1+Atmel3.4.4-2 installed
[19:11:06] <Bushman> Xark: can you at least help me verify that i have in fact wrote what i intended to write?
[19:11:48] <Bushman> cause from my point of view everything works except EICRA register
[19:12:03] <Bushman> it seems as if it was all zeros in there
[19:12:29] <Bushman> at least that's how the thing behaves on my table
[19:13:16] <Bushman> it now blinks slow and steady as i have not removed the connection from int0 to ground.
[19:14:08] <Bushman> the code in the interrupt handler is being executed correctly, only the Interrupt Sense Control is wrong
[19:17:30] <Bushman> Xark: thoughts?
[19:28:22] <Bushman> all the examples in the net say the same thing
[19:28:33] <Bushman> https://sites.google.com/site/qeewiki/books/avr-guide/external-interrupts-on-the-atmega328
[19:28:52] <Bushman> "EICRA |= (1 << ISC00); // set INT0 to trigger on ANY logic change"
[19:29:00] <Bushman> ANY is the keyword
[19:29:54] <Bushman> and unless i have some serious sight impairment today, this looks exactly the same in my code:
[19:29:57] <Bushman> EICRA |= (1 << ISC00);
[19:31:39] <Bushman> anyone?
[19:35:32] <Xark> The bug is no expected interrupts?
[19:35:37] <Lambda_Aurigae> Bushman, try different settings for the settings.
[19:35:48] <Lambda_Aurigae> for the triggering settings.
[19:35:58] <Lambda_Aurigae> 00, 01, 10, 11...and see what happens to each one.
[19:36:04] <Lambda_Aurigae> might be a typo or problem with the chip.
[19:36:16] <Lambda_Aurigae> there might be an errata out there for it too.
[19:37:31] <Bushman> hmm...
[19:37:39] <Bushman> the datasheet is straight from atmel website
[19:38:10] <Lambda_Aurigae> but sometimes it is wrong.
[19:38:17] <Bushman> you think they would publish this thing with such obvious error without no one noticing?
[19:38:17] <Lambda_Aurigae> that's why they have errata updates.
[19:38:26] <Bushman> hmm...
[19:38:55] <Bushman> ok, i'll go throuh all the options and check each behavior
[19:42:24] <Bushman> Lambda_Aurigae: no change.
[19:43:44] <Lambda_Aurigae> could be a problem with that _delay_ms inside of the interrupt routine then.
[19:44:45] <Bushman> explain why?
[19:44:51] <Bushman> i don't see a connection here
[19:45:31] <Bushman> the interrupt is called, and it is stopped being called again and agina AFTER i let go of the button
[19:45:37] <Lambda_Aurigae> I haven't looked at the code inside that delay so not sure.
[19:46:02] <Lambda_Aurigae> without actually testing the code, I don't know.
[19:46:15] <Lambda_Aurigae> and not currently in my workshop with stuff to test.
[19:46:19] <Bushman> no, i mean why do you even suspect the delay if it does what it suppose to do?
[19:46:45] <Lambda_Aurigae> I always suspect code I haven't reviewed.
[19:46:49] <Lambda_Aurigae> specially inside an ISR.
[19:48:09] <Bushman> will it change anyting in how you view this situation if i told you i'm currently not using delay in the interrupt handler?
[19:48:48] <Lambda_Aurigae> maybe, but, again, I would need to run it on live hardware and play with it to see what it's doing.
[19:48:58] <Lambda_Aurigae> something is amiss...and not sure what I'm a missing.
[19:54:57] <Bushman> so yea, i've removed all delays from this interrupt.
[19:55:09] <Bushman> i'm changing the PWM value instead.
[19:55:12] <Bushman> this also work.
[19:55:46] <Bushman> but it also works "all the time" and not "on ANY change"