Attiny25/45/85 FW Development Thread

1911 posts / 0 new
Last post
fixed it
Offline
Last seen: 4 months 3 weeks ago
Joined: 12/08/2015 - 14:27
Posts: 396
Location: Canada

The only point of doing it within the firmware would be to include more options than can be done with tables due to limited space. It doesn’t seem like that will be the case.

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 1 week 1 day ago
Joined: 01/14/2016 - 16:38
Posts: 1221
Location: Germany

Since there are a lot of complaints regarding "short_click/medium_click" because of temperature dependency of otc measurement I suggest a temperature compensation for next driver versions.

Quick and dirty, can be improved, works in my driver.

// experimental temperature compensation for otc value
thermal_compensation = adc_init_and_read(ADC_MODE_TEMP);
if ( thermal_compensation > 76 )
    thermal_compensation = (x * (thermal_compensation - 76));
else
    thermal_compensation = 0;

...
if ( otc_voltage > (OTC_SHORT_PRESS - thermal_compensation)  )
...

with x something between 4 and 8. Predefined OTC border values must be increased.

Mike C
Mike C's picture
Offline
Last seen: 3 weeks 4 days ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

Flashy Mike wrote:

Since there a lot of complains regarding “short_click/medium_click” because of temperature dependency of otc measurement I suggest a temperature compensation for next driver versions.


I haven’t had temp issues with mine, maybe because of the component choice, not sure. For me there is much more difference if the cell is fully charged or almost depleted. Charging the OTC with 2.8V or 4.2V makes more of a difference than temperature. I couldn’t be bothered to compensate for it though, having the voltage divider and OTC on the same pin presents it’s own set of challenges.
Mike C
Mike C's picture
Offline
Last seen: 3 weeks 4 days ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

Sharpie wrote:
I’ve got some ideas how to fix this, but that is another thread.

Something like Flashy Mike’s compensation routine should be enough.

Mike C wrote:
Flashy Mike wrote:

Since there a lot of complains regarding “short_click/medium_click” because of temperature dependency of otc measurement I suggest a temperature compensation for next driver versions.


I haven’t had temp issues with mine, maybe because of the component choice, not sure. For me there is much more difference if the cell is fully charged or almost depleted. Charging the OTC with 2.8V or 4.2V makes more of a difference than temperature. I couldn’t be bothered to compensate for it though, having the voltage divider and OTC on the same pin presents it’s own set of challenges.

Changed my mind… Going to play around a little with voltage compensation on my drivers, just to see if I can make it work nicely. If it works out maybe I can re-use the code for temperature compensation, gotta do a little more precise testing to see how much my drivers are affected by temp changes.
ToyKeeper
ToyKeeper's picture
Online
Last seen: 1 min 13 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10292
Location: (469219) 2016 HO3

Flashy Mike wrote:

Since there are a lot of complaints regarding “short_click/medium_click” because of temperature dependency of otc measurement I suggest a temperature compensation for next driver versions.


Quick and dirty, can be improved, works in my driver.


// experimental temperature compensation for otc value
thermal_compensation = adc_init_and_read(ADC_MODE_TEMP);
if ( thermal_compensation > 76 )
    thermal_compensation = (x * (thermal_compensation - 76));
else<br />&nbsp;&nbsp;&nbsp; thermal_compensation = 0;
...
if ( otc_voltage &gt; (OTC_SHORT_PRESS - thermal_compensation)&nbsp; )<br />...<br />


with x something between 4 and 8. Predefined OTC border values must be increased.


It’s not nearly as much of an issue on drivers with good components. However, that said, there are other complicating factors. For one, the most-affected drivers tend to have their OTC readings right at the edge of the usable range. So, there is sometimes no room to adjust; it’s already at the boundary. It would need calibration on a per-unit basis because the behavior varies with each individual driver. The MCU’s temperature readings alone can vary by a pretty large amount, so that “76” either needs to be configurable by the user or calibrated at the factory. As Mike C said, voltage is also an important factor. Getting a reliable temp+voltage measurement can take a few tries too, so that would delay boot-up until readings are taken. The scale factor “x” needs to be quantified and might not be linear, or might require floating-point math to get it even close to accurate (floating point or even an integer multiply can take a lot of ROM space).

Overall, it should be do-able on some drivers. But it might involve undesirable tradeoffs.

Anyway, the code is all there for anyone who wants to improve it. Smile

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 1 week 1 day ago
Joined: 01/14/2016 - 16:38
Posts: 1221
Location: Germany

It is a bit frustrating when people have a lot of counter arguments but don’t even try. I did try on two high current triples and it works reliably. Without compensation the lights with bistro drivers (banggood) weren’t usable at all when hot. If calibration were necessary then even more without compensation. When this driver is used in BLF lights we must use whatever banggood put on the driver, and that are not always “good components”. The “undesirable tradeoffs” are already there, just read the threads about this lights.
Of course factor “x” and other parameters have to be quantified and I know the temperature readings differ between drivers, my test drivers have quite different readings in voltage and temperature. And probably there is no linearity, I said that it was just a quick and dirty hack, my first test of compensation. And nevertheless it works better than without compensation.
I also don’t understand all this fear of floating point math. With some tricks you could do a lot in fixed point which means integer with some shifting. A 16×16 bit multiplication takes less than 40 bytes program space, a 16/16 bit division less than 50 bytes. I squeezed a complete 2-channel ramping calculation for 256 steps in ATtiny with less than 200 bytes code, configurable for probably any light by only 1 parameter which can easily done by the user.

ToyKeeper
ToyKeeper's picture
Online
Last seen: 1 min 13 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10292
Location: (469219) 2016 HO3

Flashy Mike wrote:
It is a bit frustrating when people have a lot of counter arguments but don’t even try. I did try on two high current triples and it works reliably.

A 16×16 bit multiplication takes less than 40 bytes program space, a 16/16 bit division less than 50 bytes. I squeezed a complete 2-channel ramping calculation for 256 steps in ATtiny with less than 200 bytes code, configurable for probably any light by only 1 parameter which can easily done by the user.

Awesome, could you put the code online?

I must admit, I was hoping to be proven wrong. Few things are more motivating than “someone is wrong on the internet“.

For people making individual lights, per-unit tweaking isn’t a big issue. A lot of cool things become possible when people can modify the code, and when space doesn’t need to be spent on runtime configuration options. Config options and whole-batch consistency only really matter when making larger amounts for more people. I think I’ve spent too much time on the large-batch approach, and should go back to the more enjoyable one-at-a-time approach where these things are feasible.

Hoop
Hoop's picture
Offline
Last seen: 1 week 1 day ago
Joined: 12/20/2012 - 05:33
Posts: 1002
Location: Spokane, WA

Just tried Bistro out. Made a light for a friend of mine; Red S2+ triple with copper heatsink and a Mtn-Fet+1 with Bistro on it. Really liking the reverse functionality and programability. I’m sure most people could get exactly what they want from this firmware. Awesome work ToyKeeper.

I noticed that the voltage blinkout seems to only blink the tenths. Someone in the Mtn thread asked about turbo step-up after the temperature of the light reduces. I’m curious about this as well. Seems it does not have this functionality upon testing.

ToyKeeper
ToyKeeper's picture
Online
Last seen: 1 min 13 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10292
Location: (469219) 2016 HO3

By default, bistro uses a volts+tenths style battery readout. I think RMM’s drivers use a different style though, with 0 to 8 blinks representing about 12.5% of a full charge for each blink. It’s a compile-time option. You’d need to reflash it to change the indicator style.

About stepping back up, it should be able to in the right conditions, but those conditions are uncommon during normal use. Initially, it would overshoot its ideal level, wait for the temperature to drop, step back up and again overshoot, wait for the temperature to rise, then repeat in an oscillating pattern. It bounced. To avoid that, I simply made it steer slower. Not the greatest solution, but it worked okay with the X6 due to its large heat sink. On a smaller, higher-powered light, I honestly wouldn’t trust its thermal regulation much.

If you want to see the thermal behavior more clearly, you could put it on a medium mode, aim a hot blow dryer at it until it steps down, then switch the blow dryer to cool mode until the light ramps back up. Works faster if you pull the driver out so it’s floating in the air, though it still steers pretty slowly to avoid bouncing.

Here’s a visual representation. On the left is what I started with, reacting too fast and too far, bouncing around. In the middle is what bistro uses now, reacting slowly in a manner which overheats then settles (usually), but might overheat too far on a small triple. On the right is what it should ideally be doing, hitting the right level at the right time without exceeding any limits.

Hoop
Hoop's picture
Offline
Last seen: 1 week 1 day ago
Joined: 12/20/2012 - 05:33
Posts: 1002
Location: Spokane, WA

Ah. Thanks for the great explanation. Well, it definitely works as a safety feature as is, which is necessary, and I appreciate. I’d wager it’s better than an adjustable turbo timer.

The first step down stays pretty bright, and it does keep getting hotter. A few more step downs starts to stabilize the temperature. It continues to step down a couple more times to a pretty low level (like mode 2) and stays there. On this light, maybe a large initial step down might work well, then ideally it would wait and adjust the output in small increments based on the temperature, to maintain that temperature. A very slow, almost imperceptible ramping adjust after the initial drop, or just in general, would be super cool but that might be impractical due to program space or whatnot.

Good safety feature as is though. I think it may work better on this light if I set the initial trip point lower.

EasyB
Offline
Last seen: 55 min 6 sec ago
Joined: 03/09/2016 - 15:24
Posts: 1951
Location: Ohio

Regarding the Bistro thermal management: I just got a FET+1 driver from MTN with bistro flashed by Richard. I’m using it in a S2+ with single XPL emitter. I was trying to test the thermal management by monitoring the light output. With a cooling fan and light in medium mode (about 2.2A, one mode down from 100% in the 5 mode group) the outside temp stabilized around 111F. I then turned the fan off and the temp quickly went up and the driver stepped down when the outside got to around 123F. The driver stepped down to roughly 60% every 12 or so seconds, so it got down pretty quickly. It stepped down 3 or 4 times then stayed at that level. I then turned the fan back on and the flashlight cooled pretty quickly to 91F. I waited for several minutes, but it never stepped the output back up.

Does this seem normal? It’s hard to know exactly what the temp of the MCU is, but it seems like it would have cooled enough to get below the temp setpoint.

ToyKeeper
ToyKeeper's picture
Online
Last seen: 1 min 13 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10292
Location: (469219) 2016 HO3

If it didn’t step back up, it’s probably still in the green zone on that middle graph. To avoid constant bouncing, it has a window of a few degrees where it won’t step up or down. If it gets above the window it steps down, and if it gets below the window it steps up, but if it stays in that zone, it won’t make any changes.

The MCU’s temperature units seem a bit odd. It gives me a reading of 74 for room temperature (70 F?), 87 if I hold a hair dryer on it at its hottest setting for a few minutes (135 F?), and 62 after resting in the freezer (10 F?). That seems to be something like 4 to 6 degrees F per thermal unit, and the no-change window is 2 of those units.

By default, it’s:

  • 79 or more: step down (95 F?)
  • 78: do nothing (90 F?)
  • 77: do nothing (85 F?)
  • 76 or less: step up (80 F?)

That could mean it needs to cool by 15 degrees F before it’ll step back up… which is a bit much. This is probably made worse by how slowly the heat transfers to the driver. Basically, the ceiling gets set a bit low in order to start the step-down sooner, but then when it later stabilizes it might end up too low.

Oh, and the readings differ by at least 5 thermal units between different MCUs of the same type. So, the hardcoded default is likely to be off by 25 F (or maybe more) due to manufacturing variances. I set the initial value to work just right on one light, then tried another identical light with identical code and it thought room temperature was “overheating”.

Anyway, I’d suggest reflashing it if you can, with the window set to maybe 1 unit instead of 2. That’s the minimum to avoid constant adjustments but small enough to make it step up easier. IIRC, I tried this and found it still adjusted too much, but your mileage may vary. Look for this part:

    if ((temp < maxtemp - 2) && (actual_level < output)) {
        actual_level ++;
    }
Flashy Mike
Flashy Mike's picture
Offline
Last seen: 1 week 1 day ago
Joined: 01/14/2016 - 16:38
Posts: 1221
Location: Germany

ToyKeeper wrote:
Awesome, could you put the code online?
Soon.
ToyKeeper wrote:
Few things are more motivating than “someone is wrong on the internet“.
That’s cool!
ToyKeeper wrote:

For people making individual lights, per-unit tweaking isn’t a big issue. A lot of cool things become possible when people can modify the code, and when space doesn’t need to be spent on runtime configuration options. Config options and whole-batch consistency only really matter when making larger amounts for more people. I think I’ve spent too much time on the large-batch approach, and should go back to the more enjoyable one-at-a-time approach where these things are feasible.
I’m rather targeting the less experienced modders who are not able to fiddle with code and like to use this driver for different lights – and the experienced modders who don’t want to flash the driver multiple times in order to find the best ramping curve.
blueb8llz
Offline
Last seen: 10 hours 6 min ago
Joined: 06/02/2012 - 01:16
Posts: 3029
Location: California

Can’t believe I never seen this thread. Maybe because the thread title didn’t look interesting or just because it has to do with boards, drivers, programming and software stuff And all things I’m not able to do.

But some very interesting reads here. I’m not close to finish reading this thread yet though.

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 1 week 1 day ago
Joined: 01/14/2016 - 16:38
Posts: 1221
Location: Germany

ToyKeeper wrote:
The MCU’s temperature units seem a bit odd. It gives me a reading of 74 for room temperature (70 F?), 87 if I hold a hair dryer on it at its hottest setting for a few minutes (135 F?), and 62 after resting in the freezer (10 F?). That seems to be something like 4 to 6 degrees F per thermal unit, and the no-change window is 2 of those units.
Don’t know if you are aware of reading the ADC left aligned which means only the highest 8 bits of a 10-bit temperature reading. Reading all 10 bits should show the specified temperature resolution of 1 LSB / °C.
ToyKeeper
ToyKeeper's picture
Online
Last seen: 1 min 13 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10292
Location: (469219) 2016 HO3

I’ll have to try using 10-bit temperature readings next time. It looks like the useful range (in 8 bits) is about 50 to 110, or perhaps 200 to 440 in 10-bit mode, which should translate nicely back into an 8-bit integer for convenience. If I understand correctly, that would be enough to cover the entire range the MCU will ever see in a flashlight. It’d probably need to average several samples to reduce noise, but that’s not hard.

The only cost there is a few extra bytes of ROM. And it shouldn’t be much compared to what’s needed for a proper PID algorithm.

It could probably also use this data to adjust the OTC, as you suggested. Maybe just right-shift the temperature reading by a few bits and add or subtract it from the threshold to compensate for variable OTC drain. It seems safe to assume the OTC and MCU will be near the same temperature. I’m not too excited about doing the measurement and calibration on that though. Smile

There have been some efforts to resolve OTC variability in hardware too, using higher-value resistors for the voltage divider and adding an explicit OTC drain resistor to help it discharge at a predictable rate. And a little talk of adding a big capacitor to keep the MCU running as long as possible after power gets disconnected, going into a sleep mode, and measuring “off” time with a low-speed watchdog timer. None of these are ideal, but all of them seem at least promising.

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 1 week 1 day ago
Joined: 01/14/2016 - 16:38
Posts: 1221
Location: Germany

Just my personal opinion regarding thermal regulation:
I don’t really like the light ramping up and down by itself caused by temperature change. If the light can’t hold the required brightness level I rather prefer the same step down as is done using a turbotimer and step up again with a short click later. If the user can configure the turbo stepdown delay, the temperature limit and the level to stepdown to – even better.

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 1 week 1 day ago
Joined: 01/14/2016 - 16:38
Posts: 1221
Location: Germany

I did some more tests with otc temperature compensation. It now works almost perfectly when bleeding resistor has been removed, and with bleeding resistor in place still much better than without compensation. As Toykeeper mentioned there should be some calibration. This can easily be done when doing calibration for the maximum temperature limit: user has to start this calibration with "cold" light (room temperature), just when started store the (low) temperature into eeprom. For "better" drivers which need less compensation (don't have any) probably decreasing the shift value will help - or use a multiplication or a lookup table instead for more granularity. Look up table might even be the best solution since there are only a few values to look up and optimal compensation is not linear (medium press otc value could even need some more compensation).

My code for banggood driver without bleeding resistor is currently:

#define OTC_SHORT_PRESS 235
#define OTC_MEDIUM_PRESS 200

...
uint8_t thermal_compensation = adc_init_and_read(ADC_MODE_TEMP);
uint8_t thermal_low = eeprom_read_byte((const uint8_t*)EE_ADR_THERMAL_LOW);
if ( thermal_compensation > thermal_low )
    thermal_compensation = (thermal_compensation - thermal_low) << 4;
else
    thermal_compensation = 0;
...
if ( otc_voltage > (OTC_SHORT_PRESS - thermal_compensation) )
...
if ( otc_voltage > (OTC_MEDIUM_PRESS - thermal_compensation) )
...

 

Edit:

thermal_compensation must not grow larger than OTC_SHORT_PRESS and OTC_MEDIUM_PRESS, a check for this should be added. If someone calibrates his light at a very low temperature, "OTC_SHORT_PRESS - thermal_compensation" may overflow and result in a too high value which may hinder the user to enter configuration mode with short clicks ever again (at higher temperatures).

giorgoskok
giorgoskok's picture
Offline
Last seen: 1 day 1 hour ago
Joined: 11/13/2015 - 10:46
Posts: 2670
Location: Greece

Any windows user knows how to flash attiny 25 ?

On attiny13 i used this in a script :

Quote:
avrdude -p t13 -c usbasp -u -Uflash:w:%1.hex:a -Ulfuse:w:0×75:m -Uhfuse:w:0xFF:m

Except the t13 (t25), what else i should change ?

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 1 week 1 day ago
Joined: 01/14/2016 - 16:38
Posts: 1221
Location: Germany

giorgoskok wrote:
Any windows user knows how to flash attiny 25 ?

On attiny13 i used this in a script :

Quote:
avrdude -p t13 -c usbasp -u -Uflash:w:%1.hex:a -Ulfuse:w:0×75:m -Uhfuse:w:0xFF:m

Except the t13 (t25), what else i should change ?

The fuses:
-Ulfuse:w:0xD2:m -Uhfuse:w:0xDE:m

If you don’t change them SPI will be disabled and you can’t program the mcu with USBASP anymore!

giorgoskok
giorgoskok's picture
Offline
Last seen: 1 day 1 hour ago
Joined: 11/13/2015 - 10:46
Posts: 2670
Location: Greece

Flashy Mike wrote:
giorgoskok wrote:
Any windows user knows how to flash attiny 25 ?

On attiny13 i used this in a script :

Quote:
avrdude -p t13 -c usbasp -u -Uflash:w:%1.hex:a -Ulfuse:w:0×75:m -Uhfuse:w:0xFF:m

Except the t13 (t25), what else i should change ?

The fuses:
-Ulfuse:w:0xD2:m -Uhfuse:w:0xDE:m

If you don’t change them SPI will be disabled and you can’t program the mcu with USBASP anymore!

Thanks .
I still get an error :

Quote:

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: error: programm enable: target doesn’t answer. 1
avrdude: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check.

Edit : i use bistro

Tom E
Tom E's picture
Offline
Last seen: 40 min 8 sec ago
Joined: 08/19/2012 - 08:23
Posts: 12873
Location: LI NY

Flashy Mike wrote:
giorgoskok wrote:
Any windows user knows how to flash attiny 25 ? On attiny13 i used this in a script :
Quote:
avrdude -p t13 -c usbasp -u -Uflash:w:%1.hex:a -Ulfuse:w:0x75:m -Uhfuse:w:0xFF:m
Except the t13 (t25), what else i should change ?
The fuses: -Ulfuse:w:0xD2:m -Uhfuse:w:0xDE:m If you don't change them SPI will be disabled and you can't program the mcu with USBASP anymore!

The fuses have to match up with the firmware as well. Need to know what 25 firmware - the firmware MUST be written for a 25, not a 13A. Bistro is for the 25 for example.

The author of the firmware pretty much always states what fuse values to use. Most of the fuse settings are required to be specific values, to match what the firmware is written for.

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 1 week 1 day ago
Joined: 01/14/2016 - 16:38
Posts: 1221
Location: Germany

giorgoskok wrote:
Thanks .
I still get an error :
Quote:

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: error: programm enable: target doesn’t answer. 1
avrdude: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check.
The error is NOT related to the fuses. USBASP can’t connect to the mcu, check the connection. In case of wrong mcu type setting you will get an other error message.

Edit:
if you’ve programmed the ATtiny25 before with the fuse settings for Attiny13 you can’t program it anymore without a special programmer. In this case the above error message (2nd) may apply. It happened to me once but I can’t recall the specific error message.
The 1st error message is not important and can be ignored.

giorgoskok
giorgoskok's picture
Offline
Last seen: 1 day 1 hour ago
Joined: 11/13/2015 - 10:46
Posts: 2670
Location: Greece

Got it working by desoldering the attiny from the pcb and flashing it alone .

My latest order from oshpark (fet+1 drivers) seems to have something wrong … Built today 4 drivers : one with attiny25 , and it works like a one mode driver (like the led – and the ground is connected) , and 3 with attiny13a that don’t even light up…. Checked all 4 for shorts , but there aren’t any….

giorgoskok
giorgoskok's picture
Offline
Last seen: 1 day 1 hour ago
Joined: 11/13/2015 - 10:46
Posts: 2670
Location: Greece

Sharpie i posted on the drivers thread , seems one pcb (the one with tiny25) had a short from the factory .
The other 3 drivers i don’t know what’s the issue .

Mitko
Mitko's picture
Offline
Last seen: 1 month 1 week ago
Joined: 09/19/2014 - 05:20
Posts: 1537
Location: Bulgaria

Anybody tried the SSN version of those controllers? Cause currently my biggest issue is the overheating, on theory they shouldbe the same

Tom E
Tom E's picture
Offline
Last seen: 40 min 8 sec ago
Joined: 08/19/2012 - 08:23
Posts: 12873
Location: LI NY

Mitko wrote:
Anybody tried the SSN( 105c) version of those controllers? Cause currently my biggest issue is the overheating, on theory they shouldbe the same

Give a clue or link - what are you referring to? What is "those controllers"?

Mitko
Mitko's picture
Offline
Last seen: 1 month 1 week ago
Joined: 09/19/2014 - 05:20
Posts: 1537
Location: Bulgaria

Talking about the 105 degrees C version of ttiny 13 and 25: i see they are awailable at Mouser, at least the 25v SSN

Tom E
Tom E's picture
Offline
Last seen: 40 min 8 sec ago
Joined: 08/19/2012 - 08:23
Posts: 12873
Location: LI NY

Dang, thought you were talk'n bout Nanjg drivers. Hhmm, never heard bout over-heating issues. What happens? Has anyone else said/noticed this? Are the 25's more prone than the 13A to overheating? What 25 boards are you using - those Astrolux ones?

giorgoskok
giorgoskok's picture
Offline
Last seen: 1 day 1 hour ago
Joined: 11/13/2015 - 10:46
Posts: 2670
Location: Greece
Tom E wrote:

Dang, thought you were talk’n bout Nanjg drivers. Hhmm, never heard bout over-heating issues. What happens? Has anyone else said/noticed this? Are the 25’s more prone than the 13A to overheating? What 25 boards are you using – those Astrolux ones?

I use wight’s boards from the development thread , v013 . i build them from scratch .

Pages