Adventures in TinyAVR 1-Series

285 posts / 0 new
Last post
gchart
gchart's picture
Offline
Last seen: 41 min 36 sec ago
Joined: 03/19/2016 - 11:57
Posts: 3173
Location: Central IL

Not without some code modifications. In “fsm-adc.c” you’ll see a reference to VREF_ADC0REFSEL_1V1_gc. For a one-off build you could change that value, or the code could be updated to read that register from a #define … but that’s still a code change, simple though it may be.

thefreeman
thefreeman's picture
Offline
Last seen: 22 min 5 sec ago
Joined: 01/06/2020 - 09:56
Posts: 973
Location: France

Yeah I saw that line but I imagined it might need some change to allow to do it in hwdef. We’ll I’m already using modified Anduril files so I might as well change it in fsm-adc.
Thanks.

thefreeman
thefreeman's picture
Offline
Last seen: 22 min 5 sec ago
Joined: 01/06/2020 - 09:56
Posts: 973
Location: France

I check the availability of the 1616 from time to time, on 17/06/21 there was :

Mouser : 82 expected for 17/07/21
Farnell : 6004 expected for 28/07/21
Digikey : 1545 expected for 25/06/21

Today :
Mouser : 12000 for 03/22
Farnell : 1079 for 14/07/21, more for 06/22
Digikey : 2830 for 24/09/21, 8200 for 01/22

gchart
gchart's picture
Offline
Last seen: 41 min 36 sec ago
Joined: 03/19/2016 - 11:57
Posts: 3173
Location: Central IL

Ugh. Thankfully my Mouser order I placed in February is en route to Mouser (from the manufacturer) with the expectation for it to ship in July. Fingers crossed.

thefreeman
thefreeman's picture
Offline
Last seen: 22 min 5 sec ago
Joined: 01/06/2020 - 09:56
Posts: 973
Location: France

Same for me, I ordered when there was 82 left for the arrival in July.

jon_slider
jon_slider's picture
Offline
Last seen: 12 hours 1 min ago
Joined: 09/08/2015 - 12:20
Posts: 5219
Location: Central North America

yay progress!
Looking forward to the AA compatible driver for my FWAA Wink

Scallywag
Scallywag's picture
Offline
Last seen: 15 hours 21 min ago
Joined: 01/11/2018 - 22:23
Posts: 2200
Location: Ohio, United States

jon_slider wrote:
yay progress!
Looking forward to the AA compatible driver for my FWAA Wink

That’s unlikely. I doubt there’s enough room in there for a boost driver for the lower voltage support.

It’s a bit of a different situation than the SP10S, which already had a working driver with the wrong UI/MCU.

jon_slider
jon_slider's picture
Offline
Last seen: 12 hours 1 min ago
Joined: 09/08/2015 - 12:20
Posts: 5219
Location: Central North America

ok, thanks for the extra details..
I did not realize the Sofirn is uniquely Boosted

In that case, I will not be waiting to inhale Beer

Microa
Offline
Last seen: 9 hours 5 min ago
Joined: 06/29/2011 - 21:20
Posts: 251

I failed to build the Hex file for RampingIOS-ConvoyH1 by Atmel Studio 7. It showed four errors
1) RampingIOS-ConvoyH1_T412.elf section ‘.text’ will not fit in region ‘text’
2) region ‘text’ overflowed gy 72 bytes
3) recipe for target ‘RampingIOS-ConvoyH1_T412.elf’ failed
4) ld returned 1 exit status
Did I miss some setting to optimize the code build?

Mike C
Mike C's picture
Offline
Last seen: 6 days 2 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2585
Location: Sweden

I don’t know if you missed optimizing, you can check. Right click on your solution in solution explorer, select properties and check your optimization settings:

If it’s not this I wouldn’t know.

Microa
Offline
Last seen: 9 hours 5 min ago
Joined: 06/29/2011 - 21:20
Posts: 251

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

Tom E
Tom E's picture
Offline
Last seen: 31 min 14 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14943
Location: LI NY

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.

thefreeman
thefreeman's picture
Offline
Last seen: 22 min 5 sec ago
Joined: 01/06/2020 - 09:56
Posts: 973
Location: France

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 Big Smile )

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.

Tom E
Tom E's picture
Offline
Last seen: 31 min 14 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14943
Location: LI NY

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.

thefreeman
thefreeman's picture
Offline
Last seen: 22 min 5 sec ago
Joined: 01/06/2020 - 09:56
Posts: 973
Location: France

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.

Tom E
Tom E's picture
Offline
Last seen: 31 min 14 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14943
Location: LI NY

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...

Tom E
Tom E's picture
Offline
Last seen: 31 min 14 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14943
Location: LI NY

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.

thefreeman
thefreeman's picture
Offline
Last seen: 22 min 5 sec ago
Joined: 01/06/2020 - 09:56
Posts: 973
Location: France

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)

thefreeman
thefreeman's picture
Offline
Last seen: 22 min 5 sec ago
Joined: 01/06/2020 - 09:56
Posts: 973
Location: France
Tom E wrote:

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…

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…

Tom E
Tom E's picture
Offline
Last seen: 31 min 14 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14943
Location: LI NY

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.

thefreeman
thefreeman's picture
Offline
Last seen: 22 min 5 sec ago
Joined: 01/06/2020 - 09:56
Posts: 973
Location: France

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) :

Quote:
1,19,52,103,176,276,406,572,776,1023,1,3,8,14,25,39,58,82,112,149,193,245,305,375,455,545,646,759,884,1023

With this :

Quote:

#define LED_ENABLE_PIN_LEVEL_MIN 1 // Op amp enable
#define LED_ENABLE_PIN_LEVEL_MAX 30

#define LED2_ENABLE_PIN_LEVEL_MIN 11 // HDR FET turns on at ramp level 11
#define LED2_ENABLE_PIN_LEVEL_MAX 30


(*)

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.

thefreeman
thefreeman's picture
Offline
Last seen: 22 min 5 sec ago
Joined: 01/06/2020 - 09:56
Posts: 973
Location: France

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.

Tom E
Tom E's picture
Offline
Last seen: 31 min 14 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14943
Location: LI NY

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

SammysHP
SammysHP's picture
Offline
Last seen: 1 hour 59 min ago
Joined: 06/25/2019 - 14:35
Posts: 1031
Location: Germany

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

Tom E
Tom E's picture
Offline
Last seen: 31 min 14 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14943
Location: LI NY

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.

 

thefreeman
thefreeman's picture
Offline
Last seen: 22 min 5 sec ago
Joined: 01/06/2020 - 09:56
Posts: 973
Location: France

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.

SammysHP
SammysHP's picture
Offline
Last seen: 1 hour 59 min ago
Joined: 06/25/2019 - 14:35
Posts: 1031
Location: Germany

thefreeman wrote:

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, …
thefreeman
thefreeman's picture
Offline
Last seen: 22 min 5 sec ago
Joined: 01/06/2020 - 09:56
Posts: 973
Location: France

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

Tom E
Tom E's picture
Offline
Last seen: 31 min 14 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14943
Location: LI NY

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.

thefreeman
thefreeman's picture
Offline
Last seen: 22 min 5 sec ago
Joined: 01/06/2020 - 09:56
Posts: 973
Location: France

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.

Pages