PDA

View Full Version : moving from java to bare metal access



badperson
December 13th, 2008, 12:04 PM
Hi,

I've worked only in java and perl as a programmer so far...I've never worked on any issues dealing with the ins and outs of a particular operating system, or dealing with hardware at all.

I'm assuming C++ is the main language people write those types of apps, and I'm wondering what are the more difficult parts for someone coming from a java or perl background.

thanks,
bp

StOoZ
December 13th, 2008, 01:09 PM
its usually C , but C++ will also do the trick , depends on what exactly you want to do.

badperson
December 13th, 2008, 04:56 PM
so, for example, if you were going to write a driver for some hardware, say a soundcard, what issues would a java programmer not have confronted before?
thanks,
bp

CptPicard
December 13th, 2008, 05:05 PM
The only thing that really comes to mind is how memory access is so much more explicit in many ways in C. Pointers and how to use them are the major difference.

pp.
December 13th, 2008, 05:15 PM
Timing, interrupts, exclusive control of the processor are other topics which come to mind, as well as ambiguous data types.

Cracauer
December 13th, 2008, 06:10 PM
Hi,

I've worked only in java and perl as a programmer so far...I've never worked on any issues dealing with the ins and outs of a particular operating system, or dealing with hardware at all.

I'm assuming C++ is the main language people write those types of apps, and I'm wondering what are the more difficult parts for someone coming from a java or perl background.

thanks,
bp

If you stay in userland you just use whatever language they give you an API for the functionality you want. Obviously, there is a C API for everything that's directly coming from kernel code, it's called system calls, the more obscure stuff often doesn't have their own system calls but uses ioctl as a hack. You can argue that /proc and /sys stuff isn't a C API at all, it's ... I dunno, a /bin/cat interface?

If you want to move from userland to actual kernel code it's just C, unless you want to go through the trouble of a userland driver.

So what are you trying to do?

If you just need to fiddle with a certain piece of hardware you need to look at the API(s) exported by whoever did the driver.