Sorry took so long. File size is very deceiving. A .HEX file is Intel HEX format, which is an ASCII format to represent binary data. It's about 3 times the size of the binary data. Not sure you are aware. My version is compile, running in a light easily, using Studio 6.2 (latest, BETA version).
If you open up the .hex file in an editor (NotePad++ for example), it has 43 chars per line, which is one record. For example:
:1002500094E00197F1F700C0000009DFE8CFF894BF
The record is as follows, with all field in hex notation (also known as HEX-ASCII):
":10" header - record size, this means 16 bytes in this record (3 chars)
I can confirm that the unedited source code for the star firmware will successfully compile under the newest Atmel Studio 6.2 Beta.
Here is the compiled size with default optimization settings, Optimize (-O1)
Program Memory Usage : 996 bytes 97.3 % Full
Data Memory Usage : 50 bytes 78.1 % Full
Optimized for size, (-Os)
Program Memory Usage : 958 bytes 93.6 % Full
Data Memory Usage : 50 bytes 78.1 % Full
part of my issue is that im doing all of this on a netbook with a 1024x600 screen so the output window isnt the largest. all i was looking for was the “build successful” at the bottom and not the percent free above.
and then id look at the hex file size and was like “shoot….”.
Got my AVR ISP USBASP USB Programmer from FT, and was finally able to compile, flash AND test the STAR V1.1 on my Banggood Convoy C8 (I did ruin one of the 7135 on the driver when I removed the driver ring but will fix that)
I must say I like this…decent Low Med and High modes very nice (need to solder down star for ML mode), turbo just like high stock, but having it step back from wide open after 2 min is a VERY nice ability
Will definitely be changing out the 1 mode on the 10W P60 dropin in my UF-502B’s and retrofitting a few other lights I have
Really digging this no flashy 4 mode driver, very good!
Plus the ability to reverse the direction from L -> H, by soldering down pin 3 to H -> L…very cool!
I believe this is a very versatile and good firmware!
Well the hex file is the image to be programmed in the Tiny13A, just that it's in a human readable format (expanded in ASCII), and can be easily re-formatted into the binary image the processor (MCU) needs.
I dunno if I'm being too spoon feeding or if this is over everyone's head. I've been doing this stuff for wayyy too many years, so it's extremely obvious to me. Intel hex formats have been around probably since the 70's or early 80's, and I've worked with them maybe since then. The 'S' record format is yet another hex record format made popular by Motorola, similar record structure.
Where things get hairy for us is when you turn ON more options, then maybe the total code size gets too big. For example, I got the TURBO feature turned OFF, so my code size is reduced. You certainly want to set the optimize option to -Os (Optimize for size). In this business, usually the latest version of the compiler is the most efficient and bug free - not always but usually, so I always want to be using the latest version, in this case it's the 6.2 BETA.
This is a very simple compiler compared to many others I've used - some have pages of compiler optimization settings. I've also done a lot of assembly language programming, so I understand what's going on "under the hood", and I've also have been involved in operating systems and device driver development, and compiler/interpreter design methods as well. Recent years has seen most of this software tools development go overseas and quality has gone down as a result in general. Funny because I saw the generations of improvements made over the years, then all that knowledge and skill seemed to have gotten lost, and the 2000's felt more like the early 80's in some respects, but also partially due to rapid advancements in the silicon. Of course I'm extremely impressed with what the Tiny13A has built in. Years past, it would have taken an 8 x 5 inch board with dozen's of IC's to do what it can do, and still not be as fast or as reliable.
So stock
ADC_LOW = 130
ADC_CRIT = 120
is just extra “buffer” in case of variances in resistances for the low volts cutoff? Or do you think a tweaking is in order to get a little bit more oomph out of the batteries
Stock right around 3~vdc it ramps down to a lower current draw level, and at CRIT at 2.8~vdc it shuts off
for “stock” I think that is safe enough…
But excellent research on the voltage levels at each setting…THANKS!
Thanks for reporting those numbers. But like RMM said, reading the datasheet for the Attiny it looks like the chips have a +/-10% variance in their ADC accuracy, so we can't pick one number and have it be correct across all drivers.
I am very interested in getting a driver pre-flashed. I think it’s amazing that someone would offer this service for such a reasonable price. I have a few questions though.
Does the memory mode worh with the optional turbo mode? If I turn the light off in turbo mode before the timer kicks in, will it start up in turbo mode again? If yes, I assume the timer is reset?
And if I run it in turbo mode long enough for the timer to kick in and then turn it off, will the mode memory start it up in high mode or turbo mode (as high mode was not manually selected)?
And finally, is turbo mode the same is the full capacity of the driver? Meaning turbo mode on a 3.04A driver (without added chips) is 3.04A? Turbo = 100%?
Starts in turbo, timed it, timed out 4 seconds before 2 min (my chip might be running fast), 5 modes, turbo w/ timeout, high, med, low, moon.
Memory retains last setting (if I was on med for more than a second or so and powered down, next time I turned it on, came back med) tested it on turbo by cycling thru, after turbo timeout, drop to high, click off, back on in turbo w/ timeout (repeated 4x times to be sure)
I am pondering soldering 2,3,4 with no memory so it starts in turbo w/ timout every time (this will be my go see what made bump in the night throw some mega light on 1st click, but then drop down to lower mode to not use up the batteries and if the kids use it so they don’t leave it wide open and get it too hot setting [if that made any sense])
I wasn’t looking to gain a wee bit more runtime. I’m more concerned about variations due to differences in chips, temperature, etc.
I only have unprotected cells and I want to be confident that they won’t get damaged by overdischarging. Based on my test numbers, I’ll likely bump up the settings for a greater margin of safety.
Of course, I’ll test other drivers as I build them to verify “safe” low voltage operation.
2.75v is probably the most common recommended cutoff voltage in the datasheets for unprotected cells, some cells even get their rated capacity by being discharged all the way down to 2.50v. 2.8v +/-10% is well within the safe range.
Just flashed my EDC Convoy S5, and soldered on the last 2 7135’s to make it a full 8*7135 105C…soldered pins 2 and 3, didn’t solder 4 on this on my “blind the badguy” Convoy C8 (8*7135 105C)
Star 2 = Moon if connected
Star 3 = H-L if connected, L-H if not
Really digging STAR V1.1 firmware (stock compile) in this fashion
The Convoy S5 at 2800mA for 2 min still gets mighty warm, but now with the 2 min turbo timeout, very very nice (stays “warm” instead of getting HOT), and since this is my EDC I went ahead and kept the memory active on this one…
As Warhawk said, it does retain turbo as the last mode even after stepping down to high, and it does reset the timer. And yes, Turbo is just a pwm value of 255 (full output).
And as for the timeout, I realized that the watchdog timer isn't all that accurate either, and it gets extrapolated the more times we have it timeout before we do something.
