GP2X Edit - Compile - Debug Cycle: What Do You Do?

[Pryankster]

Currently, my edit-compile-debug cycle works something like this:

• On PC (winXP), edit code, build code.
• Once code is built, put GP2X in USB mode.
• On PC, browse to appropriate directory, drag target files to GP2X
• On GP2X, end USB mode,
• On GP2X, browse to /mnt/sd/Serial (games->Serial) and run "Screen Session.gpe" (included below)
• On PC, start a teraterm on COM2 (where my PC mounts the GP2X as a serial gadget)
• Run program, hope it works
• If it crashes, load it with GDB and try to figure out where and why
• Exit from screen session, close teraterm window.
• Rinse, lather repeat.

There are a few pitfalls with this method. First, if I forget to close the teraterm window after ending the screen session, the next time I try to open COM2, teraterm reports that it cannot open the COM port, and can't until I reboot the GP2X. Second, for quick 'one more thing' type E-C-D, it's a painfully long process (Since in my day-job, I'm a Python programmer -- the long E-C-D cycle is especially annoying -- using python on the GP2X isn't an option for performance reasons)

What are other folks doing for E-C-D? Has anyone gotten the ethernet gadget driver working? (that plus rsh/rlogin and/or ftpd would be awesome)

I've put up my archive with gdb/screen and the startup script here: Serial.zip
(BTW: I didn't compile screen or GDB, I got them from gfoot)

-- pryankster

 

[slygamer]

Mine is similar, except I leave TeraTerm running all the time because I'm using a serial cable, not the USB serial gadget.

0. Run TeraTerm Pro.
1. Put GP2X is USB mode.
2. Compile code.
3. A post-build step in my project copies the files to the right place on the GP2X.
4. Try to disconnect device in Windows.
5. Close dialog that says "Generic drive can not be removed at this time."
6. Disconnect device in Windows again.
7. Exit USB mode on the GP2X.
8. Navigate through menus to run the app.
9. Watch it crash.
10. If necessary, Ctrl-C the app through TeraTerm Pro and run it in gdb.
11. When done, run "./gp2xmenu" to get the menu back and go back to step 1.

I would really like something similar how the console devkits work. I work with PS2, GC and Xbox devkits all day and they are a dream to use compared to this. Compile and run the code from your PC, serving data from the PC over the network, being able to step through code within the IDE on the PC. The sun will shine a lot brighter when we get to that stage on the GP2X.

 

[Radek]

1. Prototype an idea in the Python on the PC first.
(very quick and easy as there is SDL and Python has the binary operators too)
2. If it's appropriate (good enough for an final aplication) just change few things so it will running on the gp2x directly. If not then move to next point.
3. Write an equivalent in C.
4. Test on the PC if it works.
5. Compile for gp2x.
6. Now welcome to the "SD cycle"...
7. Debug using tiresome method of printf to an output file...
8. Write some fragments in the Asm for perfomance purposes and learning.
9. Have a nice program.

The debugging part sucks badly as it's very time consuming. I could use the Arm simulator too on the PC as it'd make testing few things much faster.

 

[gfoot]

I've been working on using the USB link to copy code to the GP2X, but the data rates are pretty poor at the moment (something like 50Kbytes per second) - I haven't had time to find out whether it's the net2272 driver, the gadget serial module, or something else which is at fault.

My end goal with this stuff was a PC-side target manager, which could upload new code and execute it remotely, so you don't have to mess about on the gp2x until the game boots. It's still practical to do that, but without decent file uploads it's less appealing.

The way things are now, I actually found it faster to use a card reader than the provided USB mass storage driver - including the time taken to remove the card and replace it.

gdb has a remote debugging mode (gdb-server), not sure how it works though. Could be useful when the time comes!

 

[Pryankster]

I certainly understand the benefits of Python -- my day job involves programming almost exclusively in Python. However, for the things that I'm working on, it's just not an option.

For one, I'm not using SDL (bleh), I'm using rlyeh's minlib. Second, I'm playing with multiprocessor code and porting stuff like TinyGL and klimt, for which Python is not an option.

Has anyone gotten GDB remote debugging working? At least with that, I wouldn't have to copy source trees over ...

As far as performance of the gadget storage driver, I haven't had much of a problem with it, other than the fact i had to get a pocket USB 1.1 hub because windows wouldn't recognize the GP2X as a USB2 device.

I think alot of things are waiting on GPH to release the damn kernel sources so we can add networking.

slygamer: What are you using for a serial cable?

-- pryankster

 

[Radek]

I certainly understand the benefits of Python -- my day job involves programming almost exclusively in Python. However, for the things that I'm working on, it's just not an option.

I had in a mind using Python mostly for prototyping concepts - for such task perfomance doesn't really matter. I have now some procedures made in Arm assembler (now they are fast!) and they started to exists in the Python first.
(just to test if the algos were working)
That way when I'm going to write C/Asm I can just focus on opcodes/memory organization/registers use, etc.

For one, I'm not using SDL (bleh), I'm using rlyeh's minlib. Second, I'm playing with multiprocessor code and porting stuff like TinyGL and klimt, for which Python is not an option.

I'm using SDL only in Python as I couldn't link with SDL libs for gp2x. Now I don't mind as I'm starting like direct access of hadware more and more.
(and I will go crazy when I will learn to use cache lockups)

 

[slygamer]

For one, I'm not using SDL (bleh), I'm using rlyeh's minlib. Second, I'm playing with multiprocessor code and porting stuff like TinyGL and klimt, for which Python is not an option.

Same here, though I have replaced a lot of rlyeh's code with my own. His 2nd processor code is a big lump of voodoo though.

slygamer: What are you using for a serial cable?

I bought one from Nigel at Toyz4Boyz. Works flawlessly.

 

[torpor]

i have a serial cable (self-built, its easy when you've got the connector) and i:

1. build on my PC, develop on my PC. new code gets test on PC.
2. i frequently 'make clean; make all', where 'all'==PC Target+GP2X Target (plus whatever other targets i'm interested in)
3. SD card A is mounted on my development machine, my targets put the bin in SD A's mount dir .. and i have SD card B, which is an exact copy of A..
3. to test, i log in to gp2x over serial, swap SD card A for SD card B, run the executable.

I do the "SD Card A->B" shuffle, so that both cards end up being exact copies of each other .. this is a simple shuffle/swap/speakernet style setup which has just worked for me .. forever .. so i keep doing it ..

hopefully soon, i'll be able to just mount an NFS dir over USB-Network to the gp2x, and only need to swap to serial window to run the test .. "make all -> serial window -> './myApp.gpe', edit/make/test/etc...