Searching \ for '[EE]: How to tackle a more complex programming pro' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'How to tackle a more complex programming pro'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: How to tackle a more complex programming pro'
2002\12\08@095621 by Eelco

flavicon
face
Hello,

I'm in the middle of a fairly complex programming project.
At least to me it seems like a fairly complex programming
project. I think to some of you with more programming
experience what I'm doing now may seem like a walk in the
park. (by the way going out for a walk seems to help focus
the mind).
I have read a few books and articles (maybe not the right
ones). And usually you are told how to flip a bit or how to
hook-up a LED and turn it on. But not how to tackle a bigger
project. So far I have come-up with following approach.
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?

Regards,
Eelco.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\12\08@105005 by Wouter van Ooijen

face picon face
> I have written down the dig outline and divided this in to
> smaller blocks. ....

You have already learend a lot about programming/informatics/computer
science or whatever you want to call it. Divide-and-conquer (the method
you use) is still the only method, but the emphasis is on the divide
part, which is simply difficult. And it gets more difficult when you are
earlier in the projec / handling a bigger project. That is why they have
invented functions like analyst, designer, system engineer or whatever:
basically people who have a *lot* of experience in conquering so they
now know how to divide so other people can conquer without meeting too
many unconquerable problems. But there still will be 'can not conquer'
reports, which will cause the dividing to be done all over. You might
undertand that this is expensive, because the other pars have probably
already been conquered and are now useless. So some projects choose to
conquer the difficult parts first, so when they prove to be
unconquerable not too much work is lost (this can be called
proof-of-concept, or (rapid) prototyping, or extreme programming, or
...).

One hint: if you don't need assembly consider C, Pascal, Jal or another
HLL. The time spend learing a new language will pay itself back with
easier conquering. But it will not change the basic fact: (good!)
dividing is difficult.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\12\08@111359 by Dave Tweed

face
flavicon
face
Eelco <spam_OUTe.deutekomTakeThisOuTspamHCCNET.NL> wrote:
> 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?

You're actually on the right track; it's called top-down design, bottom-up
implementation, with backtracking as required. There's no one cut-and-dried
way to tackle large projects.

As you gain more experience, you'll be able to make smarter choices on the
first top-down pass and avoid much of the backtracking. Stick with it and
you'll find that it works out rather well.

Another key for me is documentation: In the top-down design phase, I write
down (in as much detail as I can stand) the complete specifications of
both the interfaces between modules and the functionality of the modules
themselves. This helps me design clean interfaces, and becomes valuable
during debugging or when revisiting a project months or years later.
It also helps others come up to speed quickly when joining the project.

As you tweak the design details during the implementation phase, be sure to
keep the documentation up to date!

-- Dave Tweed

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\12\08@145231 by Bob Axtell

face picon face
For a complex program, we first write out the
program as a TURBO PASCAL 7.0 (DOS)
or an object in Delphi 5 (Windows, which is
also PASCAL).

The uniqueness of PASCAL is that data typing is
rigidly controlled, the routines are easily understood,
and every complex piece of the program can be
tested, retested, and minimized before committing it
to the uP. This eliminates having to later write the uP
program over and over again, which introduces
errors and poor code.

We then write the uP program in assembler, using a
simulator and/or emulator to verify each critical
routine. While the hardware emulator is best overall,
the simulator is easier to work with when minimizing
or reducing a routine.

Finally, as a test, we are able to match results of the uP
program against the results of the PASCAL.
{Original Message removed}

2002\12\09@062325 by Eelco

flavicon
face
Wouter van Ooijen, Dave Tweed and Bob Axtell.
Thank you for your answer.

Regards,
Eelco Deutekom.

--
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


2002\12\09@104100 by Olin Lathrop

face picon face
> 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


2002\12\10@052054 by Tutopia

flavicon
face
Dave Tweed wrote

DT> Another key for me is documentation: In the top-down design phase, I write
DT> down (in as much detail as I can stand) the complete specifications of
DT> both the interfaces between modules and the functionality of the modules
DT> themselves. This helps me design clean interfaces, and becomes valuable
DT> during debugging or when revisiting a project months or years later.
DT> It also helps others come up to speed quickly when joining the project.

DT> As you tweak the design details during the implementation phase, be sure to
DT> keep the documentation up to date!

I totally agree with you Dave. Documentation is helpful but hard and
boring!!!!, I hate but is necessary.

I also recommend using programs like Ultraedit to program the code. It
is a very helpful editing tool with a lot of feature that MPLAB
doesn't have.


--
Best regards,
Tutopia                            .....mplegKILLspamspam@spam@tutopia.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...