Look at section 37. Power consumption is more or less linear, but even at 10 MHz only 4 mA, so not worth to think about it. 
Thanks, I’ll do that.
Another question :
Is it possible to change the internal reference voltage in the hwdef file ? Using 2.5V instead 1.1V allows to use a divider with the same values, it’s a small detail but reducing the amount of different resistor values is always a good thing.
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.
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.
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
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.
Same for me, I ordered when there was 82 left for the arrival in July.
yay progress!
Looking forward to the AA compatible driver for my FWAA 
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.
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 
I failed to build the Hex file for RampingIOS-ConvoyH1 by Atmel Studio 7. It showed four errors
- RampingIOS-ConvoyH1_T412.elf section ‘.text’ will not fit in region ‘text’
- region ‘text’ overflowed gy 72 bytes
- recipe for target ‘RampingIOS-ConvoyH1_T412.elf’ failed
- ld returned 1 exit status
Did I miss some setting to optimize the code build?
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.
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 
)
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)