BOUNCE rtl@rtlinux.org: Approval required: Non-member submissionfrom ["Wayne E. Van Loon Sr." <wevl@pacifier.com>] (fwd)

[Der Herr Hofrat <der.herr@hofr.at>]

>From owner-rtl Tue May 22 14:31:07 2001
Received: from comet.pacifier.com (comet.pacifier.com [199.2.117.155])
	by hq.fsmlabs.com (8.11.2/8.11.2) with ESMTP id f4MKV7r31629
	for <rtl@fsmlabs.com>; Tue, 22 May 2001 14:31:07 -0600
Received: from pacifier.com (ip20.r4.d.pdx.nwlink.com [207.202.137.20])
	by comet.pacifier.com (8.11.2/8.11.1) with ESMTP id f4MKPwi20637
	for <rtl@fsmlabs.com>; Tue, 22 May 2001 13:25:59 -0700 (PDT)
Sender: wevl@pacifier.com
Message-ID: <3B0ACA7E.E50F988B@pacifier.com>
Date: Tue, 22 May 2001 13:22:22 -0700
From: "Wayne E. Van Loon Sr." <wevl@pacifier.com>
X-Mailer: Mozilla 4.61C-CCK-MCD Caldera Systems OpenLinux [en] (X11; I; Linux 2.2.13-rtl2.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: rtl@fsmlabs.com
Subject: Re: [rtl] Semi-beginner's (app design) questions
References: <001f01c0e2bc$2a600a00$0a85a8c0@goran>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Goran Bervar wrote:
> 
> Hello,
> 
> Good news: I am an experienced C(++) programmer familiar with computer
> hardware and different platforms. Bad news: I am completely new to RT Linux
> and also
> quite a beginner in Linux programming in general. I wrote some real-time
> (some would call it a quasi real-time) applications controlling user
> hardware in  good-old DOS or using a special "operating systems" such as
> pKernel. I am investigating the possibility to port one of my applications
> from DOS to RT Linux mainly for educational purposes. I've installed RT 3.0,
> went through examples and now - I am completely confused. I'll be grateful
> for any help you can give to kick me over the start of my project.
> 
> First, a layout of DOS application. I am trying to port a typical "two-task"
> single processor sampling application. The "user interface task" is running
> as a normal DOS application using a home-made GUI library (that is also
> ported to Linux using svgalib). The "real time task" is an interrupt handler
> routine trigged by the highest priority hardware IRQ with constant period,
> say 1 ms. Routine consists of IO operations (that must be done in constant
> period with minimal glitch) 

Do not know what you mean here by "minimal glitch"..

and some quite complex computations (that must
> be done at least just before the next interrupt). In DOS, IRQ routine simply
> blocks the execution of the OS (read: no STI  for the time of the execution)
> and takes approximately 60% of available processor time on 100 MHz Pentium
> processor time each time it runs. Tasks interact via shared memory using the
> only possible locking mechanism - user task disables interrupt for a very
> short time 

I assume this disable interrupt by the user task is for some I/O
operation. 

>while execution of IRQ routine can not be interrupted. Under DOS
> I know exactly what I am doing so it even works.
> 
> This is what I am planning to port to RT Linux. I suppose I should consider
> redesign of my application and here is where I need some help. First some
> questions:
> 
> 1) IMO it is always a bad idea to lock the serious RTOS (excluding DOS of
> course <g>) for such a long time. Can somebody explain what would happen
> under RTL if done so?
> 
> 2) Handling IRQ, I have to make all IO operations before re-enabling
> interrupts. I assume after that computation should be made in the highest
> priority task in RT kernel space. Is anything wrong with such a design? Some
> better ideas? Link to a similar example? And BTW, how to detect an overdue?
> 
Not sure that you need to disable interrupts assuming that you can
always 
accomplish your I/O and computations before the next sample time.
Especially
true if you have some other periodic requirement for rtl.

> 3) Can I use scheduling instead of IRQ to start the sample? How "accurate"
> is it?
> 
I am using rtl 2.0 and both scheduling and IRQ are very accurate, 
probably within 20 us. on 400 Mhz. K6-III.

> 4) Communication between threads is something I can not decide how to.
> Taking in account that there is quite some non-critical information from RT
> thread (mostly read-only) that user thread must read often (where the data
> *may* be partly incorrect now and than), what is in your opinion "the best"
> way to do it? Shared memory, FIFOs, messaging...?
> 
I would "push" the data from the rtl thread to the user Linux GUI
process 
using a rtl FIFO. In the Linux process, I would make a select call on
the 
FIFO and only spend time reading the FIFO when the rtl thread had
complete 
data ready.

I would also have a second FIFO from the user Linux task back to the rtl
process and use my rtl process as a driver. (Assuming that the Linux
task
has some I/O requirement)

> 5) I have some problem understanding RT Linux mutexes. Do they include
> priority switch to avoid priority dead locks?
> 
> Well, enough for the first post. I believe you'll hear from me again soon.
> 
> Sincerely
> 
> goran
> 
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail majordomo@rtlinux.org OR
> echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.org
> --
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/