Attiny25/45/85 FW Development Thread

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.

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.

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?

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.

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.

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.

Did you remove the bleeder resistor?
And I donā€™t know if we can trust clamp readings at this little currrents.

Not that Iā€™m aware of ā€¦ Thanks, I guess I kinda missed thatā€¦ How do I recognize the bleeder resistor?

It also sporadically jumps modes now, for example from moon to a high modeā€¦

At the banggood X6 driver it goes from the LED+ pad to ground, labelled 471 which means 470 Ohms.
How many amps does your mod pull at turbo?