QuickStart Whack-a-Mole Demo
jazzed
Posts: 11,803
Here's a QuickStart Whack-a-Mole demo.
Should call it Mole-Run because of the way it works.
This program uses a single COG.
I'll make a multiple COG version if I have time.
Should call it Mole-Run because of the way it works.
This program uses a single COG.
I'll make a multiple COG version if I have time.
/** * The Blue LED moles are eating up your QuickStart yard! * You must get rid of them! * * Gameplay: * * All living moles will run around the QuickStart burrow during * the game and you'll know they're alive by the dimly lit LEDs. * * Sometimes a mole will pop up as brighly lit LED and you must * wack the mole pad to knock it out. * * When the moles are gone, your QuickStart yard will celebrate! * */
Comments
my first question was: "What is a Quick Start"
Now, I found the schematics for the board and can buld it.
On the other hand, I can take the sourcecode and port it to a dsPIC Board,
which have a huge LED and Botton Matrix.
That is the charme of C, easy to port from one hardware to another, rather than each other programming language.
I know this is not the focus for a gcc alphatest forum, but I must say it.
best regards,
Reinhard
Reinhard,
I don't think there's any problems pointing out the portability of C here. I for one would be interested in seeing the code after you port it to compare the differences between the hardware specific details.
As I understand it, well written C code should be able to go back and forth between platforms with a minimum of work. That's one of the things that makes propgcc (and other C platforms for the Prop) a win-win scenarios.
[/QUOTE]
Assume I have a board with the same wiring as Quick Start.
The canditads for hardware abstraction layers are:
/* * Set the LEDs to val */ void LEDOUT(int val) { DIRA |= 0xff << 16; OUTA = (OUTA & ~(0xff<<16)) | (val<<16); } /* * msleep makes the cog wait for about t milliseconds. */ void msleep(int t) { waitcnt((CLKFREQ/1000)*t+CNT); } /* * Get all buttons at once * Run this function from HUB if compiled for LMM. */ int getButtons() { int n = 16; int result = -1; int reading = 0; int pins = 0xFF; OUTA |= pins; //output high to buttons while(n--) { DIRA |= pins; //output high to buttons DIRA ^= pins; //switch to input reading = pins; msleep(2); //wait for RC time reading &= INA; //return button states result &= reading; } result = ~result & 0xFF; return result; }But I am not really interest to port it.
Making libraries that are compatible with some other popular environments could be useful to empower customers who may benefit from the Propeller's strengths (and enable greater Return on Assets/Equity for Parallax).
What I've posted could be easily changed to run on other MCUs since it uses single COG. Reinhard has pointed out most items. Also srand(CNT) could be changed to srand(clock()) or left out entirely.
I was thinking of adding 2 COGs: one to display the "runners" and another to detect the "whack". The intent of that would be to improve performance and showcase Propeller strengths.
However if I add COGs the code would be even less portable (could be wrapped into a #ifdef __PROPELLER__). Encapsulating things into a function would make it easier for other MCUs and vanilla C compilers.
So a key question arises: If one wants to make something worth more to potential customers, how do you extend their current code to allow using Propeller's strengths?
BTW: I had planned a trip today. But it has been delayed a bit.
What I mean is the portability of C in general.
Of course the propeller is a unique chip ( therefore I like them ).
with 8 cpu's in parallel, other hardware goes to the limit and is not easy to port.
Hope I have cleared this disaccord.
best regards,
Reinhard
You could use the pthreads library to start the other COGs -- that way the code would be portable to other MCUs. Of course it does mean you have to use LMM C code for the code you run in those other COGs, so there is a limitation, but it's not too awful.
Eric