Ok thanks man. One more question, now that I’m looking at it- what’s the best proper way to enable moonlight when using the alternate PWM output? Before [when using a single PWM, before the new stuff came around] if I wanted to make moon be on without having to solder the star I would do this:
if ((PINB & (1 << STAR2_PIN)) > 0)
Is that still how I should do it or is there a better way?
With JonnyC's firmware if you use the secondary PWM output then moonlight is automatically enabled, since the firmware was originally designed as a firmware to get an exceptionally low moonlight (obviously not to control two different colors, otherwise the interface would be different).
In short: no need to change anything. I would take a look at what Toykeeper has done, as it may be easier for you to do what you want with your project.
In the starry-offtime firmware, the only solderable star is the one which toggles mode memory. All the other pins are used for other things.
So, you’d probably want to just do something like this in the #defines at the top:
// PWM levels for the big circuit (FET or Nx7135)
#define MODESNx 0,2,12,100,255
// PWM levels for the small circuit (1x7135)
#define MODES1x 3,0,0,0,0
#define MODES_PWM PHASE,FAST,FAST,FAST,PHASE
Edit: You might also want to remove the HIDDEN_MODES bits too, which aren’t actually hidden yet. I’ll go back and hide those on a day I’m feeling a little better.
Ok thanks, and I’ll have a look at TK’s FW now too.
What I’m trying to do is make a driver to run my new 17650 light as an EDC, I want to have a triple in it with a nichia 219 powered by 2 or 3 7135’s for a good moonlight (plus low and medium modes) and then have it switch that off and turn on a FET that powers 2 XP-L’s for medium-max (to help with runtime from the little cells), does that seem doable?
I’ve made the changes you specify above and compiled, I got 5 warnings (but all were preexisting), it’ll be a few weeks before I have a board to test this setup tho.
If it takes that long, I’ll probably have the BLF A6 firmware done (or released, anyway). It should work too, and does a lot more than starry-offtime. I branched it off to a new file because it barely even resembles STAR any more.
It’s actually a little more indepth than I described above, I don’t know what the A6 FW is but doubt it would be what I need, thanks for the offer tho (and thanks for whatever it is in general).
In this application in actually going one step further and using a head twist as another control method (whether it’s loose or tight). I’ll do a thread on it once it’s done, according to you guys the FW Should be good, just waiting on the board for it to control it all.
Ah, I have a host here waiting for me to mod it and write firmware including a head loose/tight sensor. I just haven’t gotten to it yet.
Nothing supports that yet, but it’ll be interesting to add.
The BLF A6 is a group buy currently in progress, with wight’s hybrid FET+1 driver in a tube light. It’s kind of groundbreaking in several ways. Take a look here for more details:
Here’s how I implement it for my use, feel free to expand on this method (if anyone needs a driver for a different light let me know, it will be harder than simply sizing this one down ~2mm but not to much I dont think. I dont use any sort of head sensor or monitor for a pull down, I simply use the head tighten to supply GND to the FET’s source.
Oshpark Projects (post 1524 in case you have different page display settings)
This has probably already been discussed and the current work is pretty far advanced but I need to go back for a sec with this question to simple star off time WITHOUT dual PWM; exactly when does the MCU check which stars are pulled down? Is it continuous at every mode change or does it only do it at full reset (when the light either reverts back to the start or to the saved mode, i.e. a long press of the clicky).
Thinking of a way to add a moonlight switch, not to instantly jump to moonlight, but a way to select if moon will be in the mode rotation or not by grounding it’s star with some sort of mechanical switch. Would that work or does it not check the stars enough?
It doesn’t matter which firmware version you look at, all STAR_on_time and STAR_off_time work the same way… they check the stars every time they are powered on.
Note that the stored mode will change when moon is enabled/disabled. (assuming that memory is enabled)
It’s pretty straightforward to see all that in the code: note that the star-checking/modes-setup happens before the main WHILE() loop.
Yep, I got that. Your right it’s very straight forward, what I dont know, and I still dont get after reading your reply is whether it checks it after every tap of the tail switch when it’s just changing modes, or if it only checks it at the initial start up after a full reset (the time when it either reverts back to the start or back to the memorized level).
I guess I could reword my question; Does a short power cycle to advance to the next mode restart the whole thing and re-initialize (thus checking the stars) or does only a full reset cause it to initialize again?
A short tap restarts everything. If it didn’t the mode change wouldn’t work as all that is done at start up. It’s basically only watchdog interrupts (for turbo timeout) and voltage monitoring that is running, everything else is start up code.
That’s what makes clicky-switch lights so “fun” to write code for… it resets completely every time the button is pressed, and must boot fresh after each time. It’s actually a lot like how web application code works; it must start fresh on each page load. Anything which passes between pages must either be sent from the browser each time or saved in a cookie-linked session on the server. Except on torches, the “cookies” are in EEPROM or in a capacitor.
In any case, the star-checking code is not a sub-clause of the OTC-checking code, so it happens regardless of how long the switch was held down.
How to change the is_pressed() function to positive logic in momentary firmware?
I disabled the pullup resistor and soldered a pulldown resistor to the star and ground
I need it because my headlighe has a switch in front and 3 wires going to the battery and driver
+led which is also +batt
led which is not gnd so cannot use it for the the switch
is the switch - I connected the other side it to +led
If I understand your question correctly, you can do this by simply changing the “return (buffer” part to “return !(buffer” to logically invert the value.
