[rtl] Re:
[EMAIL PROTECTED] wrote: Due to RTLinux v2 is not stable yet, should I use RTLinux v1.x or v2?? My app doesn't have to perform complex tasks, only: Access I/O ports and serial port Comunnicate processes with FIFO's Which problems can I have using version 1.x??? I had a simple servo-task running for the seven days of CeBIT99 along with Staroffice, Netscape, 20 Fli-Animations, 2 xquakes, mp3-decoder (x11amp), gimp, glquake and bfries on voodoo1 and a bunch more applications, running almost everything in parallel using fvwm95 and a KDE-session within a nested X-Server. You can imagine, that when about 1000 people (no exaggeration) per hour were bassing by in the "Linux Lane", i was not willing to show anything on Linux that would have been crashed :-) So i used RTL0.6 along with Kernel 2.0.33 - no Problems at all! Most "usual" people were absolutly astonished, that so many (user-)tasks can run in parallel on a standard AMD K6/300. The guys that also knew anything about "Realtime-System", even couldn't beleave, that the same machine is generating the timing critical signale for up to 12 RC-Servos at the same time. (http://www.linux-magazin.de/ausgabe/1998/11/Rtlinux/rtlinux2.html sorry, german language, only) Zentropix sold there CDs with 0.9J for a long time due to some "scheduler problems" in RTL1.2 - in deed: the RC-Servo timing generator had unusual jitters up to 30 microseonds. i didn't had stability problems, but i also didn't spend much time on evaluating 1.2, and i don't know anything about 1.3. At least, with RTL2.0 i have detected some minor problems, but that may be due to my special Dual-Celeron-Configuraton along with a Kernel-module for the 3D-acceleration of a Voodoo3-Card, combined with only few experiences with the new version :-) AFAIK RTL2.0 is also considered stable ... hope that helps Bernhard --- [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] SMP and RT-Linux.
Michel Doyon wrote: I am looking for any documentation and/or examples that could help me to design software that would run under rt-linux with an smp machine. RTLinux and RTAI are ready for SMP. I tried both and they seemed to work just fine. But i suggest fixing the rt-task to a specific CPU with RTAI, because the jitters are much higher then, when you allow tasks to jump around across CPUS. RTLinux doesn't has a cross-cpu scheduler, but AFAIK, when you don't tell the task which cpu to run on, then it's more or less randomly, where the task will be started. So, IMHO, in both RT-Extentions, it is wise to fix tasks to specific CPUs :-) Bernhard --- [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] RTEC-0.3: added software interrupts
RTEC-0.3 - a concurrent realtime task system
1. Changes to RTEC-0.2:
2. Introduction
3. API description
4. Download
5. Installation
1. Changes to RTEC-0.2:
===
o Timing Bugfix
o Added soft-interrupt support
o rearranged the core (rt_core.c)
o created a better understandable demo (rt_application.c)
o more convenient "API"
2. Introduction
===
RTEC is a try to port RTLinux to uClinux.
Actually, there is no priority task-scheduler,
but you can have up to 16 concurrent periodic
tasks (only limited by #define) running
at a desired periodizity. Every task has
it's own stack, currently limited to 16KB
(hardcoded). This is the basis for
a scheduler.
Additionaly, you can send an emulated interrupt
to the standard linux kernel. This is the
basis for a FIFO-handler (dev/rtf*).
Currently, the system is limited to MC68328.
3. API decription
=
There are only a view functions that are interessting
for the user:
RT-Task handling:
-
void rt_task_create(RTTASK *task,void (*code)(void),int add_to_list);
void rt_task_sleep(void);
void rt_start_concurrent_task_system(hrtime_t period);
void rt_switch_to_task(RTTASK *new_task);
RT-Interrupt handling:
--
int rt_request_irq(unsigned int irq, void (*handler)(void));
void rt_free_irq(unsigned int irq);
Soft-Interrupt handling:
void rt_pend_soft_irq(irq)
void rt_reset_soft_irq(irq)
Have a look at the Demo-Application to understand
for what these functions are used for:
/* ../linux/arch/m68knommu/platform/68328/rt_application.c */
#include asm/system.h
#include asm/MC68328.h
#include linux/rtl.h
#include linux/sched.h
#include asm/irq.h
unsigned long fb_data[160][5];
/* soft interrupt emulation - */
#define MY_SOFT_RT_IRQ_NUM 31
int my_soft_rt_irq_handler(int vec, struct pt_regs *fp) {
printk("soft irq occured\n");
rt_reset_soft_irq(MY_SOFT_RT_IRQ_NUM);
return 0;
};
/* rt-handler for pen */
void rt_pen_demo(void) {
/* just do something */
fb_data[20][2]--;
/* pen-irq doesn't seem to be resetable ? */
/* send software interrupt to linux kernel */
rt_pend_soft_irq(MY_SOFT_RT_IRQ_NUM);
};
/* - concurrent task system demo --- */
RTTASK rt_listed_task1,rt_listed_task2;
RTTASK rt_circular_task1,rt_circular_task2;
/* this two "listed" tasks will be
called every 2 ms automaticaly */
void rt_listed_task1_code(void) {
while(1) {
fb_data[5][0]--;
rt_task_sleep();
};
};
void rt_listed_task2_code(void) {
while(1) {
rt_switch_to_task(rt_circular_task1);
};
};
/* circular_task1 will be started by rt_listed_task2.
circular_task2 will be started by rt_circular_task1.
circular_task2 will go back to rtlinuxtask */
void rt_circular_task1_code(void) {
while(1) {
fb_data[5][2]++;
rt_switch_to_task(rt_circular_task2);
};
};
void rt_circular_task2_code(void) {
while(1) {
fb_data[5][4]-=5000;
rt_switch_to_task(rtlinuxtask);
};
};
/* -- init - */
void rt_init_app(void) {
/* set LCD-Display output area */
LSSA = fb_data;
/* request handler for pen-interrupt */
rt_request_irq(PEN_IRQ_NUM,rt_pen_demo);
rt_task_create(rt_listed_task1,rt_listed_task1_code,1);
rt_task_create(rt_listed_task2,rt_listed_task2_code,1);
rt_task_create(rt_circular_task1,rt_circular_task1_code,0);
rt_task_create(rt_circular_task2,rt_circular_task2_code,0);
request_irq(IRQ_MACHSPEC | MY_SOFT_RT_IRQ_NUM, my_soft_rt_irq_handler,
IRQ_FLG_LOCK, "my_irq", NULL);
/* start timer1 and request handler */
rt_start_concurrent_task_system(200); /* 2ms */
};
4. Download
===
This is a patch against uClinux-2.0.38.1pre1:
wget http://www.rcs.ei.tum.de/~kuhn/uclinux/uClinux-2.0.38.1pre1_rt-0.3.diff.gz
5. Installation
===
Just unpack a clean linux-2.0.38 and patch it with uClinux-2.0.38.1pre1
and then apply the patch above.
For a more detailed installation instruction, refer to
the readme-file of rtec-0.1:
wget http://www.rcs.ei.tum.de/~kuhn/uclinux/rtec-0.1.txt
--- [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 IS FREE
Paolo Mantegazza wrote: The part stating it is proprietary is FALSE. Some marketing people understand it like this: non-standard == proprietary That's why many people think that the RedmondOSes arn't propietary, because they think they are standard ... :-) However: it's bull***t anyway :-) cu Bernhard -- [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] the performance of linux run on MPC860
Kulwinder Atwal wrote: shaolin zhang wrote: some result is: Linux pSOS VxWorks for(;;) for local variable: 0.52 usec/times 23.81 usec/times 4.79 usec/times for(;;) for global variable: 0.48 usec/times 9.58 usec/times 3.99 usec/times while() for local variable: 0.57 usec/times 11.90 usec/times 5.78 usec/times while() for global variable: 0.445 usec/times 11.90 usec/times 3.97 usec/times Does not a lower time mean it runs faster? It sounds like linux is running faster than pSOS and VxWorks. At least, it is rather unclear what the meassured values want to say anyway: how do you messure the execution time of an endless loop? :-) Do you think this "Empty-Loop-Benchmarks" say anything usefull for a more complex application? I doupt, your main application is an endless loop without content (maybe, you posted the whole stuff in the linuxppc-mailinglist, but definitly not at the RTL-Mailinglist) BTW: RTLinux will not speed up the execution time of loops. This only depends on the compiler. RTLinux just reduces latenciesjitters and gives you guaranteed response times. Please, can you be a little more specific and tell us exactly how you did you performace tests including the code? Bernhard -- [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] Power-Up and shutdown
Vernon Van Steenkist wrote: 1) I need my device to be active 5 seconds after power-up. Can Linux come up that quickly? Depends on the BIOS ... but usualy, EmbeddedPCs can´t be up and running that fast. Linux itself can be downsized to operate within a few seconds. The AXIS-Web/ModemCam based on uClinux (m68knommu), for example, is fully operational within 5 seconds after supplying power. 2) I can not use the shutdown command to turn off the device. The device will be turned off when power is removed. Will I incur any file system corruption issues? mount the root-filesystem read-only and create a (umsdos)-partition for the data (reiserfs isn´t an option, as it usualy needs 30MB for the journal) Bernhard -- [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] RTLinux 2.0 tutorial/manual/documentation ?
Bart Vandewoestyne wrote: i have to be able to measure with an accuracy of 0.001 micro sec. You mean 1 nanosecond? Independent from the operating system, this is not managable with the parallel-port of a PC, since each read access will take about one microsecond: the read has to go the way from the CPU via Host-Bridge via PCI/ISA-Bridge to the SuperI/O-Chip. No chance at all to measure 1 nanosecond directly in a loop! Even when using the interrupt line of the parallel-port, the latencies caused by the intel-(mainboard)-architecture are much higher than a microsecond. You might connect an external counter, but up to 1 GHz, that´s realy not cheap! YOKE Another solution might be very funny: AFAIK, the time stamp counter is clocked with the speed of the CPU, for example 500MHz (2ns). You could directly use one of the unused LINT-lines of the processor, but you will still have some latencies (about 10ns, AFAIR). Also, it won´t be a simple task to design the necessary circuit ... /YOKE What exactly is the application, maybe there are other solutions ... -- [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] Threads or Tasks?
WORM wrote: I´ve been wondering during the last days, which are the differents between using threads and using tasks. Sorry for bothering you, but I can´t find the answer to this. The definition for both expression may vary, depending in which "computing-world" you are living in :-) So i will try this: In general, a "task" can be any kind of computing job (even an interrupt service routine), but with Linux, "task" usualy means "(user-space-)process". Every process has it´s own address-space and other processes can´t access the data except when using shared memory. Threads can (or with RTL do) run in the same address-space, sharing data. Besides, i would like to know the pros and cons of using each other. Processes are protected against each other, but this causes some overhead when switching tasks since the MMU has to be reconfigured and the TLB may has to be updated. With RTL, "real time tasks" have more in common with "threads" than with "processes" since they run in the same address space. (as like "kernel-threads" a running in the same address space as the kernel itself). Comments? Bernhard -- [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
Herman Bruyninckx wrote: We have a control problem in which we need a simple controller to run at preferably 30 000 Hz... So, keeping everything in cache is really needed... 30 KHz is ok, as long as some events can be missed or jitters in the range of the period are ok. Otherwise you might run into problems with latencies using Host-to-PCI bridges (but who knows?) ... So, IMHO, it is more wise to design a dedicated controller unit for your application ... Bernhard -- [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
[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! I´d 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. 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" :-) This surely wouldn´t 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 ... BTW: how was you talk in San Jose? Bernhard -- [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
[EMAIL PROTECTED] wrote: 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. hmm ... I am allways wondering why customers prefer wasting their money for licences instead paying for good services ... that´s that basic Idea with linux and with mechanisms like the web: any good line of code can be reproduced million times without any costs ... the good lines will sum up over time and that´s it! The earlier the pointy haired bosses get used to this, the earlier they will understand what´s going on: if any feature is realy interessting for any application, then how long will it take until somebody will reprogram the hidden code because he needs it or just because he is courious or doesn´t know how to spend his time in another way? :-) If the code is too special and only applies for a few customers, then nobody will care wether the code is available or not ... You know that all this rt-stuff is no rocket technology and can be performed by a small group of people (or even by a single person) within a few month ... That´s why Linux scares QNX and Lynx (Ah, sorry LynuxWorks): They are just jumping onto the open source train like many other companies to *protect* their invests: If somebody has published his code long befor you, then he´s the boss. It´s more like in the scientific world: publish or parish! Coming back to Lineo: although it´s a really strange company to me, they also recogniced the need to publish their stuff ... To sum it up: sell services, not products! Ok, this is a little bit more sophisticated, but as long as you can´t delete any line of open source code, time can´t be turned back! just my 0.02 euro ... Bernhard -- [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] FSCK and power up
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 Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] DGA graphic access
Arnaud Adell wrote: I would like to know if anyone know where I can find a documentation on the DGA (direct graphic access) to be able to use it to increase the speed of displaying sequences of images. IMHO, DGA is not what you are looking for. For many applications X is just fine, but you should run the application and the X-Server with o high priority (renice or SCHED_RR), or o one of the many kernel-scheduler enhanced linux-versions (RED-Linux, qlinux, linux/rt, SMART, KURT-Linux, MVistas RTS - are there more?) If your application has a hugh number of graphical operations then better learn OpenGL and get a Voodoo3 or nvidia-based card (TNT2,Geforc256,2GTS). Here, the libraries are directly linked into the application (but within protected memory space). So that the application directly accesses the accelerated functions of the hardware. OpenGL is designed for 3D, but can be used it for 2D as well. If you want to display something in hard real time (i dont see a case where this realy should be necessary) then you will have to use RTL or RATI and the framebuffer device, but this, at least, is slower because not accelerated. Bernhard -- [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] Draft of ``Real Time and Embedded HOWTO''
Hi Herman! Overall, you did a good Job, but i strongly disagree with some statements in chapter 3.2: The Linux kernel that supports a typical desktop computer is quickly more than 1 megabytes large. And that does not include the memory taken up by the Linux tools and the users' applications Hence, the Linux footprint is too large for most embedded systems. It also takes about a minute or so to boot, which is much too long for most embedded systems. And it expects at a hard disk to work with, and a power supply of more than 100 Watts for modern high-end CPUs, video cards and hard disks. 1) Please have a look at the MIPS-Port and uClinux and don´t just discribe why x86-Linux isn´t convenient for most embedded applications. (for example, a staticaly linked binary of a Tetris-clone for the uClinux/framebuffer has a size of just 11 KByte. A Minesweeper-Clone even fits into 8 KByte -- i just feel back in the times of C64 :-)) 2) Telekommunication switching systems, computer numeric machine control systems and similar process control systems are also embedded applications (having moderate real time constraints within few milliseconds and a huge market share, btw). Here, the recources are not a matter of fact but the number of features, the embedded os can deliver ootb. 3) uClinux just takes two seconds for booting (ok, network setup takes three more) Just my 0.02 Euro ... Bernhard BTW: Right now, there are only seven participants filled at http://www.thinkingnerds.com/projects/rtos-ws/participants.html I hardly can believe that there are not more people interessted in the linux real time workshop!? -- [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 and RTLinux
[EMAIL PROTECTED] wrote: Let's say I have N message buffers in a pool. What if there is no more free buffer? Then the design for your hard real time system was wrong :-) Bernhard -- [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] Draft of ``Real Time and Embedded HOWTO''
[EMAIL PROTECTED] wrote: x86 MiniRTL fits on a floppy and runs in 4Meg. Sure, but IMHO that was not was Herman is thinking of. I am sure, he is talking about stuff like engine control systems, heaters, fluid-controllers - stuff were usualy a bare C-Coded 8051 is quite enough. But today, evene these apps have to have a build in web-server with database and three tier architecture :-) Then, Linux just fits in perfectly ... 3) uClinux just takes two seconds for booting (ok, network setup takes three more) One of my favorite projects: http://www.acl.lanl.gov/linuxbios/ Yeah! Right, realy funny thing! There will once the day i will find the time to try it out :-) Bernhard -- [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] Example code for servo motors on parallel port...
Arne Linder schrieb: http://www.linux-magazin.de/ausgabe/1998/11/Rtlinux/rtlinux2.html As the article is based on RT-Linux v1.x, i have updated the software for 2.2 (the hardware and its description is still valid): ftp://ftp.linux-magazin.de/pub/devel/rtlinux/pwmdemos-19991221.tgz This package includes three examples: 1) the rc-servo control demo for up to 12 rc-servos attached to parport t_period=12-24 ms, t_on=1-2ms 2) PWM-Controller for 12 dc brush motors (without feedback) using subscheduler t_period=1ms, t_on=0-1ms 3) PCM-Sound for PC loadspeaker with two fold oversampling f_period=16KHz This demos have only a few lines of code and can easily by ported to RTAI if desired. Maybe that help Bernhard -- [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] RTLinux + UMLinux ???
Denis Karpov schrieb: is it possible to run RTLinux in User Mode Linux I didn´t tried it, but it´s rather unlikly that it will run: the UML-Kernel is patched in the areas of memory management, process scheduling and interrupt-handling in order to be able to run as usual application. I doubt that the rtl-patch could be applied without rejects to a kernel prepatched with UML. Even then, you have to redo the same work as for the kernel-scheduler etc. Beyond all this problems, the UML-RT-kernel wouldn´t be real-time capable any more. BTW: Everybody laughs about "printf-debugging" (means writting message-bytes to the printer port), but IMHO, for many hard-rt-applications(!) this is a quite convenient way to get programms bug-free. Other possibilites: R2D2 from Zentropics and LXRT from RTAI. Bernhard -- [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] Synchronisation point in Disney World?
Hi! I could imagine that some readers of this list(s) will be present at the real time linux workshop next monday. Coming from europe, i only got a flight for saturday. If there are more people arriving on the weekend, may be we could group up, not to spend the whole sunday each alone in the big disney world? :-) comments? Bernhard -- [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] OpenGL?
marco zoncu schrieb: Is it possible to use OpenGL libraries in a rtlinux task? Don't try this at home! :-) To be serious: IMHO it is not necessary to use rtlinux or rtai to do this kind of jobs, nor these hard real time implementations are intended for stuff like this ... What you need is "quality of service" (QoS), what i like to call "Multimedia Real Time Scheduling" :-) There are several ways for optaining this: Have a look at www.timesys.com. There you can get patches for a kernel, that guarantees i.e. 40ms in a period of 50ms to be assigned to the process handling the 3D stuff. This will allow absolutly smooth 3D rendering - as long as the scenario isn't to complex for the card to handle and thus the scene refresh rate doesn't fall below ~25 fps, of course. Instead of using the above mentioned Linux/RT (formerly called Linux resource kernel, "Linux/RK"), you could use the stuff from montavista. The kernel-patch itself is yartli (yet another real time linux implementation - that doesn't work very well, BTW), but there is a simple user space utility that can be used with an unmodified/usual kernel as well: "rt" just places itself into SCHED_FIFO - like David Olofson already explained - and then calls the given command that will run in the same scheduling space. This means, you can virtualy run any program in Posix-Realtime-space even when it isn't designed for doing so. For me, this works fine using an Nvidia 2GTS based card (with NVdriver) and several 3D-games :-) But beware: ensure that the X-Server and the Window-Manager are running with a higher priority as the 3D-program, because otherwise, the computer might easyly seem to be freezed: the machine is rather busy with redrawing the 3D-application, but doesn't get any new input from the X-Server/Window-Manager, because these processes are never scheduled any more) Also, having a bash running with the highest priority located on a serial terminal is basicaly a good idea when using the command "rt", to have a backdoor in case the X-Server loops :-) usage: rt [priority] program download: ftp://ftp.mvista.com/pub/Real-Time/utils/rt.c Of course, there are more real time linux implementations (qlinux/redlinux) out there which could do the job as well ... but ymmv. Bernhard -- [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/
Linux/RT availability, was: Re: [rtl] OpenGL?
Sven Garbade schrieb: Dont know if you mean this: http://www.cs.cmu.edu/~rajkumar/linux-rk.html#Download Exactly, but this is the stinky old version of Linux/RT formerly called Linux/RK. At least, half of the problem is solved. The correct path to version 1.1A is ftp://www.timesys.com/pub/linuxrt/ Version 1.2.1 might life in ftp://www.timesys.com/protected/ I'd like to try if version 1.2.1 works better with Athlon: version 1.1A only allowed a 10 ms resolution and a minimum period of 100ms, afair - too bad for gaming :-) Seems like Linux/RT doesn't recognice the Athlons APIC and makes a fallback to the legacy timer ... Bernhard -- [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] OpenGL?
David Olofson schrieb: Correctly, but we were discusing about visualization using OpenGL :-) Yes, but even some games and other heavy multimedia applications stream from disk and/or various forms of dynamic loading of world data. One reason to do that is to reduce loading times, so one can't just dismiss this with "but you can use more RAM". offtopic How about a 1 Gig RAM-Disk? :-) /offtopic [ 10 ms pause in rt-app ] The problem is probably that you're choking the rest of the system until you run into a dead end and *have* to sleep for some reason - and at that time, you're out for a good while... Oh, forgotten to tell: "a 10 ms pause in rt-app which is in SCHED_RR mode". means: this task will be allways scheduled next, if it desires the CPU - in this case: when the 10ms sleep is over. You may call it cooperative multitasking :-) QoS in it's simplest form basically means that you can have a certain amount of things done within a certain amount of time. Isn't that exactly the definition for hard real time? :-) IMHO QoS is this: The operating system guarantees the application some kinds of services. This might be a minimum network or harddisk bandwidth, or simply a minimum amount of task slots within a certain time - "CPU bandwidth", as linux/rt provides. Ok, this basicaly sound similar to your definition, but if the provided service is usefull for the application, that is something completly different! Example: within a 40 ms period, 30 ms are fixed to the 3D application. So if your 3D-Card is basicaly strong enough the generate 25 fps with 75% of the CPU computing power, then your application will run smooth enough for a Men Machine Interface. If you need a scene redraw rate bounded to the refresh rate of the screen (because some machinery has to bother with it) then this doesn't work, of course ... At least, you are right: to perform QoS, you need some kind of real time operating system, but for an MMI, it is IMHO sufficient to have 10-20 ms latency (depending on the application). But: For many people on this list, 10 ms might sounds like eternity :-) So IMHO, the "low latency patch enhanced soft real time capabilities of a linux operating system" (sounds like a marketing term) should be sufficient for QoS. Bernhard -- [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] Article about RTL/RTAI licence and patent situation
Hi everybody! Due to the fact that the industry gets more and more interessted in RT-Linux and RTAI, but also gets more and more distracted (because of the ongoing discussions), i intend to write a clearifing article about the licencing situation concerning both implementations. Downbelow, you can read the current status of my investigations ... Preface: Please, please, please don't discuss the following contribution on the mailing list, but send me your comments personaly to avoid damaging the mailing list server :-) If you realy intend to put your comment on the list, be aware that you have started the flame war, not me! Introduction Last week, the exhibition "Embedded Systems 2001" took place in Nuernberg/Germany. Along with a couple of Linux-Companies like Montavista and Lineo, there was a "Linux-Forum" organized by the management of the exhibition and its' media partner "Linux New Media AG", publisher of "Linux-Magazin", "LinuxUser" and their UK sister "Linux Magazine". In my function as staff writer for the german Linux-Magazin, i did some presentations in this Forum about realtime-linux in general and also mentioned RT-Linux and RTAI in detail. Afterwards there was some time for QA. Here it showed up that the auditorium (about 300 tech and management people on three days) had concerns about the recent license/patent issues. As i certainly couldn't give a 100% satisfactory answer, i'd like to do an article on that topic to clearify the situation. For this reason, i have noted my current thoughts below. Everybody is invited to send me a qualified comment. With your input, i will try to mix it together to a complete article ... One problem, of course, is that there are different laws for different countries. As i am not a expert on international legal stuff, i will mostly have a sane look on the techical side according to my profession as engineerer. Mixing GPLed and proprietary code - From what i have understood it by now, the main dicussion is about proprietary code mixed up with GPLed Code in some way: Just adding or modifying code in GPLed files will certainly result in a "derived work", means it has to be GPL. Creating a new Application from scratch might be not considered a "derived work", even when linked to GPLed code, because every single line of the new program was written by yourself. But you usualy have to include some GPLed C header files in order to be able to compile your application and link it to the GPLed binaries due to definitions and symbols. Also, the headers oftenly include macros that will result in assembler code mixed with the instructions of the application. As far as i understood, the LGPL was created to have a 100% clearification to this situation. But the problem does still exist for GPL: one can argue that including header files doesn't imply a derivation from a GPLed work. Especialy when you have recreated the necessary header files on you own in a "clean room". Usualy, it is hard to prove clean room conditions, but in our special case about programing pure posix complient applications, this could be (more or less easily) possible due to open standards. non-GPL RT-Linux Licence illegal? - But now, let's be nickpitting by saying a code derivations is implyed by using GPLed header files. This means that any RT-Linux application would be a derived work due to the fact that files like rtl.h, rtl_fifo.h and rtl_sched.h usual have to be included. Now, there is the situation that companies might like to write applications for rt-linux, but can't open the source codes (even if they like to so) due to the fact that their application incorporated licenced code from other companies. The way out is that the copyright holders of the headers files (here fsmlabs) are forced to have another license for these files in order to fit with proprietary code. (BTW: So far, RT-Linux is comparible to Qt: licensing is free of charge as long as you go the new "Open Source Way". Those who want (or have) to go the old way might (or in fact will) have to pay some fees according to the alternative non-GPL licence.) If you are agreed so far, then we are in big troubles! The RT-Linux header files include GPLed standard linux header files, rendering the RT-Linux headers a derived work from the standard linux kernel (not to mention the implementation of rtl_sched, rtl_time etc. which are also a derived work, then). Consequently, the RT-Linux header files can't be licenced under other conditions than GPL! Means: proprietary rt-applications can't be used along with RT-Linux at all! The only solution, again, is the clean room implementation of the necessary linux header files - a work virtualy impossible to be done ... For this reason, for example, proprietary binary only linux kernel drivers are always encapsulated in an "open source stub" (i.e. the nvidia GFX driver). Unfortnuatly this
[rtl] [Update] licences and patents
Hi everybody! First of all, thank you for your input ... makes things much clearer now! No legal actions prepared = Although there were some roumors and signs, i am very happy to tell you that neither Victor nor Paolo intend to do legal actions against each other: Victor Yodaiken: "[...] We are not planning any legal actions against anyone although we are being careful to get legal opinions. [...]" Paolo Mantegazza: "[...] I do not know what Yodaiken is doing but I'm not preparing any legal action. [...]" Additions/modifications to GPL in Linux Kernel == As Robert Schwebel already mentioned, there is an addenum/preface to the linux kernel licence file: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". [...] This statement only clearifies the use of user space programs, but not the usage of kernel space modules. Two years ago, L.T. wrote the following statement on the kernel mailing list. As none of the other copyright holders (the kernel developers) "dared" :-) to object to this statement, it can be taken as officialy granted: [...] I _allow_ binary-only modules. I allow them because I think that sometimes I cannot morally require people to make sources available to projects like AFS where those sources existed before Linux. [...] So, you can now argue that adding kernel space modules also "is merely considered normal use of the kernel" and thus "does *not* fall under the heading of 'derived'". For this reason, RTAI-modules can be distributed under LGPL and RT-Linux-modules under any licence. But the kernel-patch itself has to be GPL, because GPLed files are modified directly instead of creating new files that can be compiled as modules. And the Patent? === Concerning the software licences, the world looks fine, again. But there is still the patent left! It basicaly says "[...] use of the Patented Process is permitted, without fee or royalty, when used: A. By software licensed under the GPL [...]" Means, you will have to pay a patent licence fee to fsmlabs when using LGPLed RTAI in US. You don't have to pay a fee when using RTAI and/or RT-Linux in contries where US patents have no legal effects. Especialy in europe, where software patents are only allowed under very rare circumstances, the RT-Linux patent very likly wouldn't be granted, Victor pointed me to a patent granted in Germany that is similar to his patent. But as there are thousends of patents filled and granted illegaly, that doesn't mean very much: this patent can probably be deleted within a short amount of time. In US, the situation is different, and it might not be a good idea to do legal actions to delete the patent there, too: There are several similar patents around that could apply to Victors process. Means: things could be even worse when deleting the patent, because the other patent holders could do a much worse patent licence (i.e. you have to pay even when using GPLed code). At least, Victors patent mostly want's to protect the mechanism, so that no other company can claim their rights, but there are probably thousands of code fragments in the linux kernel that are covered by US patents - and nobody cares, because on one hand, it is not easy for the patent holders to find out whom to sue and on the other hand, a patent-suit can be very expensive and the result is oftenly uncertain. Also Victor patent forces developers to uphold free software standards: "get millions lines of code for free, but return your thousends lines of code you have created back to the community." On the other hand, propietary kernel modules mean "money is floating around" and fsmlabs just want to have some small pieces of the cake. Comments? Bernhard -- [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] Linux equivalents to pthread_make_periodic_np and pthread_suspend_np
David Schleef schrieb:
It can be duplicated using something similar to the attached
file.
select() is not bad, but you can't guarantee a stable
period (means a delay is propagated to the following
periods).
For this reason, i prefer pthread_cond_timedwait()
(see file attached).
Suspending can be done by using pthread_cond_wait().
Bernhard
// gcc -Wall -O2 -I/usr/src/rtai/include -D__KERNEL__ -DMODULE -c rt_thread.c
#include linux/module.h
#include linux/kernel.h
#include linux/version.h
#include asm/io.h
#include rtai.h
#include rtai_sched.h
#include rtai_pthread.h
#define PORT 0x378
pthread_t thread_data;
pthread_mutex_t wait_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t wait_cond = PTHREAD_COND_INITIALIZER;
volatile int kill=0;
int position=0;
MODULE_PARM(position,"i");
void add_ns(struct timespec *time,long ns) {
time-tv_nsec+=ns;
time-tv_sec += time-tv_nsec/(10LL);
time-tv_nsec = time-tv_nsec%(10LL);
};
void thread_code(int arg) {
struct timespec time;
clock_gettime(CLOCK_REALTIME,time);
while(!kill) {
outb(0xff,PORT);
add_ns(time,100+position);
pthread_mutex_lock(wait_mutex);
pthread_cond_timedwait(wait_cond,wait_mutex,time);
pthread_mutex_unlock(wait_mutex);
outb(0x00,PORT);
add_ns(time,1900-position);
pthread_mutex_lock(wait_mutex);
pthread_cond_timedwait(wait_cond,wait_mutex,time);
pthread_mutex_unlock(wait_mutex);
};
kill=2;
pthread_exit(0);
};
int init_module(void) {
printk("rt_task: started, position=%i\n",position);
rt_set_oneshot_mode();
start_rt_timer(0);
pthread_create(thread_data,0,(void*)thread_code,0);
return 0;
};
void cleanup_module(void) {
kill=1;
while(kill!=2);
pthread_cond_destroy(wait_cond);
pthread_mutex_destroy(wait_mutex);
stop_rt_timer();
printk("rt_task: stopped, position=%i\n",position);
};
Re: [Rtl]ATMEL 8051 8-bit + RTlinux
Robert Schwebel schrieb: On Sun, Oct 20, 2002 at 02:53:07PM +0200, Bernhard Kuhn wrote: If you want to stick to 8 Bit Controller: forget about Linux! Hmm, 8 bit controllers work quite fine for realtime applications with Linux. Just connect your favourite PIC, AVR or whatever to some generic io ports of your embedded Linux machine, install a standard non-realtime kernel, write your realtime program in assembler and you have jitter-less hard realtime behavour :-) I am not sure if this is what the original poster was thinking of. And even then: from experience, the process of getting a fully functional toolchain for 8 bit controllers working on a linux host can be quite a pain in the *** :-) Bernhard -- Bernhard Kuhn, Senior Software Engineer, Lineo Inc. (Where Open Meets Smart) ___ Rtl mailing list [EMAIL PROTECTED] http://www2.fsmlabs.com/mailman/listinfo.cgi/rtl
