That's exactly what I do with LibGp2x - http://code.google.com/p/libgp2x/
It's dead easy to get a process running on the 940, and you get access to printf and related functions, as well as fopen, fread etc. The functions are far from complete, but they certainly show it works.
Andrew
Yeah, I have a nice little program which fades the screen from black to white on the 940t. It runs fine.
I think the start up code I'm using is yours Squidge :-)
I guess changing the colour of the screen to indicate where it has got to is the best I can do at the moment... oh well!
Thanks,
Andrew
Hi,
Does anyone have any tips or tricks they use to help debug things running on 940t? I have some code that runs fine on my PC, but when I run it on the GP2x I get nothing...
Obviously gdb/valgrind doesn't work, and I haven't been able to get my implementation of printf to give me anything...
From Wikipedia - Valgrind is a free programming tool for memory debugging, memory leak detection, and profiling.. You can find it here. It's Linux only, but it is a really amazing tool.
Andrew
I build all my programs so they run on the PC. Once they run there, and I've checked them with valgrind for memory leaks I compile them for the GP2x and I then mount my development directory and run directly from their.
I've abstracted all the platform specific out from code so the code that I...
header.h
extern int var;
source1.c
#include "header.h"
if(var == 1) var = 2;
source2.c
#include "header.h"
var++;
source3.c
int var = 1;
Hope this helps,
Andrew
Basically I'm not seeing much of a speed up at all. The difference in speed between by 16.16 fixed point type and float for addition and multiplication is virtually nonexistant.
I'm wondering if it's actually my timing code that is the problem, I'm sure I'll work it out :)
Andrew
Are you comparing against soft-floats and not hardware floats using a version of GCC later than 4.0? I've recently been writing my own C based fixed point library and I'm not seeing anywhere near as big a speed up as you do.
Andrew
Define doesn't do what you think it does. The define'd code is just textually replaced where it is used before it is compiled. The -E option to gcc lets you see this.
andrew@andrew ~/Desktop $ gcc -E test.c
# 1 "test.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "test.c"
unsigned long...
I'm not sure if there has been a misunderstanding or not of what BradN said, but just to make it totally clear...
To use an LGPL library and not be required to release your source you must either:
a) Link with the library dynamically
B) Link with it static but provide the unlinked object files...
Check your .bin with a hex editor to make sure it starts with:
060000ea050000ea040000ea030000ea020000ea010000ea000000ea
If it doesn't then that's your problem. If found that changing the order in which things were linked sometimes caused the compiler to stick some junk before that line.
HTH...
That is already there - call GP2x_upper_memory_malloc or GP2x_upper_memory_free on the 920t, or plain malloc/free on the 940t. When transferring pointers to memory between the two processors you have to use GP2x_convert_ptr_from/GP2x_convert_ptr_to so it gets mangled correctly. I need to write...
What is it supposed to do? Is it flipping the screen in the vertical axis? Why would you want to do that?
I'm all for adding useful functions, but there needs to be a good reason why it's there...
Andrew
The build script builds a single static link library, libgp2x.a. You build it once then link it against all of your projects - and a statically linked libraries only include what you use in the final binary so I don't think having compile options like that will have any benefit.
To be honest...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.