[Oshpark] HQ ProgKey - Universal Driver Programming Key

I’m with you, Lexel. While I wouldn’t mind having a couple of ‘standards’ to cover the likelihood of some truly unique driver designs, I wouldn’t want to get into the confusing world of just not having any standards at all, and having to get a new programming key every time somebody makes a new driver board. I haven’t started flashing drivers yet myself, and when I do decide to start, I’d like to be able to buy one limited set of equipment and then get right to it. That’s how it was with the ATtiny13A chips, using the SOIC clip. Once it was figured out how to do it, lots of people were able to get on board. Since drivers are becoming more complex, and using different chips, the ‘Universal’ key could be a great help in keeping it simple for people.

And what about when somebody gets a driver board second hand (maybe already installed in a flashlight they bought), and has to try to figure out which ‘key’ was needed to re-program it? I know we’re in the early days of programming keys. Just like with any ‘new technology’ there will be competing ideas about the best way to make it work for the most people. Eventually, people will either end up standardizing themselves, or decide it isn’t worth the hassle. But, some of us would like it better if we could start the journey with trying to standardize, instead of just saying it doesn’t really matter, and letting it become a big mess.

Has anyone seen Del lately? Does anyone wonder why he left?

HQ has done nothing wrong here. He doesn’t have to share his stuff. He does everyone a nicety and gets crap for it in his own thread.

If you want to use one of his designs and don’t want to use his key you are free to use the standard programming clip. Pogo pins come in bags of 100 and boards are cheap, I don’t see the problem here. If it says HQ on the driver you use the key with HQ on it. How many people plan on building one of his boards anyway?

Texas Ace designed the drivers most popular here. If he updates them to use a programming key that key will become the standard. And that standard likely won’t last long. The ATtiny 85 is hindering firmware and driver development, its running out of memory and I/O pins. The next mcu will probably be a QFN package and the programming key will likely change again to make routing traces easier.

HQ’s universal design is great and will fit any driver with enough space for this feature. I don’t give a crap that it only cost’s $4 per alternative, let’s be open minded about a single standard. If you can’t fit HQ’s universal pads on your driver, try harder or leave the feature out. This goes for HQ too.

The great thing about through hole vias is that you don’t need any key at all, and they can be in any position on the driver.


I get it though, keys are probably fantastic if you have a large batch to flash or are in a real hurry. But I don’t, and I’m in no hurry.

I’m surprised others haven’t switched yet. I’ve been using the ATtiny 1634 QFN for a long time now, it did not take long to convert. It has better power options for low parasitic drain for E-switch lights and off time capabilities for clicky switch lights. And it’s cheaper than the 85 too, at least where I get them (Mouser, Europe). People where chatting about using the 1616 and 1617 quite some time ago, what happened?

I guess with prog key I also will slowly migrate to qfn20 MCUs


the customer for the 10.25mm driver wants to use a flexible PCB key that gets glued to a sort of 3D printed part following the shape of the prog pads(in this case a circle),
so he can arrange the viases on the driver as he likes and make custom keys in any form and pin orientation

Are there any eagle parts of pad/pin layouts available for any key design?

not using Eagle
I use Diptrace

but generally just activate snap to grid, then 1.3mm and other axis 1.5mm and place the vises/pads onto it

Clever :+1:

Thanks, I’ll make an eagle part next time I get some hobby computer time

I think, if I remember correctly, when I introduced parts of this idea a while ago, that I suggested putting the pins into a 3-D printed housing.

Based on the original suggestion by TK, that was implemented in the D4S

I was thinking square format, 1.27mm spacing. But anything else is possible with this approach.

Mike C seems to be pretty nifty with 3D printing …

I think you mixed me up with someone else. I’ve never done anything related to 3D printing.

I’ve done a lot of 3D printing. I can say it would work well for the person designing and testing it. But at this tiny of a scale, every printer is going to give a different fit.

Yes, you might need some margin. I tried it on some more boards with 0.5mm vias and the result is not consistent. On one board the pins do not fit a single via (definitely 0.5mm vias in the brd, I rechecked) and on another board they go through all 0.5mm vias and only get stuck when there’s soldermask on the other side.

.

I have made an Eagle part, but only with the position of the 8 vias, to be able to use it in non-90-degree angles. I prefer to place the vias manually on a 0.1mm grid in the particular driver and extend the restring of the via as much as deemed fit.

.

Which is exactly the point I’m talking about and the reason for my more universal approach for a key. But of course, your mileage may vary.

Again, my main goal at the moment is to get as much vias per driver as possible, to get good contact while programming. One of my first boards where I tried this out, it had 3 vias and 3 pads. Might be me gettin’ old, but boy, I liked the version with 6 vias so much better.

I don’t mind having several keys here. Oshpark boards come in batches of 3 anyway (it’s $4 and change for 3 keys…).

As I see it now, it will come down to only 2 major versions on my desk anyway (the both 4+2), which I will each hardwire/solder to a 10pin plug. So it’s an easy change at the USBASP programmer.

Sorry, it was Flashy Mike I was thinking of :person_facepalming:

That actually looks pretty fast from a cook it, flash it, test it standpoint. Both Lexel and Harley only have six pins on the programming key. Two more and they could connect one key to the programmer and a separate key to a breadboard with a switch and some 5mm led’s. A large portion of the driver could be tested without touching a meter or a soldering iron. It would be a huge time saver for someone that handles a lot of boards in a year.

The last time I checked programming a 1616 was still expensive. There was talk of programming it with an arduino but I don’t know how much progress was made. There will likely need to be a bunch of program changes needed to run the new mcu. Without any hardware to test with and without Tom around it would be a huge burden on Toykeeper to figure out and test everything. Its hard to say if moving to the 1634 is even worthwhile, maybe a small cortex or a pic is the way to go. There has to be a better architecture than what the ATtiny uses.

I have a dedicated diagnostics firmware that tests everything, each test separated by a click. It’s the first thing I do after making a driver.
For sure there are better architectures than the ATtiny and better options than the 1634. I just went with it so I wouldn’t have to learn a new architecture and a new flashing environment.

Do you want the best architecture out there and are willing to put in the time and effort to learn new architecture and flashing environment? Then no, moving to the 1634 isn’t worth it.
Do you Want 16kb flash, 18 IOs and better power saving options with minimal time spent porting current BLF shared firmware? Then I don’t know of a better option than the 1634.

Attiny 84 would be also an option in qfn package, at least more IO pins

Personally I don’t see any advantage with 84 QFN over 1634. Well, it’s 0.15€ cheaper, but if you are going through the trouble to make QFN-20 drivers, why not use the 1634. Same footprint, but 6 more IOs and double flash space. If 0.15€ matters, then by all means go for the 84. If not, there is no reason what so ever. I’ve worked with the 84, some registers are different than the 85 so you still have to do firmware porting.

I didn’t think I’d be using many IOs either, but now I have a 17mm driver than uses 16 of those 18 IOs, and I’m also designing a specific headlamp driver that will use all 18 of them :slight_smile:

I’m trying to use a 1634 as well, it does everything I’ll need it to do. I attempted porting Anduril to a 1634 once. That hurt, I’m not ready for stuff like that. Trying to learn C and work through the datasheets frustrates me and I keep thinking there has to be a better way to do things.

What really bothers me is a lack of continuity between different ATtiny families. Porting any of the firmwares popular here to a diffferent mcu family requires a lot of rewriting. And the QFN pinouts keep changing, so every time a new mcu family is used it requires a new driver. Not a big deal for me, may not affect you much either. The problem is Toykeeper will keep coming up with great ideas and others will always ask for something else as drivers evolve.

What comes after the 1634 if it is outgrown or obsoleted? Is it less strain on some key people here to skip the 1634 and put that energy into the next mcu? It would be great if that mcu was easier to work with and had a better upgrade path.

I’ve only ported my own so I guess I’ll have to back off a little. For me it was no strain, took a day or so and it was done. I wouldn’t have thought it would be an issue for other firmwares but I haven’t looked at any other for a long time. Porting or re-writing your own firmware is so much easier than doing it to someone else’s. Or maybe it’s because I’m used to it, I went from the 13A to 85 to 84 to 841 to 1634. I’ve offered assistance on the 1634 before, no one took me up on the offer so I assumed people where working on other MCUs, like 1616, 1617 or PIC. Maybe they still are…

New drivers are coming out all the time anyway. How many different 85 drivers are there now? I see new versions coming all the time. Pin swaps aren’t an issue for any driver designer, it certainly isn’t for me.

Yeah, that’s a good point, definitely a reason I didn’t think about and a strong argument against the 1634. Who knows how long the 1634 will be available? I’m not concerned though, holding of development in wait of something better is not my cup of tea. I needed more memory and IOs so I took the best option available to me at the time with the least amount of environmental changes. The switch wasn’t much of a strain. As for availability, it isn’t an issue for me. Any time I order from Mouser and need to add components to get free shipping I add a bunch of 1634s to fill out the order. I’ve got enough to last me quite some time :slight_smile:

I do have another argument against the 1634. One thing I miss that the 841 has is the ability to select your own PWM pins. They are fixed on the 1634. With the 841 you set up the PWM “generator” and then choose any available IO to assign it to. You can’t have more PWM pins at the same time, but the flexibility to choose any IO is something I do miss. If I ever move on from the 1634 it will be to an MCU with that same feature.