[Oshpark] HQ ProgKey - Universal Driver Programming Key

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:

Awesome, hopefully you have lots of memory left over.

Are you planning on sticking with the 85 or do you want to transition to the 1634?

I like the idea of making an adapter board to convert one of the new mcu’s to the old 85 footprint. The new one series has a chip with 2M of memory and a lot of pins. Enough for a crystal to make timing accurate and for an external temperature sensor on the driver and/or mcpcb. Plus only three pins on the programming key.

Not sure how feasible it is but you and the hardware people would be set for a long time.

It also has virtually no support in the open-source toolchains, so I don’t have a way to build code for it or flash code after building. I can’t really consider it as a viable option until those issues are fixed. It’ll be pretty cool some day though.

For now, the tiny1634 provides plenty of room to grow. It has twice as much ROM as tiny85, and a bunch of extra pins. I’ve also started on tiny841 support, but I don’t have it working yet.

I’ve been compiling for the the 1-series chips using GCC, you just need to include Microchip’s “device family pack” files. Now, I haven’t flashed them from Linux yet… I really need to try that.

The 1-series chips have been pretty nice. While limited to 4KB, the attiny412 makes a great PIC replacement in existing lights due to it’s pinout. I just replaced the MCU in my Convoy H1 with one (with RampingIOS). I’ve done the same with the D25 headlamp. For new development (custom boards), I’ve been using the X16 (ie: 416, 816, 1616, and 3216) where I need a smaller footprint, more pins, or more flash.

If you come up with something cool though, I bought 25 of the 1634 right before I switched over to mostly 1-series dev. Hopefully they’ll get used someday, even if it’s not by me.

It sounds like we should coordinate to get FSM supported added for those too. Or perhaps I should get off my butt and take a close look at the work you’ve already done. This may just boil down to me being slow.

Do you know if the newer chips have support in avr-libc? If so, that would make a lot of things easier. If not, it’s definitely still doable, but it’ll need to abstract out potentially the entire C library. Or at least parts of it, and how it hooks into other files.

Also, I’m way behind on getting your code into the repository. Would it be okay for me to import everything at Index of /blf/firmware ?

I took a look at FSM a while ago, I should take a stab at it. I haven’t worked with finite state machines since college (about 12-15 years ago!) but it shouldn’t be terrible. Mostly just swapping out register names. Oh, and for timed tasks I’ve been using the RTC instead of WDT. But that’s about it.

I’m using avr-gcc but you need to bring in the Atmel Device Family Pack files. A sample build script is here (originally based on one of yours)

Yup, you can grab the stuff I’ve got up there if you’d like.

It’s not exactly the cleanest code. It’s a spaghetti monster, after all. And the published branches don’t have tiny1634 support yet, so they lack the changes I made to improve portability.

I’m still pondering how best to support lots of different hardware simultaneously, in a manner which is relatively clean. It could use a lot of refactoring… beyond what I did for tiny1634 support. But I’m not sure exactly how to structure it yet.

This is from a previous post by gchart. Adventures in TinyAVR 1-Series

The 3217 is cheaper and more future proof. I’d like to think that this latest generation chip would have better internal clocks and temperature sensors but I can’y find anything in the spec sheets to prove it.

No one spends more time programming and testing than you do. It doesn’t seem like it took a long time to outgrow the 13,25,45 and 85. This time you get to choose the new chip. Twice as much memory as a 1634 and a three pin programming key can’t be a bad combo.

I’ve written and flashed simple firmware for the 3217 for a specific project. I’ve got most of the stuff working: Internal temp sensor, ADC, PWM, pin interrupts, software reboot and RTC (instead of WDT). All I have left for full functionality support is OTSM with the low power consumption options to run the MCU from the cap. After that I just have to fix the definitions and I’ll be ready to go. Besides 3 pin flashing, the 1617/3217 interested me because it has a DAC. The choice between 1617 and 3217 was pretty easy, the 3217 only costs a few more cents than the 1617, no reason not to go with 32 kb.

That’s a really interesting feature. Have you found it to be stable enough to supply control voltage to other chips?

I haven’t started testing it yet. I have a 3217 driver that will be on it’s way from OSH Park shortly. I had some space over so I included a via for DAC output so I can play with it a little. Just got to get my 1634 firmware fully compatible with 3217 by defines first.