I’m rebuilding it with each iteration, but if you don’t see something wrong with my code, that is still my best guess. Maybe there’s something weird going on with the avr tools cache. We’ll find out tomorrow.
I don’t see anything that would make either 4 mode config appear as 3 modes.
What procedure are you following? I do this:
- build in AVR STudio
- expand “output files”, double click on the hex -> save the hex file with a unique name
- switch to the CLI (command prompt)
- flash that particular hex file using a command formatted like this:
avrdude -p t13 -c usbasp -u -Uflash:w:xxxxxxxxxxxxxx.hex:a -Ulfuse:w:0x75:m -Uhfuse:w:0xff:m
That’s exactly what I’ve been doing, except for the unique name. I have been overwriting “FW.hex” with each build so I can just copy/paste the same command line. I’ll try closing studio between builds to make sure it’s actually rebuilding it, then try unique names if that doesn’t work.
I don’t see why you should need to do the unique names part, I was just telling you exactly what I was doing. If you are actually opening the “save” or “save as” dialog box and overwriting the file each time I think we can be confident that you do not need to do anything different there.
My current suggestion is to add some more modes:
- Define MODE_MOON again, leave the other modes defined.
- Use 10/35/50/70/255
Sounds like fun 
If you’re unclear whether a firmware has been flashed correctly, and you’re using Phase correct PWM. Try simply changing the 8x divider fuse bit and reflashing. You can then tell by eye if the PWM frequency has changed, 1khz vs 9khz is easy to spot by waving your hand through the light. Of course you’d likely lose the lower modes as well so that should be even more obvious.
Just to quickly confirm it’s flashing correctly without having to recompile anything.
Here’s my recommendation- recompile and name the output file something different. Before flashing, open the new file, copy it’s content and paste it into a compare tool like diffchecker https://www.diffchecker.com
Then do the same with the old hex file to the other side of the diff checker. This will tell you that you’re correctly compiling (when I was new to avrstudio I had an issue editing the wrong file, using the diff checker on your hex files will verify you’re not making that same mistake).
You must edit the .c file asscosiated with the open project, if you open the wrong .c file, make changes to it, then recompile the project the freshly compiled hex file won’t reflect the changes you made to the non-project .c file because when you hit compile it will always huild off the project’s own .c, if you accidentally opened the wrong .file to edit those changes won’t change anything so verifying the new hex is different will show you that you definitely have a different file and that you have other issues.
That’s a good sanity check Cereal_killer. Doing diffs is never a bad idea.
Ok I started over from a virgin copy of STAR. I am now getting light on 4 closely-spaced modes. There are no “dead modes” in the UI, but according to the FW there should be a fifth mode. Is it possible it’s just entirely skipping over ‘moon’ for some reason?
This is where I am now. if I try to “build” it with “define Fast_PWM start” commented out, AVR studio gives an error that it is undefined.
At one point, I got a really nice firefly mode (as in you could stare directly at the die without hurting your eyes) but with all the confusion over the mode order I’m not sure what PWM setting produced it.
edit: I’ve been making my changes in wordpad starting a new project in AVRStudio with each revision to ensure they are actually taking affect. It seems to be working in that regard.
Firefly and moonlight will probably both be somewhere in the 10 to 45 range.
Are you saying that you previously commented out “define Fast_PWM start” and were able to compile, but it doesn’t work now with your fresh copy?
For now let’s switch you to a non-dual-PWM version. Keep things simple and all that. Use this: http://www.jcapsolutions.com/wp-content/uploads/2014/05/STAR_off_time_1.3.c
I think so. With the first 2 revisions, I had it the way it is now, later I commented it out. So either I fudged something deeper in the code that allowed it to go through before, or AVRStudio wasn’t actually building my revisions and I was flashing the same FW over and over.
It actually seems like it’s skipping turbo in my last build, because all of the modes were tightly spaced and the highest one was still kind of dim. I’m testing with an XM-L U2 and a laptop pull panasonic.
Please test with the code I linked to above:
- Be sure to set your modes up.
- This uses the old turbo style. I’d leave turbo disabled. (That gives 4 modes.)
- I normally disable voltage monitoring while testing this sort of thing.
From what I can tell that didn’t make any difference. Also, I think it has been skipping moon because I commented it out and that also appears to have no difference in the result. Now I’m just playing around with different combinations of the settings to see what I can get.
Remind me which board revision (version) you are using please. EDIT: nevermind, it’s 20mm v007.
20mm v007
In that case I’m not sure what the problem is.
It should be pretty easy to identify which modes are present or not present by using clearly dissimilar values and/or disabling a bunch of stuff.
I did forget to mention that you’ll need to setup that firmware I linked you to with the :8 divider and Phase Correct PWM.
I’m fairly certain moon mode is a no go, idk why though. I have it working with this code.
At least with these settings, 37 PWM is the lowest it can light up a first-gen XM-L. At 37 you can look straight at it and still see the lines on the die. It needs some tweaking on the mode spacing, but otherwise it is working as designed. There is some buzzing on Medium and High, so hopefully tweaking PWM levels can alleviate that.
……………
I have to run to Home Depot now, I’ll play some more when I get back.
Maybe i’ve got the wrong end of the stick here but I think I know what’s causing the confusion regarding Moon mode.
That version of STAR (probably every version?) requires a soldered star to enable Moon mode, ie. A particular pin on the MCU needs to be connected to ground. It looks to me like that particular pin on this driver is left open/ungrounded. Right?
Obviously seeing as there’s no star available to connect it here you’d have to hard code “moon mode” to be on by default. ie. change the 0 in the following bit of code to 1. That should give you the expected number of modes.
“#ifdef MODE_MOON
if ((PINB & (1 << STAR2_PIN)) == 0) {
modes[mode_cnt] = MODE_MOON;”
Possibly you were seeing a medium mode at some point confusing it with an actual moon mode which caused the confusion? Seems likely since the actual minimum output level is ~37 pwm as you said.
-