So i'm making a program which requires std::variant, so obviously i need C++17 but that's not in Arduino without compiler flags, it's just I cant figure out what flags to do and how to change the compiler flags. (BTW i'm using windows, not Linux (though i do have a Linux laptop))
I have tried using the Arduino boost library but it seems to be written for C++ not Arduino even though it says it's made for Arduino,
I have also tried workarounds but they use up too much memory.
I want it to have std or out least an std::variant equivalent in Arduino but I haven't found a way to get that.
Thanks in advance!
EDIT: If there isn't a way to do C++17 in Arduino, then can someone link a tutorial to code Arduino boards using C++
To use boost.variant check https://github.com/vancegroup/arduino-boost
iostream, sstream, string, variant and other header files like them are not available in avr-libc and in Arduino that uses avr-g++ (and avr-libc)
You can check https://github.com/maniacbug/StandardCplusplus AND https://github.com/mike-matera/ArduinoSTL
For allocating values without known datatypes you can write your class and view https://github.com/radinParsaei/Value
The Arduino programming language is a subset of C++ with a few minor variations.
You can reference .CPP and .H files in your project, as long as they don't use C++ features that aren't supported by Arduino.
I'm sure someone will eventually get creative and find a way to compile code with the C++17 features into AVR machine code (if they haven't already).
But keep in mind, these are tiny chips often running at 10-20 MHz with around 2 KB of working memory. The standard template library was a great leap forward for C++ but it might not be the best choice when every byte counts.
Related
I’m working on embedded projects, using Zephyr RTOS with ARM embedded microcontrollers like STM32 Nucleo series (Cortex M4/0).
Recently, due to significant C++ support improvements in the recent versions of Zephyr, I’m considering to move from C development to modern C++.
By default, Zephyr includes C standard library, but not Cpp’s STD.
Zephyr actually added optional support for Cpp’s standard library, which seems to work pretty well. However, it requires huge flash memory usage (near 65% of my microcontrollers flash memory, without my code!).
So I’m trying to search for alternative ways to use modern C++ without the actual standard library (including the memory/utility headers).
I’ve considered to use Boost.smart_ptr for smart pointers, but I’m wondering how I should use move semantics (std::move) In my case.
Should I use Boost.Move module? Even though I’m using C++1x and not C++0x?
Should I implement move semantics by myself using direct cast from T& to T&&?
I've just found what caused the huge flash usage of the STD.
In my case, it was inclusion of the <iostream> header (used for std::cout), without it flash usage is reasonable enough, even with std containers.
So I guess it solved my issue, I can use C++ STD for my purpose now.
(using <iostream> in embedded environment is a bad idea anyways, for printing just use printf)
My boss has given a code for testing PCI express on an Altera board. The code consist of several c code files having instructions such as reading Bios, setting some registers, writing to buffers etc.
My job at present is to see the functionality of the code by running it.
I am new to FPGA and I am unable to understand what tools, compilers etc will I use for compiling it for the FPGA.
Since it is a C code so I am sure I cannot use the same environment as that of Verilog/VHDL. Can I get some hints as to what compilers are available for compiling C code for testing various interfaces of an FPGA?
Thanks and regards
H
If the FPGA board is just connected through a standard PCIexpress interface, it isn't that hard to create a Linux driver to simply access a couple of registers. This might even be easier to do than getting some old DOS-based drivers to work.
I did some work on this in a pre-project to my masters thesis some years ago - if you're interested, it's available here: http://loejer.dk/files/FORK,%20pdf.zip
It sounds like the intent is that you connect the PCI-E card to a normal computer with a PCI-E slot, then run the test software on the host computer, so it will talk to the board via PCI-E, and exercise the board from the host, collect data on the host, and so on.
Such code will almost certainly be quite non-portable. You'll probably need to ask what system it's for (or examine the code to find hints -- e.g., if it starts with #include <windows.h> that's a pretty fair indication that it's for Windows).
The OS it's written for will give at least an 80% (or so) clue about what compiler to use -- if it's for Windows, chances are pretty good that it's intended for Microsoft's compiler. If it's for Linux, there's an even better chance that it's for gcc/g++. If it's for MacOS, it's probably for g++, but if it's really new, might target Clang.
Unfortunately, my C app for PIC32 needs OO too much and I can't continue doing it in C.
Do you know any MIPS32 C++ compiler for PIC32?
Thanks
Microchip's XC32 tool chain now supports C++ since version 1.10
You might contact Comeau Computing; thier C++ compiler generates C code as an intermediate language so that it can then utilise a platform's existing native C compiler where only a C compiler is available, and therefore porting to new platforms is relatively quick and simple.
For various reasons the intermediate generation and compiler adaptation is not accessible to end users so you will still need Comeau to generate a PIC32/C32 port, but it probably won't take long and hopefully they would amortise the cost over sales to other users.
However if you use Commeau or any other C++ to C translator, you will suffer from the inability to use source-level debugging, and that is likley to be the killer to any attempt to use C++ sucessfully without native debugger support.
Although it is not always pretty, your best bet is probably to learn how to implement OO designs in C. Here's a whole book on the subject: http://www.planetpdf.com/codecuts/pdfs/ooc.pdf
According to this fairly recent thread on the microchip forums it looks like C++ support for PIC32 isn't available anywhere yet and isn't a high priority with Microchip. The wisdom of the respondents in that thread appears to be: don't hold your breath.
I'm a MPLAB user myself building small programs so I just take what Microchip gives me. I've never gotten to the point where I thought I needed C++, longed for yes, but never needed. As a next step you can either consider moving to another platform with C++ support or take another look at your design and ask why you need C++ that badly. Some features can be simulated in C with varying amounts of pain and suffering.
You might keep an eye on the proper GCC MIPS port. They have all the pieces, but I don't know if anyone's made C++ work with PIC32 in particular. I know it did work on sgimips.
I'm pretty sure this is possible but I'm not sure how to go about it. I'm very new to building with GCC in general and I have never used FreeRTOS, but I'd like to try getting the OS up and running on a TI ARM Cortex MCU but with a slight twist: I'd like to get it up and running with Pascal. I'm curious:
Is this even possible to get work? If not, the next issues are kind of moot points.
From my Delphi days, I vaguely recall the ability to access functions in C libraries. I'm wondering if I would have access to the C routines in FreeRTOS.
If I use the GCC version (preferable) would I be able to debug using OpenOCD on the target? I'm not quite sure how debug symbols work and if it's more or less language agnostic (hopefully, in this case).
As kind of a bonus question a bit outside the scope of the original query, can I simulate FreeRTOS on an x86 processor (e.g. my development PC) for easier debugging during development? (With a Pascal program, of course..)
I haven't found any documentation on achieving this, so hopefully someone here can shed some light! Any resources would be most helpful. Like I said, I'm very new to this kind of development. I'm also open to suggestions if you think there is a better alternative.
FYI, my preferred host configuration would be something similar to:
Linux (Ubuntu/Debian)
Eclipse IDE for development, unit testing, and hopefully simulation / debugging
OpenOCD for target debugging
GNU Pascal + FreeRTOS on target
FreeRTOS is C source code, so like you say you would have to have some mechanism for linking C with your Pascal programs. Also, FreeRTOS relies on certain registers to be used for things like passing a parameter into a task (as a hypothetical example, the task might always expect the parameter to be in register R0) so you would have to ensure the ABI for the C compiler and the Pascal compiler was the same - or have your task entry in C then have it call a Pascal function (very nasty). Then there is the issue of interrupts, calling inline macros, etc. I would say this would be extremely difficult to achieve.
Both GNU Pascal and Free Pascal support linking to C (gcc) and ARM, as well as calling pascal code from C etc. Writing a header and declaring the prototypes with cdecl is all there is to it.
Macros are a bit bigger problem. Usually I just rewrite them to inline functions (what they should have been anyway). Except for the macro/header issue, the problems are more compiler specific functionality (which you also would have a problem with when porting from one C compiler to the next)
If you prefer TP/Delphi dialect, Free Pascal is the better choice.
I run my old Delphi code fine on my sheevaplug.
There is already an example for FreeRTOS/GCC/OpenOCD on a TI Cortex-M3 (was Luminary Micro Cortex-M3). Be aware though that this is a really old example and both the Eclipse and OpenOCD versions used are out of date.
Although there is an Eclipse project provided, the project is configured as a standard make (as opposed to a managed make) project, so there is a standard makefile that can be just as easily executed from the command line as from within Eclipse.
http://www.freertos.org/portLM3Sxxxx_Eclipse.html
I am a complete newbie to the ARM world. I need to be able to write C code, compile it, and then download into an ARM emulator, and execute. I need to use the GCC 4.1.2 compiler for the C code compilation.
Can anybody point me in the correct directions for the following issues?
What tool chain to use?
What emulator to use?
Are there tutorials or guides on setting up the tool chain?
building a gcc cross compiler yourself is pretty easy. the gcc library and the C library and other things not so much, an embedded library and such a little harder. Depends on how embedded you want to get. I have little use for gcclib or a c library so roll your own works great for me.
After many years of doing this, perhaps it is an age thing, I now just go get the code sourcery tools. the lite version works great. yagarto, devkitarm, winarm or something like that (the site with a zillion examples) all work fine. emdebian also has a good pre-built toolchain. a number of these places if not all have info on how they built their toolchains from gnu sources.
You asked about gcc, but bear in mind that llvm is a strong competitor, and as far as cross compiling goes, since it always cross compiles, it is a far easier cross compiler to download and build and get working than gcc. the recent version is now producing code (for arm) that competes with gcc for performance. gcc is in no way a leader in performance, other compilers I have used run circles around it, but it has been improving with each release (well the 3.x versions sometimes produce better code than the 4.x versions, but you need 4.x for the newer cores and thumb2). even if you go with gcc, try the stable release of llvm from time to time.
qemu is a good emulator, depending on what you are doing the gba emulator virtual gameboy advance is good. There are a couple of nds emulators too. GDB and other places have what appear to be ARMs own armulator. I found it hard to extract and use, so I wrote my own, but being lazy only implemented the thumb instruction set, I called mine the thumbulator. easy to use. Far easier than qemu and armulator to add peripherals to and watch and debug your code. ymmv.
Hmmm I posted a similar answer for someone recently. Google: arm verilog and at umich you will find a file isc.tgz in which is an arm10 behavioural (as in you cannot make a chip from it therefore you can find verilog on the net) model. Which for someone wanting to learn an instruction set, watching your code execute at the gate level is about as good as it gets. Be careful, like a drug, you can get addicted then have a hard time when you go back to silicon where you have relatively zero visibility into your code while it is executing. Somewhere in stackoverflow I posted the steps involved to get that arm10 model and another file or two to turn it into an arm emulator using icarus verilog. gtkwave is a good and free tool for examining the wave (vcd) files.
Above all else you will need the ARM ARM. (The ARM Architectural Reference Manual). Just google it and find it on ARM's web site. There is pseudo code for each instruction teaching you what they do. Use the thumbulator or armulator or others if you need to understand more (mame has an arm core in it too). I make no guarantees that the thumbulator is 100% debugged or accurate, I took some common programs and compared their output to silicon both arm and non-arm to debug the core.
Toolchain you can use Yagarto http://www.yagarto.de/
Emulator you can use Proteus ISIS http://www.labcenter.com/index.cfm
(There is a demo version)
and tutorials, well, google them =)
Good luck!