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.
Cool. I’ve got new ones from OSH Park on the way, I’ll have a few to spare so I’ll make one for you. I’ll ask about what UI, modes, volt levels and so on once it’s built.
I don’t remember who it was that had the original idea to do it with 7135s. It was some guy using a PIC MCU instead of AVR, and maybe had a USB cable interface directly on the driver (maybe mixing up projects here). Anyhow, I wasn’t first and it sure wasn’t my idea… but I liked it 
Edit: I found it… the project didn’t see completion, at least here at BLF: The World's Most Advanced AMC7135 * 8 Driver
Oh yeah. I’m subscribed to that thread! But I forgot about him, to be honest.
I’ve fully converted my 841 firmware to the 1634. However, the 841 firmware wasn’t fully completed but it’s good enough to go. Still interested? If so I have a few questions for you:
Currently only 1S configuration supported. Is that what you had in mind? I haven’t gotten around to 2S yet, it requires some firmware changes that I won’t be doing before I go on two months vacation in September.
Do you want it configured for E-switch, Off-switch or dual switch? Can be changed in config menu, but to do the change the driver has to be in a light that supports current switch config before installing in the new light.
What UI? Currently I have three UIs:
1: “Traditional” UI with up to 4 modes. Short press up, long press down. If UI1, how many modes do you want?
2: UI with two modes. Short press cycles between them, long press enables ramping for current mode (Short press brighter, long press dimmer). 2 seconds of inactivity saves new mode level, blinks and returns to normal.
3: Constant ramping mode. Short press brighter, long press dimmer. I use this as “campsite” mode so that no accidental single press can flash full boost in someone’s face.
Voltage monitoring on or off? When on, critical voltage level can either warn or turn off and put light in sleep mode. If on, what levels?
Temperature monitoring on or off? When on, critical temperature can either warn or turn off and put light in sleep mode. Critical level is about 5 degrees Celsius higher than configurable high temp. Default high temp is set to 70 degrees Celsius. How hot this actually is depends on host as MCU is measuring the temp, and MCU placement and thermal isolation will impact.
I have 4 user modes (higher user mode includes all lower user mode functionality):
1 - Normal: Can’t do any read outs, functions or configuration changes except change the user mode (requires a timed sequence of 10 presses).
2 - Advanced: Voltage and temperature readouts, can change UIs, mode settings and boost timers.
3 - Expert: Able to configure voltage and temperature monitoring settings and levels.
4 - Engineer: Calibrations. Your driver will be calibrated, so you shouldn’t need to calibrate unless you want to play around with it.
Do you use any blinkies? I have a simple strobe, beacon and SOS. Not fully implemented though.
Finally, do you flash drivers yourself? If so I can send you the driver earlier and later send you hex files for updated firmware.
OK. I’ve been really busy at work lately. I’ll try to get answers to your questions soon.
OKAY. I have some answers for you now…
- 1S operation? Yes - 1S only
- E-switch, Power cycle, or Dual switch? Power cycle switching
- Which UI? Traditional, with 4 modes. First mode 1 lumen - possible?
- Voltage Monitoring? Yes - 2.8V warn only
- Temp Monitoring? Yes - Sleep at Critical temp
- User Mode? 3 - Expert
- Blinkies? No thanks
- Do I flash drivers? Not currently, but I hope to some day
Thanks. First mode 1 lumen is a little bit unsure as I don’t actually know what 1 lumen looks like. Is that just enough to find your keys and unlock a door?
I forgot to mention that with voltage monitoring I have both low and critical levels. Low voltage disengages boost/turbo, otherwise by default it doesn’t step down (only blinks a warning). Critical (if not set to sleep) steps down to the highest mode under a set limit, which is 1 x 7135 full on (at 2.8V the LED won’t shine any brighter anyway). The 2.8V you specified, as that low or critical? If critical, what do you want low at (or vice versa).