LED Low Assembly Code help

[tahmod]

Thanks for the help

[kfitch42]

Clearly this is a homework assignment. One thing to keep in mind is that the two steps in the first picture are in the wrong order. I have been doing software professionally for over a decade, and NO ONE in the 'real world' produces a flow chart by hand (at least it hasn't really happened in the last couple of decades).

Flow charts are mediocre ways to explain how software works, and horrible ways to develop software.

Write the code, then use existing software (for example a free trial of understand http://www.scitools.com/download/index.php ) to generate your flow charts.

[croberts]

I can't agree with your comments about flow charts. I almost always start programming projects with flowcharts and have always found them to be very useful throughout the process. The yEd Graph Editor is available free from yWorks and is a great flowcharting program http://www.yworks.com/en/index.html .

[Rufus]

I can't agree with your comments about flow charts.

I have written embedded software professionally for more than 3 decades and can agree with his comments.

[mikeselectricstuff]

Flowcharts are only useful for trivially simple systems, and fail as soon as you have any significant amount of state-dependance, or data flow.

[tahmod]

-How do I generate the flowchart when after i download the software?
-Do I put the code, open the project I created?...

Clearly this is a homework assignment. One thing to keep in mind is that the two steps in the first picture are in the wrong order. I have been doing software professionally for over a decade, and NO ONE in the 'real world' produces a flow chart by hand (at least it hasn't really happened in the last couple of decades).

Flow charts are mediocre ways to explain how software works, and horrible ways to develop software.

Write the code, then use existing software (for example a free trial of understand http://www.scitools.com/download/index.php ) to generate your flow charts.

[digsys]

In my early years, I could NOT live without them. I had WALLS covered in flow charts, often right down to module level.
I could look around and easily visualise everything that was going on, and when there was a bug, it was SO easy to
nail it. Then I guess my brain learned to put up the flowcharts in my head, and I rarely need to do it any more, unless I
start working on a totally new architecture (as per the last few months), in which case I immediately set one up !
That is until It's burnt to brain-ROM :-)  I like to be ONE with the code :-)

[MacAttak]

I've been writing software professionally for 20 years now, not once has a "flowchart" been of any benefit when it comes to describing actual code. The closest things to it that were somewhat useful are data-flow diagrams for ETL processing, and certain types of UML Use Case models.

On the other hand, there are a lot of visual software engineering tools that can be very useful. Sequence diagrams, class and/or component models, block diagrams, state diagrams, etc. Or even just some off-the-cuff mish-mash of those on a whiteboard. And when working with higher-level languages, the programming environment itself usually offers some visualization tools, and in some cases automated testing tools and code verification.


There are much better tools for planning and documenting code. Leave visio and powerpoint to the sales and training guys.


Our training guys have a saying: "anything will compile in powerpoint or visio".

[8086]

I find flowcharts slow me down significantly. Just get to writing code, I say. Debug later.

I only needed flowcharts for university nonsense, or if it would look nice in a presentation.

[HackedFridgeMagnet]

I never use flow charts either. I think mainly because they take up too much graphical space for the amount of logic they contain.
I use pseudo code instead. http://en.wikipedia.org/wiki/Pseudocode

The diagrams I would actually generate and use for a complex project are:
state diagrams if warranted,
sequence diagrams if doing protocols,
auto generated class diagrams if necessary and the IDE supports their generation.
Also relational DB diagrams I find very useful.

[kfitch42]

I would think some way to keep track of a start and end and how you plan to get their while accomplishing all the tasks in between is useful. I would suspect it to be more useful as complexity increases. Maybe not so much a flow chart per say but some kind of notes or something. I find it hard to believe Bill Gates sat down and wrote windows without so much as basic game plan scribbled out on a piece of paper.

Mind you I’m more of an analog guy who manages to muddle his way through assembly or C with pitily 8bit micro’s.

You have some points there. having an overall plan can be helpful... but they tend to look more like a block diagram than a flow chart.  A flow chart focuses on actions. A block diagram focuses on interactions, communication, and interfaces. They can be especially helpful when trying to partition work.

Software "engineering" has had at least two major revolutions:
1) About 20-30 years ago we got Object Oriented Programming: The major observation here was that focusing on the data instead of the processing makes for better processing.

2) About 10+ years ago we got Agile/Test-Driven-Development/Rapid-Prototyping/...: I see all these as aspects of a few observations ( http://agilemanifesto.org/ ), which I interpret as: a) Focus on interfaces b) its easier to modify something that works than bite off big chunks. c) focus on the end-goal/customer (not directly relevant to the current discussion)

The fact of the matter is that a flow chart doesn't "work" ... so it doesn't make a good starting point.

P.S. now that I have ranted long enough ... another aspect of agile is to focus on the team, and what works for them. If flowcharts float your boat, go for it. I will scratch my head while you draw boxes, and start writing some tests.

[Rufus]

Modern structured languages don't have 'flow'. They have blocks of executable statements and conditional statements which determine when those blocks are executed. The lack of 'flow' is what makes structured languages easy to read, understand, and of course write.

The compiler generates the gotos which are the lines on your flow charts. I don't design software by designing those gotos first, I don't need to think about them at all.

Even when the end result is assembler I will design and document in a structured language real or pseudo.