Tag Archives: Programming

Propeller Games (P2): Game Logic

Posted on by

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.

Design West Update: Compilers Unveiled

Posted on by

IAR Systems announced Tuesday at Design West in San Jose, CA, that GainSpan selected IAR Embedded Workbench as its primary development tool chain for MCU drivers and next-generation chip. “By standardizing on IAR Systems’ embedded software development tool chain, GainSpan will more easily support a wide range of MCUs to communicate with their modules,” IAR publicized a in a release.

It’s an important aspect of a larger plan, IAR’s ARM Strategic Accounts Manager Mike Skrtic said. IAR has overall tool chain standardization goals aimed at giving designers’ more flexibility when choosing MCUs for product development.

Remember: IAR Systems is teamed with Renesas for the RL78 Green Energy Challenge, which is administered by Circuit Cellar and Elektor. Designers are challenged to transform how the world experiences energy efficiency by developing a unique, low-power application using the RL78 MCU and IAR toolchain.

In other compiler-related news, Microchip Technology announced Monday at Design West its new MPLAB XC C compiler line, which supports its approximately 900 microcontrollers. Microchip’s Joe Drzewiecki said the compilers reduce code size by about 35% and improve code execution speed by about 30%. But you can judge for yourself because Microchip offers 8-, 16-, and 32-bit free editions of MPLAB XC compilers. According to Microchip reps, they are” fully functional and have no license restrictions for commercial use.”

So, if you give MPLAB XC a try, let us know what you think!

Robot Design with Microsoft Kinect, RDS 4, & Parallax’s Eddie

Posted on by

Microsoft announced on March 8 the availability of Robotics Developer Studio 4 (RDS 4) software for robotics applications. RDS 4 was designed to work with the Kinect for Windows SDK. To demonstrate the capabilities of RDS 4, the Microsoft robotics team built the Follow Me Robot with a Parallax Eddie robot, laptop running Windows 7, and the Kinect.

In the following short video, Microsoft software developer Harsha Kikkeri demonstrates Follow Me Robot.

Circuit Cellar readers are already experimenting Kinect and developing embedded system to work with it n interesting ways. In an upcoming article about a Kinect-based project, designer Miguel Sanchez describes a interesting Kinect-based 3-D imaging system.

Sanchez writes:

My project started as a simple enterprise that later became a bit more challenging. The idea of capturing the silhouette of an individual standing in front of the Kinect was based on isolating those points that are between two distance thresholds from the camera. As depth image already provides the distance measurement, all the pixels of the subject will be between a range of distances, while other objects in the scene will be outside of this small range. But I wanted to have just the contour line of a person and not all the pixels that belong to that person’s body. OpenCV is a powerful computer vision library. I used it for my project because of function blobs. This function extracts the contour of the different isolated objects of a scene. As my image would only contain one object—the person standing in front of the camera—function blobs would return the exact list of coordinates of the contour of the person, which was what I needed. Please note that this function is a heavy image processing made easy for the user. It provides not just one, but a list of all the different objects that have been detected in the image. It can also specify is holes inside a blob are permitted. It can also specify the minimum and maximum areas of detected blobs. But for my project, I am only interested in detecting the biggest blob returned, which will be the one with index zero, as they are stored in decreasing order of blob area in the array returned by the blobs function.

Though it is not a fault of blobs function, I quickly realized that I was getting more detail than I needed and that there was a bit of noise in the edges of the contour. Filtering out on a bit map can be easily accomplished with a blur function, but smoothing out a contour did not sound so obvious to me.

A contour line can be simplified by removing certain points. A clever algorithm can do this by removing those points that are close enough to the overall contour line. One of these algorithms is the Douglas-Peucker recursive contour simplification algorithm. The algorithm starts with the two endpoints and it accepts one point in between whose orthogonal distance from the line connecting the two first points is larger than a given threshold. Only the point with the largest distance is selected (or none if the threshold is not met). The process is repeated recursively, as new points are added, to create the list of accepted points (those that are contributing the most to the general contour given a user-provided threshold). The larger the threshold, the rougher the resulting contour will be.

By simplifying a contour, now human silhouettes look better and noise is gone, but they look a bit synthetic. The last step I did was to perform a cubic-spline interpolation so contour becomes a set of curves between the different original points of the simplified contour. It seems a bit twisted to simplify first to later add back more points because of the spline interpolation, but this way it creates a more visually pleasant and curvy result, which was my goal.

 

(Source: Miguel Sanchez)
(Source: Miguel Sanchez)

The nearby images show aspects of the process Sanchez describes in his article, where an offset between the human figure and the drawn silhouette is apparent.

The entire article is slated to appear in the June or July edition of Circuit Cellar.

Issue 260: Embedded Control Languages

Posted on by

Choosing a programming language is an essential part of any serious embedded design project. But the task can be daunting. When should you use a processor-specific language? Why not just use C?

In the March issue of Circuit Cellar, Steve Ciarcia reviews a handful of programming languages and types of and processors—and projects—for which they are intended.

Here’s Steve’s take:

Let’s talk about languages—specifically, embedded control languages. Everyone has their favorite, typically whatever they learned first, but when you get right down to it, all languages offer the same basic features.

First of all, you need to be able to specify a sequence of steps and then select between two (or more) alternative sequences—the if-then-else construct. You also need to be able to repeat a sequence, or loop, and exit that loop when a condition is met. Finally, you want to be able to invoke a sequence from multiple places within other sequences—a call function.

Assembly language is the lowest-level language you can use on most machines. Its statements bear a one-to-one relationship with the instructions the hardware executes. If-then-else and loop-exit constructs are implemented using conditional and unconditional branch instructions, and there’s usually a hardware stack that facilitates subroutine call and return. This is both a blessing and a curse—it enables you to become familiar with the hardware and use it most effectively, but it also forces you to deal with the hardware at all times.

Very early on in the development of computers, the concept of a high-level language (HLL) was developed to reduce this hardware focus. By creating a set of abstract computer operations that aren’t necessarily tied to a particular processor, the HLL frees the programmer from a specific hardware architecture and enables him to focus on the actual algorithm development. The compiler and library writers took these abstractions and efficiently mapped them onto the hardware. HLL opened up programming to “non-hardware” people whose first interest was the application problem and its solution.

Today, there are literally hundreds of computer languages (see http://en.wikipedia.org/wiki/List_of_programming_languages). Some of them are completely general-purpose, while others are very domain-specific. Two languages have been implemented on virtually every microprocessor ever invented: C and BASIC. (There’s no way I can mention them all, so I’ll just touch on some popular embedded ones.) Of the two, C is by far the more popular for embedded apps, since it runs more efficiently on most hardware. Many people would argue that C isn’t a “true” HLL; but even still, it’s a huge step up from Assembly language in terms of productivity.

There have been some niche languages intended for small systems. For example, there’s what you might call a family of reverse-Polish notation (RPN) languages: Forth, Postscript, and does anyone remember a tiny interpreted language called Mouse? These never caught on in any big way, except for Postscript, which is almost universally available these days on printers as a page-description language. But it’s a full programming language in its own right—just ask Don Lancaster!

Along the way, there have been a few processor-specific languages invented. For example, there’s JAL—just another language—which is optimized for 8-bit Microchip PIC processors, and Spin, which is designed to support the parallel-processing features of the Parallax Propeller chip.

Once you start getting into larger 16- and 32-bit chips, the set of available tools expands. Many of these processors have C/C++ toolchains based on the GNU Compiler Collection (GCC). However, this means you can really use any number of languages in the collection on these processors, including Fortran, Java, and Ada.

The designers of some embedded systems want to include the ability for the system to be programmed by their end users. To this end, the concept of an “extension language” was developed. Two notable examples are TCL and Lua. These provide a standard notation for control constructs (branching, looping and function calls) wrapped around application-specific primitive operations implemented by the system designer.

Once you start getting into systems that are large enough to require an operating system (real-time or otherwise), many of the available choices support the POSIX API. This means you can use any of the mainstream scripting languages—such as shell scripts, Perl, Python, Ruby, PHP, etc.—either internally or exposed to the end user.

And finally, there’s the web-based user interface. Even relatively simple embedded applications can have sophisticated GUIs by pushing much of the programming out to the browser itself by means of ECMAscript (JavaScript) or Java. The embedded app just needs to implement a basic HTTP server with storage for the different resources needed by the user interface running on the browser. There are all kinds of toolkits and frameworks out there that help you build such a system.

I’ll stop now. The point is, even in the world of embedded computer applications, there’s a wide variety of tools available, and picking the right set of tools for the job at hand is part of the system design process. Taking a higher-level view, this brief survey might give you an idea of what kinds of tools you would want to put some effort into learning, based on where your interests lie or the application dictates.

 

Processor Design Using Verilog HDL

Posted on by

If you have the right tools, designing a microprocessor shouldn’t be complicated. The Verilog hardware description language (HDL) is one such tool. It can enable you to depict, simulate, and synthesize an electronic design, and thus increase your productivity by reducing the overall workload associated with a given project.

Monte Dalrymple’s Microprocessor Design Using Verilog HDL is a practical guide to processor design in the real world.

It presents the Verilog HDL in an easily digestible fashion and serves as a thorough introduction about reducing a computer architecture and instruction set to practice. You’re led through the microprocessor design process from start to finish, and essential topics ranging from writing in Verilog to debugging and testing are laid bare. The book details the following, and more:

  • Verilog HDL Review: data types, bit widths/labeling, operations, statements, and design hierarchy
  • Verilog Coding Style: files vs. modules, indentation, and design organization
  • Design Work: instruction set architecture, external bus interface, and machine cycle
  • Microarchitecture: design spreadsheet and essential worksheets (e.g., Operation, Instruction Code, and Next State)
  • Writing in Verilog: choosing encoding, assigning states in a state machine, and files (e.g., defines.v, hierarchy.v, machine.v)
  • Debugging, Verification, and Testing: debugging requirements, verification requirements, testing requirements, and the test bench
  • Post Simulation: enhancements and reduction to practice
Click here to purchase the book.

Click here for the supplementary files associated with this book.