vscode-cpptools
vscode-cpptools copied to clipboard
microsoft
request to support sdcc mcs51 declarations (__sfr, __sbit, etc)
sdcc, which is quite popular open-source, free embedded compiler, uses special extensions for intel 8051 (aka mcs51) define special function registers and other similar things (like code, ram space, etc) e.g.
__sfr __at (0xC0) P4 ;
__sbit __at (0xC0) P4_0 ;
extensions are discussed further in section 3.5.1 of sdcc user guide: http://sdcc.sourceforge.net/doc/sdccman.pdf
We are using sdcc for a new platformio intel-mcs51 platform, (https://github.com/platformio/platform-intel_mcs51) and would love to be able to use the vscode cpptools intellisense here to peek at register definitions, etc.
I see this was previously discussed and rejected for keil C51 compiler at #1821, however I think this is quite different in that Keil is closed/proprietary/non-free (and has it's own ide) whereas sdcc is completely free and opensource, and sdcc+platformio+vscode+cpptools are getting really close to making full open-source ide stack
tagging a few stakeholders: @ivankravets @spth @znhocn
Probably, STM8 interrupt case falls here too. ISR is declared this way:
void tim4_isr(void) __interrupt(ITC_IRQ_TIM4_OVF)
vscode expects { instead of __interrupt.
Hi, I would vote for the same thing. It doesn't need to be MCS51 specific; since __sfr and __at are also used in other platforms (at least, I'm using them in Z80/HD64180/Z180).
I would really appreciate this support, I am programming for SDCC and if I use void IRQHandler __interrupt() { }, it then messes up the whole document error checking.
My workaround for this is to edit .vscode/c_cpp_properties.json and edit the"defines"array so that intellisense thinks that the additional keywords are pre-processor defines. Something like:
...
"defines": ["__interrupt(IntelliSense_Hack)=", ...],
...
When you mouseover __interrupt(nn) in your actual code, you will see some garbage tooltip of
"#define __interrupt(IntelliSense_Hack)" but that's only assumed by vscode and not by sdcc / your actual compiler, so the code compiles correctly.
I've filed a feature request on VS (if they add support, we would probably get it too due to shared code): https://developercommunity.visualstudio.com/idea/1122536/c-intellisense-request-to-support-sdcc-mcs51-decla.html
@ipa64 The issue at https://developercommunity.visualstudio.com/idea/1122536/c-intellisense-request-to-support-sdcc-mcs51-decla.html needs more upvotes...unfortunately, we don't have a way to link upvotes on GitHub to developer community upvotes.
If more people could upvote https://developercommunity.visualstudio.com/idea/869998/enable-vs-code-users-with-github-accounts-to-upvot.html then maybe they'd figure out a way to make it easier for GitHub votes to get tracked in VS issues.
UPDATE: Actually, we changed our vote tracking policy, so you can just upvote this issue on GitHub.
I think I have SOLVED.
Just #include "C:/Program Files/SDCC/include/mcs51/lint.h" and everything is wonderful =D
If you have C:/Program Files/SDCC/** or something like that on the includePath (.vscode/c_cpp_properties.json file) you can simply use #include "mcs51/lint.h".
Edit:
Of course, you still have to include the header for your uC, like #include <8052.h>
Same here, upvoted this issue. I've also created a more general issue since I didn't feel the title and content wasn't general enough -- see link above.
It would be really great to see SDCC compiler support in VSCode!
I think I have SOLVED. Just
#include "C:/Program Files/SDCC/include/mcs51/lint.h"and everything is wonderful =D If you haveC:/Program Files/SDCC/**or something like that on the includePath (.vscode/c_cpp_properties.json file) you can simply use#include "mcs51/lint.h".Edit: Of course, you still have to include the header for your uC, like
#include <8052.h>
There are still some probrems with intellsense, some key words like P0_1 still cannot be determined correctly. Just like this
When I added the sdcc include path to my project, Visual Studio Code's default c_cpp_properties.json came with a default "cStandard: c17" setting. Since sdcc itself is based on C99 (https://sdcc.sourceforge.net/), changing it to c99 satisfies Intellisense for my project files:
However, it still complains about the sdcc internal implementation:
Not a solution, but a workaround until sdcc is fully supported by VSC.
Actually, the current SDCC release 4.2.0 supports C11 by default (and C17 is just a clarification of C11).
Is there a patch or dirty hack that does this?
Borrow the above method:
You can define it in the defines of c_cpp_properties.json
"__sfr=unsigned char",
"__sbit=int",
"__at(a)= ",
__sfr __at (0x80) P0; // before
unsigned char P0; // after
This only affects IntelliSense.
I've added this configuration to my workspace:
But the keyword __interrupt is still flagged as an error:
What did I do wrong?
You will likely need to set the define as "__interrupt=" to make IntelliSense skip over it (the = is important so that it is assigned an empty string value instead of the number 1). If that still doesn't clear the error, please run the C/C++: Log Diagnostics command while the file is opened and share the output so we can determine why the define is not being used.
@ultrapoci I saw an update from you which seems to be deleted now (?). Based on what you said, the problem is that you are using the clangd extension for IntelliSense and it does not consider the c_cpp_properties.json configurations at all. I am not aware of a way to achieve what you want if you are using clangd for IntelliSense.
@ultrapoci I saw an update from you which seems to be deleted now (?). Based on what you said, the problem is that you are using the clangd extension for IntelliSense and it does not consider the
c_cpp_properties.jsonconfigurations at all. I am not aware of a way to achieve what you want if you are using clangd for IntelliSense.
Yeah, sorry, for some reason I thought I was on the clangd repo, sorry for the dumb mistake. But I've also experimented with the C/C++ extension and your suggestion worked. It was also helpful because I was able to solve the issue in clangd as well, by passing -D__interrupt flag to the compiler. Now the word is treated as an empty macro. Thank you!
