I am looking for a ARM based hardware development kit for porting Android OS on it.
My objective is to port Android OS on ARM based hardware platform and write Modbus drivers to provide serial communication support for Android based mobile phones. I an going to write Android mobile Application that will communicate my hardware board through modbus drivers.
I did some Google search and found that Beagle board is most preferable for this project and also their is huge developers community available if in case of any help.
Is their any other ARM hardware platform best suited for my project?
Try Technexion
We're using it for our (XLogic) projects, we have developed similar CAN/ModBus solutions in the past and found their TAM-3517 modules to be optimal for our prototyping needs.
It's basically a SO-DIMM 200pin form factor Sitara (OMAP3, mostly Beagleboard compatible) platform, featuring most of the needed interfaces, with decent support and dev-kits. They have already ported Android onto the platform, so you just need to add your secret sauce and be done with it.
On a somewhat related note, please ping me if you're interested in collaborating on getting industrial protocols Android APIs somewhat standarized - this is a very interesting field and we could have an opportunity to establish a reference implementation.
Go to www.linaro.org and see if their Android releases work for you. They already have Ice Cream Sandwich running on Panda and Snowball boards (although no releases just yet, I think), so you might like to try one of those.
Related
Is Way To Run Machine Code Instead Android OS In Android Devices ?
I Want Remove Android Os And Work With Cpu And Other Devices Directly .
What Compiler I Can Use ?
MASM is an x86 assembler, so it would not be suitable for most Android devices as the vast majority use ARM-based processors.
That said, Android phones are computers just like any other and can be programmed in assembly. The first thing you'll need to do is select a device running a well documented CPU and chipset.
Since you'll be removing Android and plan on programming in assembly you'll need to write your own routines for nearly everything. An understanding of the CPU, power management and some form of I/O (you can avoid having to write complex display code if you plan to interface with the phone through serial communication, for example).
Unfortunately, much of the information required for successfully writing your own OS for an Android device is unavailable so you'll need some hardware analysis tools to assist in reverse engineering some of this information. A logic analyzer may be useful in sniffing some of the protocols used between chips, although much of modern phones is done on a single SoC, so you'll need to experiment heavily and compile information from a wide variety of online sources.
Aside from that, it's smooth sailing. Programming an OS in assembly for Android is pretty much the same as programming an OS in assembly for any other computer and you'll find it to be rather familiar territory.
I need to make an architectural decision for developing (actually porting) my embedded solution.
I will try to present my case as clearly as possible, and any advice I can get will be appreciated.
Introduction
I have an embedded system, currently developed on ARM11 architecture and ArchLinux OS. It is implemented using all kinds of technologies available under Linux, including C, C++, Bash and Python.
At this time, I would like to port my solution to a tablet, so I am trying to make some decisions about the architecture, based on the requirements of my system.
Requirements
The system is modular, and it runs multiple processes and threads. It also communicates to remote servers and controls the hardware peripherals. These are the basic requirements, at the moment, I will update as discussion develops:
Primary:
Dedicated system (minimum amount of other applications running, even in the bg)
Multiple processes, ability to set priorities
Ability to assign a process to a single CPU Core (cpu affinity)
Inter-process communication mechanisms
Complete hardware control (WiFi, 3G, GSM, mic, speaker, display, ...)
Creating sockets, etc.
Other:
Ability to connect a microphone directly to a 3.5mm plug (TRRS connector)
Mainstream solution to ensure reliability
Future-proof: minimize the porting effort for new tablets and HW
My questions
What tablet and OS combination would meet these requirements?
How to approach the "dedicated solution" requirement?
How to approach the software development, what language and tools to use?
My investigation so far
My investigation so far has been concentrated on the OS choice. The main options seem to be Android and Ubuntu Touch. Here are my thoughts:
Android
Android wins in the mainstream category obviously, but...
I have no experience of Android development, but as far as I can tell, I can either develop a Java application that runs on top of Dalvik, or I can go native via Android NDK. Maybe I can even bypass the whole thing and go native side-by-side of Dalvik, and develop in Python? I guess then I will lose the access to the API for HW access. Not sure how I would access the HW then. But if I go with Java development, this is a sandbox solution, and I am not sure if I can have such a control over the processes, HW and CPU core affinity?
Ubuntu Touch
Developing on Ubuntu Touch would be more like Linux development I am used to, since it uses Qt. The issue here is that the applications are developed using the SDK that restricts me to HTML5 and QML, which I'm not sure can allow me the same control over the system I need. If I use Python and avoid the SDK, same issue arises - how do I control the HW? Of course, there is a way to do it like on a regular embedded system I guess, but I don't want to reinvent the wheel if I don't have to.
Also, it seems that Ubuntu Touch hasn't been ported to many devices yet, only a handful of them are supported.
Finally
I am not sure how well I have presented my case, but I will update the question as needed with further explanations and requirement details. Thank you for your patience, your time and any help you may offer.
I am in the same boat as you, we are developing embedded system on ARM CPU. Currently the system is written in Python on custom built linux distro from hardware vendor.
We have been looking at Android and Ubuntu Touch for a few months. So far we didn't get any decision yet. But here what we found out from our incomplete analysis:
Android is quite heavy system, that also brings JVM into the mix. So you HW and memory requirements will significantly increase.
Android likes to take over the entire system, so sometimes you might be fighting with Android.
Android has very good IPC mechanisms, not available on mainstream linux kernel, such as Binder. Of course you can port it to another system. But this would be considerable effort.
Android has very rich GUI interface, also with things like NDK view you are not confined into the JDK box.
Android doesn't use standard GNU C library, it uses something called BioniC which is a port of C library from BSD. Usually it is not a problem for most software, but if you are using some linux specific low level features, like working with serial ports you will need to tweak your code. See what I had to do to port Java RXTX library to android https://github.com/vladistan/gnu.io.android
You can find a lot of Android developers out there who will do basic GUI programming for you, while you are concentrating on your app specific stuff. Interfacing between GUI and low level things is quite easy using binder. And of course you can bring in whatever mecahnism you want via NDK.
We have considered Ubuntu Touch. But so far it doesn't seem to be mature enough.
I'm trying to chose the ARM development board for education purpose.
The goal is to learn how to run and play around with systems like Android (version 2.0 or higher),Linux, Windows CE. It must support touch-screen, Ethernet, USB host and device.
I've found many boards, the most interesting is Android6410. I've search Google and it seems that it is not very popular. Has anyone used it? Is it well documented? What about the support? How about the performance under Android?
I've also found some other development boards:
http://www.friendlyarm.net/products/mini2440?lang=en - the most popular one but probably it is too slow for android 2.0.
http://www.friendlyarm.net/products/mini6410?lang=en - the same CPU like Android6410 but it seems to be a new product so the support may be pretty bad
http://beagleboard.org/ - quite interesting and popular but no touch-screen in standard version. The external ones are very expensive (twice as expensive as the board itself)
http://pandaboard.org/ - very fast but also doesn't have standard touch-screen connector, no Windows CE support
Any hints will be appreciated.
Samsung has provided an android kernel, as well as a reasonably current "generic" linux kernel) that, amongst other Samsung SoCs, also supports the 6410. The Git repos are here:
https://android.googlesource.com/kernel/samsung
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git
These do provide smdk6410 defconfig targets.
You also need an odroid bootloader (uboot for 6410) to be able to flash new kernels onto the board and/or the SDcard it boots from, as Samsung uses a special "fastboot" utility for this purpose (very different from OMAP which just puts the kernel into a file).
I can't comment on the performance of the device compared to others, as I haven't run extensive benchmark tests or anything, sorry. You're right, it's way ahead of 2440; it's an ARM1136 CPU, so it'll end up somewhat slower than the Cortex-A chips from omap3/4 boards.
Try the FL6410: http://www.arm9board.net/sel/prddetail.aspx?id=363&pid=200
A nice board with great Android support!
I am working on a system on which currently linux kernel and microwindows windowing system is running. Code of current linux system drivers is available to me. I want to port android on it, just as a hobby project.
can you please tell me what all understanding of linux-kernel is required to port it?
Please give me references (Books, Tutorials) to build-up understandings.
Thanks, Sunny.
P.S. I have basic understanding of linux.
Configuration of device is
450 Mhz ARM9,
64 MB RAM,
256 MB NAND
480x272 resolution.
Since you already have Linux up and running on your board you most likely won't need to have a deep understanding of the kernel. It will need to be modified, however, to include the following additional Android specific features. This may be as easy as applying some patches but it could be more involved.
Low Memory Killer
Android Logger
Android Shared Memory Subsystem (Ashmem)
Android Power Management (Wakelocks)
Binder IPC
In user space, Android uses its own display software called Surface Manager so you won't be using the Nano-X Window System (formerly known as Microwindows).
For an overview of what will likely be involved in a port, I would give the Android Porting Guide a read.
Websites on porting Android to other ARM based devices that may include helpful tips:
Beagleboard (Cortex)
Rowboat (I tried this one and it works)
Embinux
Zoom OMAP (Cortex)
OMAPpedia
Nokia Internet Tablet (ARM9E)
NITdroid
Neo 1973 (ARM9TDMI)
Benno Leslie's Blog
Intel Bulverde Evaluation Board (XScale)
NemusTech Blog
Sharp Zaurus SL-C760 (XScale)
EU Edge Blog
Online groups that may be able to help:
Android Porting
Android Internals
Android Platform
To start porting Android, a basic understanding of the changes to the linux kernels is required. Also, you'll need to understand which drivers besides the Linux are required.
linuxfordevices describes what was changed to the Linux kernel for the sake of Android. They also provide handy links like a diff of the changes they made....
On Android architecture, I found the youtube presentation Android Architecture]1 helpful.
I expect some issues in the display resolution. Android applications expect a number of standard resolutions. As a first step, I suggest to limit display to the next smaller size and then improve on this once it is up and running.
Since I've looked into Adroid for use in e-readers, I'm very interested in the porting myself. For this reason, I have registered for a (web based) training on android hardware (porting). I have looked for books etc. on the subject, but the books I found were much more on using Android and writing applications.
Have a look at these books as well:
Android - A Programmers Guide
Professional Android Application Development
I am going to develop a handheld device which has an Atom processor. I am thinking of using Android embedded OS for running telecom applications on this device. I have heard from my friends that Android is good for wireless applications. But my device does not need any wireless application. I will need only data (ping, traceroute...), IPTV and VoIP applications to run on this device. So is it advisable to use Android for my device?
In my opinion the biggest benefit you get from running a OS like Android as opposed to a tailored Linux distribution are:
An application ecosystem, that integrates well
A UI environment suitable for small screens
An Application SDK that makes developing new apps pretty straightforward
Drawbacks of using Android IMHO:
No standard libc. That means you will have to do some porting, to get mplayer or something similar to play your media content
Way less libraries than you have, when you use a "regular" Linux distribution
You can only create apps with UIs using Java (well there are other possibilities but you probably wouldn't do it)
It comes down to choosing what hurts less. My estimate if you have powerful hardware and a big screen (the combination of Atom and IPTV sounds like that) than using a LFS (Linux From Scratch), Ubuntu or something similar and create a flashy UI on top of that (using QT, OpenGL, GTK, Swing, ...) is less pain than porting your libs & apps to Android.
Of course you loose the sexy Android label which decreases probability of making it to Engadget :-)
Have fun tinkering!
Android uses a Linux kernel, and is designed to support Java applications. So perhaps you need to consider whether Linux and Java are suited to your application. You may be better off with a straight Linux kernel.