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.
Sorry guys, was hoping someone else would chime in ;)
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 0x83That'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 :(
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.
Tried to compile SRK no ramp firmware with this result.
Any ideas?
Did you by chance have 'word wrap' enabled when you copied the source to paste it into Atmel Studio?
Have no idea about that.
Please elaborate.
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.