Wednesday, October 18th 2017, 7:29am UTC+2

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Kenny

Beginner

Date of registration: Jul 17th 2008

Posts: 71

Location: San Francisco Bay Area

Occupation: Embedded Systems Engineer

1

Thursday, July 21st 2016, 4:25am

MPU definition collision between RTOS.h and core_cm4.h

I'm doing some rearranging of the example project. If I include the CMSIS microcontroller header before RTOS.h in my file that integrates the RTOS I get the following error:

Quoted


1> /Volumes/Development/louise/CMSIS/CMSIS/Include/core_cm4.h:1420:46: error: expected ')' before '*' token

1> /Volumes/Development/louise/RTOS/RTOS.h:1657:12: note: in expansion of macro 'MPU'
1> /Volumes/Development/louise/CMSIS/CMSIS/Include/core_cm4.h:1420:46: error: expected ')' before '*' token
1> /Volumes/Development/louise/RTOS/RTOS.h:1657:12: note: in expansion of macro 'MPU'


`core_cm4.h` defines `FPU` as follows:


C/C++ Source code

1
 #define FPU               ((FPU_Type       *)     FPU_BASE      )

Kenny

Beginner

Date of registration: Jul 17th 2008

Posts: 71

Location: San Francisco Bay Area

Occupation: Embedded Systems Engineer

2

Thursday, July 21st 2016, 6:24am

I really need a fix for this. It's colliding with my code in other places


I've lost a lot of time trying to integrate EMBOS this time around. The features are nice (MPU support, plugin) but it's not very readable or maintainable so I find myself making many changes to clean it up. In this case I have a set of classes for the peripherals including the NVIC which leads to the include of the CMSIS header for the microprocessor. In the original file the required registers were redefined rather than use the definition in the header which I feel is poor form.

SEGGER - Martin

Super Moderator

Date of registration: Jul 1st 2014

Posts: 32

3

Thursday, July 21st 2016, 3:37pm

RE: MPU definition collision between RTOS.h and core_cm4.h

Dear Kenny,

Thank you for pointing us towards this. Your objection is basically correct: While we do not re-define any symbols already defined inside the CMSIS header, we do use "MPU" as a name for a structure member inside RTOS.h. This results in the observed problem with embOS-MPU (but not embOS) when both core_cm4.h and RTOS.h are included in that exact order. We will address this and likely change the member's name in future releases. In the meantime, however, a possible workaround is to include both files in reversed order, that is RTOS.h first and core_cm4.h second. That way, when RTOS.h is preprocessed, "MPU" is not a defined symbol to the preprocessor and thus won't be replaced.

I'm doing some rearranging of the example project. If I include the CMSIS microcontroller header before RTOS.h in my file that integrates the RTOS I get the following error:


While unrelated to your observation, we usually wouldn't recommend to include core_cm4.h directly with your application, but indirectly through the device-specific header file. This is for the reason that the device-specific header defines certain properties of your device on which the core-specific header file relies in return, e.g. __CM4_REV, __MPU_PRESENT, and __FPU_PRESENT, which otherwise may be undefined or defaulted.


`core_cm4.h` defines `FPU` as follows:

C/C++ Source code

1
 #define FPU               ((FPU_Type       *)     FPU_BASE      )


"MPU" is used in RTOS.h instead of "FPU". Since "MPU" was defined analogously in core_cm4.h, however, this does not make much of a difference.

I really need a fix for this. It's colliding with my code in other places


In urgent cases, please consider contacting us directly via our support email address. While we would usually answer request from our customers herein as well, this forum, according to its terms of use, is not meant for technical support from our technical support personnel.

I've lost a lot of time trying to integrate EMBOS this time around. The features are nice (MPU support, plugin) but it's not very readable or maintainable so I find myself making many changes to clean it up.


I'm sorry to hear your experience with embOS was that time consuming. However, since our product and especially the preconfigured start projects devilered with it will usually work with no modification at all, I'm rather surprised you needed to "clean up" embOS. I presume you are using a trial version of embOS MPU for Cortex-M and Embedded Studio? Can you give more details on your project and which modifications you had to perform? We can do this via email as well so you won't need to disclose any information on a public forum.

In this case I have a set of classes for the peripherals including the NVIC which leads to the include of the CMSIS header for the microprocessor. In the original file the required registers were redefined rather than use the definition in the header which I feel is poor form.


Can you please specify which re-definitions you are referring to? Regarding NVIC, our CMSIS-based start projects usually contain one or two definitions, but none of them re-define any symbol from the CMSIS headers.

Best regards,

SEGGER - embOS Support
Martin

Kenny

Beginner

Date of registration: Jul 17th 2008

Posts: 71

Location: San Francisco Bay Area

Occupation: Embedded Systems Engineer

4

Friday, July 22nd 2016, 3:11am

Thanks for your detailed response Martin.


In terms of clean up I'm only touching RTOSInit_STM32F4x_CMSIS.c. In that file a couple of NVIC registers and several UART registers are defined. I prefer to have them defined once in the CMSIS header. I'm not sure why you would do this at all.


I also use C++ and have my own classes for the peripherals including the NVIC. Generally defining SysTick_Handler and OSHW_Init() are pretty straight forward but I also remove many of the very sparse comments and macro definitions and anything unnecessary for my specific port for maintainability. The many macro if/else make the code very difficult to read and I try to minimize this. I understand that you probably do have to keep all of this in here to avoid code repetition.


I do not include core_cm4.h directly. Just pointing out the code. I made a mistake and included the FPU rather than MPU definition from core_cm4.h. It was a late night.


I didn't realize that the support email was still active. So many companies have moved to a forum. We are in the process of purchasing the EMBOS license so I will send urgent requests there and post others here.


The JLINKMEM stuff threw me. I didn't know whether I needed or not so lost some time there. I thought RTT was the name of the game these days.


I understand that most embedded engineers will just include whatever they are given but there are a few of us that try to keep code tidy in the spirit of future maintenance.

SEGGER - Martin

Super Moderator

Date of registration: Jul 1st 2014

Posts: 32

5

Friday, July 22nd 2016, 11:43am

Dear Kenny,

I also use C++ and have my own classes for the peripherals including the NVIC. Generally defining SysTick_Handler and OSHW_Init() are pretty straight forward but I also remove many of the very sparse comments and macro definitions and anything unnecessary for my specific port for maintainability. The many macro if/else make the code very difficult to read and I try to minimize this. I understand that you probably do have to keep all of this in here to avoid code repetition.

Many of the #if/#else directives used in RTOSInit originate from the different communication channels associated with embOSView. Furthermore, in regards to RTOSInit_STM32F4x_CMSIS.c, this specific file was intended to fit several different hardware setups, and thus includes different initializations for different USARTs used with different eval boards. I fully agree that this adds to a rather crowded impression. Usually, however, our start projects do not contain more than one USART initialization, and in some cases we may completely omit any USART initialization in favor of communication via Jlink. The resulting source files effectively are much easier to maintain. Other #if/#else directives target different compilers or other mandatory aspects and thus may, unfortunately, not be omitted. However, we are constantly striving to make our source code more convenient to work with, and thus have just recently re-thought some of the macro definitions used in our RTOSInit files, effectively rendering the source code even more readable and maintainable. These modifications will be integrated in future releases of embOS and embOS-MPU.

In terms of clean up I'm only touching RTOSInit_STM32F4x_CMSIS.c. In that file a couple of NVIC registers and several UART registers are defined. I prefer to have them defined once in the CMSIS header. I'm not sure why you would do this at all.

We'd usually do this for compatibility reasons. For example, we've seen cases in which, while sporadic, the device speficic files were altered in a way that was incompatible to a previous version. Still, we're always open for suggestions and improvements, hence we'll likely address this as well in the near future.

I didn't realize that the support email was still active. So many companies have moved to a forum.

We rather see the forum as a valuable addition to our regular support, which itself is offered via email. For further information, please also refer to the User & Reference Guide for embOS, which includes a dedicated chapter on our support.

The JLINKMEM stuff threw me. I didn't know whether I needed or not so lost some time there. I thought RTT was the name of the game these days.

JlinkMEM is used exclusively for communication with embOSView. There's no need to keep it if you don't intend to use embOSView, or else prefer a serial connection to do so.

Best regards,

Martin