Add Example for Beaglebone Black

[single9]

Hi,

I write a program for Beaglebone Black developer. This program provide a way to help BBB developer easy to use this library in Node.JS.

Please forgive me if I make any errors; my English is a little weak.

[TMRh20]

FYI just wanted to say thanks for this and that I've been meaning to look closer at this and will test it out soon.

[chgerwig]

I do not understand the numbering of the pins in combination with the Beagle Bone Black. It worked with an old library (https://github.com/mlsorensen/RF24.git) with 115. It does not work with this library and the same number. What has changed?

[single9]

Because pin number 115 didn't work with my BBB. I change it to 59 (P9_16).

[TMRh20]

With the recent makefile and example directory changes, could this be moved to the examples_linux directory and somehow included with the general linux examples? Apologies for taking so long to get this included.

[martin-mat]

cli is a great idea, and it's generic, not only BBB related. Best if it is more configurable (RF24 constructor as cli params). It has been a while since author posted it, so if he's not around I can take it to adapt and merge.

[single9]

Since I'm busy recently. I don't have enough time to do this. I'm very sorry. If @mz-fuzzy can help, I will appreciate it.

[single9]

OK, I think I still want to do it by myself... XD

OMG! I forgot set my new BBB's global config. It is as root now... :(

[martin-mat]

ok, my comments then:

• arguments of RF24 constructor would be good to have configurable as cli params, not hardcoded
• I think there is no reason why this tool should be presented as bbb-specific, it's a generic tool for rf24 modules without any binding to bbb
• also name of the tool should not contain bbb, it could be named like rf24ctl

[single9]

Hmmm... Thanks your advice but I really don't have more time to make it become a better tool... :(

[TMRh20]

@single9 Maybe do what you can, and it can be added to later?

[single9]

I will try.

[Avamander]

@single9 Any updates?

[2bndy5]

I've been thinking about adding a argParse.h for the new examples (python ships with standard argparser library).

I'm afraid of making the Linux examples too complicated to read for C++/python noobs, but it could also provide a way to use the rf modules without needing to understand the API (i.e. one-off use in openHab). My idea is that:

1. If an arg is specified, then attempt 1 OTA transaction
2. If no arg is specified, then continue with example as normal.

My idea for args is as follows

Short	Long	description
-c	--ce_pin	CE pin number
-C	--csn_pin	CSN pin number
-a	--no_ack	disable auto-ack for multicasting
-A	--use_ack_payload	enable ACK payload feature and dynamic payloads consequently
-w	--w_address	address for TX pipe
-rX	--r_addressX	address RX pipe X
-b	--buffer	TX payload (as a string)
-BX	--bufferX	load ACK payload for RX pipe X
-t	--timeout	timeout to RX or TX depending which type of buffer is specified (-b or -BX)

Notice I plan on using the length of the payload string to payloadSize() when not using an ACK payload.

I like the usefulness of this PR, but it seems to have gone stale (& outdated). I'm using this thread to avoid opening yet another issue (or would that actually be preferred?).

[TMRh20]

I thought the idea was to simplify the examples not complicate them? :p This is kind of a cool idea that could help automate testing things with a single generic example that gets fed different arguments? Just a random idea...

…

On Nov 22, 2020, at 2:47 PM, Brendan ***@***.***> wrote:  I've been thinking about adding a argParse.h for the new examples (python ships with standard argparser library). I'm afraid of making the Linux examples too complicated to read for C++/python noobs, but it could also provide a way to the rf modules without needing to understand the API (i.e. one-off use in openHab). My idea is that: If an arg is specified, then attempt 1 OTA transaction If no arg is specified, then continue with example as normal. My idea for args is as follows Short Long description -c --ce_pin CE pin number -C --csn_pin CSN pin number -d -dynamic_payload enable dynamic payload length -a -auto_ack disable auto-ack -w --w_address address for TX pipe -rX --r_addressX address RX pipe X -b --buffer TX payload (as a string) -BX --ack_payloadX load ACK payload for RX pipe X -t --timeout timeout to RX or TX depending which type of buffer is specified (-b or -BX) I like the usefulness of this PR, but it seems to have gone stale (& outdated). I'm using this thread to avoid opening yet another issue (or would that actually be preferred?). — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[2bndy5]

yea, that's what I was originally thinking, but then I didn't stop thinking and over-thought it... (common quaratine-time problem).

How bout we let the Multiceiver example (or maybe all examples if it turns out less complicated than I'm foreseeing) take a radioNumber (actually called nodeID in Multiceiver code) & role CLI args. That should be both simple for newcomers and convenient for automated testing. The complications arose after I thought about ACK payloads...

BTW I've been reading up on the python std lib argparse, and it is very impressive. We could use sub-categories of args like git does!
ex:
rf24_cli.py tx -p 1Node -b buffer for TX mode (using address "1Node" and sending "buffer")
or
rf24_cli.py rx -p1 1node -t 1000 for RX mode (using pipe 1 and listening for 1 second).

I'll shelve the CLI tool idea till after pyRF24 is up & running

[TMRh20]

Sounds good

…

On Nov 23, 2020, at 12:30 AM, Brendan ***@***.***> wrote:  yea, that's what I was originally thinking, but then I didn't stop thinking and over-thought it... (common quaratine-time problem). How bout we let the Multiceiver example (or maybe all examples if it turns out less complicated than I'm foreseeing) take a radioNumber (actually called nodeID in Multiceiver code) & role CLI args. That should be both simple for newcomers and convenient for automated testing. The complications arose after I thought about ACK payloads... BTW I've reading up on the python std lib argparser, and it is very impressive. We could use sub-categories of args like git does! ex: rf24_cli.py tx -p 1Node -b buffer for TX mode (using address "1Node" and sending "buffer") or rf24_cli.py rx -p1 1node -t 1000 for RX mode (using pipe 1 and listening for 1 second). — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.