Now that webOS is opensource I am trying to find any resources on building your own mobile phone in the US. That is put webOs on some custom hardware that has 3G voice access.
I realize this question is not a programming question but I could not find another StackExchange that was applicable.
I would suggest looking at OpenMoko and their history of attempting to release phones based on open hardware specifications for open source mobile operating systems.
Per the wiki article, Openmoko phones now support Android, Debian, Gentoo, Qt Extended Improved, QtMoko, and SHR. The announcement of the webOS opensourcing means that it's possible that webOS could be ported, as well.
You're likely going to have to wait a bit before using just any hardware. While webOS is going open source, right now the only thing that's released is Enyo (the application framework, minus the UI elements). There are other components to the OS that are still unreleased, and the OS runs on a modified linux kernel. They do plan, however, to release a version by the end of this year, called open webOS 1.0, which will run on a standard linux kernel.
Related
I'd like to start playing with ARM TrustZone, so I'd like to setup a development environment, unfortunatelly I have the feeling I'm still missing something, I don't know how to put everything together.
This is my current picture:
A SoC with a Cortex-A processor is required
is it possible to develop without a board? i.e. emulators?
TrustZone is a Hardware & Software technology
If I get a SoC board, is the hardware part already covered?
The software (OS/Kernel) part may be solved with GlobalPlatform, OpenTEE, etc.
TrustedApplications development
Which IDE's are there?
How are they deployed to the board?
I know this is a quite extensive question, I'll be happy to get links to online material.
Edit:
Some parts of my question were partially answered, but the most important thing hasn't been answered yet: is the picture I detailed correct and complete? Yes/no, why?
And no, this is not a duplicate of Which ARM based development boards should I use?
For emulator, you can use ARM Fast Model (https://developer.arm.com/products/system-design/fast-models) if you have the budget.
QEmu might have some Trustzone support but I am not sure how reliable is the Trustzone implementation (What works on QEmu might not work on real hardware). joakim-bech (one of the lead engineer working on an Open-Source implementation of Trusted OS) said in his stackoverflow response it should work; And he has still confirmed it in the blog post TEE Development With No Hardware - Is That Possible?...
I would recommand you to have a look at the list of platforms supported by Optee - Open Portable Trusted Execution Environment: https://github.com/OP-TEE/optee_os#3-platforms-supported
The answers to your other questions would really depend of the platform you use, your budget, your development environment, etc
For less than $150:
If you want to stick to Windows you might have to build qEmu yourself (qEmu seems to support Windows but I am not sure if the Windows already-built binaries support Trustzone). In term of HW board, I use the Hikey board (currently at $119) for my Trustzone development.
Using Linux for the development will probably save you some time as for this budget you will probably have to use Open-Source solutions that generally primarily support Linux.
To start developing a Trusted App for OP-TEE:
I used this presentation: https://www.slideshare.net/linaroorg/lcu14103-how-to-create-and-run-trusted-applications-on-optee
I updated/improved the original example code, my changes could be found here: https://github.com/oliviermartin/lcu14_optee_hello_world
I have compiled a simple executable application written in C, using the arm-linux-gnueabi compiler for ARM.
How to run it on device?
Assuming that I have two devices for test it:
A Samsung phone with Windows Mobile 6.1, ARM926EJ OMAP1710 processor
A Foston tablet with Android 2.x, the processor name I not found but is one of processors in the ARM family.
If is not possible run it on the current operating system, then how to format the device and put my kernel instead of Android/Linux?
An application is typically built to run on top of an operating system. An operating system is typically built to run on top of hardware. Keep this in mind.
Running your application instead of Android/Linux implies that your application is a operating system of some sort. If you didn't write or include explicit code to control the hardware chips in the device, then you are only asking the wrong question, you should ask "I've wrtten an application in C, now how do I run it on my phone's operating system." If you did write or include explicit code to control the hardware chips in the device, then you did ask the right question (but some of the details seem off). This style of development happens a lot with the arduino/PIC/embedded ARM community.
Assuming you are not doing embedded development, the application must be compiled with some understanding of what the operating system offers (against the operating system's available api's) which generally makes them incompatible with other operating systems. This means the first step is to determine what operating system you are targeting, and obtain it's development suite. Once you have that, assuming that it supports C code (as most do), the suite will recompile your source code in a format that is both compatible with the CPU of the device and the API of the operating system on the device.
Small devices like phones typically run operating systems that have a tiny fraction of the features of a PC, so be prepared for fewer convenience features, and possibly "missing" libraries. That said, if you do get it to compile, typically you then hook the device up with the supported "bus" (USB is very popular), and save the program on the device (which sometimes involves sending "development / debugging" codes across the bus, and the development suite does this for you).
If everything worked well, you can then launch your program from the phone. If the program misbehaves and renders the phone inoperable, each development suite / phone has specific instructions on how to recover or reload a fresh operating system.
Here are resources for a few well known platforms (and percentages of the phones using them)
(worldwide according to Gartner's latest study, US according to Nielsen's latest study)
As referenced from wikipedia on 4/27/2012
(52%, 46.3%) Android Standard Development Kit
(16.9%, 1.4%) Symbian Standard Development Kit
(15%, 30%) iOS Phone Standard Development Kit
(11%, 14.9%) Blackberry Phone Standard Development Kit
(2.2%, 0%) Bada Standard Development Kit
(1.5%, 5.9%) Windows Phone Standard Development Kit
Note that these measurements are like most surveys, while they attempt to be random and unbiased, they are prone to measurement error and sampling error, so the numbers are more useful as relative indicators than absolute values.
I need to create a web-controlled application (that lives in the browser) that can connect to and read data from devices connected via USB or the serial port.
At the moment, I'm using an ActiveX control to do this. However, I'm like to re-write this system to make it cross-browser (support Firefox) and eventually cross-platform (support Safari on Mac). ActiveX is neither cross-browser or cross-platform, so I'm looking for an alternative technology.
My first inclination would have been to use Silverlight, because Silverlight 4 grants access to COM Automation. Unfortunately, this only works with OOB (Out of browser) Silverlight applications - in-browser systems are still bound in a sandbox and do not have access.
So, what technologies exist (frameworks, browser plug-ins, etc) that will allow me to interface with a USB/Serial device from within a browser-based web application? What are the pros/cons of each?
I think your best bet is probably Java in this case. USB, though an industry standard in terms of protocol is definitely not standardised in terms of bare-metal implementation. For this reason, you will still need a different Java USB implementation for each distinct platform (windows, linux, osx, bsd) that you intend to support. Of course you will also have to pay for code-signing certificates so you can try to convince people to grant your application the kind of access it requires; something that browsers try very hard to deny access to and most people in this day and age are very unwilling to grant. That said, there's an old IBM article here on the various Java USB projects that makes a good read. Good luck.
http://www.ibm.com/developerworks/library/j-usb.html
-Oisin
It might be painful, but you could use a signed Java applet. Signed Java applets can have full access to the user's system.
Java does not have built in USB support, so you would probably need to roll your own JNI interface to native USB APIs.
Using JNI in an applet can be tricky. I've done it before. If you Google the topic, most results say "don't do it" or "you can't do it." Well, you can do it.
This is how I did: I packaged the native libraries (DLL, so, etc) inside the applet's JAR, and then read the native libraries out of the JAR using e.g. getResourceAsStream. I then wrote the libraries out to an appropriate location on disk (e.g. ${user.home}/.myapp/.) I then used System.load to load the JNI DLL.
There can be some ClassLoader issues with JNI libraries and applets. The issues are subtle and difficult to explain. They basically have to do with the fact that a JVM can only load and bind a given JNI library once per VM instance, but applets get instantiated a lot, often with their own new ClassLoader, which can be problematic. The work that Sun did on process separation in the Next Generation Browser Plugin may have relieved some of these issues, but your users will only have this if they are using Java 1.6.0_10 or later.
It is also possible to use JNA within a signed applet. I would not recommend using JNA to access USB APIs directly. But JNA can sometimes be a big time saver for accessing simple native functions. Although once you've set up your JNI infrastructure, JNA probably has less value.
Here are a few other random thoughts:
Java WebStart - Can be launched from browser, but runs outside the browser
Microsoft ClickOnce - Can be launched from browser, but runs outside the browser
Flash / AIR - Can't escape its sandbox
The best solution I've come across thus far is the cross-browser/cross-platform plug-in system called FireBreath. This is a framework built in C++ that allows you to generate plug-ins for both ActiveX and NPAPI from the same codebase.
So build it once, make it work, and it compiles to one DLL that you can deploy in either environment: ActiveX for IE, NPAPI for everyone else.
After reading this post and some derivative publications (ddotdash.com) I wonder whether it is possible to use a handheld as a main platform for development of web applications for mobile web browsers.
For web development I use a rather common set of tools: Cheap netbook, Ubuntu 9.10, Ruby on Rails, VIM, GIT. I think it is possible to use all of those on Nokia n900 due to the fact that it has Maemo OS on it which is based on Debian (all debs are possible to install and you can always compile problematic debs from source).
Nevertheless, I am concerned with 3 problems:
Display size. I have 1280x800 resolution on my netbook and it is convenient for me to have Terminator (multiple consoles), VIM, file browser, Firefox and some PDF books opened at the same time. I wonder if it would be possible to use all these apps on 800px horizontal resolution.
Computing power: Via Nano (or Atom) processor does not distinct dramatically from that on Nokia n900 (at least in MHz), however I wonder if 256+768(virtual) memory on Nokia will be enough for my work (I have 3 GB now on the netbook).
Keyboard. Frankly it is not a problem due to the fact that I have Nokia su-8w bluetooth keyboard that is comfortable enough for touch typing. However it is interesting to read some comments on this problem. [Edit]: Bluetooth keyboard is not so comfortable - a developer has to dispose a handheld on the keyboard and it is not easy to look at the small screen from such rather big distance (keyboard can be placed on a table or on the knees only).
Having solutions for the problems mentioned above, I will have an opportunity to exploit all the wonderful advantages of the mobile development platforms, such as:
work from anywhere (it is important for me);
develop for the same form-factor that is used by the developer and intended users both;
pocket-size working tool :)
It may well be possible - the question is how much energy you'll expend compensating for all the restrictions. It's like developing in Notepad: possible, but not a pleasant experience.
I develop a bit on my netbook too, and it's okay - but I wouldn't want to do it all day.
It's certainly quite cool to be able to develop on a handheld device, but I don't think it's really practical for significant amounts of code. If this is for your own personal pleasure and you think the benefits outweigh the costs, that's one thing - but I wouldn't do it for commercial apps.
I would like to ask a few questions regarding mobile game porting...
Let say if I have a simple 2D C++ game engine and have a PC game based on that engine and I want to port it to different mobile platforms BREW, J2ME, iPhone, Android, Symbian, etc..
Do I need to re-code the engine and the game for each platform? or is there an easier and more efficient way? I am sure the process is complicated since different phones have different graphic/processor/memory/etc. I am just curious about the overview of mobile game porting process. :)
Thanks!
There are several ways of attacking mobile game porting. First of all, until very recently it was mostly BREW and J2ME. The iPhone, Android and BlackBerry are changing this landscape and making the impossible task of mobile game porting even more impossible. I worked in 3rd party mobile game development for many years until recently. I watched BREW vanish and saw publishers completely focus on J2ME as the cost of porting is strangling the industry. There are estimates to its cost, both time and money, and it seems to bell curve around 50-60% of the total development cost for each game is just porting.
At our company, we handled porting by having two engines that paralleled each other, one in BREW, one in J2ME. We never supported Symbian as Symbian development does not make any money. It is mainly for high-end tech demos that might be on one or two devices, nothing that could reach the mass market. Plus, most Symbian phones supported J2ME.
We would be required by publishers to provide any where from 7-23 reference builds of the game, targeting many different devices, in both BREW and J2ME. Just before moving on, publishers were also starting to require a J2ME touch screen reference version, and an iPhone SKU was being left as "to be determined" based on the final product and how cost effective an iPhone version would be at that time. The reference versions would then be passed on to a porting house to translate the different references to the thousands of other required SKUs.
Companies like Gameloft still brute force their way through porting. That's why Gameloft's games are constantly at a higher quality than the rest of the industry. However, it is just not possible for smaller companies to attack the problem this way due to costs. Not everyone can afford an office in Beijing with 5000 developers.
There are many companies out there developing engines to cut porting costs. Mobile-Distillery is one I was in contact with quite a lot, but we ended up never using it. So, I can't vouch for them. The problem here is that you will be at the mercy of another companies engine. Performance could be problematic due to the fact that it is being built to target thousands of SKUs. Plus, you really have little control over the low level implementation of your game in this instance. The end result seems to be a game that targets the lowest common denominator of phones.
Finally, a lot of developers are just abandoning the idea of supporting all mobile platforms. There is a huge flood on games on the iPhone because 1) it requires only targeting one platform and 2) there is a 70 percent profit share through the AppStore for developers. Through carrier releases, the percentage is not even comparable.
This of course depends on in which language your "simple engine" is written. Java is supposed to be easier to move between platforms, since it in effect is a platform of its own. If your engine is written in something more low-level, like C++, it will likely depend on platform-specific libraries for graphics and input, since C++ doesn't provide you with that.
I can personally recommend edgelib as a cross platform layer for mobile games and application development.
It is widely used, offers excellent performance and supports most of the important smartphone platforms in existence today: Symbian, Win Mobile, IPhone and others.
Most important: It's cheap and offers a free complete evaluation until you decide to produce commercial content with it.
You can find it at: http://www.edgelib.com
You can see a showcase of games and other projects based on this platform at the site.
Unfortunately, BREW is not supported though. And since it isn't a real open platform, it poses quite a challenge compared to other mobile OS platforms as it's development community is mostly professional and not very "talkative" in online terms...
This will perhaps change as the competition is getting more open by the minute.
I am not affiliated with Edgelib... this is just my personal opinion. :)
There is no free lunch. The platforms you are considering are not compatible, most of then allow you to run C/C++ code so in theory you could port the engine to some Standard, such as ANSI, or C99 and it would compile in most of the platforms PC, BREW however this does not take in account the libraries your engine might need. For example if your engine uses OpenGL then it would work in the PC, and some consoles but on Symbiam devices you need OpenGL-ES which is not exactly the same, so you need an abstraction for all libraries you use.
About J2ME and Android they are Java platforms, so no C/C++ can be run there without any special VM lib at least. In this case you need to port the C/C++ code to Java which can be overkiling.
So my answer to this is while you can make an abstraction to your libs and code using standards you might be able to use the same engine in several platforms as long you can use the same compiler for them.
Take a look for example to this engine CubicVR it allows you to compile the same engine for PC/Linux/MAC/iPhone (maybe)/Sony PlayStation Portable
What I have used for multiplatform development is to implement a hardware abstraction layer. The engine is coded in C++ but using a plain C interface to implement the system calls. This allows you to use full-fledged C++ for your game and engine and link with the system abstraction written in whatever language your platform needs. Symbian doesn't support 100% of the features of C++, and still has a few bugs, and IPhone API uses Objective C. C is compatible which most of the platforms you mention (well, not Java) and linking C is easier than C++, as there are less problems (ABIs and all that stuff).
Implementing a additional interface in C is a little slower, but will help you a lot when porting it to other platforms. Also, it allows you to have a Win32/Linux/Mac build besides the Symbian, BREW, etc. one. I have worked, mainly, with Symbian and N-Gage, and the debugging capabilities of those platforms are signifficantly behind Visual Studio or GDB. Iphone, on the other side, has a lot of cool tools to debug and profile your app.
If the engine you have is not written in JAVA or FLASH I don't see a way that you can use your engine out of the box without recoding it in a language which might run on a mobile phone.
If it is coded in JAVA or FLASH, I think you're main problem (beside the performance difference between a phone and a pc) is the main memory. As I've heared, the main memory is the biggest problem in mobile phone game development.
As others have pointed out, if your engine is built on top of some 'platform independent' framework such as Java, then it's supposedly easier than if it's written in a lower level language. However, neither Java nor Flash is, for example, supported on the iPhone/iPod touch, and it'll probably take a while until they are. On the other hand, if I recall correctly, the only SDK available for those platforms is Objective-C, which, guessing wildly, you didn't use to implement your engine.
In general, it depends on the application/game engine you've written. Most likely you'll have to change something, as very rarely are all features available on all platforms. J2ME graphics is a classic scenario of 'platform independent'-dependence, or so I've heard. How much you'll have to change solely depends on how portable your code is, i.e. how well did you separate out the parts that potentially need changing.
Unfortunately, this is the best answer I can give you.