BLF driver programming key v3.2 launched on Oshpark

81 posts / 0 new
Last post
ToyKeeper
ToyKeeper's picture
Online
Last seen: 40 sec ago
Joined: 01/12/2013 - 14:40
Posts: 9996
Location: (469219) 2016 HO3

Mostly, I just want this to be a thing… like, yesterday. And I hope we can get someone to manufacture keys and sell a flashing kit. It looks like a huge upgrade to how we’ve been doing things, and it could enable the use of smaller and fancier MCUs.

staticx57
Offline
Last seen: 4 hours 21 min ago
Joined: 04/11/2016 - 00:43
Posts: 681
Location: New Jersey, United States

Lexel, this is huge and awesome. Great work!!

Please don’t make it fiddly, having to play with croc clips and stuff. Make it fit one way and easy to connect.

Tom Tom
Offline
Last seen: 7 months 3 weeks ago
Joined: 09/10/2017 - 08:30
Posts: 1163

Lexel, I must apologise. Somehow I had got the wrong impression that you were duplicating the 0.1 inch pitch connection that has been around for ages.

I now realise that you have chosen the 0.05” (1.27mm) pitch micro key, which is the correct decision.

The “standard” pad layout is the same, just 1/4 the area.

The tindie micro key (others may be available) shows a reasonable looking pad layout, with a square pad to indicate correct alignment. I’m not sure how more “foolproof” it needs to be.

See https://www.tindie.com/products/madworm/tiny-avr-isp-pogo-pin-programmin... and look through the photos.

My suggestion would be to include the USBasp circuit on the key, make it an integrated solution, micro USB connector.

See e.g. https://www.fischl.de/usbasp/ for some ideas. Perhaps there are more recent developments ? I just have the FastTech USBasps which seem to still do the job, but connecting them up is a pain. An integrated pogopin key that you just have to press against the back of the driver would be marvellous.

Tom Tom
Offline
Last seen: 7 months 3 weeks ago
Joined: 09/10/2017 - 08:30
Posts: 1163

PS: If it could also do fuse restore using HVSP that would be icing on the cake.

ToyKeeper
ToyKeeper's picture
Online
Last seen: 40 sec ago
Joined: 01/12/2013 - 14:40
Posts: 9996
Location: (469219) 2016 HO3
Tom Tom wrote:
PS: If it could also do fuse restore using HVSP that would be icing on the cake.

That would typically fry the rest of the driver. HVSP usually involves unsoldering the chip first.

Joshk
Joshk's picture
Offline
Last seen: 4 hours 3 min ago
Joined: 09/09/2015 - 12:12
Posts: 1658
Location: USA

I just found this thread, and I really like the idea.
I have one suggestion, redo the layout so it is skinny, especially the tip with the pins. That way it’s as maneuverable as possible. It should feel like a probe when handled, not like a car key That fat handle was designed for twisting an ignition switch.

Tom Tom
Offline
Last seen: 7 months 3 weeks ago
Joined: 09/10/2017 - 08:30
Posts: 1163
ToyKeeper wrote:
Tom Tom wrote:
PS: If it could also do fuse restore using HVSP that would be icing on the cake.

That would typically fry the rest of the driver. HVSP usually involves unsoldering the chip first.

Yes but no. The pogopin adapter connects to the necessary pins I think. But they may, or may not need to be isolated from the rest of the driver during HVSP. The obvious one being the reset pin that gets 12V up it.

As for the other pins, it depends what’s attached to them, and whether they might give some interesting flashy effects during the process, or stuff the attached circuity if normally configured as an input. If so, maybe a series resistor would prevent that. That’s also if the LED was still connected.

To disconnect at least the reset pin would be traditionally done with a zero-ohm resistor. But can also be done at zero cost with a suitably designed track-cut area on the driver. Skills and a scalpel required. Then the track cut reversed with a solder splash over the top.

Or be radical, and add a seventh pin and maybe a small diode or FET to do this automatically.

Or reverse this idea, make the connect/disconnect points part of the layout, solder bridges connect them by default, remove it with skills, a sucker or braid if you need to reset the fuses.

Anyway it’s just another bonkers idea that would cost nothing to implement on drivers, if area permits. And for anyone into bespoke firmware (the whole point of this) it takes away the risk of bricking a driver. With all the nausea that would follow if already built up into a torch. Or simply the cost of the driver and sheer inconvenience of bricking one.

A quick google: https://www.instructables.com/id/AVR-HVSP-Fuse-Resetter/

Interesting that a tiny remote control 12V cell is enough to do the re-set.

Now, my idea is to combine the USBasp functionality with the AVR re-setter into one MCU and build the whole thing into the key. One MCU, already connected through the six pins. An exercise for someone to combine the code.

Driver designers might have to step up to the mark regarding circuit design, but it doesn’t look particularly difficult. Nor should it add to the cost, except for maybe one transistor and a few Rs. Even if very few ever use it, it could prevent many problems for developers, who may not have the skill, equipment, time or enthusiasm to de-solder, somehow connect (forget clips, decent MCUs are going/already leadless), flash, re-solder, try again. Better than tossing the driver.

Just throwing out these ideas in the hopes that a few might get some traction. This doesn’t have to all be done at once, just the 6 pin plain ISP 50/1000” connection will be a great start.

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 3 days 23 hours ago
Joined: 01/14/2016 - 16:38
Posts: 1187
Location: Germany

Integrating everything including HVSP is doable but far too much development work for the limited field of application in my eyes.

I think it’s easier to keep the board with the pogo pins separated and use a connector with the same pinout as the USB ASP programmers, so they can easily get connected without problems. With some (small) drivers a different pogo pin layout might be necessary due to space restrictions, a separate pogo pin board would here be better as well.

Lexel
Lexel's picture
Offline
Last seen: 21 min 32 sec ago
Joined: 11/01/2016 - 08:00
Posts: 5478
Location: Germany

so is HVSP is just 12V to the reset pin thats easy accessable on the key using the R pin, just on your USB stick you got to disconnect 5V

Basically all BLF driver designs have reset pin of the MCU insulated anyways
Most drivers have a shottky diode on Vcc so you do not have to bother powering up the rest of the driver

Last 7 days in Hospital I worked on Lantern driver

Feedback put in the latest version, I made it a bit shorter, but added one additional aligning pogo pin pad

the USBasp header is optional, of course a 90° version might be also a good idea, depends what you equip

WTF
Offline
Last seen: 3 hours 50 min ago
Joined: 03/05/2017 - 20:13
Posts: 265

The USBasp header looks like a nice finger pad.

Would it be possible to add a solder pad for pin one in case someone wants to use it for something one day?

There is a device for arduino users that should make fuse resetting easy. I haven’t looked at it too closely but it includes the source code.

https://www.tindie.com/products/soubitos/attiny-fuse-reset-shield/

What is the reason for the programming key? Is the programming clip unreliable or using up too much board space?

DavidEF
DavidEF's picture
Offline
Last seen: 6 hours 9 min ago
Joined: 06/05/2014 - 06:00
Posts: 7674
Location: Salisbury, North Carolina, USA

WTF wrote:
The USBasp header looks like a nice finger pad.

Would it be possible to add a solder pad for pin one in case someone wants to use it for something one day?

There is a device for arduino users that should make fuse resetting easy. I haven’t looked at it too closely but it includes the source code.

https://www.tindie.com/products/soubitos/attiny-fuse-reset-shield/

What is the reason for the programming key? Is the programming clip unreliable or using up too much board space?


IIRC, the ‘reason’ for this is to design future drivers to make use of this for convenience. No more fussy clips (maybe not all are fussy, but some are) and sometimes the MCU is legless, so a clip would be useless. Then there’s the access. Using a design like this makes it easier to flash while the driver is still installed in the device. That’s another point for convenience. There are already some drivers that feature vias for pogo pins so that the driver can be re-flashed. So, the idea was already there before this key was made. But, the key will make it easier for drivers that are designed to make use of it.

The Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy

Tom Tom
Offline
Last seen: 7 months 3 weeks ago
Joined: 09/10/2017 - 08:30
Posts: 1163
Lexel wrote:
so is HVSP is just 12V to the reset pin thats easy accessable on the key using the R pin, just on your USB stick you got to disconnect 5V

Sorry, but it’s a bit more complicated than that. AFAIK 12V has to be applied to reset, the MCU powered up from e.g. 3.3V, then some complicated talking (serial protocol) with the attached device. Several other pins involved.

Bigger chips can use a parallel programming solution, but you really don’t want to go there.

This is no different from attaching an USBasp or any other sort of asp e.g Arduino. Except for the high voltage and the different chattering that has to go on to re-set the fuses.

I am well out of my depth here, but the entire substance of this idea is to eliminate the clip and make/copy a standard pad layout for a pogo pin adapter/key. Preferably on the backside (accessible) of the driver without disassembly. But if that is not possible, the other side. Six pads including couple of location vias cost nothing, provided there is room. The fuse re-setter is just my mad idea, would be nice to have but not important (unless it can be done at minimal cost, I think so, but it would take effort to develop and I think we are over-stretching our firmware specialists already).

Basically, please forget I ever mentioned it.

Tom Tom
Offline
Last seen: 7 months 3 weeks ago
Joined: 09/10/2017 - 08:30
Posts: 1163

PS: why we call it an asp:

https://en.wikipedia.org/wiki/Asp_(reptile)

With thy sharp teeth this knot intrinsicate
Of life at once untie: poor venomous fool
Be angry, and dispatch.

—Cleopatra, Act V, scene II
Antony and Cleopatra

My dog knows an asp when he sees one, they are the only venomous snake in the UK (Adder) and gloriously bountiful where I live, but his instinct kicks in and he walks, or usually runs, away. As do the snakes.

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 11 months 3 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 580

I really welcome the idea of a programming key, as it would allow to program drivers that are soldered in or have short leads to the led. Or just not to have to pry out the SRK driver every time.
After looking at several drivers I got some additional thoughts.

  • The 1.30mm spacing will not be a problem.
    This is a slight increase to the 1.27mm footprint of the Attiny, while still well in line of the pads.
    With recent Oshpark design rules this allows a 10mil (0.254mm) trace between 16mil (0.4064mm) vias. The resulting distance is still >6mil (>0.1524mm).
    Oshpark’s resolution seems to be fine enough to allow for a 0.03mm shift.
  • I’d use as much unmasked vias as possible (instead of pads) on the driver, to allow for self aligning of the pogo pins.
  • A (pin-strip-) connector on the key is good.
    With pin strip connectors you are not bound to a certain layout and can change from driver to driver if necessary.
    You could solder for example 4+3 pogo pins to it and can then use it for drivers with different pad layouts.
  • If you stick with orientation pins, I’d not connect them to GND. Depending on components on a small driver you might short something to gnd while programming.
    Even better: connect the orientation pins to unused pins on the pin strip connectors, making them available for other pin layouts.

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

Fate0n3
Offline
Last seen: 4 months 16 hours ago
Joined: 05/04/2013 - 12:36
Posts: 178
Location: US
ToyKeeper wrote:
Mostly, I just want this to be a thing… like, yesterday. And I hope we can get someone to manufacture keys and sell a flashing kit. It looks like a huge upgrade to how we’ve been doing things, and it could enable the use of smaller and fancier MCUs.

I would also love to see something like this, help simplify a lot of things for new people like myself getting into the wonderful hobby. Hope to see this make it from concept to finished product!!!

Lexel
Lexel's picture
Offline
Last seen: 21 min 32 sec ago
Joined: 11/01/2016 - 08:00
Posts: 5478
Location: Germany

boards are ordered but will take a while

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 11 months 3 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 580

ToyKeeper wrote:
Mostly, I just want this to be a thing… like, yesterday.

Same here.

I just couldn’t help trying this out on some drivers of different sizes. TomTom has a point that a narrower key is better. So I tried 3+3 first. But I agree with Lexel as well, that some orientation guide is needed, I would not want to brick the MCU.

My favourite right now is a 4+2 design.

Especially as it fits quite easily inside the SOIC8 MCUs.
You need 6 pins anyway, plus orientation pin would make it at least 7 (4+3). Just leave it at 6, it wouldn’t be wider, and makes it inherently foolproof.

Like these.

.

.

.

.

.

Can hardly wait to get this going.
I like the 2nd one with all vias best, but I’m sure the others with 4 vias will align well.

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

zeroflow
Offline
Last seen: 2 weeks 3 days ago
Joined: 05/23/2017 - 02:15
Posts: 189
Location: Austria

Well, I think lexel's connector works pretty well.

I for myself would'nt really suggest anything better.

 

 

ToyKeeper
ToyKeeper's picture
Online
Last seen: 40 sec ago
Joined: 01/12/2013 - 14:40
Posts: 9996
Location: (469219) 2016 HO3

It’s not always easy to fit these things. Like with a QFN-20 chip, things work a bit differently. As much as I want there to be a standard connector, I think it’ll be pretty difficult to make that happen.

zeroflow
Offline
Last seen: 2 weeks 3 days ago
Joined: 05/23/2017 - 02:15
Posts: 189
Location: Austria

Yeah a standard will be hard.

But at least the new ATTiny line makes it easier as you need only GND, VCC and Reset for programming.

 

Otherwise, ranked from top to bottom, I would prefer

 

  • An existing connector (like this one)
  • 100mil spacing pads / pads
  • Documented layout of pads (incl. their position on the driver)
  • Just some pads, unaligned, undocumented
HarleyQuin
HarleyQuin's picture
Offline
Last seen: 11 months 3 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 580

@zeroflow
Nice work! 1+2+5 AMC7135 triple channel driver with dedicated moon? Yummy Smile

Only… Lexel’s connector wouldn’t work on your driver.
The connection points are inverted. The pinout (viewed from top) is:

Lexel key
SCK MISO MOSI
RES VCC GND
Z125M (green side)
MOSI MISO SCK
GND VCC RES

With Lexel’s pinout you’d have to use the key from the MCU side (orange side), which of course won’t work when the MCU is soldered on.
EDIT: But your layout looks fine. Hmmmm…

Anyway, don’t get me wrong, I’m far from insinuating that my 4+2 idea is best. I just wanted to show that there are reasons for a more flexible approach.

.

ToyKeeper wrote:
It’s not always easy to fit these things. Like with a QFN-20 chip, things work a bit differently. As much as I want there to be a standard connector, I think it’ll be pretty difficult to make that happen.
Yup… hear you.

There must be a reason that the keys you can find on the net have different pinouts, although 3+3 is quite common. But Lexel came up with even another distribution of the signals within the 3+3, simply what suited him.

Sure thing, a common standard would be nice. Makes it foolproof for users and for Lexel and his more commercial approach this is perfectly understandable. I’m very grateful he shared his thoughts on this, as he effectively introduced it to me as well.

Of course I’m in the comfortable position of making my own drivers and will make a ProgKey for my needs. This enthusiast approach is less foolproof, but more flexible. My idea is a key with 4+4 pogo pins and 8 pin strip connectors. This would allow for many different layouts (including a 3+3) on a very small footprint:

oooo      oooo      oooo       ooo
 oo       o  o       ooo       ooo 

The spacing that Lexel used is perfect in my eyes (0.4mm vias, 1.3mm/1.5mm spacing). This is for a 0.8mm pcb and the 0.68mm pogo pins. At least that can serve as ‘common ground’.

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 11 months 3 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 580

About the ‘inverted’ thing

@Lexel, do you really want to run with this key version?
Is it meant to be used on the MCU side of the driver? (this would very much limit the use)
Or shall it be used from below, then your markings are quite off
because
SCK MISO MOSI
RES VCC GND
is the top layout of the Attinys (with VCC pulled down center)

while the layout that @zeroflow used comes quite naturally for a 3+3 design on a smaller driver, when you access the programming pads from the non-MCU side, which would of course need mirrored pins

.

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

zeroflow
Offline
Last seen: 2 weeks 3 days ago
Joined: 05/23/2017 - 02:15
Posts: 189
Location: Austria

HarleyQuin wrote:
@zeroflow Nice work! 1+2+5 AMC7135 triple channel driver with dedicated moon? Yummy Smile ... EDIT: But your layout looks fine. Hmmmm... Anyway, don't get me wrong, I'm far from insinuating that my 4+2 idea is _best_. I just wanted to show that there are reasons for a more flexible approach. .

Yeah, the 1+2+5 is planned for my Emisar D4 mod with Nichia Optisolis LEDs where I don't need a FET.

Also, I'm still thinking about changing the anduril ramping code a bit so that there is a maximum number of "non-pwm" levels.

 

Currently, non-pwm levels are just 1x7135, 3x7135 and full 8x7135.

If I find enough time, my goal would be to have stepped ramping with the non-pwm 7135 levels 1, 2, 3, 5, 6, 7, 8.

Maybe I'll leave out 6 and 7 as those maybe have too little change in brightness.

 

Also: Thanks, i usually spend a big part of the time making my layout look nice and "flowing" instead of crossing traces everywhere.

Even tho the Moonlight channel is not regulated as it is just a series resistor to a MCU Pad, it should work just fine.

 

HarleyQuin wrote:
Only... Lexel's connector wouldn't work on your driver. The connection points are inverted. The pinout (viewed from top) is: +Lexel key+ SCK MISO MOSI RES VCC GND +Z125M+ (green side) MOSI MISO SCK GND VCC RES With Lexel's pinout you'd have to use the key from the MCU side (orange side), which of course won't work when the MCU is soldered on.

 

Yeah, I noticed that after ordering my PCBs. Typical error where I didn't check good enough

ToyKeeper
ToyKeeper's picture
Online
Last seen: 40 sec ago
Joined: 01/12/2013 - 14:40
Posts: 9996
Location: (469219) 2016 HO3

zeroflow wrote:
Yeah, the 1+2+5 is planned for my Emisar D4 mod with Nichia Optisolis LEDs where I don’t need a FET.

Also, I’m still thinking about changing the anduril ramping code a bit so that there is a maximum number of “non-pwm” levels.

If you do that, instead of 1+2+5, I’d suggest doing 1+1+2+4 — with PWM only on the first 1×7135 channel. It lets you do a no-PWM level every 350mA. As an added bonus, instead of using 24 bits per ramp level, the ramp data can be condensed to about 11 bits per level, or 8 bits per level (plus 8 bytes and a couple extra lines of code).

      1   1   2   4
0-1  PWM  0   0   0
1-2  PWM  1   0   0
2-3  PWM  0   1   0
3-4  PWM  1   1   0
4-5  PWM  0   0   1
5-6  PWM  1   0   1
6-7  PWM  0   1   1
7-8  PWM  1   1   1
zeroflow
Offline
Last seen: 2 weeks 3 days ago
Joined: 05/23/2017 - 02:15
Posts: 189
Location: Austria

ToyKeeper wrote:
zeroflow wrote:
Yeah, the 1+2+5 is planned for my Emisar D4 mod with Nichia Optisolis LEDs where I don't need a FET. Also, I'm still thinking about changing the anduril ramping code a bit so that there is a maximum number of "non-pwm" levels.
If you do that, instead of 1+2+5, I'd suggest doing 1+1+2+4 -- with PWM only on the first 1x7135 channel. It lets you do a no-PWM level every 350mA. As an added bonus, instead of using 24 bits per ramp level, the ramp data can be condensed to about 11 bits per level, or 8 bits per level (plus 8 bytes and a couple extra lines of code).
      1   1   2   4
0-1  PWM  0   0   0
1-2  PWM  1   0   0
2-3  PWM  0   1   0
3-4  PWM  1   1   0
4-5  PWM  0   0   1
5-6  PWM  1   0   1
6-7  PWM  0   1   1
7-8  PWM  1   1   1

 

That sounds like a good idea, but the boards are already ordered and shipped.

1+2+5+M was a compromise as I could reuse the existing triple-channel ramping code and just add a extra switch for the moon mode where one pin is set to low if the level is 0 and else is set to High-Impedance.

Tom Tom
Offline
Last seen: 7 months 3 weeks ago
Joined: 09/10/2017 - 08:30
Posts: 1163

1+1+2+4 looks good if you have enough pins, but light and human eyes don’t really work in a simplistic linear fashion, so I think it is a bit of a waste obsessing about the lowest levels and ultra-fine precision (i.e. the 1+1 end.

I suspect you will be fine with 1+2+5, and a bit of PWMing on two of the lower channels. Which might fit with smaller MCUs that have limited timer-counters.

With the moon pin you can actually set two levels of moon. One high level using the pin pulled up hard (20 mA or more) via an external resistor to set a reasonable current, the other value using the internal MCU pullup resistor, plus anything external. This has been demonstrated and worked.

Except it seems better to pull the pins down, rather than up, to match the way that the main current to the LED is usually arranged. Never tried it myself.

Then there is the FET to deal with, which still seems to be expected.

zeroflow
Offline
Last seen: 2 weeks 3 days ago
Joined: 05/23/2017 - 02:15
Posts: 189
Location: Austria

The linear fashion was sorta the reason why I went with 1+2+5+M. This way I can have 1x7135 after connecting power, 2x7135 as the ramp ceiling and 5x 7135 as a turbo mode.

 

Regarding the two levels, I think you mixed up aux leds and the main LED. Aux LEDs (connected to GND and the MCU) can have high (pin set to high) and "low" (pin set to pullup)

But the main LED is constantly connected to VBat and the GND side is switched/regulated. In that case, I can only have one moon mode set by the series resistor.

ToyKeeper
ToyKeeper's picture
Online
Last seen: 40 sec ago
Joined: 01/12/2013 - 14:40
Posts: 9996
Location: (469219) 2016 HO3

I agree about the 1+1+2+4+8+16 (etc) approach being overkill, and not incredibly useful. I think it’s a pretty slick method though, and wanted to mention it since what you have is so close.

I’m generally happy with FET+1 or FET+N+1, or more generally, putting power channels about an order of magnitude apart. I haven’t found it very useful to maximize the number of no-PWM levels. And on ramping designs, swapping channels around has a tendency to create mismatched joints in the ramp, so I try to avoid that.

Lexel
Lexel's picture
Offline
Last seen: 21 min 32 sec ago
Joined: 11/01/2016 - 08:00
Posts: 5478
Location: Germany

yeah just see I made the mistake not taking into account that the design program has vottom side mirrored
so the 10 pin connectors does not work 1:1, reverse 4 soldered leads should be no problem

atm in customs with C8F 21700, MF04S, prototype D1S, D4, D4S, MF01 aux LED boards

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 11 months 3 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 580

And yesterday is… today Big Smile

It’s really that good.

The picture shows a 4+4 key and the driver I was working on at the time I ordered the key. The DD+1 driver is 17mm and just there for size comparison.
The key-pcb is 10mm x 27mm, at the pogo-pins the pcb is only 5.6mm, that will fit about anywhere. When you only use 3×3, you can file the key even narrower.
Pcb width is 0.8mm. Pogo-pins are 0.68mm diameter, 16mm long. Via drills on the driver are 16mil (0.4064mm). Distances are 1.3mm between left and right vias and 1.5mm between up and down vias.

Just programmed a driver and it’s a hoot.

.

The size of the key is perfectly fine, can be put between thumb and middle finger with the index finger on top, gently pushing the springs of the pogo pins down. With 6 vias, aligning is of course a breeze.

Refined the key a bit, not much really. I’ll make at least two versions:
- A neutral one marked from A to H, where up to 4+4 can be used. With connectors any combination can be plugged on the fly
- A key marked with the pin numbers of the Attinys in my preferred layout

.

EDIT: I shared them here

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

Pages