Reply
Thread Tools
Posts: 292 | Thanked: 128 times | Joined on Dec 2009
#1
Brainstorm:

http://maemo.org/community/brainstor...n900_emulator/


It would be very productive for the developers (and even for users) if there was a complete N900 emulator. The standard SDK is fine for development, but it could be better if real ARM code could be run on it.

The idea is to make it possible to do a few things:

1) Test new software on it *without* the risk of thrashing the real N900 device;

2) Instead of warning users not to install software from extra-devel or extra-testing we could warn them to first test that software in the emulator and, why not, give some feedback;

2) Have a development environment that doesn't require the real device for testing and debugging;

3) One developer could configure the SDK + emulator on his/her home system, office and notebook. Then he/her could use git or mercurial to synchronize it all and be able to code wherever and whenever there is available time without the need to depend on the real device;

4) A larger group could contribute to porting and developing apps for the N900 device if only they could use the emulator without having to buy one real device. For instance: an upstream maintainer of some package could agree to accept some patches and even test them on the emulator.

Last edited by chemist; 2010-01-23 at 16:15.
 
Posts: 316 | Thanked: 150 times | Joined on May 2006
#2
I always thought you could target code at ARMEL in the SDK?? It's certainly there as a target option.

I'm having trouble with Xephyr at the moment but ISTR it was doable with the 770 SDK.
 

The Following User Says Thank You to jaark For This Useful Post:
Posts: 292 | Thanked: 128 times | Joined on Dec 2009
#3
Originally Posted by jaark View Post
I always thought you could target code at ARMEL in the SDK?? It's certainly there as a target option.
Yes, you can compile to an ARMEL target but you can't run it. At least, you can't run graphical applications in the ARMEL target.
 
Posts: 316 | Thanked: 150 times | Joined on May 2006
#4
Yeah, I meant compile and run. I did say that I was thinking back to 770 times that and the fact that no-one has backed me up leads me to believe that it's likely I have delusion brought on by poor memory
 
javispedro's Avatar
Posts: 2,110 | Thanked: 4,087 times | Joined on Jan 2009 @ Barcelona
#5
The only thing missing for this is more complete qemu support, and qemu is an OSS project. The rest of the infraestructure is out there and in fact someone booted Diablo in qemu a year or so ago.

What is missing for qemu to be able to emulate a N900-like board? CPU documentation? Board documentation? Or just plain man-hours?


Note that either way I don't see most of your points, since an ARM emulator isn't going to give you all the hardware the real device has, like the accelerometers or 3d graphics, and thus you end up needing a real device either way. Nokia gets this and thus they allow you to test your applications on real devices:

http://www.forum.nokia.com/Technolog...Device_Access/

Last edited by javispedro; 2010-01-23 at 01:58.
 

The Following User Says Thank You to javispedro For This Useful Post:
Posts: 292 | Thanked: 128 times | Joined on Dec 2009
#6
The problem of not being a complete N900 device (no accelerometers, sensors and so on) is a good point. Nevertheless, most of the points are still valid.

Take, as examples, Java MIDP emulators, Windows Pocket PC emulators and Palm emulators. All those emulators didn't have touch screen, sensors, and network hardware just like the original devices, but they did have mappings for all those: regular emulator menu controls would control how the emulated hardware would "perceive" actual sensor data. Say you want the light sensor to show 100% light, just move the emulator light sensor slider to full 100%. The same mechanism can be used for all other sensors and hardware, some will be more difficult than others, of course.

In any case, there could be scripting to help change sensor data while running an application. This way you could test how you application behaves when a call is coming, etc. It would be possible to test difficult to test or expensive use cases. Suppose you are developing an app that logs international roaming call costs and durations. You could just script the sensors to show roaming to another country and start and end some calls.

As for the Nokia RDA and Device Anywhere, I didn't see N900 listed there yet. However, wouldn't an emulator be more flexible? Since the real devices already have some features blocked or not available (audio, GPS signals, outgoing calls, SMS, etc) the emulator could even be considered "better" in that it could at list simulate all events with simulated data.
 
Posts: 40 | Thanked: 16 times | Joined on Aug 2008
#7
Originally Posted by soeiro View Post
Brainstorm:

http://maemo.org/community/brainstor...n900_emulator/


It would be very productive for the developers (and even for users) if there was a complete N900 emulator.
I completely agree with you.
 
chemist's Avatar
Administrator | Posts: 940 | Thanked: 1,495 times | Joined on Sep 2009 @ Germany
#8
Originally Posted by soeiro View Post
1) Test new software on it *without* the risk of thrashing the real N900 device;

2) Instead of warning users not to install software from extra-devel or extra-testing we could warn them to first test that software in the emulator and, why not, give some feedback;

2) Have a development environment that doesn't require the real device for testing and debugging;

3) One developer could configure the SDK + emulator on his/her home system, office and notebook. Then he/her could use git or mercurial to synchronize it all and be able to code wherever and whenever there is available time without the need to depend on the real device;

4) A larger group could contribute to porting and developing apps for the N900 device if only they could use the emulator without having to buy one real device. For instance: an upstream maintainer of some package could agree to accept some patches and even test them on the emulator.
Ad 1, SDK is in place
Ad 2, normal users wont use the emulator, that many did brick their device yet or did other stupid things by using repositories and bare .debs not ment to be for them... hints "you may brick your device" should stay as most avarage joe users are not able to test software for good and will brick their devices even with software they tested..."yeah it starts... lets install on to device... ah what should I do it doesnt boot anymore... the community sucks... why nokia doesnt fix this... n900 sucks... I want my money back..."
and this will stay

Ad 3 and 4, SDK is in place, well it is missing buttons and sensors but that could be coded for the SDK as add-ons.

if you are talking about windows SDK and a device shown in a window that you are bale to move around and press buttons and so, have fun...
 
Posts: 292 | Thanked: 128 times | Joined on Dec 2009
#9
Originally Posted by chemist View Post
Ad 1, SDK is in place
Ad 2, normal users wont use the emulator, that many did brick their device yet or did other stupid things by using repositories and bare .debs not ment to be for them... hints "you may brick your device" should stay as most avarage joe users are not able to test software for good and will brick their devices even with software they tested..."yeah it starts... lets install on to device... ah what should I do it doesnt boot anymore... the community sucks... why nokia doesnt fix this... n900 sucks... I want my money back..."
and this will stay

Ad 3 and 4, SDK is in place, well it is missing buttons and sensors but that could be coded for the SDK as add-ons.
I don't quite follow how itens 1-4 are in place. Do you mean it is now possible to run (and debug) ARMEL code on the SDK? This is what I'm looking for.

Originally Posted by chemist View Post
if you are talking about windows SDK and a device shown in a window that you are bale to move around and press buttons and so, have fun...
What I've asked for is to be able to run complete graphical ARMEL applications in the SDK. Furthermore, it would be easier if all that could be package as an QEMU image to be run in whatever OS the developer uses. In my case (I use Debian and Kubuntu) I'm happy that I can use the current SDK.
 
javispedro's Avatar
Posts: 2,110 | Thanked: 4,087 times | Joined on Jan 2009 @ Barcelona
#10
So you want slow emulated native compilers...

Ignoring that, here's http://code.google.com/p/qemu-omap3/ .

Last edited by javispedro; 2010-01-25 at 18:34.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 20:48.