An MCU-resident rapid prototyping and education environment for the Freescale Badge Board
Like I said, we’re now in an interactive debugging session. We just stopped the program. We can actually continue the program. You want to see what that looks like. Right now you will see how we’re not running right now. If I say continue, then we can keep continuing and then I can stop it again and now we stopped at line 750. Basically we are in an interactive debugging session where we have full control over the MCU. You know we came in through you know either 3 USB wires or you know some Ethernet wires or some Zigbee or whatever, and we have got full control over the MCU like just as if we were using an in circuit emulator.
We can stop the program, we can start the program. Change the program. We can actually modify lines of the program that we support and editing continues. So, lines get recompiled, reintegrated into the program and you can continue to change program from where you left off. Anyway, we can also as we have seen modify pins. We can examine and modify variables. We have a tilt variable that tells us where the accelerometer is right now and basically, it says we’re at 1696 milli volts and if we turn the board up on its end and recall that command and retry it again, you know we’re at 2571 milli volts. So we have got live access to all the pins. We can control all the pins. We can read all the pins. We can control the variables, read all the variable. We’re in a very powerful debugging session.
We can set break points. We can do you know assertions. We can set watch points. We can you know all sorts of really cool things, right here for debugging this program. But we’re not here to debug right now. We’re here to look at the program. So let’s list it. This is basic remember and we’re going to scroll to the top and then we will go through the program you know kind of section by section. So this is the start of the program. Its, you know hover many lines that was, 93 lines I think or something like that. We start out by declaring some RAM variables. X and Y are basically just going to be the position of the ball at all times. Xv and Yv are going to be its velocity components.
Typically one or minus 1, P is the position of the pedal. Programs typically start out by declaring their variables and they’re going to declare pin variables which is basically going to, they act just like regular basic variables but they’re bound instead of having RAM behind them, they actually have pin functionality behind them. So, when you configure a digital output pin variable, when you modify that, the pin instantly reflects the modification. When you can configure a nlog input pin variable, when you read it, it instantly reads you know the instantaneous value on the A to D converter right there on that pin. So, we have to interface first the accelerometer. In order to do that, if you remember the accelerometer has 3 inputs, that have to be set before you can actually use it. Those translate into outputs on the MCU. Those are gcell1, gcell2 which are the gravity sensitivity select and the sleep pin. What we’re going to do is we’re basically going to create, bind a variable named dcell1 to pin ptc4 and we’re going to configure that pin for digital output.
Little down here we’re going to assign 0 to that and that’s basically going to you know lower that output pin on the MCU. We’re going to bind the variable gcell2 to pin ptc5 and we’re also going to configure that for digital output, a little bit down here we’re going to again 0 to it and that’s going to lower the output pin. Finally we’re going to declare a variable named sleep and we’re going to bind it to pin ptc3 and this one's configured for digital output inverted. Basically what’s that saying is that its an active low signal named sleep and so in the program we want to be able to refer to all these variables in their positive sense. You know if you want to go to sleep, you say lets say sleep = 1. And this basically, the inverted basically, says you know what, even though we’re referring to all about variables in the positive sense in the program, by the time it gets on out to the MCU, I want a go to sleep signal to be represented by a logic 0 instead of a logic 1.
So, when I set that to 0 here, that’s saying I don’t want sleep logically. So, please put a 1 on the pin. Anyway once we have got gcell1 and gcell2 and sleep configured and assigned then we can use the accelerometer at that point. So we can use the analog inputs of the MCU attached to the analog output to the accelerometer. And we can actually access that. So way we’re going to do now is we’re going to bind a new variable named tilt, to pin ptb5 which is an analog input pin and we’re going to configure it for analog input also inverted. Basically analog input says turn on the analog to digital converters and you make sure they’re running and every time I access the variable tilt make sure that I have the current value of you know the analog voltage on that pin in milli volts. Inverted, basically says, you know what I really want is 3300 minus that value. So, when the pin is at 0 volts I want to see a value of 3300 in the variable tilt, when the pin is at 3.3 volts I want to see a value of 0 in the variable tilt. Just makes the program flow a little bit easier. Anyway, so we have got the accelerometer configured. Now, its time to interface to the buzzer.
To interface to the buzzer, basically, we just need one pin. So we create a new variable, called audio and we bind it to pin ptf2 and we configure that for frequency output. That means take that pin, turn on the timer that’s on that pin and program the timer so that you know if the guy sets audio to 5000, we have got a 5000 hertz signal on that pin. If he sets it to 500, we have got a 500 hertz signal on that pin. If he sets it to 0, we turn off the frequency on that pin. Finally one last thing to do, we have got all the pins configured, now we need a virtual timer. You have up to 4 virtual timers. What we’re going to do is we’re going to configure virtual timer #1 so that every 50 milliseconds it will call a pedal sub routine. Basically what we’re going to do in the main program is we are going to manage the ball position of the main program. We are going to attract the ball. We’re going to figure out when it bounces off the things. Figure out when the game is over and things like that.
Asynchronous to that main program, every 50 milliseconds we’re going to call a pedal sub routine in order to attract the pedal. And to basically measure the accelerometer, figure out whether the pedal needs to move and so forth. So, on to the main program loop. For the main program loop, it’s really two wire loops, two nested wire loops. There’s an outer one and an inner one. The outer one basically, you know again we auto run when the guy turns the badge board on and the outer is basically truly infinite, okay we’re going to play this game over and over and over again until the guy turns the badge board off. Okay. The new one is basically, the inner wire loop is basically managing an individual game. Okay. So we’re going to stay in the inner wire loop until the game is lost and then we’re going to break out and then we’re going t return to the outer wire lop and then we’re going to start a new game. So, new game initialization right here. What we’re going to do is we’re going to start out, we’re going to put the ball in the upper left corner. We’re going to set it velocity to 45 degrees down. And we’re going to set the pedal in such a position that if the user doesn’t do anything, he’s going to hit the ball the first time. Then we have two statements that are special.
Basically, we can run the exact same version of this operating system on the 51JM128, the 5221, the 52233. There are only 3 statements two of which are these that we have added to the badge board to make the badge board experience a little more badge board unique and that is basically, we have added the ability to manipulate the LED matrix. You can set and clear individual or groups of pixels on the LED matrix using the jmclear and jmset commands and you can also scroll text asynchronously across the LED matrix using the jmscroll command. So, what we’re doing here is we’re basically clearing the display and then setting just the pixel representing the current position of the ball. Then we sleep for 3 seconds, 3000 milliseconds to give the user time to pair and then we begin the main game loop. The main game loop basically, we enter this on a new game and then we’re going to stay in this game until the game is lost. All we’re going to do is we’re going clear the old ball position, then we’re going to calculate the new ball position by basically adding the X velocity to the X position and the Y velocity to the Y position and then we’re basically go through you know our edge detections.
So, if we hit the horizontal edge of the screen, then we’re going to bounce horizontally which means we’re going to invert the X velocity. If we hit the bottom of the screen, then we’re going to need to do a couple of things here, right. First thing, we need to do is, we’re going to check and see if the pedal was nowhere close then we basically just lost the game. So we call to lose sub routine and then we break out of the inner wire loop, return to the outer wire loop and start a new game. Otherwise, if we didn’t lose the game, but we were really close to the edge of the pedal, then basically what we’re going to do is we’re going to give this pedal a kind of 3D feel and we’re going to let the ball bounce not only vertically off the pedal but horizontally as well. So, we again invert the X velocity. Then basically, if we have hit the top or the bottom of the screen, we need to bounce vertically by inverting the Y velocity. Let’s assume that you know if we’re here, we haven’t lost the game, then we must have hit the pedal. And finally, here we’re going to set the new ball position.
We computed the new ball position up above, we’re going to set the new ball position. And now what we’re going to do is we’re going to wait a little bit before moving the ball again. So the user you know has a chance to react. But we’re also going to beep. We want a beep every time we move the ball. So, we’re going to set a 100 hertz signal for a 100 milliseconds followed by a 0 hertz signal for another 100 milliseconds, at that point we go back and move the ball again. So we’re moving the ball basically, once every 200 milliseconds, half of that time we have got the audio on. So that’s basically the main program loop. Manages the ball position, figures out when the game is over, completely asynchronous to that we have got the pedal sub routine that’s being called every 50 milliseconds by a virtual timer.
Read also: CPUStick
- samshekar's blog
- 455 reads





Post new comment