Oh, I got that const error too, with both gcc-avr 4.7 and gcc-avr 4.8. I just added the keyword it wanted, and it worked fine. It’s not like we modify the mode list at runtime, so making it const shouldn’t cause issues.
I’m not sure why that particular variable was declared as progmem though… I ended up removing that part too, which simplified access to it, and reduced the overall code size.
I don’t have a fully-working firmware yet though. I broke my SRK’s switch wire by taking the driver out for flashing too many times, and I’ve been too busy to fix it yet. So, that firmware is stalled.
Also, I’ve noticed that my toolchain seems to produce slightly different binaries than the windows-based tools. Not sure what exactly is different, but I think WinAVR may be passing different flags to gcc. Like, some unmodded STAR firmwares compile to like 1040 bytes instead of 1024 or less.
I'm not sure either ;) Another reason why I deserve no credit for this firmware as I'm just picking up stuff as I go. Finally read more about it, and it just frees up RAM space by storing it in the program space (flash memory) instead (attiny13a has 64 byte RAM, 1024 byte program storage). So it really doesn't matter in the case of STAR_no_ramp because the program is only 736 bytes, but it becomes an issue when you start adding extra functionality. This weekend I'll remove it, test it, and change version numbers of the program on my site. Maybe I'll finally create a GIT repository as well so you guys can see what all changes were made between versions.
This weekend I should hopefully get around to finally adding the ability to define PWM modes (fast-pwm vs phase correct) per mode, and add the ability for a second PWM output in case, for example, you want to drive just one 7135 in moonlight mode. Hopefully it can be done, we'll see. The problem with changes like these is the four programs I have out on my site are all slightly different and require testing, with some of them already pushing the limit on program space :( It will then be confusing if one program has the new features but the others don't, as I'm sure that will be the case here.
For open-air testing out on the bench, just ground whichever pin at the MCU (or the switch pad on the PCB) with tweezers. Because of stuff like breaking wires when assembling/disassembling a bunch of times while testing, I solder wires to the input side of the driver and use an external battery box with alligator clip leads until I'm nearly sure it's ready for final assembly. I also do that for the reason that on these press-fit drivers, they get a little less tight each time you remove them, so try to keep that to a minimum.
Should I add any links on my firmware page (http://www.jcapsolutions.com/flashlights/firmware/) to other sources of information on aquiring a programmer, how to flash, Attiny13a pinout, etc.? If you have any ideas on links shoot them my way, since I don't even know of all of the resources out there. Then hopefully the page can kind of be a point of entry for people new to this.
That would be nice!
I now have a courui driven @3amps with srk no ramp Firmware. If I decide to use a fet nanjg, should I make any changes to Firmware?
The FET drivers will start working down at lower PWM values than 7135 drivers... FETs light up all the way down at 1 or 2, 7135s require a minimum of 5 or 6 for the lowest mode. Other than that, everything else in the firmware works the same.
For FET drivers without an inductor (if you don't know what that means then you don't have one) I use PWM levels of 0,1,6,20,56,120,255.
For what it’s worth, I’ve already created a DVCS repo with STAR in it, among other firmwares. I’ve been really busy trying to get a house sold during off-work hours so I haven’t added everything I want to it yet, but it’s supposed to go on the market tomorrow and free up a lot of time. Anyway, that project/repo is here:
It’s using bzr+Launchpad instead of git+GitHub, but it’s mostly the same idea. LP has more features but isn’t as popular.
In the repo itself, I have each version of STAR I could find, NLITE (some other DrJones projects coming soon), MikeC01’s STAR derivatives, my own STAR derivatives, example code from tterev3, some info on how to get started, convenience scripts, etc.
So, I have some questions:
Can several of us share a code repository to make things simpler for everyone else?
If so, is Launchpad okay or should we move it elsewhere?
To explicitly prevent/avoid any copyright issues, could we add some type of open-source license to as much of the code as possible?
Looking at the ATtiny13A datasheet it looks like 20 mA is about the most you can get out of the pins directly, so you would need to use some type of relay (like the 7135 acts as) to drive a fan. If you're wondering what pins can output, on the NANJG driver stars 2 through 4 can be configured as outputs.
I think the spec is 40ma max per output, 200ma max for all outputs. But the answer is yes, you have multiple outputs available on the MP. However, the code would not follow anything we’ve worked with yet.
I like the idea of mixing output pins to come up with more complex flash patterns. Seeing how the MP is “generic”, you really have to work from the ground up to integrate your specifications.
That little chip can do a lot. Just don’t overlook what has already been developed in the stock drivers. Some features are not mentioned very often in these threads, like the 2.8V/cell dropout protection where the drivers goes into a low output slow flash. A feature that is a mode onto itself.
It will not run a relay, you'll need a small FET. Depending on the load you're driving the fet could run it directly or be used to control the coil on a traditional mechanical relay. The MCU does not have any temperature sensing ability though, so it would probably be best to use a separate fan controller with its own thermistor.
I think (wink wink nudge nudge) someone is working on the bits to plug into STAR momentary use the unused PB4/PB0 (pins 3 & 5) to power battery level indicator LEDs... they're very low current, able to be powered directly by the MCU. Once the code is worked out it can be tweaked to make those pins do other stuff.
So this is a little sneak peak of the tiny changes I made to the SRK_no_ramp firmware to utilize the 2nd star for a PWM output as well as the normal output. Also you can set the...hold on a sec, I was just testing it again and now have a blank spot in the middle of my vision. Ok, I can see what I'm typing again. You can set PWM mode/function by each individual mode as well. This will allow you to, for instance, run (with a custom board or added wiring to the 105C) moonlight mode using phase correct PWM off of a single 7135, and then have every other mode run off all 7135's using fast-PWM.
I'm SURE this has been documented before on this site, I was just surprised what little changes it took to work. I'll be polishing up the code and have RMM take a run at it before I release it.
Note: I didn't try a real moonlight mode here. Later I set the PWM value to 2 and it barely glows.
I finally put together a Github repository. Here's a link to the "dual pwm" branch where so far I've added the PWM features to STAR and STAR_momentary. They have been (mostly) tested. But if someone wants to give them a shot, or maybe just pull the new logic in for their own use, obviously feel free.
Speaking of which I've finally named my programs a little better. STAR_momentary instead of SRK_no_ramp, and STAR_dual_switch instead of DualSwitch. I'll update my site sometime to change the names and point to Github for the downloads.
Oh my gosh. I just tried the STAR momentary without ramping with Tom E's modifications. Wow, love it. High, Low, Strobe, all available at start up. Can go up, down, to strobe, or off from anywhere. Very reliable and consistent behavior. Quite impressive.
The only improvement I can think of is to add an SOS mode. It can potentially be a life saver. Maybe only available from Strobe with another long click or or 2 fast clicks.