Did you open the .c/.txt file directly with Atmel Studio? What changes did you make before attempting to build it?
Copied it, pasted, no changes.
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).
Will do that when I return home.
I just copied it from browser’s page.
Showing lines 55 to 62, line 59 highlighted...
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.
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.
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.
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."
I am using AVR studio 6.
Is there a solution for that error?
Did you try that?
I think the consensus is to use either the most recent AS version, or the old reliable works-with-everything 5.1.208.
Still away from home, I will try it and less you know.
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.
This gave no error.
Just have to flash & try if everything ok.
is Ulfuse:w:0x75:m -Uhfuse:w:0xFF:m ok?
I'm not sure either ;) Another reason why I deserve no credit for this firmware as I'm just picking up stuff as I go. Finally read more about it, and it just frees up RAM space by storing it in the program space (flash memory) instead (attiny13a has 64 byte RAM, 1024 byte program storage). So it really doesn't matter in the case of STAR_no_ramp because the program is only 736 bytes, but it becomes an issue when you start adding extra functionality. This weekend I'll remove it, test it, and change version numbers of the program on my site. Maybe I'll finally create a GIT repository as well so you guys can see what all changes were made between versions.
This weekend I should hopefully get around to finally adding the ability to define PWM modes (fast-pwm vs phase correct) per mode, and add the ability for a second PWM output in case, for example, you want to drive just one 7135 in moonlight mode. Hopefully it can be done, we'll see. The problem with changes like these is the four programs I have out on my site are all slightly different and require testing, with some of them already pushing the limit on program space :( It will then be confusing if one program has the new features but the others don't, as I'm sure that will be the case here.
Yup, that's what I use.
For open-air testing out on the bench, just ground whichever pin at the MCU (or the switch pad on the PCB) with tweezers. Because of stuff like breaking wires when assembling/disassembling a bunch of times while testing, I solder wires to the input side of the driver and use an external battery box with alligator clip leads until I'm nearly sure it's ready for final assembly. I also do that for the reason that on these press-fit drivers, they get a little less tight each time you remove them, so try to keep that to a minimum.
Should I add any links on my firmware page (http://www.jcapsolutions.com/flashlights/firmware/) to other sources of information on aquiring a programmer, how to flash, Attiny13a pinout, etc.? If you have any ideas on links shoot them my way, since I don't even know of all of the resources out there. Then hopefully the page can kind of be a point of entry for people new to this.
That would be nice!
I now have a courui driven @3amps with srk no ramp Firmware. If I decide to use a fet nanjg, should I make any changes to Firmware?