Incredible power of the micro controller

Every now and then i sit back and consider what i have done with a micro controller. Then i tend to search around the internet looking to see what others are doing. Needless to say i don't find many interesting projects.  It is all the same bull shit over and over again. One guy used the same chip i am using and managed to get a serial pass through lcd driver on it. 

This is almost depressing. Seriously, if this is what i have to look forward to in peers - i'm going to start looking behind me.

What a waste of a precious micro controller. Seriously people- wake up.

One of my projects which is a DIY spot welder requires a controller. It can be found here I fit the lcd driver, debug terminal(serial), joystick driver, string library, and menu subsystem on the chip. With applications and debug code i only used ~80% of the chip. The chip is an attiny2313 that weighs in at 2k program and 128 bytes of sram.

All of my code is written in avr assembler. I can give the best of the C programmers a run for their money in terms of speed of development, refactoring, and final binary size. 

This leads me into another compliant to most of the micro controller developers. What the hell is up with your drivers? If you want to see some lousy code -check out the code these people crank out. They use so called portable language (C) and end up beating the code into a state which renders it impossible to port.  I little suggestion to all you people who love to cite how portable your language is in comparison to assembly. Write truly portable code first and then make your argument. Until then keep your language and your blown out the ass practices to yourself. Just because you can flash an LED does not make you a programmer.

How about this for a test run I can move any of my drivers I/O to any pin on the device which can support the drivers cause. For example i can move any pin of any driver around and simple tell my code base the new pin definition, rebuild and call it magic - it works. All of that and it only takes one statement for every I/O pin that needs moved. Nothing else need be meddled.

Bang for a buck.

Bang for a buck is down right old school. Or is it?

This is a pretty strait forward way to convey a simple but very complicated performance analysis. But what is it that is being citing in the claim "More bang for your buck". 

Microcontroller can be classified several different ways, among those the more common are:

1) Data bus width

2)Program addressing space and type(Rom,Eprom,Eeprom,Flash,Mram)

3)Data addressing space and type

4)CPU speed

5)Number and type of integrated peripherals

6)Power requirements

7) Price

8)Development tools

9)Hardware(electrical,mechanical,environmental)

10) Device maturity status and availability

This is no where near a comprehensive list but I believe most people will agree that this covers the majority of the factoring when determining a cost analysis. In fact those ten classifications could fill dozens of well written text books.

In the abstract it can be argued that "bang for a buck" is a performance gauge. But a performance of what? Surely this can not be used to predict the products performance so what is it that we are attempting to measure here? This is a very difficult question indeed. Perhaps we are attempting to quantify potential in the abstract. In this case it becomes evident that we are dealing with a problem of relation. This is in itself another problem. We can not make this a simple problem of relation between microcontroller and programmer. There are many other factors at play that must be address. Starting with the hardware. In order to achieve a high "bang for buck" figure it is found that the electrical, mechanical, and environmental characteristics must be of convenient terms. After all if the hardware engineer has to spend two years interfacing the microcontroller it is not likely to have a high "bang for a buck" ratio regardless of how attractive the other terms may be. The same holds true for the software side of the problem. At this point we still can not get an accurate gauge of what "bang for a buck" represents. Programmers do not magically conjure up software and teleport it to the chip. Development tools must be used in order to achieve such a goal. The development tools alone can make or break a project. With this I come to the conclusion that "bang for a buck" is a standard assumption that the acquirer is very experienced in the given terminology.

In this case "bang for buck" gauging works both ways.  For the experienced, a high "bang for buck" ratio is a positive number. For the in-experienced, this number will be negative. To me this seems to be common sense. The problem with common sense is that it is not that common.Thus the reason for this blog.  We will compare both sides of this argument.

First we will begin with the experienced side of the argument. The experienced hardware engineer has come to terms with a given manufacturers electrical, mechanical, and environmental characteristics. Everything is second nature to the engineer and projects zip through like the well oiled machine. The programmer, who has taken a liking to the given manufacturers choices of instructions and development tools - feels quite comfortable developing applications on the given device. The programmer has already been through all the woes of the tool chain and can solve most any problem without the blink of an eye.  This management wise tale gets even better.  Suppose the manufacturer develops a device that supersedes their previous product line. This new device is 100% backward compatible, contains ten fold the features of every term and costs half the price. Obviously this team has just hit the rhetorical lottery. 

Now we assume the worst position imaginable. Perhaps that of a start up who has just hired a complete team right off the university press. The entire teams combined project experience is perhaps half a year standard industry work time. This start up is very intrigued about the given manufacturers incredible new product line. They surely hit the rhetorical lottery. As do they buy into the device portfolio and set out to become the next high technology leader. Not long into the project problem begin to arise. The hardware is very strange and the company must invest in additional test equipment and consults in the field. The programmers are already weeks behind schedule when the first design spin rolls off the press. They aggressively work to meet their project deadline but subtle problems consistently stop the development as they attempt to understand this new technology. The development tool has its own problems which can only be managed with time. At some point the programmers manage to get their code onto the chip but it is not functioning properly. The problem is eventually traced back to a hardware issue known in the chip since the first silicon die and the hardware engineer is forced to revised the board. The small start up has already incurred great costs and they still have not met their initial goals. This story is a common story because it holds true for many start-ups.  Also understand that this start up was doomed from the beginning i had set them up for failure to accentuate the negatives of a high "bang for buck" The reality of this is that a start-up with properly management could in fact succeed even with a high "bang for buck" ratio. However, they could do so with far less resources should they stay in their element.

From this you may be able to make your own inferences.

An industry of greed and hype

From the beginning a powerful suggestion is at lay that technology be a very profitable line of work. There is a severe imbalance in that profit outweighs product. There is a very strong push to get products into the market. In more cases than not these products are not finished. Here the context of the word "finished" must be expanded upon. Classically, we tend to think that a finished product is in itself complete. This expansion requires particular attention be applied to the word "complete".  Complete, lacking nothing. It can be argued that a complete product would have passed QC, QA before making it to the market. Well products certainly do not meet these classic definitions today. Notice that I refer to these definitions as "classic". This is because the industry has found clever ways of redefining words for the sake of profit. In order to redefine a word we must first have the means to do so.  Lets put this idea to the side for the time being as we will come back to it later. I will shift to responsibility now.

Most of us have an uncanny sense of responsibility. Perhaps best found in a parking lot of many cars. If you were to open up your car door and damage the neighboring car there is an uncanny sense of responsibility. The method of which we as individuals address this is very different from the industry. We as individuals have learned to use euphemisms to lesson the feeling of responsibility. We call this an accident. Though most of us have a decent set of morals and thus we neglect our euphemism and tend to take direct responsibility.The industry has also learned to use euphemisms to shift the point of responsibility. The difference here is that the industry as an entity does not have morals. The industry will undergo a great deal to dodge responsibility. An example of this can be found in the use of the word contention. Contention is now used to describe yet another euphemism which is violation. Now we must consider what violation has been used to replace. Further studies here reveal the word illegal. Being the social beings we are I should hope we all understand the word illegal.  With this concept in mind I continue with my thoughts on the clever use of words for profit.  

At this point I need to use these concepts in an example. So let us assume that the industry has produced a product and this product has been used by manufacturers in various other products. Not long after the product reaches the market a serious problem is found with reliability.The industry finds the problem to be isolated in interface of the CPU block and the static ram block. Further study shows that there is an illegal hold time on the data bus during a data read cycle. The industry succeeded in finding the problem but this problem creates a larger problem. The problem lies deep inside a piece of silicon wafer. The only way to correct this problem is issue a silicon revision and start another batch of wafers. Now the industry has two problems. The first and foremost problem being that they have 1.000,000 devices that are junk. The second problem is that they have 1,000,000 junk wafers which must make a profit if the industry is to show profit. At some point a decision is made to market the product anyway. A rather clever product errata sheet is published which explains the known problems of the product. The errata sheet states that under very specific conditions the device may experience bus contention and may enter an undefined operating mode. 

In order to sell all these junk products the industry corrects the internal budgets and applies focus to marketing and special interest groups. The media sells the hype from the printing press through the radio. Special interest groups have ventured interests and manipulate standard drafts to ensure the product be used in all new products.

We as a people have come to use euphemisms everywhere.  People are now "consumers". After all it is easier to come to terms with: 1,000,000 consumers bought junk rather than 1,000,000 people bought junk. The clever people in risk analysis have learned that a marginal percentage of these people will be upset that the product does not function properly. They have also learned that even a smaller percentage of these people will complain. Depending on the budget and profit margins there may be yet another probability understanding that given percentage of these people who are complaining will receive product replacement or reimbursement. The elaboration still continues in that demographics dictate who will receive services.

It is not to be suggested that this corruption is intentional in the fundamental use. I believe this to be a direct attribute of greed. It is well known that our industry can produce very reliable products that yield respectful profits. Another problem of greed starts earlier in our lives. It is commonly suggested that we find a line of work that will make us rich. This may be the majority contributor to the problems in the industry. We have people who hold engineering titles but are not engineers. We have people who develop software but are not programmers. The problem continues until one finds a true engineer, a true programmer. I can not put a concise definition on the "true" aspect of any profession. Do not confuse this with a common misconception that there is no difference.  This is the likely argument of the para-type. The difference is in that of the uncanny sense. A member of the true nature will exhibit deep passion, motivation, and interest in their line of work. This will be quite evident as it saturates all who come in contact with the individual. Those of the par-type will be rather dull.

In final analysis we can attribute quite a few problems to the creators of technology who are not interested in that technology. This really is a shame since the ultimate price is paid by the people who use the technology. Everyone has paid this price at one time or another. Whether by some miniscule inconvenience or near catastrophe. The problems can be greatly reduced by simply doing what you enjoy, assuming adequate responsibility, and avoiding greed.

Ofcourse this line of reasoning does not fit well with current economic practices.  Maybe it is time things change.