Attiny25/45/85 FW Development Thread

Thanks. Basically what I’ve done is do a voltage check on startup for off time, start the watchdog interrupt to highest 16ms, in the watchdog interrupt I do a temp check, restart ADC and then do a voltage check which covers E-switch and cell voltage. If the voltage is 0 (or very close to it) the the E-switch is pressed because it shorts to ground.

With the voltage divider resistors high enough and with very different values there is a measurable difference between the caps charge time and discharge time, allowing me to get off time readings on startup that are much lower than voltage readings during normal operation. R2 of the voltage divider works as a bleed resistor to the off time cap, so it has to be pretty high. I’m using 1500K as R1 and 300K as R2. I have to delay the normal voltage check slightly after each E-switch press in order to wait for the cap to be fully charged again or the cell voltage reading is too low.

I’ve got more testing to do to see high this works with lower voltages when the cells are nearing depletion, and also maybe temperatures will screw it up further. A few quick tests on difference voltage levels seems ok, but haven’t tried out under high temps. Looks good so far though, and requires no additional components, only higher values on the voltage divider resistors. Accuracy for off time measuring isn’t as good but so far I’ve been able to reliably detect quick off and medium quick consistently, so it appears good enough.

I’ve been reading this thread for a while and my understanding is you guys are trying to make
ATTiny 85 based driver with actual temperature detection (no more turbo timers), e-switch support,
accurate button press timing and possibly more modes (ramping?) and options due to more resources
85 provides?

Please excuse my ignorance. :slight_smile:

Partiallymostly correct, yes. My first goal is more functionality and greater flexibility, but another goal is to make use of the internal temp sensor the 85 has (13A doesn't have it). There's other special use applications the extra program space will give you, plus things like what Mike is doing - multi-use of I/O pins we probably couldn't do before because of limited program space.

I have basically working now combined power switch and e-switch mode changing, so lights like the Warsun X60, EE X6R, and many others can fully utilize both tail and side switch's. I'm mainly working on the e-switch capabilities because I much prefer the better UI's they can offer. Also just got working a config UI for choosing 1 of 8 mode sets, lo-hi, hi->co toggle, and mode memory toggle. Also want to add a side switch lock-out ability to make it difficult for the e-switch to inadvertently turn on the light. I got a quick access to strobe now, but want to make it a full group of hidden/special modes.

Also an advantage will be combining our separate drivers into one code base - the 85 will allow us to do that. Again, I'm almost there with this one driver supporting both an e-switch and tail power switch.

Lots more to do, and would not have this option on the 13A for sure...

I have ATtiny84 firmware I’m using in the drivers I built for these two lights: Mod: BMF SRK v2 Roche Edition (Rebuilt into triple XHP 35 HI) and Mod/Driver: ZY-T08 series conversion, MT-G2..
I’ve done a bit of coding on it since then and have implemented quite a lot of functionality that I really like. Almost everything is user configurable, like the temperature threshold for shutdown, output levels, voltage thresholds, turbo timer, etc. It also has constant current steps of 0.35/0.38 amps, using PWM only between those steps, and this is what uses up the pins. Now I want to use it in my 85 based drivers, but because the 85 has less pins I’ve attempted to move the functionality of three pins over to one pin. It’s working, so I can proceed


I finally made time to get started on new features for a tiny25 clicky-switch driver. So far most of the changes have been oriented toward making the code more portable and abstract, but this should help with adding more features soon.

Tonight’s progress was about abstracting away PWM levels and power channels. So, instead of specifying these directly, the code simply requests a perceptual brightness level of 0 to 64. Or zero to whatever the ramp size is set to. It uses a smooth ramp based on perceptual brightness, which gets translated automatically into PWM levels for each power channel. Aside from making mode definitions shorter and easier, it also provides a foundation for smooth output control for thermal and voltage step-down. And e-switch-based ramping, sometime in the future.

Normally, to get five evenly-spaced modes from moon to max, the code would need to specify PWM levels like 1, 7, 38, 114, 255. Or something more complicated for a FET+1 driver — 0+3, 0+66, 11+255, 88+255, 255+0. But instead, one can now specify 1, 16, 32, 48, 64. Or, with a ramp size of 100, it would be 1, 25, 50, 75, 100. And it works regardless of whether it has one or two power channels.

This isn’t really a user-visible sort of thing, but it makes the rest of what I’m doing a lot easier.

Thanks guys, this clarifies a lot! :beer: I really look forward to all those things getting
accomplished. My electronics knowledge is (currently!) limited to Ohm’s and Kirchoff’s
laws, but I do have some experience with C/C, so I will probably mess around with
your work and try to learn something.

May I suggest that you try Github for code hosting? It would be amazing if
one day all of the open source projects originated here on BLF were hosted
in one place with proper documentation and support.
(I plan on introducing this idea to community, hopefully there will be response)

I think a lot (most?) of the open source code we bump around with on BLF is available in ToyKeeper’s repository. Link is in her signature line. Am I right, TK?

Yeah, but only firmware source code. I was thinking more of a repository for EVERYTHING open source.
Firmware, drivers, schematics, CAD files, 3D models

And I vaguely remember TK saying she plans on migration to Github. Might my imagination though. :bigsmile:

I wouldn’t mind some open source files for drivers so I could adjust and add bits without having to start from scratch on eagle.

^

Big +1.

Pilotdog68 shares his .brd file on OSH Park. His boards look great and I have some on order, but his design approach doesn't use a schematic so you can't move parts and have the traces follow. Nothing wrong with his approach. He seems to be making some very good boards.

trev3 posts his .brd file, but not the schematic file. The rest just post their Gerber files.

Sorry for the off topic, but the above idea is a real good one.

Then I will start drafting proposal for community and exploring implementation options.

There is a reason that most of us don't share our BRD files: it encourages others to learn a higher level of proficiency. Pilotdog may correct me here, but initially he just wanted to make some tweaks of existing driver boards. The unavailability of a complete BRD file made him to learn what he needed to learn to become more proficient.

That makes a lot of sense RMM, i thought it was some copyright thing that the developers of the driver & pcb’s didn’t want other to easily copy there work, change a little thing and call it theirs & sell them or something.

But doesn’t it also raise the bar for entry quite high, if you have to do it from scratch to do it at all?
For example someone found a bug in one of wight’s 12mm driver and because he isn’t available it can’t be fixed, if not someone recreate the same driver without the bug.

And the firmware “scene” seems alive & healthy even if several good open source versions is available, that more inexperienced programmers can tinker with.

EDIT only fixed spelling :wink:

I use GIT @work now and am comfortable with it for the most part, no expert though. Our GIT is on our local network only of course. We use TortoiseGit as the UI. If you can use TortoiseGit as the UI for GitHub, that would be great for me...

It’s hard to know how far I would have gone if I had not had to start from scratch. When I started, I asked RMM for his files and he declined. I was disappointed at first, but in the end it only delayed my progress an hour or two, and it probably saved me many hours of frustration later. Even starting from scratch, it’s not too hard to figure out how to piece stuff together, but it takes a lot of just doing it to start getting things exactly how you want it. Once I started working in eagle more, I started seeing why wight and others placed things in a certain way, and why they ran certain traces in a different way. Looking at wights threads, I also occasionally find something that I would have done very differently. It’s all a learning experience.

I personally uploaded my .brd’s just because I wanted my .zip files to be complete, not as an active attempt to share them to everyone.

I agree that the best way to learn is to watch the videos and start from scratch.

It certainly is the prerogative of any creator to choose not to share the details/info of how an item was created. Furthermore, they should not have to justify their decision. Everyone should respect that.

Regarding learning. Everyone approaches and learns things differently and the community benefits from this. Some like and have the time to start from scratch. I like that method best if I have the time, but life can get in the way. For instance, I have had drivers that I like for the most part. I learned what I needed to change something I didn't like and upgraded. I did not start by taking electronics courses and building drivers from scratch. Doing that enough I can basically build drivers from scratch now. By the time I was done with the GarryBunk bike light I had basically resigned (several times) and built the driver into something that barely resembled the original driver. I still have many gaps in my electronics knowledge that I hope to eventually fill in, but I doubt I would know most of what I know now if I had to start from scratch.

The Attiny25 et al. is another example. I had asked several people why are we sticking with the 13a. They told me it's more complicated than it sounds for various reasons. Some of them started from scratch and that actually seemed to create a barrier for them. I eventually bought some Attiny 45's, took my favorite FW and the data sheets for the 25 and the 13a. I looked up every register, command, and memory reference and substituted in the equivalent from the data sheet from the 25. I still can't create programs in C from scratch, but I learned a lot. Not only that, it opened the minds of some others with real programming knowledge/skill and now many will benefit from my not from scratch efforts.

I could site examples like the above all day long. And that would be just with flashlights.

EDIT:

Regarding Eagle. It is not an intuitive program by any means and I have spend well over a hundred hours on it trying to build driver boards and such. For some reason, the program challenges me more than others. I feel that looking at even one successful Eagle project would help me tremendously.

Part of my problem is all the errors the program reports back to me. I think I have made more of an issue with them than is needed. I say this because when I take one of the OSH Park shared .brd files and run an error routine on it, it lists nearly 400 errors. I haven't used that board but I bet it works fine. Apparently, that creator knew some errors don't matter.

I hear you guys on the Eagle stuff. My recommendation would be to watch Matt's Eagle tutorial videos, walk along with them, and do the steps in your own Eagle program along the way. After that, trial & error and Google are your friends. I, and many others, are also here to help with any issues you may have. I think that walking through the basics yourself gives you a good foundation to build on.

Building boards is a bit different than coding, in that at least putting boards together is visual once you understand the program. Starting from complete scratch with an uC program is an extremely daunting task for someone without a lot of experience.

Regarding Eagle errors: I don't run DRC checks. On the size and complexity of boards we typically do, it's not worth the hassle to get everything set up right to even try and run them. Visually check the board, step away, check again, then just buy a few and test them out. Once you have the boards in your hands you'll know if you screwed up or not. If we were building huge complex circuits it would be of great value to use the DRC, but for our <20 component circuits it really isn't necessary.

First of all, I want to say I have huge respect for what you do. Your shop, community dedication and knowledge. Most other people who hold back their sources do it just for financial gain and you offering gerbers clearly shows that is not the case. You here motivating other people to learn in any way can only be described as noble.
I personaly have desire to learn, and will eventualy get to designing a driver regardles of available Eagle files.
So I guess it’s the same with other people willing to learn, you can’t be really good at something like this unless
you did it all on your own and from scratch fully understanding every step along the way. With this being said,
I think availability of BRD files would be huge. It gives already experienced people better insight into (in this example)
driver allowing them to both improve their knowledge and your product (git pull request in my vision), while noobs like me
can utilize available source in any way imaginable to learn. School would be hell if there weren’t already solved problems and exercises to learn from. There are also small things like having 1mm wider host than driver and no BRD.

You can use anything you like, GitHub is just web interface to command line program, git itself.
You probably wouldn’t need to open GitHub web ever again after you have generated keys for
remote access. I have no real experiece, but making couple pull requests over the time from CLI
was quite intuitive (with some help of man pages).

You have summed it all up really nice. I’m 20 with plenty of time to learn, and everything I learn will be
of use at one point in life or another, plus I study Computer science so it’s closely related to my education.
But imagine having work completely unrelated to anything electronic, having bills to pay, kids and wife
threatening to kick you out if she sees just one more light emmiting thingie in your hands. I highly doubt
learning Eagle would be high on your bucket list.

I think you just did introduce the idea to the community. :slight_smile:

The repository currently uses Launchpad and bzr instead of Github and git. This is because LP/bzr are what I use for everything else, are widely regarded as more intuitive, and because nobody seemed to have a preference when I asked. They are mostly functionally equivalent for BLF purposes, though. LP has a lot more features than Github and git is more popular than bzr
 but we’re not currently using most of the extra features. And I find git’s workflow style rather funky. But ignoring all the UI differences, the main functional difference in their core is that git has no concept of a mainline, and because of this it culturally encourages fast-forwards and rebasing and historical revisionism instead of explicit merges.

But git won the DVCS wars, and it’s the most popular by far, so it might be a good idea to switch if BLF people prefer it. Even Launchpad supports git now, though the support is still a bit beta quality.

Anyway, I’d love to include driver schematics and stuff. I don’t have any circuit design skills though, so I probably wouldn’t be a great curator when I don’t really understand what I’m looking at. And I’m not sure how the licensing on those works
 and then there are all the other issues raised above. I’d prefer to include complete schematics though, despite the advice to start from scratch, because I don’t like to artificially limit anyone’s involvement or raise the barrier to entry.

I can’t really comment on git vs bzr since I haven’t used bzr apart from simple check outs, but as you said git won VCS war (or at least has only a couple of battles left). All the big boys seem to use it (it killed Google code!) and pretty much every open source project that cares about outside contributions. I just spent few minutes browsing your firmware repo and Launchpad seems completely unintuitive. On GitHub everything is easy to find, while on Launchpad even code is somewhat hidden. And social aspect is great. Last semester I had to translate some Ubuntu packages through Launchpad and it was pretty painful experience. With time you can become efficient in any software, but in my case it’s the first couple of uses that determine whether I will run it ever again (if there are other options, of course).

You say you might not be great curator, but that’s what I like the most about GitHub Organizations concept. You have a number of reputable members with full access for commiting code, while
others simply send their contributions for review and inclusion. Everything is simple and transparent. Licences are huge pita, but it should be requirement for authors to include one that requires sharing modifications of original works, while allowing people to use source for whatever they like (GPL?).