I am starting to create a QT application with sqlite for a hand held device. My Project Manager asks me to select an operating system (embedded linux) for the device (we are not considering android).
As in Desktop, are there many embedded-Linux distributions for devices?
If so, Which embedded linux I should consider?
You have multiple choices, but I will suggest the easier and - in my opinion - better two.
Buildroot - is a set of makefiles that lets you create your custom embedded distribution. Can take care of building the Linux
kernel, the toolchain and a barebox or U-Boot bootloader, too. Easily expandable and
with a practically zero learning curve. You have a fully working
system in a matter of hours.
Yocto - a fully fledged (and complicated) build system. Suggested over Buildroot when you need a LOT of packages/components
and may need flexibility in expanding the system directly on
premises. What you can do substantially depends on the "layers" (sets of rules for building things) available: you combine layers together to obtain your system. Has a steep learning curve but is used and directly
supported by multiple vendors (e.g.: Atmel, TI).
Anyway, unless you have more than good reasons, I strongly suggest the former.
There are several Linux distros to be used with ARM. Maybe you should consider Fedora ARM https://fedoraproject.org/wiki/Architectures/ARM
This is a difficult question to answer not knowing more about the project requirements (not just software requirements, but also non-functional ones as well) and capabilities of the platform.
Angstrom (based on OpenEmbedded) is another possibility for Linux.
I would challenge the assumption that the operating system must be Linux. Why? If time-to-market or having commercial support are important, you might be better off with commercial embedded or RT operations systems such as VxWorks or QNX.
There are also professionally supported Linux distros such as Montavista
Whilst free linux distros are, well, free, you are generally on your own and your team's time isn't free.
You can use Qt for embedded device , it’s fast and compatible with many hardwares and if your hardware is not supported, porting it to a new hardware is not so hard
plus it has special rendering system
Related
Can you send MPI messages across two libraries?
Example - If I have MS-MPI installed on a windows machine and then Open-MPI on a linux cluster (Same Network), can I get messages between code running on the two different OS.
Basically multiple program multiple data MPMD but using Windows and Linux resources.
Just need to know if this is possible, and if so any info would be nice, but not needed.
No, that is not possible. You will even get into great trouble if you try this with different versions or configurations of one implementation.
MPI is targeted at homogeneous installations on HPC systems. The communication protocol is not standardized, only the programming interface is.
In general: no. This is not specified within the MPI standard, and most implementations do not support such jobs. It is a rather uncommon use case, I guess.
However, Intel MPI does provide cross-os launching of jobs, see:
https://software.intel.com/en-us/mpi-developer-guide-linux-cross-os-launch-mode
Some detail:
Intel MPI, as well as other commercial MPI implementations are based on the MPICH open source project. I am not sure if cross-os launching can be achieved somehow via MPICH, though. A quick google research only provided negative, but possibly outdated results, e.g.
https://lists.mcs.anl.gov/pipermail/mpich2-dev/2005-July/000085.html
I have to port the application which is using the Qt3 library to a new embedded OS.
If the OS is not yet selected but it is known that it is not Linux/Windows, what is the general way of porting procedure? I mean what files should be changed and what are independed and can be left as is?
If it's not Linux or Windows you could be pretty stuck out the door. Qt is highly dependent on libraries being available for it to be able to build. This is not a no however, it has been ported to Symbian which is obviously not Linux or Windows. The big thing on that though is that it was ported by Nokia, who had amount of time and amount of developers, where those X's are reasonably big numbers.
Start by getting the Qt everywhere source code, work out what bits you're going to need and which bits you won't. If the platform has gcc/g++/another reasonably well understood C++ compiler you're in luck and you should be able to build the bits as needed. Qt does depend on standard libraries throughout so make sure they're also available in some form for the platform, and it does use some non-standard ones for some components so you'll need to know which aspects of Qt you're working on. You should be able to get some sort of toolchain from there.
I'd stick to platforms that Qt supports though, if you go off the beaten track you're looking into increasing your dev times and having very little useful support.
Here's a candid admission first -- that I know zilch about RTOS or Embedded programming, so folks who know better may help me frame the query more appropriately.
What would be the minimal FOSS RTOS (or any OS for that matter) with support for TCP/IP, SSL, USB and some basic file-system for low-end ARM devices like Cortex-M3's ?
Have not ruled out something like ARM9/ARM7TDMI, so an RTOS that has "optional" MMU support, may be a major plus. We are at present dabbling with few uncertainities like precise processor, MMU/no-MMU, running completely head-less (no display), however I wanted to start a little ramp-up.
Would gladly answer counter questions to clarify the requirement.
I believe that eCOS has support for all you need and is scalable.
Alternatively you could build from a self-selected kit of parts; choosing independent RTOS, filesystem, USB, etc. From different sources, and integrating them yourself.
X86 and AMD64 are the most important architectures for many computing environments (desktop, servers, and supercomputers). Obviously a JIT compiler should support both of them to gain acceptance.
Until recently, the SPARC architecture was the logical next step for a compiler, specially on high-end servers markets. But now that Sun is dead, things are not clear.
Oracle doesn't seem to be really interested in it, and some big projects are dropping support for that architecture (Ubuntu for example). But on the other hand, the OpenSPARC initiative intended to open source recent processors is quite promising, meaning that a lot of manufacturers could implement and use SPARC for free in the near future.
So, is SPARC still a good choice as the next target architecture for a JIT compiler? Or is it better to choose another one (POWER, ARM, MIPS, ...)?
I don't know any more than you about SPARC's future. I hope it has one; it's been tragic how many good architectures have died out while x86 has kept going.
But i would suggest you look at ARM as a target. It isn't present in big server hardware, but it's huge in the mobile market, and powers all sorts of interesting little boxes, like my NAS, my ADSL router, and so on.
Your next target architecture should definitely be ARM - power consumption in large datacenters is a huge issue and the next big thing will be trying to reduce that by using low-power CPUs; see Facebook's first attempt on this.
This question is for experienced Unix/Linux developers.
If you have found that you like Mac OS X better than *nix as a development platform, why is that?
I know that hardware configuration is more convenient and graphics are generally more polished, but I'm not referring to those things. I'm asking specifically about functionality related to software development.
Also, do the benefits still apply if you are mainly targeting Windows or Unix/Linux?
For most purposes, OS X is Unix. Aside from Xcode (which I personally don't care for), there isn't really anything there to make it better or worse than any other Unix-like system for development.
Most of the typical tools, libraries, languages, and interfaces are there, you'll even be using GCC for C/C++ work. As long as you're not developing against Apple/OS X-specific interfaces like Cocoa, you are developing on Unix.
I use OS X because it just works, thus not interfering with my development, not because it has magical fairy dust that makes it better than any other Unix for development.
I love Apple as a dev platform because I get all the power of the *nix commandline as well as Apple's developers tools (XCode).
The additional software/hardware polish, and quality of third party software make it all that much more enjoyable.
Mac OS X is not better than a Unix environment, it is a Unix environment: http://www.opengroup.org/openbrand/certificates/1190p.pdf
I'd go as far as saying it's probably the most used Unix, considering it's also in all iPod Touch and iPhones.
(As far as I'm aware, Linux isn't a certified Unix, but I may be wrong, perhaps a distribution/vendor went through that process.)
Sometimes, for professional reasons, you just have to have tools that are compatible with what your boss or customers use. This often includes proprietary tools like MS Office, whether you want it or not (OpenOffice can't always deal perfectly with Word documents). OSX provides this intermediate ground, where the developers can also be users or closer to their user base.