Skip to main content
CKauf
Associate II
June 12, 2019
Solved

Using Visual Studio for hardware integration?

  • June 12, 2019
  • 2 replies
  • 1492 views

Hello,

is it possible to use VS for coding the hardware integration side of a TGFX-Application?

I tried the following:

I downloaded the example project from here.

When I tried to make some modifications to model.cpp the Intellisense didn't find any commands relatet to the BSP. My guess was, that because "SIMULATOR" is definded, all the code relatet to the BSP is being ignored as it sits inside an #ifndef-block.

Because I could not find a way to "undefine" SIMULATOR I changed the code from

#ifndef SIMULATOR
#include "stm32746g_discovery.h"
#endif

to

#include "stm32746g_discovery.h"

But this just resulted in a "File not found"-Error.

Adding the file's folder to the project resulted in even more errors due to missing files and datatypes.

So I guess my question is: Is it possible to use VS for all the coding (using the TGFX-Designer to compile for target)? I am not aiming at compiling from VS (this would be a bonus, of course ;) ).

Or do you recommend using VS only for the GUI/Simulator and using a different IDE (for example SW4STM32) for the hardware integration?

Thank you and best regards

Christoph

This topic has been closed for replies.
Best answer by Martin KJELDSEN

Hi,

It's entirely possible to simply code the UI using Visual studio and test certain things in the SDL simulator when running the application. Then use your target cross compiler (IAR, KEIL, CubeIDE, etc) to compile the files for your target.

Some of us do that here.

Addition: To be more explicit: You cannot compile target-specific things with visual studio. You can only verify the application UI using SDL on windows. But then, yes, you can use the designer (arm-gcc) to compile to target, but you would be using TGFX designer as a sort of IDE which it is not that suitable for since it only gives you the errors in a log window. But if that works for you, you can definitely do it that way. But, MSVS is Simulator only. There are symbols and intrinsics that MSVS does not understand.

/Martin

/Martin

2 replies

Martin KJELDSEN
Martin KJELDSENBest answer
Principal III
June 12, 2019

Hi,

It's entirely possible to simply code the UI using Visual studio and test certain things in the SDL simulator when running the application. Then use your target cross compiler (IAR, KEIL, CubeIDE, etc) to compile the files for your target.

Some of us do that here.

Addition: To be more explicit: You cannot compile target-specific things with visual studio. You can only verify the application UI using SDL on windows. But then, yes, you can use the designer (arm-gcc) to compile to target, but you would be using TGFX designer as a sort of IDE which it is not that suitable for since it only gives you the errors in a log window. But if that works for you, you can definitely do it that way. But, MSVS is Simulator only. There are symbols and intrinsics that MSVS does not understand.

/Martin

/Martin

CKauf
CKaufAuthor
Associate II
June 14, 2019

Hej Martin,

so I can't use VS to code the "target-specific low level C-stuff" as it does not know the neccessary symbols.* Thank you for that clarification.

Well, I guess I will bite the bullet and get familiar with CubeIDE then ;)

Thanks again for your support (also in all the other threads).

Best Regard

Christoph

*I guess I could, but without the Intellisense-features VS would just be a glorified text-editor while throwing errors the whole time...

Martin KJELDSEN
Principal III
June 14, 2019

To be more explicit: You cannot compile target-specific things with visual studio. You can only verify the application UI using SDL on windows. But then, yes, you can use the designer (arm-gcc) to compile to target, but you would be using TGFX designer as a sort of IDE which it is not that suitable for since it only gives you the errors in a log window. But if that works for you, you can definitely do it that way. But, MSVS is Simulator only. There are symbols and intrinsics that MSVS does not understand.

/Martin