> I have written down the dig outline and divided this in to
> smaller blocks. Some of these blocks are small enough to be
> turned in to a flowchart. From this flowchart I then make
> the actual assembler program. But when it comes down to the
> nitty-gritty detail I find that the division I made when
> working with the bigger blocks is not always the right one
> and I have to go back to the top level and re-arrange thinks
> to make them fit the nitty-gritty detail stuff. Tedious work
> in short. There must be a better way. So I'm asking you how
> does one go about tackling a more complex programming
> project?

There have been volumes written about this and competing religions evolved
from differing views.  The best approach depends on a lot of things,
including the size of the project (amount of code ultimately required) and
the number of people that will work on that code.  Other factors include
how much auditing is required, what kind of accountability is required for
billing or charging the time, etc (government contracts can force certain
structures, for example).

PIC projects are inherently small because of the limited program memory
size.  I just looked at the two biggest PIC projects I remeber.  One was a
cram packed 16F876 and the other a nearly full 16F877.  The first took
8186 lines and the second 8601 lines of well documented code unique to the
paricular project.  This does not include several thousand lines of
standard PIC environment stuff with include files, 32 bit integer and 24
bit floating point library routines, etc.  I would assume therefore that
even a full PIC18 project would be less than 20000 lines of
project-specific code.

Code of such small size is best written by a single person.  Other people,
if needed, can work on other parts of the bigger project, like the low
level host library that provides a procedural interface to the PIC gizmo,
or the GUI that sits on top of that.

I prefer to first loosely design a system from the top down.  The result
of this should only be a one or two page block diagram.  This is where you
decide what gets done in hardware versus firmware versus host software
(let's assume this thing talks to a host for now), but only enough of the
details to know that each block can do its job appropriately.  This should
give you a rough idea of the host <--> PIC communications protocol and the
interfaces between major blocks in the system.

Next I start writing the specifications at important interfaces, like the
host communications protocol.  The firmware reference document is started
and the PIC I/O pins are defined with /INBIT and /OUTBIT directives and
documented in the project include file.  (see http://www.embedinc.com/pic
and look at the PIC preprocessor for a description of /INBIT and /OUTBIT).

Now spend some time just thinking how all PIC code will be partioned and
how the pieces will be put together.  This is the real software
engineering step, and unfortunately I don't know how to explain or teach
how to do this right, although it is critical.  Experience definitely
helps.  This is where you'll find the biggest difference between bad and
good software engineers (anyone can write code that eventually works, but
very few people seem to be good at stucturing it).  This is where you
decide things like will the A/D be read from an interrupt, or from the
foreground code?  Should this be a global parameter or passed to
subroutines when needed?  How much of the specific job should this
subroutine do versus being general and useable in more places?  How can it
be layered to have both interfaces without replicated code?

Once you've got the basic structure in your mind (I don't think it needs
to be written down for a project of this size, but go ahead if it helps
clarify your thought), you can start writing code.  I always start from
the bottom up.  You will discover details in the low levels that change
the architecture of the higher levels.  That's fine since the higher
levels haven't been implemented yet, but it's very important that the
documentation is kept up to date.  If not, things can devolve to confusion
rapidly.  The project will eventually build up from the low levels until
everything is implemented.

The only drawback to the bottom up approach is that it is difficult to
demo until most everything is implemented.  The importance of this depends
on how impatient the customer is, how much the customer needs to prove the
concept to their customer, etc.  I've been on projects where almost as
much effort was put into throw-away code for demo purposes as the real
project.  This seems to be proportional to how much the project manager
feels threatened by not understanding the technology, although sometimes
there are legitimate reasons for it too.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics