Hi Vitaliy,
The OOP approach was the one I took in the beginning, but as I tried to
make may program more and more universal, similar to a class, it started
not working very well. The main problems were how to deal with the
interrupt routines and the order of the include files. As some of my
"class like functions" had links with the interrupt routines, they
seemed not to make sense on there own, also the order of the include
files on the main "class" was not always the same depending how the
program was used.
On this particular program I am using the USART to transmit and receive
a packet of information, I have several functions that dealt with packet
reception, packet processing once received, packet validation and
checksum calculation. I also have similar functions for packet
transmission. The intension was to use this program as an ancillary
program to transmit/receive data from another device like a PC, whenever
I need that facility. So when I need communications I just include the
packet transmission functions and on the main program pass it or get the
data I need to transmit or receive. In OOP this structure is trivial but
in C it is difficult to make it that simple.
I will be interested to look at your method.
Thanks.
Best Regards
		Luis      


-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf
Of Vitaliy
Sent: 02 July 2009 06:37
To: Microcontroller discussion list - Public.
Subject: Re: [EE] C programs representation

Luis Moreira wrote:
> You are right, this is probably what I need.
> I never realised how difficult it was to get a relationship diagram in
C
> that gives you all the information about the function interaction. But
> maybe is the way I am writing my programs.
> I started out by having a separate file for each function that I
deemed
> it was large enough or had some possibility of reuse, but then it seem
> to make more sense to have library C file that had all the functions
in
> it. Like this I just include one file and all the functions are there.
> At this point it doesn't seem like a good idea anymore.

Luis, I think it's great that you recognize that there is a problem and
that 
you are looking for a better way.

I think that any serious procedural programmer sooner or later gets to a

point where his program get so complex that it's impossible to grasp in
its 
entirety. The natural reaction is to try to rein in this complexity with

documentation in the form of flowcharts, interface specifications, and 
comments inside the code. I know because I've been there. It is
frustrating.

About a year and a half ago, I got really tired of using the brute force

method of learning from my mistakes, and started researching better ways
of 
writing and managing code.  I read books on OOP, design patterns and 
refactoring, came across a great article on the internet written by
someone 
who explained how to use C++ concepts in plain C, and bounced ideas off
the 
PICList. If you were bored enough, you could follow my posts starting
around 
that time, and see how the method gradually took shape.

My biggest realization was that in order to effectively manage
complexity, 
one has to start thinking in terms of objects. An object is "something
with 
responsibilities". It takes some practice, but eventually the answer to
the 
question "where do I put this function?" becomes self-evident. Perhaps
even 
more important, this works in reverse as well: you know which object a 
function resides in.

Thinking in objects has other positive side effects, for instance you
get 
code that is more cohesive and loosely coupled, which in turn makes it 
reusable. If you want to give it a shot, I can describe the specifics in

more detail.

You don't have to spend a lot of time to change over to this system,
either. 
You can do it in small steps, refactoring your existing code little by 
little. So the risk is minimal, and the benefits are great.

Vitaliy


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist