views:

60

answers:

1

I'm working on software to control a mmap'd device on an embedded ARM system, but have run into a few situations where the debugging and development tools available haven't been sufficient. i.e. Instrumentation tools like valgrind and higher end thread profilers are unavailable.

What I'd like to do is compile my code on an x86 machine, mmap a 'dummy' segment of memory using the same size and then proxy those reads/writes across the network to the embedded machine which could then respond accordingly.

I realize this would likely require a client/server mechanism and would be excruciatingly slow but the benefits of having this option would make the mechanics outside of the mmap interface itself (async event handling, thread management) available to instrument using x86 development tools would be very useful.

I've heard of this technique in some ASIC development for simulation but never used anything that provided this functionality. The key point here is that I want to use the same code on both platforms without having to rewrite a bunch of stuff, or have to write a kernel module that has any hardware handling logic in it. I want to keep all the device control logic in userland through mmap

+1  A: 

If you think this through, basically this boils down to implement a remote file system.

  • the "easiest" would probably if your embedded device could realize a simple version of the NFS client side, and mmap a file on your desktop machine
  • the inverse should also be possible, namely to have nfs server modules running on you embedded system and to export something like /dev/shm as an nfs mount point to your desktop.

For both approaches (any any other using mmap) you must be really careful on data synchronization. But as long as you have a typical debug setting with basically one writer and one reader this could be doable. If this gets more complicated, there is remote file locking available as an nfs extension.

Jens Gustedt
An interesting suggestion, I'll investigate!
synthesizerpatel