[Oshpark] HQ ProgKey - Universal Driver Programming Key

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.

The low-level hardware interfaces usually seem to me like the hardest part of making firmware. Each chip has its own particular way of setting registers to configure it in a useful manner. Once the hardware is configured though, I like building the upper layers of the code.

That’s why it takes me so long to add support for new MCUs in my UI toolkit. Most of that work is about the low-level interfaces, and I’m more of an application developer at heart… not as much of a hardware enablement developer.

I should probably rewrite the entire hardware abstraction API. What I have now is completely ad-hoc and not particularly coherent. But until I’ve added a few more chips, I don’t know how best to organize it. Attiny1634 was relatively easy compared to something like tiny3217 or a PIC chip, because it wasn’t much different than tiny85.

If you can help isolate the hardware-level stuff, I’d be glad to try and help with the porting to 1-series.

I’ve never looked at PIC but I probably should sometime as it seems that many non-BLF flashlight drivers use PIC. But it has been handy that the X12 AVR’s use a PIC layout (thinking retrofit here).

Tterev has done some beginners guides to pic’s, I think Toykeeper has stashed some of his work on the repository.

I think an adapter board would be the easiest way to tackle pic’s. Wight made one for the eight pin chips although I don’t think anyone ever finished the project.

Here’s something unrelated that may interest Toykeeper, hopefully the arduino code doesn’t make her eyes hurt. gxb172-attiny841/GXB172ATtiny841_V1p0_WIP.ino at master · loneoceans/gxb172-attiny841 · GitHub

I’m very glad to learn about the port to attiny1634. :slight_smile:
The smaller size coupled with larger capabilities is good. :slight_smile:
So is the slightly lower price. :slight_smile:

Well… I dunno exactly when I’ll get around to porting the code, but I made a development board for the attiny816 (or 1616 / 3216). Basically the same at the 817 except it’s 20 pin instead of 24; I don’t plan on need 24 pins anytime soon. Instead of running through regulators or FETs, I’m just using the MCU output to run the LED (limited with resistors). Since this is just for testing, I don’t need it bright… actually, bright is bad because I’d just be blinding myself. :sunglasses:

Andúril and NarsilM, here we come!

PS… sorry for the threadjacking

gchart, I’m not knocking you for threadjacking, because I’m just glad to see this development come to light. :sunglasses: But this is very big news. It actually does deserve its own thread, if you can find the time. :smiley:

I just cross-posted in my AVR Series-1 thread. I’ll try to continue posting updates over there. I just ordered the boards today, so it’ll be a little bit before they’re fully assembled. I guess I could start pulling code down and converting in the meantime… (like I really needed another thing to do :person_facepalming: )

That’s what FSM does. There’s a hardware interface on the back end, plus a UI toolkit on the front end. That way, the UI code is portable and doesn’t have to care (much) about the hardware it runs on.

However, it’s not exactly the cleanest code. It’s a spaghetti monster. It doesn’t do a great job of isolating the hardware-level parts from the library logic, so that gets kinda mixed in sometimes and could use cleaner abstractions. There’s probably a lot of stuff which doesn’t really make sense, but needs a fresh pair of eyes to notice the mess.

Thanks. I’ve been meaning to check on that project again, but I get distracted easily by other shiny things. It’s great to see that the code is available now, and published under GPLv3. There’s nothing wrong with arduino code though… I even used a couple arduino-isms while designing FSM’s interface. Anyway, it looks like loneoceans made things pretty clean.

That was just a lame attempt at making you smile, I didn’t mean to infer anything negative.

Lone Oceans is so damn smart. The I2c temp sensor code looks so clean, although a lot of code could be hidden in a library.

You should check out his website if you haven’t already, he really likes his Tesla coils.

I really like the flexibility of HQ’s programming key. There’s no reason you couldn’t adapt nearly any PCB design to use it (or some variation of it). I picked up 6ea from oshpark and can’t wait to try my hand at designing my own driver boards with integrated programming ports.

Thanks for open sourcing the design. I’ll probably try using kicad, so I’ll see if I can release some definitions for the footprint.

Are you already a user of KiCAD? I’d like to learn it, but the learning curve is steep for me. There is an Eagle tutorial around here from years ago, which helped a lot of us get started in PCB design. If you know how to use KiCAD, it would be helpful to at least some of us if you could help out with a quick-start tutorial of sorts. :innocent:

Never used kicad, I’ve used eagle a bit in the past. This is mainly a good excuse and project for me to get back into embedded electronics. I’ve been meaning to learn kicad for a while (not a huge fan of eagle since auto CAD bought them). I’ll definitely try to document my descent into the abyss!

Yeah, since AutoCAD bought Eagle, it has gone to junk. That’s why I’d like to learn KiCAD now. But it just isn’t very intuitive to me. :weary:

I still use diptrace for PCB design and find it does everything I need.

Hmm, I might have to check out diptrace. Heard of it, never tried it. I’ve been using eagle.

I tried eagle at first but did not like it and found diptrace to be better personally.

Can I buy a ready assembled key with pogo pins attached?

Can someone tell me what this part is called:

Alternatively if there is another inexpensive part that allows me to go from the key to the USB ASP let me know. I have small gauge wires and extra jumper wires but nothing else.