SMM work-in-progress

J

Thread Starter

Jiri Baum

Hello,

I've checked the smm work-in-progress into the CVS, but it's not much use yet. As is, it should provide read-only access to the shared memory :)

Still, the interface shouldn't be changing much, so feel free to use smm.h


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Yes, I should do that, shouldn't I...

Shared Memory - Manager and Library
===================================

The shared memory (also known as the `global map') is the common data area for the linuxPLC. It contains all the inputs and outputs, and all internal coils that the logic engines wish to share with one another, or with other modules (HMI, debugging).

Each module has its own copy of the data in a `private map'. Any operations on the shared memory are first done on the private map and the global map is updated later. [1]

Access to the global map is protected by a semaphore, so that the updates are atomic. This allows linuxPLC to mimic the synchronous behaviour of traditional PLCs when there is only one logic engine.


The shared memory manager (smm/smm-mgr) is a small program that allocates and initializes the shared memory and does little else. At present there's no provision for shutdown, so it must be done manually using ipcrm(8).

The shared memory library (smm/smm.h and smm/smm_lib.o) is the only way to access the shared memory. At initialization, it allocates a private map and also a map mask, which will determine the read/write status of each point.

The library provides two access functions for the private map: plc_get() for reading and plc_set() for writing. There are no access restrictions on
these; a module may modify any point in its private map.

There is a combined function which updates the private map from the global map and the global map from the private map: plc_update(). This function uses the read/write status of each point and discards any modifications to read-only points in the private map. It is atomic.



Let me know if this makes sense... (I'll check it into the CVS, too.)


Jiri

[1] There could also be a function that discards the contents of the private map. Let me know if you want it.
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

I'm afraid it doesn't relate at all, or very little.

Some parts of Ron's code (eg distinguishing inputs and outputs) sound like a step backwards elegance-wise from the status quo in the discussion around end of January / mid-February.

Since it doesn't do any interprocess comms, I assume it'd require everything to be in one big monolithic program? (No multiprocessing?)

The part which parses an address may be useful, but I'd just as soon use free-form point names (the config has to list them all anyway).

I don't handle counters and timers, but then again neither does Ron.

Hmm, what's left; floats and integers, I guess, and reallocation.

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

I am not surprised that what I put up doesn't "relate". I wasn't too attentive to the conversations back in Jan/Feb.

As for IPC issues, I had envisioned a driver mechanism to deal with that. I had also envisioned the drivers running as fork's/clones/threads off of the main process. This stuff can also just as easily be a shared library (.so or .dll, OS dependant) so the monolithic bit doesn't hold too much water.

Regarding timers/counters. I see the same idea being used there, just using a larger allocation size (since a timer/counter will need more data stored).

Ron

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> I am not surprised that what I put up doesn't "relate". I wasn't too
> attentive to the conversations back in Jan/Feb.

I think once again we have the problem that several people try to do this part almost at once... At least this time there's actual code happening, rather than just volunteering :)


> As for IPC issues, I had envisioned a driver mechanism to deal with that.
> I had also envisioned the drivers running as fork's/clones/threads off of
> the main process.

A fork gives you a completely separate process, with its own memory space. I'm not sure how you intended the driver mechanism to work.

We could use threads - I've never used them before, so I don't know how easy/difficult they'd be.

More explanation please?

> This stuff can also just as easily be a shared library (.so or .dll, OS
> dependant) so the monolithic bit doesn't hold too much water.

Well, in linux you get per-process control, per-process memory protection etc. (Having a badly-written piece of code crash just itself rather than the whole PLC sounds attractive.)

It's also a lot easier to run two copies of a program (with different configs) than to make it reenterant.

Running up a (debugging) map-displayer and then taking it down again is also easier with separate processes. Sure, we could have the main process
spawn a new thread, and then take it down again, but I don't see any advantage of that over making use of what the kernel already provides.

> Regarding timers/counters. I see the same idea being used there, just
> using a larger allocation size (since a timer/counter will need more data
> stored).

Yes, but they do need some special things (especially timers), and those things will want hiding from the end-user.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

Regarding threads: They are quite easy to set up. By using the pthread library (included with just about every linux distro nowadays), a thread is simply set up as follows:


(void *) thread_routine (void)
{
blah blah blah
}

int main (void)
{
pthread_create (thread_routine, thread_flags);
}

This is the basics, with a LOT of detail simply not given. The basic idea is that a thread shares the memory space of the parent, so that any variable available to the parent is also available to the thread. For a better example
(that I have wrote), go to freshmeat.net, search for "dallas", grab the latest copy of my Dallas DS-1820 Sensor program. The "gdallas.c" program makes fairly heavy use of threads (serial comm running in a thread to allow GUI program to run being "blocked" by the comm routines).

The thread loads the data into the first element of a storage array, the main program manipulates the entire array.

Ron


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
[email protected] wrote:
> Regarding threads: They are quite easy to set up. By using the pthread library<

OK (yes, I do have the pthread library here).

> The basic idea is that a thread shares the memory space of the parent, so
> that any variable available to the parent is also available to the
> thread.

I'm not sure to what extent that is really an advantage. I would expect that it would be very error-prone...

With separate processes, the default for any variable is `private'. With threads, it is `shared, unprotected'.

> For a better example (that I have wrote), go to freshmeat.net, search for
> "dallas", grab the latest copy of my Dallas DS-1820 Sensor program. The
> "gdallas.c" program makes fairly heavy use of threads (serial comm
> running in a thread to allow GUI program to run being "blocked" by the
> comm routines).

OK, I'll have to go have a look.

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

> > Shared Memory - Manager and Library
> > ===================================
...
> > Let me know if this makes sense... (I'll check it into the CVS, too.)

Curt Wuollet:
> Makes sense, but not just yet.

Can you let me know in what way it doesn't make sense yet? I'd like to improve the explanation...


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
[email protected]:
> Hmmmm... Maybe I got the filename wrong.

First thing I checked - grep thread *

> I thought it was gdallas.c (GTK+ based). There is also a monitor.c
> program in there that does NOT have thread support (console based). I
> don't remember. It has been a while since I did anything with it.

The hardware it's talking about sounds interesting, though!


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

Except I was describing stuff that's - for the most part - already implemented (and in the CVS). The only things that are missing for pass 1 are the string->address translation and points wider than 1 bit.

The rest of the stuff - global map, private maps, semaphores, access functions, plc_update() - is implemented. Granted, it may need some
debugging :)


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

Curt Wuollet

> Oh, OK.
>
> Except I was describing stuff that's - for the most part - already
> implemented (and in the CVS). The only things that are missing for pass 1
> are the string->address translation and points wider than 1 bit.

OK Jiri, you're contributing code aimed at where we are at in the process and you want to support that process and that is a very hopeful sign. As promised, I will work with your code. Two things have to happen. Your code covers in one fell swoop many of the more complex bits of UNIX programming, I know why. Shmem is the fastest IPC available and the most flexible. It abstracts the
process of updating the map and hides the complexity of multiple access and means the using process can make a simple function call and not deal with the details. That is good design. I was going to write a couple pages of
bonehead C (tm.) for an example of how we'd interface to the map. That is good project management at this stage. We have to stop and explain your MM to the extent that we don't lose people again and then you'll have to work with me on the next step which is to sketch out a reasonably simple output process that interfaces to your MM. If we bury our readership, we have failed and will have to start over...again.

> The rest of the stuff - global map, private maps, semaphores, access
> functions, plc_update() - is implemented. Granted, it may need some
> debugging :)

and a lot more explaining. I'll try to have intelligent questions for Monday.
regards,
cww

One other note, Driver is an extremely inprecise term in software, I will try to use an appropriate qualifier like, kernel driver, char driver, etc. I have been using IO process to describe the stuff you and Dan were back and
forth about. Once we get folks up to speed on the MM, our next issue will be to clear that up.


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