Attiny25/45/85 FW Development Thread

Very good info. The code should be a great starting point. Probaby just need to change to ADCx to ADC4 for the internal sensor (haven't looked at the code yet). Although external would allow a higher quality sensor and faster feedback, it does cost a MCU pin.

Thank you RMM for an awesome tip. :)

I ordered these:

ATtiny25V-10SSU (from Mouser, qty 10 for $19.50, total order: $32.64, total payment: $39.63)

Just doing a search on the SSU part # on AliExpress found qty 10 for like $13-$14 which is a pretty good deal, just hope these haven't been pre-programmed with the reset bit set as an I/O pin - this happened to me for a qty 10 order of 13A's on eBay.

I'll look at that temp sensing code. Still tied up with the dive lights, but they are coming along. The Dx4S seems to be an awesome deal. One I modded does little over 3000 lumens with an R120 resistor mod, replaced 4 cool white XM-L2's with T6 4C's, 4.5A tail on 2 26650 protected cells. Wish I could do a driver swap, but they use the mag sensor. Might be worth looking into though to get one of those working on an I/O pin. The Dx4S is two cells with the LED's wired 2S2P, so perfect for a Zener LDO driver.

^ That Mouser price is a good deal for the 25SSU. I need to figure out what all I need so that I can spread out the shipping cost.

Sounds like a sweet mod. I need to look up what this Dx4S is. You have a thread on that Tom E?

Can you point me to this Zener LDO driver? There are some nice LDO drivers out there (RMM has some), but I don't know any LDO drivers using zeners.

EDIT: This must be the light you are referring to. Is the "S" a new model?

Well, you wouldn't use a zener and an LDO together. The whole point of the LDO is so that you don't have to use the zener. The zener is a cheap way to regulate voltage and it works great in clicky lights; but in momentary lights, the drain when nothing is running is too high to consider for long-term use.

Ooops, yes, LDO instead of zener, of course. Haven't done a LDO driver yet, though I'd like to with a Y3 as well.

That's the old style Dx4, the Dx4S is at BG ($44) and GB ($37), cheaper at GB but I bought qty 3 at BG and express DHL shipping for under $1.The Dx4S is re-styled, different switch mechanism. BG honored a price match request to GB before for me. GB has given me fits lately. BG seems soo much better, from their well managed, feature rich order history to their customer service, BLF 8% discount code, etc. Right now GB is a bit cheaper though, mostly. they got a MAXY 5% code, but don't work on discounted items.

This Win10 IE (Edge) is driving me nuts! Gotta install a decent browser. With Edge, can't right click, it pastes weird formatting in BLF, PIA...

This topic has gotten a little strewn about (mostly my fault I think), but, since I feel comfortable with what I have working, and seen it work on a 25, 45, and 85, I started looking into the temp sensor support. Post #1186 here: https://budgetlightforum.com/t/-/25032 (STAR firmware thread) has the latest.

Found the Atmel doc http://www.atmel.com/Images/doc8108.pdf, and one fairly good ref for sample code http://andrey.mikhalchuk.com/2011/06/20/reading-attiny854525-internal-temperature-sensor.html.

This is a variant implemented for the 84: https://harizanov.com/2012/07/using-attiny-84s-internal-temperature-sensor/. It has a link to a github repository for the source code.

This one has a plot showing readings, bit for another Atmel AVR MCU, guess it's at room temp: http://www.narkidae.com/research/atmega-core-temperature-sensor/

With reference to the above posts, I have modified JohnnyC’s MTN_momentary_temp.c for Attiny25, the sensor at pin3 PB4 was moved to pin2 PB3 and the switch at pin2 was moved to pin3.
I am not good at writing codes, would the experts here please check if I am modifying the codes correctly. Thanks,

Looked at it quickly. Interesting, this uses the rule of 4 readings in a row, no averaging at all, so one bad reading of a low value will cause a hi temp to not trigger dropping modes. Now this might be ok, not good, or may work flawlessly - I don't know enough at this point. The sample code though uses averaging, and I believe with tossing out outliers (way off readings).

This code may be fine for a more reliable, robust external sensor, but may not be good for an internal sensor. It also doesn't address the issue of calibration, so the two threshholds of 100 for low, 120 for high would have to be calibrated for the internal sensor.

It could be a good starting point however - just dunno enough yet to say.

About the code for addressing ADC4 for the temp sensor, not sure if ADMUX is set correctly. For ADC4 (Channel 4), the code for the variable named: adc_channel has it set to 0x03 - doesn't make sense - ADC4 is a special state of 0B1111 in the 4 lower bits of the register. Can't follow it all, but it doesn't seem correct, not sure... Refer to pg 135 of the 25/45/85 datasheet (http://www.atmel.com/Images/atmel-2586-avr-8-bit-microcontroller-attiny25-attiny45-attiny85_datasheet.pdf).

You are the man Tom. No one else has fully functional 25 FW out. So you get to strewn this thread all you want. I loaded your latest released version onto a chip last night. I should get it installed (another air-wire light) wired into a light tonight.

Hi Microa. I don't have much time and am not fully fluent in C yet. I don't see anything beyond what Tom said. The comment at line 21 specifies high fuse 0xff. That fuse setting bricked out a couple of my MCU's when I had 0x62 and 0x75 as the low fuses. Not sure if it's a problem when combined with 0xe2 like you have.

If the temperature sensor is anything like the voltage sensor, I’d definitely average a few values. Voltage is really noisy and I don’t get a stable result unless I average 8 or more samples with a delay between.

I kinda feel like -- were we nuts for not exploring this sooner? I know real estate on the 15 and 17 mm FET+1 drivers is really tight now, so an expanded footprint for a 45 or 85 might be impossible, but for the 25, it's a true drop-in replacement for the S8S1 package, and looks like you can find the 25's at a reasonable price.

I still like the idea the clock seems to dead-on, at least in the testing I did so far - with a 25 on a 17mm wight FET+1, turbo timeout of 90 secs was dead on. Saw some data though that the temp sensor is not as accurate at 8 Mhz then it is at 1 Mhz. I think we can only choose 6.4 or 8 Mhz though, using the internal clock.

Doing the temp sensor the recommended way looks a bit involved - we really would have to do some serious testing. I've read some guys gave up on the internal temp sensor from frustration with it's accuracy, and went with an external one.

Fortunately, we probably don’t really need to hardcode the temperature calibration. I think we can let the user do that — run the light on turbo while measuring, save the temp to eeprom every second or so, and then when they turn the light off the step-down point will be set.

I plan on using an internal visually-linear brightness array of 64 or 128 levels, depending on available space. Even if the light only has 4 actual “modes”, it will use the larger set as its internal representation of brightness. When the temperature gets too high, drop the internal level by one. Repeat if it stays too high. If it gets too low, increase the internal level by one (to a maximum of what the current “mode” specifies). This gives it nearly-imperceptible output changes while regulating the temperature, much like what recent Zebralights do.

As a bonus, this table means the user can smoothly ramp output. They might choose only 4 main modes, but they’ll have 64 or 128 total to choose from. And on e-switch lights they can use the full set. And by abstracting the output, it should work on both single-channel and FET+1 drivers (though it will need to be recompiled for each). And if we want lots of mode groups, it’s simple because each mode is only a single number regardless of driver type… with plenty of address space left over to represent blinky modes.

These are some of the ideas I’m hoping to build soon. I’m not sure if it will fit on a tiny25, but I hope so.

The user cal would work - we don't need to know true temperature anyway, so it's simpler, just not sure what value that would have, another words, what are we trying to protect from over-temp, and how does exterior temp effect MCU temp in varying environments of outdoor temps, wind (bike usage for example), rain, etc. I dunno if we have to do this type of testing to prove it out or not - hard to say. Have you thought about these issues? It's been going through my mind a couple of times thinking bout it. The external temp sensor seems to have more value, but hard to say. Could be the external housing temp stays pretty in sync with the MCU's, or close enough at least - I might be over-thinking this.

The higher res of larger internal table sounds great - makes a lot more sense. I never was crazy about having to use the mode table for adjusting for LVP as well. I think there is/was a firmware variation that did stepped droppage of PWM's for LVP, but not table driven. If we do have to do averaging, might have to do ADC's frequently enough to have a good adjustment response time.

I suspect that it might help to stuff thermal transfer cubes into the pill between the MCU and the plate where the MCPCB rests. This should give a better temperature reading, I think.

But it might work well enough without… I mean, the Meteor used the attiny85’s internal sensor and it does okay.

As for ADC readings, I figure it will probably have to keep two backlogs for averaging… read the voltage, add it to the voltage data, take an average, maybe make a decision. Swap the ADC channel. Read the temperature, add it to the temperature data, take an average, maybe make a decision. Swap the ADC channel. Repeat. This would be part of an active main loop somewhere which also handles blinky mode events and e-switch events.

Blinkies will likely disrupt the event timings (especially e-switch) unless it’s all asynchronous… but async is hard to do on such a small processor. Perhaps the WDT can handle that. I’m hoping to get rid of as many interrupt handlers as possible though, to reduce bugs and code size.

I’m not sure if it would be better to use a round-robin array and act on the average at each step, or collect several complete samples before doing each average.

In any case, I think I’ll be able to get hardware soon so I can start on the code. :slight_smile:

If there’s room, I also hope to queue e-switch events in a meaningful form so that complex button events can be mapped to arbitrary actions. No more awkward hard-coding the logic and special cases in an interrupt handler. I started on this once a while back, but quickly ran out of room. Hopefully it’ll go better this time.

Sorry, I’m doing a lot of thinking out loud here.

Cheat codes! :party:

Hi Tom E. Sorry for confuse you that my modified codes are for an external LM45 sensor connecting to PB3. I thought that the thermal couple between the LED and the sensor is very critical in actual application. General speaking, the MCU is remote from the LED so I prefer to employ an external sensor.

Hi ImA4Wheelr. Thanks for your advice. The high fuse should be 0xDF (SPI enabled). My modified codes have not been tested with a driver yet.

Ahh, ok. I'm thinking you'd get more reliable results with an external sensor, so all's good.

T_K - please think out loud Smile. Interesting - didn't know the Meteor was using the 85 and it's internal temp sensor. I didn't get one, and hadn't been keeping up on the threads. It sounds like if it's set up properly, it can be practical. To me, the Meteor is nothing that unusual, except for it's small size. What Richard is doin with a M6 is more interesting to me. Haven't seen/heard much in details, accept it has 4 FET's - wondering if he is stacking them/running in parallel. I didn't realize parallel FET's would be necessary because the better FET's are rated to 50-100 amps.

Great conversation going on in here tonight. TK and Tom E, one seriously talented duo.

Tom E wrote:

. . . I know real estate on the 15 and 17 mm FET+1 drivers is really tight now, so an expanded footprint for a 45 or 85 might be impossible, but for the 25, it's a true drop-in replacement for the S8S1 package, and looks like you can find the 25's at a reasonable price. . . .

Another option is to just bend the legs in on a 8S2 (SU) chip. I find the best approach is to lightly push the legs on the inward arch (towards bottom of each leg) until the leg just touches the silicon chip. Is springs back just a hair and fits the SSU footprint nicely. It's easy and only takes a couple seconds to do. I imagine we will occasionally get a broken leg, but I haven't yet so far. The picture below is a bad angle. I'll try to get a better angle next time.

Here are some better angles. First pic is comparison to an Attiny13a SSU for scale. Attiny45 SU on top. Second is a profile view. The progamming clip fits and holds much better after the pins are bent.

Used your FW for a bit tonight Tom E. Only got to use it while it was connected to the PS because I had some kind of short when I assembled the light. The little I did use it, it was very sweet. The momentary switch was flawless. That strobe is wicked by the way. I couldn't really simulate a clickie switch with my set up, but the little I did, it worked fine. I like the way you have it set up with memory on the clickie switch and all.

I didn't test turbo time out. LVP seemed to be working fine, but I just did a quick check using the PS.

Can't wait to get the short fixed so I can put it through more paces and take the light into the wild.

EDIT: Driver was a HX-1175b1 modded for 9 amps out to an MT-G2 using 4S cells. Alt PWM output was disabled and 2 Modes were added for a total of 7 modes.

Anyone know of a decent small 18650 host with both an e-switch and clicky switch? The Convoy L4 is pretty large…

I’m mostly looking for something to use for testing.