I am trying to use C++ application with FreeRTOS.
I come to know about this post :- https://sourceforge.net/p/freertos/discussion/382005/thread/5d5201c0 but I am not sure how and where to add this TaskCPP.h file.
Right now I have very simple main.cpp file something like this.
int main(void)
{
//Set priority bits to preempt priority
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4);
for( ;; );
return 0;
}
And this gives me an error :-
/usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: error: STM32F4_FreeRTOS.axf uses VFP register arguments, /usr/bin/../lib/gcc/arm-none-eabi/4.7.4/libgcc.a(unwind-arm.o) does not
/usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/bin/../lib/gcc/arm-none-eabi/4.7.4/libgcc.a(unwind-arm.o)
I am not sure what is wrong with settings.
That error is related to your tool chain. Your target triple indicates, a more generic tool chain, but FreeRTOS seems to use more specific ARM features. You may want to read this question: ARM compilation error, VFP registered used by executable, not object file
As workaround: call your compiler with -print-multi-lib and check whether the libraries required by FreeRTOS are available. If they are, you'll have to enable them. If they are not, you'll have to use another tool chain.
Related
I've been iterating on a bazel rule for a tool that is dependent on a "custom" (verilator if you're familiar). This tool is supposed to read arguments and inputs and generate cpp files. The action that invokes verilator is defined below
ctx.actions.run(
arguments = [args],
executable = verilator_toolchain.verilator_bin,
inputs = inputs,
outputs = [verilator_output],
progress_message = "[Verilator] Compiling {}".format(ctx.label),
)
The problem is that the executable given to this action is not /exactly/ the same across platforms -- it is slightly larger, has a different hash when comparing mac and linux executables here.
I can trust that the output can be the same, and I'd like to share a remote cache for this action for both platforms; is there a "best practice" where I can rewrite this action to be non-hermetic so the toolchain binary isn't considered as an "input" to the cache? I think the cpp rules do something similar to this.
No, outside of writing an incorrect, non-hermetic rule, there's no way to prevent Bazel for putting all action inputs into the hash key.
I'm using Qt5.9, a simple check:
assert(pobjNode != NULL);
Will cause the Qt Signal Received error dialog to be displayed which doesn't give any helpful information about where the problem is or what it is.
Is there a way to replace this useless information with something a bit more helpful?
What I'm thinking of is a way to set-up the dialog to display what could be an error in the event of an error.
Q_ASSERT is a custom assert macro which supposedly enhances the standard assert function.
The error message is handled by qFatal(), which can behave slightly better on some platforms than the standard assert macro. For example on Windows it will trigger the Visual Studio debugger at the point where the assertion fails instead of just calling abort().
You can also redirect the output of Qt error message functions such as qFatalto your custom message handler ( with qInstallMessageHandler() ). It can be useful for example if you want to redirect the errors message to a file.
Also note that Q_ASSERT is disabled with the macro QT_NO_DEBUG(while assert is disabled by NDEBUG) : this can be used to separate your asserts between Qt-related code and the rest.
Q_ASSERT_X Prints the message what together with the location where, the source file name and line number if test is false.
Prints the message what together with the location where, the source file name and line number if test is false.
Example:
// File: div.cpp
#include <QtGlobal>
int divide(int a, int b)
{
Q_ASSERT_X(b != 0, "divide", "division by zero");
return a / b;
}
to read more on test and debug.
You might define your own MY_ASSERT macro. On Linux it could even call another function which uses Glibc backtrace functions or Ian Taylor's libbacktrace library (provided your code is compiled with DWARF debug information using g++ -g) and perhaps display such information in a modal dialog, or on stderr. However, it should probably not return. Read also about Qt and Unix signals and signal-safety(7).
But assert detects a bug which you should correct. Try hard to avoid shipping code with such programmer bugs.
On Linux, the usual assert -it is a macro defined in /usr/include/assert.h- will call on failure __assert_fail (in your C library, but you might redefine it yourself) which would indirectly call abort which indirectly makes a core dump which you can inspect post-mortem using the gdb debugger. You only need to enable core dumps (using ulimit -c builtin in your bash terminal).
I have some proto definitions that i want to compile to C++ headers/code. When i do, all the data types are MessageLite, which I understand is more light weight for resource constraint devices.
However, MessageLite is missing a bunch of functions that i need (eg: MessageToJsonString and SerializeToOsStream). Is there a way for protoc to generate Message instead of MessageLite?
Alternatively, is there a better way to work with MessageLite? Namely, debugging and serializing to file?
Look in your protobuf definition for the following line:
option optimize_for = LITE_RUNTIME;
and either comment it out, or remove it. That line is instructing protoc to use MessageLite, not Message.
The Point Cloud library comes with an executable pcl_hdl_viewer_simple that I can run (./pcl_hdl_viewer_simple) without any extra arguments to get live data from a Velodyne LIDAR HDL32.
The source code for this program is supposed to be hdl_viewer_simple.cpp. A simplified version of the code is given on this page which cannot be compiled readily and requires a tiny bit of tweaking to make it compile.
My problem is that the executable that I build myself for both the versions are not able to run. I always get the smart pointer error "Assertion px!=0" error. I am not sure if I am not executing the program in the correct way or what. The executable is supposed to be executed like
./hdl_viewer_simple -calibrationFile hdl32calib.xml -pcapFile file.pcap
in case of playing from previously recorded PCAP files or just ./hdl_viewer_simple if wanting to get live data from the real sensor. However, I always get the assertion failed error.
Has anyone been able to run the executables? I do not want to use the ROS drivers
"Assertion px!=0" is occurring because your pointer is not initialized.
Now that being said, you could initialize it inside your routines, in case the pointer is NULL, especially for data input.
in here, you can try updating the line 83 like this :
CloudConstPtr cloud(new Cloud); //initializing your pointer
and hopefully, it will work.
Cheers,
I have a code written in Atmel Studio to read/write data from a SD card. I am using FatFs here. My problem is the code doesn't compile when I use some of the functions (f_chdir, f_getcwd...) in FatFs. Some functions works fine (f_puts, f_open, f_mount, f_mkdir...). All these functions are located in same header file (ff.h, ff.c)
The error says "undefined reference to -function-, ld returned 1 exit status". When I go to the error it shows the end of the code while it is suppose to show where the error is.
I cannot understand the problem with my code. Any help is appreciated.
Just ran into this using the SD card for a project using SAM4S Xplained Pro (Atmel 7, ASF 3.20).
Make sure you have all the asf projects (fatfs, sd_mmc, memory access control, and then the other basics e.g. pmc, gpio, and maybe a few more). My asf did NOT include sd_mmc_mem.c and sd_mmc_mem.h for some reason, so I had to include those myself. Also remember to do the sd_mmc_init() at the top of your main loop. As for the configuration...
If you look closely at ffconf.h, the first thing it does is include conf_fatfs.h, which (wait for it!) is EXACTLY the same file line by line as ffconf.h. All the variables are defined there first and foremost (and guarded by an #ifndef FFCONF and NOT an CONF_FATFS) aka that's where it counts..
Go into conf_fatfs.h and change _USE_STRFUNC to 1 or 2 et voila.
Also note that in the places where you use it, you'll have to #include the ff.h preceded by either ffconf.h or conf_access.h
ASF is a real snake pit if you don't know what you're looking for.
Enjoy.
By default, the memory control access interface is disabled in the ASF wizard. In order to enable the memory control access, please follow the steps below.
Open the ASF wizard (Alt + W).
Enable the Memory Control Access as follows.
ASF SD sd_mmc_mem.h memory access enable
Finally, click the “Apply” option to make the changes.
This adds sd_mmc_mem.h /.c files
Open the ffconf.h in your favorite editor and set _FS_RPATH to 2. From ffconf.h:
#define _FS_RPATH 0
/* This option configures relative path feature.
/
/ 0: Disable relative path feature and remove related functions.
/ 1: Enable relative path feature. f_chdir() and f_chdrive() are available.
/ 2: f_getcwd() function is available in addition to 1.
/
/ Note that directory items read via f_readdir() are affected by this option. */
Which features of the fatfs library are included in your build is configurable, so that you don't have to lose valuable ROM space (as well as a few bytes of RAM) for functions you're not using.
For versions of the FatFS library prior to 0.8a, _FS_RPATH supports only values 0 and 1; f_getcwd is not available in these versions.
Additionally, in versions prior to 0.8, it is necessary for C++ code to explicitly include its headers as C headers to avoid name mangling:
extern "C" {
#include "ff.h"
}
From version 0.8 onwards, it does this internally. You can find the new versions here if you're still working with an old one -- the comment you left leads me to believe that this might be the case.
Check if _FS_MINIMZE in ffconf.h is 0 to have all functions available.
In my version that I downloaded from elm-chan it was by default set to 3 and lead to the compiler error: undefined reference.
In file ffconf.h, set #define _USE_FIND to 1.
/* This option switches filtered directory read functions, f_findfirst() and
/ f_findnext(). (0:Disable, 1:Enable 2:Enable with matching altname[] too) */
I needed to use f_findfirst() and f_findnext() functions and i was getting undefined reference errors.
Now this solved my problem.
Drive/directory handling functions are under #if _FS_RPATH >= 1 (or similar preprocessors) .