Attiny25/45/85 FW Development Thread

Ok, I "think" I fixed the problem. I'm not too excited cause time will tell... The apparent big major problem is the pinouts of the USBASP V2.0 is not as documented, maybe... flashlightwiki seems to be wrong, at least not matching my USBASP. Also the Protostack "AC-PG-USBASP USBASP AVR Programmer" manual seems to have it wrong, even though that's where I bought the USBAVR from! Also, the ProtoStack doc and flashlightwiki don't match each other for pins #3 and #4. Ground pins are #8 and #10, pins #3 and #4 are something else -- 8 and 10 check for continuity, #3 doesn't. Both my USBASP's are labeled Lcsoft Studio, one bought from FastTech, one from ProtoStack.com, and both show no ground continuity on pins #3 or pin #4.

Ok, so change the ground pin from #3 on the dongle to #10 -- all flash programming issues seemed to have gone away. So far I haven't bricked any MCU's also, and it works multiple times without a hitch. What I'm doing now is setting the fuses separately from doing firmware dnld - two different batch files, ala Halo (thanks!). This in itself though did not help, did not fix the problem, but somehow it recovered an 85V I thought might have been bricked (no longer programmed in air).

Someone please confirm, or not, this insanity -- if we all have been wiring this up wrong and getting away with it for the 13A's...

I'm really, really hoping this is legit. WinkSmileCool

I can confirm, no ground on pin 3 of my blue LC Technology version. Pin 10 and 8 are ground. By the way pin 4 is suppose to be txd, goes along with pin 6 rxd on the LC Technology / LCsoft version. It was broken out for future use or alternative use of the board.

Did a little more searching, and in Hoop's useful thread on how to flash a Nanjg (https://budgetlightforum.com/t/-/30672), he references the flashlightwiki page, which I have to assume is wrong for the USBASP's we are buying now, but in his Post #1 he lays out the wiring for ground to go to the proper pin #10 in one set of pics/info (the clearest defined one), so maybe lots of guys have it right. Back when I started, we used flashlightwiki as the ultimate guide/ref.

Here: http://www.protostack.com/accessories/usbasp-avr-programmer, is a link to Users Guide that shows pin #3 as ground, pin #4 as TXD, but it seems clearly the doc is wrong about pin #3.

Protoshack, $18 for a usbasp clone?! At least double check and fix your pinout for $18.

Yes - I bought mine before I knew of FastTech, and the "Perfect Modes" thread and flashlightwiki were the only sources of info, so it was posted there ProtoStack had them. I got my latest AVRDude version from their site - drivers that work under Win 10. They actually have manuals, support, etc. , but after we found them on FastTech for cheap, we all got them from there. My FastTech one though has a bent USB connector - poor mount on the board.

This is great btw... I'm off writing code, testing, debugging, etc. Already re-dnlded 3-4 times without a hitch !!

I’m cheap, I like searching ebay and now aliexpress. They sometimes have better prices than FT / BG. Plus it’s easier to get a refund on ebay if the item never arrives or is doa.

Ok - got my 8 * 2 * 2 mode configurations working. Didn't take long once I could dnld. Works awesome so far - 8 sets of modes in lo->hi or hi->lo order, and mode memory or not. Just under 2K of code space.

I like how it works so far. I can add a couple more options now.

Nice!
Are you running at 8mhz on the tiny85? Have you tried 4mhz? I think 4mhz should increase reliability for the tiny85 (non-v) at lower voltages than it’s official 2.7v min. Then we can use the cheaper non-v 85s.

I don’t know if there reallyis the need, I mean is anyone going to want a LVP cutoff below 2.7v anyway? And official specs are usually conservative anyway, jeelabs sells atmel boards that run outside of specs and have never had a problem. But still I’d idea of helping to keep it reliable at lower voltages, just in case.

Yes - 8 Mhz. No, didn't try 4, but tried 6.4 Mhz, and even though I set F_CPU for 6.4, the timing of _delay_ms() was way off, like a factor of 5 times slower. Not sure why...

Nice to see you’re on track again!

Making some progress myself. I’ve now got the off time cap, voltage monitoring and the E-switch all working on the same pin, and the temperature sensor working also. It requires quite a lot of adaption in the code to do things this way, so porting my 84 firmware to the 85 will be a bit more time consuming. But happy that it works though.

Great to hear Tom E. I recall one wire not being right per the wiki back when I first set up, but I don't recall which one.

It could be just my imagination, but I find the light output at the lower levels seems more pleasant with this MCU. The output seems more "solid". They all are running at 8 Mhz.

That’s brilliant, freeing up pins for extra features like voltage indicator LEDs or extra sets of 7135s. Nice work!!

Yes - this is sounding real nice! Nice work Mike!! I think PWM's though will still be restricted to just two pins? Is that still true with this setup?

Thanks. Basically what I’ve done is do a voltage check on startup for off time, start the watchdog interrupt to highest 16ms, in the watchdog interrupt I do a temp check, restart ADC and then do a voltage check which covers E-switch and cell voltage. If the voltage is 0 (or very close to it) the the E-switch is pressed because it shorts to ground.

With the voltage divider resistors high enough and with very different values there is a measurable difference between the caps charge time and discharge time, allowing me to get off time readings on startup that are much lower than voltage readings during normal operation. R2 of the voltage divider works as a bleed resistor to the off time cap, so it has to be pretty high. I’m using 1500K as R1 and 300K as R2. I have to delay the normal voltage check slightly after each E-switch press in order to wait for the cap to be fully charged again or the cell voltage reading is too low.

I’ve got more testing to do to see high this works with lower voltages when the cells are nearing depletion, and also maybe temperatures will screw it up further. A few quick tests on difference voltage levels seems ok, but haven’t tried out under high temps. Looks good so far though, and requires no additional components, only higher values on the voltage divider resistors. Accuracy for off time measuring isn’t as good but so far I’ve been able to reliably detect quick off and medium quick consistently, so it appears good enough.

I’ve been reading this thread for a while and my understanding is you guys are trying to make
ATTiny 85 based driver with actual temperature detection (no more turbo timers), e-switch support,
accurate button press timing and possibly more modes (ramping?) and options due to more resources
85 provides?

Please excuse my ignorance. :slight_smile:

Partiallymostly correct, yes. My first goal is more functionality and greater flexibility, but another goal is to make use of the internal temp sensor the 85 has (13A doesn't have it). There's other special use applications the extra program space will give you, plus things like what Mike is doing - multi-use of I/O pins we probably couldn't do before because of limited program space.

I have basically working now combined power switch and e-switch mode changing, so lights like the Warsun X60, EE X6R, and many others can fully utilize both tail and side switch's. I'm mainly working on the e-switch capabilities because I much prefer the better UI's they can offer. Also just got working a config UI for choosing 1 of 8 mode sets, lo-hi, hi->co toggle, and mode memory toggle. Also want to add a side switch lock-out ability to make it difficult for the e-switch to inadvertently turn on the light. I got a quick access to strobe now, but want to make it a full group of hidden/special modes.

Also an advantage will be combining our separate drivers into one code base - the 85 will allow us to do that. Again, I'm almost there with this one driver supporting both an e-switch and tail power switch.

Lots more to do, and would not have this option on the 13A for sure...

I have ATtiny84 firmware I’m using in the drivers I built for these two lights: Mod: BMF SRK v2 Roche Edition (Rebuilt into triple XHP 35 HI) and Mod/Driver: ZY-T08 series conversion, MT-G2..
I’ve done a bit of coding on it since then and have implemented quite a lot of functionality that I really like. Almost everything is user configurable, like the temperature threshold for shutdown, output levels, voltage thresholds, turbo timer, etc. It also has constant current steps of 0.35/0.38 amps, using PWM only between those steps, and this is what uses up the pins. Now I want to use it in my 85 based drivers, but because the 85 has less pins I’ve attempted to move the functionality of three pins over to one pin. It’s working, so I can proceed…

I finally made time to get started on new features for a tiny25 clicky-switch driver. So far most of the changes have been oriented toward making the code more portable and abstract, but this should help with adding more features soon.

Tonight’s progress was about abstracting away PWM levels and power channels. So, instead of specifying these directly, the code simply requests a perceptual brightness level of 0 to 64. Or zero to whatever the ramp size is set to. It uses a smooth ramp based on perceptual brightness, which gets translated automatically into PWM levels for each power channel. Aside from making mode definitions shorter and easier, it also provides a foundation for smooth output control for thermal and voltage step-down. And e-switch-based ramping, sometime in the future.

Normally, to get five evenly-spaced modes from moon to max, the code would need to specify PWM levels like 1, 7, 38, 114, 255. Or something more complicated for a FET+1 driver — 0+3, 0+66, 11+255, 88+255, 255+0. But instead, one can now specify 1, 16, 32, 48, 64. Or, with a ramp size of 100, it would be 1, 25, 50, 75, 100. And it works regardless of whether it has one or two power channels.

This isn’t really a user-visible sort of thing, but it makes the rest of what I’m doing a lot easier.

Thanks guys, this clarifies a lot! :beer: I really look forward to all those things getting
accomplished. My electronics knowledge is (currently!) limited to Ohm’s and Kirchoff’s
laws, but I do have some experience with C/C, so I will probably mess around with
your work and try to learn something.

May I suggest that you try Github for code hosting? It would be amazing if
one day all of the open source projects originated here on BLF were hosted
in one place with proper documentation and support.
(I plan on introducing this idea to community, hopefully there will be response)

I think a lot (most?) of the open source code we bump around with on BLF is available in ToyKeeper’s repository. Link is in her signature line. Am I right, TK?