STAR Firmware by JonnyC - Source Code and Explanation

1335 posts / 0 new
Last post
Werner
Werner's picture
Offline
Last seen: 2 years 2 months ago
Joined: 10/19/2012 - 15:00
Posts: 3679
Location: Germany

That sounds good, code sharing in this forum is terrible and so I am quite sure a lot of useful things fall under the carpet…

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

I’m not entirely sure how to use Launchpad’s revision control tools (bzr) in Windows or MacOS, but those are both supported platforms. I think both have a few GUIs available too, but I’m not familiar with them.

I just “bzr branch lp:flashlight-firmware” to get a copy of the code, and then otherwise use bzr at the command line to check in new versions or do other common operations. The only GUI part I use is “bzr vis” from bzr-gtk, which is handy for viewing the revision history. It looks like this:

This is all optional though. I’m happy to accept patches and such via email and do all the revision control and publishing steps myself.

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

ToyKeeper wrote:
I'm happy to accept patches and such via email and do all the revision control and publishing steps myself.

This is not email, but wanted to post the enhanced _delay_ms() function here so that it won't get buried to another thread as OT post..

 

 

I have seen this "_delay_ms() can't take variables" so many times that it's time to do something for it:

 

#define OWN_DELAY
#ifdef OWN_DELAY
#include <util/delay_basic.h>
// Having own _delay_ms() saves some bytes AND adds possibility to use variables as input
static void _delay_ms(uint16_t n)
{
while(n-- > 0)
_delay_loop_2(1024);
}
#else
#include <util/delay.h>
#endif

...main...
 
#ifndef OWN_DELAY
uint16_t randTime;
#endif

while(1)
{
// turn the emitter on at a random level,
// for a random amount of time between 1ms and 20ms (* 4/3)
PWM_LVL = rand() % 190 + 10;
#ifdef OWN_DELAY
_delay_ms(rand() % 19 + 1);
#else
randTime = rand() % 19 + 1;
  while(randTime--) // _delay_ms() can’t take variables that can change, make loop with variable instead
    _delay_ms(1); // and delay_ms with fixed value within loop
#endif
// turn the emitter off,
  // for a random amount of time between 1ms and 1000ms (* 4/3)
  PWM_LVL = 0;
#ifdef OWN_DELAY
_delay_ms(rand() % 999 + 1);
#else
randTime = rand() % 999 + 1;
  while(randTime--)
    _delay_ms(1);
#endif  
}

In this example, using own delay saved us 16 bytes (with -Os) and made the code cleaner.

Enjoy! Smile

=the=

 

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

the wrote:
This is not email, but wanted to post the enhanced _delay_ms() function here so that it won’t get buried to another thread as OT post..

This is good stuff. It should probably replace the standard _delay_ms() in every firmware which calls _delay_ms() more than once. On one of my STAR derivatives, this delay function saved me at least 140 bytes.

The parameter sent to _delay_loop_2() is also a handy thing to change per-driver if you want more accurate timing, since it can be calibrated for each individual chip. I’ve tried it on three now, and the value has been anywhere from 890 to 950 if I want _delay_ms(1000) to be reasonably close to one second.

I suppose I should probably update STAR with this. I may need to upgrade my avr-gcc first though, since what I have now compiles STAR to about 1060 bytes instead of 1024.

Mike C
Mike C's picture
Offline
Last seen: 19 hours 15 min ago
Joined: 01/22/2014 - 08:03
Posts: 2585
Location: Sweden

I posted this in the random flash thread, but can post it here too:

I did a shorter one some time ago so you don’t even have to include delay_basic.h. I basically just ripped out one of the assembler loops from delay_basic.h. The variable entered does not resemble a nice even millisecond value, like 1 or 10 ms or similar, but I don’t need exact millisecond numbers, I only have to adjust the value until I like what I see.

By the way, how did you post your code? It looks like code, when I try to paste in my code it looks like garbage so I post images instead. How did you get it formatted nicely like that?

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

Mike C wrote:
I did a shorter one some time ago so … The variable entered does not resemble a nice even millisecond value

I looked into it, but I needed something with fairly precise timing so I didn’t use it.

Mike C wrote:
By the way, how did you post your code? It looks like code, when I try to paste in my code it looks like garbage so I post images instead. How did you get it formatted nicely like that?

I used the HTML ‘pre’ tag.
<pre>
(insert code here)
</pre>
comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

Helios made me a kewl Roche F6 driver (momentary switch) with two battery level indicators, but I have zero clue how to add whatever to the FW to make them work. They're run by MCU pin 3 & pin 5, circuits for both are totally separate so it's possible to use them one at a time or both together, to get a third color. Any suggestions for what the LEDs should do? Keep the original low voltage behavior (blink + ramp down) or ditch it?

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

comfychair wrote:

Helios made me a kewl Roche F6 driver (momentary switch) with two battery level indicators, but I have zero clue how to add whatever to the FW to make them work. They’re run by MCU pin 3 & pin 5, circuits for both are totally separate so it’s possible to use them one at a time or both together, to get a third color. Any suggestions for what the LEDs should do? Keep the original low voltage behavior (blink + ramp down) or ditch it?

Depends on your preference I suppose. In order to get the most mileage out of those indicators it seems that removing the ramp/step-down makes sense. Replace that with warning indications… but really I probably wouldn’t do it unless I could make the indicators pretty visible.

OTOH there’s nothing wrong with having both systems in place – a red indicator is just a confirmation that the stepdown is due to LVP.

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 8 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

I could use some help. I’m not sure what I need to do to move PWM from PB1 to PB0.

Here is what I have so far.

I changed:

  • the PWM_PIN define
  • the PWM_LVL define (output compare register)

I did not change the TCCR0A or TCCR0B stuff.

This is for the LD-29 project. In retrospect it may have made more sense to hookup the normal PWM pin… maybe that’s what I’ll end up doing.

Thanks in advance.

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 8 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

wight wrote:
I could use some help. I’m not sure what I need to do to move PWM from PB1 to PB0.

Here is what I have so far.

I changed:

  • the PWM_PIN define
  • the PWM_LVL define (output compare register)

I did not change the TCCR0A or TCCR0B stuff.

This is for the LD-29 project. In retrospect it may have made more sense to hookup the normal PWM pin… maybe that’s what I’ll end up doing.

Thanks in advance.

Bump. I could still use some help with this. Even if I hookup PB1 to the PWM input on the LD-29, I would still like to know about how this would be done. I have another project (17mm DD+7135 — linear regulated driver w/ FET turbo) which would benefit from the ability to use two PWM outputs (not simultaneously). The PCB for that project is already laid out for using both PB0 and PB1.

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

Dunno, but I’ll be quite happy if anyone has an answer… because when I get time I’d rather like to make a RGBW light with each color controlled individually… and I’m hoping I can use PWM arbitrarily on any two colors at the same time (most likely will need a better MCU though, with two PWM channels).

It might be a while before I can start on that though… too many other projects.

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

Sorry guys, was hoping someone else would chime in Wink

I've never changed the PWM from PB1 to PB0, but it looks like, along with what you changed already, you need to change TCCR0A to this...

TCCR0A = 0x83; // phase corrected PWM is 0x81 for PB0, fast-PWM is 0x83

That's my guess looking at the datasheet, which I've never been the best at reading. I just searched for TCCR0A and the first two bits relate to COM0A (PB0), and the next two bits relate to COM0B (PB1). So instead of it being "0010", it's "1000".

An outstanding thing for me to look into for RMM is the ability to change the PWM output pin based on the mode selected (so you could have a single 7135 on one pin, the rest on the other), and/or be able to change the PWM mode between phase correct and fast PWM based on the mode as phase correct does a better job with lower levels.  I'm sure this was discussed before, I just haven't been paying attention lately Sad

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

Thanks JonnyC, I’ll try that and continue to poke around in that vein if it doesn’t work by itself.

If there was a discussion about the minimum level that Fast PWM vs Phase Correct PWM could sustain, I missed it too.

I was thinking of using a 2D array to store pin states (including PWM levels) for modes. I think that could be implemented in a reasonably flexible way in order to facilitate drivers which need to do various pin sequences for modes. We currently have drivers with one PWM pin, plus drivers which operate like the DQG 26650 driver (a run pin + several pins which should be turned on exclusively for different modes), and in the future I’d really like to have a driver which operates the way I described here (#32). I think it might be possible for us to describe the modes for each of those drivers (plus the DD+7135 one I linked to before) using the same array format.

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)

zeremefico
zeremefico's picture
Offline
Last seen: 57 min 17 sec ago
Joined: 03/27/2012 - 02:44
Posts: 1390
Location: Greece


Tried to compile SRK no ramp firmware with this result.
Any ideas?

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

My YouTube channel

Flashlights & edc gear

K40M F16

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

Did you by chance have 'word wrap' enabled when you copied the source to paste it into Atmel Studio?

zeremefico
zeremefico's picture
Offline
Last seen: 57 min 17 sec ago
Joined: 03/27/2012 - 02:44
Posts: 1390
Location: Greece

Have no idea about that.
Please elaborate.

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

My YouTube channel

Flashlights & edc gear

K40M F16

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

Did you open the .c/.txt file directly with Atmel Studio? What changes did you make before attempting to build it?

zeremefico
zeremefico's picture
Offline
Last seen: 57 min 17 sec ago
Joined: 03/27/2012 - 02:44
Posts: 1390
Location: Greece

Copied it, pasted, no changes.

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

My YouTube channel

Flashlights & edc gear

K40M F16

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

OK, so, what did you copy it from? Notepad? Was 'word wrap' enabled in notepad when you copied it? Atmel Studio chokes on the line breaks if you paste in source that's using 'word wrap'. That frequently causes those kind of errors - some variable ends up being placed on a new line by itself when it really belongs at the end of the previous line. 'Word wrap' is the cause of that.

Also, your screenshot is not showing the line with the error in it (line 59), please take another shot showing what's on line 59 (double click the entry in the 'errors' list at the bottom, it will scroll the upper window to the problem line automatically).

zeremefico
zeremefico's picture
Offline
Last seen: 57 min 17 sec ago
Joined: 03/27/2012 - 02:44
Posts: 1390
Location: Greece

Will do that when I return home.
I just copied it from browser’s page.

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

My YouTube channel

Flashlights & edc gear

K40M F16

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

Showing lines 55 to 62, line 59 highlighted...

http://75.65.123.78/screenshot.21-08-2014-17.19.28.jpg

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

zeremefico wrote:
Will do that when I return home. I just copied it from browser's page.

And it only showed one error? That's pretty amazing. Save it to an actual real local file.

.c or .txt doesn't matter, if you're copy/pasting. Atmel Studio can open the .c files directly without pasting.

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

Hmm, I don't get that error when I compile. The line in question must be this...

PROGMEM  uint8_t modes[] = { MODES };

Maybe try just adding "const" in there, as it is constant (doesn't change at runtime), so it doesn't hurt for me to add that too.

PROGMEM  const uint8_t modes[] = { MODES };

Maybe you're on a slightly newer version of ARV Studio than me (5.0.1223) so it's providing better warnings?  I tried enabling all warnings and it still wasn't giving me that error.

If that's the fix I'll have to add that into the file posted on my site.

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

I don't get that or any errors when building the same source, nothing wrong on your end. But, I'm also not copying straight from a browser window.

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

Yup, must be using AVR Studio 6.

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=141164

"ok, I see what is going on here. newer avr-gcc versions demand that everything put in progmem is defined const [1]. So I had to add a cost in front of the first error line."

zeremefico
zeremefico's picture
Offline
Last seen: 57 min 17 sec ago
Joined: 03/27/2012 - 02:44
Posts: 1390
Location: Greece

I am using AVR studio 6.
Is there a solution for that error?

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

My YouTube channel

Flashlights & edc gear

K40M F16

Helios-
Helios-'s picture
Offline
Last seen: 2 years 1 week ago
Joined: 01/18/2012 - 21:12
Posts: 2099

JonnyC wrote:
PROGMEM  uint8_t modes[] = { MODES };

Maybe try just adding “const” in there, as it is constant (doesn’t change at runtime), so it doesn’t hurt for me to add that too.

PROGMEM  const uint8_t modes[] = { MODES };


Did you try that?


Counterfeit 18650s, 2,<a href=“http://

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

I think the consensus is to use either the most recent AS version, or the old reliable works-with-everything 5.1.208.

zeremefico
zeremefico's picture
Offline
Last seen: 57 min 17 sec ago
Joined: 03/27/2012 - 02:44
Posts: 1390
Location: Greece

Still away from home, I will try it and less you know.

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

My YouTube channel

Flashlights & edc gear

K40M F16

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

Oh, I got that const error too, with both gcc-avr 4.7 and gcc-avr 4.8. I just added the keyword it wanted, and it worked fine. It’s not like we modify the mode list at runtime, so making it const shouldn’t cause issues.

I’m not sure why that particular variable was declared as progmem though… I ended up removing that part too, which simplified access to it, and reduced the overall code size.

I don’t have a fully-working firmware yet though. I broke my SRK’s switch wire by taking the driver out for flashing too many times, and I’ve been too busy to fix it yet. So, that firmware is stalled.

Also, I’ve noticed that my toolchain seems to produce slightly different binaries than the windows-based tools. Not sure what exactly is different, but I think WinAVR may be passing different flags to gcc. Like, some unmodded STAR firmwares compile to like 1040 bytes instead of 1024 or less.

Pages