i just tried toms revision of the code. it comes out at 1.73k
Gotta be something on your end then, but I don't know what it is. I would try downloading version 5.0 and try again.
ok. is 5.0 from atmel working unlike 5.1?
I was wrong in my earlier post, I am running 5.0. Thought I was using 5.1. I am running this version on Windows 7 x64, downloaded from Atmel: 5.0.1163.
ok ill try it
Yeah… for some reason I had the same issues with compiling on 6.1, used comfychairs “howto: Use Atmel AVR Studio 5.1 to make a .hex file” and now they all compile like a champ!
I had to download the version from his link though…not sure why it doesn’t work on 6.1 but works fine on 5.1
I have a shared repository of the STAR firmware and a few custom builds as well
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)
- "0250" address field (4 chars)
- "00" think this is a record type (2 bytes)
- "..." 16 bytes of binary data (32 chars)
- "BF" record checksum (2 bytes)
The entire hex file:
:100000000CC024C033C022C021C020C01FC01EC0ED
:100010005AC01CC000050F5CFF0011241FBECFE9B1
:10002000CDBF10E0A0E6B0E0E2E6F2E002C005904D
:100030000D92A236B107D9F720E0A2E6B0E001C0E8
:100040001D92A736B207E1F7DBD009C1D9CF96B32D
:1000500093FB992790F981E0982780916300880F9E
:10006000892B809363008F7090E008951895F89421
:10007000A89584B7877F84BF81B5886181BD11BC95
:10008000789410926500E3DF892B39F08FEF9AE4C2
:100090000197F1F700C00000F6CF8BB780628BBFED
:1000A00085B7806285BF889585B78F7D85BF8BB703
:1000B0008F7D8BBFF894A89581B5886181BD80E460
:1000C00081BD789408951F920F920FB60F9211245C
:1000D0002F933F934F935F936F937F938F939F9350
:1000E000AF93BF93EF93FF93B2DF892BF1F0809131
:1000F00065008F3F29F0809165008F5F80936500D8
:1001000080916500803169F480916600811102C0A0
:1001100084E003C080916600815080936600109255
:1001200064008CEB809360005AC0809165009091D0
:1001300064008823A1F080916500803180F4809173
:1001400066008F5F80936600853010F01092660025
:100150009B3410F010926600109264003EC081E063
:10016000890F09F48FEF80936400809160008823E9
:1001700019F08150809360008091600081112DC042
:10018000349B16C025B130E080916600813019F4AF
:1001900085E790E002C082E890E02817390734F440
:1001A000809162008F5F8093620002C010926200B3
:1001B00080916200843080F080916600811102C0DD
:1001C00084E003C0809166008150809366001092A5
:1001D00062008CEB80936000369A10926500FF916C
:1001E000EF91BF91AF919F918F917F916F915F91AF
:1001F0004F913F912F910F900FBE0F901F90189528
:1002000017BA89E188BB88E085BB82E087BB81E2C1
:100210008FBD81E083BF81E687B9A29A86EC86B95B
:10022000479A85B7877E806185BF21DFC0E08091D6
:1002300066008C17E1F3C0916600E0916600F0E083
:10024000EC5EFF4FE491E9BD89B58111F0CF8FEAF3
:1002500094E00197F1F700C0000009DFE8CFF894BF
:02026000FFCFCE
:02026200BC00DE
:00000001FFFor the amount of real memory it will take, look at the second to last record: address of 262 hex for length of 2 bytes, therefore total file size:
264H, which is 612 bytes
So, plenty of space left over, because 1,024 bytes is available for program space. This match's what shows in the .map file exactly.
Under 6.2 BETA, the created binary was 4 bytes smaller than under 6.1 I believe.
That might have been why I was getting 1,032 on my compile in 6.1 (101.6% max capacity…DOH) which led me back to 5.1…hmmmm
I’m going ahead and installing 6.2 beta, and see if it compiles under the size limit, if not I will try AVR Studio 5
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
so the hex file format isnt necessarily the exact data that is programmed to the tiny13a? gotcha.
maybe my stuff was fine then. i just saw 1.83k for the file size of the created hex and was like “hmmm this wont fit.”
programming isnt really my strong suit though i eventually muddle through. 
brian
sorry fellas, im a dufus.
my files were fine.
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….”.
all is well now.
brian
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.
i understand, thanks. im used to .bin files for my cars computer stuff that i reprogram, i didnt realize that .hex was a somewhat different critter.
Brian
Did a bit of testing on low and critically low voltage levels tonight.
With ADC_LOW = 130, step-down began at 2.961V
With ADC_LOW = 125, step-down began at 2.89V
With ADC_CRIT = 115, cut-off warning began at 2.777V
Tests were repeated a couple of times, using a variable bench supply, Qlite w/Star1.1 and a Fluke 87 (true RMS) voltmeter.
I estimate maybe +/- 2.5mV variation in my readings.
-JW
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!
Here's what you'll find: each driver is quite a bit different in where the low voltage cutoff is. Don't expect each one to be the exact same.
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.