Some six months ago Texas Instruments announced the Evalbot, a development platform for their Stellaris ARM Cortex-M3 microcontrollers in the shape of a little robot. It took me a while to get hold of one, but now I have one driving happily around in my living room. It is actually a pretty neat and cleverly engineered kit that you have to assemble yourself. Most parts are made out of PCB material – the two wheels for instance are each made of three disks and a rubber ring – the rest are mainly nuts & bolts. Two little motors with gears drive the wheels and everything is powered from three AA batteries.
The Evalbot is not a gadget; it is a powerful development board with wheels. In the center off the disk-shaped board sits an LM3S9B92 ARM Cortex-M3 controller (256 KB flash, 96 KB RAM and more peripherals than you will probably ever need) assisted by a tiny 96 x 16 blue OLED display, 6 push-buttons (including the on/reset and the off buttons), an Ethernet connector, a USB host port, a USB device port, a USB debugger/programmer port (ICDI), a micro-SD card connector, a speaker, power supply, JTAG, two LEDs and probably more that I am overlooking now; and two motor drivers. Thanks to the battery holders (with batteries) on the bottom of the board the whole thing is pretty heavy and the rubber “tires” prevent sliding it off your desk when you hook the board up to a computer with a USB cable that wants to unwind the wrong way around.
A special wireless expansion port is available too on which you can plug a CC1101EM sub-1 GHz transceiver, which will get you an 868 or 915 MHz radio link. The James Bond part of this setup is a third kit from TI, the eZ430-Chronos based on the CC430F6137 sub-1 GHz RF SoC. This is a combination of a biggish but stylish black watch with a large character display and a USB access point for your PC. Once connected you can control your PC with the watch, although it takes some exercise to do it properly. But... you can also use the watch to control the Evalbot! An integrated accelerometer lets you influence the driving direction of the robot by tilting and rotating the watch. Cool huh? The watch in itself is actually a dev kit and you can reprogram it with your own application.
Programming the dev kits is done with Code Composer Studio 4, the Eclipse-based dev environment from TI. A license file is included with the Evalbot kit, but what exactly this enables is not clear to me. I did read something somewhere about code sizes & limits, but I forgot where. Anyway, all the source code for the Chronos controlled Evalbot is available, it compiles without warnings and errors and programs fine. This really is a fine (but strange) development kit.
Showing posts with label ARM. Show all posts
Showing posts with label ARM. Show all posts
Wednesday, July 6, 2011
Monday, February 7, 2011
Break the 8/16-bit habit
Most people, including me, like to get stuff for free. Electronic component manufacturers know this and often they offer free samples in the hope that their parts get designed in. Microcontroller manufacturers have started doing design contests and other campaigns to get new users for their products. One of the latests campaigns was launched by NXP for their ARM Cortex-M0 parts.
NXP already did do a design contest (or challenge as they called it) for their LPC1100 parts and now they are giving away LPCXpresso boards that contain a Cortex device. To get one, all you have to do is to show how you plan to stop using 8 and 16-bit devices. You can do this by sending in a picture or a video and if accepted it will be posted here.
Here is the video I sent in.
NXP's website does not mention which LPCXpresso board you will get, but I suppose it will be the board with the LPC1114.
Here are some photos & videos I received in response to this article. Feel free to share your way of breaking the 8/16 bit habit by sending me your photo and/or video and I will put them up here too.
L. Francey prefers to use his obsolete microcontrollers to create arty objects.
Marc will eat anything that has legs.
Jonathan likes Aciiid!
Denis combines his passions for nature and electronics.
NXP already did do a design contest (or challenge as they called it) for their LPC1100 parts and now they are giving away LPCXpresso boards that contain a Cortex device. To get one, all you have to do is to show how you plan to stop using 8 and 16-bit devices. You can do this by sending in a picture or a video and if accepted it will be posted here.
Here is the video I sent in.
NXP's website does not mention which LPCXpresso board you will get, but I suppose it will be the board with the LPC1114.
Here are some photos & videos I received in response to this article. Feel free to share your way of breaking the 8/16 bit habit by sending me your photo and/or video and I will put them up here too.
L. Francey prefers to use his obsolete microcontrollers to create arty objects.
Marc will eat anything that has legs.
Jonathan likes Aciiid!
Denis combines his passions for nature and electronics.
Tuesday, November 23, 2010
PSoC 5 Design Challenge
Here is yet another design contest:
Cypress Semiconductor announced the ARM Cortex-M3/ PSoC 5 Design Challenge, a contest to find the most innovative and useful designs from the millions of possibilities available to designers using the Cypress PSoC 5 architecture powered by the ARM Cortex-M3 processor. The contest is presented in conjunction with EE Times and ARM with the Grand Prize to be awarded in May, 2011. A total of over $10,000 in cash and prizes will be awarded throughout the contest, including the $2,500 Grand Prize. More information, including how to enter the contest and how to become a judge, as well as lively interaction from participants and the engineering community is available here.
Cypress Semiconductor announced the ARM Cortex-M3/ PSoC 5 Design Challenge, a contest to find the most innovative and useful designs from the millions of possibilities available to designers using the Cypress PSoC 5 architecture powered by the ARM Cortex-M3 processor. The contest is presented in conjunction with EE Times and ARM with the Grand Prize to be awarded in May, 2011. A total of over $10,000 in cash and prizes will be awarded throughout the contest, including the $2,500 Grand Prize. More information, including how to enter the contest and how to become a judge, as well as lively interaction from participants and the engineering community is available here.
Sunday, April 18, 2010
Porting code...
...or how to waste lots of time.
Writing portable code is more than just sticking to strict ANSI-C. If you look at the sources of programs or libraries that compile on different platforms, you will find lots of ifdef statements that provide the portability. It is actually pretty difficult to write portable code.
Currently I am into ARM development and I try to target just one OS: mine, on one platform: mine. But I want to use different compilers. I try to write code as portable as possible, without adding compiler specific things, but that just isn’t possible, especially when you target an embedded platform.
Initially I developped some code for GCC. Then I decided that it would be nice if I could use the Keil uVision tools as well. Getting my GCC code to compile with the RealView compiler (used by the uVision tools) was not too difficult, but getting it to work, was.
The problems were caused by, as always, the interrupts. In my code a timer and a UART use interrupts. With the GCC tools both worked fine, with the Keil tools only the UART worked. Uh oh... long debug hours ahead...
I remembered that the GCC code had an interrupt wrapper in the startup code, so all I had to do was to replace the Keil startup code with the GCC startup code. Easier said than done, because it turned out that the Keil assembler did not like the GCC assembly code. This code was definitely not tool-portable (even though the origin of the code clearly was Keil.).
Right, forget about GCC’s special interrupt code, let’s do it the Keil way. I found a Keil timer example that worked on my platform and I copied the code across to my GCC code and … it did not work. I examined the assembler code generated by the compiler for both cases and noticed that the entry and exit code was not the same depending on if the code was integrated in my GCC code or in the Keil example. Yet it was the same C-code, verbatim, since I copied it across, remember?
Or was it?
After stripping down my GCC code (and many hours of hair tearing) I finally discovered that the GCC code had defined away the __irq keyword! Aaargh! So that’s why I didn’t get the right entry and exit code for my ISR!
OK, so I quickly fixed this and now everything would work, right? Wrong!
Obviously there was another problem. My code was now working a bit, but it hung in a delay function. This delay function waited for the timer to reach a certain value before continuing. After some debugging I found that the problem was not so much the delay function itself, but returning from it, it made the program crash. Hmm, that smelled like stack problems.
To make a long story short, the hanging was caused by a function call from within the timer ISR to update a 10 ms timer. After many more debugging I finally found the reason: it was the example code that I had copied! The example proudly mentioned that it handled nested interrupts and I thought that that was mighty fine. But as it turned out, the way the example handled nested interrupts it could not handle function calls from within an ISR... Once the nested interrupts disabled, my Keil code finally worked as my GCC code.
In the end I did not have to make a lot of changes to my original code to port it to a different compiler. It was enough to set the include paths right, define away a GCC __extension__ keyword, add a wint_t typedef, re-allow the __irq keyword and disable nested interrupts, but these last two took me many hours to figure out. At least I now finally understand why the GCC startup code has this special interrupt handling code...
Writing portable code is more than just sticking to strict ANSI-C. If you look at the sources of programs or libraries that compile on different platforms, you will find lots of ifdef statements that provide the portability. It is actually pretty difficult to write portable code.
Currently I am into ARM development and I try to target just one OS: mine, on one platform: mine. But I want to use different compilers. I try to write code as portable as possible, without adding compiler specific things, but that just isn’t possible, especially when you target an embedded platform.
Initially I developped some code for GCC. Then I decided that it would be nice if I could use the Keil uVision tools as well. Getting my GCC code to compile with the RealView compiler (used by the uVision tools) was not too difficult, but getting it to work, was.
The problems were caused by, as always, the interrupts. In my code a timer and a UART use interrupts. With the GCC tools both worked fine, with the Keil tools only the UART worked. Uh oh... long debug hours ahead...
I remembered that the GCC code had an interrupt wrapper in the startup code, so all I had to do was to replace the Keil startup code with the GCC startup code. Easier said than done, because it turned out that the Keil assembler did not like the GCC assembly code. This code was definitely not tool-portable (even though the origin of the code clearly was Keil.).
Right, forget about GCC’s special interrupt code, let’s do it the Keil way. I found a Keil timer example that worked on my platform and I copied the code across to my GCC code and … it did not work. I examined the assembler code generated by the compiler for both cases and noticed that the entry and exit code was not the same depending on if the code was integrated in my GCC code or in the Keil example. Yet it was the same C-code, verbatim, since I copied it across, remember?
Or was it?
After stripping down my GCC code (and many hours of hair tearing) I finally discovered that the GCC code had defined away the __irq keyword! Aaargh! So that’s why I didn’t get the right entry and exit code for my ISR!
OK, so I quickly fixed this and now everything would work, right? Wrong!
Obviously there was another problem. My code was now working a bit, but it hung in a delay function. This delay function waited for the timer to reach a certain value before continuing. After some debugging I found that the problem was not so much the delay function itself, but returning from it, it made the program crash. Hmm, that smelled like stack problems.
To make a long story short, the hanging was caused by a function call from within the timer ISR to update a 10 ms timer. After many more debugging I finally found the reason: it was the example code that I had copied! The example proudly mentioned that it handled nested interrupts and I thought that that was mighty fine. But as it turned out, the way the example handled nested interrupts it could not handle function calls from within an ISR... Once the nested interrupts disabled, my Keil code finally worked as my GCC code.
In the end I did not have to make a lot of changes to my original code to port it to a different compiler. It was enough to set the include paths right, define away a GCC __extension__ keyword, add a wint_t typedef, re-allow the __irq keyword and disable nested interrupts, but these last two took me many hours to figure out. At least I now finally understand why the GCC startup code has this special interrupt handling code...
Friday, March 19, 2010
The InterSceptre
This blog will also be used to inform you about the Sceptre, the open source & hardware ARM7-based 32-bit fast prototyping platform as published in Elektor. In the Pages box on the right of this article you will find a link to a special Sceptre page. All information about updates will be posted there; it is sort of the project’s home page.
The Sceptre is my baby and (for the moment) I do all the development for it. Currently I am working on an extension I/O board on which you can plug a Sceptre so that it can talk to the rest of the world. At the same time my goal is to make this board as universal as possible so that it can also be used with other microcontrollers. Except for its name, InterSceptre, and some component print this I/O board will not be Sceptre specific.
The InterSceptre is due for the June issue of Elektor and I am almost done with the circuit diagram. The board will feature lots of communication interfaces: 2x RS-232, 2x RS-485 (so RS-422 is possible too), MIDI in/out, DMX-512 (OK, that’s just RS-485 with a different connector), a WIZnet module for Internet connection, SPI, PS/2 and I2C. USB is available on the Sceptre itself, but a dedicated USB connector for ISP/serial comms will be on the InterSceptre. I also added a JTAG connector and a 4-way multiplexed DAC (the LPC2148 used on the Sceptre has a 10-bit DAC). To stay flexible the board will have a 25-pin DB connector to give access to the ADC inputs and PWM outputs, and some other GPIO.
All of this can of course (unfortunately) not be used at the same time, but I am confident that it will be useful anyway for many applications.
The universal side of the board is also emphasized by its power supply and it will work with 5V and 3V3 systems. The Sceptre is a 3V3 system but 5V tolerant and I will soon show you how you can use it with a 5V I2C controller.
Contrary to the Sceptre, the InterSceptre will only use easy to solder (change/replace/remove) through-hole parts so mounting it will be possible for anyone capable of holding a soldering iron.
That’s all for now folks, I have a PCB to draw.
The Sceptre is my baby and (for the moment) I do all the development for it. Currently I am working on an extension I/O board on which you can plug a Sceptre so that it can talk to the rest of the world. At the same time my goal is to make this board as universal as possible so that it can also be used with other microcontrollers. Except for its name, InterSceptre, and some component print this I/O board will not be Sceptre specific.
The InterSceptre is due for the June issue of Elektor and I am almost done with the circuit diagram. The board will feature lots of communication interfaces: 2x RS-232, 2x RS-485 (so RS-422 is possible too), MIDI in/out, DMX-512 (OK, that’s just RS-485 with a different connector), a WIZnet module for Internet connection, SPI, PS/2 and I2C. USB is available on the Sceptre itself, but a dedicated USB connector for ISP/serial comms will be on the InterSceptre. I also added a JTAG connector and a 4-way multiplexed DAC (the LPC2148 used on the Sceptre has a 10-bit DAC). To stay flexible the board will have a 25-pin DB connector to give access to the ADC inputs and PWM outputs, and some other GPIO.
All of this can of course (unfortunately) not be used at the same time, but I am confident that it will be useful anyway for many applications.
The universal side of the board is also emphasized by its power supply and it will work with 5V and 3V3 systems. The Sceptre is a 3V3 system but 5V tolerant and I will soon show you how you can use it with a 5V I2C controller.
Contrary to the Sceptre, the InterSceptre will only use easy to solder (change/replace/remove) through-hole parts so mounting it will be possible for anyone capable of holding a soldering iron.
That’s all for now folks, I have a PCB to draw.
Thursday, March 11, 2010
It's a tactile green embedded world
Last week I visited Embedded World 2010 in Nuremberg in Germany. Nuremberg is a nice city with a mediaeval city center and even though I had a hotel room right on the main market place, I did not see much of the town because of the show. The show was pretty big, more than 700 exhibitors spread out over three halls and allthough I spent two full days there, I did not have enough time to see everything.
The main theme of the show was green electronics. Lots of companies showed off green products, low-power boards and microcontrollers. Although low power electronics is very important, there were not many real green novelties. Microamps per megahertz is the most common term now and several manufacturers claim that their products have the lowest number. Unfortunately these numbers are difficult to compare, because one manufacturer talks about a 32-bit controller whereas another is talking about an 8-bit controller. Actually uA/Mhz is not a good measure, it would be better to use something like uA/MIPS or so. Energy Micro, a company that I didn't know before, won the Embedded World award in the category Hardware. Their EFM32 32-bit MCU (ARM Cortex-M3) consumes 180 uA/MHz (running at 32 MHz and 3V).
Another big thing these days is touch technology. In the coming years everything will be tactile, if we can believe the Embedded World exhibitors. Personally I am a bit weary of touch interfaces. At the end of the seventies touch keys were hot too. Being a poor student I had recovered a third-hand color TV with touch keys for the channel selection. These keys were very sensible to weather conditions and my TV changed station randomly, especially when humidity was high or when I really wanted to see something. One day this TV caught spontaneously fire and I finally got rid of it, but that's another story.
Now I have a monitor with touch keys. I also have a cat. It has happened several times that the cat changed the settings of my monitor in a completely random way just by striking the tactile surface of the monitor. I guess I’ll just have to wait until the touch craze has passed before I buy any new kit.
The main theme of the show was green electronics. Lots of companies showed off green products, low-power boards and microcontrollers. Although low power electronics is very important, there were not many real green novelties. Microamps per megahertz is the most common term now and several manufacturers claim that their products have the lowest number. Unfortunately these numbers are difficult to compare, because one manufacturer talks about a 32-bit controller whereas another is talking about an 8-bit controller. Actually uA/Mhz is not a good measure, it would be better to use something like uA/MIPS or so. Energy Micro, a company that I didn't know before, won the Embedded World award in the category Hardware. Their EFM32 32-bit MCU (ARM Cortex-M3) consumes 180 uA/MHz (running at 32 MHz and 3V).
Another big thing these days is touch technology. In the coming years everything will be tactile, if we can believe the Embedded World exhibitors. Personally I am a bit weary of touch interfaces. At the end of the seventies touch keys were hot too. Being a poor student I had recovered a third-hand color TV with touch keys for the channel selection. These keys were very sensible to weather conditions and my TV changed station randomly, especially when humidity was high or when I really wanted to see something. One day this TV caught spontaneously fire and I finally got rid of it, but that's another story.
Now I have a monitor with touch keys. I also have a cat. It has happened several times that the cat changed the settings of my monitor in a completely random way just by striking the tactile surface of the monitor. I guess I’ll just have to wait until the touch craze has passed before I buy any new kit.
Tuesday, February 16, 2010
Become a beta tester and win
It is contest time. I allready mentioned the Luminary, sorry, I mean Stellaris ARM contest from Texas Instruments together with Circuit Cellar and a week later the LPCXpresso ARM contest by NXP. Now it is Freescale who organises a contest. OK, this is not a very difficult contest and you don't have to design anything, but you can win some smart prizes.
To participate you only have to enter the CodeWarrior Development Studio 10.0 beta test program. Free access to the beta release, including full documentation and task-based videos are available for a limited time at www.freescale.com/cwmcu10. CodeWarrior integrates the development tools for the RS08, HCS08 and ColdFire architectures into a single product based on the Eclipse open development platform. Since this is a beta release, it cannot be used for the development of production products. However, you are encouraged to explore the functionality of this new development environment.
To recognize your participation, on April 12, 2010 Freescale will be drawing names from the pool of beta testers for three exciting prize packages:
- Canon Rebel digital single-lens reflex (SLR) camera
- Wii game console by Nintendo
- Garmin handheld GPS
So, go get that 500+ MB download and win that camera!
P.S. You have to submit feedback through a Freescale Service Request to really enter. Alternatively, participants may send an email with name, address (including zip code), home and work telephone numbers (including area codes) to r63076@freescale.com.
To participate you only have to enter the CodeWarrior Development Studio 10.0 beta test program. Free access to the beta release, including full documentation and task-based videos are available for a limited time at www.freescale.com/cwmcu10. CodeWarrior integrates the development tools for the RS08, HCS08 and ColdFire architectures into a single product based on the Eclipse open development platform. Since this is a beta release, it cannot be used for the development of production products. However, you are encouraged to explore the functionality of this new development environment.
To recognize your participation, on April 12, 2010 Freescale will be drawing names from the pool of beta testers for three exciting prize packages:
- Canon Rebel digital single-lens reflex (SLR) camera
- Wii game console by Nintendo
- Garmin handheld GPS
So, go get that 500+ MB download and win that camera!
P.S. You have to submit feedback through a Freescale Service Request to really enter. Alternatively, participants may send an email with name, address (including zip code), home and work telephone numbers (including area codes) to r63076@freescale.com.
Sunday, February 7, 2010
LPCXpresso design contest
Last week I received two LPCXpresso boards designed by Embedded Artists for evaluation. An LPCXpresso board is a small but longish 35 by 140 mm board split in two parts. One part has an ARM Cortex (M0 or M3) processor from NXP (LPC1114 or LPC1343) on it, together with a 12 MHz crystal and a small prototyping area. The other part of the board is the LPC-Link, which is a real JTAG programmer/debugger. This part is a sort of detachable JTAG pod and if you cut the connections between the two rows of JTAG connector pads you can connect it to other compatible hardware, your own ARM board for instance.
Why is this interesting? Well, first of all because of the price, since Embedded Artists sells it for only 20 euros. This means that you can get yourself a JTAG debugger for a very good price.
Then there are the development tools (Windows only, but should also work on virtual platforms with USB support on other operating systems). The boards are supported by a free enhanced Eclipse-based IDE developed by Code Red. This software lets you compile programs of unlimited size, but program and debug only up to 128 KB. The NXP web site has a list of compatible processors which is unfortunately missing the LPC2148, but according to NXP it should work with unlisted controllers too, as long as you respect the 128 KB limit. I have yet see this as the IDE does not allow picking an incompatible controller and an LPC2142 is not an LPC2148.
LPCXpresso LPC1114 together with an mbed module and the mbed pin-out card. Everything on the left of the pin-out card is the LPC-link JTAG pod.
Note that the LPCXpresso is pin compatible with an mbed board. That may seem strange as an mbed module only has 40 pins whereas an LPCXpresso has 54, but pin 1 to 20 and pin 28 to 47 of the LPCXpresso module have (where possible) the same functionality as the mbed pins. One problem though, the mbed processors (LPC1768 and LPC2368) are not supported by the LPCXpresso IDE. I have been told though that a Cortex-M0 mbed is coming soon.
Also interesting is that NXP has launched a design contest. Anyone entering a valid design concept before the 8th of March 2010 will receive a free LPCXpresso development kit and then has about one month to actually build it and show that it works. Check out all the details here.
Why is this interesting? Well, first of all because of the price, since Embedded Artists sells it for only 20 euros. This means that you can get yourself a JTAG debugger for a very good price.
Then there are the development tools (Windows only, but should also work on virtual platforms with USB support on other operating systems). The boards are supported by a free enhanced Eclipse-based IDE developed by Code Red. This software lets you compile programs of unlimited size, but program and debug only up to 128 KB. The NXP web site has a list of compatible processors which is unfortunately missing the LPC2148, but according to NXP it should work with unlisted controllers too, as long as you respect the 128 KB limit. I have yet see this as the IDE does not allow picking an incompatible controller and an LPC2142 is not an LPC2148.
LPCXpresso LPC1114 together with an mbed module and the mbed pin-out card. Everything on the left of the pin-out card is the LPC-link JTAG pod.
Note that the LPCXpresso is pin compatible with an mbed board. That may seem strange as an mbed module only has 40 pins whereas an LPCXpresso has 54, but pin 1 to 20 and pin 28 to 47 of the LPCXpresso module have (where possible) the same functionality as the mbed pins. One problem though, the mbed processors (LPC1768 and LPC2368) are not supported by the LPCXpresso IDE. I have been told though that a Cortex-M0 mbed is coming soon.
Also interesting is that NXP has launched a design contest. Anyone entering a valid design concept before the 8th of March 2010 will receive a free LPCXpresso development kit and then has about one month to actually build it and show that it works. Check out all the details here.
Thursday, January 28, 2010
Will the new Bill Gates please stand up?
Circuit Cellar together with Texas Instruments have launched a design contest around the Stellaris LM3S9B96 microcontroller. This 100 pin controller is based on a 32-bit ARM Cortex–M3 core with 256 KB flash memory, 96 KB RAM and it sports many interesting features like CAN, USB 2.0 OTG/Host/Device, 10/100 Ethernet MAC and PHY, I2C, I2S, SSI, UART, PWM, ADC and some other peripherals. Although this is more or less what you would expect from a modern 32-bit microcontroller, it is not all: the device also has a built-in library with almost 400 functions to access its peripherals. This BIOS (Basic Input Output System) provides a nice hardware abstraction layer for almost all of the registers and makes life of the programmer much easier.
To top thing off, the device also has a built in real time operating system (RTOS)! According to the datasheet the controller has a copy of SafeRTOS inside, a secure version of FreeRTOS edited by Wittenstein. Unfortunately, the datasheet isn’t very verbose about it, but it is there.
Now what do you call a processor with peripherals, a BIOS and an operating system? A computer! Indeed, this microcontroller is pretty much like a computer on a chip (CoC) and the only thing missing is a graphical interface, but that is probably just a matter of time and/or pin count.
Are we entering a new era of microcontrollers? Will this be the new standard architecture for the next generation of microcontrollers? What about code portability? Will the user get access to the source code of the built-in BIOS and RTOS? Will ARM, TI & Wittenstein be the next Intel, AMD and Microsoft?
At the end of 2008 I assisted at an ARM conference in Paris. The buzz word then was "code portability". If only everybody would be using ARM-based processors, then code would be easily portable from one device to another. Luminary, the developper and former owner of the Stellaris processors, was present too. But is the BIOS & RTOS they now put in their devices good for code portability? Will other ARM-based microcontroller manufacturers too integrate a compatible BIOS & RTOS in their devices or provide compatible libraries? Or are we going to have to deal with tens of different BIOS-es and RTOS-es in the future, supported by code bloating tests to figure out what the heck the platform actually used is capable off?
Devices will get bigger and will integrate more and more. Within a couple of years they will be as powerfull as a modern PC is now, with built-in BIOS and OS. This all smells so much of Microsoft and the OS wars from the past years.
NOOOOOOOoooo!!!!!
Please, not again!
To top thing off, the device also has a built in real time operating system (RTOS)! According to the datasheet the controller has a copy of SafeRTOS inside, a secure version of FreeRTOS edited by Wittenstein. Unfortunately, the datasheet isn’t very verbose about it, but it is there.
Now what do you call a processor with peripherals, a BIOS and an operating system? A computer! Indeed, this microcontroller is pretty much like a computer on a chip (CoC) and the only thing missing is a graphical interface, but that is probably just a matter of time and/or pin count.
Are we entering a new era of microcontrollers? Will this be the new standard architecture for the next generation of microcontrollers? What about code portability? Will the user get access to the source code of the built-in BIOS and RTOS? Will ARM, TI & Wittenstein be the next Intel, AMD and Microsoft?
At the end of 2008 I assisted at an ARM conference in Paris. The buzz word then was "code portability". If only everybody would be using ARM-based processors, then code would be easily portable from one device to another. Luminary, the developper and former owner of the Stellaris processors, was present too. But is the BIOS & RTOS they now put in their devices good for code portability? Will other ARM-based microcontroller manufacturers too integrate a compatible BIOS & RTOS in their devices or provide compatible libraries? Or are we going to have to deal with tens of different BIOS-es and RTOS-es in the future, supported by code bloating tests to figure out what the heck the platform actually used is capable off?
Devices will get bigger and will integrate more and more. Within a couple of years they will be as powerfull as a modern PC is now, with built-in BIOS and OS. This all smells so much of Microsoft and the OS wars from the past years.
NOOOOOOOoooo!!!!!
Please, not again!
Wednesday, December 30, 2009
Do you know MIPS?
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!
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!
Subscribe to:
Posts (Atom)
