Support for low level NRF24 APIs

[sytelus]

I'm working on using crazyradio for other quadcopters. One of the main problem is that firmware doesn't expose API to make calls for NRF24 low level APIs. For example, it would be great if Python script can call ReadReg, WriteReg, FlushTX via entry point in firmware just like it currently supports setting channel, bit rate etc. This will allow almost any customization for enabling other quadcopters without any need to modify firmware.

For example, look at below code that sets up Syma X11 quadcopter:
https://github.com/goebish/nrf24_multipro/blob/master/nRF24_multipro/SymaX.ino

Basically we need firmware support for the following APIs that can be called from Python:

• Reset
• Initialize
• SetTxRxMode
• ReadReg
• WriteReg
• WriteRegisterMulti
• FlushTx
• ReadReg
• WritePayload

[ataffanel]

This is a good idea, I was thinking of implementing more generic commands at some point.

[adjavaherian]

👍

[DollC]

👍

[gherlein]

I am looking at implementing exactly these kinds of additions. I would like to use the CrazyRadio for added things as well. If you will consider my PR I'll submit them. I am just getting started now.

[ataffanel]

@gherlein Great! How do you plan to implement the functionality?

There is already 'modes' in the crazyradio, one called 'legacy' (that I will rename in 'packet' mode), it is the mode used right now, and one called 'cmd' that is not finished.

These modes are implemented in separate functions so I am thinking that maybe the easiest would be for you to implement a new mode. This way you can keep your implementation fairly independent of the current protocols and it will be much easier to merge it. Any thought about it?

[gherlein]

@ataffanel yes, I'll use the same 'mode' technique so it's totally isolable from the existing functionality. I'm not sure if we want to expose the raw low level items that @sytelus mentioned above. I think that adding the ability to enable/disable CRC, set CRC length are good first starts. Scanning https://github.com/goebish/nrf24_multipro/blob/master/nRF24_multipro/SymaX.ino I don't see much more that is not already implemented in the firmware. I hope to have something for you to look at this week. I may submit a small PR to just add etags and some cleanup to the makefile to match my programming environment so you can code review things more easily

[ataffanel]

Thanks for the small PR. If you do not plan to change the way packet are sent (ie. one packet sent per bulk out transfer and optionally an ack in a bulk IN tranfers), you could just add the options you want as control command as well. Making a new mode is mostly interesting if you change the bulk IN/bulk OUT meaning.

On a side note: I am going to be away for 3 weeks and it is likely no-one will merge during this time. Though I will gladly look at it when I am back.

[gherlein]

@ataffanel @sytelus I don't plan to modify the bulk transfer at all. I have added code to enable/disable CRC and change the CRC size, and enable/disable Shockburst. But the sketch above does not need those things - and I actually think that it could be rewritten to use the commands already implemented. One question @sytelus: how were you planning to have the arduino talk USB?

[gherlein]

@ataffanel no problem on the delay - I want to test it well first anyway :)