For those offering help

M

Thread Starter

Mario de Sousa

Hello everybody,

It seems there are few people wanting to help out, so I'll give a few ideas of what could be useful to the project. Just pick what you prefer,
and send me an email for details if you think you require them.

Most of what we need are User interfaces to configure and program the LPCL, but I'll leave these out for now as it seems the people offering help are not very keen on these.

- documentation. Let me start this list re-stating what Jiri said:
We are too close to the code to figure out the difficulties
a new user will have. Curt will be doing this _very_ important
job, but the more, the better...

- what we really need most is a working IEC compiler. People working
on this will need knowledge on bison and flex. The compiler has
already been started, but it needs finishing.

- port Hugh Jack's plc5 emulator into a LPLC module. This is C++ code!

- clean up the synch_setup.c file. It includes several functions for
handling data structures that would be better off in the already
existing /lib/misc/ds_util.h file and a new ds_util.c file.

- continue with the generic io library to handle arrays of plc points,
and analogue values.

- include code in the gmm_setup.c file to allow the user to skip the
location of the configured plc points.
e.g. allow a user to insert in the linuxplc.conf file
point P1 "point 1" owner_module at 0.0
skipping the "at 0.0" at the end.
This means that the setup program has to decide where to place the
point.

- change the way the gmm handles the plc_pt_private_t structure.
Currently this is a structure with all relevant information required
to access the plc point. This structure is built from data stored in
the cmm. What I would like to see is the data that is currently
stored
in the plc_pt_private_t stored directly within the cmm, and have the
plc_pt_priv_t point to that location.
Benefits:
- This is part of what is required for supporting online
configuration
changes. We can change the location of a plc point, and all
modules
using that point will automatically see the change.
- This will also greatly reduce stack memory used by the modules.

- carry on with the support for online changes. This means augmenting
the synch library in such a way that we can signal a module to
stop/run, and a global switch for every module to stop/run. I have
not
completly thought this out yet.
Jiri - I think this would be a better solution than to have the
"quit"
point? We can then add two simple command line utilities to signal or
wait on the relevant semphores.

- bring every existing module to support online changes. This merely
means to have the modules use the cmm for global state variables
instead
of placing them on the stack.

- augment the cmm. The cmm is basically a memory allocation library.
De-allocation is not yet implemented, and more intellegent memory
management would be welcome.

- make the code POSIX compliant. We currently use non-POSIX shared
memory
and semaphore primitives. This is not so difficult because all access
is
made through the lib/misc/shmem_util.c and lib/misc/sem_util.c files.
Shared memory has already been fixed, just needs checking for bugs.
Semaphores may be a little trickier because we use them in a way that
I am not sure the POSIX primitives allow. For example, we wait and
signal the _same_ semaphore atomically!


Mind you, I still believe that some User Interfaces should have a higher priority than some of the stated above. If anybody is willing to start on user interfaces, please let me know!

I am starting out a lib/period sub-library. This will allow the user to specify the period of execution of a module. This will come in handy
for modules such as the dsp, that does filtering of analogue values and requires periodic sampling of the input. This sub-library will be the
place where we later place code that can work expliclty with RT Linux. E.g. use the real-time clock to signal the modules to run, etc...
As soon as I have this working, I will write the il demo, that will also use the above. This is in the list for the release.

As you can see, there is always lot's to do.

Cheers,


Mario.

--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

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