STAR Firmware by JonnyC - Source Code and Explanation

1335 posts / 0 new
Last post
Hoop
Hoop's picture
Offline
Last seen: 15 hours 2 min ago
Joined: 12/20/2012 - 05:33
Posts: 1036
Location: Spokane, WA

Just tried offtime-no-memory. It is exactly what I am after. The general public would probably appreciate that simplicity, I figure.
I’m using a low of “6” with fast pwm. Seems to work pretty good. Is there a limit to how low I can make low before there is some kind of issue?

wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

Hoop wrote:
Just tried offtime-no-memory. It is exactly what I am after. The general public would probably appreciate that simplicity, I figure.
I’m using a low of “6” with fast pwm. Seems to work pretty good. Is there a limit to how low I can make low before there is some kind of issue?
The lower limit depends on hardware. Driver, LED, and [potentially] input voltage.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

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

In general, for a nanjg driver with current-gen LED the lowest is about 6 (fast) or 4 (phase). For a FET driver the lowest is generally about 1 (phase) or 0 (fast, with some caveats).

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

It also depends greatly on the number of 7135s (the higher the number, the higher the stable PWM value), the batch of 7135s (they vary from batch to batch, and even within batches), and whether the 7135 is a 350mA or 380mA (350mA can generally run at a lower stable value). 

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

HighEfficiency
HighEfficiency's picture
Offline
Last seen: 4 years 2 months ago
Joined: 02/05/2014 - 11:33
Posts: 74
Location: USA

Is reverse polarity protection something that is physically built into the circuit or something that is handled via firmware? Doing a S2 build for my wife with a 105c and STAR and wanted to make sure that it stayed in.

Thanks

Mike C
Mike C's picture
Offline
Last seen: 2 days 14 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2578
Location: Sweden

HighEfficiency wrote:
Is reverse polarity protection something that is physically built into the circuit or something that is handled via firmware? Doing a S2 build for my wife with a 105c and STAR and wanted to make sure that it stayed in.

Thanks


It’s physically built in. It’s a diode.
HighEfficiency
HighEfficiency's picture
Offline
Last seen: 4 years 2 months ago
Joined: 02/05/2014 - 11:33
Posts: 74
Location: USA

Many thanks.

Tom E
Tom E's picture
Offline
Last seen: 10 hours 2 min ago
Joined: 08/19/2012 - 08:23
Posts: 14629
Location: LI NY

ToyKeeper wrote:
Offtime-no-memory is my favorite configuration. Smile Basically, I set it up so that a short press goes to the next mode, a medium press goes to the previous mode, and a long press goes back to the first mode. It thus always starts in the first mode, and can navigate in two directions. If the user goes backward from the first mode, it enters some semi-hidden "negative" modes like turbo and battery check.

Is this version posted in your repository? Think I went look'n - not sure I could locate it. So... Are you saying you are using 3 level values for reading the cap to determine the short/med/long press's? If so -- is this reliable? Standard value OFF time cap used, etc.? If it's reliable, wouldn't JC incorporate it into this? Maybe he doesn't feel confident, or maybe just no time to do it yet, or maybe he doesn't care for this feature?

 If it's a mod of JC's OFFTime, is it based on his latest 1.3 version?

This sort of seems like it works like the "werner" style e-switch firmware. I make the long hold do a strobe typically. I think the OFF time style med and long press's though would be a little more tricky/finicky then a simple button hold for an e-switch, maybe?

Only a couple of questions.... SmileInnocent

wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

Tom E wrote:

ToyKeeper wrote:
Offtime-no-memory is my favorite configuration. Smile Basically, I set it up so that a short press goes to the next mode, a medium press goes to the previous mode, and a long press goes back to the first mode. It thus always starts in the first mode, and can navigate in two directions. If the user goes backward from the first mode, it enters some semi-hidden “negative” modes like turbo and battery check.

Is this version posted in your repository? Think I went look’n – not sure I could locate it. So… Are you saying you are using 3 level values for reading the cap to determine the short/med/long press’s? If so — is this reliable? Standard value OFF time cap used, etc.? If it’s reliable, wouldn’t JC incorporate it into this? Maybe he doesn’t feel confident, or maybe just no time to do it yet, or maybe he doesn’t care for this feature?


 If it’s a mod of JC’s OFFTime, is it based on his latest 1.3 version?


This sort of seems like it works like the “werner” style e-switch firmware. I make the long hold do a strobe typically. I think the OFF time style med and long press’s though would be a little more tricky/finicky then a simple button hold for an e-switch, maybe?


Only a couple of questions…. SmileInnocent

I haven’t used it, but I just can’t see the short/long press navigation being half as user friendly as an e-switch. With the e-switch you do a long press by holding the button until something happens. You do a short press by hitting it and letting go. Both pretty straightforward actions. Now when it comes to “how do I turn this thing off?”… the clicky may have an advantage. Wink

I’ll still give this business a try, I want to see what it’s all about.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Tom E
Tom E's picture
Offline
Last seen: 10 hours 2 min ago
Joined: 08/19/2012 - 08:23
Posts: 14629
Location: LI NY

wight - yes, agree: think the e-switch would be more user friendly. In "my special" e-switch version, once you lock in a mode (like 1 sec or so), one short click turns the light OFF - best solution I could come up with Smile. I had to have a 1 click OFF UI and this seemed to be pretty easy to implement. VOB loves it - got maybe a couple other BLF'ers using my e-switch version around... I really though it was super clever/cool/nifty, and I don't say that bout much I do lately... Smile

A side effect function of this, is if the light is ON and locked in and you do a button hold, the previous mode switch will still work, then you can go fwd in modes with short clicks until you pause/delay again to lock it in. So, even thoug you got a simple 1 click OFF, you can still navigate through all the modes without turning the light OFF (unless you are already at the first/lowest mode already).

Edit/Update: Dang wight - forgot... Just built a S2+ shorty (18350) using a triple XP-G2 3C and your 17mm DD driver (A17DD-S08) with JC's OFFTime latest driver - came out really sweet!! Love your DD drivers for having the clean spring side - simple with the Convoy tube lights. I even scraped off around the spring pad to widen it so I could use the stock spring the S2+ host (from RMM) came with -- again, simple and sweet! Thanks Again for these great driver designs!!!

JonnyC
JonnyC's picture
Offline
Last seen: 4 months 4 weeks ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

I haven't given it a shot yet.  Sounds pretty cool, but for me I only ever have 3-4 modes, so it's not needed.  I'm at max capacity on STAR_off_time, so features would have to be disabled in order to enable this.  I think just having ToyKeeper's custom offshoot is the way to go, unless it really is that intuitive that everyone would want it.

Tom E
Tom E's picture
Offline
Last seen: 10 hours 2 min ago
Joined: 08/19/2012 - 08:23
Posts: 14629
Location: LI NY

Ohh - I used your latest STAR-Off_time verison for the 1st time and got a bit confused over "DUAL" PWM support. I finally figured it out after seeing how the conditional compile switch's were being used, but would have saved me time if I could have understood it better from the descriptions/docs. I was thinking DUAL PWM mode was phase controlled and fast, as opposed to DUAL outputs, so had me going for a while...

Also, maybe it wasn't so clear to me, but finally understood it by again, going through the code. I think in the prior versions TURBO would knock down to the previous mode in the mode table, but now, it knocks down to a set value, not in the table. I definitiely prefer the way you have it implemented now. I always thought the TURBO step-down setting should be an accessible mode and take up another mode setting. Think the BLF SE X6 driver works the old way which I can't stand - seems a waste of a mode, more clicking, etc.

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

Tom E wrote:

Is this version posted in your repository? Think I went look’n – not sure I could locate it. So… Are you saying you are using 3 level values for reading the cap to determine the short/med/long press’s? If so — is this reliable? Standard value OFF time cap used, etc.? If it’s reliable, wouldn’t JC incorporate it into this? Maybe he doesn’t feel confident, or maybe just no time to do it yet, or maybe he doesn’t care for this feature?


 If it’s a mod of JC’s OFFTime, is it based on his latest 1.3 version?


This sort of seems like it works like the “werner” style e-switch firmware. I make the long hold do a strobe typically. I think the OFF time style med and long press’s though would be a little more tricky/finicky then a simple button hold for an e-switch, maybe?



Yes, it’s in my repo. It’s ToyKeeper/cypreus. However, that version is a little complicated and I need to make a simpler branch which is closer to STAR. It was originally based on an older version of STAR, but I did a lot of weird stuff to it (like a PFM self-adjusting moon mode for FETs, and lots of blinkies).

The timing and behavior is actually pretty reliable, and not terribly difficult to use. I ended up with values of 190 and 100 to differentiate between short, medium, and long presses (< 0.5s, 0.5s to 2.0s, > 2.0s).

In any case, when I have hardware again in a few days, I’m hoping to make a more generic version which is easier to configure. I may even be able to add some things into STAR, but it’ll require making room and that might not go smoothly.

wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

Tom E wrote:

wight – yes, agree: think the e-switch would be more user friendly. In “my special” e-switch version, once you lock in a mode (like 1 sec or so), one short click turns the light OFF – best solution I could come up with Smile. I had to have a 1 click OFF UI and this seemed to be pretty easy to implement. VOB loves it – got maybe a couple other BLF’ers using my e-switch version around… I really though it was super clever/cool/nifty, and I don’t say that bout much I do lately… Smile


A side effect function of this, is if the light is ON and locked in and you do a button hold, the previous mode switch will still work, then you can go fwd in modes with short clicks until you pause/delay again to lock it in. So, even thoug you got a simple 1 click OFF, you can still navigate through all the modes without turning the light OFF (unless you are already at the first/lowest mode already).


Edit/Update: Dang wight – forgot… Just built a S2+ shorty (18350) using a triple XP-G2 3C and your 17mm DD driver (A17DD-S08) with JC’s OFFTime latest driver – came out really sweet!! Love your DD drivers for having the clean spring side – simple with the Convoy tube lights. I even scraped off around the spring pad to widen it so I could use the stock spring the S2+ host (from RMM) came with — again, simple and sweet! Thanks Again for these great driver designs!!!

I do very few builds myself, I do plan to try out your UI absolutely ASAP on my next momentary build. The first time I heard it described I was uninterested. The next few times got the wheels in my head turning a little. Wink

As far as the dual-PWM functionality in STAR, part of the reason it’s confusing is because both of the features were merged into mainline at once: the ability to use both fast and phase correct PWM in one firmware as well as the ability to output an “alt” PWM signal on an extra pin for the “moonlight special” style drivers. JonnyC has packed a bunch of great features in here at this point, but there’s limited documentation as to the what/why/how of using them. I’ve been thinking that I should do a writeup on how to use the firmware, complete with all features and what’s required to take advantage of them. So far I’m just too lazy.

I’m glad that the driver is working well for you! If you have thoughts on how large would be ideal for the default spring pad, please post over in the driver thread. I chose pretty arbitrarily. I’ve been thinking of doing a different kind of spring pad pattern in order to make it easier to center & solder different springs, but in the meantime…

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 20 min ago
Joined: 01/12/2013 - 14:40
Posts: 10731
Location: (469219) 2016 HO3
Tom E wrote:

In “my special” e-switch version, once you lock in a mode (like 1 sec or so), one short click turns the light OFF – best solution I could come up with Smile. I had to have a 1 click OFF UI and this seemed to be pretty easy to implement. VOB loves it – got maybe a couple other BLF’ers using my e-switch version around… I really though it was super clever/cool/nifty, and I don’t say that bout much I do lately… Smile

A side effect function of this, is if the light is ON and locked in and you do a button hold, the previous mode switch will still work, then you can go fwd in modes with short clicks until you pause/delay again to lock it in. So, even thoug you got a simple 1 click OFF, you can still navigate through all the modes without turning the light OFF (unless you are already at the first/lowest mode already).

I made a couple 1-click-off firmwares for e-switches, under the Ferrero_Rocher dir of my repo. I’m curious what you think about them.

One does a smooth auto-reversing ramp on long press while the other does a stepped looping ramp. Both give instant access to min, max, and the last-used mode from off. One also includes a soft lockout mode and takes moon out of the main mode sequence (Baton).

It’s hard to include lots of extra blinky modes with an e-switch though, because handling the e-switch takes more room than a clicky. Space tends to fill up with just basic modes, before adding any really interesting stuff. It seems easiest to handle lots of modes on a clicky w/ off-time cap.

Tom E
Tom E's picture
Offline
Last seen: 10 hours 2 min ago
Joined: 08/19/2012 - 08:23
Posts: 14629
Location: LI NY

Ahh - ok. I looked again and did find it in the cypreus version earlier. I hear you bout space - hoping the ATtiny25 venture works out - think JohnnyC is looking into it, started a port. Doubling program space should help big time.

I'll see if I get a chance to look at your e-switch versions. Not sure if I have time because work is goin nuts - adding a vibrotactile belt (yes - a vibrating belt Undecided) to the Biodex Balance systems, plus major port from WinCE C++ to Win 7+ C#/.NET platforms, plus adding JSON/web interfaces, etc., etc., on and on...

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

wight wrote:
I’ve been thinking that I should do a writeup on how to use the firmware, complete with all features and what’s required to take advantage of them.
.
..
I’ve been thinking of doing a different kind of spring pad pattern in order to make it easier to center & solder different springs

Yes, please. STAR has me so lost…

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

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

Mike C
Mike C's picture
Offline
Last seen: 2 days 14 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2578
Location: Sweden

JonnyC wrote:
I’m at max capacity on STAR_off_time, so features would have to be disabled in order to enable this.

Are you using the standard Star off time as can be found in the link in your signature? That code really isn’t optimized. There are a lot of things you can do to minimize space. For example:

Instead of having all of those defines for modes, just make a simple array without all of this “#ifdef” and “mode_cnt++” stuff. I mean, when you compile the hex file you know how many modes you’re going to have anyway:

static uint8_t modes[] = {3,14,39,255};

For turbo mode definition you can then just use #ifdef TURBO_TIMEOUT.
For moon mode definition:

#ifdef MODE_MOON
static uint8_t modes[] = {3,14,39,255};
#else
static uint8_t modes[] = {14,39,255};
#endif

Then you can get rid of the unneeded space wasting integer “mode_cnt” and it’s handling, and instead use “sizeof(modes)” to get the amount of modes later in the code.

I’ve written my firmware this way so I know it works, so I just tested making these small changes in the linked Star off time (took about 5 minutes) and went from 1000 bytes to 920 bytes… With no change in functionality at all.

Star and the off time version have plenty of things that can be optimized in similar fashion without changing functionality. Star is great because it’s written for easy use, but there are changes that can be done like the one I made above that can save even more space without necessarily making it harder to use.

Hoop
Hoop's picture
Offline
Last seen: 15 hours 2 min ago
Joined: 12/20/2012 - 05:33
Posts: 1036
Location: Spokane, WA

How might I allow for slower or faster button presses when changing modes with STAR_offtime_no-memory? I would like to allow slower presses to change modes instead of reverting to low. Does the CAP_THRESHOLD value affect this?

I gave my mag-lite to my parents to see how the mode switching worked for them and they fumbled with the control of the light more than I was expecting.

Mike C
Mike C's picture
Offline
Last seen: 2 days 14 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2578
Location: Sweden

Hoop wrote:
How might I allow for slower or faster button presses when changing modes with STAR_offtime_no-memory? I would like to allow slower presses to change modes instead of reverting to low. Does the CAP_THRESHOLD value affect this?

Yep, the CAP_THRESHOLD is what affects it. In easy terms the off time press check is just checking the voltage level of the capacitor, a lot like the voltage monitoring routine. When the light is turned on the off time pin is configured as input and compares the measured level with the threshold value. Once all of that is done the off time pin is set to output and turned on (high) which charges the capacitor and keeps it charged until the light is switched off.

Hoop wrote:
I gave my mag-lite to my parents to see how the mode switching worked for them and they fumbled with the control of the light more than I was expecting.

Yeah, getting some to understand momentary pressing rather than full clicks is not always easy.
JonnyC
JonnyC's picture
Offline
Last seen: 4 months 4 weeks ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

Tom E wrote:

Ohh - I used your latest STAR-Off_time verison for the 1st time and got a bit confused over "DUAL" PWM support. I finally figured it out after seeing how the conditional compile switch's were being used, but would have saved me time if I could have understood it better from the descriptions/docs. I was thinking DUAL PWM mode was phase controlled and fast, as opposed to DUAL outputs, so had me going for a while...

Also, maybe it wasn't so clear to me, but finally understood it by again, going through the code. I think in the prior versions TURBO would knock down to the previous mode in the mode table, but now, it knocks down to a set value, not in the table. I definitiely prefer the way you have it implemented now. I always thought the TURBO step-down setting should be an accessible mode and take up another mode setting. Think the BLF SE X6 driver works the old way which I can't stand - seems a waste of a mode, more clicking, etc.

Yeah, not all that user friendly Sad  It will be rare that someone would use dual PWM outputs, but I don't want to have a whole bunch of separate programs with different features.

I have a light that has the old turbo step down, and I find it really annoying too, especially because "turbo" is not that much brighter than "high", yet I have to step through high to get to turbo.  The ramp down works awesome too, most users won't even notice a change in output yet they get max brightness right from the start without any overheating.

JonnyC
JonnyC's picture
Offline
Last seen: 4 months 4 weeks ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

Mike C wrote:
JonnyC wrote:
I'm at max capacity on STAR_off_time, so features would have to be disabled in order to enable this.
Are you using the standard Star off time as can be found in the link in your signature? That code really isn't optimized.

Modes (well, just moon) can be altered by the stars that are soldered though, so they aren't just determined at compile time, even though most people that are customizing the code really have no use for the star soldering features.

I said it before, but seriously, if someone wants to take this codebase and make it an "official" BLF firmware and continue adding features, please feel free.  Many of you have come up with great features already, and are better programmers than I.  Now that STAR has options there to fit almost anyone's basic needs for a light (my UI needs were met a long time ago), I have lost interest in adding features, creating documentation, etc., as everyone has little variances in how they would like the UI to work (and you are implementing those UI's just fine on your own, which was really the point of releasing this firmware as it's a good starting point for modification).  As you guys have pointed out, the more features that were added, the more confusing it is to newer entrants to firmware flashing.  This can only get worse.

I will go through each program when I get some time to add some more comments about what #define options do what to make it easier for a newer user to understand everything.

I'm working with RMM on a port for the ATtiny25 (already ported, just need to implement temp sensing in STAR_off_time like we have in STAR_momentary), where we have much more room to improve the logic to adjust the output based on temperature.  Once that is completed I will probably bow out, as it was a fun hobby from the start, but is now more of a chore.  Working for a new software startup is keeping me busy (which I honestly should be devoting every waking minute to), and I have a whole bunch of projects that I haven't had the mental energy to commit any time to, including learning to machine parts on my 9x20 lathe, rebuilding a motorcycle has been down to the frame for more than two years, and remodeling my house.  I guess finding a girlfriend/wife should be in there somewhere as well Wink

Mike C
Mike C's picture
Offline
Last seen: 2 days 14 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2578
Location: Sweden

Yeah, I get what your saying. Gotta thank you for your work, it got me going with writing my own firmware. I spent a lot of time optimizing because I needed the space.

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

Mike C wrote:
That code really isn’t optimized. There are a lot of things you can do to minimize space.

I just tested making these small changes in the linked Star off time (took about 5 minutes) and went from 1000 bytes to 920 bytes… With no change in functionality at all.

Except, of course, breaking the core design concept of STAR. It’s designed to be configurable at run-time (via soldered stars) instead of compile-time. This costs a lot of space, but makes drivers end-user configurable.

However, I’ve found two things which definitely can be reduced in STAR off-time. It doesn’t actually need to set up or use the WDT interrupt. That part of the code can be removed and replaced with a small bit of logic in the main loop. It also can be made smaller by replacing the stock _delay_ms() with a custom one. These are the first two things I figured I’d try before attempting to add medium-press and battery check to it.

FmC
FmC's picture
Offline
Last seen: 6 months 4 weeks ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU
ToyKeeper wrote:
Except, of course, breaking the core design concept of STAR. It’s designed to be configurable at run-time (via soldered stars) instead of compile-time. This costs a lot of space, but makes drivers end-user configurable. /snip

It will be interesting to see if 105c supplies dry up, or if they will be kept in production.

Several people, including myself, have been sent the 105d’s, which don’t have the stars.

Hoop
Hoop's picture
Offline
Last seen: 15 hours 2 min ago
Joined: 12/20/2012 - 05:33
Posts: 1036
Location: Spokane, WA

Because I can flash drivers now, the stars don’t matter as much to me, but for the average person buying a 105C with standard or custom firmware on it they are kind of nice to have. Of course, programmable drivers, programmed via the input switch would eliminate the need for stars and allow for even more changes on the fly.

Mike C
Mike C's picture
Offline
Last seen: 2 days 14 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2578
Location: Sweden

ToyKeeper wrote:
Except, of course, breaking the core design concept of STAR. It’s designed to be configurable at run-time (via soldered stars) instead of compile-time. This costs a lot of space, but makes drivers end-user configurable.

Yeah, your right about that. I’m just the kind of guy that programs in a moon mode if I want it, and leave it out if I don’t. I don’t use stars for any kind of mode configurations, only use them for off time caps, inputs and outputs.
ToyKeeper wrote:
However, I’ve found two things which definitely can be reduced in STAR off-time. It doesn’t actually need to set up or use the WDT interrupt.
Also true, but you’d have to re-program the turbo timeout because it’s currently counting WDT ticks.

ToyKeeper wrote:
It also can be made smaller by replacing the stock _delay_ms() with a custom one.
Yep, I suggested that quite a lot of pages ago in this thread. I’ve found that the stock _delay_ms() is not so bad, but gets bad if you pass values above 255 into it, forcing it to deal with doubles. My delay routine has a lower resolution so all my delaying needs are under 255 and therefor only needs integers. That keeps memory usage down a bit.
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 20 min ago
Joined: 01/12/2013 - 14:40
Posts: 10731
Location: (469219) 2016 HO3

Mike C wrote:
I’ve found that the stock _delay_ms() is not so bad, but gets bad if you pass values above 255 into it, forcing it to deal with doubles. My delay routine has a lower resolution so all my delaying needs are under 255 and therefor only needs integers. That keeps memory usage down a bit.

It doesn’t really matter right now, but a “double” in C is a float with twice the default resolution. Integers above 255 are still integers, they’re just 16 bits instead of 8. Technically, it would be called a dword, or double-word, since the word size on the attiny13a is 8 bits.

For portability, people usually avoid using “words” because the size varies per architecture, choosing explicit bit sizes instead. But words are handy for speed optimization, since they typically are the fastest for most operations.

Mike C
Mike C's picture
Offline
Last seen: 2 days 14 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2578
Location: Sweden

Interesting… from that last post all you comment with is an in depth explanation of my incorrect terminology. Oh well, I guess it’s good that everyone is different, the world would be a boring place otherwise Beer

wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

Hoop wrote:
How might I allow for slower or faster button presses when changing modes with STAR_offtime_no-memory? I would like to allow slower presses to change modes instead of reverting to low. Does the CAP_THRESHOLD value affect this?

I gave my mag-lite to my parents to see how the mode switching worked for them and they fumbled with the control of the light more than I was expecting.

Did they stumble with the offtime timeout, or the fact that it’s a forward clicky with an offtime firmware?

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Pages