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

Support for low level NRF24 APIs #22

Open
sytelus opened this issue Dec 16, 2015 · 9 comments

Comments

Projects
None yet
5 participants
@sytelus
Copy link

commented Dec 16, 2015

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 comment has been minimized.

Copy link
Member

commented Jan 19, 2016

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

@adjavaherian

This comment has been minimized.

Copy link

commented Jan 19, 2016

👍

1 similar comment
@DollC

This comment has been minimized.

Copy link

commented Mar 14, 2016

👍

@gherlein

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 26, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2017

@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

This comment has been minimized.

Copy link
Member

commented Oct 27, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.