Thank you for the update. I feel like this is potentially groundbreaking and “next level” driver design. I really like it. just need to source the MCUs in small quantities somewhere.
Well, if we can get enough people wanting them, we might be able to talk Richard into carrying them at Mountain Electronics. That at least helps USA folks. 
Mike, are you sharing these boards on OshPark or planning to make them available through you?
+1. 
Thanks. I do have my eyes on the ATtiny1617 but I can’t get these easily, and more importantly I don’t have the tools to program them. I haven’t found any 1617 support for AVRDude, or even any info on anyone programing them with a normal USBASP.
I’ll come clean on this… I want to share them on OSH Park for anyone to order how they wish, but I do not want to share the project files. OSH Park have continuously told me that they are about to implement this, but they’ve been saying that for over a year. Personally I don’t understand why one should be able to download the project files just to order a board. It’s not even good business for them, one can just download the project files for any project and order from somewhere else. If I want to share the source files I’ll do it somewhere else, like here. Currently there is no way to share a board for ordering without sharing the project files, and I think that’s stupid.
You can always run the OSH CAM job in Eagle, ZIP up the resulting Gerber/Excellon files and upload that to OSH instead of the .brd file. Not much anyone can do with the Gerbers that they cannot with regular images/photos of the board.
Yes, that’s definitely possible.
I use the CAM job. Too me it’s irrelevant. I don’t understand why my files should automatically be available for download just because I want others to be able to order boards.
Anyhow, despite this I have shared before and will probably do so again if OSH Park don’t want to have an option for disabling download.
Well, as far as I’m concerned, you have a right to your files, whether you choose to share them or keep them private. As you said, it doesn’t even make sense for Oshpark to share them, since someone could easily download those files that Oshpark is hosting freely, and use them to buy boards from another fabricator.
I don’t think OSH Park cares if someone goes to other fabricators. What they care about is in their name — Open Source Hardware. It’s not called Closed Source Hardware Park.
If I understand correctly, he’s less interested in profit or mass-production and more interested in building a collaborative ecosystem, so he has reasons to strongly encourage people to share their designs in ways which can be modified by others.
I can *ahem* kind of relate.
O pen S ource H ardware… That figures, I didn’t know that. In any case I think that OSH Park also is a business, not just a community, and catering for those that do not wish to share their files will not harm those that do in any way. Having the choice is better than enforcing strongly encouraging, and as it’s in the pipeline they seem to think so too. Their latest response was “soon”, but they don’t say weather “soon” is days, weeks, months or years.
Too be honest, I would be open to alternatives to OSH Park if there are those where one can share projects without source files, but OSH Park have so darn good customer service that I’d rather not.
Update.
I was unable to add all the features I wanted in my full feature firmware with 8kb flash space so I decided to ditch the ATtiny841 and go with a 16kb MCU. I know others have seen in their crystal ball that the 1617 is the future, but it’s too far into the future as there is no 1617 support in AVRDude and I don’t want to buy an Atmel ICE. If I do switch MCU in the future I would personally go for the 1616 with it’s a smaller package.
Some downsides to the 1634 vs 841 is 256kb EEPROM instead of 512kb, and the PWM pins are fixed (841 has flexible PWM pin assignment). However, the 16kb flash more than makes up for it. The 1634 uses all pins too, so there are more IOs. The 841 has some useless “no connect” pins, so now I have more pins to play with without changing package footprint. It also draws a little less power in sleep mode as I can consistently get over 15 seconds of measurable OTSM offtime with a 47uF cap vs 12 seconds with the 841. So E-switch only lights will have at least as low parasitic drain as the 841’s 0.1uF.
The first board with the 1634, my F-2:
I discovered a while back that VCC is not needed for flashing at all so that frees up a little more space as I only need 5 vias for flashing instead of 6. It probably has never been needed, but I’ve only verified it on the 841 and 1634. I’m not done with “porting” my 841 firmware to the 1634 yet, but once I’m up to speed I can share something if there is any interest.
Also, I have KiCad which is open source PCB design software with multi layer support. 4 layer boards cost more at OSH Park but the additional layers sure can make things a little easier on some designs.
That’s a fantastic update! So, the only “user-side” changes to your driver with the 1634 are the larger code space, so you can fit all of your desired features in, and the removal of the VCC flashing via, which you discovered wasn’t needed. Is that right? Will you be making a list of features once it is ready? Also, are you going to make these driver boards available for sale?
very nice. Until I joined BLF I thought all a flashlight could do was switch on a LED. this is really great.
In the case of these “normal” flashlight drivers, yes. I will be using the additional pins in my headlamp projects with two E-switches, FET and separate 7135/A705 banks for each LED. For “normal” lights I don’t really need the extra pins, but as the pins are there either way I’d rather have the option to be able to use them instead of the 841’s useless non connected pins which just waste space (six of them).
Yes. It was only a few hours ago I got the necessary features working in order to approve it as a replacement for my drivers. Once again the plan is to release a sort of basic firmware that supports off switch, dual switch and E-switch only. I didn’t get around to it on the 841 because hitting the 8kb limit put me off continuing.
Yes. I’ll start with one or two of the two layer boards with fairly basic firmware to see if there is any real interest. Then with the additional 8K I could even give that flashing by phone a go, at least if someone can make the phone/computer app part. I ain’t gonna spend any time learning how to do that stuff, I’ve got enough to do as it is.
Thanks Mike. I just downloaded the datasheet for the 1634. It has two PWM timers, and one of them is 16 bit! Do you think that will ever be useful for possibly more fine-tuned modes, ramping, or something else?
I don’t know yet but I’m going to find out as I’ve used one of the 16 bit PWM pins for one of the LEDs in my dual LED headlamp project. For these “normal” lights I didn’t dare as I don’t need to fine tine low/moon modes to that degree so I played it safe, but we’ll see. I’ve also designed a development breakout board with vias for every pin to ease testing new things. I put a bunch of extra stuff on it like LDOs, voltage dividers, digital pots, several caps and so on, and everything is connected by vias only so pin changing is a matter of moving a wire. I’m fed up with mucking about modding existing drivers for tests like this.
Awesome! I’ll be watching here. :nerd_face:
Updated OP with two shared projects (F-2 and F-4) and some info.
I’m interested in a fully built F-4 if you get around to selling them. I’ve always admired your PWM-less mode steps, accomplished by using multiple output channels. The way I remember it, you were the true father of multi-channel drivers on BLF.