STAR Firmware by JonnyC - Source Code and Explanation

1335 posts / 0 new
Last post
Microa
Offline
Last seen: 19 hours 10 min ago
Joined: 06/29/2011 - 21:20
Posts: 251

I have just downloaded the off_time_V1.3, may I ask what are the changelog ?

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

Microa wrote:
I have just downloaded the off_time_V1.3, may I ask what are the changelog ?

JonnyC graciously left v1.2 up on his site, so we can diff them. To me it looks like he changed two things:
  1. in v1.2 ADC_LOW and ADC_CRIT got declared twice. v1.3 corrects this.
  2. reduced low/crit values by 2/256 units each.

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)

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

Yes, that's the main difference (ADC values defined twice.)

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

Microa
Offline
Last seen: 19 hours 10 min ago
Joined: 06/29/2011 - 21:20
Posts: 251

Thanks wight, I see the differences now.

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

Yeah, sorry, I didn't keep a change log for the first few changes, so i didn't want to start now Wink

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 1 year 1 week ago
Joined: 03/29/2013 - 04:47
Posts: 588

I thought it might be a nice idea to move the 1u capacitor for off-time memory to a different place, between star2 and star1 (gnd).
But after some research I assume this won’t work.

According to the ATtiny13A datasheet, only PB2, PB3 (Star4), PB4 (Star3) and PB5 are an ADC Input Channel, whereas PB0 (Star2) and PB1 are not.

Quote:
___Table 10-3.___ PB5 ADC0: ADC Input Channel 0 PB4 ADC2: ADC Input Channel 2 PB3 ADC3: ADC Input Channel 3 PB2 ADC1: ADC Input Channel 1 PB1 AIN1: Analog Comparator, Negative Input PB0 AIN0: Analog Comparator, Positive Input

Does this mean only PB3 and PB4 can be used for the 1u capacitor, but not PB0?

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

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

HarleyQuin, that is what I have been assuming.

Why did you want to move the cap? When I first tried the offtime firmware I was planning on placing the cap directly between the physical Pin2 (pin that conects to Star 4) and GND. I did it, but had some other problems and ended up needing to remove the cap to reflash a couple of times – in the end I put it on the bottom between the star and GND and never put it back. So I never fit it to a flashlight while assembled that way. I’ll probably try again.

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)

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

I generally do just put it on the physical star, but I have built a few lights where I wanted the entire underside to be flat so there and on the FET drivers I just reflowed it between ground and the attiny pin.

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

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 1 year 1 week ago
Joined: 03/29/2013 - 04:47
Posts: 588
wight wrote:
Why did you want to move the cap?

All started with the Nanjg 101-AK-A1 (4× 7135). Very nice driver for smaller lights with the advantage of being single sided, no stars to be shorted with a retaining ring, room for a large and flat spring. But, as you can see…

… on the 101 there are only bad places for the capacitor, a change of firmware would always need desoldering. Blue is what the firmware suggests, red would still be nicest, but that is Pin5/PB0 (Star2). Yellow is what I seem to have to end up with, using a 0805 package capacitor and changing the firmware so that Pin3/PB4 (Star3) manages the memory.

While considering I compared it to the 105C. Having too large capacitors (SMD 1210, 1206), at the blue place it will collide with the pill. Red would be similar to the place on the 101, so I thought of Star2, which is connected to Pin5/PB0. Well, the green place between Star2 and Star1 would be just perfect: easy to solder and not colliding with anything. But I think I will use a 0805 package capacitor at the yellow place on this one.

With the 47A it’s easier. Each Star has a related solder point on the component side and a GND solder point nearby (marked R2, R3 and R4). Perfect for the cap.

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 1 year 1 week ago
Joined: 03/29/2013 - 04:47
Posts: 588

Perhaps someone has use for this compilation without my markings, so I might as well add it here. The 6 Nanjg pictures are from Fasttech, as are my driver.

Just follow the link behind the picture.

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

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

Thanks for the pics HarleyQuin – clear driver pictures are always an asset.

I’ve started modifying the STAR (SRK_no_ramp_1.0.c) firmware to run the DQG 26650 EDC triple light. EDIT: which is an e-switch setup with a pretty unique method for controlling modes.

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: 7 months 1 week ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

Very nice wight.  How does the UI work?  Richard gave me a slight nudge to finally get the dual switch program written, something I've been planning on doing for months but just haven't created the time.

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

Glad to hear that you're working on a dual switch program! I think many modders and users would love that. With 4 easy to define user inputs (2 short and 2 long presses) you can easily do up/down and special/off.  That would satisfy basically all of the things people have asked for... as long as they build a dual-button light of course.

I'm not sure what you're asking me though.  The UI should be the same as your original one if I've done things correctly.  I don't own one of those flashlights, so I am unable to describe the stock UI.  Ahh.. I probably wasn't clear in saying "a pretty unique method for controlling modes".  I meant that the driver board does not use a PWM, serial, or other conventional way of controlling the modes.  They are controlled through a series of 4 pins on the MCU.  You bring them up like this for the 4 modes:
none: OFF
RUN_PIN: LOW
RUN_PIN & MODE1_PIN: MEDIUM
RUN_PIN & MODE2_PIN: HIGH
RUN_PIN & MODE3_PIN: TURBO
 

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: 7 months 1 week ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

Ahhh whoops!  I misread your post thinking that the light you were using this program on had two switches.  Nevermind!

Mike C
Mike C's picture
Offline
Last seen: 1 week 3 days ago
Joined: 01/22/2014 - 08:03
Posts: 2585
Location: Sweden

I’ve got my programmer and AVR Studio 5.1 set up (thanks Comfychair for your excellent howto). I’ve been looking at the STAR 1.1 version (and a few others people have posted here) and have a quick tip for us lazy people on how to calculate the voltage levels for ramping and low voltage cut off.

In the source code this comment is the original formula: Value = (V * 4700 * 255) / (23800 * 1.1)
For me that’s just unnecessarily long. If I understand it correctly, these values are not that accurate in terms of exact voltage, so why not make the formula simple instead? Like Value = V * 45.78? It’s the same thing (well, almost the same thing. Value = V * 45.779220779220779220779220779221 would be EXACTLY the same thing).
Sorry if this has been posted, I read through this thread but didn’t see it in that case.

Also, what is the reason for this:
#ifdef MODE_TURBO
#undef MODE_HIGH
#define MODE_HIGH MODE_HIGH_W_TURBO
#endif
As you are programming the modes yourself, why would you want to do this rather than just change the MODE_HIGH to what ever you wanted in the first place? Why have a MODE_HIGH_W_TURBO? Turbo mode is not selectable by soldering stars so I see no point in doing this. If you have edited turbo mode on or off you should be capable of editing the MODE_HIGH to be want you want it to be, it is simple enough. What is the reasoning behind having this MODE_HIGH_W_TURBO?

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

Wait, does the attiny13a have the ability to do floating-point math? Is it actually built in or does the compiler fake it? Does it use up a bunch of extra ROM space (for fake FP-handling code) if the program includes floating-point math?

I was assuming these were integer-only.

Mike C
Mike C's picture
Offline
Last seen: 1 week 3 days ago
Joined: 01/22/2014 - 08:03
Posts: 2585
Location: Sweden

It’s not the code itself, it’s the comments on how to calculate the value from the desired voltage I was referring to. The end value used in the actual code has to be rounded to an integer either way.

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

Mike C wrote:
Also, what is the reason for this: #ifdef MODE_TURBO #undef MODE_HIGH #define MODE_HIGH MODE_HIGH_W_TURBO #endif As you are programming the modes yourself, why would you want to do this rather than just change the MODE_HIGH to what ever you wanted in the first place? Why have a MODE_HIGH_W_TURBO? Turbo mode is not selectable by soldering stars so I see no point in doing this. If you have edited turbo mode on or off you should be capable of editing the MODE_HIGH to be want you want it to be, it is simple enough. What is the reasoning behind having this MODE_HIGH_W_TURBO?

This is for when someone programs a lot of different lights, and they can just set it and forget it and only worry about enabling or disabling turbo.

Mike C
Mike C's picture
Offline
Last seen: 1 week 3 days ago
Joined: 01/22/2014 - 08:03
Posts: 2585
Location: Sweden

I’d think that someone who programs a lot of different lights would have a lot of different source files, I know I will Smile But I guess it’s down to personal preference…

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

Compile-time options are generally a good thing. They almost literally make the world go around.

Normally, it’s used so that a configuration script can auto-configure a program to build and run correctly based on what it detects about the host system, and compile-time options like that were probably part of the build process for 90% of the programs on your computer. The only real difference here is that it’s a human defining the parameters instead of a script.

WarHawk-AVG
WarHawk-AVG's picture
Offline
Last seen: 1 year 6 months ago
Joined: 01/04/2014 - 06:47
Posts: 5071
Location: H-Town

wight wrote:
WarHawk-AVG wrote:
Oh nice!!!
(I think I can sneak that one Wink )
I broke down and “snuck one” myself just now. I ordered mine from here since the listing I linked to before is done. Good luck to both of us with this cheapest of programming sockets… Wink
Got mine in wight…just gotta solder some leads to it and give it a whirl Big Smile
wight
Offline
Last seen: 1 year 8 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

WarHawk-AVG wrote:
wight wrote:
WarHawk-AVG wrote:
Oh nice!!!
(I think I can sneak that one Wink )
I broke down and “snuck one” myself just now. I ordered mine from here since the listing I linked to before is done. Good luck to both of us with this cheapest of programming sockets… ;)
Got mine in wight…just gotta solder some leads to it and give it a whirl Big Smile
Sweet, keep us posted. Looks like I’ll know whether my two bucks was a wasted investment long before I receive the product. ;)

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)

Mike C
Mike C's picture
Offline
Last seen: 1 week 3 days ago
Joined: 01/22/2014 - 08:03
Posts: 2585
Location: Sweden

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?

WarHawk-AVG
WarHawk-AVG's picture
Offline
Last seen: 1 year 6 months ago
Joined: 01/04/2014 - 06:47
Posts: 5071
Location: H-Town
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?

What are you wanting to do?

Mike C
Mike C's picture
Offline
Last seen: 1 week 3 days ago
Joined: 01/22/2014 - 08:03
Posts: 2585
Location: Sweden

WarHawk wrote:

What are you wanting to do?

I want to understand what that line does exactly Smile

I am experimenting with different behavior for low voltage step down and critical volt shut of, such as not blinking “off” but blinking with the same PWM_LVL of the mode it will switch to after the warning flash, and am also contemplating weather I want the driver to remember this as the new mode, or keep original mode in memory but running PWM_LVL as the previous lower mode. To me it looks like that line just changes the output and not the mode, but I am no programmer so I just wanted to ask as I don’t have a good testing facility set up in order to test this myself… yet…

Mike C
Mike C's picture
Offline
Last seen: 1 week 3 days ago
Joined: 01/22/2014 - 08:03
Posts: 2585
Location: Sweden

As my question is more about programming syntax than the actual firmware, disregard it. I have software developers at work, I will ask one of them.

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

Your understanding is correct.

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: 7 months 1 week ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

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?

Yup, that's just for Turbo.  It's so that when you turn it off and back on it will switch back to Turbo, and not the previous level that it stepped down to.

EDIT:  Oops, and yes, it does the same thing for the low voltage ramp down.  You're correct in that it doesn't save the mode, that only happens when store_mode_idx is called.

Cereal_killer
Cereal_killer's picture
Offline
Last seen: 1 year 11 months ago
Joined: 07/22/2013 - 13:10
Posts: 4005
Location: Ohio
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.

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

Mike C
Mike C's picture
Offline
Last seen: 1 week 3 days ago
Joined: 01/22/2014 - 08:03
Posts: 2585
Location: Sweden

Cereal_killer wrote:
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 other than hobby 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.


Yes, I saw that JW980 had done that in his code.

Has anyone written a simple delay command, like a long loop? I’ve noticed that including util/delay.h and using the _delay_ms() function eats a lot of memory. I’m running out of space and would think that a simple loop that doesn’t do much could achieve the same result using less memory. It would be tricky to time accurately but exact timing on warning and cut off blinks does not really matter to me. Any one tried it?

Pages