Attiny25/45/85 FW Development Thread

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

Bzr is pretty straightforward, especially if you ever used svn, but it might be a little weird from a git background. The first thing to know coming from git is that bzr encourages one directory per branch instead of checking out one at a time in a single shared directory. Then to compare things between branches, use the same regular filesystem-based tools as you’d use for anything else. There is no need to use a vcs-specific tool like one does with git.

The other main difference is it heavily encourages a feature branch workflow. Branch, hack, merge… instead of git’s typical branch, hack, rewrite history, fast-forward. This difference is illustrated in the article I linked earlier, including the commands used. If you’d like to get started, simply install bzr then run “bzr branch lp:flashlight-firmware”.

Finding a curator for circuit designs is a social problem, not a technical one. Is there anyone willing to maintain it, and to actively work toward building the repository? Would you?

As for github organizations, the equivalent in launchpad is groups or teams. Same concept, and it’s easy to set up… but it’s less necessary because Launchpad is organized around projects instead of users. It does a lot of “organization” stuff by default, so groups are only necessary if you want to add a mailing list or assign bugs to an entire team or give multiple people direct write access to trunk. Instead of having people write to trunk, it’s generally recommended to use a merge bot instead, which bases its actions on the results of the built-in code review system. And bugs are an artifact of projects, not users, so there is no need to set aside a special user or organization to act as the center of the branch network. It does the right thing by default.

Despite having quite a few big differences, the two sites are similar enough that either one would probably work fine for BLF purposes. If there is a community consensus to move, it can move. If not, moving would be a lot of effort for very little gain.

About licenses, it is the responsibility of the repository maintainers to respect the wishes of the code authors. Code cannot be added unless it has a compatible license, which is why most of DrJones’ work is not included. Beyond that, it’s mostly a social effort to reach out and ask for permission, and help people understand what the licenses do and why they’re worthwhile, since most people generally would rather not have to care. Adding a strict up-front requirement to use license X to get in the door seems counter-productive, and several large projects have found it slowed development and reduced participation. So I prefer to be as lenient about it as possible.

So, I think there are two open questions:

  • Does the code repository need to move to github? Yes, no, and/or don’t care?
  • Do we have a volunteer to build and maintain a driver circuit repository?

Since you are most comfortable with bazaar, it makes most sense to use Launchpad. But some sort of poll with everybody giving valid point is in order. I did some research and there are ways to push bzr code to git, so we could have GitHub mirror of Launchpad code. That way bzr stays main vcs, but whoever is more comfortable with git has an alternative. I’d hate to see someone wanting to contribute giving up just because of different vcs. And for people who don’t use any, they could just send me code and I’d push it giving proper credits and author info. I’m more than willing to set everything up, maybe I can’t (currently) contribute to code and hardware developement, but maintaining repo, indexing stuff and working out license issues seems perfectly fine. Wiki with info covering everthing that is in repo (driver characteristics, firmware versions, flashing equipment, dev environment, etc.) is imho needed and I would tackle that too. I wasn’t thinking to impose strict license requirements, just to work it out with contributors in whatever way. I think many projects without license show people in general don’t care about it much, so it shouldn’t be huge issue in big picture.

It’s awesome that you want to contribute and help the community. Could you start on gathering the driver info, writing a wiki, etc? It could either be sent as a merge request for the firmware repository, or you could start a new repository. Either one works, and they can be easily merged later if desired.

If you’re interested… There is also missing info in the firmware index/meta files, like the license type and info about whether LVP is implemented, plus more detailed descriptions of each project. The files are in rfc2822/email header format, or basically “Key: Value” pairs with optional continuation after newlines by indenting.

FWIW, git and bzr are so similar that they can directly use each other’s repositories as back ends. In Debian, the packages for this are called git-bzr and bzr-git. There’s also fastimport/fastexport for one-time full conversions between them. It’s quick and easy.

Also BTW, unrelated question… why do you have a bunch of extra line breaks in your posts? It breaks the browser’s text wrapping:

I will first gather everything I can offline and work on documentation, I’ll think about merge vs new repo later. Meta files and descriptions should get some love too.
New semester starts on Monday, so I won’t have much free time compared to now, but I will do my best to do everything I have planned. There should be progress over the next week.

About line breaks, I guess it’s just a bad habbit that I don’t even notice. I had to look twice at your SS to realise what’s wrong. It’s fixed now. :slight_smile:

BTW, if anyone wants to see what I’m doing with a tiny25 MCU (or try it), the code is here:

https://code.launchpad.net/~toykeeper/flashlight-firmware/tiny25

It’s mostly in a new project called “bistro”, for lack of a better word. It’s basically blf-a6 plus a few extras. Today’s main addition was volts+tenths for the battery indicator.

I've been working on and off (no pun intended Wink) on my enhanced version of e-switch, and after the bad ground fiasco, I ran into another frustrating issue, but I think finally this evening I fixed it, very happy now... SmileSmile Btw, the downloading is working like 100% reliable now - best it's ever worked, more reliable then I ever had with a 13A -- never seem to get a bad clip on. Amaz'n what a good ground will do...

TK - haven't had time to look at yours, sorry.

The problem I had was very intermittent, no apparent pattern that I could repeat it with, but it would flake out after switching from hi to OFF - sometimes it worked fine 10x in a row, then intermittently occur, sometimes resulting in a lock-up with the light ON or OFF - bazaar stuff. The changes that fixed it were:

  • eliminate possible redundant back to back output to the TCCR0A register to set PWM mode (FAST or PHASE)
  • clearing of the pressDuration variable in a couple more places, which seemed not necessary

I'm thinking the first fix in more explainable, though I'm not sure why. Then again, I've been testing for only a few minutes, doing all sorts of crazy things and can't reproduce it so far, doesn't mean it's truly fixed yet.

Enhanced features:

  • 8 mode sets to choose from, plus hi->lo option, plus mode memory
  • lock-out feature to disable possible inadvertent clicks (quick sequence of click-click-click&hold for 2 secs)
  • compile time option:

- for e-switch's with a tail power switch, mode settings available off the power switch

- or double blink for power-on (when using a tail lock-out, the blinks will occur to signal battery is connected)

Still need to add some things, but it's beyond a 25 now - needs a 45 or 85 to run.

FYI - my test light has been a SupFire M2-Z I bought from Richard for modding. Wow - what a deal. It's a perfect light for the lock-out feature: it has no tail switch and bare threads so impossible to lockout with unscrewing the tailcap. A 22 mm driver fits fine, has a nice threaded retainer ring, and a wired side switch mounted to the housing (stock driver is not needed. I used long LED wires so I could pop it out and re-program without much of a fuss, and could do basic testing with a battery wired direct to the driver and the driver wired in to the head, giving you full control with the side switch. I swapped the plastic reflector for an alum one (XP-R C8 style), and put in a XP-L V6 3D on a Noctigon - didn't worry bout bypassing springs yet.

I was gonna use a Crelant 7G2CS, but it turned out the driver shelf is way too wide and would interfere with components on the driver - I'd have to machine some material from the shelf (inside the pill) to fix it up. Might be easier to piggyback a driver, not sure yet.

These are the modes:

Mode Set Order

Mode Count

Mode Percentages

Notes

1

5

ml-2-10-40-full

10=max 7135, 40=mixed

2

4

ml-10-35-full

10=max 7135, 35=mixed

3

3

5-35-full

5=1/2 7135, 35=mixed

4

7

TK BLF A6 7 mode

moon plus 6 evenly spread

5

4

TK BLF A6 4 mode

no moon, 4 evenly spread

6

3

ml-10-full

moon, max 7135, max FET

7

2

10-full

max 7135, max FET

8

1

full only

(full is always max FET, no 7135)

I like those mode sets. Looking forward to seeing this stuff included in a light somewhere that we can buy for a budget price. :wink:

Interesting. And cool. And sorry, I haven’t had time to try yours out either. :slight_smile:
(I don’t even have a tiny25 hooked up to an e-switch yet, though I at least have the parts)

What I’m making is a little different… the 8 mode groups are simply 1 to 8 total modes, all evenly-spaced. Separate option for whether there should be a moon mode, so it actually does N+1 modes if moon is enabled. This means the BLF A6 defaults would be group 6 plus moon, or group 4 without moon.

Basically, pick how many modes you want, choose whether to add moon, choose low-to-high or high-to-low mode order, choose whether the “medium press” does reversing or not, choose whether to enable mode memory, choose a maximum temperature… etc. I’m hoping it can cover almost everyone’s preferences. I’m also hoping the missing parts will fit into the ~600 bytes I have left on the attiny25. If not though, I can cut a couple of space-hungry optional extras.