[Oshpark] HQ ProgKey - Universal Driver Programming Key

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.

Why not just make a 2nd PCB where you have plated holes in the correct size for pogo pins and a connector. In the worst case, you can take two of those PCBs stack them and have a very rigid stack for an programming adapter.

Otherwise: please publish the exact spacing if you don’t use your standard key, because making a 3D-printed adapter is easier with a known spacing.

Also, if possible please connect the + pad to the VCC net after the diode and not to the battery connection.
That way, the main LEDs are not supplied when flashing. I had some problems with the D4S where the process of flashing would pull too much current from the USB port.

For drivers with enough room, another option is to use a 6x1 1.27mm pad layout, since adapters for those can be purchased pre-made. This covers pretty much all the other reasonably compact layouts though, and should be pretty universal as long as the pads are kept together in a tight formation. :slight_smile:

Gchart has had some success with the new one series mcu’s (ported ramping ios). They only need three pins.

That’s what I’m doing next, actually. I just need to get a programming key built so I can actually flash the MCU. And, of course, do all the porting work. But 1634 has pretty decent support in avr-libc, so I don’t think there will be as much trouble there as trying to get newer MCUs to work.

Most of the difficulty will probably come from removing assumptions built into my code, making it amenable to different MCU architectures. The 2nd arch is generally the hardest to add… 1st is easy since everything can be hardcoded. 2nd is hard because everything was hardcoded the first time. Then the 3rd and later should be easier since the 2nd did most of the hard parts.

Preach it, sister! If/when you get over the “2nd chip” hurdle, I’d be up for trying to port it to the new 1-Series. Since ya know… you’ve done most of the hard work in abstracting some of the architecture. Oh, to have HAL-like stuff done and all kept within tk-attiny.h… what would make things a breeze.

Oh, um, I forgot to post about it before, but… I have tiny1634 working, thanks to a HQ adapter. Dingwat sent me a couple. :slight_smile:

I should have the code published sometime soon.

Nice work HQ and TK. :+1: