Cell Phone Software Forum
| View previous topic :: View next topic |
| Author |
Message |
LuisC
Guest
|
 Posted: Thu Mar 15, 2007 12:30 am Post subject: Help with software design |
 |
|
Hello
I am programming a Linux based system in with I'm integrating
databases (currently MySQL), interacting with I/O ports (USB, RS-232
and Parallel).
The system is being writing in C (I don't now very much about C++, and
my mind _think in_ structured, not OO, but I want to learn to Design
and Program in OO).
This is an automated cars and trucks access control system based on
Active RF ID technologies, and it has the next components: One or many
(say, 10) LED matrix panels controlled by the I/O ports (mostly by
Parallel and Serial ports), one LCD panel controlled by parallel port,
--I call these the "output subsystem", along with the reports sent by
mail--; one RF ID Reader (serial port), one Bar code Reader (serial
port), and probably others (like iButton readers) --the "input
subsystem".
Because I need to poll the serial port for inputs, and I need
constantly refresh the panels (each panel may print distinct data,
like clock, the number of the truck the temperature, some publicity,
etc), and also I want a flexible system (that I can add "readers" or
"writers" --such as panels and bar code readers -- and without
recompiling the code), I was made 2 versions: one with each subsystem
as thread --I need to recompile the code if I want a new "reader or
writer"--, and one with each subsystem as processes (each process can
be compiled separately, and then "attached" to a main process through
some IPC --I am using TCP sockets).
The problem with the "threads version" is that the code is very
complicated, and is difficult to debug and maintain.
The problem with the "processes version" is that I need to duplicate
much code and actions (like connecting to the database to get the
configuration settings), and sometimes (I don't know why) I'm losing
some messages sent by TCP socket to the main process. Also, I need to
recompile the main process each time I need to attach a "new type" of
subsystem (this is not a major issue).
So, I need help. How can I do to get a "better system"? What is the
best approach? What another approach are there that is better than
this? I'm using the correct language?
Thanks
Luis
P.S.: Sorry for my bad English. I'm an Spanish speaker. |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
Martin Vuille
Guest
|
| Posted: Thu Mar 15, 2007 1:37 am Post subject: Re: Help with software design |
|
|
"LuisC" <luiscardozocarreras@gmail.com> wrote in
news:1173904222.249580.237090@p15g2000hsd.googlegroups.com:
| Quote: |
This is an automated cars and trucks access control system based
on Active RF ID technologies, and it has the next components:
One or many (say, 10) LED matrix panels controlled by the I/O
ports (mostly by Parallel and Serial ports), one LCD panel
controlled by parallel port, --I call these the "output
subsystem", along with the reports sent by mail--; one RF ID
Reader (serial port), one Bar code Reader (serial port), and
probably others (like iButton readers) --the "input subsystem".
Because I need to poll the serial port for inputs, and I need
constantly refresh the panels (each panel may print distinct
data, like clock, the number of the truck the temperature, some
publicity, etc), and also I want a flexible system (that I can
add "readers" or "writers" --such as panels and bar code readers
-- and without recompiling the code), I was made 2 versions:
one with each subsystem as thread --I need to recompile the code
if I want a new "reader or writer"--, and one with each
subsystem as processes (each process can be compiled separately,
and then "attached" to a main process through some IPC --I am
using TCP sockets).
|
My approach would be to break the system up into multiple
processes along functional lines, perhaps with one process
per subsystem, perhaps with finer granularity than that (i.e.,
one process for bar code readers, one for RFID readers, one
for LED panels, one for LCD panels, one for reporting, etc.)
Some of these processes could then use multiple threads
if that makes it easier to control that type of device. For
example, if you are not very comfortable with asynchronous
I/O, you could have one thread per device, so that you can
use blocking I/O calls. Because there should not be much
interaction between the threads (since they're not talking
to each other, but to the main control process,) it should
keep the number of problems down to a minimum.
To add and remove devices from the system, I would simply
update the configuration in the DB, and have each process
manage the appropriate number of devices based on the
configuration data. You don't say whether you want to be
able to add/remove devices while the system is live.
If you mean that you want to be able to add new types of
devices that the system didn't support before, then things
get a little more complicated. You would have to define
some sort of generic "input" or "output" device interface
that every input or output device has to implement. When
you want to support a new type of device, you then have to
code-up a process to map the new devices onto the appropriate
generic interface. Then there would be no need to make
changes to the main control process.
| Quote: |
The problem with the "processes version" is that I need to
duplicate much code and actions (like connecting to the database
to get the configuration settings), and sometimes (I don't know
|
There should be no need to duplicate code, in the sense
of having the same code in multiple source files. Whatever
code needs to be shared can be placed into libraries. Each
process calls the library to perform common functions.
| Quote: |
why) I'm losing some messages sent by TCP socket to the main
process.
|
This just sounds like a bug. Passing messages between
processes is very reliable.
| Quote: |
P.S.: Sorry for my bad English. I'm an Spanish speaker.
|
I think your English is fine. Better than my Spanish :-)
MV
--
I do not want replies; please follow-up to the group. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
H. S. Lahman
Guest
|
| Posted: Thu Mar 15, 2007 7:49 pm Post subject: Re: Help with software design |
|
|
Responding to LuisC...
Basically I agree with Vuille; you probably need to break up the
application into more modules or a layer for talking to the I/O port at
a low level.
| Quote: |
I am programming a Linux based system in with I'm integrating
databases (currently MySQL), interacting with I/O ports (USB, RS-232
and Parallel).
The system is being writing in C (I don't now very much about C++, and
my mind _think in_ structured, not OO, but I want to learn to Design
and Program in OO).
|
Learning OO by programming in C++ is not a good idea. The OOPLs,
especially those that are C-based, make a lot of compromises with the
hardware computational models. That makes it very easy to map procedural
design techniques onto OOPL code. And learning OO while programming in C
is a Really Terrible Idea. B-) If you want to learn the OO paradigm you
need to read up on OOA/D. It is a completely different and incompatible
approach to design from Structured Design. [The Books category of my
blog has some suggesting for finding a good book or two.]
| Quote: |
This is an automated cars and trucks access control system based on
Active RF ID technologies, and it has the next components: One or many
(say, 10) LED matrix panels controlled by the I/O ports (mostly by
Parallel and Serial ports), one LCD panel controlled by parallel port,
--I call these the "output subsystem", along with the reports sent by
mail--; one RF ID Reader (serial port), one Bar code Reader (serial
port), and probably others (like iButton readers) --the "input
subsystem".
|
Whether you need to isolate each device depends upon the complexity of
talking to the device (e.g., connecting/disconnecting, register
protocols, buffering, etc.); you don't need a subsystem or process just
to read a register. It can't hurt to isolate each one in the initial
design, though, because it is much easier to combine trivial devices
than it is to break up monolithic processing.
Also, you want to isolate based on the subject matter. The semantics of
an LCD panel and the semantics of a bar code reader are quite different
and one would expect different interfaces that reflect that semantics.
Whoever is providing/requesting the values will be thinking about a
quite different problem context. However, under the hood the mechanisms
may be very similar. In that case the interface essentially just
provides data identity for mapping to things like "canned" message
formats. [More below on making that mapping generic.]
That is, talking to an I/O port is pretty much the same for broad
classes of I/O ports. So there may not be many flavors of I/O port
implementation once one abstracts the invariants. But determining what
values to send/receive is very likely to be quite different for each
device. So you may have more interfaces than I/O port readers/writers.
| Quote: |
Because I need to poll the serial port for inputs, and I need
constantly refresh the panels (each panel may print distinct data,
like clock, the number of the truck the temperature, some publicity,
etc), and also I want a flexible system (that I can add "readers" or
"writers" --such as panels and bar code readers -- and without
recompiling the code), I was made 2 versions: one with each subsystem
as thread --I need to recompile the code if I want a new "reader or
writer"--, and one with each subsystem as processes (each process can
be compiled separately, and then "attached" to a main process through
some IPC --I am using TCP sockets).
|
I get the impression that the flexibility is really your main concern;
that you want to be able to modify the system while it is essentially
running 24x7.
I would look at parametric polymorphism as a vehicle for doing that. At
the lowest level controlling any device is about reading and writing
values to hardware registers. At that level the semantics of the value
don't matter; the problem is mapping it into registers and fields. Those
registers and fields are described in bit sheets that are basically just
data. If you provide generic code for the hardware reads/writes that is
parameterized by the bit sheet data, it will be reusable across devices.
Then you can substitute devices by just supplying different <external>
configuration data. [The category on Invariants and Parametric
Polymorphism on my blog provides more details.]
Then the interface I referred to above just provides identity for the
value to be read or written. That is, the interface method (e.g.,
writePixel(...)) identifies the data and that can be used to map into
register/field identity (or sequence of writes for a message format like
a SKIPPY driver) through lookup tables that are initialized from
external configuration data.
<aside>
I worked on a VXI system where we queried the hardware to find out what
was actually there. Then we read an Excel spreadsheet containing the bit
sheet information to initialize the right hardware surrogate objects
with the bit sheet data as attributes and generic read/write methods.
That allowed exactly the same software to run in customer environments
that had highly customized hardware. All we needed was for the
spreadsheet to contain bit sheet data on all the /possible/ hardware
variations. So when new hardware cards were added, we just updated the
configuration file.
</aside>
| Quote: |
P.S.: Sorry for my bad English. I'm an Spanish speaker.
|
The English is fine. But being a Spanish speaker is something else
entirely... B-))
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
212 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
