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.
-
Yeah I was just thinking about the star/pin needing to be grounded. I’ll try that after dinner tonight.
My mistake, I should have known better. I got confused.
Probably nothing but should you have both of these lines commented out?
//#define FAST_PWM_START 255 // Above what output level should we switch from phase correct to fast-PWM?
//#define DUAL_PWM_START 8 // Above what output level should we switch from the alternate PWM output to both PWM outputs? Comment out to disable alternate PWM output
That’s all I saw that looked odd to me. But I’m not the one to ask on these things. Wight, RMM or ToyKeeper , by the way, where’s Comfy?