Linux question -- how to tell if serial port in /dev is for real?

On Wed, 6 Aug 2014 05:16:13 +0000 (UTC)
Grant Edwards <invalid@invalid.invalid> wrote:

> 
> I do a _lot_ of desktop serial port stuff in support of embedded work,
> and all the desktop stuff is in Python -- and some of it needs
> response time measured in tens of microseconds.  I know a lot of other
> embedded developers do that as well.
> 
> -- 
> Grant
> 

I'll bite.  I do most of my desktop support in Python as well, but
always assume that at any time the combination of Python and the OS
may wallop me for any number of milliseconds, and that I just need to
suck up and deal, and find some other way to handle it when I need to
ensure realtimeyness.

How do you guarantee microsecond level response from Python (and I
assume Linux)?

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

On Wed, 06 Aug 2014 05:17:51 +0000, Grant Edwards wrote:

> On 2014-08-06, Tim Wescott <tim@seemywebsite.really> wrote:
>> On Tue, 05 Aug 2014 16:15:44 -0700, Paul Rubin wrote:
>>
>>> Tim Wescott <tim@seemywebsite.really> writes:
>>>> All of the desktop serial-port stuff I've done in the last decade has
>>>> been in support of embedded work, ...
>>>> So I'm constrained to C or C++.
>>> 
>>> If this is about embedded Linux, Python works great for that.
>>
>> Will Python run on an ARM Cortex M0 with 64k of ROM and 8K of RAM?
>> With room left over for actual application code?
> 
> No, but you said it was _desktop_ serial-port stuff.  Your desktop is an
> M0 with 64K of ROM and 8K of RAM?  And it suppors network access and an
> NNTP client!  That is impressive.

Actually I explained it in my original post: I'm running the software on 
a desktop, but it's written with a Linux serial driver and a cool GUI 
that are easy to lop off.  At some point all of the (by then hopefully 
well-tested) stuff in the middle will get shoved into an itty bitty 
processor on a board with two buttons and a 2 line by 16 character 
display.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Wed, 06 Aug 2014 16:51:48 +0300, Tauno Voipio wrote:

> On 6.8.14 05:39, Tim Wescott wrote:
>> On Wed, 06 Aug 2014 10:18:06 +0800, Reinhardt Behm wrote:
>>
>>> Grant Edwards wrote:
>>>
>>>> On 2014-08-05, Tim Wescott <tim@seemywebsite.please> wrote:
>>>>
>>>>> Thanks Rob.  Eventually I may get my head wrapped around all the
>>>>> termios stuff, probably ten minutes before I get run over by a beer
>>>>> truck.
>>>>
>>>> If you think the application level termios stuff is a mess, you
>>>> should take a look at the serial port APIs in the kernel...
>>>
>>> If you don't like the termios API you should try the serial port API
>>> in Windows. You will love termios thereafter.
>>
>> I know both, to my sorrow.
>>
>>
> Tim,
> 
> I sent an email to you about both - did you get it?

Yes I did -- thanks.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
> How do you guarantee microsecond level response from Python (and I
> assume Linux)?

Linux has a realtime scheduler but guaranteeing microsecond response is
not realistic because of nondeterministic cache misses and that sort of
thing.  For soft realtime maybe it's feasible.  Milliseconds are easier
than microseconds of course.

Python is interpreted and slower than C, but if the realtime loop is
simple, then you can generally have at least a "soft" bound on the
latency.  Memory management is by reference counting so there should be
no GC pauses unless you're building up large connected structures and
freeing them in one piece.

Paul Rubin <no.email@nospam.invalid> wrote:

> Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
> > How do you guarantee microsecond level response from Python (and I
> > assume Linux)?
> 
> Linux has a realtime scheduler but guaranteeing microsecond response is
> not realistic because of nondeterministic cache misses and that sort of
> thing.  For soft realtime maybe it's feasible.  Milliseconds are easier
> than microseconds of course.

or you use something like Linux RTAI that gives you hard real time.

Bye Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

pippo2@disney.com (Jack) writes:

> Paul Rubin <no.email@nospam.invalid> wrote:
>
>> Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
>> > How do you guarantee microsecond level response from Python (and I
>> > assume Linux)?
>> 
>> Linux has a realtime scheduler but guaranteeing microsecond response is
>> not realistic because of nondeterministic cache misses and that sort of
>> thing.  For soft realtime maybe it's feasible.  Milliseconds are easier
>> than microseconds of course.
>
> or you use something like Linux RTAI that gives you hard real time.

Is CONFIG_PREEMPT_RT dead?
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

On 06/08/14 20:56, Jack wrote:
> Paul Rubin <no.email@nospam.invalid> wrote:
>
>> Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
>>> How do you guarantee microsecond level response from Python (and I
>>> assume Linux)?
>>
>> Linux has a realtime scheduler but guaranteeing microsecond response is
>> not realistic because of nondeterministic cache misses and that sort of
>> thing.  For soft realtime maybe it's feasible.  Milliseconds are easier
>> than microseconds of course.
>
> or you use something like Linux RTAI that gives you hard real time.

.. providing, of course, the processor neither instruction nor
data caches. If either are present then the ratio of mean:max
latency rapidly becomes very significant.

Even a 486 with its tiny caches showed a 10:1 interrupt latency
depending on what was/wasn't in the caches. (IIRC that was measured
with a tiny kernel, certainly nothing like the size/complexity
of a linux kernel)

Tom Gardner <spamjunk@blueyonder.co.uk> writes:

> On 06/08/14 20:56, Jack wrote:
>> Paul Rubin <no.email@nospam.invalid> wrote:
>>
>>> Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
>>>> How do you guarantee microsecond level response from Python (and I
>>>> assume Linux)?
>>>
>>> Linux has a realtime scheduler but guaranteeing microsecond response is
>>> not realistic because of nondeterministic cache misses and that sort of
>>> thing.  For soft realtime maybe it's feasible.  Milliseconds are easier
>>> than microseconds of course.
>>
>> or you use something like Linux RTAI that gives you hard real time.
>
> .. providing, of course, the processor neither instruction nor
> data caches. If either are present then the ratio of mean:max
> latency rapidly becomes very significant.
>
> Even a 486 with its tiny caches showed a 10:1 interrupt latency
> depending on what was/wasn't in the caches. (IIRC that was measured
> with a tiny kernel, certainly nothing like the size/complexity
> of a linux kernel)

Aren't interrupt routines in some permanently-cached portion of the MMU?
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

On Wed, 06 Aug 2014 17:31:23 -0400, Randy Yates
<yates@digitalsignallabs.com> wrote:

>Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>
>> On 06/08/14 20:56, Jack wrote:
>>> Paul Rubin <no.email@nospam.invalid> wrote:
>>>
>>>> Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
>>>>> How do you guarantee microsecond level response from Python (and I
>>>>> assume Linux)?
>>>>
>>>> Linux has a realtime scheduler but guaranteeing microsecond response is
>>>> not realistic because of nondeterministic cache misses and that sort of
>>>> thing.  For soft realtime maybe it's feasible.  Milliseconds are easier
>>>> than microseconds of course.
>>>
>>> or you use something like Linux RTAI that gives you hard real time.
>>
>> .. providing, of course, the processor neither instruction nor
>> data caches. If either are present then the ratio of mean:max
>> latency rapidly becomes very significant.
>>
>> Even a 486 with its tiny caches showed a 10:1 interrupt latency
>> depending on what was/wasn't in the caches. (IIRC that was measured
>> with a tiny kernel, certainly nothing like the size/complexity
>> of a linux kernel)
>
>Aren't interrupt routines in some permanently-cached portion of the MMU?


There's no such thing on typical x86s.

On Wed, 06 Aug 2014 11:53:57 +0300, upsidedown@downunder.com wrote:

>On Wed, 06 Aug 2014 13:08:32 +0800, Reinhardt Behm
><rbehm@hushmail.com> wrote:
>
>>Robert Wessel wrote:
>>
>>> On Wed, 06 Aug 2014 10:18:06 +0800, Reinhardt Behm
>>> <rbehm@hushmail.com> wrote:
>>> 
>>>>Grant Edwards wrote:
>>>>
>>>>> On 2014-08-05, Tim Wescott <tim@seemywebsite.please> wrote:
>>>>> 
>>>>>> Thanks Rob.  Eventually I may get my head wrapped around all the
>>>>>> termios stuff, probably ten minutes before I get run over by a beer
>>>>>> truck.
>>>>> 
>>>>> If you think the application level termios stuff is a mess, you should
>>>>> take a look at the serial port APIs in the kernel...
>>>>
>>>>If you don't like the termios API you should try the serial port API in
>>>>Windows. You will love termios thereafter.
>>> 
>>> 
>>> Which one?  The traditional one or the TAPI one?  ;-)
>
>If one does not need any telephony related functions, why would one
>use the TAPI interface ?
>
>The basic Win32 CreateFile/ReadFile/WriteFile interface is easy to
>use. Of course you may also need GetComState/SetComState to set line
>speed and parity etc.


The TAPI functions allow you to share a device with other
applications.  So if your PC had a modem that was also used for
faxing, you could ask nicely if the modem was available.  Which is not
possible with the traditional API - the fax program would always have
the serialport/modem open for receiving faxes.