Testing with 10K resistors on the status leds, same result.
Moving led enable to PA5
PB0 PWM
PA5 led enable
PA1 R
PA2 G
PA3 B
No led enable.
Circuit on the breadboard :
I also checked with a voltmeter instead of status leds (i.e. the pins are only connected to the voltmeter), same result, I just used leds because it’s quicker for checking the pins status.
So at this point I’m eliminating any issues with the circuit, it must be in the code.
In the present state if I want to use the attiny1616 with my driver I must wire the PWM, led enable and RBG on different ports, which is possible of course, just not as convenient as using any pins. But if there is functionality added for the current sense resistor selection, then that’ll possibly means it’ll have to be on another (nonexistant) port. (Toykeeper said she has an unfinished branch that might have functionality for this).
Edit : for the 3rd question I’m guessing no, anduril apparently turns the flashligh off (led enable goes off) when putting 0 as the floor so it’s not obvious, but shortly before that the level just stops at 1/1023 for like half a second, instead of smoothly going to 0.
Looking with the scope, it seems that having the PWM pin (e.g. PB0) connected to a floating pin (e.g. PC0), doesn’t affect the waveform. The difference in current draw with the floating pin is about 50~100uA. I might do that, that way the hardware would be compatible with both TCA and TCD.
Interesting thefreeman, I thought that a floating pin would consume a significant amount of power.
Thanks all of you for sharing your progress, it is being a really entertaining reading for me.
Great to know! That would certainly be handy for a development/testing build so that you can play around with trying to get TCD working. The 50-100 uA isn’t a whole lot, but more than I would want in a production light. Is that the case for both while the MCU is awake and sleeping? I’ve always heard that a pin shouldn’t be left floating in order to minimize current draw, but I’ve been curious about just how big of an impact it makes.
So after of before the LDO it works, also when powered by another source e.g. the battery. Mike already mentionned it but with the LDO I wanted to test to be sure.
Good to know! I haven't experimented much with it, but ElTangas says that as long as the VCC at the MCU is ~60%+ of the programmer's voltage, it should work just fine.
I just pushed a few changes to my Anduril2 branch:
Switched to 10 MHz clock and Phase-Correct (dual slope) PWM instead of Fast (single slope) PWM at 5 MHz. This results in the same effective PWM speed: 19.6 kHz in the upper ranges, down to 4.9 kHz in the lowest modes (due to the dynamic underclocking mechanism).
Added some documentation to the PWM setup code including a some instructions and a link to the datasheet
Instead of Factory Reset forcing a thermal offset to assume an ambient temperature of 21°C, a Factory Reset for the 1-Series will clear any user-set thermal offset since the internal sensor is factory calibrated.
phase correct allows for full on and full off PWM, are there other advantages ? For drivers where we use the filtered PWM signal it’s not really an issue to have 1/resolution-1 as the min/max, and running the MCU slower saves power so if there are no other advantages then fast PWM is preferable.
I’m not aware of other benefits, it’s mostly to just get the Full-On and Full-Off signals.
For the drivers with a filtered PWM signal, you can still use Single Slope (Fast) when setting up the PWM in hwdef. And in the config file, just set the QUATERSPEED_LEVEL and HALFSPEED_LEVEL really high so that the MCU is running underclocked most all of the time. At least that’s the easiest thing I can think of at the moment.