In some point in past it may have been ttyS2, but right now on kernel
4.16+ the UART is on ttyS5. We could do like is done for I2C and search
on sysfs, but it requires additional changes.
Apparently this code came in part from libuavcan that defines this
struct Control. They also had the same issue detailed on
https://github.com/UAVCAN/libuavcan/issues/116.
The solution here is much simpler though: stick to the design of cmsg()
even if it's C. As per cmsg(3), use a union together with CMSG_SPACE().
Use a const variable instead of a define so we don't polute the
environment with a define specific to this function.
Also remove tabs and replace with proper coding style.
This adds a counter here to only loop to a maximum number of iterations.
Now we avoid situations in which we would be stuck processing packets here.
This also adds some other meaningful defines
Removes compile-time selection of RCInput driver for ocpoc_zynq.
PPM and SBUS input are now colocated on the ocpoc board, and it
only needs to run RCInput_ZYNQ. Pulse input is also inverted
to accommodate SBUS input, which has no effect on PPM input.
On kernels 4.7+ duty_cycle should always be less than period.
Otherways, we'll get a EINVAL.
It makes sense to set duty_cycle to 0, as
duty_cycle doesn't really make sense without a proper period.
A proper way to handle these errors might be to call pwm_adjust_config
in every pwmchip backend but it's unrealistic to hope that all vendors
will do it quickly.
If we are the controlling terminal for a tty device we will receive a
SIGHUP when the device disappears. Currently what happens is that we
simply stop the whole process. We don't want to fall off the sky due
to a bad device. This can happen for any reason, but it's more likely
if the UART is behind a USB connection.
These messages are only valid in a small subset of Linux boards (those
based on BBB and variants). The ToneAlarm class should actually be
split allowing different implementations, but for now let's just disable
the message.
It's not being sold, there are just a few (different) engineering
samples built and there are no plans for this to go forward for people
that were pushing it.
There's an implicit (apart from the name) dependency between SPI and
SPIUARTDriver which results in a crush on a restart or a shutdown.
By moving the initialization we're making sure that all objects are
deleted in the right order.
_export_path and _duty_path will have been already long time gone by the
time dtors kick in.
Probably better to use OwnPtr around those. But it's better to be done
in a separate PR.
Checking the time on the tcpdump capture, it matches the first fields
from the data:
$ tshark -n -c 4 -r ~/tmp/solo/rc.pcap
1 0.000000 10.1.1.1 → 10.1.1.10 UDP 68 5005 → 5005 Len=26
2 0.019976 10.1.1.1 → 10.1.1.10 UDP 68 5005 → 5005 Len=26
3 0.040046 10.1.1.1 → 10.1.1.10 UDP 68 5005 → 5005 Len=26
4 0.059961 10.1.1.1 → 10.1.1.10 UDP 68 5005 → 5005 Len=26
From the previous commit (first 2 packets):
5fa8 f441 3414 0500 73d7 dc05 dc05 dc05 db05 e803 e803 e803 f401
73f6 f441 3414 0500 74d7 dc05 dc05 dc05 db05 e803 e803 e803 f401
0x0005143441f45fa8 - 0x0005143441f4f673 = 0x4E14 = 19988 (usec)
Which seems to approximately match for the other packets as well. We are
not using the field since we rather get the time when we receive it, but
at least use a better name.
If a thread other than the main one calls Scheduler::delay() we could
end up triggering the call of delay callbacks. Those should only ever
happen on the main thread.
We are setting a termination handler for some signals which are of not
interest. Just ignore them. Ignoring SIGWINCH allows for example to
run on a screen and change the window size later without killing
ardupilot.
RPI-based boards that use RCInput_RPI need more stack space otherwise we
end up with stack corruption. This leads to crash particularly when also
using GPIO_RPI since it may change what that driver is poking on memory.
This increases stack size to 1M which is overkill for most of other
boards with a more controllable stack usage. However this exposes that
on multiple different HWs a single point for stack size decision may not
be the best. This can be improved in future.
While at it, add final and override to mark this as being the overriden
final implementation of this method.
Thanks to Phillip Khandeliants (@khandeliants) for reporting.
While at it, add final and override to mark this as being the overriden
final implementation of this method.
Thanks to Phillip Khandeliants (@khandeliants) for reporting.
Lucas De Marchi
Andrew Tridgell
Francisco Ferreira
Michael du Breuil
mirkix
Peter Barker
Mark Whitehorn
chobits
Dmitri Ranfft
Siddharth Purohit
Nikita Tomilov
Tom Pittenger
Alexey Bulatov
HeBin
Georgii Staroselskii
alexshirley
Georgii Staroselskii
Lucas De Marchi
Aaron Wang Shi
davidaroyer
hiro2233
Pierre Kancir
Eugene Shamaev
murata