I'm having this robotic arm project along with some engineers we haven't settled for the Micro Controller of choice yet but currently a PIC is being tested. I was wondering if there were Micros that support C++ ?
Background:
I'm a (Java) software developer, beginner in Embedded systems, currently programming using Mikro Elektronika IDE and C language.
AVR, MSP-430, Blackfin, almost anything 32 bit (ARM, AVR32, Renasis RX family).
If you are starting from nothing, an ARM is probably the best way to go. Atmel, NXP, TI and others have single chip ARM microcontrollers with inexpensive development kits.
I know you're asking for C++, but I just got a netduino that runs C# (very similar in syntax and concept to Java) and I'm loving it.
The whole dev board (which in many aspects is compatible with readily available arduino shields) costs less than 40 bucks.
I would add to hexa's answer that for ARM llvm is also a good compiler (I use binutils to assemble and link).
Going metal with C++ is not optimal for a number of reasons, simply because you are not running on top of an operating system and, to name one, dynamic memory allocation simply doesn't exists. No new no malloc. I don't mean you CAN'T go C++, but I would refrain.
I've used Mikroe C for PICs, it's ok but I'd go with MPLAB, just a matter of personal taste.
If you wanna go ARM, go GCC.
Why don't you try the mbed plattform? It's an open source arduino-like board which I consider to be more powerful. It is programmed in C/C++ and the good part is that there are literally thousands of APIs you can use in your project.
Hope this helps
https://mbed.org/
Related
I have just begun learning C++ through a flemmish government funded course. I was given 'thinking in c++' by Bruce Eckel as my educative material.
Besides learning c++ i'm also picking up objective-c on my own as I go, my long-tearm goal is to be a independent osx/ios dev, but i have to learn an succeed in c++ for the funding to continue. Betting on two horses and such.. you're getting the picture, i'm sure.
So now it begins. I have to choose an IDE. Xcode seems only to serve the os x oriented C++ development as far as I understand... Am i right?
I would consider other IDE's like eclipse or even go linux and what not, but in the end, long term, I'm going to be coding in Xcode because of my independent ambitions... So it would be really convenient if I could get started with Xcode right away, nice and comfy, so i don't have to divide my 'learning curve' an lose valuable time
So the question nice and short; is it possible to code C++ for non-osx based sources and frameworks and what not. More importantly, can i learn everything in the book by Eckel if i stick to Xcode?
I'm a new kid on the block. Forgive stupid questions and wrong usage of dev lingo.
much obliged.
Yes - stick with Xcode - you don't need to use any Apple-specific frameworks - just build command line tools.
Sure you can. Most good programming language books don't talk much in terms of any particular editor or IDE. And OS X is at least somewhat amenable to using open source software libraries that you might want over time (e.g. Boost).
If have not used Xcode but I don't see why you should not be able to do so. If you want to build for non mac machines you just have to compile your code with the proper flags, and be mindful of the libraries available on the other system. As for frameworks, you won't find them on non mac machines so you shouldn't use -framework option in gcc.
Greetings,
I am trying to decide between C and C++ for my robot. I am a 5+ year veteran of Visual Basic.NET, however I'm going with Linux (Ubuntu) on this robot, and there is a compatibility problem between Linux and the .NET Framework. I want to stick with whichever language I choose for all of my projects, so I want to make sure that I choose the most appropriate one for the task.
For reference, I will describe my current robot in progress and what I am going to do with it. I am in the process of building a full-sized R4 Astromech (yep, I'm one of those guys). I have incorporated a PC motherboard with an Intel Core 2 2.1 GHz processor, 1 GB RAM. I will be using a scratch-built parallel interface card to control the drive motors, head motor, as well as a secondary parallel interface card (going to a second parallel port) which all of the sensors (IR, Ultrasonic Ranging, Visual Recognition via webcam, etc.) will be going to. Commands will be given using speech recognition (currently have a VB.NET scratch-built recognition program that I will be adapting to the new language).
Given the specifications and desired goals listed above, would I be better off with C or C++? I greatly appreciate any suggestions that you might have.
Thanks!
Thaskalas
What do you mean by a compatibility problem? Have you looked at Mono? It's an open-source implementation of the .NET libraries. It's geared toward C# not VB.NET but if you're more comfortable in a .NET environment use that. Speed isn't really an issue here as a Core2Duo is plenty fast for what you need to do.
If Mono won't work for you, I'd recommend C++. There are a lot more libraries out there for C++ (or at least, I am familiar with more, e.g. Boost), which can use most C libraries too. There's no real speed penalty for using C++. While using C wouldn't be bad per-se, C++ has some benefits and no drawbacks, so it's probably the better choice.
I would recommend using ROS. It will let you get started with a sophisticated Inter-Process Communications manager, as well as a large library of sophisticated robotics code, including multiple implementations of SLAM and other critical robotics algorithms. ROS also lets you program in multiple languages, including C, C++, and Python, so you aren't stuck with one language or another down the road.
I would also recommend C++ and ROS. In our company we're migrating to it, because there's so many people working on it, expanding it, and adding lots of cool features.
With this, you can forget about implementing most of the basic low-level stuff and start working on what you intend to research.
It's really easy to set up and start developing.
Since you're running Linux on it, I'd recommend a split approach, where you do the lower-level (device interface, where you may need fast performance) stuff in C (or C++), and the higher level stuff in a modern language like C# (using Mono) or Java, or even Python.
Python especially is hugely expressive, has a large set of libraries, and has a pretty straightforward C interface.
Writing your high-level control stuff in a low-level language like C/C++ will get old fast (IMHO). Robots should be fun!
Have you considered D? It's a fairly new language, is compiled to native code and can link directly to C. (The entire C standard library is even available from D, and bindings to the POSIX API are included in the standard library.) Basically all you need to do to use any C library from D is compile it with a C compiler and translate the function prototypes, constant declarations, etc. in the header file.
D is low-level enough that an experimental kernel is written in it, but has modern features like garbage collection (though manual memory management is still permitted), builtin strings and arrays, and more advanced/easier to use template metaprogramming facilities than C++. The biggest disadvantage is lack of a mature toolchain and libraries for enterprise-y things, but for your purposes that probably doesn't matter. BTW, if you need to do a bunch of matrix manipulation and stuff, there's the SciD project, which provides nice templated wrappers over LAPACK and BLAS.
Use C++. You have the space. You can use it "as a better C" to start with.
C++ is a bigger tool bag; why would you not want that!? You need not use all the tools, but with C you'd have no choice. Most importantly with C++ you have the choice of using both C and C++ third-party libraries.
I have been using C++ for a while now and I began to get interested in lower level system programming like drivers and stuff. Even some kind of primitive operating system could be very interesting project!
I have no clue where I could start. Are there any not-too-challenging things I could get started with and are there anything about C++ I should try to avoid like exceptions in performance critical code?
My current OS is Windows 7 if that matters much.
Writing Windows device drivers in C++ isn't impossible, there are not many CRT functions that you could use to get you into trouble. The new operator is unusable for example, you don't have to fear a std::bad_alloc. Unless you replace it, that cuts out a rather large swath of standard C++ library classes.
But that's not really the point of a device driver, it is rather important that you make it as small as possible. C++ pays off when you write complex code. You explicitly do not want to write complex code in a device driver. Debugging it is redrum.
Linus really likes C in the kernel. There's a good reason for that.
C++ doesn't provide quite all of the tools you will need to actually implement a full operating system in it. There are a few machine specific things that cannot be done in c++. These things are handling and raising interrupts, controlling the MMU, controlling access to supervisor cpu instructions, and a handful of other small odds and ends.
Fortunately, these things are few enough that they can be written in assembly language accessed from C++.
Have a look at osdev.org (lots of questions that will pop into your mind when considering developing your own OS are answered here).
I would strongly suggest you start by hacking existing open source device-drivers and kernels, which you can really only do in Linux or *BSD. The experience will also give you a good sense of whether you're cut out for this kind of programming.
I have heard the recently open sourced Symbian OS is written using C and C++. Not sure which parts of it are done with C++ as I have not read the code base. Consider looking into it.
Kerneltrap.org has some very good discussions about why the Linux kernel does not have C++ in its code base. Consider reading that as well.
Symbian OS is written in a variant of C++. Of course, there's assembly code for low-level things, but that is all wrapped up. You cannot use exceptions, and for real-time drivers you cannot do normal things like dynamic memory allocation, not even in C.
I recommend C Programming Language and assembler. I'm not sure if it's possible to low-level much with C++.
With RoR, Java, C#, PHP etc.. what do people use C++ for these days?
You're comparing apples to oranges. Languages such as PHP, Ruby, and Python are scripting languages. They a) are interpreted, and b) don't provide the kind of low-level memory access that C++ does, and thus aren't suitable for things that need to talk directly to hardware. Java and C# both run in a runtime environment on top of a particular platform and for the same reason aren't always the best choice. In all of these cases, things such as garbage collection can get in the way of speed and performance.
Languages are just tools; you choose the best tool for the task at hand. Just because higher-level languages make many tasks easier for a particular application domain doesn't mean that lower level languages don't have their place.
C++ is the preferred language when the user experience is more important than
development cost.
Performance. When Users time is valuable enough to spend some extra development hours.
Stability. Other languages may quick whip up something of descent quality.
But If you want it flawless, C++ is a better choise. As usual in c++ it is both
easier to get it totally wrong and totally right, depending on your skill and time available.
Ease of use. You can deliver a single binary that works everywhere. No need
for inexperienced end user to fiddle with installling runtimes and
interpreters, worring about VM versions and GC tweaking.
Users resources. Just because the user has 2gb of ram doesn't mean that she
wants our program to use all of it.
Usability. If you want specialized non-standard streamlined user interface.
Something that seems to have been overlooked so far are projects where there is already a substantial C or C++ code base. Most programming work is not going into creating brand new programs. If you are so blessed as to be creating something completely de novo, great, but that's not the common situation.
It's possible to mix languages, of course, so you can have the old C++ core program with additional code written in some other language. But, this is not easy, for a number of reasons:
There's the impedance mismatch between the languages themselves. Try to send a C++ std::multiset to Perl. It's kind of like an associative array, but not really. You end up using lowest-common-denominator data structures, avoiding anything that's specific to only one of the two languages. You then lose out on some of the features you were trying to gain by mixing languages.
You have to spend a lot of effort to define some kind of API between the two parts of the program. Most programs are not already architected to have such a layer. Refactoring and packaging the old core functionality to provide this is not easy, and it's ongoing work as the program's scope expands.
You either have to integrate the interpreter for the other language into the old C++ core, or you have to run it as a separate program and arrange for coordination between these two different programs. They must start up and shut down together, they have to maintain their IPC channels, etc.
Having overcome all the above, you will frequently find yourself needing to write code for both halves of the program. You will always have some delay while your brain makes a kind of mental context shift between the two languages. It never drops to 0 delay. This soaks up some of the superior productivity of the higher-level language. This is especially bad when working on a new feature in the high-level code that requires adding something to the old C++ core, so you're constantly bouncing between the two. It can be done, but it's a drag on productivity, the main claimed advantage from switching to some other language.
Two of the most common usage of C++ I would think are graphical interfaces and video games programming.
Almost everything on the desktop (except paint.net)
Everything on the server that RoR, php etc is running on top of (any language that can't write it's own compiler is probably written in C++)
Anything embedded smaller than an iPhone
Anything with a lot of computation - that isn't in Fortran ;-) Yes I know C# performance has improved, anybody got round to rewriting LAPACK, BLAS or NAG in it yet?
edit -
Is there a badge for most comments?
This is why SO doesn't work for discussions. Notice the order of comments change as they are voted. If you want to have childish arguements there is always reddit.
Anything where performance is a high priority. Garbage collection, HTML rendering, animation, games, intensive computation...
And from personal experience Computer-aided Design (CAD) plugins/addins are also C++, especially if you want to target multiple CAD systems (e.e Pro/Engineer, SoludWorks, CATIA, UG, AutoCAD etc).
Backends to projects. Many projects are written in multiple languages, where all the backend operations are written in C++ where APIs to other languages are provided.
The best project I can think of that does this is GNU Radio. Basically, how GNU Radio works is that all the DSP blocks (modulators, filters, etc) are written in C++. However, you make your radio using python, that is you connect the blocks together in python.
While other languages have come along. Many poeple who have used C++ in the past aren't just going to jump bandwagon with Java or C#. Linux all well and good in it's own right, but the majority of the computer Market still belongs to the Evil Empire. Java is NOT the dominant language there, no matter how much the religeous zelots claim it to be. Actually in small business apps, VB is king. I think I saw one figure giving it 58% of internal development for GUI front ends. C# is picking up momentum, but I suspect it primarily from the younger crowd who are less set in there ways. You can argue till your blue in the face virtues of a new language with someone who's been using a language for 15 years, and they just won't care. "Oh that's neat." and they turn back around and continue typing their C++.
Edit:
OS development, C maybe C++.
Tool & Langauge development, C maybe C++.
Industrial control, C, C++, Labview in somecases, FPGA development and NO trendy languages.
Embedded alot of C, some C++ and some assembly required.
(The IPhone is a general purpose palm computer, with phone capability. Not special
purpose computer designed for a singular purpose.)
PS3 C, C++ and some assembly required.
XBox360 Some C#, mostly C++ and some C and again some assembly required.
GPU Programming? It ain't PHP that's for DAMN sure.
Windows Programming C++, C#, and even some C still, VB.
Edit:
#Jeff L:
The Cult following that many these language have, I find irrational and distasteful. I start edging away from anyone who waxes poetic about ANY language, it's just mental. It's not a matter of opinion that professionally sold applications AREN'T written in Java for Window, it's fact. I'm sorry, but it's true. Maybe in the IT world it's useful, but not for shrink wrapped Windows software. I write embedded software, and the "feature" of not having pointers means that in order to do any practical work there or on OSs and device drivers requires hacks that violate the language it's self. There are cases where you have to "fly without a net" and the interpretive languages are designed SPECIFICALLY not to let you do that.
And not to be too argumentative with, but the heritage code base is a hard issue to get around. While we write new code in C and C++, I can't even get management PAY to upgrade old code written in Fortran or Ada to C or C++ forget Java that requires a whole new coding standard and butt loads procedures and documentation have to update, that cost even more. And unless the only software you write is GPL and freeware, who's paying for it is the primary concern. And in many cases "if it's isn't broke don't fix it" doesn't even apply, "if it's broke and no one bitching, we're not paying to fix" is managements choice.
Any project that needs direct hardware access, like drivers, operating systems
Any project where better performance is a competitive advantage, like games, simulations
Any project that needs a small footprint, like embedded systems
Check out the click modular router. Written completely in C++ (with some C where necessary)
A lot of micro ISVs are (enthusiastically) using C++ for almost anything you can think of.
It isn't maintained regularly, but here is a list of apps written using C++ Builder. I was pleasantly surprised to see WinRAR and Partition Magic.
I just interviewed with a company that has C++ programs using VS5.0 as they keep planning on phasing the C++ apps out, so updating is not needed. After 12 years you would expect that they would just upgrade their compiler.
If you want to use DirectX the you have to use C++ now, as MS dropped support for a Managed DirectX API.
As was mentioned, in the embedded world C++ or C is the primary languages.
If you work in a system that cannot crash, then you will may use C or C++ and just don't use new or malloc, but use arrays, so that you won't have any memory leaks, which can be a likely reason a long running process may run out of memory and crash.
If you are going to do a great deal of kernel level programming then C or C++ makes more sense as there will be some functions to call that will be incredibly difficult to call from C#, for example.
We do these projects in c++:
Simulation
Game
GIS tools
if you need performance, you should use c++...
I keep hearing mostly from electrical engineers that C is used for fpga work.
What about C++? Are there any disadvantages to using C++? I would think that the parallelism desired when programming for hardware would be better served by C++ more than C, no?
Also what do I use after that to make compatible c++ with the hardware?
I'm pretty sure that FPGAs are programmed either in VHDL or Verilog.
http://en.wikipedia.org/wiki/Vhdl
http://en.wikipedia.org/wiki/Verilog
I know that Altera also offers some C to HDL translators. I doubt that they are usable for anything but tiny designs though.
By far and away the easiest way to program an FPGA is via LabView's FPGA module. However this also ties you into their hardware and software. Not a cheap solution, but certainly the fastest way to get your program in hardware without having to learn anything but LabVIEW.
You can use C or C++ to program FPGAs but it requires some very expensive Highlevel Synthesis software. CatapultC is a product from Mentor Graphics which allows you to write your algorithm in untimed C++. It then synthesizes that C++ into RTL VHDL or Verilog. But CatapultC sells for well over $100,000 so it's definitely not for hobbyists. There's another product called ImpulseC which allows you to write C code which then gets synthesized into RTL, but I'm pretty sure that it only handles C not C++. ImpulseC is about $2000.
For hobbyists, you're probably best off sticking with VHDL or Verilog to describe your design and then using the free tools from Xilinx or Altera to synthesize that code and program the FPGA.
There is a big difference between compiling for CPUs and compiling for FPGAs. "Normal" compilers generate binary program code. The special FPGA compilers generate "hardware". There are compilers out there that turn some C-like code into "hardware". But it's not exactly C. It may be a C derivative extented with integer types of arbitrary bit lengths and is probably restricted to iteration and non-recursive function calls.
I am a big fan of C++ but even I see that many parts of it are just not appropriate for FPGAs: virtual functions, RTTI, exceptions. At least that's my impression. I didn't test those C-like FPGA compilers myself but a buddy of mine worked with them and it's supposedly a PITA.
They're probably using C to interface with the FPGA. When working with one in a design class, we used Verilog to program the FPGA and C in the attached Linux board. In that case, they're likely using C as it's easier to bang out a small program in C than in C++.
You're probably talking about SystemC, which is a set of C++ classes and macros used mainly for (transaction-level) modeling, not for synthesis. The high-level model can then be used as a golden reference to verifiy the register transfer level (RTL) description, which is typically coded in VHDL or Verilog.
as some of you I'm a fan of C++. I think it would be great to use SystemC to work with fpga's. So looking for that I found the next page. Maybe it could interest some of you.
http://www.es.ele.tue.nl/~ljozwiak/education/5JJ70p/blocks/4/sc2fpgaflow.html
What you are referring to is "behavioral synthesis", a compilation technique that allows to take sequential code as input (C, SystemC, C++) and generate automatically a FSM+Datapath pair in VHDL or Verilog, that can then be synthesized using regular Xilinx or Altera synthesizers.
To date, there are many "behavioral synthesizers" :
CatapultC from Mentor Graphics allows you to use a big subset of C and also C++
Cynthesizer from Forte Design System (systemC based) [edit 2015: now Cadence]
for FPGA, ImpulseC seems quite mature
[edit 2015] for Xilinx FPGA : Vivado-HLS
Hope this helps
Two that I can think of off the top of my head: C++ is much more complicated to write compilers (in this case HDL translators) for and has too many features that just would not be useful in such low level programming as fpga programming calls for.
Like others have said most FPGA's are designed using VHDL or Verilog. I have also seen PALASM used several years ago for small designs. The design is a logic description that is converted to settings that configure the FPGA. Verilog is based on c so knowing c will help with learning verilog however FPGAs are by nature parallel so even though the syntax might look similar not much else translates.
They might be talking about a programming language like Handel-C, which is some kind of C dialect, targeted for hardware programming. Handel-C can be directly or indirectly compiled to HDL, which in turn creates an FPGA configuration (i.e., the "program" on an FPGA).
Although VHDL and Verilog are much harder to learn, I suggest you start right away. When you're doing FPGA-related stuff, you're usually interested in efficiency. Handel-C will most likely make less efficient code than the code that you can write by hand (in VHDL or Verilog).
Edit: There's no C++ variant of Handel-C or related compilers I have ever head of.
You could use a soft processor running on the FPGA and code in C from there (NIOS from Altera, Microblaze from Xilinx etc).
SOC FPGA using OpenCL to interface with the FPGA from the ARM processor.
You can use C/C++ to program FPGAs. Xilinx has SDSoC, an eclipse based tool to program your FPGAs using C/C++. This basically builds hardware accelerator for part of code flagged to be synthesized. This assumes ARM+FPGA based zynq devices, host code is running on ARM
There is another flow SDAccel for PC based solution. With host code on X86 & accelerator on FPGA connected to your PCIe slot.
FPGA code describes hardware. What that means is you design a digital system and then use code to "describe" the hardware to the compiler. This is mainly done in VHDL or Verilog.
Modern compilers provide inerfaces between software and hardware platforms to let you write C code that can be run on FPGAs. Its not really code that will be uploaded to the FPGA but merely lets the compiler make code for the FPGA based on your C code. For an optimal system, there will need to be a Hardware Engineer who can make changes to the compiler generated code.
Here's a nice article on the issue: https://www.eetimes.com/c-language-techniques-for-fpga-acceleration-of-embedded-software/#
There are some programs like Intel Monitor Program which let you run C code on FPGAs but what it does is create a 'Computer' using the Microprocessor already on Chip to let you see how the code works. Its more of a learning tool.
Not sure if this has been said yet (I didn't read all the responses) but it is a possibility that what you are hearing is a running software in a soft core... For instance Altera has Nios II which can run a linux kernel (uCLinux) which will allow some pre-loaded C programs to run on that soft core which in turn communicates with the FPGA. So an FPGA will still be programmed with VHDL/Verilog for the hardware side, then whatever data it holds could be accessible to a small app running on the OS in the soft core. I'm sure C++ would be allowed so long as uCLinux/whatever kernel is running supports the language.
~doddy
You usually get a larger standard library with C++ and with C, and C is closer to the way that the hardware operates, i.e. easier for electrical engineers.