-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Jiminy Support for hwrng and at86rfr2 transceiver #8742
Conversation
Josar
commented
Mar 5, 2018
•
edited
Loading
edited
- Support for hwrng
- Included at86rfr2 support into at86rf2xx driver.
Could you open a separate PR for the atmega stack pointer commit? It will make review easier and keep this PR focused on one task. |
@gebart done |
16379c3
to
35917ee
Compare
@PeterKietzmann maybe this is also interresting for you as you have the hardware at hand. ;-) |
@gebart and @PeterKietzmann just curious if someone has time to review this? |
@Josar, currently I don't have time to provide a proper review. I do my best to come back to this soon, but I can't promise anything. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some unrelated changes in here (code style, whitespace fixes etc) which I think is fine to have in the PR, but they should be in a separate commit before all of the rfr2 additions. There are also a few points in the rfr2 driver where I have some comments, see inline comments below
@@ -5,3 +5,4 @@ include $(RIOTCPU)/atmega_common/Makefile.features | |||
|
|||
# Various other features (if any) | |||
FEATURES_PROVIDED += periph_cpuid | |||
FEATURES_PROVIDED += periph_hwrng |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing newline at end of file
drivers/at86rf2xx/at86rf2xx.c
Outdated
#include "od.h" | ||
#endif | ||
|
||
#ifdef MODULE_AT86RFR2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this whole block could go in its own file at86rfr2_isr or something? It's the only CPU dependent functionality in the driver so it makes sense to move it out of the generic parts.
cpu/atmega256rfr2/periph/hwrng.c
Outdated
|
||
/* Manual p. 119 radio transceiver in Basic Operating Mode receive state*/ | ||
while (TRX_STATUS != 0x06) { | ||
TRX_STATE = 0x06; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am worried that this will lead to a race between the radio driver and the hwrng driver
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please eleborate this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Imagine this scenario:
- two threads: a low priority thread that uses the hwrng, a high priority thread that reacts to some outside event (e.g. gpio interrupt, or timer)
- hwrng thread is running and using the hwrng
- outside event occurs, low priority thread is pre-empted in favor of the high priority thread
- high priority thread wants to interact with the radio in some way (e.g. Send packet or put the radio to sleep)
- hwrng has left the transceiver in an unexpected state. <- possible problem
- high priority thread finishes
- hwrng restores a state which was saved before, possibly overwriting what the high priority thread did. <- Possible problem.
cpu/atmega256rfr2/periph/hwrng.c
Outdated
regVal = regVal >> 5; | ||
regVal = regVal << 2 * i; | ||
rnd |= regVal; | ||
xtimer_usleep(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this sleep necessary to the hardware timing? It is short enough to be better suited for xtimer_spin.
drivers/at86rf2xx/at86rf2xx.c
Outdated
|
||
#ifdef MODULE_AT86RFR2 | ||
/* Store device pointer for interrupts */ | ||
static_dev = (netdev_t *)dev; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume the at86rfr2 only ever has one transceiver in the same CPU
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a SOC and will ever features only one transceiver.
You could also add an additional external transceiver, but this is also not featured with the current implementation. And i do not see why someone would do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this would fall under #4876. The static_dev variable is fine since there is only one instance of the rfr2
/* enable interrupts */ | ||
at86rf2xx_reg_write(dev, AT86RF2XX_REG__IRQ_MASK, | ||
AT86RF2XX_IRQ_STATUS_MASK__TRX_END); | ||
/* clear interrupt flags */ | ||
at86rf2xx_reg_read(dev, AT86RF2XX_REG__IRQ_STATUS); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated change, please split into its own commit
drivers/at86rf2xx/at86rf2xx.c
Outdated
// dev->idle_state = state; | ||
// } | ||
|
||
while (state != AT86RF2XX_STATE_TX_ARET_ON) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is not obvious what it fixes, what was broken before?
It should probably go in a separate commit.
drivers/Makefile.dep
Outdated
@@ -19,16 +19,18 @@ ifneq (,$(filter at30tse75x,$(USEMODULE))) | |||
FEATURES_REQUIRED += periph_i2c | |||
endif | |||
|
|||
ifneq (,$(filter at86rf2%,$(USEMODULE))) | |||
ifneq (,$(filter at86rf2% at86rfr2,$(USEMODULE))) | |||
USEMODULE += at86rf2xx | |||
USEMODULE += xtimer | |||
USEMODULE += luid | |||
USEMODULE += netif | |||
USEMODULE += ieee802154 | |||
USEMODULE += netdev_ieee802154 | |||
FEATURES_REQUIRED += periph_gpio |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the rfr2 need gpio?
|
||
#ifdef MODULE_AT86RFR2 | ||
/* SOC uses no SPI, but uses memcpy */ | ||
#include <string.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should not be indented
#ifdef MODULE_AT86RFR2 | ||
|
||
/* check if frame buffer protection is active, rx frame was not read jet*/ | ||
/* if( ( *(AT86RF2XX_REG__TRX_CTRL_2) &(1<<RX_SAFE_MODE)) != 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dead code
One more question: does the hwrng driver stand on its own or does it require the at86rf2xx driver to be initialized beforehand? |
The hwrng is intentional not dependent on the at86rf2xx Module. This maybe lead to a little bit of overhead but i think this is okay. |
Is there any risk that initialization of the hwrng driver will mess up the state of the at86rf2xx driver? They are touching the same hardware after all |
Yes, there is. And for that all states are saved and set back to previous states. Reading exactly what you wrote, NO, there is nothing done in initialization. Everything is done when reading some random numbers and set back afterwards. |
81086d4
to
05e1494
Compare
5306d1a
to
f60ee90
Compare
@gebart tried to addressed your requests. Had to rebase as evtimer changes had to be applied for proper function. |
@gebart and @PeterKietzmann maybe you could find some time to review this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hwrng: Some code style issues exist, and I am not sure that xtimer is necessary in the current implementation.
Did not have time to review the radio changes
uint8_t rnd = 0; | ||
for (uint8_t i = 0; i < 4; ++i) { | ||
/* Random value update period 1us p. 47*/ | ||
xtimer_spin(wait); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this necessary?
I imagine that the CPU instructions leading up to this point take at least 1 µs on atmegas?
transition(); | ||
|
||
/* Manual p. 119 radio transceiver has to be in Basic Operating Mode receive state*/ | ||
if ( (TRX_STATUS&0x1f)!= 0x06) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this 0x1f magic number is used in several places in this file, it should be converted to a define, or if possible, reuse the hardware register bit masks from the radio driver.
RX_SYN &= ~(1 << RX_PDT_DIS); | ||
|
||
/* Manual p. 105 RPC/SRT has to be disabled. */ | ||
TRX_RPC &= ~(1<<RX_RPC_CTRL1 | 1<<RX_RPC_CTRL0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uncrustify should be able to fix code style spacing and indentation issues in this file. There is a configuration in the RIOT tree root (uncrustify-riot.cfg)
Closed in favor of #9172 @gebart thread concurrency has to be solved in future releases so i will skip hwrng in favor of the transciever. |