Active Topics
-
TLS 1.2 for N9 is ready (29)
to MeeGo / Harmattan by smatkovi - 3 hrs, 58 mins ago -
Error after installing Leste on sdcard (12)
to Maemo 7 / Leste by teroyk - 4 hrs, 45 mins ago -
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 3 days, 13 hrs ago -
Maemo repository (3)
to Community by torsen - 4 days, 5 hrs ago -
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 6 days, 9 hrs ago - more...
|
2010-01-22
, 13:39
|
|
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.
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: | ||
|
|
2010-01-22
, 15:37
|
|
Posts: 292 |
Thanked: 131 times |
Joined on Dec 2009
|
#3
|
Originally Posted by jaark
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.
I always thought you could target code at ARMEL in the SDK?? It's certainly there as a target option.
|
|
2010-01-22
, 15:49
|
|
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 
 |
|
2010-01-23
, 01:52
|
|
Posts: 2,355 |
Thanked: 5,249 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.
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: | ||
|
|
2010-01-23
, 13:45
|
|
Posts: 292 |
Thanked: 131 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.
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.
|
|
2010-01-23
, 15:01
|
|
Posts: 40 |
Thanked: 16 times |
Joined on Aug 2008
|
#7
|
Originally Posted by soeiro
I completely agree with you.
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.
 |
|
2010-01-23
, 16:13
|
|
Administrator |
Posts: 1,036 |
Thanked: 2,019 times |
Joined on Sep 2009
@ Germany
|
#8
|
Originally Posted by soeiro
Ad 1, SDK is in place
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 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...
__________________
useful links for newcomers: New members say hello, New users start here, Community subforum, Beginners' wiki page, Maemo5 101, FAQ
useful links for newcomers: New members say hello, New users start here, Community subforum, Beginners' wiki page, Maemo5 101, FAQ
|
|
2010-01-25
, 17:46
|
|
Posts: 292 |
Thanked: 131 times |
Joined on Dec 2009
|
#9
|
Originally Posted by chemist
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.
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.
Originally Posted by chemist
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.
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...
|
|
2010-01-25
, 18:30
|
|
Posts: 2,355 |
Thanked: 5,249 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.
Ignoring that, here's http://code.google.com/p/qemu-omap3/ .
Last edited by javispedro; 2010-01-25 at 18:34.
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.