If your next application will be deployed on a 32-bit or 64-bit processor and TCP/IP network device, then now is a good opportunity, because you have considered Linux or Android as your embedded operating system. Comparing the original real-time operating system with the embedded kernel, both Android and Linux are mature enterprise/desktop operating systems. They all run off-the-shelf middleware and packaged applications, even in specialized embedded and mobile application environments. However, these two open source operating systems are different from the bottom of the software stack to the top layer of development, integration, and hosting, and these all affect how and where to find the best deployment solution.
This article will sort out the determinants to consider when choosing a small green robot or chunky penguin. In particular, this article focuses on why different development methods are needed under different usage scenarios. Why is this operating system used instead of the other one? Why do some applications only use one operating system, and sometimes they need both? Operating system.
The following content section represents a classic “thought movementâ€, but in fact the discussion stems from a series of dialogues around project objectives that are based on energy management, IVI (Automotive Infotainment System), network, and smart display devices. Product design debate.
Most of the original embedded systems are very closed entities. Even if the selected real-time operating system supports standard APIs (typically a subset of POSIX threads and/or BSDlite networks), applications that are carefully customized or hosted on those platforms for embedded platforms are highly customizable. They are also the only software that runs on those systems throughout the life cycle. In contrast, software deployed on smartphones, tablets, and more and more modern smart devices has become more like desktop server software. With more and more modern devices, original equipment manufacturers, operators, and end users can already install new application packages throughout their use. Firmware and system software can also be upgraded without relying on special workbench software or factory RMA (renovation) programs.
When creating a smartphone operating system, Google positioned Android as an open, field-upgradable application platform. The core idea of ​​this mobile operating system is to be able to run application packages at any time. Therefore, in order to create, sell, and deploy packaged applications, the optimization of the Android platform's eco-environment is first performed through the Google Play Store.
The embedded Linux system also has the same situation as the Android application platform, but from a practical point of view, it is more suitable for one-time deployment in closed box applications. Indeed, there are more recognized programming methods for programming on Linux, such as C, C++, Java, Ruby, Python, Lua, etc., but there is no single model for building, publishing, and installing applications. There is no hardware abstraction model that, like Android, supports (if uncertain) interoperability. Instead, there are a number of specific methods (such as package management, apt-get, etc.) and common/best practices that work in different kernel architecture trees (Kernel Tree).
For these pragmatic reasons, Linux is somewhat more suitable for closed or semi-enclosed embedded applications. If you do not need extensive interoperability and you don't have to worry about breaking APIs and packaging applications, original equipment manufacturers (OEMs) can be freed from constraints; this can also allow them to specialize in hardware and software requirements for the device. Freedom from customization and adaptation to Linux. If an ecosystem evolves around a single device (as it happens on the Raspberry Pi and Python), the Linux example can always break the closed box strategy, as if using a Dalvik virtual machine like Android, which favors Java.
One thing to note is that do not confuse open and closed boxes with open source and open source issues. The Linux kernel and the GNU/Linux operating system are far more open source than Android. The community that maintains and upgrades Linux is a truly elite-managed community, and it is open to all sources of resources. In contrast, Android is a private club where Google and its top partner, OHA, can dictate and control the roadmap for the development of the platform. It only accepts minimal input from outside organizations.
Do you want to budget or save some money?The problem with open/closed boxes is the question of whether the resources are rich or not. One example of an extreme resource shortage is to say that there is only one big device with a network interface, and an extremely resource-rich design requires a monitor, keyboard, pointing device or touch screen, a robust memory and memory components, and so on. The most realistic design in the world is somewhere in between.
Given the legacy of its smartphone, Android is suitable for consumer electronics applications with rich interfaces. Outside of the box, the Android protocol stack supports handheld and tablet type configurations, and it is increasingly being deployed on DTVs, set-top boxes, IVI systems, and other user interface-intensive systems. Therefore, there is not much convincing reason to convince people to use the Android system on a headless system.
On the contrary, the range of hardware configurations and peripherals that Linux can support is very extensive and rich. It can also be reduced to an extremely compact system with only memory, memory, etc., as needed. If you do not have hundreds of MB or even GB of DRAM or more Flash space (for operating systems and applications), you cannot deploy Android on such a system, but you may only need tens of MB of storage. Deploy a simple embedded Linux system (Oh, I never thought I would think Linux is so small!). Another reason not to vote for Android when choosing a system for thin hardware configuration is that Android is a CPU/GPU-intensive system.
So, if your design is intended to reduce costs by deploying a low-end CPU, not using a GPU, and minimizing memory and memory, then Linux is a more appropriate choice. If you have a lot of money to "burn" - these years, the price of silicon is only a few dollars, but the monitor and input hardware is likely to need tens of thousands of dollars, then this time Android will be more suitable for you.
Local display or Bring Your Own Device (BYO)?In last month's RTC magazine, I wrote an article on selecting available devices as display servers for headless systems. In this article, I emphasized how local uncapped system design can be used with nearby or remote browser-based display devices, including smart phones, digital televisions, and more. On the premise of choosing one of Android and Linux, the need for a local or remote monitor is another deciding factor. If your device requires a close-to-physical contact display, Android with an integrated user interface (UI) is a good choice. But if the user mainly wants to interact with the device from a browser or a dedicated smartphone and tablet application in the distance, then you can support the use of embedded Linux to host Apache services or several small Web servers. The programming paradigms (PHP, Python, C, etc.) achieve the goal of eliminating the overhead of the Android system.
Of course, you can configure both Android and Linux to support local displays, network interfaces, or mobile applications as needed. Both operating systems support rich user interfaces and are easily deployed as Web servers. However, ready-made Android applications can only be run and displayed on an Android native display device. Linux native applications created using GTK+ or Qt require a local monitor or an available remote X server.
Choose Java or C/C++, or LAMP?A semi-technical argument is that Android or Linux is a familiar programming language and framework. If your team has already created Java applications in some other environment, you will probably want to use this expertise to create applications (even headless devices) on other devices. But if your developers are more familiar with C/C++, Lua, GTK+, and QT's similar UI frameworks and countless other programming paradigms, then it is highly recommended that you choose Linux and/or LAMP (Linux, Apache httpd, MySQL, and PHP/Perl/ Python).
This argument is not very clear. It must be discussed with other people present. You can also use the Android/Linux native programming interface to create your embedded application, but you may break the Android application's interoperability and packaging and no longer have an open box. Also keep in mind that when choosing a language or framework, it is often necessary to consider whether it is a local display or a remote display. In addition, perhaps the more liberating idea is that today's developers are proficient in multiple languages, so whether Android or Linux is used on Linux, the C++ or Web programming language will feel equally comfortable.
Consider a permitA set of non-technical yet complex licensing-centric selection criteria revolves around Linux and Android and applications and extensions written for both operating systems. Many native device manufacturers adopt Android because of the free license terms of this mobile operating system: In fact, the components of Apache 2.0 for Android middleware and its applications are only in the part of the underlying Linux General Public License (GNU GPL). Native equipment manufacturers have disclosure requirements. The top Apache licenses in Android always indicate "OEM friendly" because the device manufacturer modifies much of the Android stack and uses Apache and any other OSS licenses (Table 1) without the need to disclose changes And the Hardware Abstraction Layer (HAL) that distributes their own code adds the peripheral interface. The actual situation is somewhat complicated, as discussed in Black Duck's article "Android-Opportunity, Complexity and Abundance."
Table 1 Licenses for various Android and Linux stack layers
This is not an example of opposition to Linux - it is simply possible to perfectly isolate and protect proprietary code on a device running Linux. However, each type modified and added to the embedded Linux stack needs to consider its own actual situation (see Table 1). In particular, some native device manufacturers do not like to work directly under any of the GNU licenses (GPLv2/v3, LGPL, etc.), which leads them to choose Android instead of Linux. Of course, they still need to deploy the Linux kernel, but the Android libraries and middleware running on it only serve as a "buffer." Usually it feels comfortable to do this.
Here, our purpose is to provide general guidance for selecting Android or Linux for various types of smart devices. For vertical applications (cell phones, medical devices, transportation vehicles, etc.), the classification itself does not want to list all the methods. It wants to provide selection criteria that the development paradigm relies on, or to consider the device market and deployment life cycle. way.
Table 2 summarizes the arguments presented in this paper. It emphasizes that the choice is not absolute: Since Android includes a Linux kernel instance, the Android system can theoretically host and run the same software as Linux. Linux can also be hosted on a device with a local display because it can host and run Java, as well as a series of user interface (UI) frameworks, even on phones, tablets, and other devices that are closely related to Android.
Table 2 summarizes the arguments for the characteristics of Android and Linux
So, go and use Android or Linux or both. But you need to consider the following questions first:
How are system software and applications deployed throughout the life of your device?
Where do you want to spend most of your budget?
What are the user interaction modes of the device?
What programming hobbies do your developers have?
How does your choice of platform and license affect your company's intellectual property (IP) portfolio?
WARNING!
Do not plug two or more meters together!
IMPORTANT
Don't plug in an appliance where the load exceeds 16 Amp. Always ensure the plug of any appliance is fully inserted into the meter outlet. If cleaning of the meter is required, remove from mains power and wipe meter with a dry cloth.
KEYBOARD DEFINITION
1). SET: Set price with button UP.
2). MODE: Exchange display state.
3). UP: Set price combined with button SET.
GENERAL FEATURES
1).Display line power.
2).Display and memory accumulative total power quantity.
3).Display and memory total power charge of price.
THE DATA DISPLAY
Press MODE button the data displays as follows:
W →KWh →PRICE →COST/KWH
↑_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _↓
1). Plug in socket and power on, the meter will display real power.
2). Press MODE button once again and release, the meter will display accumulative KWh.
3). Press MODE button once again and release, the meter will display total power charge.
4). Press MODE button once again and release, the meter will display COST/KWH.
SETTING PRICE OF COST/KWH
1). Press SET button during display COST/KWH,the first digital COST/KWH flash, press UP button to set it.
2). Press SET button once again and release, the second digital COST/KWH flash, press UP button to set it.
3). Press SET button once again and release, the third COST/KWH flash, press UP button to set it.
4). Press SET button once again and release, the fourth COST/KWH flash, press UP button to set it.
5). Press SET button once again and release, the radix point COST/KWH flash, press UP button to set it.
DATA CLEAR
Press and hold MODE button for 5 seconds will clear KWH,PRICE and COST/KWH data.
Power Backlit, Backlit socket, power meter Backlit, energy meter Backlit, backlit adaptor, backlit plug socket
NINGBO COWELL ELECTRONICS & TECHNOLOGY CO., LTD , https://www.cowellsocket.com