More on shared memory and drivers

K

Thread Starter

Ken E.

Hello Guys,

Curt has been bringing up some interesting points about RT and shared memory. It also goes back to my original proposal. LXRT has seemed to clear up some of the issues of sharing resources between threads (i.e. you can have global memory amongst threads). And in that respect, I beleive that using LXRT for logic solve threads is great becasue you can probably switch between hard and soft real time with a recompile like they state.
Curt mentioned a good point that you may still want to have the raw IO drivers to reside in kernel modules and present an image through a shared memory. I also beleive this is much easier to do and you don't have to implement the "normal" linux methodology of accessing drivers (i.e. via /dev devices ... correct me if I am wrong, I admit to never writing a native linux device driver..)

There might be a catch with LXRT and making kernel function calls needed to use drivers. (In fact I think this is probably very *likely* ). After all, LXRT threads are really linux processes running in standard linux ram space but they are made non-preemptable through the RTAI kernel modules. So in this respect, my original proposal of having a IO system in kernel modules presenting IO images to shared memory is still valid.

As far as how to implement shared memory, RTAI and RT linux use the mbuff memory driver, so it is no longer necessary to mess around with LILO (not that it was difficult or problematic, I am sure, but it is now obsolete.) The way that the mbuff driver works is that the kernel module and the user space program make a call to the mbuff driver and pass it a string token so that the kernel module knows that you both want the same piece of memory. This function call returns a pointer to the base of the shared memory. I am about to start testing it here in the next several weeks (we are moving our entire facility in a couple of weeks, so it is a bit hectic around here now ... )

As a side question, what is the best way to locate a bunch of data variables to shared memory?? Obviously if the pointer to memory is
generated dynamically by the driver, the compiler isn't going to be able to assign the variables to this block of memory at compile time. My first
thought was to simply re-assign the pointers to my data structures to the memory area and build this up with an initialize function. I think this will work, but what if you want to do this for a lot of scattered data variables? Is there a methodology for coding this?

~Ken

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 
C

Curt Wuollet

"Ken Emmons, Jr." wrote:

> Curt has been bringing up some interesting points about RT and shared memory. It also goes back to my original proposal. LXRT has seemed to clear up some of the issues of sharing resources between threads (i.e. you can have global memory amongst threads). And in that respect, I beleive that using LXRT for logic solve threads is great becasue you can probably switch between hard and soft real time with a recompile like they state. Curt mentioned a good point that you may still want to have the raw IO drivers to reside in kernel modules and present an image through a shared memory. I also beleive this is much easier to do and you don't have to implement the "normal" linux methodology of accessing drivers (i.e. via /dev devices ... correct me if I am wrong, I admit to never writing a native linux device driver..)

Yes, all you need is the bottom end of a typical driver and direct hardware access makes that fairly simple as you don't need to copy to userspace. Sharing the map between all drivers eliminates a lot of buffering, etc. They literally simply read and write from mapped hardware to the map.

>
> There might be a catch with LXRT and making kernel function calls needed to use drivers. (In fact I think this is probably very *likely* ). After all, LXRT threads are really linux processes running in standard linux ram space but they are made non-preemptable through the RTAI kernel modules. So in this respect, my original proposal of having a IO system in kernel modules presenting IO images to shared memory is still valid.
>
> As far as how to implement shared memory, RTAI and RT linux use the mbuff memory driver, so it is no longer necessary to mess around with LILO (not that it was difficult or problematic, I am sure, but it is now obsolete.) The way that the mbuff driver works is that the kernel module and the user space program make a call to the mbuff driver and pass it a string token so that the kernel module knows that you both want the same piece of memory. This function call returns a pointer to the base of the shared memory. I am about to start testing it here in the next several weeks (we are moving our entire facility in a couple of weeks, so it is a bit hectic around here now ... )

I kinda like having hard addresses, but I'll look at the mbuff setup. I'm concerned with resources as I'm looking at embedded platforms. We would still need to access serial and networking drivers for remote IO.

> As a side question, what is the best way to locate a bunch of data variables to shared memory?? Obviously if the pointer to memory is generated dynamically by the driver, the compiler isn't going to be able to assign the variables to this block of memory at compile time. My first thought was to simply re-assign the pointers to my data structures to the memory area and build this up with an initialize function. I think this will work, but what if you want to do this for a lot of scattered data variables? Is there a methodology for coding this?

My thought was to map as much as possible as JBOR with a few for flags, etc. that way what they mean is up to the app. If you really want elegant you can use different structs on each side but that would be compiler dependent. If they are regular you can get to anything with a base and offset.

I am now going back to deep lurk mode to write more tester code.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top