Compiling Examples/Usage/LED_remote error

[k2OS]

https://github.com/TMRh20/RF24/blob/master/examples/Usage/led_remote/led_remote.pde

line 236: done = radio.read( button_states, num_button_pins );

led_remote:236: error: void value not ignored as it ought to be

in RF24.h read() returns a void, but in the example an int (or something else) is expected.

Compiling for Arduino UNO on windows 7 / 64 bit using the Arduino 1.0.5 rc2 IDE.

Thanks

[k2OS]

Actually.. none of the examples presented in the Arduino IDE from this library will compile:

Trying out GettingStarted, GettingStarted_CallResponse and a couple of others returns
"error: 'rf24_min' was not declared in this scope..

[TMRh20]

Thanks for mentioning this. Should have tested the change that caused this on Arduino, but it seemed so straightforward, and I didn't catch the error.

[k2OS]

Excellent. Now we get to the 2nd error in the old examples:

led_remote.pde: In function 'void loop()':
led_remote:236: error: void value not ignored as it ought to be

read() now returns void and as far as I can tell, available() is now supposed to be used to test if we're done... I'm not profficient enough to rewrite the examples though..

Another thing.. I'd really like for the pin-connections to be clarified a bit more in the examples.. I am scratching my head as what RF24 radio(9,10) meant.. I did figure out that it probably meant which MISO/MOSI-pin on my device the radio was attached to, but there is no mention of where and how CE and CSN are configured (but apparently their pins are predefined to be 7 and 9 (in this library?)).

I could open another bug.. and I could also (when I finally get the communication to work) rewrite the descriptions of the newer examples to be more beginner-friendly.,

Cheers

/rené

[TMRh20]

Technically, users can choose any pins for the radio CE and CS pins. I chose 7 and 8 as the default, since pins 9 and 10 conflict with my audio libraries.

I don't understand your confusion, because the example literally says
// Hardware configuration: Set up nRF24L01 radio on SPI bus plus pins 7 & 8
RF24 radio(7,8);

I would argue that it is not the job of a low-level radio driver to teach users about SPI functionality. In any case, Google has pages and pages of information on using NRF24L01 modules, and there is tons of documentation about SPI, not to mention http://tmrh20.github.io/RF24/index.html

I am aware there are problems with some of the examples, but examples and documentation are last on my list of priorities. I thought it more pertinent to spend the hundreds of hours involved into fixing and testing the actual radio driver, and network library, instead of making things pretty.

I'm not sure why so many people are freaking out about the LED sketch right now, but no amount of emails or harrassment is going to make me change it right now, I'm busy.

BTW, the LED sketch was left in for historical purposes for users to reference. If anything I would just remove it entirely because I'm getting really sick of it. Feel free to contribute.

Pin assignments are not a software bug. If anything, feel free to update the documentation and/or examples if you feel it needs clarification.

[k2OS]

facepalm.. on my part. of course those two numbers are the CE and CS-pins
and not SPI..

I came off sounding way less greatful than I really am. I do understand
that there are several generations of code and examples in this (great!)
library.. whenever I dive into a new library I always go to the examples
for ideas how the library works and when the examples don't work.. well..
frustration ensues..

I am guessing that these nRF24-modules recently came into a awareness of a
'new' generation of arduino and pi-users, which might be why you are
feeling 'bombed' suddenly.

Give me a few days and I'll see if I can't rewrite the LED-sketch.. it's a
great real-world example of how to use this (did I mention 'great'?)
library and submit it to you.

Best Regards

/rené

On 28 November 2014 at 07:59, TMRh20 notifications@github.com wrote:

Technically, users can choose any pins for the radio CE and CS pins. I
chose 7 and 8 as the default, since pins 9 and 10 conflict with my audio
libraries.

I don't understand your confusion, because the example literally says
// Hardware configuration: Set up nRF24L01 radio on SPI bus plus pins 7 & 8
RF24 radio(7,8);

I would argue that it is not the job of a low-level radio driver to teach
users about SPI functionality. In any case, Google has pages and pages of
information on using NRF24L01 modules, and there is tons of documentation
about SPI, not to mention http://tmrh20.github.io/RF24/index.html

I am aware there are problems with some of the examples, but examples and
documentation are last on my list of priorities. I thought it more
pertinent to spend the hundreds of hours involved into fixing and testing
the actual radio driver, and network library, instead of making things
pretty.

I'm not sure why so many people are freaking out about the LED sketch
right now, but no amount of emails or harrassment is going to make me
change it right now, I'm busy.

BTW, the LED sketch was left in for historical purposes for users to
reference. If anything I would just remove it entirely because I'm getting
really sick of it. Feel free to contribute.

Pin assignments are not a software bug. If anything, feel free to update
the documentation and/or examples if you feel it needs clarification.

—
Reply to this email directly or view it on GitHub
#43 (comment).