How does one go about planning a project?

Discussion in 'Embedded Systems and Microcontrollers' started by bance, Jan 24, 2013.

  1. bance

    Thread Starter Member

    Aug 11, 2012
    315
    34
    I normally work in construction, I'm quite used to working on large complex projects, with contributions from other professionals.

    I try to make a relatively simple project on a micro-controller, and the task seems insurmountable!

    I know I have to break it down into manageable chunks, solve the small problems in each chunk and then amalgamate them all into a cohesive whole. At work there are many tools that I can use to aid me in the planning and execution of a project, what are the tools available (particularly at the planning stage,) for planning to programme a micro-controller?

    I suppose I'm asking what form of analyses are used when there are loops within loops within loops and then branches and delays and who knows what else,to contend with.

    Actually just writing this has made me think of analogous situations in my own work that I may be able to apply.

    However, the question is what do you use?
    Flow-charts? Critical-path analysis? I think some sort of graphical description of what is required, at least. Do you scribble on a piece of paper or use software? If so what do you use?

    Come on let me in on the secret!!!!:D
     
  2. tshuck

    Well-Known Member

    Oct 18, 2012
    3,531
    675

    It depends on the complexity of the project. Flowcharts are a good way to understand what you want to have happen. Simulators are a good way to understand what should happen. And real life is, well, what actually happens. Unfortunately, there are limitations to consider for each step.

    I sometimes scribble on a napkin while I'm out to dinner, or do a full diagram after hours of meticulous planning at my desk.

    Simulating your design can save many a headache as you can see if your program is outputting what you think it should be. This can help with your loops. You can pause the simulation and see what the iterator for your loop is, or what the logical condition of your loop is before the code gets there.

    After everything is hooked up, using a debugging tool to step through your microcontroller's functions can be quite nice, as you can see your register values in each step of the program in operation.

    Laying out your schematic in a layout program, like EAGLE, can help in wiring.

    Doing component simulation is a circuit simulator, like LTSPice or PSPICE, can also help.

    It all comes down to what phase you are at in the project.

    What microcontroller are you planning to use?
     
  3. THE_RB

    AAC Fanatic!

    Feb 11, 2008
    5,435
    1,305
    It's hardly a "secret" but flowcharts are vital I think.

    It's good to start with a flowchart of the actual device operation (often seen from the user). Ie; if you press button A then X happens.

    That first flowchart should solve all the operational issues; what the user inputs are, what the outputs are (displays, lights etc) and is the kind of task normally done by a "designer" who designs what the project actually does.

    It's good to draw that one on paper.

    Then you do a more complex flowchart of the software operation. This will chart out what decision the software makes, what loops there are and basic branching etc. It also should have some decisions made about how inputs/outputs are handled, and if any task is done in an interrpt, at a fixed interval, as part of items in a loop etc etc.

    That one you can probably write out as comments in your code source. Then when the comments show exactly what has to be done it becomes pretty easy to type the code in between the comments.
     
  4. kubeek

    AAC Fanatic!

    Sep 20, 2005
    4,670
    804
    As for the actual programming of microcontrollers, this depends on the complexity of the task.

    For example for somthing simple, like controlling stepper motors in a would-be CNC I just started writing the program and debugged as I went (it is great to have a spare uart and spare processor time to print debug messges to a terminal).

    For something more complex I usually start drawing on a piece of paper - tables, state diagrams, equations, timing, drawings of received data packets...

    For even more complex and fast stuff I have to resort to setting trigger to an output pin and watching on a scope for example how often a routine or interrupt is called or how long it actually takes to execute.
     
  5. bance

    Thread Starter Member

    Aug 11, 2012
    315
    34
    So. it sounds like first draft on paper.... then more concentrated thought maybe in an office suite (easier to re-arrange stuff)...

    Different pages representing various branches/loops? But is there no organised (set pattern) method to this?

    E.G. In construction (mostly) we start from the ground up... then things are arranged in work groups... excavation, earthwork support (for safety,) concrete, frame..... etc. etc.

    OHHH I get it because one could be doing anything, the structure has to be created for each project.... OK maybe it's how the framework is constructed that's important....

    How would one start to list priorities?.... goes back to the beginning doesn't it?

    I do realise the importance of simulators when writing code, I wish I knew better what they were telling me?

    I think some of that is my unfamiliarity with how programs work, and also a lack of real understanding of the simulators themselves.

    It boils down to training doesn't it, for instance my code reaches a certain point then fails... so I know the problem lies in this area. however I lack the understanding of what has actually gone wrong.. the programme jumps to somewhere unexpected and I fail to understand why?

    I know that this is part of the learning process and I do my best to not get frustrated by it.... but in all the things I've ever done in my life this is one SOB.

    I've made another post in 'projects' outlining what I'm trying to achieve.
    and I'll post again in "embedded' with more detailed explanation of the problems I'm facing.

    Thank's for your help, I'll try to come up with a plan......
    because as everyone knows, if you fail to plan, you plan to fail!
     
  6. kubeek

    AAC Fanatic!

    Sep 20, 2005
    4,670
    804
    Usually what you use for programs are debuggers, not simulators.
    Form your other thread it seems to me that most of your problems arise from doing it in assembler. I don´t know PICs very well or even which series you use, but from what i´ve heard about them programming them in assembler is PITA. And even though I have a fair experience in AVR assembly, I wouldn´t try doing a project of this complexity in it.

    When you program in C, the code gets very straightforward and you can very easily divide the problem in many sub-tasks without loosing track of which part does what and how, where does the result get stored and what other things you might have altered in the process. Also revising your code is much easier, because most code in C you just look at and know what it is doing, not so much in assembler where one line of C could take 10 instructions, and an error could be in any of them.
    And then comes the switching between memory banks..
     
  7. bance

    Thread Starter Member

    Aug 11, 2012
    315
    34
    Thank's Kubeek,

    But I'm really trying to learn how processors work, and I've always found that learning the fundamentals stands one in good stead for all others... laziness in the extreme.

    Or if you like " give a hungry man a fish and you've fed him, teach him to fish and he'll never be hungry"

    C is something I want to learn also, but I want to understand it and what it does, I'm not looking for instant results, I'm looking for understanding..
     
  8. kubeek

    AAC Fanatic!

    Sep 20, 2005
    4,670
    804
    Well with C you will have to learn about the same as with assembler, because if you don´t know what the harware does when an interrupt is served or when you go to sleep mode, you´re screwed with either of them. Also it seems to me that what you accomplished so far shows that you already understand what the processors does.
     
  9. thatoneguy

    AAC Fanatic!

    Feb 19, 2009
    6,357
    718
    Decide what the inputs are, and what your outputs will be. Get a rough idea of total power draw/power supply requirements.

    Decide what external peripherals, such as ADC, LEDs, motors, etc. will be used.

    If you are using a microcontroller, choose one that has the abilities you need to eliminate peripherals, such as external ADC, comparators, logic, etc.

    Draw a flow chart of how you want things to work, looking between datasheets and required I/O and functions.

    Draw a schematic that is set in clay, defining all of the electrical connections.

    Start writing the code, follow flow chart. Start with the basics, work to each functional module until finished. (Preferably in C. I use SourceBoost C when working on mid range PIC, gcc for AVR, embedded C for soft cores)

    Simulate circuit and MCU software. (concurrent with code)

    Prototype to ensure it works (often done at same time as writing code).

    Make schematic that is set in dry clay.

    Layout and etch PCB (if making more than one unit, or if using SMD)

    Test, fix code or schematic as needed until all functions and environments have been tested with multiple units. Test overload limits.

    Post code (All previous versions should be saved in CVS Versioning system and commented extremely well).

    Fix Schematic, PCB, and code so things stop locking up, smoking, melting, and failing during tests. :)

    Go through tests again (not needed for hobby circuit)

    Draw final schematic.

    Post final code (All previous versions should be saved in CVS Versioning system and commented extremely well).
     
    Last edited: Jan 25, 2013
Loading...