Wow! Haven't come across that little beauty before.
Lucky you!
Regardless of how bool is represented underneath the hood, any non-zero value is converted to true when it's converted to a bool, so no worries about that happening.
There was a time when Arduino headers mistakenly typedefed (or #defined) bool as byte (edit: it might have been the Arduino-specific boolean type, not bool), and that did have exactly the problem that you described. See also BOOL / bool / Boolean / NSCFBoolean - NSHipster for a similar case of this.
1 Like
No
the promotion rule from int to bool says that any non null integer value is becoming true.
Related discussion:
The first production release with CHANGE was ArduinoCore-API 1.1.0:
https://github.com/arduino/ArduinoCore-API/commit/445594a6107b4f201675338221fb704d7638a863
So you can use the ARDUINO_API_VERSION macro for this purpose:
https://github.com/arduino/ArduinoCore-API/blob/1.1.0/api/ArduinoAPI.h#L24
#if !defined(ARDUINO_API_VERSION) || ARDUINO_API_VERSION < 10100
// handle absence of CHANGE
#endif
As mentioned above by bperrybap, That is what was done to address arduino/ArduinoCore-API#25:
As bperrybap also mentioned, this fix only applies to C++/"Arduino Language" code because the overloads are not supported by C:
But it's likely that the amount of code that is both in C and making the problematic assumptions about the types of these identifiers is likely very small.
It's down to how the processor works and assembly code but in general after every operation a set of status bits tells us useful details about what happened like was the high bit set, T/F, or was a bit carried, T/F, all in a register (AVR is 8-bit).
With AVR I use type byte ( uint8_t) or byte arrays. A byte operates on 8 bools at once.
You can read a port PINx register to get many pin states at once.
Not bool in the sense of C++ type.
A signed char can indeed be used to represent 8 independent binary states, one per bit (leading to 256 possible global states in total)
That looks like it would work for now for the arduino.cc platforms, but I'm not sure if that will always work across other platforms from 3rd party core developers.
i.e. it is possible that a platform may add CHANGE pin support without fully implementing the ArduinoAPI stuff.
So over time, it may start to get trick/ugly to detect it across platforms.
--- bill
1 Like
Yes, but while it is much faster than using the Arduino digital i/o it is stepping outside of Arduino and will not be portable since it is not using the portable Arduino digital pin i/o abstraction API.
--- bill
Whole processes can be represented as sets of go/no-go T/F bits suitable for switch-case packing as a state machine.
I use bits to hold button pin states over 4 ms time to debounce the button.
When using input or output shift registers as pin multipliers, it's bits time then too.
Somehow I don't think that the AVR registers or their Arduino symbols will change at all.
I also do my writing in C anymore. Start with a dot-c source.
If you are referring to AVR register symbol names like PORTx PINx etc... Those are not Arduino symbols and are not part of anything Arduino.
They are part of the avr-gcc package and are processor specific, which is outside of the Arduino "language", no different than using inline assembler.
While it can be useful, it is stepping outside the Arduino environment which provides a portable abstraction layer and therefore is not portable since it will not work on other platforms.
--- bill
1 Like
To me, AVR-GCC is the horse Arduino rides in and very much part of the whole I write examples for.
While the avr-gcc toolset and avr libC is important (actually necessary) and is used to build the code on AVR platforms, Arduino is much bigger than that.
If you use capabilities in avr-gcc that are not part of the Arduino language APIs, like doing AVR port i/o, you are technically not actually writing Arduino code anymore, even if you use the Arduino IDE to compile & build the code.
You are writing code that is a hybrid of Arduino code and avr-gcc code that is not portable to other platforms.
Code that is written for Arduino using the Arduino APIs and strictly conforming to the Arduino APIs will be portable to any processor that has an Arduino core platform.
IMO, that is what much of this thread discussion is about.
There is a distinction between using the Arduino IDE and its environment to build code and actually writing Arduino code.
To write truly portable Arduino code, you need to only use Arduino API functions strictly the way they are documented. i.e. write code using only what the Arduino environment provides - not what a particular build tool may provide.
The original sketch example that kicked off this thread was an example of code that was trying to be strictly portable using the Arduino APIs the way they are defined while at the same time trying to be easy to read and understand.
Can you do things differently, and perhaps generate better/faster code?
Sure, but many of the ways to do that, particularly ones that increase performance by doing things like AVR port i/o are stepping outside of the Arduino environment and hence are not portable and technically is no longer Arduino code.
--- bill
Of course! Almost always. 
And of course, not portable.
You always use assembler if you need high performance, efficient and reliable code. Mostly you do not and "C", "C++" is a matter of convenience. Certainly, it takes skill, but that was never really a question. 
56 is OK; I'll keep my eye on #100. 
I don't agree about the technically Arduino part. While waiting for my 1st Uno to arrive I read the main site docs. Arduino is an open, inclusive system.
I use pinMode() in setup but I'll read or toggle PINs in loop() for speed.
If I can compile it on the Arduino IDE and it runs, that's enough for me.
What it isn't is raw beginner.
Portability of Technical Arduino? Going from AVR to ARM, port hardware has some different steps but I am okay with coding for AVR especially along families like ATmega48/88/168/328 that are pin compatible and plug into an Uno.
Meh
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.