You probably have heard about ARM processors. ARM seems to be everywhere and we are flooded by press announcements about new ARM-based products. This might make you think that ARM is currently the most successful processor around, especially if we think about 32 bit processors. But did you know that there exists another 32 bit processor for embedded applications? Well, yes, of course, there are other 32 bit microcontrollers that are not ARM, but there is one particular brand that you probably have as a brain for at least one of your electronic gadgets: the MIPS processor.
Like ARM, MIPS Technologies does not make silicon, but only so-called soft cores, a piece of software that describes a processor core. To use a soft core you have to licence it and put it in a chip yourself. There are many MIPS cores, not only 32 bit but also 64 bit, and there are many companies that use one of those in their products. To name a few (in random order): Sony, Realtek, Broadcom, Pioneer, Motorola, Cisco, Microchip, Hewlett-Packard, Philips, Toshiba, Canon, Samsung, JVC, Pentax, Casio, Minolta, NEC, Fujifilm, Ikanos, etc., etc. That is quite an impressive list for a processor that we hardly ever hear about, isn't it?
As you can see from the list of MIPS users, these are all big well-known companies that make many types of consumer products, which explains why you probably own at least one MIPS processor. Digital camera's, network routers, Wi-Fi access points, DSL modems, printers, netbooks, digital photo frames, DVD players, GPS receivers, game consoles and even cars, many of them contain a MIPS core. Unlike ARM, MIPS Technologies does not make a lot of noise, yet their products are everywhere.
But there is one major product in which you will not likely find a MIPS: the mobile phone. This market is almost completely dominated by ARM, but MIPS is hoping to get in thanks to Google's Android, the open source smart phone operating system. Android, developed for ARM processors, is a platform that current MIPS users might want to use too, so MIPS Technologies started porting it to their products. And then, with a bit of luck, MIPS users will start building smart phones with MIPS cores.
For the electronics hobbyist the easiest way to get started with MIPS is probably to buy a PIC32 processor from Microchip. The PIC32 is based on the MIPS32 M4K family and according to Microchip they perform better than an ARM7 clocked at 100 MHz.
If you look hard enough you can also find single board computers with MIPS processors and run for instance Linux-MIPS on it. Or hack a router and play with OpenWRT.
Share your MIPS experiences!
Wednesday, December 30, 2009
Friday, December 18, 2009
Take the time to learn your system
I’ve always been fascinated by microcontroller systems and the process of making them come to life.
It all starts by designing the system, a controller with some peripheral hardware. Once I finally have a prototype of my design the first thing I do is to see if I can talk to the processor. This is always an exciting moment. Will it respond? Will it program?
I prepare a small hello-world type of program and try to load it into the controller (or in its external memory, depending on what I am working on). Suppose all went well and the controller accepted the program (what a deception if it didn’t). Usually the hello-world program is flawed and doesn’t work as intended. Maybe I was too brave and tried to put too much in it, maybe I didn’t understand some functionality? I modify the program and try again, but still nothing. So I hook up the oscilloscope and start probing around. Aha! found a signal, but on the wrong pin. Back to the code, locate the bug this time and now the hello-world program works. Great! Little by little I start adding functions to the code, first to test the peripherals and then to get fancy. And then suddenly it all stops working…
Oops. Now what exactly did I change the last time? Ehmm…
So I start taking bits of code out, but that doesn’t help. I remove more, change this and that, decide that some parts could be coded more elegantly and I end up spending many hours coding without much success.
And then, as suddenly as it stopped working, the program starts working again. Hallelujah! From this moment on, I know from experience, it will never stop working again. No matter what I do, the program will run. There will be a bug every once in a while, but I know I will fix it quickly and I just can’t seem to mess it up anymore. My baby is alive! I master the system without really knowing what went wrong, where and why. Now my prototype can and will grow into a fully functional system.
Fascinating, isn’t it? No? Oh well, I guess you had to be there.
So what’s the point? Well, the fact that I spend many hours fiddling around trying to figure out what and why made me into an expert. The experience gained from debugging and rewriting code helped me understand my system. Since this has happened often to me, I now know that I have to go through this phase to be able to finish the job.
So don’t despair when you can’t find out why your system doesn’t work. Keep patient. You will get there if you are willing to spend the time to learn your system. Once you are the expert, your system will listen to you and obey.
Do you recognise any of this? Let me know how you work, how do you learn your system? Please share your experiences.
It all starts by designing the system, a controller with some peripheral hardware. Once I finally have a prototype of my design the first thing I do is to see if I can talk to the processor. This is always an exciting moment. Will it respond? Will it program?
I prepare a small hello-world type of program and try to load it into the controller (or in its external memory, depending on what I am working on). Suppose all went well and the controller accepted the program (what a deception if it didn’t). Usually the hello-world program is flawed and doesn’t work as intended. Maybe I was too brave and tried to put too much in it, maybe I didn’t understand some functionality? I modify the program and try again, but still nothing. So I hook up the oscilloscope and start probing around. Aha! found a signal, but on the wrong pin. Back to the code, locate the bug this time and now the hello-world program works. Great! Little by little I start adding functions to the code, first to test the peripherals and then to get fancy. And then suddenly it all stops working…
Oops. Now what exactly did I change the last time? Ehmm…
So I start taking bits of code out, but that doesn’t help. I remove more, change this and that, decide that some parts could be coded more elegantly and I end up spending many hours coding without much success.
And then, as suddenly as it stopped working, the program starts working again. Hallelujah! From this moment on, I know from experience, it will never stop working again. No matter what I do, the program will run. There will be a bug every once in a while, but I know I will fix it quickly and I just can’t seem to mess it up anymore. My baby is alive! I master the system without really knowing what went wrong, where and why. Now my prototype can and will grow into a fully functional system.
Fascinating, isn’t it? No? Oh well, I guess you had to be there.
So what’s the point? Well, the fact that I spend many hours fiddling around trying to figure out what and why made me into an expert. The experience gained from debugging and rewriting code helped me understand my system. Since this has happened often to me, I now know that I have to go through this phase to be able to finish the job.
So don’t despair when you can’t find out why your system doesn’t work. Keep patient. You will get there if you are willing to spend the time to learn your system. Once you are the expert, your system will listen to you and obey.
Do you recognise any of this? Let me know how you work, how do you learn your system? Please share your experiences.
Labels:
debugging,
embedded,
learning,
microcontroller,
system
Thursday, December 10, 2009
And the winner is…
Last week I did a small survey of microcontroller preferences. Although I had an idea what to expect, there were some surprises in the responses. First of all I received much more reactions than I had hoped for. I would like to say thank you very much to all of you who took the time and effort to reply to this survey! The people that posted a reply (in English!) directly to the blog will find it added to my original post. Those that sent me an email, well, I am very sorry, I am not going to add them all to this blog as there were way, way too many. However, I did spend a few hours reading all the messages and a summary follows here.
What we all want to know now is of course: who won?
But before I will tell you, you will have to read through the following advertisement.
Just joking: the winner is… AVR! Yes, the AVRs received 43% of the votes, while the PIC family lagged behind with 35%. The rest of the votes went to other families of which the MSP430 and the Propeller were mentioned quite often. 8051/2 clones are also reasonably popular.
The main reason for the AVR domination was the available tools. Although free tools exist for many microcontrollers, BASCOM for AVR was mentioned several times and also Arduino. Now this survey originated at Elektor and was read mostly by Elektor readers, so it is biased as Elektor has published quite some projects using BASCOM-AVR, but in general it was felt that the free tools (BASCOM is free only for small executables) for AVR are better than those for PIC. Also the AVR seems to be more easily available and cheaper than a PIC (even more so since Microchip restricted their sampling program), especially important outside the US and Western Europe.
In favour of the PIC was the abundant documentation, examples and free libraries. It is true that Microchip puts a lot of effort in that. On a pure technical level, some people felt that the PIC is less sensitive to noise than the AVR.
Other processors were of course mentioned, but as the survey mainly spoke about PIC and AVR, most people restricted themselves to these two families. However, as stated by several people, if the MSP430 would exist in more DIP packages (only the smallest ones are available in DIP packages), they would definitely prefer it over both PIC and AVR. Surprisingly to me the Propeller from Parallax was mentioned a few times too. Personally I think of this processor more as a sort of freak processor and I would not easily invest time and money in it. Maybe the future proves me wrong, what do I know?
Several people liked the Stellaris, now from TI, others love Freescale.
What is very clear from all the responses and which didn’t surprise me much: architectural reasons clearly do not dominate the choice of a controller family. Once people have learned to use a certain microcontroller family and have invested in tools, they are not very likely to switch to another family from another manufacturer just for the fun of it.
So, my next question is: what does it take to make you switch to a competing microcontroller?
What we all want to know now is of course: who won?
But before I will tell you, you will have to read through the following advertisement.
Just joking: the winner is… AVR! Yes, the AVRs received 43% of the votes, while the PIC family lagged behind with 35%. The rest of the votes went to other families of which the MSP430 and the Propeller were mentioned quite often. 8051/2 clones are also reasonably popular.
The main reason for the AVR domination was the available tools. Although free tools exist for many microcontrollers, BASCOM for AVR was mentioned several times and also Arduino. Now this survey originated at Elektor and was read mostly by Elektor readers, so it is biased as Elektor has published quite some projects using BASCOM-AVR, but in general it was felt that the free tools (BASCOM is free only for small executables) for AVR are better than those for PIC. Also the AVR seems to be more easily available and cheaper than a PIC (even more so since Microchip restricted their sampling program), especially important outside the US and Western Europe.
In favour of the PIC was the abundant documentation, examples and free libraries. It is true that Microchip puts a lot of effort in that. On a pure technical level, some people felt that the PIC is less sensitive to noise than the AVR.
Other processors were of course mentioned, but as the survey mainly spoke about PIC and AVR, most people restricted themselves to these two families. However, as stated by several people, if the MSP430 would exist in more DIP packages (only the smallest ones are available in DIP packages), they would definitely prefer it over both PIC and AVR. Surprisingly to me the Propeller from Parallax was mentioned a few times too. Personally I think of this processor more as a sort of freak processor and I would not easily invest time and money in it. Maybe the future proves me wrong, what do I know?
Several people liked the Stellaris, now from TI, others love Freescale.
What is very clear from all the responses and which didn’t surprise me much: architectural reasons clearly do not dominate the choice of a controller family. Once people have learned to use a certain microcontroller family and have invested in tools, they are not very likely to switch to another family from another manufacturer just for the fun of it.
So, my next question is: what does it take to make you switch to a competing microcontroller?
Subscribe to:
Posts (Atom)