[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Paparazzi-devel] Non-blocking module code
|
From: |
Felix Ruess |
|
Subject: |
Re: [Paparazzi-devel] Non-blocking module code |
|
Date: |
Thu, 5 Jul 2012 00:44:18 +0200 |
Hi Gareth,
yes, there are no "real" threads so far. So a usleep blocks everything except the low level interrupt driven parts of drivers and systime...
Not sure what the best way would be to stop transmitting anything (including replies to settings, waypoint, .. changes).... It should probably by done in the datalink subsystem itself.
But with the current macro based solution this is really hard to do. I was hoping we could completely ditch the macro style messaging in favor of callback function style messaging with the new message system....
Cheers, Felix
On Wed, Jul 4, 2012 at 11:22 AM, Gareth Roberts
<address@hidden> wrote:
Hi Limaiem & Reto,
in practical way you use the procedure output I mean xbee_reset_ticks to push ananalog output to high during a certainperiod of time to reset the xbee modul ?
I tried this approach initially but found a couple of issues.
The XBee reset pin is open drain, which means it needs grounding to reset. The only pins capable of doing this without additional components are SDA & SCL from I2C-1, as per Jeremies solution.
Unfortunately, on my Umarim I2C-1 is used to drive the IMU.
I then tried using a transistor driven from the usual LED_ macros. Unfortunately, my particular XBees fail to come back up after reset if you are transmitting to them about 25% of the time.
AT commands
As Reto says, I turned to the gluonpilot solution of using AT commands to reset the xbee.
The disadvantages are:
- There is a 2 second stop in telemetry inherent in the reset process
The advantages:
- It should work with any paparazzi board
- It's a software only modification
For my use case, a 2 second interruption in telemetry every 5 minutes is not an issue.
How it works:
Thanks to the cunning mind of Stephen Dwyer, most messages are handled in a fairly elegant manner.
You need to have a modified telemetry section which includes a <mode name="blank"></mode> in both Ap and Fbw sections.
The current telemetry mode is switched over to the blank telemetry, and then restored after reset.
However, this doesn't stop all telemetry. My branch also contains modifications to main_ap.c, consisting of guard statements which check a disable_telemetry flag around a few hardcoded telemetry calls. I've also modified datalink.c to support this flag. When this flag is set to true, all hardcoded telemetry calls should stop.
You need to define <define name="ALLOW_TELEMETRY_DISABLE" /> in the firmware section of your airframe file to enable these guards.
Whilst I can do a github pull request, there may well be a more elegant solution to the hardcoded calls, so it would be great if one of the experienced developers could comment on this.
Also, whilst I have tested this on the ground for several hours and works quite happily, I haven't yet taken it flying.
Therefore, I wouldn't recommend using this module in air for now - I posted it for development feedback, not as a finished product.
Cheers,