I want to use eclipse for Arduino development and I have some issues.
I use Eclipse + Eclipse AVR plugin + WinAVR. I managed to compile the Arduino core library into a static library.
Now I want to use my ethernet shield but I can't find a way to use the ethernet library with Eclipse.
Copied the folder from arduino-022/libraries/Ethernet and arduino-022/libraries/SPI to my project folder and then I made some changes to the includes in order to work. The result is some errors about DDRB and PORTB.
Added the folders Ethernet and SPI into the project's include path. The result is the following.
main.cpp:(.text+0x8): undefined reference to `Server::Server(unsigned int)'
./main.o: In function `loop':
main.cpp:(.text+0x36): undefined reference to `Server::available()'
main.cpp:(.text+0x3c): undefined reference to `Client::operator bool()'
main.cpp:(.text+0x56): undefined reference to `Client::available()'
main.cpp:(.text+0x64): undefined reference to `Client::read()'
main.cpp:(.text+0xf6): undefined reference to `Client::connected()'
main.cpp:(.text+0x110): undefined reference to `Client::stop()'
./main.o: In function `setup':
main.cpp:(.text+0x138): undefined reference to `Ethernet'
main.cpp:(.text+0x13a): undefined reference to `Ethernet'
main.cpp:(.text+0x144): undefined reference to `EthernetClass::begin(unsigned char*, unsigned char*)'
main.cpp:(.text+0x14c): undefined reference to `Server::begin()'
I don't know what else to do. Has anyone tried something like this?
I have lost all day trying to figure this out and it turns out its actually not that difficult. The lost time is due a bit to the fact that some settings are "invisible" to the make file. Also the generated eclipse makefiles are quite cryptic for anybody without delving into the manual. If you want to take a look at the manual.To the solution itself:
Short version:
Make a static library project of the Arduino Core library and build it.
Make separate static library project for SPI, w5100 and Ethernet
There are some connections which must be made for the projects to build. First I set the include directories to point correctly, which i will describe next. Second i set the project references correct so its possible to build the application with all the right dependent builds.
SPI -> includes the arduino core
w5100 -> includes arduino core and SPI
Ethernet -> includes arduino core SPI and w5100
The Application itself -> include just w5100 and Ethernet (assuming its just the Ethernet - library)
The Application itself -> add the all paths of your projects to the library paths and the respective libraries(without the lib prefix)
Be careful with project renames as they don't propagate through the library settings and paths. Be mindful also of some sanity in your setup so as to make it easier to catch any detail that is missing and breaking.
I will try to edit later with a more detailed explanation but this should answer your question
EDIT
I have tried to just import the Ethernet folder and make a static project out of if. For some weird reason(i don't know the details of Eclipse) Eclipse doesn't go deeper into the utility folder effectively not compiling it. If it does not compile and, as you dont have a static library for that include files you will get undefined references trying to compile Ethernet. Also static libraries cannot be linked through the avr eclipse plugin, and that should actually be enough. There is no such dialog.
Also in a weird error, which i cannot explain and which drove me almost nuts, some magic in the make file invoked the compiler through the cc variable which Eclipse did not define. The problem was solved passing the variable as an argument to make like make.exe CC=avr-g++.
I tried harder to make it work through only one project and it just ended up giving me undefined references to arduino core in the static library build which got me completely petrified.
I know this is not part of the answer to your question but it shall stay here for anybody to find guidance in the process of making Eclipse a de facto Arduino IDE, which is what you ask.
I don't understand how you got the errors regarding PORTB and DDRB but i think it was probably something missing in the build. As in my case it just spat non sense error reports.
The lesson is: Make the separate libraries into static library projects and reference and include them in source and in static library in your final application.
(Side note: Arduino IDE should be completely banned and migrated to Eclipse or some real IDE)
Related
I'm using VSCode with the PlatformIO plugin and PlatformIO bazel integration (https://github.com/mum4k/platformio_rules) to write code for multiple different types of micro controllers (ATTiny84, ATTiny85, Arduino Nano, ESP32-S3). The code builds correctly as the bazel integration to PlatformIO selects the correct libraries, but as there are libraries with the same name made for different types of micro-controllers, IntelliSense will select one kind of at random and will mark a bunch of symbols as not defined or libraries not found (effectively, a lot of red squiggly marks)
As an example, I have some code that configures a timer for ATTiny85, and access registers like TCCR1 and OCR1A, which are correctly defined in Arduino.h for that micro-controller, but are not defined in any of the other 4 versions of the library available
Another example would be Arduino.h not defining Serial when built on ATTiny, but doing it when working with the Arduino Nano
The code I'm working on here is C++
Because of the fact that the whole project includes code for all of those micro-controllers (the project makes use of several different types of micros) I need to put the directories where all of those libraries are in for all of the micros in the include path, which is what I think is causing this problem. I have tried to fully qualify the path for the library that I'm using in my code, but that doesn't work because libraries included inside those libraries are not (and cannot be) fully qualified, so at some point this problem happens again, just one level of indirection down. Also, this code might end up being open source at some point, hence I cannot force my own absolute paths there
I would like either
For VSCode IntelliSense to get information about the right libraries to include through either PlatformIO or Bazel (best solution)
If that doesn't work, I'd like to have the option to change the include path on a per-directory basis. This would add additional directory structure on my project, and I'm still not 100% sure it would work, but would be a start
At this point I feel like my only option is to disable the red squiggly lines completely, but that looks like a sub-optimal solution
This question already has answers here:
CMSIS & STM32, How to begin? [closed]
(2 answers)
Closed 1 year ago.
As I want to write an efficient program to use minimal RAM & Flash, I want to remove HAL library completely from my project & program only in registers.
I want to use cubeIDE for compiling & Debugging but I do not know how to remove HAL library from my project(It seems that HAL library created and attached to project by default when generating project).
Is there any practical way?
Best!
There is an option in STM32CubeIDE project generation which allows you to create empty projects.
The empty project comes with the following:
main.c : Mostly empty
syscalls.c : I don't know what it is for but probably useless.
sysmem.c : Implements _sbrk() function, which is used by malloc() & new()
startup_stm32[xxxxxxxx].s : Startup file in assembly. You can leave it as it is
[xxxxxx]_FLASH.ld : Linker script file. Most of the time, this can be left unchanged.
But you need some additional libraries & files.
CMSIS Library : This includes some core functions common to all Cortex M devices. The core library is header only, and it's the only one you need to get started. There are some additional CMSIS libraries, like the DSP library which you may need depending on your project requirements. I suggest downloading it from its official repository.
Official STM32 headers from ST : This is actually called STM32Cube[xx] (STM32CubeF4 for example) and includes the Cube & HAL framework you want to get rid off. But we're interested in CMSIS compliant device headers. You can delete the rest. It also includes a version of CMSIS which lags behind the official one. Since you can download the latest CMSIS from its official repository, you don't need the one included in Cube package. You can download the relevant package from ST. For example, this one is for F4 series.
Once you have the needed packages, you need to configure STM32CubeIDE such that your project uses the newly obtained libraries. Basically, you need to add some additional include directories and symbol definitions. And there is an additional system_stm32[xxxxx].c file, which can be found in STM32Cube package and needs to be included in your project.
Here you can find a somewhat related answer.
Here is an example STM32CubeIDE blinky project I've created for the Blue Pill board (STM32F103C8). It may be somewhat outdated but it's probably still useful.
The method I've described probably isn't very practical. Some people suggest creating a normal Cube & HAL project and than pruning the unused parts.
I add the UnityEngine.UI.dll and UnityEditor.UI.dll to my assets folder with their mdb files . also i add the both project to my current project. i am sure all the unity engine ugui code build success, because i debug log in the event system, and it print message. when i want to step into the event system class, i always failed . I find unity will load the code from a build path ,rather than i original code. Why does it do this ? if i want to debug unity engine ugui code, what should i do ?
To debug code, you need two things:
Symbols, the list of all functions, classes, variables used throughout the module. When using C++ symbols are stored in special .pdb files on Windows (and you obviously are using Windows since you are talking about dlls). Symbols in C# (.NET in general) are stored in the .dll itself. Having symbols will let you see the name of functions on the call stack and possibly some variables but nothing more.
Source code of the module.
U3D's source code is proprietary - you need to spend a good amount of money to receive it. And if I am guess to - UnityEngine.UI.dll is a C++ module with stripped (removed) symbols removed.
Thus you have neither, so you can't debug U3D's code at all.
Why would you need to that anyway? If you want to see how the internals of a big game engine work, there are plenty of other options (for example UE4 and Lumberyard). If you are struggling with a problem and you'd like to be able to solve it through debugging...well though luck. Your best bet would be to ask in unity community.
I'm pretty new to c++ (and programming in general) and I'm currently trying to inlcude the "SDL.h" header into a c++ project in Eclipse (I use minGW btw). I've provided the project with the paths to the the header files and the library of SDL. However, whenver I specifically include "SDL.h" and the build then project I get the following Message:
" 'Launching SDL Basic.exe' has encountered a problem. Program file does not exist. "
I'm pretty sure that this has to do with the fact that no .exe file is generated whenever I build the project with SDL.h included. What I don't get is why this happens. When I include some other SDL header, such as SDL_assert, this is not a problem. Then the .exe file is generated just as usual and the program runs just as it should.[enter image description here][1]
http://i.stack.imgur.com/cdV8U.jpg How it looks when SDL.h is included.
http://i.stack.imgur.com/MW7PX.jpg How it looks when something else from SDL is included.
I seem to have fixed the problem. Whenever I ran the program the console window outout " undefined reference to 'Winmain#16' ". So I googled on it and found out that SDL defines its own main function in SDL_main.h, which in total would give me two main functions. To prevent SDL from defining its own main function I had to define the macro SDL_MAIN_HANDLED before I included SDL.h, and look, it worked:
http://i.stack.imgur.com/mNOOE.jpg
If someone can explain this in more detail I'd really appreciate it.
I did a little research and it looks like the undefined reference to WinMain#16 is because SDL is automatically creating a Windows entry point for your application, but you haven't provided the necessary libraries to link in the SDL implementation of that entry point. However, if you intend to use the SDL functionality, you really do need that entry point, because it performs several important initialization steps necessary to leverage the SDL features that you presumably want to use.
Defining SDL_MAIN_HANDLED is a mechanism that would allow you to provide your own Windows entry point (i.e.: WinMain), but that is a more complicated approach (albeit more flexible). This only solves your problem because it happens to prevent "main" from being redefined to "SDL_main" which in turn means that your .cpp file no longer even requires any of the SDL libraries. So it compiles and links, but you won't have any of the SDL functionality you're looking for.
You need to link in the appropriate libraries. See here - it provides some info that might help.
I'm developing a bare-metal embedded application; no OS or MMU. I'm using a toolchain that consists of arm-none-eabi-gcc, ld and make. It requires some plugins to be dynamically loaded/unloaded and I don't know how to create script for this configuration.
The host application has a defined API for plugin system, it consists of function declarations for init_plugin() and execute_plugin().
There's several C files called plugin01.c, plugin02.c..., which are all implementing that defined API. I want to compile them and then place all plugins in exactly the same address space. There's only a single plugin loaded at once, so there's no problem with memory collisions. After compiling and linking I would extract these plugins from output file and load them separately into the target hardware.
I need help with solving two problems:
Linker should not complain about multiple different definitions of same function
Linker needs to place all code from pluginXX.c files into same memory range. It should reset the location counter after linking each plugin. It should assign same VMA and different LMA. Same VMA allows running plugin when it is loaded in that location, and different LMA allows me to extract compiled and linked plugins from output file.
For anyone interested, I managed to solve it.
The problem of conflicts in symbol names was solved by prefixing all sections with .pluginXX string, and renaming symbols to pluginXX_init_plugin and pluginXX_execute_plugin.
The problem of placing all plugin code into same address space was solved by using OVERLAY feature of linker. All plugins linked together with the host with just one linker pass, which guarantees that everything is linked correctly.
Before this, I tried two-step linking by partially linking only host code into an object file, which would then be linked with each plugin separately. This was waste of time. During the partial linking step, unused code could not be discarded (--gc-sections option was not available together with partial linking --relocatable option) and code would not fit into available memory.