Yeah, I goofed up. I showed 11111111000000, which is 16320 base 2, and mistakenly called it 4080. You read the familiar numbers 64 and 4080 and thought I’d failed to multiply by 4, a common mistake in this forum. I compounded my mistake by getting one of my binary numbers wrong. I don’t blame you for it, but I think you missed my point. Relative to the Control Center, all values from 1 to 63.75, that’s 00000000000001 through 00000011111111 relative to the script AFTER multiplying by 4, are adjusted upward to 64.0, that’s 00000100000000 AFTER multiplying by 4, thanks to Min. Right so far? And all values above 4080 * 4 = 16320, that is, 11111111000001 through 11111111111111, are adjusted downward to 11111111000000, thanks to Max, right? I can’t get 10 contiguous bits out of any 10 bits when I only consider 10 bits, because of Min and Max. The rest of your response simply commandeered an eleventh bit when you questioned my logic. But I was only discussing using ten bits. So let’s clarify:
The example you linked to uses the ten low-order bits. Remember how it takes the channel position from a given channel 3 through 5, then pushes 512 (1000000000) onto the stack as a bitmask and shifts right from there in a loop, using bitwise_and to examine the bit at 512, then 256, then 128 and so on down? The sample does not advise as to the range of position settings that are useful for that sample, or that some settings don’t work right because of Min and Max. Assume for a moment that I’ve set the channel to (63.5 * 4) = 254 = 11111110 in an attempt to achieve a dimmed color brightness in only 10 bits, wanting to conserve the high-order four bits for essential flags and other purposes. I fail; I get the brighter 100000000, which is as dim as I can go except for off. Because of the Min limitation of the Maestro, displayed as 64.0 in the Control Center but actually-- and I DO understand this, Paul, my goof-up above to the contrary-- 4 times higher, or 256, it can never get a value lower than 0100000000 when the Control Center’s channel setting is below 64.0. I started this thread because I want to dedicate ten contiguous bits, and no other bits, to defining a color, and therefore wish to have a variable value where I can use any or all of the 14 bits as I please. In this instance I want the ten low-order bits for color information and the upper four bits for something else. But I can’t because of the Min limit. .
You are, of course, correct that I can get ten contiguous bits if I introduce an offset, which is to say, set one of the four high-order bits of the position setting to 1 as an eleventh bit of the light color setting. To get 1111111111 as the low-order ten bits, I need one or more of the 4 high-order bits set 00011111111111 through 11111111111111. It would appear I have to lose one of my flag bits, which you can tell from the above discussion I don’t like being forced to do. That’s what this thread is about-- defeating Min and Max in the Control Center, in the Maestro, or both. You’ve said there may be a way through the SDK, and that serial variables may come some faraway day from now. Good, and good. Meanwhile, what occurs to me is that I don’t necessarily need to fully dedicate one of the four high-order bits as an eleventh bit, I can still use all four of them as flags. I just have to be sure at least one of the four flags is set any time I supply a color value to a servo positioning channel, but not all four flags so that the total value will never exceed 16320. In any case, any workaround in this particular instance does not in any way weaken my argument before Pololu for the usefulness of a full 14-bit variable. I’m certainly not contradicting your assumption that I can or want to use an eleventh bit, or should infer the use of one from the sample script you linked to. When using ShiftBars/ShiftBrites, most people probably dedicate the whole servo positioning channel “variable” just for setting light color and thus have four bits to spare. I do wish you’d consider my Variable ideas, especially the one about pushing multiple parameters on the stack when calling a script so we don’t have to use servo positioning channel settings as script variables that may be automatically adjusted upward to 256 or downward to 16320. That would only require some code-changes in the Maestro’s PIC the next time you program a batch of them, and some documentation changes. You do make firmware and documentation changes now and again! I for one am doing a lot of diverse things with the Maestro, and am sure 'many other users are too. I want to be able to pass more than one variable, up to 14 bits each, and doing it directly into the script like I can the one parameter now would be ideal. Thanks again,