Re: [rtl] Interrupts

2000-06-26 Thread yodaiken

On Thu, Jun 22, 2000 at 03:29:23PM +0100, Stuart Hughes wrote:
 What is a good complaint ??? doesn't the 'P' in POSIX stand for portable
 ? What you continually offer is non-portable extensions that make it
 impossible to run the same code on any environment other than RTLinux.  

Continually? Really, the API has been pretty dull for nearly a year.
But RTLinux _is_ different than other environments.  

 A better idea might be to use what exists so that we all have a chance
 of running our code on a number of operating systems.  May I suggest
 that a SIGHUP may be construed as a wakeup signal to a thread (it has
 been used context before), this may be bogus too, but you get the idea:
 try to use something that has a chance of being portable. 

SIGHUP is fine. Actually, WAKEUP is defined as 1 so SIGHUP will
do the same thing. I'm not sure if it is better, however, to pretend that
we are doing something you can do in Chorus or PSOS. After all, you 
are sending an interrupt from the RTkernel to a Linux subthread and this
is not something that "exists" or can be done on other operating systems.

We've had this discussion before and I remain convinced (under the
delusion?) that there are two different needs:

1. Pedal to metal, simple and appropriate APIs for RTLinux specific
   code: for this I like our LightWeight POSIX PThreads. Needs some
   fleshing out, but the technical soundness and coherency seem to 
   me to have been proven out.
2. Compatibility libraries that make it easy to move code from 
   legacy operating systems. 

What I most definitely do not want to do is to re-discover all the
errors and ugliness in Chorus that made me want to have RTLinux 
in the first place. I realize that people who have huge Chorus or
PSOS or ... programs will find it inconvenient that RTLinux native
programs, designed using our idea of decoupling RT and non-RT will
greatly outperform their code, but my theory is that the RTLinux
approach to RT is fundamentally _better_ than prior programming
models and I don't see any way to magically repair the damage created
by mixing RT with non-RT in one incoherent mass of code.



-- 
-
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 Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




[rtl] Chrash using network

2000-06-26 Thread npace

After I insert modules for RTAI/LXRT (rtai, rtai_sched, lxrt), If I try to 
download a file via ftp to my target, the system always crash with a kernel panic. 
Crashes happen
for rather large file ( 500K), for small file transfers seem to work.
I am using RTAI1.3, Linux 2.2.14, and the upscheduler on a 486/100 embedded board with 
16M ram, no swap disk.
The network chipset is a PCI Realtek 8139. Note that I have no realtime user 
process/tasks module active 
(only the core module installed). If I don't install the realtime modules the system 
works fine.

What could I do ?

Best regards 
Eng. Nicola Pace


 

--
TiscaliFreeNet, libero accesso ad Internet.
http://www.tiscalinet.it

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




Re: [rtl] Chrash using network

2000-06-26 Thread Stuart Hughes

npace wrote:
 
 After I insert modules for RTAI/LXRT (rtai, rtai_sched, lxrt), If I try to
 download a file via ftp to my target, the system always crash with a kernel panic. 
Crashes happen
 for rather large file ( 500K), for small file transfers seem to work.
 I am using RTAI1.3, Linux 2.2.14, and the upscheduler on a 486/100 embedded board 
with 16M ram, no swap disk.
 The network chipset is a PCI Realtek 8139. Note that I have no realtime user 
process/tasks module active
 (only the core module installed). If I don't install the realtime modules the system
 works fine.
 
 What could I do ?
 
 Best regards
 Eng. Nicola Pace
 

Hi Nicolo,

Do you have a hard drive in the system or is it loading to a RAM disk ??

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




Re: [rtl] hrtime_t - int

2000-06-26 Thread Michael Barabanov

Cory Papenfuss ([EMAIL PROTECTED]) wrote:
   Hey all... I've got something that's been bugging me for awhile on this
 project.  I really only need millisecond resolution (since I'm logging data to
 disk), but the hrtime_t doesn't like to be divided by 1000 (NS_PER_MS), as
 it's a funky type.  Any way I can get around that and get a millisecond
 timestamp?

What do you mean it doesn't like to be divided? hrtime_t is just
an alias for long long.

   On a related note, I've got a user-space app that can send new
 pthread_make_period_np periods (again in [ms]).  Problem is that if I try to
 send a time greater than 2147 ms, the machine craps out.  I suspect it's a
 rollover on my 
 
 looptime = some_int_from_fifo * 100;
 pthread_make_periodic_np(thread[0], genesis+OFFSET, looptime);
 
 
 What's a good way to do arithmetic on these hrtime_t creatures?

looptime = some_int_from_fifo * (long long) 100;

Michael.

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




Re: [rtl] Chrash using network

2000-06-26 Thread Paolo Mantegazza

npace wrote:
 
 After I insert modules for RTAI/LXRT (rtai, rtai_sched, lxrt), If I try to
 download a file via ftp to my target, the system always crash with a kernel panic. 
Crashes happen
 for rather large file ( 500K), for small file transfers seem to work.
 I am using RTAI1.3, Linux 2.2.14, and the upscheduler on a 486/100 embedded board 
with 16M ram, no swap disk.
 The network chipset is a PCI Realtek 8139. Note that I have no realtime user 
process/tasks module active
 (only the core module installed). If I don't install the realtime modules the system
 works fine.
 
 What could I do ?

I have tried it under a PC-104, 486 DX66 with a flash Diskonchip2000.
With the hard real time lxrt sem_clock example running, i.e. with a
significant load, I've dowloaded tens of megabytes, at 4 Mbytes/s, many
times, without any problem.

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




Re: [rtl] More interrupt confusion

2000-06-26 Thread Michael Barabanov

eric keller ([EMAIL PROTECTED]) wrote:
 We were running the  nice example programs from Mirko
 Holler.  Looking at parport.c, he calls
 rtl_request_irq(7, handler)
 then he does this:
 outb_p(inb_p(0x21)  (~0x80),0x21);  //enable interrupt 7
 outb_p(0x20,0x20);
 //clear in service register
 rtl_hard_enable_irq(7);
 
 This program directly manipulates the interrupt controller
 to enable its interrupt line.  does this
 code make sense? or is it redundant?
 eric

For RT-interrupts, the low-level irq handling code works as follows

handler:
mask_interrupt_line
ack_irq_controller
call RT-handler
return_from_interrupt

So if it's needed to receive further interrupts from the device,
one has to explicitely re-enable the interrupt line in the handler.

Michael.

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




Re: [rtl] More interrupt confusion

2000-06-26 Thread eric keller

Michael Barabanov wrote:


 For RT-interrupts, the low-level irq handling code works as follows

 handler:
 mask_interrupt_line
 ack_irq_controller
 call RT-handler
 return_from_interrupt

 So if it's needed to receive further interrupts from the device,
 one has to explicitely re-enable the interrupt line in the handler.

 Michael.

That's the way i understand it.  What i didn't quite understand is
this
code where he installs the interrupt handler

   rtl_no_interrupts(f);

   status = rtl_request_irq(7, intr_handler);
   /* enbable parallel port interrupt */
   outb_p(inb_p(0x37A) | 0x10, 0x37A);

   outb_p(inb_p(0x21)  (~0x80), 0x21);  //confusing
   outb_p(0x20, 0x20);//confusing

   rtl_hard_enable_irq(7);

   rtl_restore_interrupts(f);

I added comments where i am confused.  He directly
manipulates the irq controller in those lines.  My understanding of
rtl is
that you don't have to do that, so i took those two lines out, but it
didn't
work always. Then i took out the lines where he says rtl_no_interrupt
and
rtl_restore_interrupt and then it works again.
Now my code looks like this:

status = rtl_request_irq(7, intr_handler);
   /* enable parallel port interrupt */
   outb_p(inb_p(0x37A) | 0x10, 0x37A);
   rtl_hard_enable_irq(7);

This should install the interrupt 7 handler and enable interrupt 7,
right?
thanks,
eric





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




[rtl] Re: [realtime] Experiences with Real-Time Tulip driver

2000-06-26 Thread Gautam H Thaker

We will use [EMAIL PROTECTED] in future. 

I believe we will wait for your new version of RT_Tulip. I agree that we
should be comparing worst case times since RT_tulip is there to control
this worst case behaviour. However, I have to believe something is wrong
with our set up since the RT_Tulip roundtrip latencies are coming out so
much larger than TCP. A factor of 100 tells me something is not right. I
think people might accept RT_Tulip that is 10x slower in *average* case
than TCP if it means the worst case is well bounded, but a 100x?

Gautam

[EMAIL PROTECTED] wrote:
 
 Please send queries to [EMAIL PROTECTED] as the realtimelinux mailing
 list is one we don't monitor often.
 
 RT_tulip has worked well for us in the past. We intend to make a new
 version in the next month or two.
 
 Please compare round trip latency -- worst cases. Generic TCP/IP will
 be good in average case but RT_tulip is designed to reduce worst case.
 
 On Thu, Jun 15, 2000 at 03:47:20PM -0400, Gautam H Thaker wrote:
  We have been experimenting with the below:
 
  RT_Tulip: An RTLinux-based PCI Ethernet Realtime Driver
  A PCI Ethernet network driver for the Tulip Network card under Realtime 
Linux,
  that shares network bandwidth with Linux.
 Submitted by: Axel Bernal([EMAIL PROTECTED])
 
  We are trying to simply send the string "hello_there" from one machine
  to another. We observe two things:
 
  1) When the message gets to the receiver it is of correct length (11
  bytes in this case) but it contains garbage.
 
  2) The round trip message latency is coming in at about 6000 usec, or
  about 100x slower than generic DEC TULIP driver with a 4 byte TCP
  message round trip.
 
  3) Entire system seems fragile and we see frequent crashes.
 
  4) What can be done with RT_TULIP driver that can't be done with "tc"
  command and network QoS support such as CBQ queue discipline, etc.?
 
  Has this RT_TULIP worked for anyone? Is there anyone around that knows
  about this code or is this an old, dormant project.
 
 
 
 
  --
  Gautam H. Thaker
  Distributed Processing Lab; Lockheed Martin Adv. Tech. Labs
  AE 3W; 1 Federal Street; Camden, NJ 08102
  856-338-3907, fax 856-338-4144  email: [EMAIL PROTECTED]
 
 --
 -
 Victor Yodaiken
 FSMLabs:  www.fsmlabs.com  www.rtlinux.com
 FSMLabs is a servicemark and a service of
 VJY Associates L.L.C, New Mexico.

-- 
Gautam H. Thaker
Distributed Processing Lab; Lockheed Martin Adv. Tech. Labs
AE 3W; 1 Federal Street; Camden, NJ 08102
856-338-3907, fax 856-338-4144  email: [EMAIL PROTECTED]
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] hrtime_t - int

2000-06-26 Thread Cory Papenfuss

I've (sorta) figured it out.  The int must first be cast as a long long
or the multiplication will overflow, but when I tried putting a division in a
rt-space function to return miliseconds since boot, I get 

./init.o: unresolved symbol __divdi3

when I try to load up my init.o module.  Is the access of the longlong division
forbidden within rt-space?

BTW, getlrtime that produced that error is little more than

unsigned long int getlrtime(void){
  return((unsigned long)((long long)gethrtime() / 100LL)
}

-Cory
On Mon, 26 Jun 2000, Michael Barabanov wrote:

 Cory Papenfuss ([EMAIL PROTECTED]) wrote:
  Hey all... I've got something that's been bugging me for awhile on this
  project.  I really only need millisecond resolution (since I'm logging data to
  disk), but the hrtime_t doesn't like to be divided by 1000 (NS_PER_MS), as
  it's a funky type.  Any way I can get around that and get a millisecond
  timestamp?
 
 What do you mean it doesn't like to be divided? hrtime_t is just
 an alias for long long.
 
  On a related note, I've got a user-space app that can send new
  pthread_make_period_np periods (again in [ms]).  Problem is that if I try to
  send a time greater than 2147 ms, the machine craps out.  I suspect it's a
  rollover on my 
  
  looptime = some_int_from_fifo * 100;
  pthread_make_periodic_np(thread[0], genesis+OFFSET, looptime);
  
  
  What's a good way to do arithmetic on these hrtime_t creatures?
 
 looptime = some_int_from_fifo * (long long) 100;
 
 Michael.
 


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




[rtl] Mbuff v0.6.6 Install

2000-06-26 Thread Estabridis, Janet P

Hi,

I'm using kernel 2.0.36 with RTL v0.9J.  Currently I am using the old style
shared memory (only have up to 4 MBytes).  I need to increase this to
support my maximum data storage. I have the .pdf instruction and have read
the README and FAQ's that come with the source.  So, this should be easy for
someone to answer ...

1.  Install in the README, it says, "Make sure you have in /usr/src/linux
the configured source of the currently running kernel."  is this a file
named ".config"  and how do I create one since there is not one there ?  


Janet Estabridis
Electrical Engineer
NAWC Code 473E00D
Building 31440 Room 1017
China Lake, CA 93555
[EMAIL PROTECTED]
(760) 939-2896  FAX (760) 939 -3075

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




Re: [rtl] Mbuff v0.6.6 Install

2000-06-26 Thread Steve Papacharalambous

"Estabridis, Janet P" wrote:
 
 Hi,
 
 I'm using kernel 2.0.36 with RTL v0.9J.  Currently I am using the old style
 shared memory (only have up to 4 MBytes).  I need to increase this to
 support my maximum data storage. I have the .pdf instruction and have read
 the README and FAQ's that come with the source.  So, this should be easy for
 someone to answer ...
 
 1.  Install in the README, it says, "Make sure you have in /usr/src/linux
 the configured source of the currently running kernel."  is this a file
 named ".config"  and how do I create one since there is not one there ?
 
 Janet Estabridis
 Electrical Engineer
 NAWC Code 473E00D
 Building 31440 Room 1017
 China Lake, CA 93555
 [EMAIL PROTECTED]
 (760) 939-2896  FAX (760) 939 -3075
 
 -- [rtl] ---
 To unsubscribe:
 echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
 echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
 ---
 For more information on Real-Time Linux see:
 http://www.rtlinux.org/rtlinux/

Hi Janet,

I believe that this means that /usr/src/linux and /usr/include/asm
should be symbolic links that point to the 2.0.36 RTL-0.9J kernel source
files on your machine,

Best regards,

Steve

-- 

Zentropix - A Lineo company.
Visit http://www.zentropix.com/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] hrtime_t - int

2000-06-26 Thread David Schleef

On Mon, Jun 26, 2000 at 09:22:44AM -0500, Cory Papenfuss wrote:
   I've (sorta) figured it out.  The int must first be cast as a long long
 or the multiplication will overflow, but when I tried putting a division in a
 rt-space function to return miliseconds since boot, I get 
 
 ./init.o: unresolved symbol __divdi3
 
 when I try to load up my init.o module.  Is the access of the longlong division
 forbidden within rt-space?


Long long division requires a function call to a function that is
part of libgcc.  Do to 'executive decision' in the kernel, i.e.,
it's been that way forever, libgcc is not linked with the kernel.
(Libgcc _is_ linked with the kernel for most non-i386 architectures,
however.)  You have the option of making a difference 'executive
decision', and link your module with libgcc.



dave...

 
 BTW, getlrtime that produced that error is little more than
 
 unsigned long int getlrtime(void){
   return((unsigned long)((long long)gethrtime() / 100LL)
 }
 
 -Cory
 On Mon, 26 Jun 2000, Michael Barabanov wrote:
 
  Cory Papenfuss ([EMAIL PROTECTED]) wrote:
 Hey all... I've got something that's been bugging me for awhile on this
   project.  I really only need millisecond resolution (since I'm logging data to
   disk), but the hrtime_t doesn't like to be divided by 1000 (NS_PER_MS), as
   it's a funky type.  Any way I can get around that and get a millisecond
   timestamp?
  
  What do you mean it doesn't like to be divided? hrtime_t is just
  an alias for long long.
  
 On a related note, I've got a user-space app that can send new
   pthread_make_period_np periods (again in [ms]).  Problem is that if I try to
   send a time greater than 2147 ms, the machine craps out.  I suspect it's a
   rollover on my 
   
   looptime = some_int_from_fifo * 100;
   pthread_make_periodic_np(thread[0], genesis+OFFSET, looptime);
   
   
   What's a good way to do arithmetic on these hrtime_t creatures?
  
  looptime = some_int_from_fifo * (long long) 100;
  
  Michael.
  
 
 
 -- [rtl] ---
 To unsubscribe:
 echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
 echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
 ---
 For more information on Real-Time Linux see:
 http://www.rtlinux.org/rtlinux/
 
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




Re: [rtl] More interrupt confusion

2000-06-26 Thread Michael Barabanov

 status = rtl_request_irq(7, intr_handler);
/* enable parallel port interrupt */
outb_p(inb_p(0x37A) | 0x10, 0x37A);
rtl_hard_enable_irq(7);
 
 This should install the interrupt 7 handler and enable interrupt 7,
 right?

Right.
outb_p(inb_p(0x21)  (~0x80), 0x21);  //confusing
outb_p(0x20, 0x20);//confusing

These two are not needed. However, rtl_no_interrupts/rtl_restore_interrupts
presence should make no difference.
Do you mean that when they are present,
you don't always get parport interrupts?

Michael.

PS What version of RTL is this?

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




[rtl] audio

2000-06-26 Thread yodaiken


Anyone here working on audio?


-- 
-
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 Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




[rtl] SHM mmap question

2000-06-26 Thread S.A.

Is it possible to use named files to access shared mem inside RTLinux
instead of /dev/mem ?


 if ((fd = open("./file", O_RDWR))  0)
{
  /* handle error here */
}

ptr  = mmap .

bye
steph


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




[rtl] Floating Point???

2000-06-26 Thread Daniela Soares de Almeida

Hi Gabor, Hoffman and all,

First, i'd like to apologize come back to this point now but in the last
days i've been trying to understand (trough your e-mails) and testing my
program to learn how can i use FP in my own programs, but to be honest some
things, even now, aren't clear for me.
  Before talk about my doubts i'd like to thank Gabor for his help
about rtl_printf: I changed all  printk with rtl_printf and my system began
work better although it still freeze sometimes. I'd like to thank Hoffman
too and everybody that sended e-mails about this point. 
After my mail talking about my "system freezing" Hoffman asked me if the
floating point reference ("10.0") in my init_module() code couldn't be
causing the crash. Well, when he asked this i really didn't know the
answer, now (after many mails) seems to me that it could be the problem but
my practice results are bring me doubts.

To test my module i removed all the rtl_printf calls. Now my program seems
work very well, without crashs. Important points: I'm still using FP in my
init_module() and fifo handlers and i don't call pthread_setfp_np (or
something like that) in any point of my code.

Hoping you can help me to understand this,
   
Daniela. 

P.S.: My module is attached. Sorry but i didn't have time to translate the
comments.

/* Driver para controle de um duplo integrador. Daniela Almeida 16/05/2000 */
/* This program makes the interface between a GUI (not RT) and  AD/DA boards. It looks 
for work with
 2 kinds of AD/DA boards and V1.1 and V2.2 of RTL, both choosed through #define */

#ifndef MODULE
#define MODULE
#endif

#ifndef __KERNEL__
#define __KERNEL__
#endif

#ifndef __RT__
#define __RT__
#endif

// Define se o drive sera para a versao 1.1 ou 2.2 do RTLinux e se sera para a placa 
DAS1600 ou AIO (STD)

//#define V1//Escolhe entre as versoes 1.1 e 2.2 do RTL
#define V2

//#define AIO   //Escolhe entre as placas AD/DA  AIO(STD) e DAS1601
#define DAS1600

#define OSC //Define se havera uma onda quadrada na porta paralela 
para teste

#include linux/module.h
#include linux/kernel.h
#include linux/version.h
#include linux/errno.h
#include linux/cons.h
#include linux/ioport.h
#include linux/string.h

#include pthread.h

#include asm/io.h

#include rtl_sched.h
#include rtl_fifo.h
#include "declaracoes.h"

#ifdef AIO
#include "placa_ai.h"   // header com os enderecos da placa AD/DA do STD
#endif

#ifdef DAS1600
#include "placa16.h"  // header com os enderecos da placa AD/DA DAS1600
#endif

#ifdef V1
RT_TASK tarefa[2];
#endif

#ifdef V2
pthread_t tarefa[2];
#endif


//Definicao das variaveis de tempo

#ifdef V2
hrtime_t RT_TICKS_CTRL; //Variavel utilizada para determinar o tempo de amostragem 
para o controle
hrtime_t RT_TICKS_SAVE; //Variavel utilizada para determinar o tempo de amostragem 
para salvar os dados nas fifos
hrtime_t ONDA_QUADRADA;
hrtime_t ONDA_QUADRADA2;
#endif


#ifdef V1
RTIME  RT_TICKS_CTRL; //Variavel utilizada para determinar o tempo de amostragem para 
o controle
RTIME  RT_TICKS_SAVE; //Variavel utilizada para determinar o tempo de amostragem para 
salvar os dados nas fifos
RTIME  ONDA_QUADRADA;
RTIME  ONDA_QUADRADA2;
#endif


parametros_PID PID;  // Ganhos do PID
mensagens MSG;  // Mensagens de inicializacao e mudanca de periodo
float uf, vf;
int ub;
int valor;
float tensao;
float h;
float ek, pk, dk, otensao, ref;
float ik;
float N=20.0;
float Nh;
float escala; //escala de medicao: VADPP/4095.0 (converte para volts)
int a=1;
int range;   // Range de enderecos ocupados pelo AD
int dispara_ad;   //String que dipara o AD
int controle_ad;  //String que controla o funcionamento da placa AD/DA

float FREQHZ;
float VADPP;
int contador; //Contador que controla a onda quadrada
int sinal;  // Sinal da onda quadrada

int count=0;

#ifdef AIO
static int AIO_port_base=0x0300;   //Se zero a base sera lida do arquivo .h
#endif

#ifdef DAS1600
static int das1601_port_base=0;  //Se zero a base sera lida do arquivo .h
#endif




void *lei_controle(void *t)
{
  while (1) {
if (count  100)  //rotina para teste
{
//rtl_printf("Lei de controle Chamada,count= %i\n",count);
count = count+1;
}

#ifdef DAS1600
valor = ( (inb(AD0)  0x0F0)  4 | ((inb(AD1)  0x0FF)  4));  // Aquisicao da 
posicao
tensao = ((float) (valor - AD_POL))*escala;
#endif

#ifdef AIO
valor = ( (inb(AD0)  0x0FF) | ((inb(AD1)  0x00F)  8));  // Aquisicao da posicao
tensao = ((float) (valor - AD_POL))*escala;
#endif


 // Rotina para gerar a onda quadrada

if (contador  ONDA_QUADRADA2  contador = ONDA_QUADRADA)  // Gera um onda 
quadrada ou retangular?
  sinal = -1;
else if (contador  ONDA_QUADRADA) {
  sinal = 1;
  contador=0;
}
   contador++;


// Lei de controle

ref = PID.ref + PID.sw_amplitud*sinal;  // A referencia eh uma 

[rtl] Raceway/Gbit Ethernet from Linux

2000-06-26 Thread Mike Cravens


Anyone out there doing Raceway interface under Linux or specifically RTL?
On VME ( and mezzanine cards) or PCI/cPCI?
Hardware recommendations or known driver support?
Hope this isn't off-thread too far?
Regards,



Mike Cravens

--
 Alcatel USA Internet: [EMAIL PROTECTED]
 1000 Coit Road Plano, Texas 75075
  The opinions expressed are not those of DSC Communications, Inc 



 "Keep things as simple as possible, but no simpler". A. Einstein


begin:vcard 
n:cravens;mike
tel;home:(972) 423-9463
tel;work:(972) 477-7077
x-mozilla-html:TRUE
adr:;;1000 Coit Rd;Plano;Tx;75075;USA
version:2.1
email;internet:[EMAIL PROTECTED]
title:Senior Software Engineer
x-mozilla-cpt:;-10560
fn:[EMAIL PROTECTED]
end:vcard



[rtl] Real-time networking

2000-06-26 Thread Mike Cravens


Another question for a group with real-time insight:
If I want to stream packet data from a high bandwidth parallel interface
like Raceway coupled through hardware fifos onto gigabit ethernet,
possibly to be consumed by Unix workstations, then what could give
me optimum streaming:
(1) Running something in RTL at both ends
( 2) Something in RTL at the Raceway/ ehternet conversion end
(3) Something in RTL at the workstation consumer/ data processing/display
end.
Also, what are the design tradeoffs betweek shared RAMand
RTLFIFOS? My own cicular buffers in shared RAM?
Thanks for any insight as to how to approach or even quantify the relative
performance, boh best/worst case, and typical.
Regards,

Mike Cravens
--
 Alcatel USA Internet: [EMAIL PROTECTED]
 1000 Coit Road Plano, Texas 75075
  The opinions expressed are not those of DSC Communications, Inc 



 "Keep things as simple as possible, but no simpler". A. Einstein


begin:vcard 
n:cravens;mike
tel;home:(972) 423-9463
tel;work:(972) 477-7077
x-mozilla-html:TRUE
adr:;;1000 Coit Rd;Plano;Tx;75075;USA
version:2.1
email;internet:[EMAIL PROTECTED]
title:Senior Software Engineer
x-mozilla-cpt:;-10560
fn:[EMAIL PROTECTED]
end:vcard



[rtl] USING STI/CLI pporach for benchmarking

2000-06-26 Thread Mike Cravens


This may be a sensitive issue, what with S/Wpatents and the
like, but what public information is there about using the RTL approach
to get precise performance measurements of either soft real time or hard
real time performance.

This could be in conjunction with a code instrumentation approach or
without it.
Any interesting performance measuring example code out there?
Trace code? Code coverage?
Regards,

Mike Cravens
--
 Alcatel USA Internet: [EMAIL PROTECTED]
 1000 Coit Road Plano, Texas 75075
  The opinions expressed are not those of DSC Communications, Inc 



 "Keep things as simple as possible, but no simpler". A. Einstein


begin:vcard 
n:cravens;mike
tel;home:(972) 423-9463
tel;work:(972) 477-7077
x-mozilla-html:TRUE
adr:;;1000 Coit Rd;Plano;Tx;75075;USA
version:2.1
email;internet:[EMAIL PROTECTED]
title:Senior Software Engineer
x-mozilla-cpt:;-10560
fn:[EMAIL PROTECTED]
end:vcard



Re: [rtl] Soft Real Time

2000-06-26 Thread Mike Cravens


Could you encourage more participation in the porting process by
others interested in keeping the source open?
If you close the source, I might as well use VxWorks.
Many people are just arriving at the real-time and embedded party.
Getting people to contribute commits them in ways beyond money and economics.
There are some things that die if you hold them too tightly.
Our biggest concern where I work is that our vendors of "software" --
usually meaning services -- will not be able to keep up with our demands
and we will have to do work here on infrastructure that we would rather
someone else provided.
Having source is a security blanket that we can pack our own parachute
, if need be, but we would rather focus on our areas of expertise
as a corporation, and get help in other areas.
We have several time " bought " software that we though included a specific
port or "Board Support Package", complete with development environments
and support contracts, only to be told that the BSP was not
a product, just an unsupported example, that the tool chain
was now obsolete, and we must change in mid project, and that
our support contract did not cover getting responses in finite time,
and that all our problems would be solved if we could suddenly sign a consulting
agreement.
You might want to get your investors to read "Under the Radar,
by Red Hat's Robert Young. The part where he was talking to Intel
money people about giving away software was both humorous and informative.

The project I current work on is an example of why having source is
important.
We needed a real-time data base package on embedded Linux node,
and started with one we have source to for Solaris on Sparc.
The port has involved changing some kernel parameters involving things
like shared memory, buffer queue depth, semaphores, etc.
In modifying these things, I was concerned about inducing inefficiency
or bugs.
Reading kernel source led me to see the implications of our changes
and the limits on them; I also found a latent kernel source
bug in how message related parameters are defined that would be catastrophic
in our case while not affecting users with short queue depths.
So I have avoided having my (legal) change break existing code,
and saved a full design cycle over just having header information,
etc.
Also, our project started on a closed X86 Unix which required
long cycle times through the vendor to change anything. We cannot
meet our schedules and go through that [extended] hoops that they
require to effect change.
So all our embedded nodes now run O/S's for which we have source.
Regards,

Mike


[EMAIL PROTECTED] wrote:
On Sun, Jun 25, 2000 at 10:49:11PM +0200, Bernhard
Kuhn wrote:
> [EMAIL PROTECTED] wrote:
> >
> > We have an experimental RTL V3 with an option to turn off Linux
> > on one PC. Measured latencies are very low -- but this is early
code.
> > If you are interested in testing please send email to me.
>
> Very interessting!
>
> Id like to have a look at it, because i intend to
> modify the kernel-scheduler in the following way
> (if i ever have enough time to do so :-) )
>
> o user-spaces processes, kernel-threads and linux-interrupts
> should be fixable to specific CPUs.
Ingo did Linux interrupts already for 2.3 x86. The others should
be easy.
BTW: We are under enormous pressure from potential funders who argue
that
we need to abandon open source entirely to keep Lineo from simply riding
us down. I expect RTAI in the future will have done PPC ports
before RTLinux and etc. I'm attempting to manouver around both this
problem
and funder demands. We will see.
> o Additionaly to the usual time-sharing "nice-value", a
> priority is assigned to user-space processes, resulting
> in somewhat i would call a "hierarchical priority encoded
> preemptiv time sharing scheduler" :-)
I have a solution to this, but [see above]
> This surely wouldnt apply to machine control systems, but
> is intended for multimedia (happy fragging!) ... i know
> that there are several other projects out there, that care
> especialy about the second point (red linux, qlinux),
> but AFAIK, nobody cares about the first one ...
RedLinux contains RTLinux 0.9 code, I don't know the others. But [see
above]
>
> BTW: how was you talk in San Jose?
Packed. Very interesting.
--
-
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 Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

--
 Alcatel USA Internet: [EMAIL PROTECTED]
 1000 Coit Road Plano, Texas 75075
  The opinions expressed are not those of DSC Communications, Inc 



 "Keep things as simple as possible, but no simpler". A. Einstein


begin:vcard 
n:cravens;mike
tel;home:(972) 423-9463
tel;work:(972) 

Re: [rtl] hrtime_t - int

2000-06-26 Thread Chris Hawks

---On Mon, Jun 26, 2000 at 09:22:44AM -0500, Cory Papenfuss wrote:
   I've (sorta) figured it out.  The int must first be cast as a long long
 or the multiplication will overflow, but when I tried putting a division in a
 rt-space function to return miliseconds since boot, I get 
 
 ./init.o: unresolved symbol __divdi3
 
 when I try to load up my init.o module.  Is the access of the longlong
 division
 forbidden within rt-space?

I ran into this problem a while back __divdi3 is in a library not
linked to the kernel. My solution for dividing a 54bit by a 32bit was to copy
/usr/src/linux/arch/i386/math-emu/div_small.S to my local dir and include
it in my module.

--re: Re: [rtl] hrtime_t - int

 Chris
#include stddisclaimer.h

Christopher R. Hawks
Software Engineer
Syscon Plantstar a
Division of Syscon International

[EMAIL PROTECTED]

Computers are like air-conditioners:
They stop working properly when you open windows.

Linux: The OS for people with an IQ over 98





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




[rtl] Weird compilation problem while including sys/io.h, who helps?

2000-06-26 Thread Bert Eding




I have gcc version 2.95.3 (shipped with mandrake 7.1),
when I try to compile a file which includes sys/io.h I get strange 
problems:


the c-code 
=
#include sys/io.h

void main(void)
{
 ;
}
=
g++ file.c

result:
In file included from file.c:
/usr/include/sys/io.h: In function "void outl(unsigned int, short unsigned 
int)":
/usr/include/sys/io.h:125:parse error before "::"

the piece of code in io.h:

122:extern inline void
123:outl(unsigned short value, unsigned short port)
124:{
125: __asm__ __volatile__ ("outl %0, %w1::"a" (value), 
"Nd" (port));
126:}
=

Can anybody tell me whats wrong, it is a standard include file?

Regards
Bert



[rtl] ANNOUNCE: RTiC-Lab/COMEDI interface

2000-06-26 Thread Edgar Hilton

Folks,

By popular demand, there is now an interface available that allows
RTiC-Lab to use all the drivers available for COMEDI.  This interface
has been graciously submitted by a
href="mailto:[EMAIL PROTECTED]"Jose Guilberto/a as a set of
RTiC-Lab "drivers".  The RTiC-Lab/COMEDI interface may be found in the
RTiC-Lab home site:

http://128.143.47.231/~efh4v/rtic-lab.html


-- Edgar
--
Edgar F. Hilton   email: [EMAIL PROTECTED]
office#: (804) 924-6233   fax#: (804) 982-2246
http://www.people.virginia.edu/~efh4v



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




Re: [rtl] Soft Real Time

2000-06-26 Thread yodaiken

On Mon, Jun 26, 2000 at 01:18:21PM -0500, Mike Cravens wrote:
 Could you encourage more participation in the porting  process by others
 interested in keeping the source open?
 
 If you close the source,  I might as well use VxWorks.

I am not closing the source. Please note that there are new GPL releases
of RTLinux on our web site nearly every week. We have a long
track record of delivering GPL code. Longer than anyone else in this
area, by some years.


 Many people are just arriving at the real-time and embedded party.
 
 Getting people to contribute commits them in ways beyond money and economics.
 
 There are some things that die if you hold them too tightly.


Contributed source and ports are great. Please send 'em.
What we've found is that most RTLinux users want to work on their
own apps.  RT kernel code is really specialized.
 If you look at the credits file sent with RTLinux, you will
see that there are some exceptions -- and I, for one, really appreciate them.
Tomasz, Jerry, and others have been critical. What I have rejected, 
and will continue to reject are changes that I think are technically
wrong, poorly done, or violate the base paradigm. An advantage of 
open source is that others who disagree are free to pursue their own
path. And if their ideas turn out to be good, we may even change our 
minds. A good example of how this works is the Linux fbcon component
that came after a conceptually similar but weak alternate method
was rejected.


 Having source is a security blanket that we can pack our own parachute ,  if
 need be,  but we would rather focus on our areas of expertise as a
 corporation,  and get help in other areas.

Of course. The commercial advantage of Linux/Open-Source is exactly
this: the balance of power shifts from the controlling closed source
vendor. Our customers have the advantage of being able to get support
from someone else, or do some work internally, or ...
This means we have to deliver or get replaced, and we don't mind that
bargain at all. However, because customers now have more power, they
have to be careful to think things through and decide on the implications
of choosing one vendor over another.  For example, paying a vendor
for a product delivered by Debian, while not putting any money back
into Debian may be a self-defeating strategy.  

 You might want to get your investors to read "Under the Radar,  by Red Hat's
 Robert Young.  The part where he was talking to Intel money people about giving
 away software was both humorous and informative.

When RedHat (or Heinz ketchup!)  posts a profit this will be
a more persuasive argument.

I don't want to 
overemphasize the difficulties. We are still having a good time here --
and we are breaking even. But even a calm, easygoing, person like myself
can lose his temper now and then.  And at ELC, I talked to a potential
investor who asked me precisely this question inspired by talks in which
Debian invented technology was being advertised as proprietary.  A
somewhat grumpy, low-sleep email followed. Don't read too much into it.


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




Re: [rtl] RTAI Vs RTLinux

2000-06-26 Thread Karim Yaghmour


[EMAIL PROTECTED] wrote:
 RTLinux is in the default PowerPC Linux kernel in development versions.

Given your previous record, I must admit that this is quite an
unfortunate event! I'm siding with Paolo on this one and hope
that most people reading this do take a very serious look at
RTAI. In my opinion, it far outdoes anything RTLinux can ever
do (plus, it doesn't need to employ Microsoft-like tricks to
innovate).

My 2$

===
 Karim Yaghmour
   [EMAIL PROTECTED]
  Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/




[rtl] realtime OS

2000-06-26 Thread hong



Dear all:
 
  I 
have two questions about the realtime OS.
1. Are there any articles 
talking about the comparison of the realtime OS in the markets?
  
2. How can we evaluate the performance of a realtime OS, such as the rtlinux? 

  

Thanks for your 
help!

Wish you have a nice 
day!--Meng-Hong 
ChenDeptartment of Electrical EngineeringTamKang UniversityE-mail : 
[EMAIL PROTECTED]Tel 
: 886-2-26215656 ext. 2102