STAR Firmware by JonnyC - Source Code and Explanation

1335 posts / 0 new
Last post
flucero28
Offline
Last seen: 7 months 3 days ago
Joined: 04/24/2012 - 11:24
Posts: 46
Location: New Mexico

Hello everyone, I have read through this thread but have not seen this question answered. Does anyone know if there is a version of STAR with the short cycle mode memory similar to luxdrv? If not, is it possible and how difficult would it be? This is the only feature missing keeping me from using the STAR firmware.

Thank you,

Frank

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 45 min 9 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10741
Location: (469219) 2016 HO3

flucero28 wrote:
Hello everyone, I have read through this thread but have not seen this question answered. Does anyone know if there is a version of STAR with the short cycle mode memory similar to luxdrv? If not, is it possible and how difficult would it be? This is the only feature missing keeping me from using the STAR firmware.

I don’t think there is, but could you describe a little more about what you mean by short-cycle memory? It seems to get used to mean more than one different thing around here.

I think that style has mostly been abandoned ever since people found ways to measure the amount of time the light was off. So, instead of short-cycle memory, people mostly use a long-press or short-press to tell the light whether to go to the next mode or back to the beginning.

flucero28
Offline
Last seen: 7 months 3 days ago
Joined: 04/24/2012 - 11:24
Posts: 46
Location: New Mexico
ToyKeeper wrote:
I don’t think there is, but could you describe a little more about what you mean by short-cycle memory? It seems to get used to mean more than one different thing around here.

By short cycle I mean upon switching from a locked mode, the light defaults back to the first mode in the mode list instead of the next mode in the mode list. I hope I’m explaining this correctly. It was always a great compromise between having mode memory with many modes and not having to scroll through all of them to use the first few modes.

ToyKeeper wrote:
I think that style has mostly been abandoned ever since people found ways to measure the amount of time the light was off. So, instead of short-cycle memory, people mostly use a long-press or short-press to tell the light whether to go to the next mode or back to the beginning.

Will this method also work with regular clicky style lights? It would be great if so!
Thank you very much for your input ToyKeeper.

Frank

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 45 min 9 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10741
Location: (469219) 2016 HO3

Yes, offtime memory works only with clicky-style lights.

With short-cycle memory, it uses on-time. The light comes on, then if you tap the button (cut power) within the first second or so, it knows that it should go to the next mode. Then if you leave it on longer than a second or two, it locks in and the next tap will go back to the beginning of the sequence. I used this interface on several of my lights, such as early versions of s7.c or brass-edc.c.

I think you might be looking for “off-time no-memory”. With that, it doesn’t care how long the light was on. If you tap the button for a short time, it will go to the next mode. But if you leave it off for a longer time, it will go back to the beginning of the sequence. So you can easily jump to the next mode, regardless of how long the light was on, and you can also get back to the beginning pretty quickly too.

I normally set the boundary between “short press” and “long press” at about half a second.

In addition to that method, I’ve also become fond of a 3-way split instead of just 2 ways. So, it has a short press, medium press, and long press. Short goes to the next mode, medium goes to the previous mode, and long resets to the beginning. This allows navigating the mode sequence both ways, and additionally allows having an entirely different sequence if you go “backward” from the first mode. Here is a diagram showing that interface on a popular BLF light:

mattlward
mattlward's picture
Offline
Last seen: 4 hours 27 min ago
Joined: 06/19/2015 - 09:20
Posts: 3128
Location: Illinois, USA

Why is there a dual switch version, the tail cap click switch would just kill power to the whole driver. I can see where one could take out the mode selection that puts the driver to sleep… Is that the whole point of that version?

Thanks matt

EDC rotation:
FW1A, LH351D 4000k (second favorite)
FW3A, LH351D 3500k
FW3A, SST20 FD2 4000k
FW3A, Nichia 4000k sw40 r9080 (favorite light!)
FW3A, Cree XP-L Hi 5A3
Emisar D4V2, SST20 4000k
S2+, XM-L2 T6 4C

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 45 min 9 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10741
Location: (469219) 2016 HO3

Sure, one switch is a hard power disconnect while the other is just a little electrical blip… but with two buttons you can do a lot of stuff which isn’t possible with just one button.

For example, when turning the power on (via hard power switch), you could make it do different things depending on whether the e-switch was up or down at the time. Or use the clicky switch for momentary control while the e-switch ramps brightness up and down.

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

Are the PWM channels reversed from the BLF-A6 firmware to STAR? To clarify, “star 2” controls the 7135 in blf-a6, and in STAR, that leg is the “ALT PWM.”

I tried STAR firmware on the A17DD-L FET+1 driver but I am only getting one mode.

Edit: I think I’ve determined the answer is yes. I swapped some values and I get modes:

In STAR, I swapped values of lines 108 with 113, and 119 with 120.

default 108: #define STAR2_PIN PB0
default 113: #define PWM_PIN PB1

default 119: #define PWM_LVL OCR0B
default 120: #define ALT_PWM_LVL OCR0A

Edit: #define CAP_THRESHOLD in STAR seems to be having no affect on the offtime function. I am not sure why. Tried values from 110 to 255 and it always took some 7+ seconds to reset the modes.
The stock “OT” labeled cap on my board looked bridged across the top with a very conspicuous blob of solder. I wasn’t sure if this was intentional from the factory so to troubleshoot I removed the “OT” cap from the A17DD-L and the board does take way longer to reset the mode to low; 10+ seconds. I then stuck on a 1uF cap that I bought from mtn and it performs as the stock one did as far as I can tell; 7+ seconds before reset.

Update: Actually, with the cap removed the modes don’t revert. It is always next mode from the last used mode.

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

ToyKeeper wrote:
I think you might be looking for “off-time no-memory”. With that, it doesn’t care how long the light was on. If you tap the button for a short time, it will go to the next mode. But if you leave it off for a longer time, it will go back to the beginning of the sequence. So you can easily jump to the next mode, regardless of how long the light was on, and you can also get back to the beginning pretty quickly too.
That doesn’t sound like a match for what flucero28 is asking about. I was under the impression that short-cycle would work with either ontime or offtime, it doesn’t depend on the method of memorization.

Let’s go with offtime for an example though:

  1. Out of 5 modes we switch to 4 and memorize it by turning the light off for a period of time.
  2. We turn the light back on, it is now in mode 4 (as memorized).
  3. Now we do a “short press”. The light should cycle to mode 1.

That’s how I understood short-cycle.

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: 45 min 9 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10741
Location: (469219) 2016 HO3

wight wrote:
That’s how I understood short-cycle.

Oh, yeah. Short-cycle with memory is weird, especially if it’s ontime-based. Does anyone like it that way?
wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

I’ve never tried it. Conceptually offtime + no-memory sounds better to me for my uses. With that said, offtime+no-memory can probably be a huge drawback on a light with lots of modes. I tend to run only a few modes, but if I had 20 modes I might want memory + quick access to the first few modes. Short-cycle fits that description.

I haven’t had good luck with the short+medium+long-press stuff. If I was able to use that reliably I think that would be a better solution to the same problem.

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: 45 min 9 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10741
Location: (469219) 2016 HO3

If the button timings aren’t calibrated well, it can definitely be a pain. The X5/X6 aren’t calibrated well, since they used hardware three months newer than the firmware and there was no opportunity to calibrate it.

I use offtime no-memory on most lights, including basic nanjg drivers with no physical mods. I prefer to have an OTC though, for a deeper UI with faster ways of getting to the modes I want. It’s nice being able to reach moon, low, med, and turbo all within one second. I almost never use any other modes (except blinkies).

The main exception for me is e-switch lights. On those I like smooth ramping with memory and shortcuts to min/max.

zeremefico
zeremefico's picture
Offline
Last seen: 8 hours 47 min ago
Joined: 03/27/2012 - 02:44
Posts: 1389
Location: Greece

I face a problem with lvp in a zener modder 105c driver. On driver there are the 2 standard resistors plus a 2000 resistor replacing the diode aside led+.
After suggestions from this thread, I used 141 & 151 values for 2s setup.
Unfortunately, after checking with my power supply, I have no lvp, xhp50 is dimming till 5v, without mode step down.
Any ideas?

₪₪₪₪ ΟΥΔΕΝ ΚΡΥΠΤΟΝ ΥΠΟ ΤΟΝ ΗΛΙΟ ₪₪₪₪

My YouTube channel

Flashlights & edc gear

K40M F16

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 45 min 9 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10741
Location: (469219) 2016 HO3

… flash battcheck.hex onto it and let it tell you what the attiny sees at different voltages?

Measuring is far more effective than guessing. Smile

The battcheck/README file explains how to measure the voltage range, among other things.

Tom E
Tom E's picture
Offline
Last seen: 8 hours 52 min ago
Joined: 08/19/2012 - 08:23
Posts: 14638
Location: LI NY

flucero28 wrote:
ToyKeeper wrote:
I don't think there is, but could you describe a little more about what you mean by short-cycle memory? It seems to get used to mean more than one different thing around here.
By short cycle I mean upon switching from a locked mode, the light defaults back to the first mode in the mode list instead of the next mode in the mode list. I hope I'm explaining this correctly. It was always a great compromise between having mode memory with many modes and not having to scroll through all of them to use the first few modes.
ToyKeeper wrote:
I think that style has mostly been abandoned ever since people found ways to measure the amount of time the light was off. So, instead of short-cycle memory, people mostly use a long-press or short-press to tell the light whether to go to the next mode or back to the beginning.
Will this method also work with regular clicky style lights? It would be great if so! Thank you very much for your input ToyKeeper. Frank

I did this, both in a Attiny25 version (over 1KB code) with more advanced features like luxdrv has - strobes and batt check, and a 13A version without strobes and battcheck. Not posted yet anywhere, but love the 25 version of it - have it in a BLF D80 and a NiteFighter F30B and it works great! Should post it up somewhere - well tested at this point.

I was always a fan of short cycle memory, specially for 3-4 mode levels - phrase probably coined by Dr Jones. 4 mode levels is my favorite for this setup.

Halo...
Halo...'s picture
Offline
Last seen: 5 years 1 month ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

I’ve kind of wanted to try out short cycle memory ever since I first heard of it. Sounds like it could be useful.

You get memory of the last used mode but you always know where you will start off if you start clicking. For example if you have ML,L,M,H,Turbo and you need low just tap twice (while pressing the flashight head against your thigh to block any bright mode). Even if you don’t recall what mode you last used, 2 taps will always get you low.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 45 min 9 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10741
Location: (469219) 2016 HO3

Halo… wrote:
I’ve kind of wanted to try out short cycle memory ever since I first heard of it. Sounds like it could be useful.

You get memory of the last used mode but you always know where you will start off if you start clicking. For example if you have ML,L,M,H,Turbo and you need low just tap twice (while pressing the flashight head against your thigh to block any bright mode). Even if you don’t recall what mode you last used, 2 taps will always get you low.


Say you have a light with moon, low, med, high, and turbo, in that order.

If I understand correctly, reaching low mode from off, using “offtime no-mem”, would mean “click, tap”. Using “offtime short-cycle” or “ontime short-cycle”, it would mean “click, tap, tap”. Is this correct?

Let’s say the light was used for a couple minutes in low and you do another button tap. In “offtime no-mem” this would go to medium. In “ontime short-cycle” this would go to moon. What is the intended behavior for “offtime short-cycle”?

Tom E
Tom E's picture
Offline
Last seen: 8 hours 52 min ago
Joined: 08/19/2012 - 08:23
Posts: 14638
Location: LI NY

Yep, that last sentence is what you get, and why you want it. The main purpose, as I understand and use it for, is to have a light w/memory first of all, but doesn’t force you to cycle thru the high modes, and blinky modes following high modes – high mode is extremely bright on most of my mods, and for general use, is not what you want to flash through.It doesn’t work well with 6 or 7 modes because of the amt of clicks to get to hi, in my opinion, but is pretty darn nice for 3-4 or less, plus blinkies. I suppose you could add long press handling, and add reverse navigation, or long press going to hi, on top of short cycle w/memory – might be a pretty cool combo.

I haven’t had much luck with consistent long presses on a clicky light, or if it works somewhat reliably, it’s timing is quite different from other lights – cold is different from warm, etc., while e-switch lights are rock solid, and easier to use. I got 6 KRONOS lights now running bistro and the long press timing varies light to light, cold to warm, it’s very confusing…

Halo...
Halo...'s picture
Offline
Last seen: 5 years 1 month ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

ToyKeeper wrote:
Say you have a light with moon, low, med, high, and turbo, in that order.

If I understand correctly, reaching low mode from off, using “offtime no-mem”, would mean “click, tap”. Using “offtime short-cycle” or “ontime short-cycle”, it would mean “click, tap, tap”. Is this correct?

Let’s say the light was used for a couple minutes in low and you do another button tap. In “offtime no-mem” this would go to medium. In “ontime short-cycle” this would go to moon. What is the intended behavior for “offtime short-cycle”?

Correct.
Intended behavior for “offtime short-cycle” would be to go to medium, if I’m not mistaken. In offtime mem, short-cycle shouldn’t be come into play for button taps. Only full / long clicks (which discharge the OTC below the threshold for a long click).
Now, I’ve never had or used a short-cycle light so this is just from my understanding of them.
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 45 min 9 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10741
Location: (469219) 2016 HO3

Tom E wrote:
I haven’t had much luck with consistent long presses on a clicky light, or if it works somewhat reliably, it’s timing is quite different from other lights – cold is different from warm, etc., while e-switch lights are rock solid, and easier to use. I got 6 KRONOS lights now running bistro and the long press timing varies light to light, cold to warm, it’s very confusing…

It’s a pain, isn’t it?

Using the best available components helps reduce the temperature sensitivity, and getting drivers from a high-quality source (or building them yourself with a consistent method) helps reduce variation between individual units. But even in the best case it’s still not as consistent as an e-switch.

Two improvements under discussion at the moment are replacing the OTC with a bigger cap plus a resistor (to make the drain more consistent) or attempting to make the MCU detect power-disconnect events, go into super-low-power mode, and keep running long enough to measure button timings. Both are likely to require hardware changes, and the last one might not even be feasible since a 22uF C1 is probably not big enough to run the MCU for more than a few milliseconds.

For personal use, I just calibrate the OTC individually for each light, using a metronome, with drivers from RMM. That gets them about as close to ideal as currently possible.

On the other end of the spectrum, Manker’s drivers are particularly inconsistent and often pretty far out of spec. Sad

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 45 min 9 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10741
Location: (469219) 2016 HO3

As for offtime short-cycle, I guess I was wondering which specific conditions should reset it to moon:

  • Long-press followed by an immediate short-press? (yes, I assume)
  • Long runtime followed by a short-press? (not sure)

Or should it behave more like TheStar, which cycles through regular modes but not blinkies? That is, unless the user quickly cycles through all the regular modes twice. So, it short-cycles back to the first matching regular mode, but does not specifically short-cycle back to moon.

The only short-cycle UI I’ve actually used is the ontime version, which is fairly straightforward.

Halo...
Halo...'s picture
Offline
Last seen: 5 years 1 month ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

ToyKeeper wrote:
As for offtime short-cycle, I guess I was wondering which specific conditions should reset it to moon:
  • Long-press followed by an immediate short-press? (yes, I assume)
  • Long runtime followed by a short-press? (not sure)
1. yes. Go to moon.
2. no. Just go to next mode / normal short-press behavior.
ToyKeeper wrote:
Or should it behave more like TheStar, which cycles through regular modes but not blinkies? That is, unless the user quickly cycles through all the regular modes twice. So, it short-cycles back to the first matching regular mode, but does not specifically short-cycle back to moon.
I’m not sure if I understand.
Should short-cycle skip moon, since it’s a bit of a special mode? You could if you want but I don’t know if that is standard in most short-cycle implementations.
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 45 min 9 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10741
Location: (469219) 2016 HO3

Oh, it’s not that TheStar skips moon… it just acts (usually) like a boring 5-mode light with memory. But if you cycle quickly through those modes twice, it’ll enter the blinky modes.

I don’t know what to call that style of memory and cycling.

I found it a bit awkward, personally. If I’m on medium and I want blinky 2, it means tapping a bunch of times to go to medium, high, turbo, moon, low, medium, high, turbo, moon, low, medium, high, turbo, blinky 1, blinky 2. Then after using it a while, getting to blinky 3 will take a bunch of taps too, since the next one goes back to moon.

However, it is rather good at keeping the blinkies out of the way when you don’t want them.

Instead of that, I just went with offtime no-mem. It lets me decide whether to go to the next mode or back to the first, simply by tapping for less than or greater than half a second.

_the_
_the_'s picture
Offline
Last seen: 3 weeks 2 days ago
Joined: 07/08/2011 - 06:22
Posts: 3646
Location: Finland

ToyKeeper wrote:
Oh, it’s not that TheStar skips moon… it just acts (usually) like a boring familiar and intuitive 5 3 mode light with memory. But if you cycle quickly through those modes twice, it’ll enter the blinky hidden modes.

Fixed that for you. Wink

ToyKeeper wrote:
I found it a bit awkward, personally. If I’m on medium and I want blinky 2, it means tapping a bunch of times to go to medium, high, turbo, moon, low, medium, high, turbo, moon, low, medium, high, turbo, blinky 1, blinky 2. Then after using it a while, getting to blinky 3 will take a bunch of taps too, since the next one goes back to moon.

However, it is rather good at keeping the blinkies out of the way when you don’t want them.


TheStar is build with an assumption that the hidden (blinky) modes are not used very frequently. Usual TheStar config is 3 modes + hidden extras.

Note that the version in your repository packs in “too many” hidden modes, just to showcase them. An ordinary user can’t memorize them and/or find the correct one when needed => using only 1-3 extras is highly recommended. (for example: Moon, bike flasher, strobe)

ToyKeeper wrote:
Instead of that, I just went with offtime no-mem. It lets me decide whether to go to the next mode or back to the first, simply by tapping for less than or greater than half a second.

Offtime no-mem is good if you usually want to use one of the first modes. (Low, med – or High, med)
The advantage of TheStar (or any FW with ordinary short-cycle memory) is that it allows you to leave the light on a desired mode and turn it on with that mode when needed..

For example:
Click-click-…-click-Moon -> turn the light off -> wake up at 2am -> turn the light on (moon) => don’t accidentally wake up other family members
Click-click-…-click-Strobe -> turn the light off -> go to a walk -> face an attacker -> turn the light on (strobe) => STROBE!

Halo… wrote:
I’m not sure if I understand.
Should short-cycle skip moon, since it’s a bit of a special mode? You could if you want but I don’t know if that is standard in most short-cycle implementations.

Yes. Usual TheStar has Moon as the 1st hidden mode, but it can be (of course) added as a normal mode if used “too often” to avoid two cycles of modes to access it.

=the=

 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 45 min 9 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10741
Location: (469219) 2016 HO3

the wrote:
Fixed that for you. Wink

Thanks!

It was in kind of a dusty part of my head.

the wrote:
Note that the version in your repository packs in “too many” hidden modes, just to showcase them.

Oh, that explains a lot. I had wondered about that.

Code updates are always welcome. Newer TheStar code is on my todo list and everything. Smile

Tom E
Tom E's picture
Offline
Last seen: 8 hours 52 min ago
Joined: 08/19/2012 - 08:23
Posts: 14638
Location: LI NY

I'm not sure that explains it right. Go to the source for the best definition of short cycle memory: http://drjones.nerdcamp.net/

Short-cycle memory is a special UI that allows to have memory and many modes without the need to cycle through all of them.
With classic memory you have a few modes, and if you want to go back to the first mode, you have to cycle through the remaining modes.
With no memory, you always start at the 1st mode and don't always have to click through all the modes, but you have no memory.
With short-cycle memory, a mode is memorized (i.e. if the light is switched off an on again, it comes on in that previously used mode), but when you change modes again, it will restart in the first mode instead of the next mode, so you don't have to cycle through all the modes. This combines memory with the advantages of a no-memory-UI. It effectively hides every mode behind all it's predecessors and is very effective if you have your favourite modes in front and blinkies or other rarely used modes at the end. I call it "short-cycle" in contrast to the classic cycle-through-all-modes memory, but it was actually invented by sixty545 at BLF.

It's a great way to avoid hi and blinky modes when those modes are defined at the end of the mode list.

mattlward
mattlward's picture
Offline
Last seen: 4 hours 27 min ago
Joined: 06/19/2015 - 09:20
Posts: 3128
Location: Illinois, USA

I am trying like hell to finish my D01, but can’t make STAR Momentary work the way I want it to…

Ok, so I added the tail switch to my D01 and modded STAR Momentary to these modes…

#define MODES 1,39,150,255 // Must be low to high, and must start with 0
#define ALT_MODES 255,255,255,255 // Must be low to high, and must start with 0, the defines the level for the secondary output. Comment out if no secondary output
#define MODE_PWM PHASE,FAST,FAST,PHASE // Define one per mode above. 0 tells the light to go to sleep

When I turn the light on via the tailcap switch, I still have to hit the momentary button to wake it up. After that it cycles through the modes fine and the tail cap of course shuts it off. What am I missing? I really wanted to hit the tailcap to turn it on in low and the cycle the modes… With the 0 levels gone, should not the cpu boot and give me the lowest mode with out a side button press?

I have decided that it takes an interrupt to wake up the MCU, that interrupt is generated by the side switch. How do I disable the requirement for an interrupt and force the MCU to boot with power applied via the main tailcap switch?

I know someone has made this work… I have looked at the STAR dual switch, but it is not built for dual PWM channels. I guess that I could abandon the channel that runs the 7135 and go purely FET and run that code. What are the other options for dual switch code?

Thanks Matt

EDC rotation:
FW1A, LH351D 4000k (second favorite)
FW3A, LH351D 3500k
FW3A, SST20 FD2 4000k
FW3A, Nichia 4000k sw40 r9080 (favorite light!)
FW3A, Cree XP-L Hi 5A3
Emisar D4V2, SST20 4000k
S2+, XM-L2 T6 4C

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

The first thing that happens when the MCU receives power is what you see in int main(void) – if we take a quick look at that we see that some setup is done, then it drops into a while loop looking for mode changes. If there is no mode change, it does not attempt to set the output. In my opinion, the fastest hack is probably to just change line 411:
uint8_t last_mode_idx = 0;
to
uint8_t last_mode_idx = 1;

This will make it appear that a mode change has occurred every time the light is powered on. The mode change will be from mode 1 to mode 0 and it will set the output to be appropriate for mode 0.

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)

mattlward
mattlward's picture
Offline
Last seen: 4 hours 27 min ago
Joined: 06/19/2015 - 09:20
Posts: 3128
Location: Illinois, USA

Wight, that made so much sense… but no go same behavior. I have 4 modes defined, none of them 0 modes so as to prevent MCU shutdown. Looked at the code around the line above and that really looked right.

EDC rotation:
FW1A, LH351D 4000k (second favorite)
FW3A, LH351D 3500k
FW3A, SST20 FD2 4000k
FW3A, Nichia 4000k sw40 r9080 (favorite light!)
FW3A, Cree XP-L Hi 5A3
Emisar D4V2, SST20 4000k
S2+, XM-L2 T6 4C

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

Oops, sorry. I didn’t notice line 409 sleep_until_switch_press();

So here are a couple of things:

  1. I don’t see why you need line 409 for your application.
  2. Note the first if inside the while(1) loop – that’s a problem for you I think. Remember that there’s a difference between mode_idx==0 and any modes actually defined as 0 (eg PWM=0/255). This firmware is designed around having modes[0] == 0… you’ll probably have to iron out a few more little things.
  3. With that said… I hacked it up a little. I removed line 409, I removed the offending IF statement I mentioned above, I removed the IF statement and actions from 435-439, and I changed the initialization on line 411 as described previously. It’s not a great hack, but I think it’s probably going to work for you. STAR_momentary_v1.6w1.c

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: 8 hours 52 min ago
Joined: 08/19/2012 - 08:23
Posts: 14638
Location: LI NY

I got dual switch controls fully working in Narsil a while back. I basically merged the two different firmware versions - best-of-both, post 729 here for latest source code and manual. Not to keen on enabling the tail switch for mode changing though - don't understand the usage scenario. It's great for a power lockout in certain lights, but Narsil has a built-in sequence to lock-out the e-switch, just like commercial lights now (I think mine is better of course smile), and the CPU drain in power saving mode is pretty darn low.

I think you might find when you merge the capabilities of clicky and e-switch firmware (without cutting features), you are out of memory in a 13A -- that was the original reason why I went with the 25's and above.

Pages