electrodesigns.net

Open Source Software vs Open Source Hardware

In the field of open source software, a community develops new program or makes addition to an existing program. Similarly, this type of approach is also used in open source hardware. But the difference between the open source software and hardware is that the development of software is free of cost, while in case of hardware, the physical developments are not easy and require some sort of investment.

Economic Advantages

• Open way of Product Development without Market Research: Open source hardware approach also helps to know about the customer’s needs and preferences without any market research. Consumers of specific product show their interest in a product and also indicate that what type of new product they want. For example their demands is 10 mega pixel cameras with zoom in and zoom out functions similarly Wi-Fi connectivity in a mobile etc. provides information about consumers demands and expectation about mobile devices. We have seen different innovative ideas through this channel. This type information and ideas enables companies in providing of best marketable products. This is also playing a vital role in products development. (continue reading…)

It’s always challenging for us to manage embedded projects when we have small resources. The key to do it is to choose what to do when and our experience is here to rescue us out of difficult situations. The procedure in this post is for typical microcontroller based projects with little to average complexity. This scheme assumes that you have at least some experience with such projects and you have at least one relevant hardware development kit or a previously designed hardware which has some features common with your new project. It’s not about soldering DIP-only components on veroboard rather its a professional way for relatively experienced designers. Off-course there may be better ways to execute such a project. You can suggest if you like.

• Designs your hardware: Normally we work on development kits. If you are using a reference design, which normally happens and is a standard practice now a days, try to design around it. In this way you are basically re-using the effort made by the vendor to bring up something working. It will save lots of development time. Adjust the hardware according to your special needs. This may be the schematic change, components packages change, or perhaps one or two extra peripherals addition. When you are done and satisfied with the hardware, send it to the PCB fab. The PCB fab takes its time. (continue reading…)

One of my previous post was about the advantages of open source hardware and its possible model. However, there are situations where open source hardware is not a very good idea.

• Small companies which can not produce something in big quantities hence can not compete in price
• You need money to run your business and do not have extra cash to put into open source hardware and have no time to wait for the community to come and help you run your business
• The design is for a specific customer who does not want to disclose his IP (intellectual property)
• The situation where the open source hardware can clearly be used for wrong-doing. Anything which is clearly going to hurt somebody must be discouraged
• You have tough competition and opening up the IP will drag you out of competition

Though it is possible to keep some designs open while the other closed, companies tagged with open source usually keep all of their designs open. However, striking right balance between open and close is necessary to serve techno-society as well as keeping the customers satisfied.

Open source hardware model

The open source hardware initiative is very interesting because open source, in most of the cases, means something for free as free lunch without any royalty or earning. This is especially interesting because unlike software, where one usually needs to donate time and effort only, here you need to spend considerable money to bring-up a working prototype. There are several things, however, which make this logic practical:

• Today there is bundle of CAD tools which help to simulate hardware before going to fab. Tools like Altium have everything built-in from PCB design to FPGA design to firmware development. There are also some cheap alternatives available like Diptrace or Eagle, though with a subset of functionality. This reduces risk of repetitive prototyping and saves time and money.
• It is possible that initial effort of design be shared to open source community and let somebody else develop the actual hardware. Like some of the designs on this website which have not been tested by building a working prototype but at least they provide a very good ground for starting a product development from something which is valuable and can save lots of time, especially, for the beginners like young electronic engineers.
• The people who use the open source hardware design to build their gadget are very important because they are the ones who actually debug the hardware. These are typically called application engineers who design for service providers. Their feedback is extremely important. Feedback plays very important role which open source community uses in the improvement of a design. The feedback also helps to get new ideas popped up and hence new designs and expansion in open source base.
• Though the hardware may be free, the components like ICs, capacitors, inductors are never free. The people who manufacture these parts must support the open source hardware initiatives. Infact many companies like Coocox, Adafruit, Sparkfun and alike work on the very same idea. Look at the success of Beagle board; it could not have been possible without the support of TI and Digikey. After all who spent probably hundreds of thousands of dollars to bring down the price of Beagle board with so many hefty features? Coocox site tries to depict the actual open source cycle which is a win-win situation for everyone, the chip manufactures, the open source hardware developer, the hobbyist or application engineer, the solution provider company that hires this application engineer and, not to forget, the consumer or end-user.

Why not the application engineer designs directly from the reference design of chip manufacturer? Basically this is what widely happens and it is happening right from the beginning. But open source hardware has some advantages which this conventional model does not offer. Like the product standardization is lot easier and natural as lots of people use the same design or the derived ones from the same hardware. The end product is more likely to bug free as larger number of people build and test and report the bugs. The end product design life-cycle drastically reduces as the application engineer utilizes pre-tested open source hardware components. The hobbyists and young engineers just entering this field greatly benefit by having lots of free stuff available to play with. And sky is the limit.

Often we come up to the situations where our newly design prototype is not working or malfunctioning. This situation becomes more interesting when hardware and software guys are working together on their respective parts of a  design.

Often our embedded boards are resource-limited and they doing something unexpected. Recently one of my software colleague was sending printing information to a handheld printer. My job was to translate the information on TCP to serial port through a small hardware designed by me. Everything was working on my side but when his data arrived, the printer could not print it properly. When I used to send the data through a little TCP client application running on my PC, the printer worked fine. Suddenly a thought flashed in my mind.  I had experienced such situation earlier when I was receiving a response from a remote TCP server which my TCP client could not understand properly. This time the situation was different but the problem seemed to me the same limited buffer space in my microcontroller’s tiny RAM. I told the software guy to send data with little time delays. The printer worked correctly this time. The reason was TCP port is a fast port and the serial port is a slow port, much slower than Ethernet. My embedded device’s buffer overflown before it could serve the previous packet. This has not been for the first time with me. In the early days of my professional life, I used to complain more. But experience has taught me to always remember “check yourself first”. So in the world of embedded systems, always be ready for something unexpected. And the fault usually lies within our designs.

Before complaining to the software guy, make sure that everything is working fine at your end. There are hardware, software debugging and sniffing tools available which greatly help to investigate the problem. For example if you are communicating on TCP, use Wireshark or similar tools to sniff the data and see if it follows desired packet structure. Similar are tools like TCP Toolkit for TCP, COMPort Toolkit for serial port and many other useful tools. Take advantage of free online tools to verify your design and only after then call your colleague to look into the matter.

Embedded systems is a very interesting field which needs to deal with software as well as hardware at the same time. To write proper software it is necessary to understand the underlying hardware. Also software knowledge is a must to actually perform useful tasks. Often software engineers only write the software for embedded devices which we call firmware. They do it because they are taught and trained to do so. On the other hand, hardware or electronics engineers are more inclined towards the “hardware” which include analog and digital circuit design, PCB design, troubleshooting, hardware installation and support. Writing code is not their primary job as taught in university courses. However, they have a great advantage over software engineers that they understand the hardware architecture better. They know how the processor has to interact with the analog circuitry and how it will affect the overall performance. Often there are things that can be done either through hardware or software. For example an application requires a trigger over a certain voltage input. Now is it feasible to use a fixed voltage comparator in the hardware or to read the analog value and define the threshold in the software? Only a person familiar with the actual analog signal and its behavior can decide what to do. That is why electronic engineers with strong firmware/software skills are preferred.

However, sometimes hardware skills are relatively irrelevant; for instance embedded Linux development. In this case software engineers have clear advantage as the very knowledge of every register and flag bits is not necessary. However, as I learned through my experience, if you are learning embedded Linux for the first time, it does not make you very different from the software guys as even they come up to a newer field except somebody is a Linux guru. An electronics engineer still has great chance to learn Linux during his course of career.

As the time is passing by, more and more products carry intelligence deeply embedded in them. Small, low-cost, power efficient microcontrollers are widely used to make things smarter. Every household product carries a small electronics running a little RTOS or pseudo code carrying that “little intelligence” to make them so. Therefore electronics engineers with strong background of hardware development must also invest some time and effort to learn writing firmware and should master C language as it is de-facto standard in embedded world. I remember when I was at University and used to pay special attention to the my C language course. This was because I liked coding. This effort paid me back in my professional career as I have been coding in C for more than seven years now. All in all, embedded systems is a great career for electronics engineers. However, they need to pay special attention to firmware as well as getting familiar with embedded Linux.

In the world of embedded systems designing, there are some main design objectives which are desired by client as well as design house. These are almost universal:

• The design meets the user requirements
• The end-product is low-cost
• Minimum time in development process
• Minimum development cost

To meet these requirements in current competitive environment, the designer must be smart enough. There are several techniques which effectively reduce time and cost of development while managing to fulfill all user requirements.

1. Lock the requirements before starting the design: carefully read-out the exact client requirements. It often happens that non-technical managers take the requirements from client and pass on to the designer. When the designer comes up with the final prototype, he comes to know that client was looking for something else, huh! This has happened to me several times. So if management doesn’t mind, try to interact with the client at the very early stage of project to get the exact picture.
2. Re-use previous designs: Try to reuse what you already have and used in other designs. You better know the pros and cons of your previous designs and try to the best options you have. This may include schematic parts, the components and layout libraries etc.
3. Use available and tested firmware components: Often firmware libraries are available for every vendor of main MCU that you are going to use. If there are no exclusive requirements otherwise, use the available code. It is tested and trusted.
4. At least initial design should be on a tested hardware:  This may be a development kit or a PCB of previous design (Keep the royalty thing in mind haan..). Now a days, demo kits are cheap, tailor-able to some extent and have some great features. If you don’t have kit(s), you can also take help from reference design of the vendor. Every vendor has ref-designs of almost all hot topic in industry. Like Zigbee is a hot field today and every vendor like TI, Atmel, Microchip etc. have their demo boards and firmware stacks to download and develop upon.

There may be other things besides mentioned above, what is your experience?

Although modern day technologies have now converged practically into embedded systems still there are people among us who still question what an embedded system is?

The field of embedded systems is a unique combination of softwar and hardware where the whole intelligence of the system is confined into the firmware of hardware residing indide hardware itself. Now what is firmware? Firmware is the software or intelligence portion of the systems which resides in the hardware, takes directions from hardware peripherals, processes  information, takes decisions and issues control signals to actuate outputs. The formost effrot in designing embedded systems is to reduce the physical footprint of the system to fit it into the space and weight constrained applications. Another design goal is to keep the cost as low as possible. The advantage of embedding the intelligence into the small hardware is to make efficient and cost effective systems, basically, to make small ordinary things much more smarter than before.

The example of embedded systems are everywhere which we use on daily bases like cell phones, the control in washing machine, tv and tv remote etc. One distinctive difference between general purpose computers and embedded computers is that they are application specific. Also the embedded systens are “all in one” systems based on small computer, peripherals, sensors, indicators, actuators and everything necessary to carryout a specific task, to fulfil a certain objective.

Becuase of their nature, the embedded systems designers must understand both software as well as hardware. only electronics engineer can not design good embeded systems and a software-only guy is incompatible with this field. There are two models of job models followed by companies mainly based on their resources. The large companies have specialist of hardware and software so the engineers need not to design everything. This does not mean that they don’t need to be familiar with each other’s domain as they need to coordinate with each other constantly and regularly. In small companies, the same guy has to do everything. the hardware as well as the firmware (embedded software). Also there are many other things which need to done like casing designs or at least considerable effort in determining the right enclosure of the product and its overall shape.

All in all embedded systems is an interesting field but it is demanding at the same time.