MCUXpresso Library Include Issue

[simon_hilt]

Hello,

I am using the CAN-FD kit LPCXpresso54618 and its IDE MCUXpressso IDE v11.1.0. Its the first time that I'm using NXP.

I am trying to include an external library in my project, but it always failed even if I reduce the project to a minimum. I don't know where the error is.

The library is the libTML (TML Messaging Suite - get connected ) library. After installing the library I got some include files, dll's and lib's (is in the attachment).

I worked through the instruction Creating and Linking to Library Projects and searched in forums and the internet to integrate the library in my project. I think, this part work fine, because I can include the library with

Therefore I changed the properties for example under c/c++ build -> settings -> tool settings -> MCU C compiler -> includes

But I'm not sure which library search path I should use under MCU-Linker -> librarys, so I tried all possibilities: the dll's under TML11/bin/win32 and TML11/bin/x64 or the lib's under TML11/lib/win32 and TML11/lib/x64 (see attachment). I think the last one is the best, because my laptop has an x64 architecture (hp elitebook 850 G5) and libs better for the IDE, but I'm not sure because no way works.

My code is the first example from the libTML homepage (TML Messaging Suite: Introduction to libTML-c). I think that is unnecessary because I can't even compile the include of the library.

The error list is very long (578 errors), but all errors belong to one line:

C:\Apps\TML11\include/sidex.h:191:23: error: expected declaration specifiers before '__declspec'
     #define SIDEX_API __declspec(dllimport)
                       ^~~~~~~~~~
C:\Apps\TML11\include/sidex.h:2145:1: note: in expansion of macro 'SIDEX_API'

This error occurs in all lines where the "SIDEX_API" is used. I searched for this error and found:

"The '__declspec(dllimport)' is a MS-specific extensions to the C language."

and

"No, it's a compiler incompatibility. MS compilers use '__declspec(dllimport)' to tell the compiler and linker that a function resides in a DLL. I don't know what CW for Win32 uses to do the same thing."

Both from <https://community.nxp.com/thread/21745>

I also tested a lot of configuration hoping that some compiler would work (e.g. ISO/GNU  C11/C90/C99), but every time it fails with the same error.

Is there a way to use the library even if it uses the dllimport/dllexport functionality?

Or did I do something wrong in the configuration or setting of the properties of the project?

Has anyone seen this issue before? Any help or advice is greatly appreciated.

Best regards

Simon

P.S.: Sorry for my bad englisch...

[converse]

You need a version of the library that is ported to the ARM Cortex-M4 ( the processor in the LPC54618). From the look of the website, it looks like this library is designed for hosts such as Windows, Linux and Mac and not for embedded. 

[simon_hilt]

Many thanks!

I thought ist was possible to include external libraries. Are there any differences in the DLLs or libs? I'm aware that Windows uses DLLs and e.g. Linux uses libs. I thought the implementation in in the IDE on Windows uses the library and then pushes the machine code to the board, so the type of the library is irrelevant.

I can include the library in Visual Studios, is it not because of the wrong compiler or linker?

Is there a tutorial or a simple example somewhere where an external DLL or lib is used? So far I have only found some instructions that describes how to change the properties of the project.

Best regards

Simon

[converse · Accepted solution]

Your target is a LPC54618 which is an ARM Cortex-M4 device. This is a 'bare metal' device - it has no software, no operating system - nothing - until you write the code and download it to the device.

The MCUXpresso IDE runs under Windows (or Linux, or Mac) and is known as a a cross-development environment. That is, you use it to compile code to run on the target - in your case the LPC54618. It cannot do anything with host based software, such as libTML, because that is built to run on Windows (or Linux, or Mac...).

In theory, it would be possible to take the source code for libTML and 'port' it to run on the LPC54618 - but, this would be a HUGE effort - libTML relies on a sophisticated operating system to provide all of the services it needs (such a TCP/IP).

DLL (Dynamic Linked Libraries) are specific to Windows (although Linux and Mac have an equivalent, but different mechanism, called dynamic libraries). This is where an operating system dynamically loads the library at run time (normally on-demand) and 'fixes-up' the calls from your application to the correct place in the library. This is done so that many application (potentially running concurrently) can use the exact same code without it needing to be loaded for each application. On Windows, Linux and Mac, this uses Virtual Memory and a demand paged memory management. None of this is available on a LPC54618 - or any other embedded microcontroller (MCU).

MCU's do support statically linked libraries. This is where the library is linked into your application, so it can all be downloaded into your device. This is the type of library supported by MCUXpresso (and IAR, Keil etc).

__declspec is a Windows specific enhancement to C/C++ for the use of DLL's. There is no way to use this for the LPC54618. There is not even an equivalent concept.

You can include external (statically linked) libraries in MCUXpresso, but the libraries have to be specifically written for, or ported to, ARM Cortex-M4 (or M3, or M0 etc) devices.

[simon_hilt]

Thank you very much. So I have to find another solution. Maybe another protocol than BEEP, which is suitable for my project.

Best Regards

Simon

[converse]

Perhaps if you explain what you are trying to do, others may be able to suggest possible solutions 

[simon_hilt]

My project is a bachelor thesis with the title "Development and implementation of a network interface between a vehicle
and the PC application of a test system with configurable signal evaluation".

I try to create an interface between the vehicle's can-fd from vehicle and ethernet to the measurement laptop of a test system. I was looking for a suitable protocol for ethernet that met the following requirements:

- flexible, high expandability, modular

- protection with checksum

- optional transmission security via ACK

- equipment identifier (e.g. this interface, a display)

- P2P, IPv4

- full duplex

- time stamp or prioritization

I found the BEEP protocol to be the most suitable and found the library libTML (or Vortex) for it.

The board should send the evaluation of the CAN-FD messages from different vehicles and its own status reports via ethernet and receives control signals from the measurement laptop, e.g, which vehicle platform is used. As an extension, the CAN FD messages can be manipulated by the control signals via ethernet on the laptop. But that is optional.

I have seen for example, that the protocol MQTT is offered for the board, but I think that it is not useful for my use case. Maybe I shlould work out and implement an own structure.

In any case, I first get the basic connection of CAN-FD an Ethernet to run without a protocol. I have already sucessfully tested both interfaces individually using some examples from the IDE, but have not yet combined them and wanted to build the library on CAN-FD straight away. I probably had too many requirements.

Another solution would be to use a raspberry pi, but I don't think it makes sense for the bachelor thesis anymore to switch the hardware. I want to get the best out of the NXP board and include the rest as a suggestion for improvement.

I am very grateful for your support and that you want to help.

[converse]

I don't know if there is anything in FreeRTOS that would help you - there are several network stacks available, that may suit?

FreeRTOS - Real-time operating system for microcontrollers - AWS 

Alternatively, there may be something provided in ARM mbed - again, lots of connectivity options.

Mbed OS | Mbed 

[simon_hilt]

Thanks for your suggestion. I will work out a solution.