GoForSmoke:
bperrybap:
GoForSmoke:
Is there a binary logic chip made that uses other than 0 for FALSE/LOW and 1 for TRUE/HIGH?
Memory, controller, processor, register?But we are not talking about chips.
We are talking about how to write software to use a software API function.Completely wrong. YOU are pissing up the API rope. And I know the difference and I specified it.
My methodology is that I focus on writing code that is portable that conforms to APIs whenever I can.
When circumstance won't allow it like it needs to be tighter to meet some kind of real-time
or space constraint need, I then go back and start making non-portable changes to optimize things.
Those non-portable changes can even extend to the point of completely bypassing an API and using assembler.
The s/w API says use these defines: "HIGH" and "LOW" to get things done.
The s/w API is written to run the chips, not conform to fairyland.
Exactly.
And suppose you need to support PWM AND an analog output?
How would you propose updating the API to support both PWM and analog output?
It could easily be handled by extending digitalWrite() as I outlined above.
But then that requires users to strictly stick to the API of using HIGH and LOW for
steady state high and low level outputs.
BTW, there are some chips that use separate set and clear registers.
In that situation, 1 bits written to a clear register will actually clear bits not set them.if ( var != LOW ) then var = HIGH;
else var = LOW;I guess THAT will work any better in your dragged up exception huh?
Certainly better than;var = !var;
Yeah.... whoops! Didn't think of THAT didja?
I have no idea what you meant by that.
Does the if/else example above even toggle the variable var between HIGH and LOW?
Also, I was not the one that proposed
var = !var;
That is one of the non portable examples I recommend against.
The only thing I'm saying is that when possible it is best to strictly follow
an API definition and use the specific parameters it specifies.
If you step outside of that, by taking advantage of the knowing the internal behavior
or the raw values of the abstracted parameters, you run the risk of your code either not working immediately
or potentially breaking at some point in the future.
I'm not sure why that is so controversial.
--- bill