Adventures in TinyAVR 1-Series

Thankyou Sir,
The problem was solved. My original setting was -Og. I changed to -Os, The Hex code was complied successfully.

thefreeman - is your 5 amp linear (CC ?) 1616 driver working? Very much interested. If so, I can try updating the files to OSHPark to run off copies. Let me know.

I never built it, went directly to dc-dc converters, I don’t see why it woudn’t work but still, it’s better I test it before sharing it.

There is one thing about the HDR function that requires some additionnal code though, which I partially did : the HDR FET needs to be turned on above a certain ramp level, so that the sense resistor is switched to the low value one for the high current range. I used LED2_ENABLE_PIN for that and copied the code from LED_ENABLE_PIN so that they could be set at different ramp level. (copy pasting is about the extent of my coding skill :smiley: )

The thing left to do is to add a delay when the HDR FET turns on (but not for off), as we ramp up the PWM level reaches the top of the low current range (1023/1023), then on the next ramp level the FET turns on, the PWM level is back to 1 but it takes some time for the voltage that set Vsense to go back to 1/1023 due to the RC filter, it only last a few ms but that enough for a very undesirable flash.

I have no idea how to do that so I added the delay in hardware in the other drivers I’ve been developing since then, it requires 2 resistors, a cap and a diode which is a bit ridiculous. I would love for proper anduril support for this added.

Anyway I need to add those to the board, there should be enough space so that it stays one sided.

Yea, the delay is difficult to work around for smooth ramping, but if it's only at the transition point and you enable the blink at the channel transitions, wonder if it would be noticeable.

Ah, how long is the blink ? is it easy to change ? need about 10 20 ms depending on the RC values chosen.

edit : but it will still be a problem for stepped ramping.

I finished the changes :

I’ll order and test it.

You think the 10-20 ms would be noticeable in stepped mode? Dunno off hand the delay value, but maybe it could be compensated for because there has to be a fairly significant delay between bumps, like 100-200 msecs or so I'd guess. I should look it up...

Looks like the blink from level to level is done by blip() in misc.c, and it goes dark for 12 msecs. Still looking for the stepped timing.

It seems that it just sets the level at 0, which won’t solve the problem. It would need to set the LED_ENABLE_PIN low to turn off the LED (or better the LED2_ENABLE_PIN, i.e. the HDR FET, that way no blink and no flash)

I’m not sure I understand exactly what you meant here, but yes it’s nearly as noticeable in stepped mode, the difference is that the highest step on the low current range might not be at max PMW level, so the flash can be less intense than in smooth mode, regardless it’s quite strong especially with powerfull drivers (like with my 5A/6V boost driver).

About the linear driver I added a diode for reverse polarity protection, I’m not really happy with it because it will start to lower the output when the cell falls below ~3.1V. I remember searching for LDO with reverse current protection (for the MCU) and reverse batt protection (for the LDO) but I never found a suitable one. Anyhow it’s optional.

Also I’ve been working on a high efficiency dual 6A buck (12A total) with common cathode and HDR for tint ramping (or dual channel in general) that would fit inside the D4v2 :

The common cathode design simplifies wiring and modification of MCPCBs, I’ve already done this on a D4v2 MCPCB it’s quite doable, separate cathodes would have been impossible even with a special MCPCB, to many wires. Here the cathodes don’t even need to be connected with a wire if the connection is made with the body by the mounting screws.

Optionnaly, only one channel can be populated to make a single channel 6A driver.

But it has additional issues with HDR :

‐ since it uses PFETs the FETs are off with signal high, and on with signal low, so the delay needs to be on pin low.

- if I understand correctly each channel gets a calculated PWM level depending on the tint, instead they would need to get the PWM level from the ramp, not by calculation, and also need to know when to turn on/off the HDR FET on each channel. Probably some big code change/addition needed here…

Guess I"m confused - I thought there was just a simple delay but you are referring to a flash and I'm not sure what that means (high output or OFF, etc.). I suppose if it's not a simple delay, then yes - stepped or smooth, it's noticeable.

Also don't know what 'HDR' is, or 'cathode' is, in the context you are using them. I'm definitely weak in some areas.

Yes sorry I should have detailed more.

Cathode is the LED - (anode is +).

HDR stands for high dynamic range dimming. If you have a driver with one power channel like a linear or buck/boost driver you are limited by the resolution of the PWM, so 8bit or 10bit (higher then becomes limited by the precision of the current sensing circuit) but that’s still not enough for moonlight modes, a 5A driver with 10bit PWM can only be dimmed to ~5mA which is arround 1.5lumen.
To get a much higher resolution I use (like Zebralight, Armytek, Loneoceans, Mike C) multiple sense resistors, 2 in my case (ZL use 3 in most of their drivers), which are selected with a mosfet (which I call HDR FET), here is the shematic of the linear CC circuit :


(R9 should be 10Ω here, not 5. R11, R10, D2, C6 are for the hardware delay)

To quickly go over how the constant current regulation works : In this configuration the op amp will increase or decrease the gate voltage of Q1 (acting as a variable resistor) so that the voltage at the inputs of the op-amp, Vset and Vsense, are equal. In order to get the desired current we apply whatever voltage gives us the desired voltage drop across Rsense. If we choose 50mV Vset, we get 50mV Vsense, with Rsense = 10mΩ that means 5A. Basically this is a voltage to current circuit.

But Anduril only outputs a PWM signal, the attiny1 series do have a DAC (8bit) for outputing an analog voltage but there is no support for it in Anduril, so we convert that PWM signal into a voltage with an RC filter. The downsides are that it doesn’t smooth it completely (ripple), but with a C value high enough it’s good enough, and it takes some time for the voltage to rise/fall :

This is with the values in the shematic, with a PWM freq of 10kHz, duty cycle of 50% and a PWM voltage high of 50mV, it takes about 15~20ms to reach the desired voltage (25mV), and consequently the desired current.

Getting back to the HDR function, when the HDR FET (Q2) is ON the sense resistor is Q2(~2mΩ)+R8 = 10mΩ (there is R9 in parallel but it’s too high to matter), with Vset = 50mV current = 5A. At PWM 1/1023 we get ~5mA (just dividing by 1000 to simplify).
When the HDR FET is OFF the sense resistor becomes R9, the current at 1023/1023 becomes 5mA, and at the lowest level 5μA ~ 0.0015lm.
Effectively we get 20bit dimming with 10bit PWM. Though in some cases when Vsense is too low the output can be unstable, so we might not use the PWM level 1 or 2, decreasing the total resolution, but there is still plenty enough.

For reference the SC/H600 mkII have the lowest level at 100μA.

In CFG the ramp looks like this (only 30 steps to not break the page) :

With this :

(*)

We ramp up and reach ramp level 10, PWM 1023/1023 Vset/Vsense = 50mV, current =5mA because HDR FET is OFF, Rsense=10Ω, then it reaches ramp level 11, HDR FET turns ON, Rsense is now 10mΩ, due to the RC filter Vset is still at 50mV (5A) and fall to 50uV (50mV/1023) over the course of 15~20ms : that’s the flash.

So we can either add a delay on the HDR FET so that it takes >20ms to turn ON (that’s what I’ve done in hardware, but software would be miles better), or like you suggested use the middle ramp blink to turn the LED OFF during the Vset settle duration.

(*) Typing this I just realised that PWM level 0 in the blink function will actually turn off the op-amp/linear FET (Q1), contrary to what I said in the comment above, I’m stupid…
I’ll test that, I do worry that the op-amp doesn’t turn off instantly.

Alright it works for the smooth mode but not for stepped mode, I guess one step needs to be exactly on the transition level so that it blinks, which is technically possible but then the ramp and number of step are tied together and the later can’t be changed afterwards in the UI.

Just fyi, I'm reading all this and do understand most of it. Thanks!

Btw: ToyKeeper has implemented higher resolution PWM and “jump start” yesterday in the anduril2 branch.

Ok, I'll bite. What's jump start? And how exactly, what exactly did she do with higher PWM's?

Brief list of changes here over the last day or so: https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/anduril2/changes/606

She took it from 598 to 606, mostly on the KR4.

"added a "jump start moon" option for hold-from-off, for lights with slow-activating circuits (briefly pulses the light at a higher level to wake up the circuit faster)"

Guess this is for problems with the KR4 as well, nothing like a new feature.

With the Noctigon linear driver the LED can take a second or so to lit up on the lowest level (not sure why), with jump start apparently it starts at a higher level then go back to the actual level.

Dynamic PWM : likely to prevent noise during thermal throttling, since the PWM runs at 4kHz (10bits) in the Noctigon driver the bulk 0805 cap can sing. So here resolution is decreased to 8 bit for the FET and frequency increased to 16kHz so that it’s not audible.

No, to change the timing to get higher resolution in the lower levels. Like 1/10, 1/9, 1/8, 1/7, 1/6, 2/10, 2/9, 2/8, …

Ah yes, I assumed that was the implementation starryalley’s dynamic resolution but no.

I reflowed my first 1616 MCU last night on my tweaked gchart 20 mm driver boards. It's just an old FET+1 but what a PIA soldering that VQFN-20 part. I must have made like 8-10 attempts at it, but hoping the next will go easier. I made my own 22-23 mm version that can be sanded down a couple mm's to fit various lights.

One of the 23 mm's sanded down will be going in a cheap 18650 small zoomie with an e-switch. By cheap I mean like paying $7 shipped.

I think what I'll do is use very little solder paste for the middle pad, and don't reflow the pins. For the pins I'll hand solder with just laying a thin stripe of solder paste across each side of 5 pins, then working it with the small tip iron. Might need the solder wick as well.

For the one I did last night I first tried paste all around and ended up with big balls of solder on each side, crossing all 5 pins. Eventually what worked was hot air removal of the MCU, solder wicked the pads clean, then hot air reflowed the MCU back on. I think the MCU had enough solder on the pins to bond well and still stay clean. All this time the driver was on a 100C hot plate.

Personnaly I’m using a stencil I made a while ago, just for the 1616.

Another way is to tin the pads and then reflow.