Forum Index > Projects > LED Pegboard and Matrix Projects
 Working on Gem Drop...anyone have debugging suggestions?
 |  Printable Version
By: Anonymous: Ken Corey () on Saturday, December 27 2008 @ 01:58 PM PST (Read 6961 times)  
Anonymous: Ken Corey

Hi All,

Anyone have a nifty way of debugging via a serial cable to the Meggy?

I'm working on a little program that old-timers might have seen years ago. A bar of three pixels drops from the top of the screen.
Button_Left moves it left.
Button_Right moves it right.
Button_Down advances it one row.
Button_B rotates the order of the pixels of the bar.
Button_A changes orientation from vertical to horizontal and back.

I've got the basic logic in, but there's a boundary case I'm missing that's driving me nuts. I've even considered writing a meggy-alike library for Visual C or gcc+SDL that will allow for running the code, and testing your logic, on a full-power computer.

My problem is that I've got a bug that's tickled at the boundary condition on the top row or bottom row. Without being able to dig through the variables I'm not sure where to start.

I've tried illuminating specific pixels on the screen, or lighting up the auxilliary LED's...any further suggestions about debugging?

If you're interested, you can take a look at the code here: http://flippinbits.com/twiki/MeggyJr_GemKeeper.zip

It's not brilliant, but it's runnable now. Mind you, it's not, yet, a game. Just a tech demo.

-Ken





       
   
By: Windell (offline) on Saturday, December 27 2008 @ 04:04 PM PST  
Windell

Hi Ken,
Good idea for a game. Serial monitoring is pretty straightforward, and you can use that for debugging purposes.

Add the following line to your setup() section:

Serial.begin(9600); // set up Serial library at 9600 bps -- You can also use 19200, for example.

Then, add the following where you like, either in the setup() or loop() parts:

Serial.println("Hello world!" ); // prints hello with ending line break
byte b = 5;
Serial.println(b);

To see the serial output, click the "Serial Monitor" button in the Arduino environment; it's the one next to the "Upload to I/O board" button. Also, make sure that you have the correct baud rate selected-- the baud rate selection should be visible once you have the serial monitor on. For additional details, see LadyAda's tutorial: http://www.ladyada.net/learn/arduino/lesson4.html

There's also a Meggy Jr emulator already, if you'd rather go that way:
http://code.google.com/p/meggy-jr-rgb-emulator/


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Anonymous: Ken Corey () on Sunday, December 28 2008 @ 02:17 PM PST  
Anonymous: Ken Corey

Oh, cool! I can imagine all sorts of cool over-serial interaction with this thing now.

As you can see from my other post, I went a little crazy and built the simulator I needed to find my bugs...

I like the speed of the development cycle using Visual C better than in the Arduino environment, but it's really handy to know the serial trick for the times when development *must* be done on the Meggy.

Thanks!

-Ken





       
   
By: Anonymous: Ken Corey () on Monday, December 29 2008 @ 01:38 PM PST  
Anonymous: Ken Corey

Gem Keeper is now at version 0.8. Most of the bugs seem to have been ironed out, and there's (very) rudimentary sound, now.

As before, you can get it at:

http://flippinbits.com/twiki/MeggyJr_GemKeeper.zip

I'm happy for this to go on the Google Code site, if you're of a mind.

-Ken





       
   
By: Rafiki (offline) on Thursday, January 01 2009 @ 07:35 AM PST  
Rafiki

Cool game, Ken.

One of the boundary condition glitches that you mention might be the switch from vertical to horizontal when barx=7.


Forum Apprentice
Apprentice

Status: offline

Registered: 12/09/08
Posts: 14
Bloomington, IN USA

Profile Email Website  
   
By: Rafiki (offline) on Thursday, January 01 2009 @ 08:59 AM PST  
Rafiki

Ken,

I hope you don't mind, I've been tinkering with your program. Here is a list of changes:

1. Does not allow vertical to horizontal when barx > 6. (This might be the cause of some of the bizarre detection behavior.)
2. Changed color list so that the first 6 or 7 colors are easier to distinguish.
3. Added a splash screen so that player initiates new games by pushing any button (can see score before game resets).
4. Random seed to time of first button push because the original seed was not really random, at least not on mine.

Do you want me to email the changes to you?

Mark


Forum Apprentice
Apprentice

Status: offline

Registered: 12/09/08
Posts: 14
Bloomington, IN USA

Profile Email Website  
   
By: Anonymous: Ken Corey () on Friday, January 02 2009 @ 03:51 PM PST  
Anonymous: Ken Corey

Ran into an interesting thing. I don't know if it's a bug, or a limitation of the compiler on the arduino.

For context, you can download the most recent version of GemKeeper (silly name in hindsight...is 'Gem Drop' better?) from:

http://flippinbits.com/twiki/MeggyJr_GemKeeper_080.zip

Rafiki, of *course* I don't mind you playing with the source code. Thanks very much for taking the time to do so! I'd love to see your changes (you could email them to me at ken@kencorey.com). 0.80 above seems to me to solve the dangling bit bug on bary=7, and also the control at the top of the screen bug.

1) Interesting thing...

Windell was kind enough to send me an updated version of the Meggy library that provides for automatic ending of notes handled in the screen redraw code.

This gave me just enough rope to hang myself. I built a music call that plays a melody without much in the way of program input. Not fully in the background, but the next, best, thing.

Anyway, I noticed that as I added notes, and increased the size of the storage (the music array to 200 or more), that at some point the machine loses it's mind...displays garbage (or even more scary) nothing at all. Works fine at 150 elements of the array (unsigned ints), but dies strange deaths somewhat above that.

Another thing I noticed is that without being able to mute the music, it's annoying enough that perhaps we don't need music on this platform in the first place...;^)

The song is intended to be 'The Bare Necessities' from Disney's 'Jungle Book'.

2) I have fixed the two glitches I knew about...but didn't do any screens of any kind yet.

-Ken





       
   
By: Windell (offline) on Friday, January 02 2009 @ 05:10 PM PST  
Windell

Windell was kind enough to send me an updated version of the Meggy library...

Oh dear-- cat's out of the bag-- I'll have to get this new version posted soon now. Oops! Wink

The problem that you have is that you are running out of RAM. The ATmega168 has 1k of RAM (SRAM, really). The Meggy Jr library (MeggyJr.h) uses approximately 210 bytes of RAM, mostly for display memory and associated variables. The Simplified Library take up about 130 bytes more (Off-screen buffer & pre-defined colors), for roughly 340 bytes total, leaving about 2/3 of the memory free. (All of these numbers are approximate-- there's also Arduino overhead for globals and buffers. Coincidentally, (1) the screen redraw functions and associated hardware access overhead take about 1/3 of the CPU cycles, leaving 2/3 of the CPU time free. Also coincidentally (2) the library functions take up about 1/3 of the available program space flash memory.)

For most of what we want to do, leaving 2/3 of the RAM available is just fine. But, when you start to load large arrays into memory, you'll find a problem quickly. If you load an array of 200 unsigned ints into memory, that takes up 400 bytes of memory; each is two bytes long. Assuming that your program is fairly complex and uses a few hundred bytes of RAM, you'll run out of RAM and things will go haywire. You can make a hell of a program that fits into a few hundred bytes of RAM, but big lists are just trouble. (Also: avoid large numbers of long or float variables!)

Quick fix: Make your array of 200 points an array of 8-bit numbers (type byte), which refer to unsigned ints in a short look-up table. If you have fewer than 17 total notes, you can even recycle bytes, storing a note in the high 4-bits and in the low 4-bits.
This will probably save you about 200 bytes of RAM.

Better solution: Store large arrays in the program flash memory (avr progmem), and only call out a handful of notes at a time when you need them.

Another thing I noticed is that without being able to mute the music, it's annoying enough that perhaps we don't need music on this platform in the first place...;^)

You can hold down a button at power on to Mute Meggy Jr, but that's probably not what you mean. Yes, a soundtrack can get painful. If we manage to hack in a programatic volume control it might be tolerable. Smile


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: KenCorey (offline) on Saturday, January 03 2009 @ 04:03 AM PST  
KenCorey

Oh dear-- cat's out of the bag-- I'll have to get this new version posted soon now.



My deepest apologies. Eek! I wrote without thinking.

Even worse, I've got a version of Gem that I'm happy enough with (Thanks Mark!) that I'm calling it 1.00. Sadly, though, it depends on the new version of the library. Once you're happy enough with the new library to release it, I can upload the 1.0 version of Gem on Google Code. It's available now for testing at http://flippinbits.com/twiki/MeggyJr_GemKeeper_100.zip

The way the new library version is currently written might cause us trouble, as I don't think code can run on both libraries. Older code will sometimes rely on having Tone_Update(), or perhaps MeggyJr::SoundCheck() and newer code will rely on having the new features, which won't link on older versions of the library.

I don't mean to teach my Grandmother to suck eggs...but that could be a potential support problem in the future.

May I make a few suggestions?

1) provide a unsigned int Meggy_Version() function that returns a version number programs can check? You could, if you really wanted, use the first byte for major version, and the minor for smaller increments. Programs could check for this to make sure they have a version of the library they expect.

2) provide backwards compatibility (or at least compilability) so older programs can run (or at least compile) without modification. The Tone_Update() function shouldn't disappear, it should simply not do anything...in this case, at least, older programs would still work just fine. This is where those golden handcuffs I was talking about come into play. The more API functions there are, the more support changes will require.

As a programmer, it's no big deal to switch between versions of the library...but as a consumer, (especially a hobbyist not interested in the programming aspects), I wouldn't want to have to worry about library versions, and swapping them in and out just to compile and download a randome game.

What do you think?

-Ken


Forum Henchperson
Henchperson

Status: offline

Registered: 01/02/09
Posts: 22

Profile Email    
   
By: Windell (offline) on Saturday, January 03 2009 @ 04:30 AM PST  
Windell

The new version is up on SVN now. You could add your program to the SVN tree as well; that's really the best way to keep it current.

I *do not* have a compatibility mode for Tone_Update(), but I can add one without pain... maybe like this:

#define Tone_Update(); {}

-- Using a #define is good; it won't take any space in programs where it isn't called.


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Windell (offline) on Saturday, January 03 2009 @ 04:41 AM PST  
Windell

Yes adding "#define Tone_Update(); {}" works for backwards compatibility.

Just committed to svn. A bunch of other new examples as well today, including three examples of using serial communication. Smile


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Rafiki (offline) on Saturday, January 03 2009 @ 11:08 AM PST  
Rafiki

I don't see an update to the library here: http://code.google.com/p/meggy-jr-rgb/downloads/list

Is there a convenient link to the svn from the forum?


Forum Apprentice
Apprentice

Status: offline

Registered: 12/09/08
Posts: 14
Bloomington, IN USA

Profile Email Website  
   
By: Windell (offline) on Saturday, January 03 2009 @ 12:22 PM PST  
Windell

>I don't see an update to the library here: http://code.google.com/p/meggy-jr-rgb/downloads/list
>Is there a convenient link to the svn from the forum?

No... there's an intentional barrier between easily downloadable things and what's in the svn structure. That keeps casual users from downloading the "latest thing," which is a good thing because it removes the requirement that the developers only upload things once a new version is to a "useable" state.

The new MeggyJr library is useable, although I'd like some feedback on it before I make it the featured download, so I've put it up as version 1.3 BETA; you can download it from the google code site now. There are some *awesome* new demo programs included. Big Grin


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   



 All times are PDT. The time is now 08:15 AM.
Normal Topic Normal Topic
Locked Topic Locked Topic
Sticky Topic Sticky Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Able to Post 
Filtered HTML Allowed 
Censored Content 

Evil Mad Scientist Forum Archives — Read only!

Please visit our new forums for new discussions.


DIY Hardware for Electronic Art


The Original Egg-Bot Kit


Octolively
Interactive LED kits


Meggy Jr RGB
LED matrix game
development kit.


Business-card sized
AVR target boards


Peggy 2
LED Pegboard kits

My Account






Lost your password?