STAR Firmware by JonnyC - Source Code and Explanation

Which of these will be a best replacement for off time cap, 0.1uf, 0.22uf, or 2.2uf? I am planning to buy the otc and c1 10uf x7r from one ebay seller but he doesnt have 1uf x7r in stock, only those caps i mentioned are in stock.
Also what would be the effect if i use y5v capacitor on c1?

Hi to all,
tks for all your answer, youre the best! i finally found whats was the problem. My power supply couln’t deliver the proper current… well it work for 20 drivers but the other batch that i received was consumming more current??? I installed a freshly charge 18650 battery pack and and… IT WORK!

I spend some time figured it out what it was in the code to change setting in voltage monitor. It pin point the problem , but i felt a little disapointed to change some safety feature.Everything was fine from the begining! Thumb up for JohnyC for its code… its really well design! Almost bulletproof!

Tks for all your reply

Well, I bought the hardware (USBasp, Pomona clip, color ribbon, USB extender) and installed AVR Tools, the driver and RMM’s batch file. The only hard part so far was finding the right driver (Libsub0 v1.2.4.0 ) and installing an unsigned driver in Win 8.1. Is that the right driver?

Hooked the Pomona to a MCU and downloaded the BLF-VLD.hex, and got this:

C:\Hex and Flash Files>flash BLF-VLD

C:\Hex and Flash Files>avrdude -p t13 -c usbasp -u Uflash:w:BLF-VLD.hex:a
se:w:0x75:m -Uhfuse:w:0xFF:m

avrdude: warning: cannot set sck period. please check for usbasp firmware up
.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9007
avrdude: NOTE: “flash” memory has been specified, an erase cycle will be per
ed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware up
.
avrdude: reading input file “BLF-VLD.hex”
avrdude: input file BLF-VLD.hex auto detected as Intel Hex
avrdude: writing flash (882 bytes):

Writing | ################################################## | 100% 1.02s

avrdude: 882 bytes of flash written
avrdude: verifying flash memory against BLF-VLD.hex:
avrdude: load data flash data from input file BLF-VLD.hex:
avrdude: input file BLF-VLD.hex auto detected as Intel Hex
avrdude: input file BLF-VLD.hex contains 882 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.69s

avrdude: verifying …
avrdude: 882 bytes of flash verified
avrdude: reading input file “0x75”
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0x75:
avrdude: load data lfuse data from input file 0x75:
avrdude: input file 0x75 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying …
avrdude: 1 bytes of lfuse verified
avrdude: reading input file “0xFF”
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xFF:
avrdude: load data hfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying …
avrdude: 1 bytes of hfuse verified

avrdude done. Thank you.

C:\Hex and Flash Files>

So, did it work? I don’t have a light to test it with, and my test bench isn’t up yet—but a 5-pound, finned, heat sink came in today, so I’m a little closer.

This is the only warning I get:

avrdude: warning: cannot set sck period. please check for usbasp firmware up

I get this warning using the avrdude test string also. Can I just ignore this warning? Is there a way to get rid of it?

Thanks in advance.

looks like it worked to me

Looks good. Don't worry about that warning.

Well that was painless. Do you know what the “cannot set sck period” warning is? I’ve seen it before in these threads.

Also, is the source code C? I want to study the correct version of C. Some computer guy I met snow camping this weekend recommended Lynda.com to learn C.

Thanks again.

Oops RMM, looks like I typed over you.

It's a modified C, so the basics are there but there are some differences. There are some good guides to programming Atmel MCUs online. If you're not already proficient, and your goal is specifically to program Atmel, then I would focus on Atmel programming tutorials and not generic C or C++ tutorials.

Can I use C++ on the AVR?

It uses a limited version of C with some assembly-like conveniences thrown in for direct access to hardware features. An atmel-specific guide would be far more helpful than a generic C guide, and either one would be light years ahead of a C guide. Even a simple C program probably wouldn’t fit on an attiny.

The main ways that its version of C is limited are that the MCU lacks some basic operations — so if you use those it must emulate the process, and that takes up a lot of extra room. Specifically, floating point math is probably a bad idea (use integers instead), and it uses a lot of room for each multiply or divide instruction… so try to use addition, subtraction, and bitwise shifting instead. Also try to use 8-bit integers when possible, since that uses significantly less room than 16-bit or 32-bit.

Oh, and most standard C library functions will also use a lot of extra room… so you may want to write your own minimal versions instead, if you need anything from the standard libraries. The atmel-specific libraries are pretty decent and compact though.

Other space-saving tricks are to use data tables instead of logic (when possible), and try to avoid accessing ‘volatile’ variables or variables which were defined outside the local scope. Don’t use interrupts unless absolutely necessary. And always compile with -Os to optimize for size.

First off, thank you for all your help. Glad I didn’t go barking up the C tree.

So, my first attempt at testing/programming went without a hitch. That was on a pre-made board.

With that success in my pocket, I opened my Digikey box and pulled out one of the Attiny13As from the tube. First off, finding pin 1 was hell with these 50 something eyes. Had to use my 30X stereo microscope to see a slight notch above the pin (which didn’t match the datasheet, BTW). I’ve worked with much smaller chips and finding pin 1 was never that hard. Pin one found, I attached the Pomona clip to the bare chip and did a test. “Target not found” was the error message. Tried it a few times on two different chips—same error message. Dumbfounded, I remembered that I had the programmer set to 3.3 volts (which worked before on the star board), so I set it to 5 volts and tried it again. Success! Reads and writes every time at 5 volts. I don’t ask why anymore (especially since I’m using a $4 programmer with questionable components). I just declare victory and move on.

Hope this helps someone…

Anyone?

I'm not sure which would be the better replacement between the 0.22uF and 2.2uF. Either one of those is going to require some tuning and tweaking (not worth the hassle, in my opinion). My opinion: don't cheap out. Pay the extra $1, get the proper parts, and save yourself the headache.

Same goes for the Y5V. They aren't as temperature stable and may give you switching issues over time and with heat exposure. With off-time memory capacitor stability affects the timing, so you don't want it to drift too much.

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.

For those that don’t know how to do it, here are the details:

For this to work you have to change a fuse settings in the AVRDUDE command. “Brownout detection” must be enabled. Snipped from Alex site:
“Example of working fuse bit configuration avrdude arguments: -U lfuse:w:0x79:m -U hfuse:w:0xed:m”

The code:
First you need a byte in the “no initialise” area. Define it like this:

http://pastebin.com/embed_iframe.php?i=W6F8DCRr

When the light is on normally (after all start up code) you set it to 0 with “OffCheck = 0”.

On startup when detecting a short press, just check if it is still 0 with “if (!OffCheck)”.

With the brownout fuse set the OffTime integer value survives short off presses because of the input capacitor. It decays away after about half a second. Decayed non initialised bytes are 0xFF (all bits 1), the exact opposite to 0 (all bits 0 ). Meaning if the OffCheck value is still 0 it was a short press. If it’s not 0, it has decayed to 0xFF meaning the light was off for longer.

Brownout detection works pretty well for distinguishing between short (< 0.5s) and long (> 0.5s) presses.

I haven’t made a STAR clone with it yet, but I have a non-STAR firmware published and working if you want a reference. It’s ToyKeeper/s7/s7.c in my repo linked below. It may be a bit on the fancy side though, with 15 different modes… but at least you don’t have to cycle through them to use just the basic “normal” modes.

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?

? 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...!?!

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.

Change the shift register code to this:

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

This inverts the logical value of the input pin.

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!

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