Posted on April 26, 2017 at 17:03No, I think that creates more busy-work for me, the PM arrived first, and I've handled it off-board. If I get feedback that my suggested changes work outside my test bench, I'll perhaps share an example.
The Ping-Pong example has meta-stability issues, it starts, it stops, it doesn't restart, the nodes get confused about what role they are playing, or can't decide. The example is also a bit superficial, if you extend or alter it to some more practical/real-world use case, you run into a number of flaws that should have been apparent when it was coded. There are issues with interrupt priorities, code in interrupt handlers blocking, and with the radio / uarts interacting badly causing data loss on both interfaces.
More generally there seems to be some issues with using the FSK build, splitting/spanning of large packets, call-backs. Now some of this may be due to a lack of appreciation about how the API is supposed to function, on my part, but the PingPong example does a poor job of illustrating how things should work, or act as a rigorous test of the API.
What is the value of doing Radio.Sleep(), and the purpose of inserting DelayMs(1) with no explanation? Why doing RadioTx() in the 'case TX:' seems to not succeed a lot of the time? Should I be able to manage data transfers in the call-backs? Are there situations where no call-backs will occur?
Not sure this is something I can hash out on the forum. Perhaps you have someone with some in-depth understanding of the API and radio stack?
