Rn2483 driver In Progress, Configuration Mostly Complete #2
Conversation
…ice. Implemented with the rn2483_radio_set_cmd function which uses an enum to represent each cmd and sends a radio set <message> to set the desired values of the corresponding cmd. void *data is the generic pointer which will be set to different data types, so appropriate pointer casting was used. All inputs to the radio_set_cmd function are presumed to have already been checked, which is why there are no checks in the function itself. A dummy file_read call is a temporary fix to get rid of an annoying bug where the 'sys get ver' value would be the first values in the read buffer after startup. Logging is used mostly for debugging at this point through syslog.
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
There was a problem hiding this comment.
Just wanted to recommend that you keep your commit messages curt (something like 2 sentences) just to make it easier to figure out it changes. You don't have to explain what's going on in the message, but rather do so instead in code comments (if things aren't self-evident). Another thing is to not have all your changes in one commit, a commit should only do one thing (e.g. refactor code, add specific functionality etc.). Otherwise, excluding @linguini1's comments, LGTM.
Oops, looks like NuttX's contributing guidelines tell you to make your commits messages like that so it puts it in the pull request, my mistake. It would still be a good idea to separate out your commits, however. |
Yeah we can keep them granular on the fork here, I usually just squash them all before sending them to NuttX upstream. |
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
…te functions. Removed all enums related to rn2483_radio_set_cmd.
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
…h radio parameter.
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
…nger than required in case we need to adda null terminating character.
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
…know if it is neccessary.
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
…dded 2 to each buffer length.
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
…ed define for dummy read buffer length. Would like to get rid of dummy read eventually.
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
… recommended. I am also subtracting one to keep space for the null terminating character.
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
There was a problem hiding this comment.
Outside of review comments, logic all looks good to me! You can start writing your test case for the ioctl calls, or help Jason with the TX implementation. We can merge in RX after review comments are resolved. Looking like an upstream PR might be ready before end of November! Great work!
…t, set priv->config options after sending the radio command instead of before, and now check for the error return value from that radio command call before setting the config's parameters.
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
There was a problem hiding this comment.
Great work! I think this is solid logic for the configuration settings, and I doubt you'll find any issues with your ioctl tests. I'll merge in the receive logic at some point soon and then you can write some code to test receiving too (it's quite fragile). I'll get you the COTS board and last year's test scripts to try sending actual radio signals!
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
Added ability to set board configuration values by sending "radio set " signals to board.
Note: Please adhere to Contributing Guidelines.
Summary
Update this section with information on why change is necessary,
what it exactly does and how, if new feature shows up, provide
references (dependencies, similar problems and solutions), etc.
Impact
Update this section, where applicable, on how change affects users,
build process, hardware, documentation, security, compatibility, etc.
Testing
Update this section with details on how did you verify the change,
what Host was used for build (OS, CPU, compiler, ..), what Target was
used for verification (arch, board:config, ..), etc. Providing build
and runtime logs from before and after change is highly appreciated.