iWave Demos Xen Virtualization on its I.MX8QM-Based Module

iWave Systems has announced that it has successfully demonstrated the Xen virtualization hypervisor on their i.MX8 QM SoC based System on Module. The SMARC R2.0 compatible SOM is based on the i.MX8 QuadMax SoC. The SoC is comprised of 2x Arm Cortex-A72  cores at 1.8 GHz and 4x Arm Cortex-A53 cores at 1.2 GHz and 2x additional Cortex-M4F cores at 266 MHz.

On the i.MX8 QM, iWave has implemented the virtualization of hardware using the open-source type 1 Xen hypervisor. The Xen hypervisor enables multiple virtual machines to be created over a single hardware resource, each virtual machine capable of running its independent operating system. This enables i.MX8 QM SOM (shown) to run multiple operating systems concurrently on the same physical board. The Xen hypervisor allows maximum utilization of resources thereby improving overall system performance and efficiency.
Xen is an open-source type-1 hypervisor developed by the University of Cambridge and is now being developed by the Linux Foundation. Xen runs directly on the hardware to manage guest operating systems. Hence, it’s also considered as a bare-metal hypervisor. Xen has less overhead enabling faster performance and operating systems are more secure because they don’t rely on base OS for installing the hypervisor.

A system running the Xen hypervisor contains three components:

  • Xen Hypervisor
  • Domain 0 (Dom0) – Privileged virtual machine running on the hypervisor that can access the hardware directly and interact with other unprivileged virtual machines running on the system.
  • Multiple Domain U (DomU) – Unprivileged virtual machine running on the hypervisor and have no direct access to the hardware (e.g. CPU, memory, timer, and interrupts cannot be directly accessed)

During the initial system start-up, Xen hypervisor launches the Dom0 that runs the Linux operating system. The Dom0 has unique privileges to access the Xen hypervisor compared to other Domains. Dom0 manages the DomU, the unprivileged domains running on the system. Dom0 allocates and maps hardware resources for the DomU domains.

The solution has the follow advantages:

  • Less overhead compared to type-2 hypervisors since type-1 hypervisors make use of ARM virtualization extensions.
  • Having faulty/buggy OS in the DOM-U domain will not disrupt the functionalities of DOM-0 OS.
  • DOM-U driver domains can support legacy hardware drivers no longer supported by the new OS.
  • Have completely isolated workspaces with different requirements. For example: gaming and multimedia.
  • Better resource management since resources rarely used will not be powered on if the domain it belongs to is not booted.

In iWave’s Xen Demo on i.MX8QM Board, the DOM-0 OS runs Linux 4.9.88 from eMMC and DOM-U runs Android Oreo 8.1 from USB drives. Such a system can be used where there is a need for both faster, highly reliable OS (such as Linux) and more multi-featured slightly slower OS (such as Android) to be running on the same hardware.

iWave Systems | www.iwavesystems.com

 

Guitar Video Game Uses PIC32

Realism Revamp

While music-playing video games are fun, their user interfaces tend to leave a lot to be desired. Learn how these two Cornell students designed and built a musical video game that’s interfaced using a custom-built wireless guitar controller. The game is run on a Microchip PIC32 MCU and has a TFT LCD display to show notes that move across the screen toward a strum region.

By Jake Podell and Jonah Wexler

While many popular video games involve playing a musical instrument, the controllers used by the player are not the greatest. These controllers are often made of cheap plastic, and poorly reflect the feeling of playing the real instrument. We have created a fun and competitive musical video game, which is interfaced with using a custom-built wireless guitar controller (Figure 1 and Figure 2). The motivation for the project was to experiment with video game interfaces that simulate the real-world objects that inspired them.

Figure 1
Front of the guitar controller. Note the strings and plectrum.

Figure 2
Back of the guitar controller

The video game is run on a Microchip PIC32 microcontroller [1]. We use a thin-film-transistor LCD display (TFT) to display notes that move across the screen toward a strum region. The user plays notes on a wireless mock guitar, which is built with carbon-impregnated elastic as strings and a conducting plectrum for the guitar pick. The game program running on the PIC32 produces guitar plucks and undertones of the song, while keeping track of the user’s score. The guitar is connected to an Arduino Uno and Bluetooth control center, which communicates wirelessly to the PIC32.

The controller was designed to simulate the natural motion of playing a guitar as closely as possible. We broke down that motion on a real guitar into two parts. First, users select the sound they want to play by holding the appropriate strings down. Second, the users play the sound by strumming the strings. To have a controller that resembled a real guitar, we wanted to abide by those two intuitive motions.

Fret & Strum Circuits

At the top of the guitar controller is the fret board. This is where the users can select the sounds they want to play. Throughout the system, the sound is represented as a nibble (4 bits), so we use 4 strings to select the sound.

Each string works as an active-low push-button. The strings are made of carbon-impregnated elastic, which feels and moves like elastic but is also conductive. Each string was wrapped in 30-gauge copper wire, to ensure solid contact with any conductive surfaces. The strings are each connected to screws that run through the fret board and connect the strings to the fret circuit (Figure 3).

Figure 3
Complete controller circuit schematic (on guitar).

The purpose of the fret circuit is to detect changes in voltage across four lines. Each line is branched off a power rail and connected across a string to an input pin on an Arduino Uno. Current runs from the power rail across each string to its respective input pin, which reads a HIGH signal. To detect a push on the string, we grounded the surface into which the string is pushed. By wrapping the fret board in a grounded conductive pad and pushing the string into the fret board, we are able to ground our signal before it can reach the input pin. When this occurs, the associated pin reads a LOW signal, which is interpreted as a press of the string by our system.

Along with the fret circuit, we needed a way to detect strums. The strum circuit is similar in its use of a copper-wrapped, carbon-impregnated elastic string. The string is connected through the fret board to an input pin on the Arduino, but is not powered. Without any external contact, the pin reads LOW. When voltage is applied to the string, the pin reads HIGH, detecting the strum. To mimic the strumming motion most accurately, we used a guitar pick to apply the voltage to the string. The pick is wrapped in a conductive material (aluminum foil), which is connected to the power rail. Contact of the pick applies voltage to the string, which on a rising edge denotes a strum.

Figure 4
Shown here is a block diagram of the controller signals.

As shown in Figure 4, the direct user interface for the player is the guitar controller. The physical interaction with the guitar is converted to an encoded signal by an Arduino mounted to the back of the guitar. The Arduino Uno polls for a signal that denotes a strum, and then reads the strum pattern across the four strings. The signal is sent over USB serial to a Bluetooth control station, which uses a Python script to broadcast the signal to an Adafruit Bluetooth LE module. The laptop that we used as a Bluetooth control station established a link between the controller and the Bluetooth receiver, and was paramount to the debugging and testing of our system. Finally, the Bluetooth module communicated over UART with the PIC, which interpreted the user’s signal in the context of the game [2].  …

Read the full article in the March 344 issue of Circuit Cellar
(Full article word count: 3271 words; Figure count: 10 Figures.)

Watch the project video here:

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

MCU Family Serves Up Ultra-Low Power Functionality

STMicroelectronics has released its STM32L0x0 Value Line microcontrollers that provide an additional, low-cost entry point to the STM32L0 series The MCUs embed the Arm Cortex -M0+ core. With up to 128 KB flash memory, 20 KB SRAM and 512 byte true embedded EEPROM on-chip the MCUs save external components to cut down on board space and BOM cost. In addition to price-sensitive and space-constrained consumer devices such as fitness trackers, computer or gaming accessories and remotes, the new STM32L0x0 Value Line MCUs are well suited for personal medical devices, industrial sensors, and IoT devices such as building controls, weather stations, smart locks, smoke detectors or fire alarms.
The devices leverage ST’s power-saving low-leakage process technology and device features such as a low-power UART, low-power timer, 41µA 10 ksample/s ADC and wake-up from power saving in as little as 5µs. Designers can use these devices to achieve goals such as extending battery runtime without sacrificing product features, increasing wireless mobility, or endowing devices like smart meters or IoT sensors with up to 10-year battery-life leveraging the ultra-frugal 670 nA power-down current with RTC and RAM retention.

The Keil MDK-ARM professional IDE supports STM32L0x0 devices free of charge, and the STM32CubeMX configuration-code generator provides easy-to-use design analysis including a power-consumption calculator. A compatible Nucleo-64 development board (NUCLEO-L010RB) with Hardware Abstraction Layer (HAL) library is already available, to facilitate fast project startup.

The STM32L0x0 Value Line comprises six new parts, giving a choice of 16- KB, 64- KB, or 128- KB of flash memory, 128-byte, 256-byte or 512-byte EEPROM, and various package options. In addition, pin-compatibility with the full STM32 family of more than 800 part numbers offering a wide variety of core performance and integrated features, allows design flexibility and future scalability, with the freedom to leverage existing investment in code, documentation and tools.

STM32L0x0 Value Line microcontrollers are in production now, priced from $0.44 with 16-KB of flash memory and 128-byte EEPROM, for orders of 10,000 pieces. The unit price starting at $0.32 is available for high-volume orders.

STMicroelectronics| www.st.com

Robotics & Intelligent Gaming

When Alessandro Giacomel discovered Arduino in 2009, he quickly became hooked. Since then, he’s been designing “little robots” around Ardunio and blogging about his work and findings. In this interview, Alessandro tells us about his most interesting projects and shares his thoughts on the future of robotics, 3-D printing, and more.

CIRCUIT CELLAR: How long have you been designing embedded systems and what sparked your interest

ALESSANDRO: I have been designing embedded systems for about five years. My interest arose from the possibility of building robots. When I was a kid, I found robots extremely fascinating. The ability to force matter to do something we decided always seemed to be one of the main goals conceded to man.

CIRCUIT CELLAR: Tell us about your first design.

ALESSANDRO: My first embedded system was an Arduino 2009. The availability of a huge shield, sensors, and actuators has enabled me to design many applications at an acceptable price for an amateur like me.

DIYrobot

Alessandro’s first robot

I started like many people, with a robot on wheels moving around avoiding obstacles. It’s a standard robot that almost all beginners build. It’s simple because it is built with only a few components and a standard Arduino 2009. The design included modified servomotors that can rotate 360° moving the robot and connected to the wheels and a servomotor to move a little head where there is an ultrasonic distance sensor. The distance sensor lets you know when the robot is in front of an obstacle and helps you decide the most convenient way for the robot to escape.

In its simplicity, this robot enables one to understand the basics for the development of a microcontroller-based robot: the need to have separate power supplies for the motors’ power circuits and for the microcontroller’s logic, the need to have precise sensor reading timing, and the importance of having efficient algorithms to ensure that the robot moves in the desired mode.

My first robot took me a long time to build. But all the elements of the robot (hardware and software) were developed by me and this was important because it let me begin to face the real problems that arise when you are building a robot. Today there are many resources on the Internet that enable one to build a robot simply replicating a set of steps anyone has described. These guides should be used as a source of inspiration, never followed exactly step-by-step, otherwise—while in the end it is true that you can build a robot—you don’t own the knowledge of what has been done.

My robot evolved with the ability to speak, thanks to a sound module. When I build a robot the goal is always to experiment with a technology and to have fun. My friends have enjoyed seeing the robot turning around, speaking, and telling funny stories.

CIRCUIT CELLAR: Your blog, Robottini (http://robottini.altervista.org), is described as “little robots with Arduino.” What inspired you to begin the blog

ALESSANDRO: I strongly believe in sharing knowledge and open-source hardware and software. I thought it was normal to try to share what I was designing when I started to build robots. When I started, I had the benefit of what others had made and published on the Internet. I thought about writing a blog in my language, Italian, but I thought also it would be a good exercise for me to try to write in English and, most importantly, this enabled me to reach a much wider audience.

The site description includes the philosophy at the basis of the blog: small robots built using Arduino. I build small robots because I’m an amateur and my house isn’t very big, so I only build robots that I can put in an armoire. I use Arduino because it is a microcontroller developed in Italy, it was obvious for me to use it, and it is really a great board for a beginner—inexpensive and robust.

ArduinoRobot

Alessandro’s first robot at the Arduino Day 2011 event

The community has developed thousands of applications that can be reused. When I started the blog in 2011, I was building small robots for a few years. In the beginning, finding information was much more complicated and there were few shields that were not cheap. So, I always tried to use “poor” materials (e.g., recovered or recycled). Decreasing the cost of implementation and reusing and imagining new purposes for the things already available in a normal house seemed like a good way to work.

My achievements documented in the blog are never step-by-step guides to build the robot. I include a list of components to buy, the source code, and sometimes the wiring diagram. But I never provide a complete guide, since I think everyone should try to build their own robot because, once built, the satisfaction is enormous.

Through my blog I am available to help with problems people encounter when they are building robots, but I think it is important to give people the tools to build, rather than providing detailed explanations. Everyone can learn only by fighting the difficulties, without having someone preparing everything perfectly.

CIRCUIT CELLAR: Robottini obviously includes quite a few robotics projects. Why did you build them? Do you have a favorite?

ALESSANDRO: Many times people ask me what is the meaning of the robots I build. The answer that I give them leaves people puzzled. The answer is this: My robots are useless. They are useful only as fun—as a passion. I’m happy when I see my little son, Stefano, who is three years old, watching and laughing at a robot turning around in our house. But this does not mean I don’t follow a branch of research when I build robots.

Initially, I built robots to understand how the driver for the motors works, the sensors, and the problems related to the logic of the robot. Afterward, the first branch of research was the issue of control, how to set the proportional, integral, derivative (PID) control to follow a line or make a robot that is in balance. This has enabled me to address the management of complex sensors, such as the inertial measurement unit (IMU).

To have a robot balance on two wheels it is important to measure how much the robot is tilting from the vertical. To do this, typically a cluster of sensors is used, called IMU, which are based on multi-axes combinations of precision gyroscopes, accelerometers, magnetometers, and pressure sensors. In a more simple version, the IMU uses an accelerometer and a gyroscope, and it is mandatory to use both signals to obtain a correct value of the tilt angle from the vertical (it is called fusion of signals).

The most common method used is based on the Kalman filter, which is a mathematical tool that enables you to combine two or more signals to obtain the value of the angle. But it is a highly sophisticated and difficult for an amateur to understand, and it requires fairly advanced knowledge of mathematics. A new method that is rather simple has been proposed in the last years. It is called the “complementary filter.“

One of the studies I performed and posted on my blog compares in practice the signals of the two filters to verify if the complementary filter is able to approximate the Kalman filter in typical situations coming up in robotics. This post has had a great following, and I’ve been surprised to see that several university-level scientific publications have linked to it. I only wrote the post because I was curious to see a simple and almost trivial method that has become helpful to researchers and hobbyists. It has been a pleasure for me.

In the last year, I have followed the trend of art and interaction (i.e., the possibility of building something that can somehow marry art with technology). It was the theme of the stall I had at Maker Faire Europe in Rome, Italy, in October 2013. Arduino is an electronic circuit without a heart and without a soul. Can an Arduino be an artist? I’m trying to do something with Arduino that could be “art.” The arts include painting, poetry, music, sculpture, and so on. I’m trying to do something in different fields of art.

My first experiment is the Dadaist Poetry Box, which is a box capable of composing and printing Dadaist poems. It’s made with an Arduino and uses a printer for receipts to write poems. The box uses an algorithm to compose the poems in autonomy. You push the button and here is your Dadaist poem.

PoetryRobot

Dadaist poetry box design

Normally, the poem is a valuable asset, the result of an intimate moment when the poet transposes on paper the emotions of his soul. It is an inspired act, an act of concentration and transport. It’s not immediate. The poem box instead is trivial, it seems almost “anti-poem.” But it’s not; it’s a Dadaist poem. A user can push the button and have an original poem. I like the machine because it gives everyone something material to take home. In this way, the experience of interaction with the machine goes beyond the moment.

Another of my favorite robots is one that is capable of drawing portraits. I’ve never been good at drawing, and I’ve always been envious of those who can easily use a pencil to make a portrait. So I tried using my technical skills to fill this gap.

DrawingRobot

Portrait-drawing robot

The search of the algorithm that—starting from a picture—is able to detect the most important lines of the face has been particularly long and difficult. I used the OpenCV open-source libraries for computer vision and image processing, which are very powerful, but hard to handle. Installing the libraries is not a simple undertaking and using them is even more complicated. I used the OpenCV for Processing. Processing is an open-source programming language and integrated development environment (IDE) built for the electronic arts, new media art, and visual design communities with the purpose of teaching the fundamentals of computer programming in a visual context.

The algorithm initially found facial lines using the algorithms for calculation of edges of a picture. So I used the Canny edge detector, the Sobel edge detector, and all the other main edge detection algorithms, but none of these proved to be adequate to draw a face. Then I changed the course and used the Laplacian filter with threshold. I think I reached a good result because it takes less than 10 minutes to draw a portrait, which enables me to take pictures of people and make their portrait before they lose their patience.

CIRCUIT CELLAR: What new technologies excite you and why?

ALESSANDRO: I work almost strictly with Arduino microcontrollers. I was excited with the arrival of Linux-embedded mini-PCs (e.g., the Raspberry PI, the pcDuino, and BeagleBoard.org’s BeagleBone Black). Forcibly, I’m very intrigued by the new Arduino Tre, which is a mini-PC with Linux joined with an Arduino Leonardo. Combining a PC’s processing power of with Linux with the real-time management of the sensors and actuators made by an Arduino is an interesting road. It offers the possibility to manage the real-time processing of video streams through, for example, the OpenCV libraries, with the option of acquiring signals from analog sensors and the possibility of drive motors. For example, this enables one to have a completely autonomous 3-D printer and to perform the slicing and management of the 3-D printer. It also opens up new perspectives in the robotics and computer vision. The main limitation, which is now present in embedded systems, is the limited processing capacity. The ability to have in the same card a Linux system—with the world of applications and drivers already available—linked to the ability to manage physical devices brings a revolution. And I’m already excited to see the next results.

Read the complete interview in Circuit Cellar 292 November 2014.

Electrostatic Cleaning Robot Project

How do you clean a clean-energy generating system? With a microcontroller (and a few other parts, of course). An excellent example is US designer Scott Potter’s award-winning, Renesas RL78 microcontroller-based Electrostatic Cleaning Robot system that cleans heliostats (i.e., solar-tracking mirrors) used in solar energy-harvesting systems. Renesas and Circuit Cellar magazine announced this week at DevCon 2012 in Garden Grove, CA, that Potter’s design won First Prize in the RL78 Green Energy Challenge.

This image depicts two Electrostatic Cleaning Robots set up on two heliostats. (Source: S. Potter)

The nearby image depicts two Electrostatic Cleaning Robots set up vertically in order to clean the two heliostats in a horizontal left-to-right (and vice versa) fashion.

The Electrostatic Cleaning Robot in place to clean

Potter’s design can quickly clean heliostats in Concentrating Solar Power (CSP) plants. The heliostats must be clean in order to maximize steam production, which generates power.

The robot cleaner prototype

Built around an RL78 microcontroller, the Electrostatic Cleaning Robot provides a reliable cleaning solution that’s powered entirely by photovoltaic cells. The robot traverses the surface of the mirror and uses a high-voltage AC electric field to sweep away dust and debris.

Parts and circuitry inside the robot cleaner

Object oriented C++ software, developed with the IAR Embedded Workbench and the RL78 Demonstration Kit, controls the device.

IAR Embedded Workbench IDE

The RL78 microcontroller uses the following for system control:

• 20 Digital I/Os used as system control lines

• 1 ADC monitors solar cell voltage

• 1 Interval timer provides controller time tick

• Timer array unit: 4 timers capture the width of sensor pulses

• Watchdog timer for system reliability

• Low voltage detection for reliable operation in intermittent solar conditions

• RTC used in diagnostic logs

• 1 UART used for diagnostics

• Flash memory for storing diagnostic logs

The complete project (description, schematics, diagrams, and code) is now available on the Challenge website.

 

Game On with the Arduino Esplora

Every time the Arduino team is about to release a new board, we expect something great in terms of better specs, more I/Os, a faster processor, more memory—or, well, just something to “fill the gap,” such as small-scale versions. With “Esplora” the Arduino team pleasantly surprises us again!

Arduino Esplora

The brand new Esplora is targeted toward gaming applications. It consists of a gamepad-shaped development board that includes an Arduino-compatible Atmel ATmega32U4, a light sensor, a temperature sensor, an accelerometer, a joystick, push buttons, a slider, an RGB LED, and a buzzer.

The Esplora is as a ready-to-use solution for designers who don’t want to deal with soldering or prototyping by means of discrete components. In fact, it comes preprogrammed with a controller script, so you only have to connect it to a PC, download the free game “Super Tux Cart,” and have fun.

An additional color LCD will be released soon in order to create a portable console. The only drawback is you can’t directly connect standard Arduino shields to it , mainly because of space limitations. Nevertheless, the board itself includes enough features to make it interesting.

The Esplora should enable you to implement a controller for almost any application you dream up. In our case, we’re sure it will bring back nice memories of the time when we were too young for soldering irons but already pros with gamepads!—Jaime González Arintero Berciano, Elektor International Media

 

Propeller Games (P2): Game Logic

In the first part of this article series on Parallax Propeller-based gaming projects, I hooked up the hardware for the Hi/Lo game on a breadboard. Now I’ll write the game logic. The finished code is available here.

The power of the Propeller chip is in its multiple CPU cores. But you can do just fine with one processor, especially for a simple game like Hi/Lo. You program each of the processors in assembly or in the Parallax-invented SPIN high-level language. Assembly programs run blazingly fast directly in the CPU core. SPIN compiles to a binary format that is interpreted by the SPIN interpreter (written in assembly). The interpreter runs in the CPU core.

The CPU core is designed for speed, but it only has room for 512 instructions. The SPIN interpreter fetches your program byte by byte from shared RAM. Your code runs more slowly, but you have 32K of space to work with. I’ll use assembly in future projects, but SPIN is perfect for Hi/Lo.

A SPIN file is a collection of functions and data (shared by all functions in the file). The functions use local variables kept on a call stack. You break up your programming task into smaller functions that build on one another and call each other. You pass parameters to the functions and use the return values. It is all very similar to C programming though the syntax is different. The interpreter begins with the first function in your file no matter what you name it.

I started the project with a test “main” and the functions to control the Hi/Lo speaker, LEDs, and switches. 

This function plays a tone on the speaker (Source: C. Cantrell)

The “playTone” function generates a square wave on the speaker pin. The “cnt” register is a built-in 32-bit value that increments with every system clock. I run the prop stick full out with an 80-MHz clock configuration (5M-Hz crystal with a *16 internal multiplier). The “waitcnt” instruction puts the CPU to sleep until the system clock reaches the requested value. There are two waits in the loop that generates one clock cycle. Thus the generated frequency is roughly 40 MHz/freq. I say “roughly” because each instruction takes a little time to execute. The actual generated frequency is slightly less. There are much better ways to generate a precise square wave with the propeller hardware, but this is function is easy to understand, and it works fine for the simple Hi/Lo game.

The LED display is a collection of 14 segments and two dots that are turned on or off by writing a 1 or 0 to the Propeller port pins. The program use a look-up table that defines the various segment patterns to be shown.

The output pin bit patterns for numeric digits (Source: C. Cantrell)

The look-up table is defined in a data (DAT) section in the program. The SPIN language allows you to define binary constants with a “%” prefix. You can use the underscore (“_”) anywhere in any numeric constant to make it easier to read. The comment line just above the table shows how the segments map to bit positions in the propeller’s output register.

The “drawNumber” function displays a two digit value on the display. The function first divides the value by 10. The whole part (value/10) is the digit in the 10s place. The remainder (value//10) is the digit in the 1s place. The function looks up the separate patterns, ORs them together, and writes to the “outa” output register to toggle the lights.

I wrote LED functions to “drawBlank” (blank the display) and “drawHi” (show “Hi”) and “drawLo” (show “Lo”). These one-line functions are easy enough to code inline where they are used. But having the functions in distinct blocks makes the using code easier to understand and modify.

The functions to read the buttons return Boolean values: true if the switch is pressed or false if it is not. When a button is pressed, the corresponding input bit in “ina” goes to “1.” There are five buttons and five functions—one for each. There is also an “isAny” function to detect if any button is pressed.

The function returns "true" if a button is pressed. (Source: C. Cantrell)

The game itself has two distinct modes. The “splash” mode flashes “Hi/Lo” and waits for a player to press a button. This is an “attract” mode that draws players to the game. The “splash” function returns when a button has been pressed. The “playGame” function is the game logic. The function returns when the game is over. Thus the main loop simply calls the two functions in an infinite loop.

???????????. (Source: C. Cantrell)

The “splash” function calls “drawHi” and “drawLo” with a pause between.

The function attracts a player to the game. (Source: C. Cantrell)

The “pauseStopOnAnyButton” function counts up the delay and watches for “isAny”. It aborts the pause and returns true if a button is pressed. The “SPLASH_DELAY” is defined in the constant (“CON”) area of the program. I keep all “magic numbers” like delay counts and tone values in the CON area for easy tweaking.

The “playGame” function uses three helper functions: “getPlayerGuess,” “showWin,” and “showHint.” The “showWin” and “showHint” functions are just a couple of lines each and could be coded inline. Having them separate allows you to enhance the visual effects without changing the game logic code.

The “getPlayerGuess” does the real work of the game. It watches the buttons and changes the displayed number accordingly.

The function takes the player input. (Source: C. Cantrell)

The “getPlayerGuess” function is an infinite loop with five IF checks for each button. When the middle button is pressed the function returns with the global “playerGuess” variable holding the input value. The other buttons increment or decrement the digits on the display. Each IF block checks for overflow and plays a feedback tone.

There you have it: a simple Hi Lo game. The visual and input effects are in separate functions ready to be spruced up. I bet your solution has many more bells and whistles! I look forward to reading your ideas in the comments of this blog.

Next time I’ll wrap up the Hi Lo game with a little multitasking. I’ll write parallel programs to run in two new CPU cogs to manage sound effects and the LED display.

Chris Cantrell earned an MSEE from the University of Alabama. He writes Java and Flex for Emerson Network Power in Huntsville, Alabama. Circuit Cellar published 10 of his articles between 2002 and 2012: Issue 145, Issue 152, Issue 161, Issue 184, Issue 187, Issue 193, Issue 205, Issue 209, Issue 139, and Issue 260.

Propeller Games (P1): Hi Lo

Welcome to the Propeller Games! In a few installments, I’ll present several gaming projects that use the Parallax Propeller chip. The Propeller is perfect for gaming with its multiple CPU cores to handle simultaneous gaming activities and its on-board video generation circuitry.

My first game project is the classic “higher/lower” game, where the computer thinks of a number between 0 and 99 and you guess it. You have probably seen this played as the “Clock Game” on The Price is Right TV show, though some contestants struggle with a basic binary search algorithm. (You can watch videos of the game at YouTube.com.)

This entire project is built on a solderless breadboard. If you are new to the Propeller, this is the perfect project to get acquainted with the hardware and programming. If you are a Propeller guru, you will enjoy the nostalgia of gaming on LEDs and push buttons. Grab your breadboard and follow along.

Parts

What you’ll need:

  • Breadboard and wire
  • 9-VDC wall transformer
  • Parallax PropStick USB
  • Two-digit 7-segment LED display
  • Five SPST pushbuttons
  • Audio speaker
  • Sixteen 200-Ω resistors
  • Five 10-kΩ resistors

The board and basic parts

The Parallax Propeller chip requires a few external components. You need a 3.3-VDC power regulator, a crystal, and a USB-to-serial converter. You also need a serial EEPROM if you want the Propeller to run your program at power up. You can buy all these separately and wire them up on the breadboard. Or you can save time and space with the Parallax PropStick USB. It combines all these external parts on the same footprint as the 40-pin Propeller chip.

I bought the LED display for this project from Mouser Electronics (part number 630-HDSP-521E). The large red segments are common anode (common ground). You supply positive voltage from a propeller port pin through a 220-Ω resistor to light the segments.

I bought the push buttons from Pololu Robotics & Electronics (part number 1400). They are specially designed for mounting on a breadboard. One side of each switch is connected to 3.3 V and the other is connected to a propeller port pin and pulled to ground with a 10-kΩ resistor.

I bought the speaker from Digi-Key (part number 668-1140-ND). The negative terminal of the speaker hooks to the breadboard’s ground. The positive terminal hooks directly to a Propeller port pin.

A speaker, one LED segment, and one switch wired to the Propeller

I placed four of the switches on the corners of the display. These switches are used as up/down inputs for each digit allowing the player to select a number from 00 to 99. The fifth button to the right of the display is the “Enter” button.

The photo above shows the speaker, one LED segment, and one switch wired to the Propeller. I tested the hardware and software incrementally as I hooked it up instead of trying to debug the final system as a whole.

The Parallax Propeller Tool is the free graphical Integrated Development Environment (IDE) you use to develop code for the Propeller. The code editor colors and highlights your work making it easy to see functions and keywords. It also manages indentation. The SPIN programming language uses indentation to identify code blocks much as Python does.

Basic hardware test

The code above is my basic hardware test. The CON (constants) section at the top configures the clock speed of the chip: 5 MHz × 16 = 80 MHz. The OBJ (object) section pulls in the serial terminal driver library. This library object allows you to use the USB cable for both programming and an input/output terminal. The one second pause on line 12 gives you time to switch from the IDE program to the terminal program on your PC once the code is downloaded. The Propeller tool download includes the parallax serial terminal for your PC.

Line 10 sets general I/O pin 0 (P0) as an output (they are inputs by default). Line 17 reads the switch connected to P11 and turns the LED segment on or off accordingly. Line 18 prints the state of the input pins to the PC terminal in an infinite loop.

Parallax serial terminal

It took me a while to warm up to the SPIN programming language. It is syntactically very different from C and its derivatives. But conceptually it is familiar: you break your software up into functions and local/global variables. In the end the simplicity of the syntax and the friendliness of the IDE won me over!

I really like the “Propeller font” used in the Propeller Tool IDE. It includes special symbols you can use to draw circuits and timing diagrams in your code comments. For instance:

Check out the font

Now to wire up the rest of the LEDs and switches. I thought about wiring the left digit to the first port byte and the right digit to the second port byte so that the segments are laid out the same way in each byte. This would make the software easier to write. But the pins for the segments on the display are kind of scattered around at random. The wiring is easier and neater if you wire the segments from the bottom of the display to the bottom of the propeller and from the top of the display to the top of the propeller. You can make up for the scattered pattern with software.

Two tips: Wire the segments from the bottom of the display to the bottom of the Propeller. Wire from the top of the display to the top of the Propeller.

Hi/Lo breadboard layout

That’s it for this installment. Now I’ll clean up all the little wire stripping sprinkles I left around my workbench. In Part 2 of this series, I’ll switch modes from hardware to software and write the Hi/Lo game. Hopefully you are following along. Until next time, may the COGs be ever in your favor.

Chris Cantrell earned an MSEE from the University of Alabama. He writes Java and Flex for Emerson Network Power in Huntsville, Alabama. Circuit Cellar published 10 of his articles between 2002 and 2012: Issue 145, Issue 152, Issue 161, Issue 184, Issue 187, Issue 193, Issue 205, Issue 209, Issue 139, and Issue 260.

Tech Highlights from Design West: RL78, AndroPod, Stellaris, mbed, & more

The Embedded Systems Conference has always been a top venue for studying, discussing, and handling the embedded industry’s newest leading-edge technologies. This year in San Jose, CA, I walked the floor looking for the tech Circuit Cellar and Elektor members would love to get their hands on and implement in novel projects. Here I review some of the hundreds of interesting products and systems at Design West 2012.

RENESAS

Renesas launched the RL78 Design Challenge at Design West. The following novel RL78 applications were particularly intriguing.

  • An RL78 L12 MCU powered by a lemon:

    A lemon powers the RL78 (Photo: Circuit Cellar)

  • An RL78 kit used for motor control:

    The RL78 used for motor control (Photo: Circuit Cellar)

  • An RL78 demo for home control applications:

    The RL78 used for home control (Photo: Circuit Cellar)

TEXAS INSTRUMENTS

Circuit Cellar members have used TI products in countless applications. Below are two interesting TI Cortex-based designs

A Cortex-M3 digital guitar (you can see the Android connection):

TI's digital guitar (Photo: Circuit Cellar)

Stellaris fans will be happy to see the Stellaris ARM Cortex -M4F in a small wireless application:

The Stellaris goes wireless (Photo: Circuit Cellar)

NXP mbed

Due to the success of the recent NXP mbed Design Challenge, I stopped at the mbed station to see what exciting technologies our NXP friends were exhibiting. They didn’t disappoint. Check out the mbed-based slingshot developed for playing Angry Birds!

mbed-Based sligshot for going after "Angry Birds" (Photo: Circuit Cellar)

Below is a video of the project on the mbedmicro YouTube page:

FTDI

I was pleased to see the Elektor AndroPod hard at work at the FTDI booth. The design enables users to easily control a robotic arm with Android smartphones and tablets.

FTDI demonstrates robot control with Android (Photo: Circuit Cellar)

As you can imagine, the possible applications are endless.

The AndroPod at work! (Photo: Circuit Cellar)