When to use Emulation when to use Hardware, when to use Virtual devices.Re: Software Emulator

Koen Kooi koen at dominion.kabel.utwente.nl
Sun Mar 4 22:26:50 CET 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is the best summary on the subject I've ever seen!


John Carter schreef:
> On Sat, 17 Feb 2007, Koen Kooi wrote:
> 
>>> If you don't like using an emulator, by all means, don't, but please
>>> understand that, whether the desire is rational or not, the rest of us
>>> prefer them.
> 
>> Amen to that. To clarify: y response was incited by repeated
>> statements of "need an emulator to see how openmoko looks like",
>> which is simply isn't true.  regards,
> 
> As a guy that develops development environments for a living... let
> me say there is a lot of middle ground in this argument....
> 
> You see, I have found it depends critically on what you are doing with
> the device.
> 
> If you are writing hardware device drivers, you need the real
> hardware. Period. With JTAG's and any tool you can lay your hands on.
> 
> If you are porting compilers / toolchains / bootcode / OS's, then
> sometimes NOT having real hardware and having a plain CPU emulation is
> easier. ie. Fight one issue at a time, get your code working and
> debugged on the emulator, then try on real (usually slightly buggy)
> hardware.
> 
> If you are working at the Application level, it is _way_ _way_ nicer
> just to work in a Bog Standard Linux Desktop Native
> environment. Everything is _way_ faster, your tools are _way_ better &
> smarter (valgrind, gcov, gprof, gdb, compile,link,d/load,run
> cycle....)
> 
> But.
> 
> There is a Gotcha.
> 
> You need to be able to talk to and receive stimulus from the real
> hardware (or a really good facsimile thereof) ie. The phone stack, the
> GPS, the ...)
> 
> That can be handled two ways.
>   * Completely virtualized.
> 
>   * Some back channel communication that has stubs on the desktop
>     connecting to stubs on the dev board. (Good for doing the
>     development of the lower layers of the comm stack)
> 
> The answer is you can get damn far in application development with a
> good way of virtually providing the stimuli needed.
> 
> In the OpenMoko environment what do you need?
> 
>  * The guys doing the real platform development and writing drivers
>    for new devices etc. Yup. Need real hardware.
> 
>  * The guys doing the OS port and the compiler toolchain, may find a
>    CPU emulator of some use. (Real Hardware sucks, it suffers from
>    things like bad connections, limited ram, slow connections,
>    ummfeatures, ....all problems that stop you working on your part of
>    the problem. Let the h/w, boot and device driver guys do their
>    thing)
> 
>  * The guys doing application development need to realize they aren't
>    in "embedded device" Kansas anymore. You _must_ write your code to
>    sit atop ordinary Linux. Not wired as directly and shortly to the
>    hardware as many embedded system folks are use to. ie. If you need
>    the real hardware to get it to run, you are doing it wrong!
> 
>  * Once the Application is working, tested and debugged. Then you need
>    absolutely vanilla bog standard mass market hardware to do
>    integration and functional testing on. (Test like you fly, fly what
>    you tested)
> 
> John Carter                             Phone : (64)(3) 358 6639
> Tait Electronics                        Fax   : (64)(3) 359 4632
> PO Box 1645 Christchurch                Email : john.carter at tait.co.nz
> New Zealand
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFF6zmaMkyGM64RGpERApdSAJ9azZw7lx9KeVx8HjN80WwnnOoQRQCfZa+F
sfRy84wouynTediw/rRBO4s=
=IppJ
-----END PGP SIGNATURE-----



More information about the openmoko-devel mailing list