[Oshpark] HQ ProgKey - Universal Driver Programming Key

118 posts / 0 new
Last post
Mike C
Mike C's picture
Online
Last seen: 10 min 26 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2343
Location: Sweden

staticx57 wrote:
I am not sure how this helps.

It doesn’t help. Never intended to help. Lexel calls it a big mistake. It isn’t. That’s all I’m saying.
Lexel
Lexel's picture
Offline
Last seen: 4 hours 34 min ago
Joined: 11/01/2016 - 08:00
Posts: 5357
Location: Germany
staticx57 wrote:
Mike C wrote:
Lexel wrote:
This is just a big mistake
No, it’s not a big mistake. $4 and change, please, who cares. I wouldn’t commit to a standard for my boards either, I do as I please just as HarleyQuin.

I am not sure how this helps.

How about this, we agree on one design for commercial products. Having a bunch of different designs out in the wild is annoying.

I can understand that flashing drivers is not for the newbie, having limitless designs defeats the purpose of a programming key making flashing more accessible.

excactly this, who wants on different drivers of one designer like Harlekin, Mike C, DEL others and me to have 4 or 5 different keys in the box and even to have to arrange the key every time with different pinout connections on Harlekins “universal key”, because he wants to avoid using a bit time to route around a standard pattern when he does his drivers

the key is to use one uniform layout and pinout, change pinout on different drivers just to do less routing or component shifting if you do mostly use for youtrself is OK
but if you put those designs online and others make more or you also make them for sale makes no sense for pther people only you gained some time and feel comfortable re arranging pinout on your key

If i have any of my or BLF lights with the “standard” programming port I want to grab the key out of the box without thinking if the pinout fits or have to be changed, just plug and flash as simple as that

having more poeople make their universal key and on different drivers different pinout just kills the thing of one uniform programming port

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

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.

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

WTF
Offline
Last seen: 6 hours 22 min ago
Joined: 03/05/2017 - 20:13
Posts: 258

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.

Joshk
Joshk's picture
Offline
Last seen: 5 hours 15 min ago
Joined: 09/09/2015 - 12:12
Posts: 1527
Location: USA

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.

Mike C
Mike C's picture
Online
Last seen: 10 min 26 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2343
Location: Sweden

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.

WTF wrote:
The next mcu will probably be a QFN package.

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?
Lexel
Lexel's picture
Offline
Last seen: 4 hours 34 min ago
Joined: 11/01/2016 - 08:00
Posts: 5357
Location: Germany

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

Cereal_killer
Cereal_killer's picture
Offline
Last seen: 2 hours 34 min ago
Joined: 07/22/2013 - 13:10
Posts: 3871
Location: Ohio

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

 RIP  SPC Joey Riley, KIA 11/24/14. Now I am become death, the destroyer of worlds.

Lexel
Lexel's picture
Offline
Last seen: 4 hours 34 min ago
Joined: 11/01/2016 - 08:00
Posts: 5357
Location: Germany
Cereal_killer wrote:
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

Joshk
Joshk's picture
Offline
Last seen: 5 hours 15 min ago
Joined: 09/09/2015 - 12:12
Posts: 1527
Location: USA
Mike C wrote:
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.

Clever Thumbs Up

Cereal_killer
Cereal_killer's picture
Offline
Last seen: 2 hours 34 min ago
Joined: 07/22/2013 - 13:10
Posts: 3871
Location: Ohio
Lexel wrote:
Cereal_killer wrote:
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

!{width:50%}https://i.imgur.com/8IMylIv.jpg!

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

 RIP  SPC Joey Riley, KIA 11/24/14. Now I am become death, the destroyer of worlds.

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

Lexel wrote:
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

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

http://budgetlightforum.com/node/61509

http://budgetlightforum.com/node/61509?page=3

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 …

Mike C
Mike C's picture
Online
Last seen: 10 min 26 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2343
Location: Sweden

Tom Tom wrote:
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.
Joshk
Joshk's picture
Offline
Last seen: 5 hours 15 min ago
Joined: 09/09/2015 - 12:12
Posts: 1527
Location: USA

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.

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

Mike C wrote:
So maybe I’ll try 0.55mm vias so they can go through every time. I agree that if you just want to flash a driver then holding is the easiest solution but I do too much flashing, testing, development and flashing again for that to be reasonable. I wanna stick’em in one by one and leave them there until I’m done.
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.

.

Cereal_killer wrote:
Are there any eagle parts of pad/pin layouts available for any key design?
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.

.

Lexel wrote:
… 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
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.

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

Tom Tom
Offline
Last seen: 6 months 3 weeks ago
Joined: 09/10/2017 - 08:30
Posts: 1163
Mike C wrote:
Tom Tom wrote:
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.

Sorry, it was Flashy Mike I was thinking of Facepalm

WTF
Offline
Last seen: 6 hours 22 min ago
Joined: 03/05/2017 - 20:13
Posts: 258

Mike C wrote:
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?

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.

Mike C
Mike C's picture
Online
Last seen: 10 min 26 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2343
Location: Sweden

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.

Lexel
Lexel's picture
Offline
Last seen: 4 hours 34 min ago
Joined: 11/01/2016 - 08:00
Posts: 5357
Location: Germany

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

Mike C
Mike C's picture
Online
Last seen: 10 min 26 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2343
Location: Sweden

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 Smile

WTF
Offline
Last seen: 6 hours 22 min ago
Joined: 03/05/2017 - 20:13
Posts: 258

Mike C wrote:
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.

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.

Mike C
Mike C's picture
Online
Last seen: 10 min 26 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2343
Location: Sweden

WTF wrote:
Porting any of the firmwares popular here to a diffferent mcu family requires a lot of rewriting.

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…

WTF wrote:
And the QFN pinouts keep changing, so every time a new mcu family is used it requires a new driver.

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.

WTF wrote:
What comes after the 1634 if it is outgrown or obsoleted?

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 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.

zeroflow
Offline
Last seen: 5 days 1 hour ago
Joined: 05/23/2017 - 02:15
Posts: 189
Location: Austria

Lexel wrote:
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

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 23 min ago
Joined: 01/12/2013 - 14:40
Posts: 9957
Location: (469219) 2016 HO3

For drivers with enough room, another option is to use a 6×1 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. Smile

WTF
Offline
Last seen: 6 hours 22 min ago
Joined: 03/05/2017 - 20:13
Posts: 258

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

http://budgetlightforum.com/node/66272

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 23 min ago
Joined: 01/12/2013 - 14:40
Posts: 9957
Location: (469219) 2016 HO3
WTF wrote:
I attempted porting Anduril to a 1634 once.

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.

gchart
gchart's picture
Offline
Last seen: 6 hours 48 min ago
Joined: 03/19/2016 - 11:57
Posts: 1678
Location: Central IL

ToyKeeper wrote:
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.
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 23 min ago
Joined: 01/12/2013 - 14:40
Posts: 9957
Location: (469219) 2016 HO3

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

I should have the code published sometime soon.

MRsDNF
MRsDNF's picture
Offline
Last seen: 1 hour 58 min ago
Joined: 12/22/2011 - 21:18
Posts: 12967
Location: A light beam away from the missus in the land of Aus.

Nice work HQ and TK. Thumbs Up

 

djozz quotes, "it came with chinese lettering that is chinese to me".

                      "My man mousehole needs one too"

old4570 said "I'm not an expert , so don't suffer from any such technical restrictions".

Old-Lumens. Highly admired and cherished member of Budget Light Forum. 11.5.2011 - 20.12.16. RIP.

 

WTF
Offline
Last seen: 6 hours 22 min ago
Joined: 03/05/2017 - 20:13
Posts: 258

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

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.

Pages