STAR Firmware by JonnyC - Source Code and Explanation

1335 posts / 0 new
Last post
Crux
Crux's picture
Offline
Last seen: 4 weeks 9 hours ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

ToyKeeper, I'm having no luck with the Offtime-Cap firmware. I'm not seeing any blinking when turning on-off-on etc. Maybe I don't understand how to use it, can you offer any advice?

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

? Blinking ? 

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

Crux
Crux's picture
Offline
Last seen: 4 weeks 9 hours ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

RMM wrote:

? Blinking ? 

The Offtime-Cap.c (.hex) firmware blinks out the ADC value of the voltage on the Offtime cap. This helps tweak the short press and medium press values for mode switching in other firmwares.

I think...!?!

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

Crux, does it turn on at all?

Maybe the first level is too low to light up the emitter.

And if it won’t change modes, the OTC values are probably way off.

I’m just guessing though.

Oh, wait. You mean offtime-cap.c? You might want to set BLINK_PWM to a higher number, perhaps. If it’s set high enough, it should at least blink once briefly after it turns on, since a zero will still register. But it’s half as bright as the regular blinks, and much shorter, so it might not light up at all if the #define is too low.

For a value of 203, for example, it should blink out “_ _, ., _ _ _”. Or for a value of 0, it should blink out a single “.”.

But, of course, if it gives you a zero, the OTC is either not working or has been off for a long time.

dthoang
Offline
Last seen: 6 months 3 weeks ago
Joined: 10/09/2014 - 13:30
Posts: 319
Location: Austin, TX USA

dkuku wrote:
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

Quote:
int is_pressed()
{

// Keep track of last switch values polled

static uint8_t buffer = 0×00;

// Shift over and tack on the latest value, 0 being low for pressed, 1 for pulled-up for released

buffer = (buffer << 1) | ((PINB & (1 << SWITCH_PIN)) == 0);

return (buffer & DB_REL_DUR);
}


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

Change the shift register code to this:

	buffer = (buffer << 1) | ((~PINB & (1 << SWITCH_PIN)) == 0);

This inverts the logical value of the input pin.

one year rookie

Crux
Crux's picture
Offline
Last seen: 4 weeks 9 hours ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

I must have a compile issue. The .hex from your repository runs, but the blinks are too short for my driver. When I change BLINK_PWM and rebuild (Studio 6.2) the PWM pin just goes to 1 volt (?!) with no pwm. The .hex file I made is 132 bytes yours is 688 bytes.

Let me redo this from scratch, I have something wrong here.

EDIT: Working fine now (deleted all and recreated project) - operator error. Thanks ToyKeeper!

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

Ah, now I see what you're talking about.  (I obviously don't have any idea what I'm talking about!) Foot in Mouth

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

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

Okay, was BLINK_PWM the only thing you needed to change?

To help make it work on more drivers, I set it to 20 and re-published a new build. That way, even the “zero” blink will be at a level of 10, which should show up on almost anything.

Crux
Crux's picture
Offline
Last seen: 4 weeks 9 hours ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

Yes, all I changed was BLINK_PWM (to 40, because of my PWM-to-analog driver). 10 is probably fine for the bulk of the drivers. Of course after that success I also changed the Vref to Vcc just to see where the OffTime cap voltage range is. My driver runs on either two or three cells, so Vcc is stable at 5V. With 1.1V vref I was reading 255 on short clicks. With Vcc vref the counts were at 60 to 45 range. I'll need to do some more testing to find good values for medium and short presses.

So now I've been working with Battcheck.c to figure out where that count is. I plan on adding a second low battery step-down mode, one at 9V and one at 6V. Somehow I need to differentiate between three dead cells (9V), and two full cells (8.4V).  Sounds like disaster waitin' to strike. Smile

I not asking for help (yet) but I'm open to any advice.

THANK YOU for posting and hosting these programs as well as the others in the repository.

T-boon
Offline
Last seen: 8 months 1 week ago
Joined: 02/22/2015 - 00:20
Posts: 191
Location: israel

hey, im looking for a “step by step” tutorial for programing the Attiny13A useing an arduino,
just like drdanke did here in post #29, but if possible with more details and maybe even a video,

i like the idea of not need to buy the programer and the clips, and i do have the arduino alrady.

thanks.

LED Boatguy
Offline
Last seen: 1 year 3 months ago
Joined: 02/10/2015 - 17:28
Posts: 73
Location: Kollyforneah
ardvaark wrote:

 “cannot set sck period” warning is?


Only means that your usbasp device is not running the latest firmware. Nothing to worry about. You are only missing some features of the new firmware. I forget exactly what they are at the moment but for our purposes it is of no consequence.

However, if you are interested and have another usbasp you can set J2and install the new firmware from http://www.fischl.de/usbasp/

One of the cool features that I really like is being able to slow the programming down to around 93.75khz

Just so happens I have another USBasp on the way. I found the latest firmware and will update one of the units when it gets here. BTW: I’m not used to handling things like this with open chip leads w/o being grounded with a wrist strap. Has anyone had an ESD failure? I think when I’m done flashing the new firmware, I’ll slip it into some 3/4” clear heatshrink tubing and shrink the two ends.

I took the next step and loaded Atmel Studio 6.2 (along with some serious bloatware from Microsoft). So far, all the c files I’ve looked at compiled fine. Finding the optimization settings was a hoot. Looking at the code, quite a bit of it makes sense.

This is all coming together just in time, because the 22mm 16 × 7135 boards arrived from OSH today, and the F13 light is in transit. I’ve got two or three other projects underway as well plus a test bench.

Thanks to all of you for your help and support.

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

No ESD problems yet, and I've programmed a few. 

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

Microa
Offline
Last seen: 15 min 59 sec ago
Joined: 06/29/2011 - 21:20
Posts: 246

If I want to change the switch pin to Star 3 and the temperature sensor to Star 4 of MTN_momentary_temp, should I simply modify these lines:

#define SWITCH_PIN PB3 to #define SWITCH_PIN PB4

#ifdef VOLTAGE_MON
volatile uint8_t adc_channel = 1;
#else
volatile uint8_t adc_channel = 2;
#endif

to

#ifdef VOLTAGE_MON
volatile uint8_t adc_channel = 1;
#else
volatile uint8_t adc_channel = 3;
#endif

also modify the adc_channel to 0×03 (PB3)

// Switch ADC to temp monitoring
adc_channel = 0×03;
ADMUX = ((ADMUX & 0b11111100) | adc_channel);
} else if (adc_channel == 0×03) {

Thanks for your comments.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 3 hours 54 min ago
Joined: 01/12/2013 - 14:40
Posts: 10761
Location: (469219) 2016 HO3
Mike C wrote:
If you’re only going to have one type of press and can do simple coding, don’t even bother with an off time cap. Using brown out detection method works very good.
ToyKeeper wrote:
I haven’t made a STAR clone with it yet, but …

Okay, I made a version of STAR which uses brownout detection instead of an offtime capacitor. It’s just STAR_off_time 1.3 with that one thing changed; otherwise it’s identical.

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/h...

Not guaranteed to work on every attiny13-based driver, but it works on all the ones I tried. I hear the brownout timing can vary depending on some of the other driver components.

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

Everytime I read “Brownout” my mind immediately thinks “dust storm.”

I may just have to try that sometime, but I have a lifetime supply of OTC’s, so we’ll see if I ever get around to it.

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

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

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

There isn’t really any advantage to it if you already have an OTC installed. It might save a few bytes, I guess, but mostly it’s just to get an offtime-based UI on lights which don’t have (or can’t fit) the capacitor. I use this trick on a couple qlite/nanjg drivers.

LED Boatguy
Offline
Last seen: 1 year 3 months ago
Joined: 02/10/2015 - 17:28
Posts: 73
Location: Kollyforneah

I use a USBasp 2.0 programmer and grew tired of the annoying “cannot set sck period” error message every time I used it, so I fixed it (updated the firmware) for $3—and ended up with a backup programmer in the process. I gleaned the following info from a few sites including the programmer’s site. This only works if you’re currently using a USBasp 2.0 programmer.

1. Buy a USBasp 2.0 with 10-wire ribbon from Ebay, Fasttech or wherever.
2. Choose which programmer you’re going to update (the target) and mark it with a permanent marker or something,
3. Document your clip ribbon connections to your existing programmer and remove them.
4. Optional: Make sure your new programmer works. Connect to a clip, clip to an attiny13a, and test the connection. I use “avrdude –p t13 –c usbasp –n” (without the quotes).
5. Jump JP2 on the target USBasp to put it in programming mode.
6. Connect the two USBasps with the 10-wire ribbon. It can only connect one way.
7. Get the new firmware either from the developer (needs to be compiled) or get the hex file here . Lazy arse that I am, I got the hex file.
8. Put the hex file in the correct directory.
9. Plug the non-target USBasp into the USB port
10. The new firmware requires different fuse settings on the target programmer’s processor. I used the command line “avrdude –c usbasp –p atmega8 –u –U hfuse:w:0xc9:m –U lfuse:w:0xef:m” (without the quotes).
11. Flash the hex file to the target USBASP to update the firmware. I used the command line “avrdude –c usbasp –p atmega8 –U flash:w:usbasp.atmega8.2011-05-28.hex” (without the quotes). If you made your own hex file, use it in the command line.
12. Disconnect the 10-wire ribbon and remove the jumper from the target.
13. Connect the clip ribbon to the target and repeat #4 above. The “cannot set sck period” error message is now a thing of the past.

You should now be able to flash error free. Oh, I had both programmers set to 5 volts.

I have only flashed one chip with the new firmware, and it works, but I am leaving the non-target with the old firmware just in case there is some issue down the road.

Hope this helps someone and good luck!

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

I think you're the only person who has ever cared to update their firmware.  It's never caused any problems for me or anyone else that I'm aware of, so my opinion has always been "if it isn't broken, don't waste time trying to fix it".  

That said, I applaud you for figuring out a fix for something that isn't really broken just because it bugs you.  It sounds like you'll fit in really well here (we've all been known to do things like this).  Sealed

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

Tom E
Tom E's picture
Online
Last seen: 3 min 45 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14725
Location: LI NY

ToyKeeper wrote:
Mike C wrote:
If you're only going to have one type of press and can do simple coding, don't even bother with an off time cap. Using brown out detection method works very good.
ToyKeeper wrote:
I haven’t made a STAR clone with it yet, but ...
Okay, I made a version of STAR which uses brownout detection instead of an offtime capacitor. It's just STAR_off_time 1.3 with that one thing changed; otherwise it's identical. http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/h... Not guaranteed to work on every attiny13-based driver, but it works on all the ones I tried. I hear the brownout timing can vary depending on some of the other driver components.

TK - I tried this firmware on a single sided Nanjg 101-AK-A1 (from IOS) with 2 added 7135's (2.1A total). This driver really has no space for the OTC cap I could find for it. Mostly it worked great:

  • quick click detection had excellent timing and works reliably
  • LVP kicks in at just about exactly 3.0v, but with an issue:

--> It blinks 3 times ok, but immediately goes into moon mode after that, instead of ramping down. I'm using your recommended fuse settings (not sure what those settings mean: -Ulfuse:w:0x79:m -Uhfuse:w:0xed:m). Everything else is untouched, your original code, but set my own mode PWM values, including 5 for moon mode assuming that's the minimum for 7135's.

I carefully reviewed the LVP code and didn't see any differences, and the logic appears correct, using the ALT_PWM port value. Looks like it should cut output in half each time, then decrement modes when the PWM value falls below the next, etc...

Any ideas why this is happening? Does LVP work ok for you in this firmware? Almost seems like reading ALT_PWM is not working well, or something...

Edit: This is a pretty good fuse setup web app for the ATTiny13A: engbedded.com fuse app

 

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

Interesting. It could be a fuse value, perhaps, since I didn’t change anything except the memory method and fuse settings. Or it could be a bug inherited from STAR_off_time. The fuse values were copied from alexvh’s posts, but I’m not sure why some bit changed. I suspect that 0×75 and 0xfd should work, but I’ve only actually tried 0×79 and 0xed. Perhaps I can test LVP with various fuses soon…

Tom E
Tom E's picture
Online
Last seen: 3 min 45 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14725
Location: LI NY

ToyKeeper wrote:
Interesting. It could be a fuse value, perhaps, since I didn't change anything except the memory method and fuse settings. Or it could be a bug inherited from STAR_off_time. The fuse values were copied from alexvh's posts, but I'm not sure why some bit changed. I suspect that 0x75 and 0xfd should work, but I've only actually tried 0x79 and 0xed. Perhaps I can test LVP with various fuses soon...

Ok - I fixed it now. First, I re-produced it on another Nanjg 101-AK-A1 (short story: 1st light sold as soon as I showed it to someone...). This was a 2.45A build, but same exact firmware of STAR_NoInit. It has the same exact problem, but this time I notice after the 3 blinks, it actually turns off for a couple secs, then turns on at a moon mode level -- weird.

So again, I studied the code and only possible issue I could see is the manipulations of ALT_PWM_LVL, which is really the I/O register OCR0A. So, I added a variable called: 'setPwmOut' that mirror images the PWM output, and referenced it instead of ALT_PWM_LVL in the LVP code. Then viola!! Re-built and works perfectly. You can see it now go thru 3 blinks, then drop, repeatedly, which is how it should work. Also I fixed a potential bug in the Main LVP code where mode_idx is decremented where it could potentially be 0 before the decrement.

The decrement is below this comment (code inserting sux in a thread post), add an if " if (mode_idx > 0)" before "mode_idx++":

        // See if we should change the current mode level if we've gone under the current mode.

Ohhh - I use AtmelStudio 6.2 with the optimized for size setting - all same compile/build settings as my eswitch and STAROffTime projects which work well, including LVP. 

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

Awesome. Could you send me a patch, or the source you’re now using? I’d like to fix it in my repo too.

Tom E
Tom E's picture
Online
Last seen: 3 min 45 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14725
Location: LI NY

Sure.. My version has some additional formatting changes, always backs off the mode index by 1 when  a turbo timeout occurs (so 1 click restores turbo), and disables the moon mode STAR setting (commented out). @work now with no access to it, but I'll try this eve. You probably should grab all my latest to update your repository with. I'll try to throw together some readme text files for each to list the changes/enhancements.

Really love the quick click mode change of this noinit version. The OTC cap versions always seem to have issues of variation of timing, and so far, this one has been a rock. From what I can see, the 2 main changes to the fuses is the 64 msec delay option vs. the 4 msec delays option, and the brown-out detection enabling. Thinking the 64 msecs give it more time for the memory to change, so the timing of the mode change detection is better/shorter. The brown-out detection enabling is the key to it working at all, I would think.

Crux
Crux's picture
Offline
Last seen: 4 weeks 9 hours ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

Tom E wrote:
So, I added a variable called: 'setPwmOut' that mirror images the PWM output, and referenced it instead of ALT_PWM_LVL in the LVP code.

When you say "mirrored" do you mean reversed? or do you mean copied?

Tom E
Tom E's picture
Online
Last seen: 3 min 45 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14725
Location: LI NY

Smile - in CS/IT, never heard of mirror imaging doing anything reverse - interesting analogy.. I mean copy, a local copy of the I/O register.

 It's an old trick (I'm old too) to have a local copy of registers, specially when they are write-only. These registers (OCR0A and OCR0B) are doc'd as R/W, so either there's something quirky with them, or the C compiler has some bug/issue with doing manipulations on registers, dunno, or could be some flaky bug in our software that somehow corrupts something, and my change simply moved things around so the effect is minimized. I've seen it all from chip bugs to SW tool bugs, and got burned a few times on C compiler problems. We've had a few C compiler bugs on our current project at work using a TI DSP and the development tools that support them. Back in the mid-late 80's and 90's, I believe the compilers were better - they were developed in the US either directly by the chip manufacturer or direct contractor. Now everything goes overseas and the rigorous quality and testing standards have diminished. It's all bout saving money now...

Crux
Crux's picture
Offline
Last seen: 4 weeks 9 hours ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

Sorry - That's my engineer curse throwing doubt in my interpretations. Anyone else would know exactly what you meant.

I figured you meant 'copy', and now upon further refection, I can't imagine why you would 'reverse' it, but I asked first and thought second.

LED Boatguy
Offline
Last seen: 1 year 3 months ago
Joined: 02/10/2015 - 17:28
Posts: 73
Location: Kollyforneah
RMM wrote:

I think you’re the only person who has ever cared to update their firmware.  It’s never caused any problems for me or anyone else that I’m aware of, so my opinion has always been “if it isn’t broken, don’t waste time trying to fix it”.  

That said, I applaud you for figuring out a fix for something that isn’t really broken just because it bugs you.  It sounds like you’ll fit in really well here (we’ve all been known to do things like this).  Sealed

I did it because I can Silly . And now I have a spare programmer in case one goes Tango Uniform.

…And what did it cost me? $3 and maybe 2 hours of net surfing/zapping.

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

I had to go byte hunting again, both in program space and available RAM, to fit in a function in a light that has a 13A MCU. I still had some code left from the original Star and found a way to free up some much needed space.

The eeprom_read_block funtion eats a fair chunk of programming space and the eep array eats half of the 13A’s RAM capacity.

eeprom_read_block(&eep, 0, 32);
while((eep[eepos]==0xff) && (eepos<32)) eepos++;

Instead of reading a 32 byte block, read one byte at a time.

while (modeidx==0xff && eepos<64) {
	while (EECR & 2);
	EEARL = eepos;	EECR = 1; modeidx = EEDR;
	while (EECR & 2);
	if (modeidx==0xff) eepos++;
}

There are only advantages to this. Not only did it save me 32 bytes of programming space, it frees up the 32 byte eep array just hanging around eating up half of the 13A’s RAM capacity, and it also allows using the full 64 bytes of the EEPROM for wear leveling. I can’t notice any difference in mode reading time either, and I tested with the full 64 byte wrap around.

I probably don’t have to do the second wait after reading, but I need to be sure that no EEPROM reading or writing is going on before continuing. If I have to hunt down a few more bytes I’ll take a closer look at that…

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

Mike C, I did the same thing in the blf-a6 firmware. Smile

So, the blf-a6 code can be used as a reference for handling eeprom more space-efficiently. It also shows how to store multiple values, if desired, or how to store just the mode index. (full blf-a6 uses multiple values, trimmed-down version just stores one value)

BTW, there are some library functions which can be used instead of accessing the eeprom registers directly. This should make the code a little more portable to different MCUs, and might also make the code smaller or less likely to break.

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

BTW, I’m not really sure where to announce this, but I added a tagging system and an auto-generated index to the firmware repository. I hope this will make it easier for people to find code relevant to their needs.

The latest index should always be here:

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/he...

Pages