Show Posts
Pages: 1 ... 3 4 [5] 6 7 ... 142
61  Using Arduino / Programming Questions / Re: Sketch Optimization and Feasibility On An ATtiny on: July 05, 2014, 07:26:57 am
Explicitly initialize the variables improves the robustness, readability and portability of the code.
- robustness: when you decide the global array can be moved to a local array it will be initialized correctly
- readability: you can see explicit what the initial value is.
- portability: if another compiler (setting) initializes global var differently (or not at all)

For sure with respect to global variables that aren't initialized at all on the AVR, however {} is an explicit 'default initialization'. I wouldn't recommend manually defaulting all the elements of say: bool Settings[ 4000 ]; over using a single short line.

Default initialization is not just an idiom of arrays, it is used for POD's too.
Code:
struct Foo{
  char a;
  int b;
  float c;
  bool d;
};

//Can be default initialized:
Foo f = {};


Also when using dynamic memory, default initialization is all you can do with arrays ( slightly different syntax ).
Code:
char *arr = new char[ max ]();
62  Using Arduino / Networking, Protocols, and Devices / Re: how to remove HTTP response header received from webservice on: July 05, 2014, 01:11:26 am
just skip the data until you reach what you are looking for.

The standard says this too ( for http 1.1 ):
Quote
Request (section 5) and Response (section 6) messages use the generic message format of RFC 822 [9] for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body.


63  Using Arduino / Project Guidance / Re: How to do a software reset on: July 05, 2014, 01:06:42 am
Why can you not re-sync just like a reset would do? A reset seems quite an overkill for a sync error!

Something like a state machine you can 'reset' in code might achieve what you want.

Or simply change the context of your app. Rather than thinking of the hardware/global scope as the top layer, make your loop function the top layer, as in: one loop is an entire life time.

Maybe this example will help get my view across:
Code:
volatile bool errorFound;  //Only volatile cos an interrupt uses it.

void setup() {}

void loop() {
 
  //Initialize system here:
  errorFound = false;
 
  while( !errorFound ) loop2();
 
  //Shutdown / clean up anything here:
}

void loop2(){
  //Application loop.
}

void someInterrupt(){
 
  if( !errorFound ){
   
    //Application is still in a running state, do something.
  }
}
64  Using Arduino / Programming Questions / Re: Sketch Optimization and Feasibility On An ATtiny on: July 04, 2014, 07:32:25 pm
pYro_65, it sounds like
Code:
boolean buttonToggle[3] = {false, false, false};
is the same as
Code:
boolean buttonToggle[3] = {};
as the values would default to 0, which is the same as false?

Yep, that is correct. Also on an AVR, unless you specify, all global variables will contain zero on start up, so you can save some flash and remove the initialization as the variable is already zero/false. This does not apply to local variables though ( variables defined inside a function )
65  Using Arduino / Programming Questions / Re: I've broken print . on: July 04, 2014, 07:30:17 pm
Quote
I've been unable to find one so far. As AWOL mentioned, you can use memcpy_P, but that kind of defeats the point of storing the array in PROGMEM in the first place. I am using memcmp_P  to compare the contents of an array in RAM with an array in PROGMEM, but it's not reading the contents of the array in the way we would like.

I can't help but think there must be a neater way of doing it without a FOR loop, but I've yet to find it. I need to do more reading on pointers.

Only 1 byte at a time ( limit set by the hardware ). And memcpy_P/memcmp_P just run pgm_read_byte in a loop. If you want to compare without using memcmp_P, then use a loop, its not untidy. There are functions like pgm_read_word/dword, which will read 2 or 4 values ( however they just call read_byte 2 or 4 times ).

In what way do you need to read the array where memcpy_P/memcmp_P  does not suffice?
66  Using Arduino / Programming Questions / Re: Sketch Optimization and Feasibility On An ATtiny on: July 04, 2014, 08:25:54 am
Code:
boolean buttonToggle[3] = {false};
this sets only the first element to false, the others are undefined....

The others are default initialized. As boolean is an uint8_t, its default value is zero. The line above produces the same result as:
Code:
boolean buttonToggle[3] = {};
67  Using Arduino / Programming Questions / Re: I've broken print . on: July 04, 2014, 07:29:25 am
When I learned C,  this would have been an error without the keyword struct  or a typedef for it.

It should still be the case if you wrote it in a .c file.

@OP, you are using pgm_read_byte wrong.

Code:
byte DSP_STATUS_REPLY_RST [6]  PROGMEM = { 0x6A , 0x04 , 0xFF , 0x02 , 0x01 , 0x92 };

To read the first byte of the array you could do this:
Code:
byte b = pgm_read_byte( DSP_STATUS_REPLY_RST );

To read the whole array in a loop, you could do this:
Code:
for( char i = 0 ; i < sizeof( DSP_STATUS_REPLY_RST ) ; ++i ){
    byte b = pgm_read_byte( DSP_STATUS_REPLY_RST + i );
    Serial.println( b, HEX );
}

Note: sizeof works in this instance cos the array is an array of single bytes, anything larger needs help: http://arduino.land/FAQ/content/6/29/en/how-to-get-the-size-of-an-array.html

You can also rewrite the access code to use array syntax rather than pointer arithmetic:
Code:
pgm_read_byte( DSP_STATUS_REPLY_RST + i );
//Or
pgm_read_byte( &DSP_STATUS_REPLY_RST[ i ] );


68  Development / Other Software Development / Re: Problems With Include File Dependencies on: July 02, 2014, 06:56:16 am
Unfortunately, its the way the IDE does it.

For now, this is the way it'll be, I'm sure they have plans to one day incorporate a full recursive scan.
You will, for now, have to ensure appropriate documentation is included in the library, and also in any examples.

I have written an article describing some of the IDE's behaviors ( including this one )  if you are interested. There are also links to some examples where the IDE can break your code because of these changes.
http://arduino.land/FAQ/content/1/3/en/what-does-the-ide-change-in-my-sketch.html
69  Community / Website and Forum / Re: Drop the boolean data type, its broken. (or fix it) on: June 30, 2014, 10:13:41 am
I have added a pull request to the Arduino source.

For the time being, here is some code you can test. This shows why true and false cannot be defines to literal numbers.

Code:
void setup() {
  Serial.begin( 9600 );
 
  DoSpecific( true );
  DoSpecific( false );
  DoSpecific( 1 );
  DoSpecific( 0 );
}

void loop(){}

void DoSpecific( bool value ){
  Serial.print( "The boolean value is: " );
  Serial.println( value ? "TRUE" : "FALSE" );
}

void DoSpecific( int value ){
  Serial.print( "The integer value is: " );
  Serial.println( value, HEX );
}
70  Community / Website and Forum / Re: Drop the boolean data type, its broken. (or fix it) on: June 30, 2014, 06:33:22 am
C and C++ agree on false==0.   I think I'd prefer to see
#define true (!false)
If thats still acceptable.


Oops, that is actually what my code is on GitHub, I modified the example in my post above without reading the line ( I reordered mine so false is defined first, then inadvertently copied the second line from this threads example. )

I modified my post above, cheers.
71  Development / Other Software Development / Re: Will Arduino team ever do better than this?! on: June 30, 2014, 05:41:16 am
Good and interesting analysis Pyro!

Still imho mixing datatypes (int and bool(ean)) is always tricky.
With comparing integer with booleans we loose "significant truth" bits.

similar as loosing significant digits when converting long to float and or vice versa.

So in the end the programmer is responsible to know the limits of a language
(see book safer C from Les Hatton)


I'm not sure what you mean in the highlighted part. However there are pretty concise rules governing these conversions ( int & bool ). There is nothing left up to interpretation.

And I agree the programmer is responsible however, its failure waiting to happen, as the Reference a knowledgeable Arduino user would refer to is wrong. But in this case, fixing the reference is not good enough.  I mentioned earlier that the defines true and false did not affect anything, however I was wrong, these must go too.

I have started a thread regarding this issue if you are interested ( and everyone else ). I have also made some posts describing the nitty gritty of boolean conversions.

The thread is located here: http://forum.arduino.cc/index.php?topic=252120
72  Community / Website and Forum / Re: Drop the boolean data type, its broken. (or fix it) on: June 30, 2014, 04:32:46 am
Integral comparisons are done within the integer domain.

Consider ( true, not the define ):
Code:
true == true;

Both boolean values must be promoted to int before any comparison is done.
As with if( value ), value's final result is converted into a boolean, then the comparison involves a promotion back to int.
Even though bool is an integral type, it has the lowest integer rank. And integer promotions only consider variants of int ( short/long/signed/unsigned ).

There is an awful lot of things happening in the background of C++ code.

It seems like C++ would produce more initial code ( than the C alternative you provided ) as the conversion to bool would change something on any value apart from 0. However the compiler can see this, and reduce it to its optimal form. Some C++ texts even recommend enforcing the conversion so its clear to other programmers you are using a boolean value ( value != 0 ), as its widely known that the optimization will be seen. In fact it was probably once a hard coded optimization as it is such a common C idiom, it was most likely expected to be littering C++ code everywhere.

Quote
5.10 Equality operators [expr.eq]
1 The == (equal to) and the != (not equal to) operators have the same semantic restrictions, conversions, and
result type as the relational operators except for their lower precedence and truth-value result.

And when we go there we can see:
Quote
5.9 Relational operators [expr.rel]
1 The operands shall have arithmetic, enumeration, or pointer type, or type std::nullptr_t. The operators < (less than), > (greater than), <= (less than or equal to), and >= (greater than or equal to) all yield false or true. The type of the result is bool.
2 The usual arithmetic conversions are performed on operands of arithmetic or enumeration type

And msdn sums up integral promotion nicely ( which is what usual arithmetic conversions are when referring to integral types ).
Quote
Integral promotions are performed on the operands as follows:
  • If either operand is of type unsigned long, the other operand is converted to type unsigned long.
  • If preceding condition not met, and if either operand is of type long and the other of type unsigned int, both operands are converted to type unsigned long.
  • If the preceding two conditions are not met, and if either operand is of type long, the other operand is converted to type long.
  • If the preceding three conditions are not met, and if either operand is of type unsigned int, the other operand is converted to type unsigned int.
  • If none of the preceding conditions are met, both operands are converted to type int.
Quote
I'm not sure I understand the advantages of forcing bools to be only 0 or 1, aside from a sort of intellectual purity

I'll hopefully have a better explanation in the future, but:
It provides a sturdy platform for anything yes/no, as every value has meaning. Whereas only 2 values have meaning in the Arduino boolean, and 254 values are meaning-less.

It also allows us to make claims like the Arduno reference: Any integer which is non-zero is true as this is only made possible by boolean conversions ( number to bool ), and integral promotion rules for bool ( bool to int ). Without the rules while using the Arduino boolean; its up to you as a programmer to ensure that values are equal to one or zero before assigning to boolean, or to check its contents is within a certain range ( !=0, >0, <1, ==1 ). Which reflects the behaviour of C where the only boolean conversions you get are in a boolean context: if( value ), !!value, etc... And Arduino's boolean does not provide a boolean context.

I have now got a sturdy poof why true and false as defines cannot be used either. I just need to simplify it into a convincing argument.

I also have changed my fix to #define true !false for the C side of the code.
73  Community / Website and Forum / Re: Drop the boolean data type, its broken. on: June 29, 2014, 10:16:37 am
That is what the code will look like after pre processing but before the compiler processes it.
The 1 is converted to a bool before assigning. The defines do not affect the compilers internal meaning of true/false.

What I propose to do is change Arduino.h to use the boolean functionality when compiling C code, but use the built-in method when in C++:

Code:
#ifdef __cplusplus
typedef bool boolean;
#else
typedef uint8_t boolean;
#define true 0x1
#define false 0x0
#endif
74  Community / Website and Forum / Re: Nice little 'stick it to the guys with the small screens' on: June 29, 2014, 07:01:33 am
I cannot observe the original complaint on Linux, but I do note curious behaviour on my 10" Windoze netbooks whereby as the page loads, it renders in a larger font, but shrinks as it completes loading.

That's just because the site uses fonts linked in CSS. They will load after the CSS and HTML have loaded, so a restyling is seen.
75  Community / Website and Forum / Re: Drop the boolean data type, its broken. on: June 29, 2014, 06:29:08 am
In C, the rule was that you should never compare a Boolean to true.
"if ((Boolean)57) print("true");" works fine.

Thats because C does not have a boolean type, and therefore does not define any limitations to its contents, it only gives value to true and false which is why you should not compare. It is not suitable for C++, especially since bool is a real type and true is one of its values. C++ also ads implicit casts, conversions and promotions ( boolean logic ), where as C does not, but can have some explicit conversions like !! mentioned in my first post.

Also in your snippet, boolean(57) is converted to a real bool value as it is used in a boolean context, in the comparison true is promoted to int which integral promotion rules enforce, the RHS does not down cast to bool. There is an entirely different set of rules being applied.

I've often wondered what the point of the boolean type was in the first place.

Yeah, I was astonished when I saw it was an int. Just an artifact pushed into C++ Arduino so the core can use a 'boolean' in its C code ( wiring.c and others ).
Pages: 1 ... 3 4 [5] 6 7 ... 142