标签: microcontroller

I'm currently performing my Happy Dance (stop laughing, it's not my fault I caper and cavort this way) because the Simblee by RF Digital officially launched about a week ago.   Just to set the scene, let's remind ourselves that, a few years ago, the folks at RF Digital created a fingertip-sized, wireless-enabled, Arduino-compatible microcontroller called the RFduino .   (Source: RF Digital)   The RFdunio is supported by an ecosystem of plug-in shields, including Switch/LED, Relay, Servo, microSD, USB, Prototyping, and Power/Battery shields (all of these shields also work with the Simblee breakout boards discussed below).   Now we have the Simblee module, which is 10mm x 7mm x 2mm in size, and which contains two main functions: A 32-bit ARM Cortex-M0 processor (with 128KB of Flash and 24KB of RAM running at 16MHz) and a Bluetooth Smart engine.   (Source: RF Digital)   If you are creating commercial or industrial products from the ground up, then you will almost certainly decide to mount Simblee modules directly on your circuit boards. By comparison, when it comes to prototyping or hobbyist applications, you may find it more advantageous to use one of the Simblee breakout boards. There are currently two such boards; one offers seven GPIO (general-purpose input/output) pins while the other provides 29 GPIOs.   (Source: Max Maxfield/Embedded.com)   Each of these breakout boards has a Simblee module (shown in the upper-right-hand corners of the boards in the photograph above) along with 0.1" pitch headers on top for connecting shields, and 0.1" pitch pins on the bottom for plugging into breadboards or soldering to printed circuit boards.   (Source: Max Maxfield/Embedded.com)   One point that may be confusing at first is that the 29-GPIO board appears to boast 31 GPIOs numbered 0 through 30. Closer examination, however, reveals that GPIOs 26 and 27 are not exposed (they are used internally), and are therefore not available to the end user.   Now, I love Arduinos -- I use them for all sorts of things, but I have to say that it can be a bit of pain remembering which pins can act as digital inputs and outputs, which can act as analog inputs, which can act as pseudo-analog (PWM) outputs, which are dedicated to acting as a UART, which can be used as an SPI bus, which can be used as an I2C bus, and so on and so forth.   In the case of the Simblee, GPIOs 1 through 6 can act as analog inputs, and all of the GPIOs can act as digital inputs and outputs or pseudo-analog (PWM) outputs. Furthermore, any of the GPIOs can be configured to act as UART, SPI, or I2C signals. Suddenly, my life just got a whole lot easier.   Creating User Interfaces for Smartphones and Tablets A Simblee module or breakout board can be programmed using the Arduino IDE and used as a standalone microcontroller. In this case, the Simblee can be visualized as being "Just another flavor of Arduino with a different footprint or form factor."   Where the Simblee really comes into its own is when we start controlling it using a smartphone or tablet computer. This is probably a good time to mention that the term SimbleeForMobile encompasses any software, tools, and applications used to control Simblee-enabled devices using a mobile platform such as a smartphone or tablet. Now, this next part can be a bit tricky to wrap your brain around, so take a deep breath and I'll try to be gentle.   As I just mentioned, users create sketches (programs) to run on their Simblees using the Arduino Integrated Development Environment (IDE). The thing is that these sketches can include user interfaces (UIs), which can be displayed on the user's smartphone or tablet, and which can be used to monitor the Simblee's inputs and control its outputs.   We'll talk about how we create a Simblee user interface shortly. For the moment, let's just say that both your application and your user interface are loaded into your Simblee module (that little 10mm x 7mm x 2mm beauty we introduced earlier).   Next, you download a free Simblee app onto your smartphone or tablet. If you are using an Apple platform running the iOS operating system, you will download the Simblee For Mobile app from the Apple's App Store; if you are using an Android platform, you will download the Simblee For Mobile app from Google Play (formally known as the Google Play Store or the Android Market).   When you launch the Simblee app on your mobile platform, it uses Bluetooth to announce itself to the surrounding world and ask if any Simblee-enabled devices are in the vicinity. When each of those devices replies "I'm here," the Simblee app lists their names and descriptions on the screen (from the perspective of the user, this process is essentially instantaneous). Once the user taps the desired item on the screen, the Simblee app sends a message to that device saying "You're up" ; the device then uploads its user interface to the Simblee app, which renders it as a graphical user interface (GUI) on the screen. Due to the way in which this works, the Simblee app may also be thought of as being a Simblee Browser or a Simblee Renderer.   Now, I have to say that when I first heard about creating a user interface with the Arduino IDE, I was a bit puzzled -- I really couldn’t see how this could be achieved -- but once you get the idea, you say "Wow! That's Brilliant! (Why didn’t I think of that?)"   Let's start by reminding ourselves that A simple Arduino sketch includes two functions called setup() and loop() as illustrated below:   void setup() { // Put your setup code here, to run once } void loop() { // Put your main code here, to run repeatedly } Well, a simple SimbleeForMobile sketch contains four functions (also, we include the SimbleeForMobile library). In addition to the traditional setup() and loop() functions, we also have the ui() and ui_event() functions as illustrated below:   #include void setup() { // Put your setup code here, to run once } void loop() { // Put your main code here, to run repeatedly } void ui() { // Put your user interface code here } void ui_event(event_t event) { // Put your event-related code here } The ui() function is where the majority of the SimbleeForMobile User Interface (UI) is defined in textual format. For example, we might call a function (from the SimbleeForMobile library) that says "Draw a switch at this XY location on the screen and make its On-color green," and so on for other objects like buttons, sliders, and so forth. This is the interface that will be uploaded to the mobile platform, where it will be rendered (presented) as a Graphical User Interface (GUI).   The ui_event() function provides the callback mechanism by which the GUI on the mobile platform can communicate any actions back into the body of the sketch. We might think of this as acting a bit like an interrupt service routine (ISR). When the user performs some action on the mobile platform's screen, the system communicates this information back to a function in the Simblee Library. In turn, this function calls the ui_event() function in our sketch.   Each graphical object we instantiate is automatically assigned its own unique identifier (ID). The ui_event() function supports a single parameter of type event_t, which is defined in the Simblee Library. The parameter itself is the address of a structure, which contains all sorts of information, including the ID of the object being affected, the type of event, the value associated with the object, and so forth.   There's so much to talk about here, but I think we'll leave that for another column. In the meantime, let's look at a real-world example...   A real-world example As I've mentioned on occasion, I'm involved in a Cunning Chronograph competition. My entry is coming along in leaps and bounds, but I ran into a problem because I'm experimenting with lots of different effects.   (Source: Max Maxfield/Embedded.com)   One solution is to hard-code an effect I want to play with into the sketch, and then compile this and upload it into the Chronograph, but this is painful and time-consuming. Another option is to define a set of digital pins as being of type INPUT_PULLUP, and to then use flying leads to pull them down to 0V as required. This is the technique I was using for a long time... until the Simblee came along.   (Source: Max Maxfield/Embedded.com)   Remembering that the Simblee contains a 32-bit Cortex-M0 processor along with its Bluetooth Smart engine, the majority of users will almost certainly use the Simblee as a standalone solution to monitor and control things. In my case, however, I already have everything running on an Arduino Mega. Furthermore, my Cunning Chronograph is based on NeoPixels, whose critical timing is controlled using assembly code for the Arduino's Atmel processor. Thus, in this case, I simply used my Simblee to replace my hard-wired controls as illustrated below.   (Source: Max Maxfield/Embedded.com)   Now I can use my iPad to control my Simblee, which -- in turn -- controls my Arduino. The best way to wrap your brain around this is to see it in action, so I just uploaded this video for your delectation and delight.   When I first conceived my BADASS Display , I thought it would be a good idea to locate the control panel at the bottom of the main front panel. This was a decision I've come to regret because I have to keep on bending down to swap effects. Now I can add a Simblee to mirror the actions of the control panel on my iPad's screen, so I can configure the display from the embrace of my comfy chair. The bottom line is that I'm planning on sticking Simblees in all of my hobby projects. I love these things!

About a week or so ago, Max (the Magnificent) and I were talking about the electronic projects we are currently working on and comparing them to the ones we did when we were kids. I happened to mention one project that I created when I was 10 years old. This project made my dad so proud that he showed it to all his friends. When Max heard about it, he asked me to write it up to share it with other members of the EETimes community, so here we go...   This all happened back in 1965. Perhaps the best way to start is to describe what my project did and how it appeared to outside observers. First, there was a small cardboard box with holes in it that looked like a microphone. This was mounted on the wall next to the closed door of my bedroom. When I walked up to this box and said "open" into it, the door quickly opened and I stepped into the room. I then turned around and faced the people outside the room as the door closed slowly behind me.   Now, given that this was 49 years ago when there were no microcontrollers and such, and given the simple and inexpensive components that were available to the average 10 year old at that time, can you figure out how this was achieved? When you've pondered this for a while, continue to the next page for a detailed explanation. Take a look at the drawing below. The system involved nails, screw-eyes, both heavy and thin rubber bands, string, thumb tacks, paperclips, wire, paper, cardboard, D-size batteries, a permanent magnet, and tape.     Opening the door For the part that opens the door, heavy rubber bands were strung together with one end tied to a paper clip and the other end tied to the doorknob inside the room.   The bedroom had an interior wall that was against the hinged side of the door and also perpendicular to it, and this is where a headless nail went. This nail was placed into the wall near the floor at an angle that pointed up to where the knob would be when the door was fully open.   The paperclip at the end of the heavy rubber bands was slipped over this nail. With the door closed, the paperclip griped the nail due to the steep angle of the bands. As the door opened, however, the angle of the bands increased to the point where the paperclip slipped off the nail, thereby stopping the bands from pulling.   Closing the door The next step was to make the door close. At the top of the door was another string of very thin rubber bands. Using thumb tacks, one end of this string was attached to the top of the door, the other end was attached to the door jam. This band was much weaker than the opening-band, thereby giving the door a much slower closing speed.   Latching the door Now onto the door latch. Two screw eyes were installed adjacent to the door striker plate. These held a nail that was used to keep the door closed. Having a string tied around its head, the nail slid inside the screw eyes such that when the string was tugged, the nail moved so as to release the door.   The other end of the string was tied to a permanent magnet, which served to tug the string whenever the magnet fell. In order to get the magnet to fall when I wanted it to, I needed it to stick to something and then release as required.   The solution was an electromagnet, which I constructed using wire wrapped around a nail. In the absence of any current flowing through the electromagnet's coil, the magnet stuck to the nail inside the electromagnet. The electromagnet's orientation was such that, when it was activated, its north pole faced the north pole of the permanent magnet.   Thus, activating the electromagnet repelled the permanent magnet causing it to fall, thereby pulling the nail out of the two screw eyes. Once the nail had been pulled out of the two screw eyes, the heavy rubber bands would cause the door to open as described earlier.   The master control switch Powering the electromagnet was two D batteries taped in series, with wires also taped on to the ends. To finish out the design, there was a rather clever switch to turn it all on. This switch was made out of cardboard, fine wire, a thumb tack, a paperclip, some paper, and some tape.   A very fine wire was made by stripping down one strand of a bundle, which was then connected to a paperclip and taped to a small piece of paper, thereby forming one contact of a switch. The use of fine wire was required to keep the weight of the wire low and to keep the paper flexible.   The other contact of the switch was just a thumb tack, which was pushed into the wall where the paperclip could bang up against it. A piece of cardboard was used as a spacer to hold the paper away from the wall, thereby providing an air gap for the open contacts.   To finish the switch, a cardboard box with air holes was placed over it for looks. The switch worked because the letter 'P' in the word "Open" provided a puff of air that blew the paper such that the paperclip and thumb tack contacted each other.   So there you have it. Saying "Open" into the box caused the contacts to close, which caused the permanent magnet to fall, which pulled the string, which slid the nail out of the screw eyes to release the door. At this point the heavy rubber bands caused the door to open quickly. When the door was fully open, the heavy bands were released, thereby allowing the thin bands to slowly pull the door closed.   The final challenge One pretty bad operating gotcha to all this is that my brother would have to be inside the room to get it set up for the demo. I never got around to designing a way to get it set up from outside the room, partly because my dad didn't want me to mess the room up too much and partly because it would have gotten way more complicated.   Would you care to take up the challenge? Remembering that I was only 10 at the time, and keeping in mind the limitations in technology available to me, do you have any ideas as to how I could have arranged things so this system could be set up from outside the room?   Ivan Cowie Chief Engineer MaxVision

So you just completed your most recent Arduino project and are hungry to build something new and impressive. Feeling confined by the Arduino's limited environment, peripherals, and power, you begin looking around for other options, but there are too many choices. There are microcontrollers from dozens of vendors in eight-, 16-, and 32-bit flavors, each requiring its own compilers and programmers, which could add up to a fortune. Is there no cheap and viable alternative for the little blue board that has stolen all our hearts?   Enter the ARM Cortex M series of 32-bit microcontrollers. They offer a common tool chain and core design across multiple vendors. There are many ways to access the Cortex M series, from MCU vendor dev boards with built-in proprietary debuggers to professional-grade open dev boards . The open approach is the way to go.   Using vendors' proprietary dev boards will feel more like using an Arduino. The boards often come with compilers that will work only for their chips. Sometimes they even have code size restrictions. Access to the full capability of 32 bits comes from selecting a tool chain that is limitless. I won't discuss tool chain choices in this blog, except to say a nonproprietary one provides many advantages over an Arduino or similar development environment.   The most obvious thing you gain when moving up from Arduino is the power of a Cortex M. A 32-bit processor outperforms an eight-bit one running at the same speed and is often less expensive. The larger devices can also run faster. Cortex M0s, for instance, run at higher speeds than any PIC or AVR I have worked with. The 16/32-bit blend of instructions the Cortex uses also leads to a higher code density -- fitting more code into less space. With the increased processing power comes a slightly less obvious advantage: lower power consumption. Using a "hurry up and wait" strategy yields a much longer battery life, as can be seen from this video on the new Kinesis line. Though getting the Arduino up and running is simple, one major flaw is that it has no debug environment. A good ARM tool chain will allow you to stop the core when you like and find out the state of the processor. There's no more printing variables to the serial port. You just halt the processor and look directly at whatever variable or register you want.   Choosing the Cortex M series also gives you access to variety. A good tool chain will allow you to code for everything from simple entry-level devices all the way to dual-core signal-processing monsters .   All these advantages come with some downside, especially for hobbyists. Except for the upcoming LPC1114s, which will be available in SOIC and DIP packing, almost every Cortex M is either a leaded (QFP) or leadless (QFN) package. These packages make hand soldering extremely difficult, and they make direct breadboarding with the chips impossible. Additionally, if you get stuck at any point during a project, it is generally much harder to find help, because the community for these chips is much smaller. With some experience, it is very possible to take the code from other projects and port it over, but this technique is certainly not as simple as the plug-and-play friendliness of the Arduino.   This leads to the final disadvantage of moving to 32 bits: the time required to learn a new environment. With respect to coding, the switch from eight to 32 bits is not that noticeable as long as you are coding in C or C++. The difficulty lies in the switch from the finely polished Arduino libraries to the dirty but extremely powerful CMSIS libraries. Instead of spending time browsing the Arduino Reference website, you will most likely be combing through 500-plus-page user manuals looking up registers and what they do. This may sound daunting at first, but once you realize how much more control you gain from this, you may feel like programming with an Arduino is like taking a shower in a raincoat.   Making the move up to the Cortex M series is a serious undertaking, and it is certainly not for every hobbyist or every project. In my experience, I've gone from Arduino to PIC to Cortex Ms, and I have never looked back. When a new idea pops up, I am confident there is a chip available that will fit the bill perfectly, whether it's for a simple LED blinker or a complex USB audio player.   What can a move to 32 bits do for you?   Brian Carriegan Electrical engineer Picatinny Arsenal US Army  

If you are an 80s kid in the United States, you undoubtedly remember a toy called "Teddy Ruxpin." Your feelings of this bear likely range from fondness, such as happy memories of it "reading" you a story; dread, possibly fear; or curiosity about how it worked. Maybe you even felt some envy at the time if you didn't have one, likely replaced years later by curiosity about what made you want one.   Nearly 30 years later, you might again think upon that doll and realise that with modern microcontrollers, like the Arduino, this doll could be made into something different and debatably better than what it was originally intended for. Fortunately, if you'd like to start tearing into one, you can build on the excellent work of others. Mechanically, the bear is extremely simple, using one servo to control both the eyes and the mouth. Although I haven't personally disassembled one, I would guess that here is a mechanical linkage (possibly a cam) that keeps the eyes open while the servo travels through a certain range. This would allow it to actuate the mouth to "read" the story while the eyes stare creepily ahead until the servo was fully lowered. To get to the electronic goodies, you'll have to remove a flap on the back of the bear's shirt. The tape player then needs to be removed to get to the three servo wires inside the bear's body cavity. There are also two apparent power wired in this space, but if you're going to replace its centrally-located "brain" with your own controller, these likely won't be needed. There are some more pictures on wgz.org that help illustrate what is needed here. The other three wires can then be hooked up to your own controller solution for whatever mischief you'd like to cause with it. An Arduino, Raspberry Pi, or even a pyMCU come to mind. This article on Ars Technica uses an Arduino as a method for a computer to "possess" the bear, and sync up mouth movements with the Windows voice synthesiser. If one wanted to go even further, a Raspberry Pi would seem like an idea candidate for a stand-alone system. Going even further, I'd love to see one with servos embedded in the shoulders to allow for some crude arm movement, or maybe something to actuate the eyes. LEDs might be an even better solution to allow them to glow at opportune times. Of course, that doesn't even get into the possibility of using some sort of sensors for feedback. Maybe a passive infrared sensor could be used to surprise unsuspecting passers-by. It's not too early to think about your Halloween display this year! Taking a different tack, maybe you'd rather see 80 of them talking in sequence . Maybe a Bluetooth or WiFi connection could be used for something similar if a stand-alone system was devised. It seems like a strange thing for kids to want today, but it was the best selling toy of 1985-1986. On the other hand, maybe I just don't possess or understand the psychology of a 5-year-old anymore. This is probably a good thing. Finally, if you're wondering what a "Teddy Ruxpin" is, or just want a reminder, check out this YouTube channel for a sampling of what this little animatronic bear is all about . Jeremy Cook is a manufacturing engineer with 10 years experience and has a BSME from Clemson University.  

I get tired of hearing from people who have little or no idea of what it takes to bring an innovative idea or product concept to market reality—and I refer mostly to those facile, glib, smooth-talking pundits and politicians out there. Somehow, they are always alluding to some great idea—"magic bullet" and "silver bullet" seems to be the phrase in vogue—which will cut through the clutter and take us directly to a quick solution to some unpleasant problem, and with just a few small details to clean up along the way. While there are many times when a very good or brilliant idea is a real game-changer, making that idea into a workable solution is rarely easy or straightforward as they make it sound. I was reminded of the reality when I met at the recent Design West event with Raman Sharma of Energy Micro AS, about their extremely low-power EFM32 Gecko microcontroller. Besides the energy-usage data he showed me, what caught my attention was his clear exposition of the multiple tactics used to squeeze and squeeze the power/energy consumption further down. (I am sure that other vendors have used some or many of these ideas, but it was instructive to see them all called out in one clear listing by Raman.) In addition to an inherently low-power semiconductor process—that's a "given" for sure—the device uses a combination of topological and operational techniques; sometimes these are called "tricks" but I think that term is dismissive and demeaning. These included: - Low active-power consumption, of course - Minimizing time in any active mode - Very fast wake-up time - Ultra-low standby current - Autonomous peripheral (timers, ADC) operation, to avoid the need for the CPU intervention - Direct signaling between peripherals, again without the CPU - Multiple energy-usage modes - Low power I/O peripherals - ADC and associated support elements can function while CPU is sleeping - Development tools which allow the designer to observe and thus fine-tune energy use It's an old story, but often glossed over: even genuine magic-bullet ideas need fierce, relentless attention to detail, plus working though all the first-, second-, and even third-order problems, to be successful. Consider the steps between the Bell Labs germanium point-contact transistor of 1948 and eventual unbelievably high-volume, pennies-each discrete component we now have, or the first IC and how it became what it is today. Or, for a more bounded lesson, you can carefully study Jim Williams' 1976 EDN article on the high-accuracy scale he built for the MIT Nutrition Lab, "This 30-ppm proves that analog designs aren't dead yet") where he systematically identified, understood, and minimized the many subtle error sources. Have you ever been caught in the "here's the magic bullet—the rest should be no big deal" trap? Was it naively set by you? Or for you, but by others?ÿ