Attiny25/45/85 FW Development Thread

1922 posts / 0 new
Last post
Mike C
Mike C's picture
Offline
Last seen: 9 hours 49 min ago
Joined: 01/22/2014 - 08:03
Posts: 2584
Location: Sweden

Nice to see you’re on track again!

Making some progress myself. I’ve now got the off time cap, voltage monitoring and the E-switch all working on the same pin, and the temperature sensor working also. It requires quite a lot of adaption in the code to do things this way, so porting my 84 firmware to the 85 will be a bit more time consuming. But happy that it works though.

ImA4Wheelr
Offline
Last seen: 1 month 1 week ago
Joined: 02/03/2013 - 14:51
Posts: 7935
Location: SC

Great to hear Tom E.  I recall one wire not being right per the wiki back when I first set up, but I don't recall which one.

It could be just my imagination, but I find the light output at the lower levels seems more pleasant with this MCU.  The output seems more "solid".  They all are running at 8 Mhz.

pyro1son
pyro1son's picture
Offline
Last seen: 7 months 1 week ago
Joined: 03/21/2013 - 08:18
Posts: 432
Location: UK

Mike C wrote:
Nice to see you’re on track again!

Making some progress myself. I’ve now got the off time cap, voltage monitoring and the E-switch all working on the same pin, and the temperature sensor working also. It requires quite a lot of adaption in the code to do things this way, so porting my 84 firmware to the 85 will be a bit more time consuming. But happy that it works though.

That’s brilliant, freeing up pins for extra features like voltage indicator LEDs or extra sets of 7135s. Nice work!!

Pastebin                                      &nbs

Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 14740
Location: LI NY

pyro1son wrote:
Mike C wrote:
Nice to see you're on track again! Making some progress myself. I've now got the off time cap, voltage monitoring and the E-switch all working on the same pin, and the temperature sensor working also. It requires quite a lot of adaption in the code to do things this way, so porting my 84 firmware to the 85 will be a bit more time consuming. But happy that it works though.
That's brilliant, freeing up pins for extra features like voltage indicator LEDs or extra sets of 7135s. Nice work!!

Yes - this is sounding real nice! Nice work Mike!! I think PWM's though will still be restricted to just two pins? Is that still true with this setup?

Mike C
Mike C's picture
Offline
Last seen: 9 hours 49 min ago
Joined: 01/22/2014 - 08:03
Posts: 2584
Location: Sweden

pyro1son wrote:
That’s brilliant, freeing up pins for extra features like voltage indicator LEDs or extra sets of 7135s. Nice work!!

Tom E wrote:
Yes – this is sounding real nice! Nice work Mike!! I think PWM’s though will still be restricted to just two pins? Is that still true with this setup?

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.

vulpes
vulpes's picture
Offline
Last seen: 8 months 3 days ago
Joined: 08/20/2015 - 17:15
Posts: 300
Location: Bosnia and Herzegovina

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

Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 14740
Location: LI NY

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

Mike C
Mike C's picture
Offline
Last seen: 9 hours 49 min ago
Joined: 01/22/2014 - 08:03
Posts: 2584
Location: Sweden

vulpes wrote:
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?

I have ATtiny84 firmware I’m using in the drivers I built for these two lights: http://budgetlightforum.com/node/41786 and http://budgetlightforum.com/node/40759.
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…
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 16 hours 54 min ago
Joined: 01/12/2013 - 14:40
Posts: 10761
Location: (469219) 2016 HO3

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.

vulpes
vulpes's picture
Offline
Last seen: 8 months 3 days ago
Joined: 08/20/2015 - 17:15
Posts: 300
Location: Bosnia and Herzegovina

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)

DavidEF
DavidEF's picture
Offline
Last seen: 2 weeks 6 days ago
Joined: 06/05/2014 - 06:00
Posts: 7699
Location: Salisbury, North Carolina, USA

vulpes wrote:
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?

The Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy

vulpes
vulpes's picture
Offline
Last seen: 8 months 3 days ago
Joined: 08/20/2015 - 17:15
Posts: 300
Location: Bosnia and Herzegovina

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:

pyro1son
pyro1son's picture
Offline
Last seen: 7 months 1 week ago
Joined: 03/21/2013 - 08:18
Posts: 432
Location: UK

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.

Pastebin                                      &nbs

ImA4Wheelr
Offline
Last seen: 1 month 1 week ago
Joined: 02/03/2013 - 14:51
Posts: 7935
Location: SC

^

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.

vulpes
vulpes's picture
Offline
Last seen: 8 months 3 days ago
Joined: 08/20/2015 - 17:15
Posts: 300
Location: Bosnia and Herzegovina

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

RMM
RMM's picture
Offline
Last seen: 1 year 7 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

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.

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

cajampa
Offline
Last seen: 5 years 3 months ago
Joined: 08/01/2014 - 01:55
Posts: 1963
Location: Sweden

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

Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 14740
Location: LI NY

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

pilotdog68
pilotdog68's picture
Offline
Last seen: 6 months 3 days ago
Joined: 05/30/2013 - 23:31
Posts: 6422
Location: Held against my will in IOWA, USA

RMM wrote:

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.


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.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ImA4Wheelr
Offline
Last seen: 1 month 1 week ago
Joined: 02/03/2013 - 14:51
Posts: 7935
Location: SC

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. 

RMM
RMM's picture
Offline
Last seen: 1 year 7 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

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.

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

vulpes
vulpes's picture
Offline
Last seen: 8 months 3 days ago
Joined: 08/20/2015 - 17:15
Posts: 300
Location: Bosnia and Herzegovina
RMM wrote:

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.

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.

Tom E wrote:

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…

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

ImA4Wheelr wrote:

…but life can get in the way.


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.
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 16 hours 54 min ago
Joined: 01/12/2013 - 14:40
Posts: 10761
Location: (469219) 2016 HO3

vulpes wrote:
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 you just did introduce the idea to the community. 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.

vulpes
vulpes's picture
Offline
Last seen: 8 months 3 days ago
Joined: 08/20/2015 - 17:15
Posts: 300
Location: Bosnia and Herzegovina

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

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

vulpes wrote:
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?

vulpes
vulpes's picture
Offline
Last seen: 8 months 3 days ago
Joined: 08/20/2015 - 17:15
Posts: 300
Location: Bosnia and Herzegovina

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.

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

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:

vulpes
vulpes's picture
Offline
Last seen: 8 months 3 days ago
Joined: 08/20/2015 - 17:15
Posts: 300
Location: Bosnia and Herzegovina

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

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

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.

Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 14740
Location: LI NY

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)

 

Pages