On Tue, 10 Oct 2017 10:23:50 -0700 (PDT), Paul Van den Bergh
<
vdberg...@gmail.com> declaimed the
following:
>Hi Denis,
>
>Thanks for your reaction.
>
>In <termios.h> the same baudrates as in your post are mentioned. However,
>after googling about the topic I'm now investigating in the ioctl()
>function. For the moment I have this in my code:
>
<SNIP>
>This compiles without errors or warnings. But before I can test it I have
>to investigate in the "never ending story of device tree overlays".
>
I don't think it will help. Compiling/linking shouldn't be a concern --
all the arguments are literals/constants. It is run-time when the driver
does the configuration that will likely return some errno value (probably
EINVAL).
At the lowest level, any baud setting by ioctl() has to configure the
hardware UART clock/dividers, and the driver is likely limited to the
values documented in the TRM.
>BTW I cannot use one of the PRUSS processors because they are both used for
>other purposes.
>
Going to insane concepts now:
Time to plug in an Arduino (Mega and Due have 4 HW UART, Uno only has
one and uses a software emulated UART for others) programmed as a
serial<>serial baud rate converter <G> {SoftwareSerial only supports
standard rates; the hardware is implied to support non-standard: "You can,
however, specify other rates - for example, to communicate over pins 0 and
1 with a component that requires a particular baud rate."}
http://wormfood.net/avrbaudcalc.php?bitrate=65200&clock=16&databits=8
{applies to Uno; Due is not an AVR chip}
Or maybe the BBPocket to use one of its PRUs programmed as a UART with
non-standard baud rate with the regular UART talking to the BBB on a
standard rate. <G>