How to learn embedded product development life cycle and use it to create a component?

Thread Starter

naseeam

Joined Jan 4, 2017
75
I need to learn embedded software and hardware development life cycle and use it to create electronic hardware/software component. I need to approach this job systematically. For example, what is the order of tasks. Probably requirements should be gathered and documented. Then, what's next and so on? At what stage should we select hardware components.
 

shteii01

Joined Feb 19, 2010
4,644
Do something simple, door bell, tv remote, outdoors temperature monitor, etc. That will teach you and you will have something to show.
Or.
One of those free arduino projects books will walk you through a lot of stuff.
 

JohnInTX

Joined Jun 26, 2012
4,704
I need to approach this job systematically. For example, what is the order of tasks. Probably requirements should be gathered and documented. Then, what's next and so on? At what stage should we select hardware components.
You're on the right track. The first thing to do is to carefully decide what the project is supposed to do. Oddly enough, a lot of inexperienced programmers start by firing up an IDE and banging keys, hoping to get a few things working then a few more. These efforts usually end in failure.

The first thing to do is fully describe the project to yourself then write that down. It's tempting to bypass such an obvious step but you can't proceed until you know what you want. A good way to think about it is as if you were describing the project to a group of non-technical people. What's it for? How is it used? What problems does it address and solve? How does it solve those problems? When you have figured that out, things like how much I/O becomes easy to see.

As a simple example you might sit me down and say you are going to build a water pump controller that senses the level of water in a well and when the level is high enough, starts a pump to pump water into a tank. The pump stops when 1)the well level is low or 2)the tank is full. When the tank is full a green light is ON and when the pump is running a yellow light is ON. Finally, there is a switch that runs the pump manually. The whole system is powered by the regular house AC current.

Cool. Those few sentences describe the system broadly. Note that we haven't said anything about HOW all of this gets done. We assume because we are competent designers that it will get done. Next drill down and see what we can learn from the description i.e. we can extract some specifics and begin to list them.
Since there is some logic involved, we decide to use a microcontroller.
Since the power source is mains AC, we'll need a suitable power supply to convert AC power to a good clean DC source for the micontroller and logic.
We need at least 3 outputs: for the pump and for the green and yellow lights.
We need at least 3 inputs: for the well and tank level sensors and the manual button.

Let's look at the logic of how it works. Time to get a pencil and paper and start drawing. Start with a box containing the controller. Add a line for power in. Show each input and output with where it goes. Draw the well and tank and show where the level sensors are. Add the little stuff like the manual button and the two lights. There's your system!

Now, run through the logic in your mind while looking at your drawing. Well level up, tank level down, start pump, turn on light(s). Tank full, pump off, lights off etc. Go through all of the combinations of water levels, sensors etc. Start outlining the logic flow from a known condition, maybe well full and tank full. From there, sketch out the logic flow.. what happens when the tank level drops? Button pushed? Tank low but well low too? Sketch a flow chart.

Look at the unusual conditions. Well and tank full and you run a bit of water out of the tank, just uncovering the tank sensor. Does it make sense to run the pump for that little bit? Probably not. A good solution would be to use two sensors in the tank. The tank is full when both are covered. But now, as the water level drops, nothing happens until the lower sensor is uncovered. The pump then runs until the top sensor is then covered. This 'hysteresis' is common in such applications to avoid lots of short runs of the pump. It would be a good idea to do the same in the well for the same reasons. .. OK, we just added 2 inputs. No problem because we haven't picked a microcontroller yet. Just add them to the list.

Continue with the 'desk-checking' until you've 'run' the system through all its normal and abnormal conditions. When you are done, you'll have a flow chart or maybe a state diagram describing your whole system. How it operates (and how to operate it) is fully described; all the input/output requirements and how the system uses them to do its job. Congratulations, you've just done most of the work.

Note that the job's well on towards completion and we haven't written a single line of code. We haven't even picked a microcontroller. But we have pretty much solved the problem. The rest is relatively simple.

But yes, since we've gotten this far, let's look at connecting some things up. We have our IO list so let's get those hooked to the micro. Looking at that will help us identify what features we need in the microcontroller. The pump will need some sort of relay to convert the micro's logic output to something bigger. Time to design that. The light output circuits depend on the kind of light. A lot of micros can drive LEDs directly so let's go with that. The level sensors will need some signal conditioning to convert the relatively high impedance water conductivity to a good logic level. Or maybe you can use float switches. Your call. Regardless, it's time to design and test the interface hardware.

Now with all of that, pick a microcontroller. The number of IO is now known including any analog sensing for the level probes etc. Lots of micros have analog-digital converters, built in op-amps and comparators etc. I personally use PIC so I'd look at something in the 16F1xxx range. These have lots of real-world interface stuff built-in. Note that a big part of the choice is the support and cost of software to program the things. Microchip is pretty good in this regard with $20 development boards that have full debugging for the free IDE and C compilers but lots of others do, too.

How much memory/speed do you need? Experience counts here but a good rule of thumb is to find a part family that has the peripherals you need and several different sizes of memory. Develop on the biggest one then look at how things are going and buy smaller chips for production. Most uC have more than enough speed for all but the most demanding tasks.

Design the circuit using the various interfaces to the uC. Make a list of what the pins are and the logic values necessary to effect each function. 1=pump on etc.

Wow! Huge post and we haven't written one line of code yet. Yep! Code comes last. But it's easy from here. Each step in the process has been figured out and completely documented. Since it works on paper (it DOES work on paper, yes?) it will work when you code it. Any problems will likely be confined to syntax or a bad translation from design to code. The problems though will be few because you've already designed them out during the pencil-and-paper phase.

That's how it's done.

Good luck!
 
Top