Re: Frsky s port
221 views
Skip to first unread message
Andrew Tridgell
Aug 5, 2014, 5:02:22 PM8/5/14
to Matthias Badaire, Craig Elder, drones-...@googlegroups.com
Hi Matthias,
> I have tried many things and i come to the conclusion that I need more than
> 50hz loop to make it work.
> @andrew: do you have an advice on what to look at for this ?
For better than 20ms response there are a few choices:
- you could use a timer or IO timer
- we could change plane and rover to use a 100Hz base scheduler tick on
faster CPUs, so that you can schedule in 10ms increments
- we could expose a richer set of scheduling primitives in AP_HAL (such
as exposing a threading interface)
I think using a IO timer is the right way to go, although it will need
some work in AP_HAL as right now UART read/write is not allowed from
timers.
To use a IO timer you would do this:
hal.scheduler->register_io_process(AP_HAL_MEMBERPROC(&MyClass::_my_timer));
and have a function _my_timer() in your class. The timer function will
be called at around 1kHz. The function would then check for available
bytes on the UART and respond as needed (being careful to not try to
read more than the number of bytes available, and not try to write more
than the available transmit space).
To make this work we will need to change AP_HAL_PX4/UARTDriver.cpp to
allow for read/write on UARTs from other than the main thread. The
simplest way to do that is to use a semaphore and to fail the IO if the
semaphore can't be claimed.
You would then need to make sure that all IO to the UART in the FrSky
library happens from the timer.
Note that IO timers run at a lower priority than the main thread, and
may sometimes be delayed if there is a lot of data going to the SD card
for logging. So while your timer would normally be called at 1kHz you
may find that occasionally it will have a delay of 0.2s or so while the
SD card writes some data. So your library will need to cope with
that. If that won't work then we could create a new scheduling level
above the IO level but below the main thread.
You will need to be very careful with locking in your library, as you
will be feeding telemetry data in from the main thread, but doing IO in
a different thread. You could use a semaphore or a lockless ringbuffer
to manage the data.
Cheers, Tridge
> I have tried many things and i come to the conclusion that I need more than
> 50hz loop to make it work.
> @andrew: do you have an advice on what to look at for this ?
For better than 20ms response there are a few choices:
- you could use a timer or IO timer
- we could change plane and rover to use a 100Hz base scheduler tick on
faster CPUs, so that you can schedule in 10ms increments
- we could expose a richer set of scheduling primitives in AP_HAL (such
as exposing a threading interface)
I think using a IO timer is the right way to go, although it will need
some work in AP_HAL as right now UART read/write is not allowed from
timers.
To use a IO timer you would do this:
hal.scheduler->register_io_process(AP_HAL_MEMBERPROC(&MyClass::_my_timer));
and have a function _my_timer() in your class. The timer function will
be called at around 1kHz. The function would then check for available
bytes on the UART and respond as needed (being careful to not try to
read more than the number of bytes available, and not try to write more
than the available transmit space).
To make this work we will need to change AP_HAL_PX4/UARTDriver.cpp to
allow for read/write on UARTs from other than the main thread. The
simplest way to do that is to use a semaphore and to fail the IO if the
semaphore can't be claimed.
You would then need to make sure that all IO to the UART in the FrSky
library happens from the timer.
Note that IO timers run at a lower priority than the main thread, and
may sometimes be delayed if there is a lot of data going to the SD card
for logging. So while your timer would normally be called at 1kHz you
may find that occasionally it will have a delay of 0.2s or so while the
SD card writes some data. So your library will need to cope with
that. If that won't work then we could create a new scheduling level
above the IO level but below the main thread.
You will need to be very careful with locking in your library, as you
will be feeding telemetry data in from the main thread, but doing IO in
a different thread. You could use a semaphore or a lockless ringbuffer
to manage the data.
Cheers, Tridge
Matthias Badaire
Aug 7, 2014, 3:01:34 PM8/7/14
to drones-...@googlegroups.com, Craig Elder
Hi
Thanks for taking the time. I am away from my machine for 2 weeks more but I am trying to see how I will do this.
For the semaphore in the uartdriver, we want to protect read and write function only ? Not all the classes? Basically it means to just take a sem if available and fail if not during the length of the function.
I need below 11ms resolution so this is the only way to do this. I tested with ac that has a 400hz loop and got good results.
M
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Matthias Badaire
Aug 24, 2014, 3:24:10 PM8/24/14
to drones-...@googlegroups.com, Andrew Tridgell
Hi,
Can you review this patch which is the first part toward Frsky S-PORT support.
I added semaphore on the IO of the UARTDriver for PX4
The rest is ready for SBUS but it needs some cleanup
If you are interested, it is mainly here
Thanks
Craig Elder
Aug 24, 2014, 3:51:30 PM8/24/14
to drones-discuss, Andrew Tridgell
Nice work Matthias. That is really cool.
Reply all
Reply to author
Forward
0 new messages