fmu handle sensor_reset, peripheral_reset, i2c in board #11347
Conversation
|
@dagar While I appreciate the cleanup, the original reason for these commands to be present was to also induce errors / resets on the bench and see if the hardware recovers. We lose that capability with this PR. |
|
We can have a simple command line for each that's actually used. |
dagar
force-pushed
the
pr-board_peripheral_reset
branch
from
d854010 to
0422467
Compare
| @@ -399,5 +399,15 @@ __EXPORT int board_app_initialize(uintptr_t arg) | |||
|
|
|||
| #endif | |||
|
|
|||
| /* | |||
There was a problem hiding this comment.
I think we are not doing the GPIO init and this just masks the root issues.
As a side note are we ok delaying Boot? We can Break the reset into 2 pieces, it is all GPIO manipulation. Make the arch init set things up correctly. Then use the delay 3+ ms. from the aching to the app init. Then set up a call back to finish the job.
There was a problem hiding this comment.
Yes I figured this would prompt the discussion to check for what's actually needed.
- create new standalone board control command
dagar
force-pushed
the
pr-board_peripheral_reset
branch
from
0422467 to
156e2fd
Compare
|
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions. |
|
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions. |
The
fmucommandssensor_reset,peripheral_reset,i2ccan all be handled better by the board itself.I will test this on a range of good and questionable fmu-v4 units.