Yes - 5 volts. Though after several attempts, I did try 3.3v but nothing worked.
Ohh - I'm using my latest eswitch.c. I could post it somewhere for you - I'm @work now though, another 10 hrs or so. You probably have an older version of mine.
How did this thread get so into PWM hums? It's got me hearing all the hums and buzz's here @work coming from all types of equipment 
.
I used a qlite with two extra 7135s and guppydrv. The noise was clearly being emitted near the head where the driver is. I held it up to the mic on the smartphone. The peak was very visable on the app i used. There might have been more peaks higher up in the range that i wasnt able to measure due to the limitations of the smart phone. And i have to say i have never heard of the photoacoustic effect. Thats pretty neat.
As for how we got here i believe it went: what core freq to run, then 6 mhz because that allows you to get 19khz pwm to keep it inaudable and then to 19khz or not we call can hear it. And i really have nothing to add to this thread other then all the fuse setting was why I was thinking of going arduino on a tiny 85.
^ You've already contributed much value to the thread. I'm not going to pretend I understand everything you, led4power, RMM, and ToyKeeper (alphabetical order) are saying, but the hum issue is one of the vexing challenges that we have to deal with in this hobby. So any discussion that may deepen our understanding is all good.
Tom E,
Much appreciated. I will PM my email address to you. I don't have much in programming skills, but I will do my best to read the data sheet and look at the alternate pwm feed portions.
I should note that I don't recall where I read that one pwm channel is for fast and the other for phase. I skimmed the data sheet and didn't see anything like that. So maybe what I read was not correct or I misunderstood it.
Well think about all of the constant current pwmless drivers out there with a pic controling a mosfet. They are all silent but i suspect its because they are running pwm in the mhz range so that by the time all of the harmonics filter down they have no energy left to be heard. I could be wrong but i highly doubt the are changing the enhancement on the gate to vary the current flow. Which wouldnt make sense because the inductor relies upon expanding and colapsing magnetic fields to generate the current and voltage levels so i would think it needs to be an on off afair. I think the real leap in blf driver design will come when we can figure out how to use the micro as constant current switch mode controller.
It seems like pics are exclusively used for this but i dont see why we couldnt do it with an attiny.
We need a PWM-less thread to discuss getting these MCU's working 
.
Well current progress:
.Wish I could get a better handle on exactly how these MCU's differ from the 13A. Thought there was some differences in clocks, ports, etc., just cant' find it.
Update: Ok, I got LVP working now as well. Looked at the ADC support, and with the added features in this area (temp sensor, etc.), setting the 1.1v reference is now a different bit in the ADMUX register. I had a weak cell at about 2.7v, and sure enough, the firmware backed down output in steps til output dropped altogether - just what it supposed to do!
Now, still got dual channel support to figure out, with the PB0, pin #5 7135 output.
Great work Tom! I'm planning on working on this some more early next week. Want to get that temperature sensor going.
Hhmm. It all seems to be working now. Even the Phase Correction on 7135. All tests seem to be correct - amps indicate is truly working off the 7135 in the 1st 3 modes. Dunno what was wrong before - didn't "fix" anything, I don't think... Weird, but this is really nice!! Now I can do some serious programming with a whole nother 1K bytes (Tiny25) of code space !
Yes - the temp sensor would be huge as well, for sure.
Update: ZIP files of project/source code and BAT files are shared here: drive.google.com-244585. Hope this link works. You may have to sign in to Google in order to download, not sure...
This is for a wight style FET+1 driver with default 5 modes, first 3 on the 7135. It has a turbo timeout set to two minutes. I've only tested it on a ATTiny45 which should be running at 8 Mhz. It's not taking advantage of the 45's extended capabilities yet: temp sensor, extended available memory, etc.
Way to go Tom. You are the man! I finally got a 22mm board working and tested the UI of the FW you sent me earlier today. Same results as you reported. It worked great except for the Alt PWM channel. I started examining the code and came back to report and call it a night. My gosh, you got a lot done tonight.
Tom E just opened up the hobby to a whole new level!
EDIT: Status in OP updated.
Wow, guys, this is awesome! What I’d like to see is a guppydrv style mode group selection but using more advanced mode groups like we have on the BLF-A6 FW.
Funny, I was think'n the same exact thing - guppy style mode group availability w/advanced mode nav, w/all the bells and whistles of LVP, OFF time detection using a cap or brownout detection, temp sensing based output limiting, full e-switch and/or power switch support. And, of course, it should all be done in one firmware version.
This opens the door to a whole lot more versatility.
My first step (for me) is to get back to adding full power switch support w/OFF time detection to the e-switch firmware, so lights that have both can have it both ways - lights like the X6R, Yezl Y3, L4, and many others. I ran out of program space when a I tried this before. Could also be used for e-switch lights with a lock-out feature, so you have the effectiveness of a twisty, still with full e-switch support.
So, you’re saying that the firmware will have all the fancy mode groups and UI controls available to either e-switch or clicky, or even both in the same light - all supported in one firmware to rule them all? And, it would be cool to have both tighten-for-on (the standard twisty UI) and tighten-for-off (not very common, but better, IMHO) capabilities in the same firmware. Oh, and to complete the laundry list - both forward and reverse clicky support optimized. All of this should be user-programmable (or rather user selectable ) through the UI. Am I asking too much? 0:)
Probably short answer is yes - you are asking too much, or dreaming like me . Besides, “There is only one Lord of the Firmware, only one who can bend it to his will. And he does not share power.”
However, “That there’s some good in this world, Mr. Frito… and it’s worth fighting for.”
Ran Tom E's FW through some paces and it did great. UI is solid and reliable. Strobe is great. I think Turbo timed out at 2min 6sec. Could not get it to exhibit any glitches. Very nice.
I tried working the LVP, but fried an emitter due to a careless turn of the bench top voltage dial. I never get reliable results trying to test LVP with my bench top power supply anyway. Don't have time to try testing with cells tonight.
It's a winner in my book. I'm going to go work on designing the OSH Park boards I discussed in the OP. Want to get those available and also place an order since they can have long lead times.
I did the bench PS testing, and it trips at 3.1v, so the ADC_LOW should be set at 120, and ADC_CRIT at 110 to get 3.0v and 2.8v, respectively.
Darn - just bricked another 45 MCU (can't verify the dnld). It doesn't work after this occurs, so something must be goin wrong in the AVRDude dnld process. I was able to do quite a few dnlds though before it happened again.
I know this is a little late but it has an interesting tidbit on the programing. Atmel for whatever reason chose to change the instruction set between the 13 and higher models.
Although it appears that the ATtiny x5 parts are a superset of the ATtiny13 parts, they are not code compatible - not even source code compatible, since not just the register addresses, but the bit locations in them are different.
Love your work Tom E not that I really understand it. I'd suggest at the end of the day we will all win with the work your doing. Thanks.
The author sounds like he really did not attempt a port, I'd say, very little actual programming experience. Technically, the instruction set is the same between the 13 and the higher end MCU's, with minor enhancements to support the added functionality. I could not find one example of them making a change, in a register layout for example, where the functionality of the register stayed the same. In fact I'd say they went out of their way to keep it the same. I think it was 3 to 4 lines of code we had to change, out of 500 or so. There was only one line of code that wouldn't compile. His page is a great exaggeration, and the list of differences shown has very little to do with code changes. I've done tons of porting code projects over the years, from asm to C, C to C with MCU changes, C to C#, and many others, and this port was much easier than most. Porting is actually a specialty of mine, I got a rep for that, and I've gotten contract jobs with only that one goal in mind. The development tools stayed the same, and the compiler is actually the same, it's just that some pre-defined libraries and constants that are MCU specific had minor changes. Also our flashlight driver firmware versions don't use all the features the MCU offers, so it's not like we had to delve into every register, so it's simpler than what it could be.
For me with this project, testing is a challenge because I'm used to having more advanced tools available, such as simulators, and interactive debuggers.
All I have to say is WOW!!
Great work everybody!