Visual Studio 2017+Visual Micro+Teensyduino+Teensy 4.0 warns: "EMIT not typename"

Status
Not open for further replies.

LeD

Member
Visual Studio 2017+Visual Micro+Teensyduino+Teensy 4.0 warns: "EMIT not typename"

Hello guys,

I've a little problem here.
I'm quite lazy and I like to work with advanced IDEs like VS and all the stuffs that make my work easy.

I'm typically working with the following configuration:
- VS 2017 Pro (ver. 15.9.17)
- Arduino libraries (ver. 1.8.10 installed now)
- Visual Micro Add-on (ver. 1911.23.0)
- Teensyduino libraries (ver. 1.48)

Turning to Teensy 4.0 a project I already made for Teensy 3.6 that works very well, the Intellisense of Visual Studio completely breaks up, generating warnings like "The EMIT variable is not a type name" for all the typenames and keywords of the code.
Consider that:
- If I return to Teensy 3.6, the warnings disappear;
- Any project, even the most stupid (like empty setup() and loop()) generates the same error;
- I reinstalled everything;

I know that EMIT should be a compiler preprocessor keyword, but I really don't get what's the difference between a Teensy 3.6 and Teensy 4.0 project that generates this warning.
If someone has an advice to solve this problem, I would appreciate much.
 
For what it's worth, I am using
VS2019 16.3.5
VM 1909.27.0
Arduino 1.8.9
Teensyduino 1.47

and everything works fine with both T3.6 and T4. I doubt the problem crops up due to your using VS 2017 and my using 2019. You are basically one update version ahead of me in terms of VM/Arduino and Teensyduino. Have you used the combination of versions that I use, in the past, and did that work? You might try that combination. I have a few active Teensy/ESP32 projects on the go now, and have resisted updating the whole toolchain til I was finished.
Cheers
 
Can you reproduce the problem using only Arduino+Teensyduino?

Thank you Paul for your reply. Just done it, it works without any error/warning, at least for a simple project.
I will try for the full project to check if I can make it without using Visual Studio.
But, as I mentioned in my first post, it is a "problem" regarding just the intellisense, a stuff for lazy guys that generates information for debugging while writing the code.
 
For what it's worth, I am using
VS2019 16.3.5
VM 1909.27.0
Arduino 1.8.9
Teensyduino 1.47

and everything works fine with both T3.6 and T4. I doubt the problem crops up due to your using VS 2017 and my using 2019. You are basically one update version ahead of me in terms of VM/Arduino and Teensyduino. Have you used the combination of versions that I use, in the past, and did that work? You might try that combination. I have a few active Teensy/ESP32 projects on the go now, and have resisted updating the whole toolchain til I was finished.
Cheers

Hello bmillier, thank you for your reply.
I suppose the problem may arise because I'm using VS2019, maybe because last version of VM has not been tested fully with VS2017.
Consider that I started to have this problem with Teensyduino (1.48), Arduino (1.8.9) and VM(1909.27.0) in VS2017 and I updated the libraries until I found updates.
I will try on another PC with VS2019 if there is the same issue found here.

Cheers.
 
You can also give VisualTeensy a try. https://github.com/luni64/VisualTeensy
This uses VSCode which works IMHO better than VisualStudio since it uses gcc for the intellisense analysis. Thus it doesn't need to "trick" the microsoft compiler into analyzing code written for gcc which often generates the problem you mentioned.
 
You can also give VisualTeensy a try. https://github.com/luni64/VisualTeensy
This uses VSCode which works IMHO better than VisualStudio since it uses gcc for the intellisense analysis. Thus it doesn't need to "trick" the microsoft compiler into analyzing code written for gcc which often generates the problem you mentioned.

I'm a lazy programmer, I use Visual studio even for displaying simple (non-code) text...
Anyway, if I can't find any other solution, I will give it a try :)
 
Hello bmillier, thank you for your reply.
I suppose the problem may arise because I'm using VS2019, maybe because last version of VM has not been tested fully with VS2017.
Consider that I started to have this problem with Teensyduino (1.48), Arduino (1.8.9) and VM(1909.27.0) in VS2017 and I updated the libraries until I found updates.
I will try on another PC with VS2019 if there is the same issue found here.

Cheers.

Just to check, I reinstalled your configuration, except VS2017 that I cannot remove here at work.
VM 1909.27.1 (I didn't find the 1909.27.0)
Arduino 1.8.9
Teensyduino 1.47
Unfortunately, the error is the same. Even the most basic project template, goes from zero warnings for Teensy 3.6 to thousands of warnings for T4.0

I will investigate more at home, where I can try VS2017 and VS2019.
 
@LEd Have you posted this on the Visual Micro forum? Whenever I have had an issue where the Arduino IDE/Teensyduino would compile a program properly, and VM wouldn't (usually after a VM and/or teensyduino update) , I have posted it there. Tim Leek, the VM creator is very prompt at addressing these types of issues.
Cheers
 
@LEd Have you posted this on the Visual Micro forum? Whenever I have had an issue where the Arduino IDE/Teensyduino would compile a program properly, and VM wouldn't (usually after a VM and/or teensyduino update) , I have posted it there. Tim Leek, the VM creator is very prompt at addressing these types of issues.
Cheers
I've just replicated the problem at home. VS2017 (Community, 15.9.17) + Visual Micro 1909.27.1 + Arduino 1.8.9 + Teensyduino 1.47 generate thousand of unmeaningful warnings.
And verified that the same configuration, with VS2019 (Community, 16.3.10), it doesn't generate any warning.
I will post this in the VM forum, thank you for your hints.
 
@Led. Here is something I've had to do at times when things go astray. In the sketch folder, delete everything but the .ino file, including those _vm and release folders and VMs project files. Then, restart VM, and open the arduino project again. On compile, it will do all of the building over from scratch, instead of using the files it placed in the _vm and release folders. Sometimes, when I get tons of errors, and have been doing some complex stuff (including editing library files that the program needs), this works.
Worth a try.
Cheers
 
Status
Not open for further replies.
Back
Top