LED Low Assembly Code help - Page 1
Forum section: electronics / general

author: tahmod
author_rank: Contributor
timestamp: March 29, 2013, 06:12:39 pm
content: Thanks for the help

author: kfitch42
author_rank: Frequent Contributor
timestamp: March 29, 2013, 06:46:31 pm
content: 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 understandhttp://www.scitools.com/download/index.php) to generate your flow charts.

author: croberts
author_rank: Regular Contributor
timestamp: March 29, 2013, 07:12:06 pm
content: 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 programhttp://www.yworks.com/en/index.html.

author: Rufus
author_rank: Super Contributor
timestamp: March 29, 2013, 08:28:47 pm
content: Quote from: croberts on March 29, 2013, 07:12:06 pmI have written embedded software professionally for more than 3 decades and can agree with his comments.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 29, 2013, 11:52:37 pm
content: Flowcharts are only useful for trivially simple systems, and fail as soon as you have any significant amount of state-dependance, or data flow.

author: tahmod
author_rank: Contributor
timestamp: March 30, 2013, 12:04:57 am
content: -How do I generate the flowchart when after i download the software?-Do I put the code, open the project I created?...Quote from: kfitch42 on March 29, 2013, 06:46:31 pm

author: digsys
author_rank: Unknown
timestamp: March 30, 2013, 12:10:14 am
content: 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 tonail 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 Istart 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 :-)

author: MacAttak
author_rank: Unknown
timestamp: March 30, 2013, 02:26:05 am
content: 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".

author: 8086
author_rank: Super Contributor
timestamp: March 30, 2013, 02:37:15 am
content: 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.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: March 30, 2013, 03:04:52 am
content: 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/PseudocodeThe 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.

author: kfitch42
author_rank: Frequent Contributor
timestamp: March 30, 2013, 03:40:37 am
content: Quote from: AcHmed99 on March 30, 2013, 12:08:29 amYou 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.

author: Rufus
author_rank: Super Contributor
timestamp: March 30, 2013, 04:02:37 am
content: 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.