I tried that, actually. I think itās a matter of compile options, but for me it made no difference at all in the size or content of the build. But if it helps at least sometimes I donāt mind making it default.
Here is what I see when building it (same with/without inline):
Weird - just tried it again, and the difference is 48 bytes saved - 984 with inline, 948 without. I'm using Atmel Studio 6.2, and the -Os option is specified.
The important option there was ā-c -std=gnu99ā. I added this to my build script and am now getting the same results you are. This also has reduced the size of every firmware Iāve tried so far, so Iām leaving it in as a permanent thing.
This also saved enough room to let the full config mode fit into the blf-a6 firmware without having to remove anything.
The only firmware change I can think of which might be relevant is to change FAST_PWM_START to 255, to force it to use phase-correct PWM. But this would likely only change the numbers by a tiny tiny amount (like half a percent).
The rest is probably due to hardware. You might want to try bypassing springs, checking your measurement setup, using thicker wires anywhere possible, using a hotrod cell, etc. Might also be worth checking to make sure the light hadnāt already stepped down from maximum when the measurement was taken.
The emitter type and vintage makes a big difference tooā¦ if itās a recent XM-L2 it might not be able to go as high as an older XM-L2, for example.
Iām not sure what the best practices are for high-amp measurement, but it seems like most people prefer to use a clamp meter and thick short wires and it probably doesnāt work as well to use a traditional DMM on an open tailcap. I recall a lot of discussion about this on the BLF X6 thread, and how hard it is to accurately measure amps. It might be easier to measure lumens instead.
I use this method on the 84 and 85 as it has 512 bytes. I already have an array of 16 bytes full of different settings not that are changed unless user enters the user programming mode, so before this array gets filled up with the stored settings I use it for looping through as described to find the mode bytes.
On the 13A Iād go withToyKeeperās suggestion. There is no need for the array really, just use a single byte. You wonāt notice any difference in start-up speed, takes less space to program and uses less RAM.
Thatās really strange. Iām not as familiar with STAR; I only changed what was necessary to make it work as a 1-mode driver.
Looking again, I see one other thing which could make things a little weird. STAR sets alt PWM (in set_output()) to the same value as the primary channel (regardless of whether itās compiled to use dual PWM), so itās turning on both channels on a 2-channel driver. In my blf-a6 tests I found that turbo is actually brighter with only the FET channel ā turning on both the FET and 7135 causes lower output. So if youāre using a 2-channel driver it might be that the 7135 is actually getting in the way.
More generally, Iām not certain itās a good idea to run at full direct-drive amps on a 1-mode light, unless you make the turbo timeout really short. If itās mounted on a weapon, thereās no skin contact so nobody would notice if it gets really hot.
Wow, interesting... Not sure if the Studio IDE set that somehow by default. It's in the Compile "Miscellaneous" settings. When I create new solutions/projects, I simply copy a previous to begin with.
I was thinking about doing it byte by byte but thought it would be too slow so I went with a 8 byte array instead. I got plenty of space in ram anyway but I may switch later when my flasher arrives. But i donāt want a noticable boot time in my driver.
Edit: Using an array was a bit tricky with a weird pointer to the eeprom adress. Must get my flasher to confirm I got it right.
The attiny13a is running at 4.8 MHz. It only takes a few clock cycles to check each eeprom byte, and there are 64 bytes. Letās say it takes a dozen cycles each; thatās 768 cycles, which should take about 0.16 ms total. The data sheets suggest an array might save about four clock cycles per byte, but itāll still be roughly 0.1 ms.
Can you feel a boot-up difference of 0.05 milliseconds?
In general, yes, phase-correct PWM is a good idea on the highest level. It doesnāt usually make any noticeable difference, but itās nice to make the code default to phase-correct to account for the few cases where it matters. I donāt think the hardware has a default; you have to explicitly tell it to generate pulse waves because those pins can also serve other functions.
Well, the timer is set to arround 1.5minutes- then it ramps down to 50%, the FL body gets only warmer this way ā¦.plus when its mounted on a weapon it lights for usualy 10 seconds tops- i use simple momentary on self made remote switches, made from thick Cu pads: found that those are most reliable, especialy with all that forest fog and moisture
The 7135 thingā¦ā¦you might be right, i have to try the 024 version out then
Once again, 10x for that 1mode version, i waited for this long time
Most likely not. But, you can have all the mhz in the world, if itās slow reading from eeprom itāll still be slow. Look, Iām not saying itās too slow reading byte by byte. I thought it was faster reading 8 byte blocks but if it works reading byte by byte that is a simpler solution.
Ish. I normally use phase-correct on moon and turbo, and use fast for everything between. The pulses are longer with phase, which makes moon more stable (drops less with voltage).
But if it doesnāt bother you, you could use phase everywhere. I donāt like the whining sound or visible flashing, but not everyone is sensitive to those.
Getting rid of buzzing pwm modes are my main motivation for writing my own firmware. But was thinking about something else. How do the different sleep modes work? SLEEP_MODE_IDLE just seems to be doing more or less nothing. Iām more curious about SLEEP_MODE_PWR_DOWN though. Does it turn off the output? If you run a special mode like ie strobe it could be a bit tricky to turn it off manually otherwise. You only got a few bytes to play with so would be nice if output is turned off automatically when going to SLEEP_MODE_PWR_DOWN.
TBH, I havenāt really optimized much for sleep mode. I have some relevant patches waiting for me to merge and test, but I havenāt done it yetā¦
In sleep mode the PWM counter stops, but I havenāt specifically tested to see what that does when I donāt set it to zero first. I expect the emitter would stay on if itās not turned off before entering sleep (which is a trick I use for the standby light on my Roche F6, but first I set it to a special non-PWM low mode).
Interrupts can wake up the MCU from sleep mode, if they are enabled and a relevant event happens. Touching the e-switch is one example, or the watchdog timer can do it too. So for low-power shutdown itās usually a good idea to disable interrupts too. On e-switch standby though, at least the switch interrupt needs to stay on.
Hey thanks for the tip. By adding c99 to the makefile and using inline for a few functions that only run once I managed to save 40 bytes. It looks like c89 is the default you get. Using c11 didnāt change anything for me though.
Sorry, Iām still a total noob at this. Is this close to what would need to be done? The purpose is for my XinTD X3, i want to have one mode group for 18650, and one for use with 3x alkaline AAās. So I donāt need LVP for the AAās.
What is the lower PWM limit where you switch between phase-correct and fast?
Interesting. I never looked at the E-switch versions of Star. I coded my own E-switch routine by changing the watchdog timer to the fastest and have the switch test in my main while(1) loop. It may have made the logic pretty easy but I guess itās not a power efficient way of running things as my entire main routine with voltage monitoring and all gets executed a whole lot more. Has anyone done any tests? Or maybe this stuff can be found in the datasheets, havenāt looked at MCU power consumption at all.
