STAR Firmware by JonnyC - Source Code and Explanation

1335 posts / 0 new
Last post
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 week 5 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

wight wrote:
So why not link here? https://github.com/JCapSolutions/blf-firmware/tree/dual_pwm

Because I forgot to save the URL where I could find it easily, and didn’t remember where I originally found it. Also, I had some difficulty getting a copy of that via git, because it kept giving me the master branch instead of dual_pwm (even using the clone URL suggested at that site). I need to learn more about git.
JonnyC
JonnyC's picture
Offline
Last seen: 3 months 3 days ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

wight wrote:
ToyKeeper wrote:
This might not have all of JonnyC's most recent additions, but it does at least have dual PWM: http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/h... *I'm a little behind on merging in his latest changes.*
So why not link here? https://github.com/JCapSolutions/blf-firmware/tree/dual_pwm[/quote]

I merged the dual_pwm feature into the "master" branch, so it's in the latest version of the program...

https://github.com/JCapSolutions/blf-firmware/tree/master/STAR_off_time

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

Fair enough. I had to search for my own post on the topic to find the link. Or I thought I did – now that I say that it strikes me that JonnyC has added a link to the GIT repo on the firmware page of his website. I forgot about that.

FYI for Cereal_killer or anyone else, to go from the link JonnyC posted on his website (so from https://github.com/JCapSolutions/blf-firmware ) to the dual_pwm branch you must use the little “branch:” dropdown menu that defaults to branch: master.

EDIT: I got ninja’d by JonnyC: apparently the dual-pwm branch has already been merged back into the master branch. The latest code in the master branch is what you want.

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: 1 week 5 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

Thanks. Right after posting earlier I grabbed updates on the main branch and found that the dual_pwm bits had been merged in. Smile

Also, I got bzr-git working, which lets me use bzr to access git repos. This is much much easier for me, and should greatly simplify merging in changes.

Edit: … and it’s all up to date now. Smile (plus, future updates should be much easier) I should note that the dual_pwm/ dir is gone though, since it got merged back into the main STAR code.

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

Just FYI, I'm not sure that the latest versions with the dual-pwm have been fully tested, so please let me know if there are any issues.

Cereal_killer
Cereal_killer's picture
Offline
Last seen: 1 year 7 months ago
Joined: 07/22/2013 - 13:10
Posts: 4005
Location: Ohio

Using dual-PWM whats the lowest you guy’s are able to get XP-L’s to light up?

Quad XP-L with BLF 17dd V3 driver

 RIP  SPC Joey Riley, KIA 11/24/14. Now I am become death, the destroyer of worlds.

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

Cereal_killer wrote:
Using dual-PWM whats the lowest you guy’s are able to get XP-L’s to light up?
I don’t know the answer either way, but are you asking about 7135s, FET, or something else?

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: 1 week 5 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

Er, the lowest mode is really hard to predict, and highly dependent on hardware (driver, emitters, battery, etc).

For example, I’m getting 0.1 lm from a triple-219B driven by a FET, using fast PWM=0. But that 0.1lm drops down to like 0.00001 lm when the cell gets down to like 3.7V.

On the same hardware, if I use phase PWM=1 instead, the minimum level is about 3.6 lm (drops to about 0.9 lm at 3.6V).

On nanjg/qlite drivers, the lowest mode seems to depend mostly on the exact bin of 7135 chips used.

Basically, you’ll just have to try it and find out.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 week 5 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

ToyKeeper wrote:
vex_zg wrote:
next step I plan to do: implement and hide modes (strobe) “before” the first (moon) mode so that they can only be accessed immediately after the light has been switched on, using “go back” / longer press of the switch.

Now that is a very interesting idea. Smile

I think “backward from moon” might be a great way to access what I call “impress mode” on a stupidly-bright light I’m making. I wanted something to give me quick access to its brightest mode without interfering with EDC-style use, and that might work really well.

So, I put together a test light today with an off-time cap on the driver, and I adapted the cap-reading code from STAR off-time to fit in with my “s7” EDC code. I also added another cap threshold for medium presses, so it can detect short/med/long presses.

I haven’t really tweaked it yet, but it seems a short press is about 0 to 0.7s or so, a medium press is about 0.8 to 2.0 seconds, and a long press is anything over 2 seconds. These are mapped to “next mode”, “previous mode”, and “reset to mode 0”, respectively. I think the timings need to be shorter, but I can calibrate it later.

If the user does a prev-mode action at mode 0, it’ll go into semi-hidden “negative” modes, so it gives quick access to turbo, my favorite strobe, and battery check. Also, a next-mode action from any negative mode will always return to mode 0; no need to cycle back up through them again. Doing next-mode at the end of the main sequence will loop back to 0, instead of going through the negative modes.

I’m considering making back-from-zero change the mode group instead of doing just limited “negative” modes, but I’m not sure if I’ll bother.

Anyway, this went together pretty quickly and it seems to work well. Now I have firmware ready to go for my Cypreus, as soon as the emitters arrive (tomorrow or the next day). Smile

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

Am I correct in thinking that the ATtiny13A defaults to REFS0==0 on startup? So if I want to use Vcc as my analog reference I must change this line:

DMUX  = (1 << REFS0) | (1 << ADLAR) | ADC_CHANNEL; // 1.1v reference, left-adjust, ADC1/PB2
to read this way:
DMUX  = (1 << ADLAR) | ADC_CHANNEL; // Vcc reference, left-adjust, ADC1/PB2

Thanks guys!

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)

fellfromtree
fellfromtree's picture
Offline
Last seen: 6 years 8 months ago
Joined: 07/25/2014 - 15:14
Posts: 470
Location: spelunking

Not sure what bits REFS0 and ADLAR are setting in ADMUX. They start 0 I’m pretty sure though. Here’s a link on the basics- don’t see the bits for those two giving it a quick glance.. I guess could just lave REFS0 out and it should be 0

http://www.adnbr.co.uk/articles/adc-and-pwm-basics

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

fellfromtree wrote:
Not sure what bits REFS0 and ADLAR are setting in ADMUX. They start 0 I’m pretty sure though. Here’s a link on the basics- don’t see the bits for those two giving it a quick glance.. I guess could just lave REFS0 out and it should be 0

http://www.adnbr.co.uk/articles/adc-and-pwm-basics

Thanks fellfromtree. I went ahead and tried it before I saw your post and sure enough, leaving out REFS0 keeps it set to zero. (so vref is based on Vcc)

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)

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

FYI for in the future, if you download the ATtiny13A datasheet you can just search for ADMUX and it will list the register, what the bits mean, and what their default values are.

fellfromtree
fellfromtree's picture
Offline
Last seen: 6 years 8 months ago
Joined: 07/25/2014 - 15:14
Posts: 470
Location: spelunking

Ah that’s cool.. Yeah let us know how the monitoring of vcc goes wight. That sounds like fun for 1s, maybe eliminate 2 more resistors on the board

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

fellfromtree wrote:
Ah that's cool.. Yeah let us know how the monitoring of vcc goes wight. That sounds like fun for 1s, maybe eliminate 2 more resistors on the board

I don't think it is directly measuring voltage, but instead using the VCC as the reference voltage instead of the internal 1.1v.  You could use it as the reference voltage with zener mod drivers or with an external voltage regulator (both with 2S+) since the voltage input will remain constant, but with 1S cells it would be pretty much useless.  You would still need a voltage divider because the voltage you would be measuring against would still be higher than the reference.  You can use it, however, for other measurements (like a temperature sensor) without needing an additional divider.

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

fellfromtree
fellfromtree's picture
Offline
Last seen: 6 years 8 months ago
Joined: 07/25/2014 - 15:14
Posts: 470
Location: spelunking

Ah gotcha.. So your comparing it between the divider and vcc. Learn something new everyday thanks.

*Edit Wait wouldn’t it be the other way around. Cause the zener going to keep the voltage the same? The voltage will drain as the battery drains in 1s. Am I missing something.. Oh nm I see what your saying 1.1v internal is always going to be 1.1. Still need the divider to get the voltage from B+.. It’s too early for this sh Smile

Oh yeah sent my inlaw over your site yesterday. He saw my private video of the yezl blowing things up on dd and caught the lumen disease. He’s a pic guy though, so he’s talking about 3 phase pwm and all that other stuff. Can’t wait to see his lights really

HighEfficiency
HighEfficiency's picture
Offline
Last seen: 4 years 1 week ago
Joined: 02/05/2014 - 11:33
Posts: 74
Location: USA
Cereal_killer wrote:
Mike C wrote:
I am changing the functionality of some of the features with the STAR 1.1 firmware and just want to make sure about what this line of code does: PWM_LVL = modes[- -mode_idx]; This changes the PWM_LVL (output) to the level of the previous mode but does not actually change the mode itself. This means that if this line is executed while the light is on high, the output will switch to that of medium, but the light will still “think” it’s on high and remember high as current mode if switched off. Is that correct?

Note you can also use this line to modify the turbo step down to a specific PWM value instead of the previous mode, simply replace PWM_LVL = modes[- -mode_idx]; with PWM_LVL = 180 (desired PWM value). That way you can have it step down to a level of your choice but still act normal and still be able to be bumped back up to turbo with a single click.

I use it like this in my small lights that need a large step down to not overheat.

Digging up an older concept here and hoping for some help.

I was hoping the above change in code would allow me to skip having the turbo timeout step down as an independent mode. My sense is I am one step away.

Here’s what I’m after: Low (1 value), Medium (2 value), Turbo (3 value) to step down (4th value).

As the FW is written, in order for me to have this I actually have 4 click through modes of Low, Medium, Step Down, and Turbo. I’m looking to have the turbo step down mode ONLY accessed following turbo time out. So in the end I’ll have 3 click through modes, but in operation 4 output modes.

I tried the above recommendation and then attempted to comment out “#define mode_high_w_turbo” but I was left with an error in line 259 “mode_high_w_turbo” undeclared (first use in this function)”. I assume the code is trying to reference the line I commented out but I don’t see it, and definitely don’t understand it.

With no working knowledge of C++ (other than reading through this whole thread), I was hoping I could get some help.

Thanks in advance.

Mike C
Mike C's picture
Offline
Last seen: 7 hours 4 min ago
Joined: 01/22/2014 - 08:03
Posts: 2563
Location: Sweden

Not sure which version of firmware you are looking at. Have you identified where in the code you are when the turbo times out? If so you should be able to set desired PWM_LVL and not store the mode.

Should be something like (simplified): “if ticks = turbotimeout and mode = turbo then {”

There you should be able to do a “PWM_LVL = XXX” (desired value).

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA
HighEfficiency wrote:
Cereal_killer wrote:
Mike C wrote:
I am changing the functionality of some of the features with the STAR 1.1 firmware and just want to make sure about what this line of code does: PWM_LVL = modes[- -mode_idx]; This changes the PWM_LVL (output) to the level of the previous mode but does not actually change the mode itself. This means that if this line is executed while the light is on high, the output will switch to that of medium, but the light will still “think” it’s on high and remember high as current mode if switched off. Is that correct?

Note you can also use this line to modify the turbo step down to a specific PWM value instead of the previous mode, simply replace PWM_LVL = modes[- -mode_idx]; with PWM_LVL = 180 (desired PWM value). That way you can have it step down to a level of your choice but still act normal and still be able to be bumped back up to turbo with a single click.

I use it like this in my small lights that need a large step down to not overheat.

Digging up an older concept here and hoping for some help.

I was hoping the above change in code would allow me to skip having the turbo timeout step down as an independent mode. My sense is I am one step away.

Here’s what I’m after: Low (1 value), Medium (2 value), Turbo (3 value) to step down (4th value).

As the FW is written, in order for me to have this I actually have 4 click through modes of Low, Medium, Step Down, and Turbo. I’m looking to have the turbo step down mode ONLY accessed following turbo time out. So in the end I’ll have 3 click through modes, but in operation 4 output modes.

I tried the above recommendation and then attempted to comment out “#define mode_high_w_turbo” but I was left with an error in line 259 “mode_high_w_turbo” undeclared (first use in this function)”. I assume the code is trying to reference the line I commented out but I don’t see it, and definitely don’t understand it.

With no working knowledge of C++ (other than reading through this whole thread), I was hoping I could get some help.

Thanks in advance.

Mike C is right, the concept works fine. You don’t need to comment out #define mode_high_w_turbo”, maybe that’s your mistake? Comment out other modes until you have only 3 user accessible modes (low, high-w-turbo, and turbo). Set those to your desired levels. This will give you 3 modes, then do the modification to “PWM_LVL =” discussed above:
// #define MODE_MOON			8	// Can comment out to remove mode, but should be set through soldering stars
#define MODE_LOW			14  // Can comment out to remove mode
//#define MODE_MED			39	// Can comment out to remove mode
#define MODE_HIGH_W_TURBO	39	// MODE_HIGH value when turbo is enabled
#define MODE_HIGH			120	// Can comment out to remove mode
#define MODE_TURBO			255	// Can comment out to remove mode

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)

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

RMM wrote:

fellfromtree wrote:
Ah that’s cool.. Yeah let us know how the monitoring of vcc goes wight. That sounds like fun for 1s, maybe eliminate 2 more resistors on the board

I don’t think it is directly measuring voltage, but instead using the VCC as the reference voltage instead of the internal 1.1v.  You could use it as the reference voltage with zener mod drivers or with an external voltage regulator (both with 2S+) since the voltage input will remain constant, but with 1S cells it would be pretty much useless.  You would still need a voltage divider because the voltage you would be measuring against would still be higher than the reference.  You can use it, however, for other measurements (like a temperature sensor) without needing an additional divider.

RMM is correct. I was working on measuring the entire throw of a potentiometer. Pots are setup as voltage dividers, so I need a V+ to hook up to one leg of the pot, Vcc is an easy source for that. The middle leg goes to an ADC, then the third leg goes to GND. To use this I’ve got to measure against Vcc. Really I’m going to have to toggle Vref back and forth so that I can cheaply measure both Vbat (against 1.1v using a divider) and also the pot (against Vcc).

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)

HighEfficiency
HighEfficiency's picture
Offline
Last seen: 4 years 1 week ago
Joined: 02/05/2014 - 11:33
Posts: 74
Location: USA
wight wrote:
HighEfficiency wrote:
Cereal_killer wrote:
Mike C wrote:
I am changing the functionality of some of the features with the STAR 1.1 firmware and just want to make sure about what this line of code does: PWM_LVL = modes[- -mode_idx]; This changes the PWM_LVL (output) to the level of the previous mode but does not actually change the mode itself. This means that if this line is executed while the light is on high, the output will switch to that of medium, but the light will still “think” it’s on high and remember high as current mode if switched off. Is that correct?

Note you can also use this line to modify the turbo step down to a specific PWM value instead of the previous mode, simply replace PWM_LVL = modes[- -mode_idx]; with PWM_LVL = 180 (desired PWM value). That way you can have it step down to a level of your choice but still act normal and still be able to be bumped back up to turbo with a single click.

I use it like this in my small lights that need a large step down to not overheat.

Digging up an older concept here and hoping for some help.

I was hoping the above change in code would allow me to skip having the turbo timeout step down as an independent mode. My sense is I am one step away.

Here’s what I’m after: Low (1 value), Medium (2 value), Turbo (3 value) to step down (4th value).

As the FW is written, in order for me to have this I actually have 4 click through modes of Low, Medium, Step Down, and Turbo. I’m looking to have the turbo step down mode ONLY accessed following turbo time out. So in the end I’ll have 3 click through modes, but in operation 4 output modes.

I tried the above recommendation and then attempted to comment out “#define mode_high_w_turbo” but I was left with an error in line 259 “mode_high_w_turbo” undeclared (first use in this function)”. I assume the code is trying to reference the line I commented out but I don’t see it, and definitely don’t understand it.

With no working knowledge of C++ (other than reading through this whole thread), I was hoping I could get some help.

Thanks in advance.

Mike C is right, the concept works fine. You don’t need to comment out #define mode_high_w_turbo”, maybe that’s your mistake? Comment out other modes until you have only 3 user accessible modes (low, high-w-turbo, and turbo). Set those to your desired levels. This will give you 3 modes, then do the modification to “PWM_LVL =” discussed above:
// #define MODE_MOON			8	// Can comment out to remove mode, but should be set through soldering stars
#define MODE_LOW			14  // Can comment out to remove mode
//#define MODE_MED			39	// Can comment out to remove mode
#define MODE_HIGH_W_TURBO	39	// MODE_HIGH value when turbo is enabled
#define MODE_HIGH			120	// Can comment out to remove mode
#define MODE_TURBO			255	// Can comment out to remove mode

You’re both correct. The error was in my thinking. It had not occurred to me to let the “high_w_turbo” supplant my “med” mode while reprogramming the turbo to default to a PWM level OTHER than the “high_w_turbo” setting. All is well and thanks for the help.

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

Crap - haven't checked this thread for a long time... Sorry. Someone get me up-to-date. Anyone  (oops VOB) still need the hex file?

I've been having lots of troubles as of late - can't seem to program any of the custom BLF boards. I would even think programming a ATtiny13A detached should work, but can't get that to work either. Anyone know if that should be possible? I got 6 of the 8 pins wired - all have good continuity all the way back to the USB dongle. The cable setup I have works perfect with stock Nanjg boards.

Boy... Wonder if I got a bad batch of Tiny13A's, or the wrong flavor?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 week 5 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

Every BLF custom board I’ve tried has been flashable… Ferrero Rocher F6DD, RMM BLF17DD, RMM BLF22DD, and RMM 32×7135 SRK. Some with off-time cap. Plus several flavors of nanjg/qlite.

If the soldering isn’t perfect, sometimes it’s finicky about connecting and I have to try a few times or forcefully hold the clip on, but usually it just works. However, when connecting the clip I usually wear a headlamp and sometimes stereo loupes so I can really see if the connection is good.

I have 6 pins connected, using a SOIC8 clip from Digikey and a cheap usbasp from fasttech. Some of the SOIC8 pins are getting worn though, so I might need another chip clip sometime.

With only 5 pins connected (oops, didn’t know at first I needed VCC), flashing was really flaky and verification never worked.

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

I use the Pomona SOIC clip - works fine, again, still worked well with Nanjg's. Have you ever tried programming a completely loose MCU? It clips up fine and continuity checks out all the way back to the dongle.

The MCUs I find that work are marked "ATMEL 1324" and the ones that don't work are marked "ATMEL 1222" or "ATMEL 1121". I'm trying to find out the meaning of the #'s but no luck so far -- looking thru the ATTiny13A datasheet now...

I've done lots of BLF DD boards before and programmed them fine. Not sure though - might be getting into a new batch of MCU's - this is why I'm sort of doubting the MCU now...

Update #1: They are all marked "SSU", so I believe that's the right type.

Update #2: Ok - think I found the meaning of the #'s - they are date codes, described here under Date Code Management: http://www.atmel.com/about/quality/faq.aspx#body_12

So the 2013's seem to work for me, while the 2011's and 2012's don't. Anyone got any guess's?

 

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

HighEfficiency wrote:
You’re both correct. The error was in my thinking. It had not occurred to me to let the “high_w_turbo” supplant my “med” mode while reprogramming the turbo to default to a PWM level OTHER than the “high_w_turbo” setting. All is well and thanks for the help.
You’re welcome, glad it’s working!
Tom E wrote:

I use the Pomona SOIC clip – works fine, again, still worked well with Nanjg’s. Have you ever tried programming a completely loose MCU? It clips up fine and continuity checks out all the way back to the dongle.

The MCUs I find that work are marked “ATMEL 1324” and the ones that don’t work are marked “ATMEL 1222” or “ATMEL 1121”. I’m trying to find out the meaning of the #‘s but no luck so far — looking thru the ATTiny13A datasheet now…

I’ve done lots of BLF DD boards before and programmed them fine. Not sure though – might be getting into a new batch of MCU’s – this is why I’m sort of doubting the MCU now…

Update #1: They are all marked “SSU”, so I believe that’s the right type.

Update #2: Ok – think I found the meaning of the #‘s – they are date codes, described here under Date Code Management: http://www.atmel.com/about/quality/faq.aspx#body_12

So the 2013’s seem to work for me, while the 2011’s and 2012’s don’t. Anyone got any guess’s?

 

They program fine bare. I have only experienced the opposite problem. Nanjg 105c’s from FT often don’t want to flash for me until I remove the chip from the PCB. Fresh ATtiny13A-SSU units from Mouser flash fine whether bare or mounted on a PCB. At least I think they do, I don’t keep super close track. I know I definitely flashed one of those A17DD-SO8 drivers with the MCU onboard. The PCB was w/ FET, diode, voltage divider resistors, & both caps: no problem.

I’ve been using the Pomona clip along with an USBasp I’ve had for a while, I forget the source. I’ve ordered a new USBasp from FT to see if I might get a “stronger” one. (If I do I plan to leave my current one hooked up to my ZIF socket where it always works.)

Please post the full top markings of one which is giving you trouble.

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: 2 hours 11 min ago
Joined: 08/19/2012 - 08:23
Posts: 14444
Location: LI NY

Marking for ones that don't work:

ATMEL 1222

TINY13A

 SSU

 

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

Thanks Tom E. Unfortunately I think I’ve got nothing.

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)

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

I’ve got to go to bed, but here’s a real hackjob I’ve been working on this evening. It compiles, but I don’t have time to flash it and assemble a driver before bed. There may be serious oversights.

This is intended as a proof-of-concept for a VaraPower style driver (rotary potentiometer chooses brightness) which includes low-voltage-warning and low-voltage-shutdown.

Here is what I did [thankfully not written in the order I did it]:

  1. used “STAR_1.1.c” as a base
  2. stripped out everything that I don’t think this style of driver needs, modes, turbo, etc
  3. replaced the main loop with the two-way ADC loop from the Nov 4, 2014 [1263cd98f9] version of MTN_momentary_temp.c
  4. changed the way the ADC loop switches ADC channel so that it toggles Vref back and forth as well – I think/hope? Bitwise operations are difficult for me.
  5. replaced the temperature stuff with a command to just patch that ADC value to PWM_level. Maybe ideally there would be a rolling average here, but that can come later.
  6. hacked up the LVP flashing to go full brightness during flashes
  7. hacked up the LVP to semi-function without modes. Ideally it should flash quickly 3 times every ~3 seconds until we hit critical, then flash 10 times and shutdown.
  8. copied and pasted a couple of variable initializations

  • There are certainly some power savings tricks missing.
  • I actually don’t see why we couldn’t add the potentiometer as a third ADC input and keep the temp monitoring.
  • Come to think of it, now I can imagine how to include “stepdown” in a way that makes sense. After the 3 quick flashes, implement a ceiling value. Progressively half it or whatever is reasonable. Potentiometer throw remains the same, but the actual PWM value produced is capped @ whatever whenever it is set.
    if (ADC > ceiling_value) {PWM_LVL = ceiling_value} else {PWM_LVL = ADC}
    Bingo?

As far as hooking it up… I think PB2 (eg just like normal) should be voltage monitoring and PB3 [Pin 2, Star 4] should be for the pot. You hookup the pot between Vcc and GND with the sweeper hooked up to PB3.

Here it is: http://photo.jesusthepirate.com/blf/VeraPunk/v002.c

I’m sorry in advance. Wink Wink Wink

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)

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

HighEfficiency wrote:
Cereal_killer wrote:
Mike C wrote:
I am changing the functionality of some of the features with the STAR 1.1 firmware and just want to make sure about what this line of code does: *PWM_LVL = modes[- -mode_idx];* This changes the PWM_LVL (output) to the level of the previous mode but does not actually change the mode itself. This means that if this line is executed while the light is on high, the output will switch to that of medium, but the light will still "think" it's on high and remember high as current mode if switched off. Is that correct?
Note you can also use this line to modify the turbo step down to a specific PWM value instead of the previous mode, simply replace *PWM_LVL = modes[- -mode_idx];* with *PWM_LVL = 180* (desired PWM value). That way you can have it step down to a level of your choice but still act normal and still be able to be bumped back up to turbo with a single click. I use it like this in my small lights that need a large step down to not overheat.
Digging up an older concept here and hoping for some help. I was hoping the above change in code would allow me to skip having the turbo timeout step down as an independent mode. My sense is I am one step away. Here's what I'm after: Low (1 value), Medium (2 value), Turbo (3 value) to step down (4th value). As the FW is written, in order for me to have this I actually have 4 click through modes of Low, Medium, Step Down, and Turbo. I'm looking to have the turbo step down mode ONLY accessed following turbo time out. So in the end I'll have 3 click through modes, but in operation 4 output modes. I tried the above recommendation and then attempted to comment out "#define mode_high_w_turbo" but I was left with an error in line 259 "mode_high_w_turbo" undeclared (first use in this function)". I assume the code is trying to reference the line I commented out but I don't see it, and definitely don't understand it. With no working knowledge of C++ (other than reading through this whole thread), I was hoping I could get some help. Thanks in advance.

 

When I get a chance I need to look at my code again. I built a custom one for police lights I was doing, and it functioned just as you describe. It also had the option to gradually ramp down over x number of seconds, instead of step down on the timeout. I thought I put that in the main program as a compile option, but if not I'll add it.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 week 5 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

wight wrote:
here’s a real hackjob I’ve been working on this evening.

This is intended as a proof-of-concept for a VaraPower style driver (rotary potentiometer chooses brightness)

I’m sorry in advance. Wink Wink Wink

Sounds interesting. I have no hardware to run that on, but when you get it working I’d love to include it in my collection. Smile

Pages