Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am relatively new to programming with embedded hardware although not new to programming. I purchased the STM32F407VGT6 Multimedia Board, TFT LCD, SD, Accelerometer, USB from http://microcontrollershop.com/product_info.php?products_id=5058&osCsid=9jkr9kor7d76qgvu76knsr0hp2. I thought I would be able to use the microC for ARM compiler but misread the demo version as 80 kb not actual amount of 8kb. To purchase this cost 300 and I really dont have the money for it. I have tried to find a different compiler that is compatible but so far have been unable to.
I did find people mentioning that Code Sourcery lite might work although no one mentioned this specific board but the free version does not come already integrated with eclipse and I was unable to successfully integrate it.
I am really at a loss of what to do since I would rather not have to buy a whole new controller, and screen just to continue my project and I don't want to pay to purchase this compiler
If anyone knows a free IDE (even if its free for students only) that is compatible with this board it would greatly be appreciated.
A compiler is required only to support the instruction set of the processor. Board specific support itself is not the responsibility of the compiler. Moreover in the case of ARM based devices, only the ARM core is the responsibility of the compiler; support for peripherals, and in particular the PLL clocking scheme for your part are also not the responsibility of the compiler. So the fact that your board is not mentioned in the documentation is largely irrelevant.
Some tool-chains and particularly IDE's from the likes of Keil (an ARM subsidiary) and IAR provide a huge amount of chip and board support. Both these companies provide demo versions, Keil's I believe is good for at least 32K, and the IDE also supports free GNU tools such as Code Sourcery, which has no restrictions on code size.
However in many cases and in particular the case of the STM32, a lot of the board support you need is available from the chip vendor. ST provide a standard peripheral library and ARM CMSIS (ARM's standardised Cortex-M support API), plus many other libraries besides. Keil actually ships ST's Standard Peripheral Library and CMSIS with its toolchain, but getting it form ST ensures the latest version. The libraries and manuals can be found ion the Design Support tab here. The board page linked in your question has a link to download example code to support the off-chip board peripherals.
So the upshot is that Code Sourcery or other ARM GCC distribution will work fine, but you may need to build your complete development environment from parts such as chip or board vendor supplied libraries plus an IDE/debugger environment such as Eclipse or uVision.
With respect to using Eclipse, there is an article here describing how to do it for the STM32 Discovery board; most of which is applicable to your board at least for building if not for debugging/flash programming - the Discovery board has a built-in STLink JTAG debugger.
Update June 2021
A lot of the above is out-of date ST have largely deprecated support for the SPL and do not even provide it for newer series such as STM32F7, replacing it with he STM32Cube framework.
Importantly however ST now provide a free IDE with a toolchain and CubeMX integrated: https://www.st.com/en/development-tools/stm32cubeide.html
Have you considered Yagarto?
http://www.yagarto.de/
It work on Windows and MacOS.
Or GNU ARM:
http://www.gnuarm.com/
Works primary on Linux and MacOS (also Windows through Cygwin).
Add code sourcery lite to your path, so you can use it from command line, then install Eclipse with CDT. When installed create new cross compile executable project. Enter arm-none-eabi (verify that this is prefix of your toolchain) and you should be able to compile and debug your project.
Related
In this term, I have Microprocessors lectures and we're working on ARM Development with C/C++ and Assembly.
For a while I've been looking for an alternative for Keil uVision which is compatible with Linux Distributions (now using Arch) and able to assemble ARM and flash, but could not find anything. The most related platform was Eclipse but it does not look supports ARM Assembly and nothing that I read about flashing to STM32.
I don't want to work on Windows for ARM Development, is there any way to assemble ARM and flash it?
Very simple. Install STM32CubeIDE for linux and nucleotides board with your preferred STM32 uC. Follow the tutorials online
Be aware that Keil uses ARM's own compiler version 5 or 6 (current releases of Keil MDK support both v5 being ARM's legacy ARMCC, and 6 is based on clang/llvm). If you are following a course, and the course material is based on a different toolchain, you may encounter difficulties - or worse your tutor may not be able to mark your work. Just a consideration before you go off-piste.
Linux solutions are likely to be GNU toolchain based. An ARM GNU toolchain for Cortex-M can be found at: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm.
Flashing STM32 may either be done through a JTAG/SWD debugger usually using OpenOCD, or via the on-chip bootloader using a tool such as http://manpages.ubuntu.com/manpages/bionic/man1/stm32flash.1.html. Your hardware debugger vendor may have their own Linux driver, so worth checking. Mbed compatable boards present as a USB mass-storage device and can be flashed simply by copying the image file drive.
Building and flashing on Linux is only half the battle however; you will presumably want to debug your code too. GDB with OpenOCD or a proprietary driver will of course work, but raw GDB is not a pleasant experience, and you might want to have a more "visual" debug solution. IDEs such as STM32CubeIDE integrate the toolchain, flashing and debugging - but is specific to STM32.
If I want my software to run on Red Hat Linux 6.0, do I have to build it on 6.0? Or can I build it on 6.3? (Similar question for 5.X) I'm asking a general question about runtime implications of shared libraries and similar "automatic" dependencies that get sucked in during the build process. And I'm interested only in the divergence between minor releases. I know that more things change between major releases. I'm interesting specifically in RH and RH-derived distributions. My program is written in C and C++. I think the biggest dependency I need to worry about is the GCC runtime libraries for C and C++. Is there a web page I can use to verify which GCC updates were used in which RH minor releases?
To be clear: I understand the goal and commitment to compatibility between update releases going forward. Upgrading from 6.1 to 6.2 should not break my existing applications. In order to build on a newer update and run on an older update, I would need the reverse kind of compatibility. I need 6.1 to be compatible with things built on 6.2. In general this kind of compatibility is impossible to achieve on a wide-spread basis, across all config files, libraries etc. But I only need a narrow slice of reverse compatibility.
I have an app that was designed, written and built successfully on 6.1. Now I want to build it on 6.2, but I want it to still run correctly on 6.1. Is there a general software release practice on Linux that you always have to build on the oldest update release that you want to support? Or do most people use trial-and-error to determine whether their app runs on older update releases? If you use trial-and-error, how much "error" shows up in the equation?
I am required to write a C++ application to run on an embedded Linux setup (DMP Vortex86DX processor). The vendor provides a minimal linux installation image that can be installed to the board and contains appropriate hardware drivers. My question is motivated by the answer to my previous question about writing Linux software on a particular kernel to run on a different kernel . I don't really know where to start when it comes to writing the software with regards to ensuring compatibility.
My instinctive approach would be to install the same versions of g++ on the embedded device and on my desktop development machine, write the application on the dev maching, copy to the board and compile it there. This seems madness though and I find it hard to believe that this is how embedded software is developed. With regards to the answer to my previous question, is there a way I can simply build on my desktop but use the version of glibc that exists on the embedded device - if so how can enforce linkage to a specific version? Or is it possible to build everything statically so that the application doesn't link to anything dynamically (I doubt this is possible).
I am a total novice to embedded development, and foresee months of frustration unless I can get hold of some good advice or resources. Any pointers or suggestion of where to start will be very gratefully received no matter how simple or trivial they seem - I really am starting at the very bottom with regards to embedded stuff.
OK, given the fact that the Vortex86SX/DX/MX claims to be x86 compatible, a small set of compiler switches should enable you to compile code for your target machine: -m32 to ensure 32bit code, and no -march switch targeting a specific CPU.
Then you'll need to link your code. As long as you don't use anything fancy, but simple established glibc functions, I'd expect the ABI to be the same on your development machine and the embedded system. In other words, you compile against your host libraries, copy the binary to the embedded system, and it should simply run using the libraries available there.
If X-Linux were to use some other libc, like uclibc or similar, then you'd need a cross compiler on your host. I have little experience with Ubuntu in that regard, but I know that the sys-devel/crossdev package for Gentoo linux makes generation of cross-compilers very easy. This can be both for different architectures (not needed in your case) and different libraries (like e.g. uclibc).
I'd say simply give copying the binaries a try, and report back if you encounter any problems there.
I was recently tasked with performing a feasibility study based around switching from using DOS to Linux for use as an OS to run our industrial control software (developed internally). In a nutshell I have been restricted to using Ubuntu 8.04 (with a vendor supplied kernel upgrade providing drivers for the hardware on the board). As this is no longer supported I am unable to update or install software meaning that I am stuck using gcc version 4.2. I want to be able to use C++ and preferably boost libraries but currently this seems like I will not be able to do so.
Basically I am asking how do companies/professionals go about using Linux as a development environment? Is what I described above a common occurrence? Do you simply pick a version and a compiler and stick with it throughout the product lifetime to ensure that the development environment doesn't change too much or can you freely upgrade the kernel, compiler etc. as you go along? Is it common to be constrained by what a particular vendor can provide. Would anyone be prepared to give their opinion as to whether ubuntu 8.04 is a suitable choice of OS for development of industrial control software?
I am not a linux expert at all, but my research and experimentation so far is leading me to conclusion that I should abandon the linux approach and use DOS. Our company has no linux knowledge and is very small and for personal career reasons I have no interest in learning redundant technology like DOS.
I realise this is not exactly a yes/no type question but any responses will be gratefully received.
GCC 4.2 has no C++11 support but the C++03 support should be good and you should be able to find a version of Boost that can deal with that quite easily.
Ultimately, Linux has many upsides you won't find in DOS- for example, no segmentation, virtual memory, and such things that will make it easier and faster to develop software, not to mention additional libraries you might need, as absolutely nobody whatsoever will support DOS today.
With linux-based systems there's not much reason to stick with fixed OS+toolchain version, because backwards compatibility is a very serious issue in Unix-world. Sometimes it is good to target certain fixed system, but frankly these are rather rare, and even then the development can be done on up-to-date systems as long as testing is done on the target macine/platform.
Basically you could just upgrade to for example Ubuntu 12.04 LTS(long term support) for development and stick with it, it is very unlikely that there would be any sorts of uncompatibility problems on the target platform/machine.
Libraries and such tend to change between Linux distros, new versions of linux distros, and other *nix OSes.
I once worked on a C++ application that had to run on both Windows and RHEL. I was the 'Linux guy' on the team, so I got to deal with coaxing all the open-source linux libraries we were using to build and work on Windows (using cygwin), and getting the latest changes made by the devs working on Windows to work on Linux.
Midway through development, we upgraded to a newer version of RHEL. It was not a fun experience. Library versions had changed, some had been removed in favor of other 'equivalent' libs, etc. Shaking out all of the problems caused by changing gcc versions took a little while too (granted, the newer gcc version was a bit less forgiving and exposed some stuff in our code that probably wasn't quite right anyway).
A couple of days before a big demo, management informed us that the app needed to run on Solaris as well. That was not a trivial task -- Solaris is NOT Linux. They hinted about wanting it to run on IRIX at one point. Glad that didn't happen.
I would recommend that you pick a specific version of a Linux distro, gcc, etc. and stick with it throughout development. Upgrading that stuff can happen later, when the software is in maintenance. RHEL offers long-term support, at a cost. You might also consider the newly released Ubuntu 12.04 LTS
What is the command for selecting processor(MIPS R2000) in g++? Thanks
You'll probably need a cross-compilation environment for your target platform. You might find an existing one or you may need to build your own cross-compiler using the gcc toolchain. There's no single way to do this - it will depend on the specifics of the target architecture. Specifically, is there already an operating system (e.g. Linux, BSD, etc.) running on your target system? What kind of userland does it use - your build chain will need the relevant C and C++ library as well as any other libraries you need to build and run your software. Or are you coding straight against the metal? In this case, you'll want to find existing bootstrap code for getting the system into a sensible state for running your code - rolling your own will not be easy.
Generally, you're probably best off finding an existing developer community centred around the platform in question and asking for advice there. They may have step-by-step instructions for getting started.
Note that the CPU alone is only part of the picture - for example, the ARM architecture is very popular, but compiling code for Android devices (Linux kernel with Android userland), iOS devices (xnu kernel with BSD- and OSX-derived iOS userland), a Nintendo DS or a Playstation Vita (probably no multitasking OS at all) will be extremely different, even though they all use ARM chips, in many cases even the same instruction set generation.