That Geko looks like a decent ZL clone - except if there’s no moonlight there’s no point cloning ZL (to me anyway)
I’ve been away for a while… nice to see that your work with 1-series is catching on.
Maybe I’m being a stickler, but the 1 series doesn’t need three flashing pads. It’s needs GND and UDPI, and the MCU needs to be powered. If I don’t have the driver powered already I just connect V+ from the Xplained Nano to the battery spring with a crocodile clip.
Another thing… you mentioned shortage of 1616s and you see them on Farnell UK. The US branch newark.com has them in stock (selling fast though), do you still have to pay that much postage if you order through Newark? They do refer to UK stock but you might be able to get around the shipping? I can’t order from Farnell UK directly myself, but in Sweden we have a components shop that allows anyone to order from Farnell UK and only pay local Swedish postage from the Swedish shop. I just got a bunch of 1616s delivered. Perhaps there is a similar service in the US for Newark if you can’t order from them directly?
I think when I tried Newark, it was quoting me outrageous international shipment fees since the stock was going to come from UK.
I agree, you don’t need VCC if the MCU is powered, but what if you want to flash a driver that isn’t installed in a flashlight? Or it’s not able to be powered when you have access to the flashing pads (most flashlights)? In my mind, it’s no more difficult to include all 3 pads and it gives you more flexibility. Just my 2 cents.
Hmm, and here I was wondering if it mattered if the V+ for flashing was connected before or after the LDO, if like, the MCU was powered from a lower voltage (ldo voltage) than the UDPI signal it would cause issues (maybe a stupid question…).
FWIW, when making one of my programming keys, I accidentally put the resistor inline with the VCC line instead of the UPDI line. If I remember right, the computer didn’t even recognize that the MCU was connected. So I just connect the pins directly at the MCU, without anything like LDOs or diodes in the path.
Just as I wrote, I have V+ from the Xplained Nano connected to the battery spring by a crocodile clip. The Xplained Nano powers the MCU. You did write you made the change to make layout easier, I just added this because layout is even easier with two pads instead of three, it works fine for me.
sorry, I was skimming as I’m working at the moment. I should know better than to try multi-tasking…
Well I’ll be! They got a batch in earlier than expected. I’m halfway tempted to try and cancel my Mouser order and place one at Digikey.
Aaaaannndd they’re gone
Yeah lol, a few moments after I ordered, I also wanted a buck IC, some 9000 in stock in the morning, then zero in the afternoon when I placed my order, plenty of other ICs have poor availability too.
They’re also gone from Farnell.
I had 2 in my cart along with a few odds and ends and saw this this morning when I finally was ready to checkout.
Gchart, do you have an example hwdef file with TCD ?
Sorry, I haven’t used TCD with Anduril yet. But I do have a fairly bare bones TCD 10-bit PWM test code here:
http://www.ghart.com/blf/firmware/Tests/pwm_tcd_led.c
It’s been a while since I’ve played with the TCD, I should do that again. Let me know if you run into issues and I might be able to provide some pointers or run some tests on the Xplained Mini dev board.
Oh… for now I’ve just been copy pasting code from other files so that’s a bit problematic 
I tested with test code, it worked.
This is where I'm at for my boost driver.
hwdef file : (removed since it was a bit long)
Oh actually, maybe the ramp could just be like this, with only one PWM (example with ramp lenght of 10)
PWM1_LEVELS 2, 500, 1023, 2, 20, 50, 100, 200, 500, 1023
With the mosfet for the high current range enabled from level 4 to 10.
I hate to break it to you, but it looks like Anduril will need some (hopefully minor?) updates/customizations to make TCD work. If you check out page 250 of the datasheet you’ll see how the TCD works with CMPxSET and CMPxCLR. It’s opposite of how we normally think of PWM. If you set CMPxSET to 0, the LED would be fully on. If you set it to 255 (8-bit) or 1023 (10-bit), then the LED will be fully off. You’ll notice that in my test code, I subtracted the desired PWM value from the period to get the inverse.
Also… you need to tell the TCD to synchronize any time you make a CMPxSET (or CMPxCLR) update. That’s the “TCD0.CTRLE |= TCD_SYNCEOC_bm;” line in my test code.
Pretty much anywhere PWMx_LVL is used, it’ll require a small update. After grepping around, it looks like most of the changes are going to be in fsm-ramping.c. There are also a couple lines in fsm-main.c and spaghetti-monster.h. None of the changes should be too terrible. If you want, I could make the changes if you’d like to test them.
Page 250 you mean ?
Honestly I’m not understanding much of what I read, so yeah, any help would be greatly appreciated
I knew I should have used PA4 or PA5 since they can be used with TCA, but tracing was easier with the opposite pins…
Edit : maybe, if you’re interested in this boost driver, I could send you one.
Yeah, I meant 250… oops.
Now that I think about it, the easiest thing to do might be to mimic some of what the Noctigon K9.3 is doing. It has an override for the set_level function defined specifically for it, all controlled in cfg files. Note how the top of the cfg-noctigon-k9.3.h file says:
// this model requires some special code
#define OVERRIDES_FILE cfg-noctigon-k9.3.c
#define OVERRIDE_SET_LEVEL
#define OVERRIDE_GRADUAL_TICK
inline void set_level_override(uint8_t level);
and then there’s a specific “c” file to contain those override functions. We’ll probably want to do the same thing. Then you can set things like “when level == 0 set the PWMx_LVL = PERIOD” and “PWMxLVL = PERIOD - PWM_GET(x,y)” as well as being able to say when to turn on and off those specific current set resistor channels.