Re: [Xenomai-core] Re: Comedi4xenomai

[Jan Kiszka]

Herman Bruyninckx wrote:
> On Wed, 2 Aug 2006, Alexis Berlemont wrote:
>>
>> comedi-over-rtdm is currently undergoing deep modifications. I am
>> trying to
>> redefine an architecture more suitable for RTDM. That implies I am
>> rewriting
>> a big chunk of the Comedi code and its drivers without commiting into
>> SVN.
>>
>> I thought it was a bad idea to commit broken code (It does not even
>> compile).
>> Tell me if I'm wrong.
> 
> You are right! But maybe it could be good to discuss your architecture on
> the xenomai mailinglist?

Ack. I would be interested in learning more details about the
differences between original comedi (which I still don't know well
enough) and your design. Will the user notice it? What will change for
comedi driver developers? How will the RTDM profile of comedi look like?

And I think that it could be helpful for such a discussion to update the
code in your branch - even if its not compiling.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Re: Comedi4xenomai (Was: Re: [Orocos-Dev] [Bug 115] [Project] Move device drivers to orocos-components)

[Herman Bruyninckx]

On Wed, 2 Aug 2006, Alexis Berlemont wrote:


This could change fast with e.g. comedi4xenomai in the pipeline...


Do you have more information about this?


[putting Alexis Berlemont in cc:, as he is probably the one who can
answer this question]
I haven't seen anything on the xenomai MLs lately.  AFAIS from
 there hasn't been a lot
of activity on the branch lately.



Sorry for answering so late, I was on holiday.

comedi-over-rtdm is currently undergoing deep modifications. I am trying to
redefine an architecture more suitable for RTDM. That implies I am rewriting
a big chunk of the Comedi code and its drivers without commiting into SVN.

I thought it was a bad idea to commit broken code (It does not even compile).
Tell me if I'm wrong.


You are right! But maybe it could be good to discuss your architecture on
the xenomai mailinglist?

Thanks for all your efforts!

Herman

--
  K.U.Leuven, Mechanical Eng.,  Mechatronics & Robotics Research Group
 Tel: +32 16 322480

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Re: Comedi4xenomai (Was: Re: [Orocos-Dev] [Bug 115] [Project] Move device drivers to orocos-components)

[Alexis Berlemont]

Hi,

> > > This could change fast with e.g. comedi4xenomai in the pipeline...
> >
> > Do you have more information about this?
>
> [putting Alexis Berlemont in cc:, as he is probably the one who can
> answer this question]
> I haven't seen anything on the xenomai MLs lately.  AFAIS from
>  there hasn't been a lot
> of activity on the branch lately.
>

Sorry for answering so late, I was on holiday.

comedi-over-rtdm is currently undergoing deep modifications. I am trying to 
redefine an architecture more suitable for RTDM. That implies I am rewriting 
a big chunk of the Comedi code and its drivers without commiting into SVN.

I thought it was a bad idea to commit broken code (It does not even compile). 
Tell me if I'm wrong.

This is one of the two reasons why you did not notice any change on the comedi 
branch in the SVN trunk the last two months.

The other reason is private, bought a little flat =>  moved out => moved in => 
working on the appartment => all this stuff took and is still taking a lot of 
my spare time ;)

Eventually, if anyone is interested in the new comedi4xeno architecture, I 
will try to commit a reduced version in two or three weeks. 

> I don't know if that means the comedi-over-rtdm code is already in a
> "usable" state as is?

The code available in the trunk is a proof of concept, it does not contain 
real drivers, you can just find test drivers.

Regards.

Alexis.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Re: [ANNOUNCE] RTDM driver for CAN devices

[Wolfgang Grandegger]

Bernhard Walle wrote:

Hi Wolfgang,

Wolfgang Grandegger <[EMAIL PROTECTED]> [2006-08-01]:

at "ftp://ftp.denx.de/pub/xenomai/rtcan"; you can find a first version of
RTCAN, an Open Source hard real-time protocol stack for CAN devices
based on BSD sockets. It is based on the SJA1000 socket-based CAN driver
for RTDM by Sebastian Smolorz (see CREDITS file).


Has this something to do with http://sourceforge.net/projects/rtcan/?
It seems no, so maybe it would be better to find another name for your
driver.


No, the project you mention seem not to be maintained for a long time 
now and I'm going to contact the author. Please regard the name as 
preliminary. We already thought of renaming it to RT-Socketcan.


Wolfgang.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Re: [ANNOUNCE] RTDM driver for CAN devices

[Bernhard Walle]

Hi Wolfgang,

Wolfgang Grandegger <[EMAIL PROTECTED]> [2006-08-01]:
> 
> at "ftp://ftp.denx.de/pub/xenomai/rtcan"; you can find a first version of
> RTCAN, an Open Source hard real-time protocol stack for CAN devices
> based on BSD sockets. It is based on the SJA1000 socket-based CAN driver
> for RTDM by Sebastian Smolorz (see CREDITS file).

Has this something to do with http://sourceforge.net/projects/rtcan/?
It seems no, so maybe it would be better to find another name for your
driver.


Regards,
  Bernhard
-- 
"The last good thing written in C was Franz Schubert's Symphony No. 9."
-- Werner Trobin


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] [ANNOUNCE] RTDM driver for CAN devices

[Wolfgang Grandegger]

Hello,

at "ftp://ftp.denx.de/pub/xenomai/rtcan"; you can find a first version of
RTCAN, an Open Source hard real-time protocol stack for CAN devices
based on BSD sockets. It is based on the SJA1000 socket-based CAN driver
for RTDM by Sebastian Smolorz (see CREDITS file).

Currently it consist of a RTDM driver patch for Xenomai and a tar
archive with the RTCAN utilities. I have attached the README for further
details. It would be nice if the RTCAN patch could be integrated into
Xenomai. As this driver is bigger and more complex than the other RTDM
drivers, it rises a few issues with RTDM driver integration and maintenance:

- Where to put a few utility or test programs
- Where to put miscellaneous files like README, CREDITS, etc.
- Where to discuss RTCAN related question.

For the moment, please report CAN related bugs, questions and comments
to the Socketcan mailing list "[EMAIL PROTECTED]" at
http://developer.berlios.de/projects/socketcan/

Wolfgang.


RTCAN is an Open Source hard real-time protocol stack for CAN devices
based on BSD sockets. This implementation is for RTDM, the Real-Time-
Driver-Model. Note that there is a similar variant being developed for
standard Linux using the Linux networking stack.


Status:
--

Note: this is a preliminary version of the RTCAN RTDM driver!

It is available for the following CAN controller and devices:

   SJA1000 ISA devices
   SJA1000 PEAK PCI card
   SJA1000 PEAK parallel port Dongle
   MSCAN for MPC5200 boards

Currently it consist of a RTDM driver patch for Xenomai and a tar 
archive with the RTCAN utilities:

   rtcan-xenomai-0.20.1.patch
   rtcan-utils-0.20.1.tar.bz2

Likely some internals will change sooner than later, e.g. it might be
integrated into Xenomai. Nevertheless, the API is already settled well
as a result of discussions on the "Socketcan" mailing list 
([EMAIL PROTECTED])


Installation:


This example installation is for the DENX "linuxppc_2_4_devel" tree
(Linux 2.4.25) using the ELDK (see http://www.denx.de). It works in a
similar way for other kernels and distributions including Linux 2.6.


o General part:

  - Download the Xenomai distribution from the SVN repository, apply 
the RTCAN patch and run "bootstrap":

$ svn co http://svn.gna.org/svn/xenomai/trunk xenomai
$ export XENO_ROOT=$PWD/xenomai
$ cd $XENO_ROOT
$ patch -p1 < /tmp/rtcan-xenomai-0.20.1.patch
$ scripts/bootstrap

The "bootstrap" is necessary to get "include/rtdm/rtcan.h" copied
to the installation directory with make install. Alternatively,
you can copy it by hand. 


o Kernel space part:

  - Please install the Xenomai kernel space part as described in the
README.INSTALL. The following variable should point to the Xenomai
patched kernel:

$ export KERNEL_ROOT=/home/wolf/test/linuxppc_2_4_devel-xenomai

  - Configure RTCAN as kernel modules as required by your hardware 
(and make sure that loadable module support is enabled):

$ cd $KERNEL_ROOT
$ export CROSS_COMPILE=ppc_82xx-
$ make menuconfig
... Select "Loadable module support  --->" 
[*] Enable loadable module support 
... Exit
... Select "Real-time sub-system --->"
   "Real-time drivers --->" 
 "CAN bus controller --->"
[M] RTCAN raw socket interface (NEW)
(1024) Size of receive ring buffers (must be 2^N) (NEW)
(4) Maximum number of devices (NEW)
(16) Maximum number of receive filters per device (NEW)
[M] MSCAN driver for MPC5200 (NEW)
[*] Enable CAN 1 (NEW)
[*] Enable CAN 2 (NEW)
(6600) Clock Frequency in Hz (NEW)
(I2C1/TMR01) Pin Configuration
 Philips SJA1000 CAN controller (NEW)
   Standard ISA devices
(4)   Maximum number of ISA devices (NEW)
   PEAK PCI cards
... Exit and save

Note: you can also statically link the MSCAN drivers into 
the kernel.


  - Make the Linux kernel and RTCAN modules and copy them to the root
filesystem:

$ make dep
$ make uImage
$ cp -p arch/ppc/boot/images/uImage /tftpboot/icecube/uImage-rtcan
$ make modules
$ export DESTDIR=/opt/eldk/ppc_82xx
$ make modules_install INSTALL_MOD_PATH=$DESTDIR
$ find $DESTDIR/lib/modules/2.4.25/kernel/drivers/xenomai/rtcan
.../rtcan
.../rtcan/xeno_rtcan.o
.../rtcan/mscan
.../rtcan/mscan/xeno_rtcan_mscan.o
.../rtcan/sja1000/xeno_rtcan_sja1000.o
.../rtcan/sja1000/xeno_rtcan_peak_pci.o
.../rtcan/sja1000/xeno_rtcan_isa.o


o User space part:

  - Please install the Xenomai user space part as described in the
README.INSTALL. You need the path to the Xenomai installation 
directory to make the RTCAN utilities.

  - Unpack the RTCAN utility distribution:

$ tar xjf rtcan-utils-0.20.1.tar.bz2
$ export RTCAN_ROOT $PWD/rtcan-utils-0.20.1

  - Make the RTCAN utilities and install them:

$ cd $RTCAN_ROOT
$ export XENO_INSTDIR=/opt/eldk/ppc_82xx/usr/xenomai
$ make
$ make install


Ru

[Xenomai-core] [RFC] tame the watchdog (was: Beginner's question / testsuite / latency)

[Jan Kiszka]

Philippe Gerum wrote:
>> Still, reinitializing X while the latency test runs causes
>> the latter to hang, albeit LOC is still flowing properly and the box
>> keeps going normally.
> 
> This one was due to the nucleus watchdog which triggered right after the
> graphic mode was fully initialized, due to the huge amount of
> unpreemptible time spent doing this; this caused the sampling task to be
> detected as a runaway thread. So the behaviour is ok, albeit a bit
> frightening at first.
> 

That reminds of the unfortunate characteristics of the 2.6 oom-killer:
unless you set your time-critical app's oom_adj to -17, you are never
really safe from being killed accidentally on low-mem scenarios.

What about introducing some mechanism to protect audited tasks against
the watchdog? A simple thread flag settable via existing APIs, ignored
if there is no watchdog compiled in?

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] [PATCH] detect conflict with INPUT_PCSPKR

[Philippe Gerum]

On Mon, 2006-07-31 at 19:29 +0200, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Gilles Chanteperdrix wrote:
>  > > Jan Kiszka wrote:
>  > >  > No problem, but only when combining with a
>  > >  > 
>  > >  > comment "Switch off CONFIG_INPUT_PCSPKR to use Xenomai" (or so)
>  > >  >   depends on !X86_TSC && X86 && INPUT_PCSPKR
>  > >  > 
>  > >  > Otherwise the user will be left alone here with a non-selectable 
> Xenomai
>  > >  > option...
>  > >  > 
>  > >  > This actually remind me of my suggestion some months ago to add 
> Kconfig
>  > >  > warnings for CONFIG_CPU_FREQ & friends. Might be a good chance to 
> catch
>  > >  > this all. Is scripts/Kconfig.frag the preferred place to add it?
>  > > 
>  > > 
>  > > Why not? Here is a second patch that follows your suggestions.
>  > 
>  > No objections! Looks good to me. But shouldn't we add APM as well?
> 
> With APM, as well as with warnings for 2.4.
> 

Ack. Applique directement stp.

A+

> plain text document attachment (xeno-kconfig-warnings.diff)
> Index: scripts/Kconfig.frag
> ===
> --- scripts/Kconfig.frag  (revision 1402)
> +++ scripts/Kconfig.frag  (working copy)
> @@ -1,7 +1,20 @@
>  
>  menu "Real-time sub-system"
>  
> +comment "WARNING! You enabled APM, CPU Frequency scaling or use of ACPI"
> + depends on APM || CPU_FREQ || ACPI_PROCESSOR
> +comment "processor C states as idle handler (ACPI 'processor' option)."
> + depends on APM || CPU_FREQ || ACPI_PROCESSOR
> +comment "These options are known to cause troubles with Xenomai."
> + depends on APM || CPU_FREQ || ACPI_PROCESSOR
> +
> +comment "NOTE: Xenomai conflicts with PC speaker support."
> + depends on !X86_TSC && X86 && INPUT_PCSPKR
> +comment "(menu Device Drivers/Input device support/Miscellaneous devices)"
> + depends on !X86_TSC && X86 && INPUT_PCSPKR
> +
>  config XENOMAI
> + depends on X86_TSC || !X86 || !INPUT_PCSPKR
>   bool "Xenomai"
>   default y
>  select IPIPE
> Index: ksrc/arch/i386/Config.in
> ===
> --- ksrc/arch/i386/Config.in  (revision 1402)
> +++ ksrc/arch/i386/Config.in  (working copy)
> @@ -1,6 +1,12 @@
>  mainmenu_option next_comment
>  comment 'Real-time sub-system'
>  
> +if [ "$CONFIG_APM" != "n" -o "$CONFIG_APM_CPU_IDLE" != "n" -o 
> "$CONFIG_APM_DISPLAY_BLANK" != "n" -o "$CONFIG_ACPI_PROCESSOR" != "n" ]; then
> +comment "WARNING! You enabled APM or use of ACPI processor C states as"
> +comment "idle handler (ACPI 'processor' option)."
> +comment "These options are known to cause troubles with Xenomai"
> +fi
> +
>  if [ "$CONFIG_IPIPE" = "n" ]; then
>  comment "Xenomai depends on Adeos interrupt pipeline"
>  else
> ___
> Xenomai-core mailing list
> Xenomai-core@gna.org
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core