Re: [Xenomai-help] Xenomai latency tests on MPC8xx

fabien wrote: > Here, there is some xenomai tests on a MPC855T, could you comment > these results please ? > Are they correct ? > > # cat cpuinfo > processor : 0 > cpu : 8xx > clock : 50MHz > bus clock : 50MHz > revision: 0.0 (pvr 0050 ) > bogomips

Re: [Xenomai-help] Xenomai latency tests on MPC8xx

fabien wrote: > Here, there is some xenomai tests on a MPC855T, could you comment > these results please ? > Are they correct ? > > # cat cpuinfo > processor : 0 > cpu : 8xx > clock : 50MHz > bus clock : 50MHz > revision: 0.0 (pvr 0050 ) > bogomips

Re: [Xenomai-help] Xenomai latency tests on MPC8xx

fabien wrote: > Hello, first thank for your advices Wolfgang. > > 2008/1/7, Wolfgang Grandegger <[EMAIL PROTECTED]>: >> fabien wrote: >>> Here, there is some xenomai tests on a MPC855T, could you comment >>> these results please ? >>> Are they corre

Re: [Xenomai-help] Error while porting xenomai to power pc 750Cxe based SBC

Hello, rakesh bk wrote: > Hello Everyone > > I am new to Xenomai , I have ported linux-2.6.14 to our custom board based >on IBM750Cxe Iam unable to boot my kernel cross compiled with > eldk-3.0 with >enabled xenomai support.If i remove xenomai and ipipe support the > kernel >boots

[Xenomai-help] gpioirqbench: measuring external interrupt latencies

Hello, I'm proud to announce "gpioirqbench", a benchmark tool to measure external interrupt latencies. It is derived from Jan's irqbench [1] for the PC. Instead of using the serial or parallel port, it uses GPIO pins on embedded systems. It measures the time between the generation of an interrupt

Re: [Xenomai-help] gpioirqbench: measuring external interrupt latencies

Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Hello, >> >> I'm proud to announce "gpioirqbench", a benchmark tool to measure >> external interrupt latencies. It is derived from Jan's irqbench [1] for >> the PC. Instead of using the seri

Re: [Xenomai-help] Wolfgang Grandeggers gpioirqbench

Hans Søndergaard (HSO) wrote: > The attachment **gpioirqbench-0.9.0.tar.bz2 > > is a bin file.** > > **Would it be possible to get the right zipped file?** In https://mail.gna.org/public/xenomai-help/2008-02/msg00193.htm

Re: [Xenomai-help] BF537-Stamp pushbutton interrupts

Andras Garzo wrote: > Hi all, > > I'm trying to handle the BF537-STAMP pushbutton interrupts with rtdm, but > my system hangs when calling rtdm_irq_request with the following message: > > BUG: failure at arch/blackfin/kernel/bfin_gpio.c:504/set_gpio_maska()! > Kernel panic - not syncing: BUG! >

Re: [Xenomai-help] gpioirqbench: measuring external interrupt latencies

Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Jan Kiszka wrote: >>> Wolfgang Grandegger wrote: >>>> Hello, >>>> >>>> I'm proud to announce "gpioirqbench", a benchmark tool to measure >>>> external interrupt laten

Re: [Xenomai-help] FW: xeno_can: socket buffer overflow for fd=0

Hi Urs, Urs.Eichholzer wrote: > Dear Xenomai Help > > > > The write to CAN is fast and have no problem... this can be performed > fast and even in microsecond resolution > > The read to CAN is working... but not fast enough as we expect it should > be reading the network... The Xenomai CAN

Re: [Xenomai-help] Shared IRQ issue with Xeno Peak PCI CAN driver

Klaas Gadeyne wrote: > Hi, > > we're having a problem finding a non-shared IRQ for a PEAK systems can > board in a particular industrial SBC with PCI backplane [*]. > Loading the xeno_can_peak_pci driver fails due to a "so-called" IRQ > conflict. (see below) > > However, it seems the IRQ (12) is

Re: [Xenomai-help] Shared IRQ issue with Xeno Peak PCI CAN driver

Klaas Gadeyne wrote: > On Wed, 5 Mar 2008, Wolfgang Grandegger wrote: >> Klaas Gadeyne wrote: >>> Hi, >>> >>> we're having a problem finding a non-shared IRQ for a PEAK systems can >>> board in a particular industrial SBC with PCI backplane [*].

Re: [Xenomai-help] Shared IRQ issue with Xeno Peak PCI CAN driver

Jan Kiszka wrote: > Klaas Gadeyne wrote: >> --- rtcan_sja1000.c (revision 3533) >> +++ rtcan_sja1000.c (working copy) >> @@ -765,7 +765,7 @@ >> if (ret) { >> printk(KERN_ERR "ERROR %d: IRQ %d is %s!\n", >> ret, chip->irq_num, ret == -EBUSY ? >> -

Re: [Xenomai-help] problem with trivial-periodic.c example

Thomas Häberle wrote: > Hello! > > I am running Xenomai 2.3.5 on my MPC5200S on a STK52xx with a Linux > 2.4.25-DENX kernel (cross-compiling to the target). > > When I try to compile the "trivial-periodic.c" example with > >>> $ ppc_6xx-gcc SimpleTask.c -I $XENOINSTALL/include -L > $XENOINSTAL

Re: [Xenomai-help] CAN Probleme

Hi Urs, Urs Eichholzer wrote: > Hello > > We are just start to use the setup... > We try to read parameters from a device true the CAN. From some parameters we > get proper replay and with other parameters we get the following message: > rtcan0: btr0=0x05 btr1=0x4f > rtcan0: btr0=0x0a btr1=0x6f >

Re: [Xenomai-help] CAN

ng the baudrate? Ah, I see. Does the attached patch help? Wolfgang. > Thank's > > Urs > > From: Wolfgang Grandegger [EMAIL PROTECTED] > Sent: Wednesday, April 09, 2008 12:19 AM > To: Urs Eichholzer > Cc: xenomai-help@gna.org > Subject: Re: [Xenomai-help] CAN

Re: [Xenomai-help] Handling interrupt - jitter

Gilles Chanteperdrix wrote: > On Fri, Apr 18, 2008 at 4:33 PM, Bosko Radivojevic > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I'm having (from my perspective) too big jitter on handling >> interrupts. System is: ARM9, AT91SAM9260, Kernel 2.6.20.21, Adeos >> 1.8-03, Xenomai-2.4.2, interrupt is gener

Re: [Xenomai-help] migrate code from xenomai-2.3.0 to xenomai-2.3.4

recommand to update to 2.3.5., at lreast > >> The problem disapeared when we not changed the baudrate (we try to >> scan the bus..). What shoult be the time between changing the >> baudrate? > > Ah, I see. Does the attached patch help? I'm still curious, did the patch

Re: [Xenomai-help] Current state of RTDM-native?

M. Koehrer wrote: > Hi everybody, > > by reading the homepage of http://www.osadl.org I was (again) led to the > RTDM-native project which > has as target to provide an RTDM port for standard Linux (using the RT > Preempt Patch). > Looking at the GNA page http://svn.gna.org/svn/xenomai/branches/

Re: [Xenomai-help] Current state of RTDM-native?

M. Koehrer wrote: > Hello Wolfgang, > >> I do not know of any activities, but it should not be a big effort to >> get RTnet ported over RTDM-native. As I see it, mainly the build system >> of RTnet needs adaption. >> > thanks for your response. That sounds very good. > I can remember, that a long

Re: [Xenomai-help] [Socketcan-users] RTCAN & RT-Socket CAN

Breno wrote: > Wolfgang Grandegger wrote: >> Breno wrote: >> >>> Wolfgang Grandegger wrote: >>> >>>> Breno wrote: >>>> >>>> >>>>> Wolfgang Grandegger wrote: >>>>> &g

Re: [Xenomai-help] POSIX API

Breno Carneiro Pinheiro wrote: > Hi all, I wanna some help with my application. I'm learning about > Xenomai POSIX and Native API. I wonder know what is wrong with my code > below because both don't worked out: > > POSIX: > > #include > > #include > #include > > #include > > static pthread

Re: [Xenomai-help] [Socketcan-users] RT - Socketcan

Hi Breno, first I moved this thread to the Xenomai-Help ML, because it's off-topic on the Socket-CAN ML. Only questions related to the Socket-CAN API or Linux Socket-CAN implementation should be send there. Wolfgang Grandegger wrote: > Breno wrote: >> Wolfgang Grandegger wrote: &

Re: [Xenomai-help] [Socketcan-users] RT - Socketcan

[EMAIL PROTECTED] wrote: >> Breno wrote: >>> Wolfgang Grandegger wrote: >>>> Breno wrote: >>>> >>>>> Wolfgang Grandegger wrote: >>>>> >>>>>> Breno wrote: >>>>>> >>>>>> >

Re: [Xenomai-help] [Socketcan-users] RT - Socketcan

Wolfgang Grandegger wrote: > [EMAIL PROTECTED] wrote: >>> Breno wrote: >>>> Wolfgang Grandegger wrote: >>>>> Breno wrote: >>>>> >>>>>> Wolfgang Grandegger wrote: >>>>>> >>>>>>> Breno

Re: [Xenomai-help] [Socketcan-users] RT - Socketcan

Breno wrote: > Wolfgang Grandegger wrote: >> Wolfgang Grandegger wrote: >> >>> [EMAIL PROTECTED] wrote: >>> >>>>> Breno wrote: >>>>> >>>>>> Wolfgang Grandegger wrote: >>>>>&

Re: [Xenomai-help] [Socketcan-users] RT - Socketcan

Breno wrote: > Wolfgang Grandegger wrote: >> Breno wrote: >> >>> Wolfgang Grandegger wrote: >>> >>>> Wolfgang Grandegger wrote: >>>> >>>>> [EMAIL PROTECTED] wrote: >>>>>

Re: [Xenomai-help] General questions

Hi Urs, Urs.Eichholzer wrote: > Hi all, > > > > We have some general questions > > > > Our setup is: > > Hardware MPC5200B on Microsys MPX5200 > > Linux version: 2.6.19 > > Adeos Patch: Compatible with this Linux > > Xenomai version: 2.3.0 You should definitely update to 2.3.5 to bene

Re: [Xenomai-help] [Socketcan-users] RT - Socketcan

Breno wrote: > Wolfgang Grandegger wrote: >> Breno wrote: >> >>> Wolfgang Grandegger wrote: >>> >>>> Breno wrote: >>>> >>>> >>>>> Wolfgang Grandegger wrote: >>>>> >>>&g

Re: [Xenomai-help] still verification problems

Joachim Meyer wrote: > Hi > > I still have problems with 2 tests of the testsuite: > irqloop doesn't seem to work: > - > bash-3.00# irqbench/irqloop > Test mode:user-space task > Port type:serial > Port address: 0x3f8 > Port IRQ: 4 > > Received IRQs

Re: [Xenomai-help] Help rtcan and MCP5200...

quinty quinty wrote: > Hello, > > I have a MPX5200G develop board and I use xenomai to test real time task. > My problem is that I do not know how to configurate RT-Can driver in > kernel options. > > == > *U-Boot 1.3.0 (Feb 13 2008 - > 10:14:17)

Re: [Xenomai-help] Hello, doubts with RT-CAN

quinty wrote: > Hello, > > I am testing RT-CAN with MPC5200 and linux 2.6.23.14 > , xenomai 2.4.2. > Well I have some doubts: > 1.- In kernel configuration, there is a parameter to change lenght of RX > CAN buffer, 1024 by default. > What units???, 1024 bytes,

Re: [Xenomai-help] Hello, doubts with RT-CAN

quinty wrote: > > > 2008/6/17 Wolfgang Grandegger <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>: > > quinty wrote: > > Hello, > > I am testing RT-CAN with MPC5200 and linux 2.6.23.14 > <http://2.6.23.14>

Re: [Xenomai-help] periodic task

Breno Carneiro Pinheiro wrote: > Hi all, I'd like to see any good application using periodic tasks and > native Xenomai skin. does anyone have it? http://www.xenomai.org/documentation/trunk/html/api/index.html Wolfgang. ___ Xenomai-help mailing list

Re: [Xenomai-help] compiling probs

Axel Beierlein wrote: > Hello, > > when i try to compile the module examples from the xenomai source > directory i get many like this > > In file included from > /home/xx/linuxppc_2_4_25/include/asm/xenomai/hal.h:50, > from > /home/xx/linuxppc_2_4_25/include/asm-generic/x

Re: [Xenomai-help] compiling probs

[EMAIL PROTECTED] wrote: > - original Nachricht > > Betreff: Re: [Xenomai-help] compiling probs > Gesendet: Di 24 Jun 2008 13:12:26 CEST > Von: "Wolfgang Grandegger"<[EMAIL PROTECTED]> > >> Axel Beierlein wrote: >>> Hello, >>&

Re: [Xenomai-help] compiling probs

Axel Beierlein wrote: > Am 25.06.2008, 08:33 Uhr, schrieb Wolfgang Grandegger <[EMAIL PROTECTED]>: > >> [EMAIL PROTECTED] wrote: >>> - original Nachricht >>> Betreff: Re: [Xenomai-help] compiling probs >>> Gesendet: Di 24 Jun 2008 13:12:

Re: [Xenomai-help] latency in kernel mode

Joachim Meyer wrote: > Sorry, for my late answer. > > I enabled the timerbench module, and installed it with the other modules (IRQ > Benchmark and Context Switch). > The Switchtest test works, so I think the modules are correct installed and > the tests are able to load them. > Does this mean t

[Xenomai-help] Thread policy and priority in secondary mode

Hello, when a Xenomai POSIX thread switches to secondary mode, how can I define the policy and priority under which it should run under the Linux scheduler, especially, with SCHED_FIFO. The Xenomai POSIX API function pthread_setschedparam() described in http://www.xenomai.org/documentation/tru

Re: [Xenomai-help] Thread policy and priority in secondary mode

[EMAIL PROTECTED] wrote: __real_pthread_setschedparam(). Note: this will propagate the priority to the underlying Xenomai thread as well. >>> Does this mean that the Xenomai thread will run with the new (Linux) >>> priority when it returns to primary mode ? >> Yes. However, the prop

Re: [Xenomai-help] Xenomai kernel user-space problem running testsuite

Michael Galea wrote: > I'm just starting with xenomai and am having troubles getting xenomai > user space to talk to my kernel. > > I build the kernel and user-space xenomai code and try to run `latency` > from the test suite and get > mpc8360mds:# /usr/local/xenomai/bin/latency > Xenomai: incom

[Xenomai-help] RT pipe communication between two real-time tasks

Hello, I wonder if it's possible to use the RT pipe to exchange messages between two real-time task (in primary mode). The existence of the undocumented function rt_pipe_bind() makes me think so. http://www.rts.uni-hannover.de/xenomai/lxr/source/include/native/pipe.h?v=SVN-2.4.x#163 Wolfgang.

[Xenomai-help] Oops with ifconfig on Sequioa AMCC 440EPX board

Hello, I get the following Oops with a Xenomai patch kernel when configuring the EEPRO100 on the PCI slot: -bash-3.2# ifconfig eth2 172.16.0.20 [ cut here ] Badness at c0025db0 [verbose debug info unavailable] NIP: c0025db0 LR: c01b5658 CTR: c0190738 REGS: cfaa9d20 TRAP:

Re: [Xenomai-help] Oops with ifconfig on Sequioa AMCC 440EPX board

Wolfgang Grandegger wrote: > Hello, > > I get the following Oops with a Xenomai patch kernel when configuring > the EEPRO100 on the PCI slot: > > -bash-3.2# ifconfig eth2 172.16.0.20 > [ cut here ] > Badness at c0025db0 [verbose debug info unavail

Re: [Xenomai-help] Interrupt latency questions

Hello, Antonio Del Cinque wrote: > Hi, > sorry, I needed time to implement your suggestions, but finally I got > some results. I checked for cache related issues, and found that latency > is highly related to cache misses. > > I found the way to disable the instruction cache (the e300 powerpc cor

Re: [Xenomai-help] pthread_[set|get]specific()

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Hello, >> >> can pthread_[set|get]specifi()c be used safely in user space real-time >> tasks. Or does it result in a switch to secondary mode? > > I would expect pthread_getspecific to be safe on all pl

[Xenomai-help] pthread_[set|get]specific()

Hello, can pthread_[set|get]specifi()c be used safely in user space real-time tasks. Or does it result in a switch to secondary mode? Wolfgang. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] Reducing Kernel Mode Interrupt Latency

Henry Bausley wrote: > Is there any way the kernel mode interrupt handling maximum times can be > decreased. I very much need to reduce my kernel mode interrupt > latencies. I know my hardware is capable of better performance based > upon measurements done with RT Linux. Below is our timing comp

[Xenomai-help] Using Xenomai in early boot phase.

Hello, I want to use a Xenomai task overtaking the duties of a watchdog running under Linux as soon as the Xenomai layer is available during boot up. Is there a function or variable I could inspect? With 2.3.x, I called rtdm_init_task() until it returned without error but with 2.4.x it results i

Re: [Xenomai-help] Using Xenomai in early boot phase.

Philippe Gerum wrote: > Wolfgang Grandegger wrote: >> Philippe Gerum wrote: >>> Wolfgang Grandegger wrote: >>>> Wolfgang Grandegger wrote: >>>>> Philippe Gerum wrote: >>>>>> Wolfgang Grandegger wrote: >>>>>>> Hel

Re: [Xenomai-help] Using Xenomai in early boot phase.

Philippe Gerum wrote: > Wolfgang Grandegger wrote: >> Wolfgang Grandegger wrote: >>> Philippe Gerum wrote: >>>> Wolfgang Grandegger wrote: >>>>> Hello, >>>>> >>>>> I want to use a Xenomai task overtaking the duties of a w

Re: [Xenomai-help] Using Xenomai in early boot phase.

Philippe Gerum wrote: > Wolfgang Grandegger wrote: >> Hello, >> >> I want to use a Xenomai task overtaking the duties of a watchdog running >> under Linux as soon as the Xenomai layer is available during boot up. Is >> there a function or variable I co

Re: [Xenomai-help] Using Xenomai in early boot phase.

Wolfgang Grandegger wrote: > Philippe Gerum wrote: >> Wolfgang Grandegger wrote: >>> Hello, >>> >>> I want to use a Xenomai task overtaking the duties of a watchdog running >>> under Linux as soon as the Xenomai layer is available during boot up.

Re: [Xenomai-help] Using Xenomai in early boot phase.

Philippe Gerum wrote: > Wolfgang Grandegger wrote: >> Philippe Gerum wrote: >>> Wolfgang Grandegger wrote: >>>> Philippe Gerum wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Wolfgang Grandegger wrote: >>>>&g

Re: [Xenomai-help] Using Xenomai in early boot phase.

Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Philippe Gerum wrote: >>> Wolfgang Grandegger wrote: >>>> Philippe Gerum wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Philippe Gerum wrote: >>>>>>> Wolfgang

Re: [Xenomai-help] Mode switch when using RT heap on ARM

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Hello, >> >> I realized that accessing memory allocated with rt_heap_alloc() causes >> mode switches on ARM i.mx31. The attached patch provides a demo program >> to demonstrate the problem, which

[Xenomai-help] Mode switch when using RT heap on ARM

Hello, I realized that accessing memory allocated with rt_heap_alloc() causes mode switches on ARM i.mx31. The attached patch provides a demo program to demonstrate the problem, which actually does *not* show up on my PowerPC TQM5200 board. Wolfgang. --- examples/native/Makefile |4 - exampl

Re: [Xenomai-help] Mode switch when using RT heap on ARM

Wolfgang Grandegger wrote: > Gilles Chanteperdrix wrote: >> Wolfgang Grandegger wrote: >>> Hello, >>> >>> I realized that accessing memory allocated with rt_heap_alloc() causes >>> mode switches on ARM i.mx31. The attached patch provides a demo

Re: [Xenomai-help] Mode switch when using RT heap on ARM

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Hello, >>>> >>>> I realized that accessing memory allocated with rt_heap_alloc() causes >>>> mode switches

Re: [Xenomai-help] Mode switch when using RT heap on ARM

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Hello, >>>>>> >

Re: [Xenomai-help] Mode switch when using RT heap on ARM

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Gilles Chanteperdrix wrote: >>

Re: [Xenomai-help] Mode switch when using RT heap on ARM

Philippe Gerum wrote: > Wolfgang Grandegger wrote: >> Philippe Gerum wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Gilles Chanteperdrix wrote: >>>>>>>

Re: [Xenomai-help] Mode switch when using RT heap on ARM

Philippe Gerum wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Gilles Chanteperdrix wrote: >>

Re: [Xenomai-help] Mode switch when using RT heap on ARM

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Hello, >> >> I realized that accessing memory allocated with rt_heap_alloc() causes >> mode switches on ARM i.mx31. The attached patch provides a demo program >> to demonstrate the problem, which

Re: [Xenomai-help] Mode switch when using RT heap on ARM

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Hello, >>>> >>>> I realized that accessing memory allocated with rt_heap_alloc() causes >>>> mode switches

Re: [Xenomai-help] Mode switch when using RT heap on ARM

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Hello, >> >> I realized that accessing memory allocated with rt_heap_alloc() causes >> mode switches on ARM i.mx31. The attached patch provides a demo program >> to demonstrate the problem, which

Re: [Xenomai-help] Mode switch when using RT heap on ARM

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Hello, >>>> >>>> I realized that accessing memory allocated with rt_heap_alloc() causes >>>> mode switches

Re: [Xenomai-help] Icecube booting image problems

Marco Antônio Possamai wrote: > Greetings, everyone! > > > I'm having trouble concerning loading images to the Icecube (MPC5200 > Lite) board. > > The kernel version I'm using is the 2.6.25, and the U-boot version is 1.1.4. > > My directory containing the many files generated by the 'make > ARC

[Xenomai-help] pthread cancelation and scheduling magics

Hello, I have written the attached test program to cancel Xenomai POSIX threads. The "calc_task" does some busy work, which the higher priority task "ctrl_task" interrupts and aborts after some time. The program does not behave like I expect and it also behaves differently on my PowerPC and ARM te

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Hello, >> >> I have written the attached test program to cancel Xenomai POSIX >> threads. The "calc_task" does some busy work, which the higher priority >> task "ctrl_task" interrupt

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Gilles Chanteperdrix wrote: >> Wolfgang Grandegger wrote: >>> Hello, >>> >>> I have written the attached test program to cancel Xenomai POSIX >>> threads. The "calc_task" does some busy work, which the higher pr

Re: [Xenomai-help] pthread cancelation and scheduling magics

Hi Gilles, Gilles Chanteperdrix wrote: > Gilles Chanteperdrix wrote: Now, the question is, do you realistically plan to write an application which makes no syscall in its real-time loop? >>> Unlikely, but it may happen in case of programming errors. Anyhow, the >>> pthreads will run lega

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Hi Gilles, >> >> Gilles Chanteperdrix wrote: >>> Gilles Chanteperdrix wrote: >>>>>> Now, the question is, do you realistically plan to write an application >>>>>> which

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Hi Gilles, >>>> >>>> Gilles Chanteperdrix wrote: >>>>> Gilles Chanteperdrix wrote: >>>

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Gilles Chanteperdrix wrote: >>>> Wolfgang Grandegger wrote: >>>>> Hello, >>>>> >>>>> I have written the attached test program

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> For architectures with a high-resolution counter, >>> clock_gettime(CLOCK_MONOTONIC) is a xenomai service which uses the >>> counter and does not issue any s

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> For architectures with a high-resolution counter, >>>>> clock_gettime(CLOCK_MONO

Re: [Xenomai-help] pthread cancelation and scheduling magics

Philippe Gerum wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> For architectures with a high-resolution counter, >>>>> clock_gettime(CLOCK_MONOTONIC

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Hi Gilles, >>>> >>>> Gilles Chanteperdrix wrote: >>>>> Gilles Chanteperdrix wrote: >>>

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Running under gdb shows: >>>> >>>> Program received signal SIGSEGV, Segmentation fault. >>>>

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Running under gdb shows: >

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Running under gdb shows: >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x4885d4b0 (LWP 1127)] >> 0x0ff49100 in pthread_cancel () from /lib/libpthread.so.0 >&g

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Hi Gilles, >>>>>> >

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Gilles Chanteperdrix wrote: >

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Gilles Chanteperdrix wrote: >>

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: [...deletions...] >>> That is not expected. But this brings me back to my initial question, do >>> you have to work with a real world application that runs without issuing >>

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >> [...deletions...] >>>>> That is not expected. But this brings me back to my initial qu

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Gilles Chanteperdrix wrote: >>>&

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Gilles Chanteperdrix wrote: >>>&

Re: [Xenomai-help] pthread cancelation and scheduling magics

Hi Gilles, Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> I'm also puzzled why pthread_setschedparam() does make a mode switch >> to secondary mode (sometimes). > > That is normal. The glibc caches threads priority value, so we have to > call __real_pt

[Xenomai-help] Debugging RT threads with GDB on ARM/PowerPC

Hello, I understood that GDB can be used to debug Xenomai real-time applications but it seems not to work with my application on PowerPC or ARM. The applications looses determinism quickly, mainly because RT threads switch to secondary mode somehow. Have I missed something? Are there any known iss

Re: [Xenomai-help] Debugging RT threads with GDB on ARM/PowerPC

Philippe Gerum wrote: > Wolfgang Grandegger wrote: >> Hello, >> >> I understood that GDB can be used to debug Xenomai real-time >> applications but it seems not to work with my application on PowerPC or >> ARM. The applications looses determinism quickly, mainl

Re: [Xenomai-help] pthread cancelation and scheduling magics

Wolfgang Grandegger wrote: > Hi Gilles, > > Gilles Chanteperdrix wrote: >> Wolfgang Grandegger wrote: > >>> I'm also puzzled why pthread_setschedparam() does make a mode switch >>> to secondary mode (sometimes). >> That is normal. The glibc cache

Re: [Xenomai-help] pthread cancelation and scheduling magics

Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Wolfgang Grandegger wrote: >>> Hi Gilles, >>> >>> Gilles Chanteperdrix wrote: >>>> Wolfgang Grandegger wrote: >>>>> I'm also puzzled why pthread_setschedparam() does make a mode

Re: [Xenomai-help] CAN support for TS_CAN1 (Technologic Systems)

Charlton, John wrote: > I am testing CAN using a TS_CAN1 PC-104 card on an x86 Nano-7240. It appears > that none of the existing SJA1000 drivers support this hardware so I created > a new driver module from rtcan_isa.c and modified it to work with the TS_CAN1 > hardware. I am working with linu

Re: [Xenomai-help] pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Wolfgang Grandegger wrote: >>> Hi Gilles, >>> >>> Gilles Chanteperdrix wrote: >>>> Wolfgang Grandegger wrote: >>>>> I'm also puzzled why pthread_setschedparam() does

Re: [Xenomai-help] rtcanconfig rtcansend rtcanrecv

Charlton, John wrote: > I added a kernel module to the xenomai ksrc/drivers/xenomai/can/sja1000. It > builds and installs with make modules_install for linux-2.6.27.7 and > xenomai-2.4.6.1. I am using OpenEmbedded on an i686 NANO-7240 single board > computer. I load the kernal modules and sta

Re: [Xenomai-help] rtcanconfig rtcansend rtcanrecv

Charlton, John wrote: > Wolfgang, > > I added a reply to you with my reply to Sebastian Smoloz request for the > driver module source. Yes the transmitter shows TX-counter incremented by 1 > and the receiver never receives anything. The > /proc/xenomai/irq is: > > IRQ CPU0 > 0:

Re: [Xenomai-help] [Socketcan-users] rtcanconfig rtcansend rtcanrecv

Charlton, John wrote: > I am attaching an updated rtcan_tscan1.c driver for the TS_CAN1 PC-104 CAN > interface. I have only attempted to configure it for x86 so it is not > configured for ARM or any other architecture. > > I tried to build lincan-0.3.3 for linux-2.6.27.7 and so far have not > s

Re: [Xenomai-help] [Socketcan-users] rtcanconfig rtcansend rtcanrecv

Charlton, John wrote: > Wolfgang, > > Thank you for the help. I do have XENO_DRIVERS_CAN_DEBUG enabled and the > registers are: > > r...@oelinux-nano:~$ cat /proc/rtcan/rtcan1/registers > SJA1000 registers > 00: 00 00 0c 02 ff 00 03 1c 1a 00 00 00 00 60 00 00 > 10: 08 00 20 01 02 03 04 05 06 07

  1   2   3   4   >