Hi Guys,
I doing a research on Linux miniRTL embedded system that can be adapted to
various CPU (e.g Petium).
I was able to boot my miniRTL configuration from floppy disk but I am trying
to boot from Flash memory.
Can anyone teach me how to boot from Flash memory or direct me to where I
can ge
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
On Mon, 22 May 2000, Tim Liu wrote:
> On Fri, 19 May 2000, [BIG5] N-Liu/Tim (? ? INC) wrote:
> > Hi all . i want to get some information about the scheduling algorithm
> > about EDF or RM . is there some guy can help me ?
> > thanks in advance .
> >I'm not sure what you want to know?
> >Do you
The RTLinux version boots, but some of my devices do not work anymore,
I undestand that this has to do with the configuration of linux before
compilation.
How can I get the same comfiguration for the new build kernel as my original
one?
(The original was 2.2.15 of mandrake 7.1, not compiled by me)
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 manip
Hi Hofrat
Let's say I have a pendulum and I want to control. I have my algorithm whose
parameters may change to tune the system.
My idea was to have a small and simple program which would retrieve data
from a sensor and send it to a second program running in user-space, which
would calculate a
Hello,
I have an off-topic question that I think the people on
the list might be able to give me some hints or point
me to the right direction.
I have an interrupt service routine that interrupts
the operating system (currently Win 95) very often
(on the order of 2000 times per second). In addit
[EMAIL PROTECTED] wrote:
>
> On Thu, Jun 22, 2000 at 11:49:52AM +0100, Stuart Hughes wrote:
> > Victor Yodaiken wrote:
> > Hi Victor,
> >
> > pthread_kill may be standard, but AFAIK the signal you use here is not.
>
> That is because having Linux run as a thread is unique to RTLinux.
>
> Our ai
On Thu, Jun 22, 2000 at 11:49:52AM +0100, Stuart Hughes wrote:
> Victor Yodaiken wrote:
> >
> > On Tue, Jun 20, 2000 at 09:54:18AM -0700, Pascal Charest wrote:
> > > Hi,
> > >
> > > So, if I can't call Linux interrupt handler within an RTAI handler, can
> > > I use two independant handlers ; one
Sounds like a missing FWAIT instruction which is supposed to force the
program to wait until all previous fp operations (in this case probably the
saving and restoring of its state) are completed. Its very likely that the
next operation doesn't succeed because the initialization isn't complete an
On Thu, 22 Jun 2000, Stuart Hughes wrote:
> "Wayne E. Van Loon Sr." wrote:
> >
> > I am beginning a project where I would like to use a rtl process as
> > both a rt process and a driver for 4 ea. bt848 devices. I need 12
> > buffers of 172,800 bytes ea. and each buffer needs to be DMA capable
>
"Wayne E. Van Loon Sr." wrote:
>
> Hello rtl users.
> I am beginning a project where I would like to use a rtl process as both a rt
>process and a driver for 4 ea. bt848 devices. I need 12 buffers of 172,800 bytes ea.
>and each buffer needs to be DMA capable (consecutive physical addresses). I
Victor Yodaiken wrote:
>
> On Tue, Jun 20, 2000 at 09:54:18AM -0700, Pascal Charest wrote:
> > Hi,
> >
> > So, if I can't call Linux interrupt handler within an RTAI handler, can
> > I use two independant handlers ; one from RTAI and the other from Linux?
>
> It is trivial to call a Linux interr
Victor Yodaiken wrote:
>
> My opinion is that a multi-millisecond ISR is generally not a good idea.
Agreed. Aside from all the other issues, one thing should be clear as a
matter of general design philosophy: true interrupt handlers should be
kept brief.
Regards, Stuart.
-- [rtl] ---
To unsubs
Victor Yodaiken wrote:
>
> > I think you're correct (RTL & RTAI). IMHO it should be changed so there
> > is a way to pend a task to run only when an ISR has exited.
>
> That is exactly what pthread_kill WAKEUP is for.
> We have designed pthread_kill to be extremely fast and lightweight and to
>
We've been considering a backport of V3 to the 2.2 kernels but haven't done
anything about it yet. The changes wouldn't be minor for PPC and x86
wouldn't be a small undertaking so we're not doing it just yet. If there
turns out to be need for it (such as a not-so-stable 2.4), we may do it
sooner
16 matches
Mail list logo