ARM Development on Linux [closed] - embedded

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 :)

Related

Native standalone executable with smalltalk?

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.

Embedded Linux and Cross Compiling

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.

Is there an emulator of MSP430 chip that works without the actual chip and integrates with Code Composer Studio?

I need to learn to program MSP430, but don't have the actual chip yet. All configurations that I've tried at Code Composer Studio (except Snapshot, but it does not count, right?) require something on my USB. How do I learn to program the chip without the chip?
And what is an emulator that requires a USB?
Online emulator (used chrome): http://www.msp430emulator.com
This MSP430 Emulator is open source, and can be used directly online without downloading anything. Still under construction but has a good debug interface. Unfortunately no integration with CCS.
It is on the TI Open source page: TI Open Source Project Page
"The MSP430 Online Emulator provides a complete software model of the MSP430 16-bit instruction set. It is an interactive debugger for advanced development and in depth firmware/hardware analysis. Peripherals include UART, GPIO Ports, BCM+, Timer_A, and more! Open source, and absolutely free - access to the TI MSP430 Launchpad allows you to effectively build and debug firmware. No hardware setup, emulate anytime anywhere!"
open source on github:
https://github.com/RudolfGeosits/MSP430-Emulator
If you need something implemented you can add to the code yourself and run a local emulation server for real time applications.
This emulator is pretty awesome, once you can get it running. Note that it does claim GDB support, which likely means you can get a pure eclipse CDT C project & CDT-GDB-HW-Debugging session up and running against it (making sure to compile with the msp430's tool chain, of course).
http://opencores.org/project,openmsp430
As far as a simulator, the answer is truly 'no'. I would like to be wrong on that... But consider for a moment the number of variants of the msp430, the peripherals, and so on. Not sure if any company can justify that kind of cost!
Especially when launchpad/etc are so cheap and fast.
If you can afford £10 then the launchpad is the way to go just to teach yourself about the MSP430. You can use either IAR Embedded Workbench or Code Composer Studio, both which come in code size limited version which will be plenty big enough to learn with. I don't like either, but of the two the IAR one is, IMHO, the better bet as it's not Eclipse based. If you don't mind Java and Eclipse, then CCS is a viable option for you. One huge advantage with CCS is it runs on Linux, but really, it's still not a patch on Rowley Crossworks which runs on Linux. The latter has a cheap educational licence.
As far as the emulator and USB question is concerned, it's maybe being slightly pedantic, but it's not an emulator, it's a debug interface. There is a debugger built into the chip that enables you to load the code into the chip, set breakpoints, single step through code.
This kit is a great way to start because the debugger interface is built into the kit, you can access pins on the processor, see LEDs come on and all that good stuff that gives you the warm feeling you're programming a chip properly. For the sake of £10 you'd be mad not to!

Having server x86/x64, how best develop software under AIX6/7 on C++?

Having server x86/x64, how best develop software under AIX6/7 on C++?
Someone personally tried to do it and that advise from personal experience:
Can have any IBM compilers for x64, which ensures portability compilation on PowerPC AIX or can be have a virtual machine under Windwos x64 with emulate PowerPC x64 to install AIX and compile under it, or may be better buy cloud's service with AIX to develop and where can I do it?
As I know QEMU does not support AIX.
What do you say about Simics, OVPSim and Bochs or other?
I'm not clear on the question but if you don't have the AIX include files, you are going to have trouble trying to develop code that will compile on AIX. AIX often throws in some oddity that needs to be worked around in the include files.
As far as which compiler, I use gcc. Start by pulling down the gcc from IBM: http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/ezinstall.html Then pick a GCC and compile it using the GCC you pulled down. Then use the new GCC for your development. An alternative would be to pull down the GCC from perzl: http://www.perzl.org/aix/index.php?n=Main.Gcc -- I've never tried that but I've heard good things about them.
Hope this helps
Update to Alex:
Yes. As mentioned, the gcc supplied by IBM will give you fits but it is good enough to compile your own gcc which will then be very stable. I've written device drivers using C++ for AIX, used g++, and included parts of Boost.
gcc/g++ for AIX is very stable and complete if compiled properly. Aside from that project, I have about 50 open source packages working on AIX. Most are C and not C++ but in general, if you are doing open source, gcc on AIX will give you less obstacles than xlc. Not xlc's fault. Its just what the developers assume. Like perzl, I use to upload my images as installp install images but had no users so I stopped.
Last: the customary warning is to not use GNU's ld. Use AIX's ld and assembler (as) but you can find threads that will contradict this. I have not seriously tried GNUs ld although I took a stab at it once about 6 months ago and then got side tracked.
Two of my projects you might want to look at:
https://github.com/pedz/aix-build-scripts -- this is a (probably hard to follow) set of scripts to start from ground zero and get you rolling compiling open source projects on AIX.
https://github.com/pedz/aixbin -- This is a set of two scripts that I now have ambivalent feelings about. Many open source projects (Ruby in particular) need these scripts but others (GNU Emacs) will fail if they are used.

How to set up a dev. environment for ARM board AT91SAM7-EX256 under x86 Linux?

I am a newbie to embedded developement, as figure shown. I have a small ARM board, AT91SAM7-EX256. I have also a JTAG programmer dongle, too. I am using Linux (Ubuntu x86_32) on my notebook and desktop machine. I'm using CodeSourcery Lite for cross-compiling to ARM-Linux.
Am I right that I can't use this Linux-target cross-compiler to make binary or hex files for the small ARM board (it comes without any operating system)? Should I use the version called ARM EABI instead?
As I see, it's a "generic" ARM compiler. I've read some docs, and there're lot of options to specify the processor type and instruction set (thumb, etc.), there will be no problem with it. But how can I tell the compiler, how should the image (bin/hex) looks like for the specific board (startup, code/data blocks etc.)? (In assemblers, there're the org and load directives for it.)
What software do I need to capture some debug messages from the board on my PC? I don't want to on-board debugging, I just need some detailed run-time signal, more than just blinking leds.
I have an option to use MS-Windows, I can get a dedicated machine for it. Do you recommend it, is it much easier?
Can I use inline assembly somehow in my C code? I dunno anything about that. Can I use C++ or just C?
I have also a question, which don't need to answer: are there really 4096 kind of GNU compilers and cross-compilers (from Linux_x86_32 -> Linux_x86_32, Linux_x86_32 -> Linux_ARM, OSX -> Linux_ARM, PPC_Linux -> OSX) and 16 different GNU compiler sources (as many target platforms/processors exists) around? The signs says "yes", but I can't believe it. Correct me, and show me the GNU compiler which can produce object file for any platform/processor, and the universal linker which can produce executable for any platform.
While Windows is not a "better" platform do this kind of embedded development on, it may be easier to start with since you can get a pre-built environment to work with. For example, Yagarto (which I would recommend).
Setting up an embedded development environment on Linux can require a considerable amount of knowledge, but it's not impossible.
To answer your questions:
Your Linux cross-compiler comes with libraries to build executables for a Linux environment. You have hinted that you want to build a bare-metal executable for this board. While you can do this with your compiler, it will just confuse things. I recommend building a baremetal cross-compiler. Since you're building your own baremetal executable (and thus you are the operating system, the ABI doesn't matter since you're generating all of the code and not interoperating with other previously built code.
There are several versions of the ARM instruction set (and Thumb). You need to generate code for your particular processor. If you generate the code for a newer version of the instruction set, you will likely generate code which generates a reserved instruction exception. Most prebuilt gcc cross-compiler toolchains for ARM are "multilib" and will build for a variety of architectures in both ARM and Thumb.
Not sure exactly what you're looking for here. This is a bare metal platform. You can use the debugger channel to send messages if you're debugging on target, or you'll need to build your own communication channel into the firmware you write (i.e. uart support).
See above.
Yes. See here for details on gcc's extended inline assembly syntax. You can do this in C++ and C. You can also simply link pure assembly files.
There is no universal gcc compiler / linker. You need a uniquely built compiler for each host / target combination you use.
Finally, please take a look at Atmel's documentation. They have a wealth of information on developing for this target as well as a board package with the needed linker directives and example programs. Note of course the package is for Atmel's own eval board, but it will get you started.
http://sam7stuff.blogspot.com/
I use either of the codesourcery lite versions. But I have no use for the gcc library nor a C library, I just need a compiler.
In the gcc 3 days newlib was great, modify two files worth of system support (simple open, close, read, putc type stuff) and you could compile just about anything, but with gcc 4.x you cannot even go back and cross compile gcc 3.x, you have to install an old linux distro in a virtual machine.
To get the gcc library yes you probably want to use the eabi version not the version with linux gnueabi in the file names.
You might also consider llvm (if you dont need a C library, and you will still need binutils), hmm, I wonder if newlib compiles with llvm.
I prefer to avoid getting trapped in sandboxes, learn the tools and how to manipulate the linker, etc to build your binaries.