Rainer:
>>> I am now with CP for some years, but I never had to use OO features.
>>> Creating clean modules and applying classes to get abstract data
>>> types was sufficient for my projects in the past.
Classes and abstract data types are OO. So you are doing OO already at the
level which suits your needs.
> Right now my only motivation is learning. But let me tell ...
>
> In the past I developed software for automatic test equipment. We had
> VME-bus systems with 68k CPU's running a unix like real time
> operating system. The only language being available was plain C.
Now I am getting excited. I am attaching a photo of a hardware board which
I designed and built last year. Now I am developing the FPGA firmware and
the embedded Linux software running on this board. A quick look at the
board will tell you it is a VME board. I never did anything substantial in
VME. It is a new area to me.
[A note to Fyodor: this instrument is a 10-channel waveform digitizer, 14
bits {([at]})nowhere.xy
per second. It also has a gigabit ether, USB-2, LVDS, RS-232, and VME
interfaces. It is running on-board Linux. We will use these boards in our
underground astrophysics experiment searching for extraterrestial Dark
Matter. These boards can be used for many other High Energy Physics or
Nuclear Physics experiments. The instrument is commercially available from
me.]
> I tried to learn from these languages (concepts,
> readability, simplicity) and to port know how from these languages to
> programming in C.
>
> E.g. with the use of the preprocessor the source code was made more
> readable:
> - no "{" and "}" but "BEGIN" and "END"
> - no "if (a < b) {" but "IF a < b THEN"
> - no "do { ... } while (a < b)" but "REPEAT ... UNTIL (a >= b)"
> - no "a && b || c" but "a AND b OR c"
> - no "static" but "PRIVATE"
> - no "struct" but "RECORD"
> - no "++"
> - no "--"
> and many more.
This also rings a bell. About 15 years ago I did a few experiments at
Michigan State Univ. cyclotron. Their data acquisition was using a 68k VME
controller. My task was to write online acquisition procedures for that
controller. It was all C, but they performed the trick similar to yours.
They #defined FORTRAN keywords on top of their system. So I was writing
those procedures in FORTRAN-like dialect, which made the task bearable for
me and for many other physicists. That system was used for many years.
> For some reason there was a management decision about seven years ago
> to give up this platform and we were forced to program in Lab View, a
> graphical programming language by National Instruments. Poor control
> structures....
This also rings a bell! I used LabView once to test my first piece of
hardware, which was a CAMAC timing board. I needed to send a few simple
commands to that board, and collect test data. A collegaue of mine sent me
a "virtual instrument" written in LabView for a roughly similar
instrument. I took me a week to make seemingly simple changes, which would
have been trivial under any programming language. When I got it running,
it could collect data some 10,000 times slower than the hardware limit. I
completed my tests, but this experience left me wondering how LabView
could have become a huge market success?
> Because of these and many many more problems with the "world of Lab
> View" in our department there was a decision to reimplement again the
> process control application.
I am myself inclined to avoid LabView like a plague. But try saying this
to an electrical engineer.
> The project
> requirements have been increased: there should be a general solution
> which is adaptable to different needs.
To me it sounds like an interesting requirement.
> Because of my knowledge of the application on the VME-bus systems and
> because I was involved in a number of meetings concerning the
> requrements of the re-reimplementation I am very familiar with this
> topic. So I plan to take this chance to try a design and perhaps a
> partial implementation as a home work and to learn how to apply OO
> concepts to get a "general solution" which is adaptable a little bit
> to different needs.
I may have a solution for you... let ma attach a PDF file. The digitizer
from the previous photo is in fact two boards: a motherboard and a
daughter card (have a closer look). The daughter card implements those
ADCs. But the motherboard is completely general. I designed it to be a
"digital platform" to implement literally anything, if only the "anything"
can be fit on a daughter card. The "anything" can consist of ADCs (as
shown in the first photo), or DACs, or both ADCs/DACs to implement a PID
controller, or whatever you wish. Developing any application whatsoever is
a matter of designing the daughter card and then programming the
motherboard.
Programming-wise, I have OO in mind in the following sense: the hardware
board is the "object", which contains its own software in the flash chip.
What sticks outside is a web browser. The board runs its own web server.
It is the board's responsibility to take care of itself, using embedded
software which only the developer knows. And this is exactly what OOP is
trying to achieve.
What software? It is up to you. Linux is in general good at running a
great variety of things. It can be Python, or it can be Ruby, or perhaps
some Oberon stuff translated to C with Ofront.
At this point I already have embedded web server running on the board and
controlling the FPGA. Going further is a matter of customizing it to a
particular application.
>>> The big picture of the technical process to be controlled is always
>>> the same. But in reality there are some different types of machines,
>>> because they have different number and type of hardware equipment,
>>> different types of control algorithms and different types of calls to
>>> a relational data base for retrieving data about the parts to be
>>> tested automatically and for storing the results of the tests
>>> respectively.
My approach is to encapsulate all the stuff inside the board. The
behaviors stick outside. The implementation is hidden in the flash chip.
The developer is writing custom software, which controls the process via
the custom daughter card. That custom software is hosted by the embedded
Linux.
> So I will take your advice and think about developing a "small
> version" first and get it running.
My current work is focused on the hardware board, which is running its
software on-board. The board is controlled by sending it high-level
commands such as clicking the buttons generated by the embedded web
server.
I know that such solutions are not new and have been tried before. The
devil is in the details.
I hope it makes sense to you.
Regards,
Wojtek
PS: this board is commercial. If you have a need for great many such
boards then I have a company who can make them.
----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
Received on Mon Mar 21 2011 - 01:20:15 UTC
