I'm just now starting to learn embedded linux system development and I'm wondering how to go about a few things. Mainly, I have questions about cross compiling. I know what cross compiling is but I'm wondering how to actually go about the whole process when it comes to writing the makefile and deploying the application to the board (mainly the makefile part though).
I've researched a good amount online and found a ton of different things have to be set whether it's in regards to the toolchain, the processor, etc. Are there any good resources to learn this topic and master it or could anyone explain the best way to go about it?
EDIT:
I'm not wondering about how to cross compile in general. I'm wondering about cross compiling already existing applications (e.g. openCV, samba, etc) for a target system from the host system (especially when there is no support regarding the process with the application, which is common).
Basically you just need a special embedded Linux distribution, that will take care of cross-compilation process. Take a look at for example Buildroot. In folder package you'll find package recipe examples.
For your own software build process you can take a look at CMake. libuci recipe shows, how to use CMake based projects in Buildroot.
This answer is based on my own experience, so you're to justify, if it suits your needs.
I learned everything about embedding Linux with these guys: http://free-electrons.com/
They not only offer free docs but also courses for successfully running your box with custom Linux distros. In my case, I achieved embedding uClinux in an board with MMU-less 32 bit CPU with 32 MB RAM. The Linux image just occupied 1MB.
Related
I really like live smalltalk environment (though I only experimented a bit with Pharo), but there is one thing why I can't really use it for everyday development. It seems that it is not possible to create a native standalone executable from smalltalk system. The native standalone executable means to create a single executable file (PE on windows, ELF on linux, Mach-O on macosx), that a user could run by double clicking it without the need to install any additional execution environments. Am I missing something and it is in fact possible to create native standalone executable with smalltalk?
If we talk about Pharo specifically. I know that Pharo's environment includes efficient just in time compiler (that generates true native code from Pharo's VM bytecode), I know that the VM image can be stripped down by cutting of the code that my application won't ever need. So basically we already have almost everything (except the linker I guess) to be able to create native standalone executables. Cross-compilation shouldn't be a problem too, if we put all code generation stuff (for all target processors) in the image.
I know that in smalltalk world it is considered to be a good thing to deliver the whole VM image separately from the runtime environment, so the user can hack on software he/she is using. However I don't see any good reasons why it shouldn't be possible to deliver your smalltalk software as fully compiled native standalone executable. Could you please explain me why it is not a common thing to do in smalltalk world? Is there any good smalltalk implementation that allow to do it?
To sum all this. I dream of a live smalltalk environment, where I could develop and test my software, but then (when the software is actually ready for delivery) cross-compile it to native executables for windows, linux and macosx from my single development machine. That would be really awesome.
ironically enough there is one thing that an exe needs to be preloaded. Your OS. See the thing is that C/C++ can be so light because already your OS acts pretty much as the image acts with a ton of preloaded libraries. You need to waste several GBs of memory just get a simple calculator starting. Your OS is a collection of C/C++ libraries.
Things are not any prettier with other languages like python, java etc , even if the app is smaller, they still depend on this libs and they come will quite big libraries that would need installation whether your app use them or not.
Pharo and Smalltalk in general is diffirent case because they aspire to be a virtual OS by itself. The diffirence with a real OS , the smalltalk image is made to be hacked the easy way by a user .
Saying that you can rename the pharo executable, change its icon, disable to IDE tools inside Pharo so your user sees only the GUI of your App. Applications like Dr. Geo and Phratch already do this.
Compiling a Pharo project to a native executable will not make much difference, because a) Pharo is already compiled to a native executable b) you dont need to do that since Pharo is already standalone does not need to even be installed.
My advice is stop worrying about things that do not really matter and enjoy learning how powerful and fun Pharo can be.
Not Pharo, but native, compiled (through ANSI C or its own JIT) smalltalk [applications] (with ability to load pre-compiled DLLs or [JIT-]compile code on demand):
Smalltalk/X
http://www.exept.de/en/products/smalltalk-x.html
or (unofficial enhanced development version):
Smalltalk/X JV branch - https://swing.fit.cvut.cz/projects/stx-jv/
Nearly completely open-source. Everything except librun (core runtime - memory management, JIT, etc.) and stc (smalltalk-to-c) compiler is already open-source. Claus Gittinger / Exept also promised/confirmed they would release remaining sources were they to stop further development (AFAIK, those parts are closed only because of concerns of existing clients).
I highly recommend everyone to check it out, it is a wonder such a great implementation is so little known.
You might also check out Dolphin from Object Arts.
It is windows only, but the very best IDE, bar none.
If you do anything in Smalltalk, you should buy a copy.
(They also have a free non-commercial version, but you will
want to support the kind of craftsmanship behind it by buying
the Pro version. An absolutely kick-ass product, IMHO).
It will produce a standalone exe, if that's what you want.
I made an exe of a medium-featured wiki with it - the exe was
less than 1 MB. That is not a typo.
-Jim
The problem is that Pharo, in that case, cannot be compared to any native compiler like C, C++ or others, but more like java, python, ruby and other languages with a Virtual Machine around.
In these languages, you produce jars, eggs or gems to distribute your project.
In Pharo, you produce a "production image" following technics you already mentioned. But nothing prevents you to deliver an artefact including also the PharoVM (it is 2m large, after all), and you can prepare your apps to detect and open your production image (without having to ask for it).
It is about as practical with Smalltalk as with other languages: not very much. As soon as you create a somewhat larger application, you start depending on other libraries/applications being installed. If you compile them statically with the application, you have now created a much larger application that takes longer to download, and needs to be updated at least as soon as a security problem is found in one of the dependencies. If not, your application is no longer double-click startable.
There are two directions for solutions: web applications, and installers and package managers.
Squeak still maintains its one-click installer, allowing the same set of files to work on windows, mac and linux. Pharo used to have that too, but moved to having separate builds. The need hasn't been so large that the one-click build has been reinstated. It is mostly seen as useful to be able to carry around a cross-platform environment on an usb-stick. With the move to the 64-bit spur vm the dependency problems will lessen as more of the needed libraries will come pre-installed on those platforms.
Dolphin Smalltalk can produce a standalone .exe for Windows.
This is a key feature of the Pro version.
Your dream has been around since the mid-80's and it is called Smalltalk/X.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I have purchased a Tiva C series LaunchPad TM4C123G Evaluation Kit from Texas Instruments. This kit contains a small PCB with an ARM Cortex M4F microcontroller. Now I want to start writing software for this microcontroller. I am used to program AVR 8-bit microcontrollers using AVR Studio on Windows. I heard that it shoud be easy to program ARM-based microcontrollers on Linux, and since Linux is my main platform, I would like a simple IDE that will work more or less like I am used to from AVR.
For several days I have been searching for a good IDE and tools that will do the job. To my surprise, only a few will run on Linux, and none is open source or freeware. Can this really be true? I do not want to spend several hundred dollars just to try out some programming for the Cortex M4F. Nor do I want to learn one IDE now and then another later when I found out it is not good enough or too expensive. I am used to Linux and the open source way of doing things and I am very shocked that nobody seem to be doing any serious embedded ARM programming with open source tools on Linux. Please correct me if I am wrong.
I have no plans running Linux on the Cortex M4F - I just want to program it like a normal microcontroller.
Texas Instruments recommends one of the following tool chains on the back cover of the evaluation kit:
Code Composer Studio IDE: full functional board locked
Keil: 32KB address limited
IAR: 32KB address limited
Mentor Embedded Sourcery CodeBench: 30-day full functional
I have also been recommended Red Studio from code_red.
Neither is open source or free and all have limitations. It seems to me that only Code Composer Studio and Red Studio is Linux compatible.
I stumbled upon yet another product, Rowley CrossWorks, which is also Linux compatible but still very commercial and expensive.
Is it really true that there is no open source alternative? Most of the products seem to use Eclipse and GCC, which one should be able to do without these commercial packages, right? I just can't find any tutorial or guide explaining how to do set this up for embedded ARM programming. Also I need to know how to program the device after compiling.
I really want to get started soon. Any advice and ideas are very appreciated :-)
It's always the same, no matter which eval board you have: STM32 discovery, LPCXpresso, TI Launchpads. They are very cheap, but the recommended IDEs are limited: Their code size is limited, Windows only, or they are bound to a specific Linux distribution.
In my experience the choice depends on your long-term goals:
Do you want to share code with AVR 8-bit (or PIC32, Renesas RX 32, ...)?
Is it a mid-term/long-term goal to have a build system based on make?
Do you need tab-completion and/or an integrated debugger?
Do you want to try other eval boards in the future (without being forced to install yet another IDE)?
or do you just want to get this one up and running quickly. In that case I would use one of the recommended IDEs to get an impression.
On the other hand, all 32-bit microcontrollers I have used (Cortex-M0/3/4, PIC32, Renesas RX) can be programmed with gcc. As far as I know Code Red, Mentor, and MPLABX use gcc (or a modified gcc).
So there is always the possibility to use Eclipse with a Makefile project, and gcc.
I have tried it twice, but it did not work well for me, because I share libraries between the different targets, and I found it difficult to pass around the defines in Eclipse.
So my IDE is Makefile, Emacs, and gcc, and I have switched completely to using C++: This might be another advantage of using gcc.
Both possibilities (Eclipse with Makefile project or just editor with make) are not "off the shelf": They require time, patience, and your favourite Internet search engine.
Update
I am not aware of a complete tutorial on how to setup a GCC + make based environment, so I simply describe the basic steps I did it some years ago (with some changes).
Get a binary distribution of GCC for ARM from https://launchpad.net/gcc-arm-embedded
The following steps are STM32 specific:
Get one of the discovery boards, for example the STM32 value line Discovery.
Get a flash utility: I am using stlink (git clone https://github.com/texane/stlink.git). This includes a GDB backend as well.
There are various examples available, search for "stm32vl discovery blink" (I cannot recommend one here, the one I used has vanished)
As an alternative (or follow-up): Get the Peripheral firmware examples
You will find a GNU ld compatible linker script in Project/Examples/GPIOToggle/TrueSTUDIO/stm32_flash.ld
You will find a GNU as compatible startup in Libraries/CMSIS/CM3/DeviceSupport/ST/STM32F10x/startup/TrueSTUDIO/startup_stm32f10x_ld_vl.s
You will find all other required library include files and sources in the .zip archive as well
Look at the GPIOToggle project (Project/Examples/GPIOToggle)
Write a Makefile to compile, link, and flash
To build your own development environment you could use the following combination:
Eclipse CDT
Get the toolchain to be used (official GCC version or some third-party customized for your platform)
Integrate the toolchain into Eclipse environment either through the internal Eclipse build system (CDT builder) or through some external builder (i.e. make)
In order to have JTAG debugging support, there is a GDB Hardware Debugging Eclipse plug-in you will need to setup
I've managed to complete my own setup in such a way for LPC1769 (Cortex-M3 CPU) and it worked :)
Firstly, I saw some topics about these two but weren't my answer.
I'm looking for a good FPC(Free Pascal Compiler) IDE on GNU/Linux.
There are some IDE's like Lazarus and CodeTyphon. I need suggestion to choose one of those.
I've tried Lazarus once but all windows was separated. It looks messy and not interesting.
I would like to know what are the distinguishes between these two ?
I would like to know advantages / disadvantages each of those. Thank you
CodeTyphon is a distro of Lazarus, like Ubuntu and Debian are distros of Linux.
CodeTyphon comes with a large package of components and plugins, that otherwise you would have to google and download and install.
CodeTyphon have their own idea what are stable versions and what are not stable yet for both of FPC (compiler) and Lazarus(IDE). Whether their assessment is better or worse than upstream's Lazarus Team's, I don't know.
What about one-single-window plugin, it is work-in-progress and it doesn't seems to me it is ready for production use, no matter would you get it as part of CT or download and add it to vanilla Lazarus. However maybe it better works on Linux than on Windows, I don't know.
There were however issues with code legality in CT grande bundle. It is widely believed that Orca (if I remember the name) violates copyrights of glScene/vgScene, which also happened in early Delphi FMX releases but was fixed by EMBA later. There also were disputes in FPC forums/wiki about CodeTyphon pirating some open-source components. See answer by Peter Dunne below.
Your question is akin to asking the difference between Linux and Ubuntu. Lazarus is an IDE/component library, based on FreePascal (FPC). And CodeTyphon is a distribution of Lazarus and FPC. So CodeTyphon is just one way to install a functioning installation of Lazarus.
Lazarus uses the same floating window design as older versions of Delphi. Installing from CodeTyphon won't change that.
Myself and several friends highlighted several licensing issues with codetyphon
most of which could have been corrected by sourcing the included files from known good source and ensuring the correct license headers were included
PirateLogic refused to correct the issues which means they are using code in direct violation of the original license terms
The fact its open source code does not change the fact they are pirating the code by not including the correct license even after the issue was highlighted
I also found several instances of copyright code included which appears to be proprietary and not FOSS at all
They also changed the path & file names on some libraries so that source is no longer compatible with standard lazarus/component installs
This in my view is totally illogical
These 2 factors heavily undermine what was potentially the best FPC/Lazarus distro
Hardly professional
Lazarus can be a daunting installation process due to it's nature as a cross compiling environment. You don't just download an installer and click ok. A typical "installation" is actually a bootstrap FPC compiler doing a three-pass compilation of an "install". There are plenty of good installation scripts/methods from the official Lazarus/FPC team and in the community for a . But, understandably, the installation process is a skill in itself.
CodeTyphon is a a different/separate branch of an installer system, which is more of a utility suite/tools/third party code compilation library. If you want the simplest installation experience go with CodeTyphon. It has the nice graphical front end for managing the compiler. You can conveniently do the fancy stuff like build "cross-compilers" for almost every "target" operating system out there. It also is jam packed with hundreds of the best components/libraries pre-installed. It is a very actively maintained project and very professional. A whole lot of work is done for you.
Even if you want to be learn the low level compiler capabilities, CodeTyphon is a good place to start. It is written in FCP/Lazarus and is open source. Simply study it as "working demo app" and the other info on the compiler details. If you crash it, at least you don't have to learn to climb the hill. You get to get to start from the top and lose control on the way down. Start from scratch (and a three hour reinstallation) Hahaha
Lazarus also has a package "AnchorDock" which allows you to dock all the windows into one. Either install the anchor dock design package after installing Lazarus, or install Lazarus using the script at getlazarus.org which will do it for you.
The mono installation provided at mono-project.com comes packed with several libraries, such as gkt, making the installation quite large (~280MB or so).
Is there any way to provide users with an installation of "just" the mono environment? I am targeting Windows, MacOSX and Linux.
You might be looking for mkbundle which merges your application, the libraries it uses and the Mono runtime into a single executable image. See under "Bundles" in that page.
If you do this though, it may mean that you are distributing LGPL code with all that this implies.
If you are distributing your app for Mac OS X, there is also MonoMacPackager which offers more advanced support for this. I think they have done a bunch of work in the linker to really minimize the amount of Mono that you have to include. It will actually remove unused code from assemblies that you reference.
I am quite new to the embedded linux programming and did not really understand this concept very well.
Can anyone explain the essence of the "host-target" relation? Is this model only specific to the "cross-compilation"? Is it used just because "executable code will be run on another enviroment"? and what matters with the linux kernel on the target? E.g., the "building the embedded linux system" book mentioned this, but did not explain its motivation or goal of this type of development.
Thanks a lot.
The 'motivation' for this model is that seldom is an embedded target a suitable platform for development. It may be resource constrained, have no operating system, have no compiler that will run on the target, have no filesystem for source files, have no keyboard or display, no networking, and may be relatively slow or anything else you might need to develop effectively.
If your embedded system is suited to running Linux, it is possible that not all of the above limitations apply, but almost certainly enough of them to make you want to avoid developng directly on the target. If this were not so, they it hardly qualifies as an embedded system perhaps.
http://www.landley.net/writing/docs/cross-compiling.html
Seems pretty clear. What specific questions do you have?
Linux since its very origin was written in very portable way. It runs on a whole range of machines with very different CPUs, and it is considered the Good Thing to write in a portable way, so that, for example, package maintainer can easily port your program to some embedded ARM or Cygwin, or Amiga, or...
So, yes, the model is "only" specific to cross-compilation, but actually about every compilation on Linux is a (variant of) cross-compilation, just that by default build, host and target are automatically set to the same value, the same as the machine you run on.
Still, even then, you can take a Linux-i386 compiled compiler, sources for it, and "cross-compile" it for Linux-amd64. And the resulting binary will run much faster on a 64bit CPU.
It IS quite essential in embedded programming though. Mostly because you write programs for weak CPUs that are not capable of running a compiler or would run it at a snail pace. So you take a cross-compiler on a fast CPU (say, some multi-core Intel) and cross-compile for the embedded CPU (say, some low-end ARM).
"In different environment" is putting things very mildly. What you're doing when cross-compiling for embedded is working with entirely different instruction set, different memory access modes, different resource access methods and so on and so on. A machine of entirely different construction than the build host. Your build host may be a Windows PC running Cygwin. Your target may be a chip inside a smartphone. The binary will look nothing like the Cygwin .exe files.
As a direct consequence, -everything- must be compiled for the target from scratch. The kernel, the system utilities, the system libraries, all the tools the target must be running. Thing is, if the target is a ticket selling booth, there is really no sense cross-compiling Eclipse, GCC and Gnome for it, then developing in "local" environment, typing your code on a ticket booth keyboard. Instead, you just cross-compile the essentials of the OS, and your specific applications. You keep the development environment on the build machine, and cross-compile everything you need on the embedded device.
[in practice, you get a Linux distro for the target, and just compile whatever you need modified].