Attiny25/45/85 FW Development Thread

1901 posts / 0 new
Last post
Tom E
Tom E's picture
Offline
Last seen: 27 min 38 sec ago
Joined: 08/19/2012 - 08:23
Posts: 9250
Location: LI NY

giorgoskok wrote:
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 .

Sorry I was responding to Mitko. But anyway, what are doing to handle the voltage spikes that cause the 25 to reset? Are you scoping the signals? Generic 13A boards and parts usually result in flaky problems with 25/45/85's -- all noted earlier in this thread.

BangGood (or Manker) that developed the 25 driver for the X5/X6's (runs Bistro) used a 12 uF cap, not the standard 10 uF cap -- that seems to fix the problems on that board (well they think it fixed it mostly), But I've done more.

Mitko
Mitko's picture
Online
Last seen: 45 sec ago
Joined: 09/19/2014 - 05:20
Posts: 1386
Location: Bulgaria
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?

Yes TOm, the controller is overheating and starts acting wierd, happenes too often in smaller lights like S2( mostly) and C8s with longer turbo run time

Nope, Astro drivers are bad – bad caps, bad soldering work too
I use fet +1 v 09 and now for the first time i used V14 boards

Tom E
Tom E's picture
Offline
Last seen: 27 min 38 sec ago
Joined: 08/19/2012 - 08:23
Posts: 9250
Location: LI NY

I dunno - I either forgot about this heat problem or never heard it before. Has the topic ever come up? I've run lights to the untouchable level, but do't recall seeing anything wierd.

Edit: But.. You got me think'n. Maybe when they are that hot, I just turn them off and don't play with modes, etc. Guess it depends on the nature of the weird problems - flaky while just running in a mode, or flaky when operating (changing modes, etc.).

FmC
FmC's picture
Offline
Last seen: 4 hours 6 min ago
Joined: 03/31/2013 - 05:23
Posts: 1740
Location: AU

Sharpie wrote:

Apart from a decent clip. Pomona ? From where ?

Try making an offer on this one – you should get it for ~15$ (AU)

Hoop
Hoop's picture
Offline
Last seen: 1 month 1 day ago
Joined: 12/20/2012 - 05:33
Posts: 733
Location: Spokane, WA
Flashy Mike wrote:

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 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) )
...

I feel like this might just be a big development. BeerThumbs Up

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 4 days 3 hours ago
Joined: 01/14/2016 - 16:38
Posts: 540
Location: Germany

Sharpie wrote:
Apart from a decent clip. Pomona ? From where ?
I recommend the cheap ones from ebay, there are several vendors, e. g.:
http://www.ebay.de/sch/i.html?_nkw=221971171569
You’ll need more than one if you are going to use them often, this clips – also the expensive ones – don’t last forever. I used the expensive clips of 3M and Pomona before, they have not been better than the cheap ebay ones.
As you probably know you will have to re-wire the connector.
giorgoskok
giorgoskok's picture
Offline
Last seen: 3 hours 19 min ago
Joined: 11/13/2015 - 10:46
Posts: 1797
Location: Greece

I agree with Mike.

I have flashed over 30 drivers the last 3 months with the cheap soic8 clip from ebay without any issue.

fixed it
Offline
Last seen: 4 hours 6 min ago
Joined: 12/08/2015 - 14:27
Posts: 233
Location: Canada

giorgoskok wrote:
I agree with Mike.

I have flashed over 30 drivers the last 3 months with the cheap soic8 clip from ebay without any issue.


Me as well. I must have flashed the same driver at least 100 times with the 4$ model which comes with the grey cable and small PCB. I find the extra cable length useful. It isn’t showing any sign of wear so far but I am very careful with my stuff.
giorgoskok
giorgoskok's picture
Offline
Last seen: 3 hours 19 min ago
Joined: 11/13/2015 - 10:46
Posts: 1797
Location: Greece

Finally got the drivers working , but with some problems .
The fet+1 with the attiny13a (a6 firmware), have very short times for the half clicks , nearly impossible to click . Is there any way to have longer times ?

The other driver , the one with the attiny25 (bistro firmware) seems it has one “empty” mode before moon .

Mitko
Mitko's picture
Online
Last seen: 45 sec ago
Joined: 09/19/2014 - 05:20
Posts: 1386
Location: Bulgaria

The “ empty “ mode( its actualy a true moonlight, you can turn it off in the menu, 3th blink) is caused by the mosfet( high int resistance) and/or poor solder joints

Quote:
The fet+1 with the attiny13a (a6 firmware), have very short times for the half clicks

WIll you post a pic of that driver pls( a macro one if possible)

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 4 days 3 hours ago
Joined: 01/14/2016 - 16:38
Posts: 540
Location: Germany

giorgoskok wrote:
Finally got the drivers working , but with some problems . The fet+1 with the attiny13a (a6 firmware), have very short times for the half clicks , nearly impossible to click . Is there any way to have longer times ?
As long as the hardware is not faulty I would first try to adjust the regarding definitions in "tk-calibration.h".

// The OTC value 0.5s after being disconnected from power
// (anything higher than this is a "short press")
#define CAP_SHORT 190
// The OTC value 1.5s after being disconnected from power
// Between CAP_MED and CAP_SHORT is a "medium press"
#define CAP_MED 94 // Below CAP_MED is a long press

To increase switch times you have to decrease the values.

giorgoskok
giorgoskok's picture
Offline
Last seen: 3 hours 19 min ago
Joined: 11/13/2015 - 10:46
Posts: 1797
Location: Greece
Mitko wrote:
The “ empty “ mode( its actualy a true moonlight, you can turn it off in the menu, 3th blink) is caused by the mosfet( high int resistance) and/or poor solder joints

But it’s the 7135 that controls moonlight , right ? I will try to increase the value in the firmware and try again.

About the 13A drivers , the solution is probably the one Flashy Mike mentioned . Any clue how much lower should the values be ?

Sharpie wrote:

Larger or better OTC.

Try stacking another one on top, for starters.

And check the value, if your meter can measure capacitance.

It is, frankly, a rickety design, but if you can find some reliable consistent components, it seems to work far better than otherwise should be expected.

They are not cheap caps from ebay , but it’s the X7R from Farnell . Will try Mikes method before changing something Smile

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 4 days 3 hours ago
Joined: 01/14/2016 - 16:38
Posts: 540
Location: Germany

giorgoskok wrote:
Any clue how much lower should the values be ?
As a start I would leave CAP_MED unchanged and decrease CAP_SHORT in steps of 10.
giorgoskok
giorgoskok's picture
Offline
Last seen: 3 hours 19 min ago
Joined: 11/13/2015 - 10:46
Posts: 1797
Location: Greece

Success! fet+1 with 13A are ready!!!

Reduced both CAP_SHORT and CAP_MED by 20 and works perfect! Also changed to lower moonlight (from 3 to 2 on the 1×7135 channel) .

Edit : Still can’t find the problem on the other with the attiny25 . Moon mode is just empty…

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 11 hours 51 min ago
Joined: 01/12/2013 - 14:40
Posts: 4886
Location: (469219) 2016 HO3

giorgoskok wrote:
Any clue how much lower should the values be ?

This explains how to calibrate the button timings, along with some other things:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/he...

Also, the tiny25 fuse settings are in bin/flash-25.sh in the same repository.

giorgoskok
giorgoskok's picture
Offline
Last seen: 3 hours 19 min ago
Joined: 11/13/2015 - 10:46
Posts: 1797
Location: Greece

Thanks Tk ,
I couldn’t find this file you mentioned . Smile

Mike C
Mike C's picture
Offline
Last seen: 4 hours 42 min ago
Joined: 01/22/2014 - 08:03
Posts: 1521
Location: Sweden

Ive finally made some sort of firmware for my drivers available: http://budgetlightforum.com/node/46225

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 11 hours 51 min ago
Joined: 01/12/2013 - 14:40
Posts: 4886
Location: (469219) 2016 HO3

Mike C wrote:
Ive finally made some sort of firmware for my drivers available: http://budgetlightforum.com/node/46225

Very nice. May I include it in the firmware repository? If so, what kind of license should I list for it?

Each project has a key/value-list metadata file used for description and indexing, but I can probably figure out what to fill in for the rest of that. Smile

Mike C
Mike C's picture
Offline
Last seen: 4 hours 42 min ago
Joined: 01/22/2014 - 08:03
Posts: 1521
Location: Sweden

ToyKeeper wrote:
Mike C wrote:
Ive finally made some sort of firmware for my drivers available: http://budgetlightforum.com/node/46225

Very nice. May I include it in the firmware repository? If so, what kind of license should I list for it?

Sure you can add it, but managing version releases on the repository is something I won’t do. If I release a new version I’ll just switch out the zip file in my link.

What kind of license? I don’t know much about those things… as it’s for my own specific drivers I’d hope no one edits it and sends it off… But if someone actually builds any of my drivers they might want to change the code so they should. To be honest, with all the other cool driver projects floating around I don’t expect must interest in mine. I’m mainly releasing this stuff because I promised I would a long time ago Smile

ToyKeeper wrote:
Each project has a key/value-list metadata file used for description and indexing, but I can probably figure out what to fill in for the rest of that. Smile

Key/value-list metadata file?? Sounds good to me Blushing
Mike C
Mike C's picture
Offline
Last seen: 4 hours 42 min ago
Joined: 01/22/2014 - 08:03
Posts: 1521
Location: Sweden

Already found a bug… I’ve replaced the zip file in my download.

It might be useful if I can replace firmware versions in the firmware repository after all.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 11 hours 51 min ago
Joined: 01/12/2013 - 14:40
Posts: 4886
Location: (469219) 2016 HO3

Mike C wrote:
Sure you can add it, but managing version releases on the repository is something I won’t do. If I release a new version I’ll just switch out the zip file in my link.

Awesome.

I wouldn’t expect you to manage the copy in the repository. I’m going with a model similar to Linux distros, where independent authors do their own thing and someone else pulls it all together into a curated collection.

Mike C wrote:
What kind of license? I don’t know much about those things… as it’s for my own specific drivers I’d hope no one edits it and sends it off… But if someone actually builds any of my drivers they might want to change the code so they should. To be honest, with all the other cool driver projects floating around I don’t expect must interest in mine. I’m mainly releasing this stuff because I promised I would a long time ago Smile

Oh, the licensing thing can unfortunately be complicated. Most of that doesn’t really matter or apply unless it gets really popular though.

Copyrightable works default to all rights reserved. So, nobody can really do anything with it except personal stuff covered by fair use. Making it open requires at least a minimal license statement.

The opposite is public domain, when someone disclaims their copyright so that absolutely anyone can do anything with it. Although normally simple, this can be weirdly complicated in Europe.

The next simplest is a BSD-style license, which basically says anyone can do almost anything, as long as they preserve the copyright, license, and attribution. That’s the bare minimum required for it to really count as a license. Some argue this makes it the most free of all licenses. In practice, however, BSD code tends to get eaten by companies like Microsoft and Apple, who keep taking what the community provides but never give anything back.

I usually go for a GPL-style license, which adds the additional requirement that people must share alike. I.e. anyone who distributes the work (or derivative works) in binary form must also provide the sources. It keeps people from taking without giving back — they can use it, but they have to share their improvements. It also adds protections against a few abuses seen in the wild, such as Tivo-ization and patent trolling (see SCO vs IBM).

There are also quite a few others, each with their own quirks.
https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_softwar...

I know it’s a thing people don’t generally want to deal with (and it can be done later), but people can’t really use or share it without something giving them permission to do so.

Mike C
Mike C's picture
Offline
Last seen: 4 hours 42 min ago
Joined: 01/22/2014 - 08:03
Posts: 1521
Location: Sweden

Well, I don’t really consider it open for anyone to do what they want with it and send it on the others, but the people here seem to respect this no matter what license, and the ones that don’t respect it don’t really care about licenses anyway. I guess GPL sounds fair. Do I need to write something in the firmware for that?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 11 hours 51 min ago
Joined: 01/12/2013 - 14:40
Posts: 4886
Location: (469219) 2016 HO3

I can just tag it with “GPL” in the metadata file for now, but to be fully legit the code needs a comment somewhere in the header. This explains how:

https://www.gnu.org/licenses/gpl-3.0.en.html#howto

… and since the license itself is written by lawyers, this explains it in more plain language:

https://www.gnu.org/licenses/quick-guide-gplv3.en.html

Meanwhile, the BSD license could fit on a napkin. Smile

Oh, and since you own the copyright, you can change or cancel the license any time you want.

Mike C wrote:
Already found a bug… I’ve replaced the zip file in my download.

It might be useful if I can replace firmware versions in the firmware repository after all.


I’ll grab the updated version before adding it.

You’re also welcome to change a branch of the repository and propose merges if you want. It’s extra effort and overhead though, so I normally do that part. And I’m still considering moving it from Launchpad (bzr) to Github (git), since git is more popular. Any preference?

Mike C
Mike C's picture
Offline
Last seen: 4 hours 42 min ago
Joined: 01/22/2014 - 08:03
Posts: 1521
Location: Sweden

ToyKeeper wrote:
It’s extra effort and overhead though, so I normally do that part.

If you are offering to do that part I certainly don’t mind not doing it… I can spend that time on firmware… or writing instructions for it (more work than one would think).

ToyKeeper wrote:
And I’m still considering moving it from Launchpad (bzr) to Github (git), since git is more popular. Any preference?

No preference. I’ve never used any of those.
Tom E
Tom E's picture
Offline
Last seen: 27 min 38 sec ago
Joined: 08/19/2012 - 08:23
Posts: 9250
Location: LI NY

Just posted the latest smooth ramping version of Narsil up on my google docs share, with the updated manual in docx and PDF format.

The share is: Google Doc 254585 Support Shared Drive

Just to make it clear, it's configured for a FET+1 driver, with a 350 mA 7135 (not 380 mA). This is an important detail for the ramping to work properly. Other ramping tables can be built and used easy enough to support 380 mA chips, or only FET, using TK's utility. In fact I need to modify it myself to work well on one of RMM's SRK 7135 drivers. Also moon mode would need to be changed/tweaked based on what you can use as the lowest PWM value, depending on the driver (FET, 7135 350 or 7135 380).

TK - if you get a chance, you can post it in the repository - your same GPL license that you use is fine. Think it's just an update anyways.

Dutcheee
Offline
Last seen: 2 days 11 hours ago
Joined: 12/19/2015 - 21:40
Posts: 205
Location: Netherlands

Very nice, thank you very much for sharing Tom E! Beer

I just adjusted the code for modes and turbo step-down timings for my DQG mod.
.hex file got compiled just fine.

As soon as I have more time, I’ll swap the R1 & R2 resistors and flash the new firmware.

Anybody knows which 7135 (350 or 380 mA) is on the X6 driver? How can this be determined?

Tom E
Tom E's picture
Offline
Last seen: 27 min 38 sec ago
Joined: 08/19/2012 - 08:23
Posts: 9250
Location: LI NY

I think it's a 350 but not sure. Easy test is in Narsil, set a fixed mode (there are many sets with a max 7135 mode), then measure amps. Of the 350's and 380's we use (most bought from FastTech), the 380 is clearly labeled as 380 while the 350 is not.

Dutcheee
Offline
Last seen: 2 days 11 hours ago
Joined: 12/19/2015 - 21:40
Posts: 205
Location: Netherlands

I just flashed the new Narsil with ramp and replaced R1 & R2 with 220K & 47K resistors. Those 0805’s are some little pieces to solder!

Firmware is great. Ramping is a really nice feature!

I have a few issues though..
On battery check mode, I now get 1-1 blink (1.1V?). On the “old” Narsil before the resistor mod, it worked really accurate.

Also the parasitic drain still reads 0.01A on my UT210E.

Maybe some resistor has got a bad solder joint? Or won’t the driver work at all in that case?

Edit: On 100% 7135 the tailcap measures 350mA, so that should be O.K.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 11 hours 51 min ago
Joined: 01/12/2013 - 14:40
Posts: 4886
Location: (469219) 2016 HO3

The 1.1V blink means an error happened and it couldn’t measure voltage. If you flash battcheck.c onto it, it’ll probably blink out 255 every time. It’s almost certainly a physical problem somewhere on the driver, but I’m not sure where exactly.

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 4 days 3 hours ago
Joined: 01/14/2016 - 16:38
Posts: 540
Location: Germany

Dutcheee wrote:
Also the parasitic drain still reads 0.01A on my UT210E.
Did you remove the bleeder resistor?
And I don’t know if we can trust clamp readings at this little currrents.

Pages