Attiny25/45/85 FW Development Thread

I feel like this might just be a big development. :beer: :+1:

I recommend the cheap ones from ebay, there are several vendors, e. g.:

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.

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.

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 .

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

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

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.

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 ?

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

As a start I would leave CAP_MED unchanged and decrease CAP_SHORT in steps of 10.

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 1x7135 channel) .

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

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

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

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

Ive finally made some sort of firmware for my drivers available: Mike C drivers and X85 firmware.

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. :slight_smile:

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 :slight_smile:

Key/value-list metadata file?? Sounds good to me :blush:

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.

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.

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.

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.

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?

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. :slight_smile:

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

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?

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

No preference. I’ve never used any of those.