Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to support 8 pipes (on nRF5x devices) #201

Open
2 of 3 tasks
2bndy5 opened this issue Jan 3, 2023 · 6 comments
Open
2 of 3 tasks

how to support 8 pipes (on nRF5x devices) #201

2bndy5 opened this issue Jan 3, 2023 · 6 comments

Comments

@2bndy5
Copy link
Member

2bndy5 commented Jan 3, 2023

Concerning future ventures with the nRF5x ESB, I was thinking that 8 pipes shouldn't be too hard to support.

  • pipe/address validation will have to conditionally forego x <= 5 presumption about 6 pipes
  • figure out 2 new preamble-friendly physical address bytes default value (for pipes 6 & 7).
  • For a mixed network of varying max pipes, the mesh master needs a way to know when a child node can have 8 pipes. This will be the most costly in code size, thus mixed networks will not be supported. Instead we'll use a macro to instruct the compiler what code to use concerning the max pipes configured. The mesh master node will assume all children have the same number of pipes as it does.
@2bndy5
Copy link
Member Author

2bndy5 commented Jan 3, 2023

We could augment the mesh handshake info to additionally contain data that indicates to master the number of pipes supported.

There is still some reserved space in the network sys codes, so we could add a NETWORK_NODE_PROPERTIES sys code to the network layer protocol. This sys code could then be used to confirm the connection after master has leased the address. My main concern is when this feature is used with a node running an older version of the lib.

@TMRh20
Copy link
Member

TMRh20 commented Jan 3, 2023

I've given this some thought and with the increase in code size etc, I'm not sure its a good idea. RF24Mesh will still compile and run on ATTiny, even though you can't do much with it, and I would like to keep it that way.

I think on the third point, it might be kind of difficult to support a mixed network if some use differing amounts of pipes. It would be way easier to either have an nrf24l01 or nrf52840 network.

@2bndy5
Copy link
Member Author

2bndy5 commented Jan 3, 2023

It would be way easier to either have an nrf24l01 or nrf52840 network.

So, what if all code that supports 8 pipes is #ifdef out? That way the same lib cab be used for different networks.

@TMRh20
Copy link
Member

TMRh20 commented Jan 3, 2023 via email

@TMRh20
Copy link
Member

TMRh20 commented Jun 14, 2024

I think we have the first two items picked off, its just a matter of if we want to support mixed networks. I don't really want to lol.

@2bndy5
Copy link
Member Author

2bndy5 commented Jun 14, 2024

You already convinced me that mixed networks is a venture more risky than it is worth. I (& likely other long-time users) would be comfortable with an ifdef solution instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants