Plans Cad Diagrams, Electrical Diagrams

[hobbyman II]

as people have said several times, if you are working on 2D games or applications then just use SDL/C++ on any OS, then when the Pandora comes out just change your compiler to make executables for ARM/OMAP, the only other thing you need to do is to make sure your application doesn`t need more than 800x600 pixels.

if you intend to code for OpenGL then just do the same, but read up on the version the Pandora uses (nanogl?), and just use those instructions or equivalents in your rendering, you don`t need a Pandora emulator or whatever, code written in C++/SDL/OpenGL should work just fine recompiled for ARM when the Pandora comes out, compiling ARM code for a computer you don`t have is futile, since you couldn`t run it.

the Pandora is just a Linux computer running on an ARM chip, code written for Linux (or even windows) should just need small tweaks (if any) in order to run on the Pandora, so install SDL and your compiler/api of choice (sensible to use one that can manage ARM code like code::blocks or codewarrior) then use that to write your code.

short answer : install code::blocks and SDL, write your code with that, making sure you don`t go above 800x600 screen size in the compiled application, when you get a Pandora, recompile the same code for ARM/SDL.

 

[lulzfish]

I would actually stay under 800 by 480, since the Pandora is 800 by 480.

And most computers nowadays have 16:10 or 16:9 monitors, so just make your application resolution-independent enough and you'll be fine.

 

[desijays]

then use that to write your code.

short answer : install code::blocks and SDL, write your code with that, making sure you don`t go above 800x600 screen size in the compiled application, when you get a Pandora, recompile the same code for ARM/SDL.

thank you for the clear blueprint of how to go about setting it up. : ) I still have a question though. Say I use the SDL/OpenGL/C++ combination. Now i believe that would allow me to have access to the control operations and graphics on the pandora(keyboard, dpad, buttons, analog pad, touchscreen, graphics adaptor). Now say if i wanted to access the induvidual components on the pandora(keyboard, dpad, button, analog pad, graphics chip, touchscreen, wifi, bluetooth, usb ports and such).. then is there some sort of developer API for each of those components or would i have to use the device drivers of these induvidual components for accessing their features directly at a hardware level? jsut curious. not that i plan to access them that way, but i might for some thing i have in mind !

Thank you.
Cheers

 

[rabidpoobear]

.. then is there some sort of developer API for each of those components or would i have to use the device drivers of these induvidual components for accessing their features directly at a hardware level?
Cheers

What do you mean, access individual components? How is that different than what you mentioned already?
You access these components through the API you're using ( which is SDL).
You can access them at whatever level you want, really, but why would you? SDL already handles pretty much everything you'll need.
Say you want to use wifi... I wouldn't suggest controlling the wifi chip at all. Let the end user set up their wifi correctly as a connection, then just use a networking library in your language of choice to connect to wherever you need. Same with bluetooth, you can write custom drivers for your devices if you want, or you can just let them mount as normal and control them through the Bluez bluetooth stack, or you can use an API that does bluetooth handling (eg. with Python you can use pybluez). Or depending on what you're doing, a lot of cases bluetooth devices just mount themselves as virtual serial ports, so you can use a serial library and just make sure you open the right com port (pyserial for example.) An example of this: Bluetooth GPS modules mount themselves as COM ports, just as most USB GPS modules do.

You're going to need to be A LOT more specific about what you're trying to do and in what way, if you want answers that apply to your problem AT ALL. For general speculation on what is possible, essentially anything you want, so long as you have the motivation to learn how to do it. There are hardly any restrictions on the software side of the device, that's why it's so nice.

 

[Squidge]

.. then is there some sort of developer API for each of those components or would i

I think you need to research how Linux provides access to devices. Considering what the Pandora is, you shouldn't be accessing any of them directly, as the OS will provide and share access where necessary. For example, the keyboard will be available as a file called /dev/event. The internal (and any external) joypads may be available as /dev/jsX, where X is a number (eg. /dev/js0 for the internal). The graphics chip will be /dev/fb for 2d and similar for the 3d. Touchscreen will most likely be /dev/ts0. Wifi will just be a normal ethernet connection, so you would use the normal networking stack to talk or broadcast on an IP address range for example. There's typically no access to the usb ports directly, but rather whats plugged into them.

You'll find that a library such as SDL will provide encapsulated access to /dev/event, /dev/jsX, /dev/fb, and so on, so you don't need to talk to any of them directly. OpenGL will provide your 3D support. That is why we are saying to develope on Linux on your PC first, and then you can easily port your code over, as much of the code will be very similar, such as how you read the keyboard, joystick, wifi, etc.

Linux will typically not like you talking to things on a hardware level. If you want to do that, you should write or modify a device driver first, then let your application install that driver and talk to that via /dev/X where X will be the name of your driver.

 

[desijays]

THank you all for the tips. Now i think I have an idea of where to start and how to go about setting up the so far elusive dev environment lol

Cheers.

 

[Dunny]

Linux will typically not like you talking to things on a hardware level. If you want to do that, you should write or modify a device driver first, then let your application install that driver and talk to that via /dev/X where X will be the name of your driver.

So doing say, the ARM equivalent of the IN/OUT instructions is frowned upon? Or actually impossible? I know that Win32 made it very difficult to do that under 2k/XP etc. I did like to be able to talk to my hardware directly.

D.

 

[WizardStan]

So doing say, the ARM equivalent of the IN/OUT instructions is frowned upon? Or actually impossible? I know that Win32 made it very difficult to do that under 2k/XP etc. I did like to be able to talk to my hardware directly.
I'm going to guess frowned upon. I'm sure that with the right ASM trickery, you could twiggle the registers which control the GPIO lines manually, but a much better solution is to use /dev/files, or at least /sys/files.
Blinking the LEDs on the beagleboard is as easy as opening a file, and then writing "high" or "low" to it, for example.

 

[urjaman]

So doing say, the ARM equivalent of the IN/OUT instructions is frowned upon? Or actually impossible? I know that Win32 made it very difficult to do that under 2k/XP etc. I did like to be able to talk to my hardware directly.
I'm going to guess frowned upon. I'm sure that with the right ASM trickery, you could twiggle the registers which control the GPIO lines manually, but a much better solution is to use /dev/files, or at least /sys/files.
Blinking the LEDs on the beagleboard is as easy as opening a file, and then writing "high" or "low" to it, for example.

This all IIRC, but ARM doesnt have an I/O space to be used with in/out opcodes, instead the OMAPs peripherals are MMIO mapped. So you would need to open() /dev/mem and mmap("] the appropriate portion used by the device you wish to access, then just do writes/reads to the given window. But i think it is a much better idea to use/write kernel drivers for all needed peripherals, so sharing works, etc.[/quote]Ps. Posted with opera mini, i really want the pandora

 

[Squidge]

So doing say, the ARM equivalent of the IN/OUT instructions is frowned upon? Or actually impossible? I know that Win32 made it very difficult to do that under 2k/XP etc. I did like to be able to talk to my hardware directly.
The equivalent of IN/OUT instructions don't exist on ARM. Typically devices are memory mapped, but if you try to access that memory as a user program, the OS will assume your rogue and kill you. You can use /dev/mem to map (mmap) the appropriate memory spaces into your user space and twiddle them from there, but that's not recommended, specially if theres a driver already in memory which maybe twiddling the same registers in the background.