[rtl] DMA and realtime

2000-06-30 Thread eric

>

Anyone got a working example of a dma/interrupt real-time example.  I can't even
crash my
computer:(
thanks,
eric


-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] FSCK and power up

2000-06-30 Thread Bernhard Kuhn

Olaf Petzold wrote:

> I'm one of the people who havn't such luck. After a clean reboot, the contents
> of several source files was merged, so I found contents from file a.c inside
> file b.c and so on. This experience is less than an half year hold. Maybee I
> did some wrong things but, the install manual was from linux magazin and was
> descibted detailed.


Then, you really had bad luck :-(

I am using reiserfs for more than half a year now, on all my
machines i do my daily work. Because i have to bother around
with many unstable drivers for brand new products, the
machines are crashing very often ... maybe a hundred
times up to now. And of course, i sometimes shut down
the machines regular :-)

Just know, i am typing this mail using linux-2.4.0-test2-ac2 with
reiserfs ... 

btw: i don´t have a streamer and don´t do backups :-)
(ok, more or less usefull things are backuped throug the web)
but maybe that is like jumping from a big building: while
passing each levels, you can state "until know everything
just went fine" :-)

Maybe i just had luck all the time, but on the other hand:
there was some kind of bug half a year ago in reiserfs
that prevented SuSE from using it as the default filesystem.

But now, SuSE and Mandrake offer reiserfs as alternative
filesystem in it´s graphical installer ... SuSE even
encourages their customers to use reiserfs ...

At least, i heard nothing bad about reiserfs for months,
and more and more people are using it ...

But you are right, to be 100% sure, use ro-mounted ext2
and a ramdisk for /tmp (/var and /project can be rw-mounted ext2,
since the fsck won´t take much time, if the filesystem
is kept small)

Bernhard
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] FSCK and power up

2000-06-30 Thread Bernhard Kuhn

Adam Meyerowitz wrote:
> 
> Does anyone have a web site or something where I can grab some info on
> reiserFS..

http://devlinux.com/projects/reiserfs/


BTW: there are more journaled filesystems on the way:
xfs from sgi and jfs from ibm, but it will take
a while until they are usable. Don´t tell about
ext3 ... i fear that Steven Tweedy will *never*
have the time to finish it :-)   or better :-(

Bernhard
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




[rtl] Re: [realtime] RTAI Vs RTLinux

2000-06-30 Thread yodaiken

On Fri, Jun 30, 2000 at 06:11:01PM +0200, Paolo Mantegazza wrote:
> The above is agreed totally. For me the two solutions are conceptually
> the same. In fact the practicall loss of performance on lesser machine
> can be proved to be marginal on the base of experience. To be precise I

I see some numbers with lmbench that worry me -- not too much, but
1% here, 1% there and pretty soon you have NT.

> In any case you must admit that it was not so when you rejected my
> proposal on March 1999. In any case if any marginal performance loss
> exists between the two solutions it is just on Linux, real time is not
> suffering in any case.

I went back and looked at the discussion and can't see what bothers you
so much.  Probably I'm just insensitive.

> > BTW: Paolo and anyone else out there.  There has for a long time
> > been  an invitation to send complaints if you feel slighted in the CREDITS
> > file that is part of the RTLinux distribution. Send
> > me a list of what you believe
> > your contributions to be and, unless it is totally absurd, I'd be happy
> > to put it in the distribution.
> 
> I do not ask for any credit, just admit it was not saw 1.5 years ago.
> After all we are discussing things that a lot of Computer Science
> graduates can do quite easily for free, just if it payed a meaningfull
> grade increase for their thesis.
> 
> My proposal is the same as for March 1999( see:  

I have the same reaction: yes, function pointers are convenient at times,
no I don't see how this should be a design paradigm.  So if you want
a public  acknowledgment that Paolo Mantegazza released code
implementing  the RTLinux method using function pointers before we did, 
I have always been happy to make such an acknowledgement. If you want me
to agree that this is the critical step for a "hardware abstraction",
I still disagree.


> > For those who want to know. Linus notes that in the x86,
> > cli/sti/pushfl/popfl are 8 bit instructions.  Replacing these
> > with a "move mem,reg, call reg" inflates code and may cause cache
> > misses -- cli becomes a 10 byte or so operation instead of 1. The core Linux
> > developers are obsessive about cache lines, for good reason, and
> > we do see a minor slowdown in Linux on some x86s when any form
> > of RTLinux indirection is added. This was not always the case, but
> > base Linux IRQ handling has improved.
> 
> The problem is clearly not one of bytes but of cycles of excution. The

The problem is actually more a problem of bytes and cache misses.

> outcome depends on how many bytes of code the above are protecting. In
> any case RTL and RTAI are using them as such so, I repeat, it is just a

The cache miss won't come on the fetch of the cli_function, but  from the
general expansion of code -- but let's not argue this since we both agree
it is usually not anything to worry about.


> problem of having Linux pay a marginal cost, not the hard real time
> applications running unde RTL/RTAI. 

We pay the cost in cache misses, but see above.

> 
> Ciao, Paolo.

-- 
-
Victor Yodaiken 
FSMLabs:  www.fsmlabs.com  www.rtlinux.com
FSMLabs is a servicemark and a service of 
VJY Associates L.L.C, New Mexico.

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] select function in user space fifo read

2000-06-30 Thread Jürgen Appel

>Would someone please write me a code snippet which shows the proper
>usage of the select function when used to wait for data to be sent to a fifo 
>from kernel-space. 

Here you are:
 
 
 fd_set rfds;  
 int fd_control,fd_data,fd_error;   

 if ((fd_data = open(RT_FIFO_DATA, O_RDONLY)) < 0) {
fprintf(stderr, "Error opening " RT_FIFO_DATA "\n");
exit(1);
  }

  if ((fd_error = open(RT_FIFO_ERROR, O_RDONLY)) < 0) {
fprintf(stderr, "Error opening " RT_FIFO_ERROR "\n");
exit(1);
  }

   /* Wait for data showing up in either fd_data or fd_error
   no time-outs. For time-outs look at the according manpage 
   man 2 select */
FD_ZERO(&rfds);
FD_SET(fd_data, &rfds);
FD_SET(fd_error, &rfds);
select(FD_SETSIZE, &rfds, NULL, NULL, NULL);

if (FD_ISSET(fd_data, &rfds)) { // got data from in fd_data 
...
}
  
if (FD_ISSET(fd_error, &rfds)) { // got data from in fd_error 
...
}

>Does select to a busy-wait?
No.


-- 
[EMAIL PROTECTED]
PGP key: http://www.math.uni-goettingen.de/appel/jappel.pgp
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




[rtl] NEC D71055l-10 (8255, PLCC) replacement

2000-06-30 Thread Jacek M. Holeczek

Hi,
This is a little bit strange question on this list, but ...
I have here a couple of I/O cards with 8255 on them (actually NEC
D71055l-10). The problem is that quite often people shortcircut its
outputs to the ground, or to +5V, or to another output. Usually the chip
is dead then. I am looking for a replacement of these NEC chips from
another manufacturer which would be much less sensitive to such problems.
I don't really care about the output current (i don't need much), but I
really need a chip which survives shortcircuits (lasting 1 - 2 seconds
typically).
Thanks in advance,
Jacek.
P.S. No chance to protect these chips on board. All outputs are directly
 connected to the 8255. Jacek.

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




[rtl] RTAI Vs RTLinux

2000-06-30 Thread Paolo Mantegazza

[EMAIL PROTECTED] wrote:

> Paolo: you do know that the PowerPC port of Linux was partly written
> by Cort Dougan during his Masters project at New Mexico Tech?
> I was the supervisor for that project.
> Would you like to be credited for the use of indirect pointers in
> the PowerPC port?

Not at all, I said "natively" to mean that it is there without any need
of further intervention, almost. Do no provoke too far.
 
> If we ignore wording and consider whether there is
> any fundamental virtue in the indirect pointer method, we have a real
> difference. To my way of thinking, the implementation of the RTLinux
> intercept of interrupt control should be purely a question of balancing
> programmer time and hardware efficiency. We would like to do an optimized
> version of RTL for the many embedded 486/low-power Pentium machines and
> here the indirect pointer becomes a performance problem -- partially
> because of the smaller caches. The operation:
>   fetch instruction
>   call emulation
> can be noticeably  faster than
>   fetch instruction
>   do pointer arithimetic
>   fetch indirect pointer
>   call what was pointed to
> 
> In a modern OOO processors, the caches and pipelines
> are so deep  that the difference is minimal. But that's not necessarily
> the case for Elan4xx or a strongarm or a mips core embedded in an ASIC or
> a MPC860.  And it is not necessarily even always the case for high
> end processors.
> So, for me, indirect function pointer/static pointer is merely a
> difference in how the abstraction is implemented -- the user sees no difference
> other than possibly performance. And as someone whose instincts are to
> both guard every cycle and to allow for greatest flexibility in
> implementation,insisting that we always use the indirect function pointer
> seems a clearly wrong decision -- a decision to impose a low level
> non-optimal implementation  as a design fundamental.

The above is agreed totally. For me the two solutions are conceptually
the same. In fact the practicall loss of performance on lesser machine
can be proved to be marginal on the base of experience. To be precise I
have such an experience only on 486 and low end Pentiums, all going out
of market also on PC104. 486 correspending Cyrix and AMD based PC-104
are already a lot better. See the comment on cli/sti/pushfl/popfl
further on. \
In any case you must admit that it was not so when you rejected my
proposal on March 1999. In any case if any marginal performance loss
exists between the two solutions it is just on Linux, real time is not
suffering in any case.

> BTW: Paolo and anyone else out there.  There has for a long time
> been  an invitation to send complaints if you feel slighted in the CREDITS
> file that is part of the RTLinux distribution. Send
> me a list of what you believe
> your contributions to be and, unless it is totally absurd, I'd be happy
> to put it in the distribution.

I do not ask for any credit, just admit it was not saw 1.5 years ago.
After all we are discussing things that a lot of Computer Science
graduates can do quite easily for free, just if it payed a meaningfull
grade increase for their thesis.

My proposal is the same as for March 1999( see:  
Subject: [rtl] Real Time Application Interfaces/
From: Paolo Mantegazza <[EMAIL PROTECTED]> 
Date: Tue, 09 Mar 1999 11:34:44 +) in the RTL mailing list archives.

> For those who want to know. Linus notes that in the x86,
> cli/sti/pushfl/popfl are 8 bit instructions.  Replacing these
> with a "move mem,reg, call reg" inflates code and may cause cache
> misses -- cli becomes a 10 byte or so operation instead of 1. The core Linux
> developers are obsessive about cache lines, for good reason, and
> we do see a minor slowdown in Linux on some x86s when any form
> of RTLinux indirection is added. This was not always the case, but
> base Linux IRQ handling has improved.

The problem is clearly not one of bytes but of cycles of excution. The
outcome depends on how many bytes of code the above are protecting. In
any case RTL and RTAI are using them as such so, I repeat, it is just a
problem of having Linux pay a marginal cost, not the hard real time
applications running unde RTL/RTAI. 

Ciao, Paolo.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] FSCK and power up

2000-06-30 Thread Adam Meyerowitz

Thanks all for the quick responses to my question below.  Being a relative 
Linux newbie the responses
will save me a lot of time.

Much appreciated,
Adam

At 09:19 PM 6/29/00 -0400, you wrote:
>Hello all,
>
>I have a embedded linux machine using RTLinux that does not have a power 
>switch.  When ac is
>applied it boots up and to power it down just pull the plug.  However 
>since we cannot properly shut
>down linux, everytime we do this the system goes through the long fsck 
>process.
>
>Is there anyway to get around this without just disabling fsck on boot 
>up.  It would be nice if somehow
>an abnormal shutdown (like pulling the power), did not screw up the 
>filesystem.
>
>Has anyone come up with any solutions.
>
>Any pointers would be greatly appreciated.
>
>Thanks
>Adam
>
>-- [rtl] ---
>To unsubscribe:
>echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
>echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
>---
>For more information on Real-Time Linux see:
>http://www.rtlinux.org/rtlinux/
>

--
Adam Meyerowitz
Senior Software Engineer
Video Data Systems
40 Oser Avenue
Hauppauge, NY 11788
Tel# 631-231-4400
Fax# 631-231-4405
[EMAIL PROTECTED]
www.videodatasystems.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] FSCK and power up

2000-06-30 Thread Adam Meyerowitz

Does anyone have a web site or something where I can grab some info on 
reiserFS..

Thanks for the help,
Adam

At 08:59 PM 6/29/00 -0600, Cort Dougan wrote:
>You could try reiserfs.  Several people have had good luck with it.
>
>} I have a embedded linux machine using RTLinux that does not have a power
>} switch.  When ac is
>} applied it boots up and to power it down just pull the plug.  However since
>} we cannot properly shut
>} down linux, everytime we do this the system goes through the long fsck 
>process.
>}
>} Is there anyway to get around this without just disabling fsck on boot
>} up.  It would be nice if somehow
>} an abnormal shutdown (like pulling the power), did not screw up the 
>filesystem.
>}
>} Has anyone come up with any solutions.
>}
>} Any pointers would be greatly appreciated.

--
Adam Meyerowitz
Senior Software Engineer
Video Data Systems
40 Oser Avenue
Hauppauge, NY 11788
Tel# 631-231-4400
Fax# 631-231-4405
[EMAIL PROTECTED]
www.videodatasystems.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] RTAI Vs RTLinux

2000-06-30 Thread yodaiken

On Fri, Jun 30, 2000 at 10:10:16AM +0200, Paolo Mantegazza wrote:
> Jeff Studer wrote:
> > 
> > I think the point you missed, Karim, was that a function pointer is no big
> > deal.  The fact someone makes out like it was, is sort of silly.
> 
> So I was a silly guy from the very beginning, the good guys became such
> afterwards only afterwards. BTW: then all PPC Linux is a silly code as
> most basic mach dep functions, including sti/cli equivalents, are
> pointers natively.

Paolo: you do know that the PowerPC port of Linux was partly written
by Cort Dougan during his Masters project at New Mexico Tech?
I was the supervisor for that project.
Would you like to be credited for the use of indirect pointers in 
the PowerPC port?

> Clearly I do not think so, in fact all Linux versions should be
> structured that way. Note that I'm not supporting that specific
> implementation but just the idea behind it, i.e. a complete HAL, which
> despite someone's claim is not present yet in i386 Linux.

>From my perspective, i386 Linux provides a clear irq control
hardware abstraction layer. If it did not RTLinux would be impossible
and Linux portability would be a joke.
The hardware layer  consists of the operations {cli,sti, enable_irq,disable_irq
save_flags, restore_flags} and all the irq_save/spinlock operations for
SMP. This layer was present (except for the SMP parts) in very
early versions of Linux. From Paolo's perspective, as I understand it,
when the layer is implemented in the form of macros (as in the x86 native
Linux) it is not a hardware abstraction layer, however, when it is implemented
via function pointers (as in the PowerPC native Linux) it does implement
a hardware abstraction layer. 
 I don't share this perspective and I think
it violates the standard usage of the term "abstraction" in this
part of computer science. IBM implements an "abstraction layer" in the
390s in the microcode. This is an abstraction layer in my book, and 
would remain so if it were implemented in the hardware state machine
or in a Virtual Basic function. 

Suppose we write the C code;
 x = funcname;
 x();
and "cc rt_nobel_prize_winning_code.c" gets us
move, $funcname,reg
call *reg
and "cc -O2 rt_nobel_prize_winning_code.c" gets us peephole optimization
and the result:
call funcname


Is the result of the first compile "hardware abstraction", while the 
second is not? 


If we ignore wording and consider whether there is
any fundamental virtue in the indirect pointer method, we have a real 
difference. To my way of thinking, the implementation of the RTLinux
intercept of interrupt control should be purely a question of balancing
programmer time and hardware efficiency. We would like to do an optimized
version of RTL for the many embedded 486/low-power Pentium machines and
here the indirect pointer becomes a performance problem -- partially
because of the smaller caches. The operation:
  fetch instruction
  call emulation
can be noticeably  faster than
  fetch instruction
  do pointer arithimetic
  fetch indirect pointer
  call what was pointed to

In a modern OOO processors, the caches and pipelines
are so deep  that the difference is minimal. But that's not necessarily
the case for Elan4xx or a strongarm or a mips core embedded in an ASIC or
a MPC860.  And it is not necessarily even always the case for high
end processors.
So, for me, indirect function pointer/static pointer is merely a
difference in how the abstraction is implemented -- the user sees no difference
other than possibly performance. And as someone whose instincts are to 
both guard every cycle and to allow for greatest flexibility in 
implementation,insisting that we always use the indirect function pointer
seems a clearly wrong decision -- a decision to impose a low level  
non-optimal implementation  as a design fundamental. 

BTW: Paolo and anyone else out there.  There has for a long time
been  an invitation to send complaints if you feel slighted in the CREDITS
file that is part of the RTLinux distribution. Send
me a list of what you believe
your contributions to be and, unless it is totally absurd, I'd be happy
to put it in the distribution.

For example:
Paolo Mantegazza should be credited for: 
1. First use of 8253 timers in periodic mode in RTLinux.
2. Major input in getting floating point working on RTLinux.
3. First use of indirect pointers to implement the intercept
   of cli/sti in an RTLinux type system.
4. --- 10^300  
...

whatever. Just send me a note. Try to keep it under 1 megabyte.


> Torvalds likely does not like it and is accepting such a solution for
> other archs just because that helps in promoting his creature and, being
> almost god but not completly, cannot do everything by

R: [rtl] Current state RTLinux?

2000-06-30 Thread Giovanni Racciu

Dear Ossi,

I don't have any specific data, but I can tell you that we are controlling 3
to 6 motors with a PC104 (AMD5x86 @ 133Mhz) board and RT (of course), and
the timing of the whole loop is 0.3 ms (including reading, data exchange and
so on).
I am sure that with a P166 you can easily achieve better performances.
Jitters was another issue we analized, expecially we were suspecting DMA to
increase them, but with the experience I could tell you we have never find
them (that is, they are neglegible).
If you are looking back into this mail-list there is a lot of material on
jitters and latencies.

Ciao
Giovanni


-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] Is it possible to perform network operations from RTLinux task?

2000-06-30 Thread David Schleef

On Thu, Jun 29, 2000 at 03:20:47PM -0400, Ajay Avasthi wrote:
> Is it possible to send out UDP packets on a network from an RTLinux
> task?  If so, how?
> 
> Ajay
> 

If you don't need real-time performance, use a user-space helper
task.

If you _do_ need real-time performance, Lineo ISG (a.k.a., the
artist formerly known as Zentropix) will be releasing a real-time
networking package "any day now."  I know, we've been saying that
for a long time now, but it is now possible to allocate some
resources to clean it up and stabilize additional drivers.

Since it is derived from Linux networking, it is, of course, GPL.




dave...

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] rtfifos out of rttasks?

2000-06-30 Thread Stuart Hughes

Ivan Martinez wrote:
> 
> Hello all
> I'm programing Control Lib to use a rtfifo to start rttasks execution.
> The rtfifo has a handler that wakes the rrtasks up when executed. So
> actually no rttask uses the rtfifo.
> I could use a character device, but I don't like their interface (that
> thing of major numbers). Also I don't know if they can have handlers.
> Is what I'm doing dirty programing?. Thank you.
>
Hi Ivan,

IMHO these seems fine to me.

Regards, Stuart
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] FSCK and power up

2000-06-30 Thread Stuart Hughes

Hi Adam,

If your footprint is not too large (e.g no X etc), another possibility
is to build a root filesystem compressed image (for your system) and
then boot the system as an initrd and run out of ramdisk.  You will be
safe to pull power without shutting down.

To do this, you need to put the kernel that matches your compressed
rootfs modules in the usual place (e.g /boot/ramkernel) and then add
similar to following to your lilo.conf and re-run lilo.

image=/boot/ramkernel
label=ramsystem
ramdisk=8192# depending on size  
initrd=/boot/rootfs.gz
root=/dev/ram0
read-only

If your footprint is large, Cort's suggestion seems like the best
option.

Regards, Stuart


Cort Dougan wrote:
> 
> You could try reiserfs.  Several people have had good luck with it.
> 
> } I have a embedded linux machine using RTLinux that does not have a power
> } switch.  When ac is
> } applied it boots up and to power it down just pull the plug.  However since
> } we cannot properly shut
> } down linux, everytime we do this the system goes through the long fsck process.
> }
> } Is there anyway to get around this without just disabling fsck on boot
> } up.  It would be nice if somehow
> } an abnormal shutdown (like pulling the power), did not screw up the filesystem.
> }
> } Has anyone come up with any solutions.
> }
> } Any pointers would be greatly appreciated.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




[rtl] rtfifos out of rttasks?

2000-06-30 Thread Ivan Martinez

Hello all
I'm programing Control Lib to use a rtfifo to start rttasks execution.
The rtfifo has a handler that wakes the rrtasks up when executed. So
actually no rttask uses the rtfifo.
I could use a character device, but I don't like their interface (that
thing of major numbers). Also I don't know if they can have handlers.
Is what I'm doing dirty programing?. Thank you.
-- 
Ivan Martinez (Rodriguez)
BEng in Software Engineering - MEng student
http://www.student.dtu.dk/~u990873
"Got fabes?"
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] FSCK and power up

2000-06-30 Thread Olaf Petzold

Am Fre, 30 Jun 2000 schrieben Sie:
> You could try reiserfs.  Several people have had good luck with it.

I'm one of the people who havn't such luck. After a clean reboot, the contents
of several source files was merged, so I found contents from file a.c inside
file b.c and so on. This experience is less than an half year hold. Maybee I
did some wrong things but, the install manual was from linux magazin and was
descibted detailed.
At moment I use ro partitions - only /tmp, /var, /usr/src/projects are rw.

CU Olaf
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




[rtl] device-problem

2000-06-30 Thread Steffen Hildebrandt

Hello Paolo,

I have a great problem. I have compiled RTAI 1.2 with a linux-kernel
2.2.14.
It works fine. I have a kernel-module to control a AD/DA-card.
The module can initialize the RTAI-fifos and I can initialize, open and
close the RTAI-devices (/dev/rtfx) in my Linux-user-programm as root.
I have a user apg and a group uucp. The rights for the devices /dev/rtfx
are
set  for user apg und group uucp, but the user apg can't open the
devices (/dev/rtfx). Thats my problem.
Is there a possibility to change the group or whatever to get the chance
to open the devices?

Tanks.
With regards Steffen.

-- 

Steffen Hildebrandt

GESKO GmbH Dresden
Tiergartenstrasse 50
01219 Dresden
Germany

mailto:[EMAIL PROTECTED]

Tel.: +49 351 43639312
Fax : +49 351 43639318

e-mail (Pivat) : 
mailto:[EMAIL PROTECTED]
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] select function in user space fifo read

2000-06-30 Thread Pavel Andris

Hi Daniel,

I think the reply will be the same for RTL & RTAI users :-).

On Thu, Jun 29, 2000 at 08:31:15PM -0500, daniel sheltraw wrote:
> Hello RTAIers
> 
> Would someone please write me a code snippet which shows the proper
> usage of the select function when used to wait for data to be sent to a fifo 
> from kernel-space. 

man select is your best friend.

> Does select to a busy-wait?

Waiting depends on the last parameter of select function. I think the 
waiting is active (ie other processes are run).

Some chunks of my code (messy, not exactly what you want, it's about
writing to a fifo from user space, easy to modify):

--

static int fifo_0;
static struct timeval timeout={0,1}; // timeout fifo operations
static fd_set fds;  // for select (fifo)
static char *str="/dev/rtf0";

static void openFifo()
{ if((fifo_0=open(str,O_WRONLY))==-1)   // open fifo
  { fprintf(stderr,"fifo open %s, %s\n",str,strerror(errno)); 
exit(0);// if failed
  }
  atexit(closeFifo);
}

static void closeFifo()
{ close(fifo_0);
}

void writeFifo(int code)
{ int j;
  FD_ZERO(&fds);
  FD_SET(fifo_0,&fds);
  if((j=select(fifo_0+1,NULL,&fds,NULL,&timeout))>0) // if OK to write
  { if((j=write(fifo_0,(char *)&code,sizeof(int)))!=sizeof(int))
{ fprintf(stderr,"writeFifo/write returned %d, %s\n",j,strerror(errno));
  exit(0);
}
  }
  else
  { fprintf(stderr,"writeFifo/fifo not ready for write, %d chars written\n",j);
exit(0);
  }
}

---

Regards,

pa

-- 
..
Pavel Andris   | tel: +421 7 5941 2167
Institute of Control Theory and Robotics   | fax: +421 7 5477 6045
Slovak Academy of Sciences | 
Dubravska cesta 9  | e-mail: [EMAIL PROTECTED]
SK - 842 37 Bratislava |
Slovakia   |
.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] Bonehead question

2000-06-30 Thread Pavel Andris

Hi Dick,

On Thu, Jun 29, 2000 at 02:32:49PM -0700, Richard Myers wrote:
> Hi,
> 
> Sorry if this is a stupid question.  I'm trying to build an RTL 2.3
> module made up of several .c files.  All of the init, clean up, fifo
> handling and main task code are in one .c file.  The other .c files
> contain generic functions.  I can't seem to get them to compile and link
> correctly.  Are there any example Makefiles out there which show how to
> compile several .c files into one RTL .o module?  Every example I've
> found has just one RT .c file.
> 

Your question occurs periodically in this list, should be put to a
FAQ file. Your friend is called partial linking (ld -r). My example
follows.

ld -r ./obj/dspgm.mo ./obj/radic.mo ./obj/bankar.mo ./obj/insfil.mo 
  ./obj/ruovl.mo ./obj/kinem.mo ./obj/konst.mo ./obj/prmul.mo 
  ./obj/invul.mo ./obj/algeb.mo ./obj/affix.mo ./obj/chybnik.mo 
  ./obj/vykfo.mo ./obj/syntax.mo ./obj/sensor.mo ./obj/host.mo 
  ./obj/declare.mo ./obj/move.mo ./obj/inter.mo ./obj/synch.mo 
  ./obj/begend.mo ./obj/savloa.mo ./obj/ttdrv.mo ./obj/display.mo 
  ./obj/tabul.mo -L/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66 
  -L/usr/lib -L../../libobjs -lmodn -lm -lgcc -M 
  -o robol.m > ./maps/robol.m.map

where 

robol.m is   the loadable RT module (product of the linking)
./obj/*.mo   objects obtained by separete compilation of *c files (gcc -c)
-L*  library path
-l*  name of the library to be linked with
./maps/robol.m.map - map file 

Regards,

pa

-- 
..
Pavel Andris   | tel: +421 7 5941 2167
Institute of Control Theory and Robotics   | fax: +421 7 5477 6045
Slovak Academy of Sciences | 
Dubravska cesta 9  | e-mail: [EMAIL PROTECTED]
SK - 842 37 Bratislava |
Slovakia   |
.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] RT background reading

2000-06-30 Thread Paolo Mantegazza

daniel sheltraw wrote:
> 
> Hello realtimers
> 
> Would someone please tell me where I can find something to read about
> the various timer/counters used in PCs. This will help me ask more
> intelligent questions about RT. Also does anyone have a good reference for
> background reading on the PIC/APIC and how it is managed under RTAI. Any
> additional reading suggestions would be welcome as well.
> 
> Thanks everyone,
> Daniel
> 
> Despite the recent RTL vs RTAI discussion on this listing I think this is a
> great forum on RT.

Many IC makers produce 8254(timer)/8259(PIC), e.g. Harris and Oki. Go to
their sites and dowonload the related data sheets.That will give all
what is needed for true UP Pcs. For the IO-APIC I downloaded the related
INTEL data sheet, while for Pentiums local APICs my reference is chapter
7 of the 3rd volume, system programming guide, of the Pentium manuals
trilogy. The one I used is filed as 24319201.pdf (from Intel site). APIC
knoweledge is, at the moment, needed only if you have MP motherbords.

With those documents at hand look at the 4 timer functions at the end of
rtai.c, if it is not enough ask specific questions again.

Ciao, Paolo.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




[rtl] Current state RTLinux?

2000-06-30 Thread Ossi Laakkonen

Hi,
does anyone know if there is any web sites or does anyone have
information about RTLinux and its timing limits for example how fast
periodic tasks can be executed and how large jitters will exists and so
on. 
My goal is to find out is it possible to use RTLinux (with Pentium 166)
to control motor because it needs pretty fast period times (few task
with 10's to 100's of lines code) from 50 us to 500 us.   
So I would need test data.

Regards, Ossi

--
Ossi Laakkonen  
Lappeenranta University of Technology   tel. +358-5-6216782
Department of Electrical Engineeringmob. +358-50-3530354
P.O.Box 20  fax. +358-5-6216799
FIN-53851 Lappeenranta
FINLAND
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] RTAI Vs RTLinux

2000-06-30 Thread Paolo Mantegazza

Jeff Studer wrote:
> 
> I think the point you missed, Karim, was that a function pointer is no big
> deal.  The fact someone makes out like it was, is sort of silly.

So I was a silly guy from the very beginning, the good guys became such
afterwards only afterwards. BTW: then all PPC Linux is a silly code as
most basic mach dep functions, including sti/cli equivalents, are
pointers natively.
Clearly I do not think so, in fact all Linux versions should be
structured that way. Note that I'm not supporting that specific
implementation but just the idea behind it, i.e. a complete HAL, which
despite someone's claim is not present yet in i386 Linux.
Torvalds likely does not like it and is accepting such a solution for
other archs just because that helps in promoting his creature and, being
almost god but not completly, cannot do everything by himself.  

The truth is that pointers are not so silly as they affect only Linux
and ease making real time simpler, without any real time loss of
performace since real time does use those machine instructions that are
forbidden to Linux.

As I said many times people that want to enter this discussion should
read the code and know the whole story from its beginning. If they have
no time they should stay shut up. It makes no sense to take excerpts of
the whole story only because they can be bent to your own deceiving
aims.

So I suggest you just go to www.rtlinux.org, browse their March 1999
archives for:

Subject: [rtl] Real Time Application Interfaces/
From: Paolo Mantegazza <[EMAIL PROTECTED]> 
Date: Tue, 09 Mar 1999 11:34:44 +

It is a rather long and annoying one, but you should read it to get an
hystorical perspective for my claims.

Then look at the following mails and check the, deceiving, debate that
went on at that time against the present one on the subject. Even
better, dowload all the RTL and myrtlinux/RTAI versions from the very
beginning and cross check them. Maybe you can end in writing a book
paralling Pulitzer prize winners "The Making of the atomic/H bomb", but
it should be called "the making of real time Linux, how to smuggle
business as OSS ethos"

Ciao, Paolo.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/