Welcome, Guest. Please Login or Register
Arduino IDE for Visual Studio
 
 
When Logging a Support Issue in the Forum, please ensure you have also:-
  • Enabled vMicro > Compiler > Show Build Properties and Verbose
  • Re-Compile your program with these settings enabled
 
Save the new Output to a Text File and....
Support requests without the output above may be impossible to answer, so please help us to help you
 
  HomeSearch Tutorials & Wiki visualmicro.com LoginHelpRegister  
 
Page Index Toggle Pages: 1
Send Topic Print
How to reference #defines created in a project from library code - SOLVED (Read 1386 times)
Bob Jones
Full Member
***
Offline



Posts: 207
Bellingham, WA
How to reference #defines created in a project from library code - SOLVED
Jul 25th, 2018 at 5:13am
 
I am working on two sketches (Transmitter and Receiver) that communicate over nRF24L01 WiFi. I developed one class (BJRH24SendReceive) that supports both sketches. I am getting very strange compiler behavior with both sketches: one has 10 errors that look like this:

<code>Severity      Code      Description      File      Line
Error            undefined reference to BJBufferManager  BJBufferManager(unsigned int)      D:\Documents\Arduino\Communications\nRF24L01\nRF24L01_Test_Transmitter\nRF24L01_
Test_Transmitter.ino      65</code>

It is looking for BJBufferManager, but if I hold the mouse over the bad code, it clearly finds BJBudderManager.

The other module produces a bunch of errors that look like this:

<code>BJRF24SendReceive.cpp: 67:19: error: 'WIFI_POWER_LEVEL' was not declared in this scope
   radio.setPALevel(WIFI_POWER_LEVEL)</code>

WIFI_POWER_LEVEL is also defined - I hover the mouse over it and the value and comments are displayed.

The Compiler output for both of these is attached. Love any ideas you may have.
Back to top
« Last Edit: Jul 27th, 2018 at 8:22pm by Visual Micro »  
WWW  
IP Logged
 
Visual Micro
Administrator
*****
Offline



Posts: 10565
United Kingdom
Re: Strange Compiler Behaviors
Reply #1 - Jul 25th, 2018 at 5:21pm
 
I guess the errors you have shown in your post are intellisense errors. as you know you should ignore them and use the build output to report errors.

I suggest you go through the links to libraries and ensure the expected libraries are being found in the expected location. It's possible your chosen libraries and code expects certain versions so let's have a clear understand of what you expect.

Code:
Building core ...

Building libraries ...
"D:\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -Wall -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -flto -mmcu=atmega328p  -I"D:\Documents\Arduino\Communications\nRF24L01\nRF24L01_Test_Receiver" -DVM_DEBUG_BREAKPAUSE -DVM_DEBUGGER_TYPE=VM_DEBUGGER_TYPE_HARDWARESERIAL -DVM_DEBUGGER_TYPE_SERIALUSB=18 -DVM_DEBUGGER_TYPE_USBAPI=17 -DVM_DEBUGGER_TYPE_NET_UDP=16 -DVM_DEBUGGER_TYPE_HARDWARESERIAL3=15 -DVM_DEBUGGER_TYPE_HARDWARESERIAL2=14 -DVM_DEBUGGER_TYPE_HARDWARESERIAL1=13 -DVM_DEBUGGER_TYPE_CDCSerialClass=12 -DVM_DEBUGGER_TYPE_COSA=11 -DVM_DEBUGGER_TYPE_Uart=10 -DVM_DEBUGGER_TYPE_NET_CONSOLE=9 -DVM_DEBUGGER_TYPE_TTYUART=8 -DVM_DEBUGGER_TYPE_USBSERIAL=7 -DVM_DEBUGGER_TYPE_USART=6 -DVM_DEBUGGER_TYPE_UART=5 -DVM_DEBUGGER_TYPE_TEENSY=4 -DVM_DEBUGGER_TYPE_USB=3 -DVM_DEBUGGER_TYPE_FASTSERIAL=2 -DVM_DEBUGGER_TYPE_SOFTWARESERIAL=1 -DVM_DEBUGGER_TYPE_HARDWARESERIAL=0 -DVM_DEBUG_BANDWIDTH_THROTTLE_MS=33 -DVM_DEBUG_ENABLE=1 -DVM_DEBUG -DF_CPU=16000000L -DARDUINO=10805 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR -I"D:\Arduino\hardware\arduino\avr\cores\arduino" -I"D:\Arduino\hardware\arduino\avr\variants\eightanaloginputs" -I"D:\Documents\Arduino\libraries\BJBufferManager\src" -I"D:\Documents\Arduino\libraries\BJRF24SendReceive\src" -I"D:\Documents\Arduino\libraries\RF24" -I"D:\Arduino\hardware\arduino\avr\libraries\SPI\src" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers\VM_DBG" -I"D:\Arduino\libraries" -I"D:\Documents\Arduino\libraries" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers" -I"D:\Arduino\hardware\arduino\avr\libraries" "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers\VM_DBG\VM_DBG.cpp" -o "C:\Users\rhjon\AppData\Local\Temp\VMBuilds\nRF24L01_Test_Receiver\nano_atmega328\Debug\VM_DBG\VM_DBG.cpp.o"
"D:\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -Wall -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -flto -mmcu=atmega328p  -I"D:\Documents\Arduino\Communications\nRF24L01\nRF24L01_Test_Receiver" -DVM_DEBUG_BREAKPAUSE -DVM_DEBUGGER_TYPE=VM_DEBUGGER_TYPE_HARDWARESERIAL -DVM_DEBUGGER_TYPE_SERIALUSB=18 -DVM_DEBUGGER_TYPE_USBAPI=17 -DVM_DEBUGGER_TYPE_NET_UDP=16 -DVM_DEBUGGER_TYPE_HARDWARESERIAL3=15 -DVM_DEBUGGER_TYPE_HARDWARESERIAL2=14 -DVM_DEBUGGER_TYPE_HARDWARESERIAL1=13 -DVM_DEBUGGER_TYPE_CDCSerialClass=12 -DVM_DEBUGGER_TYPE_COSA=11 -DVM_DEBUGGER_TYPE_Uart=10 -DVM_DEBUGGER_TYPE_NET_CONSOLE=9 -DVM_DEBUGGER_TYPE_TTYUART=8 -DVM_DEBUGGER_TYPE_USBSERIAL=7 -DVM_DEBUGGER_TYPE_USART=6 -DVM_DEBUGGER_TYPE_UART=5 -DVM_DEBUGGER_TYPE_TEENSY=4 -DVM_DEBUGGER_TYPE_USB=3 -DVM_DEBUGGER_TYPE_FASTSERIAL=2 -DVM_DEBUGGER_TYPE_SOFTWARESERIAL=1 -DVM_DEBUGGER_TYPE_HARDWARESERIAL=0 -DVM_DEBUG_BANDWIDTH_THROTTLE_MS=33 -DVM_DEBUG_ENABLE=1 -DVM_DEBUG -DF_CPU=16000000L -DARDUINO=10805 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR -I"D:\Arduino\hardware\arduino\avr\cores\arduino" -I"D:\Arduino\hardware\arduino\avr\variants\eightanaloginputs" -I"D:\Documents\Arduino\libraries\BJBufferManager\src" -I"D:\Documents\Arduino\libraries\BJRF24SendReceive\src" -I"D:\Documents\Arduino\libraries\RF24" -I"D:\Arduino\hardware\arduino\avr\libraries\SPI\src" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers\VM_DBG" -I"D:\Arduino\libraries" -I"D:\Documents\Arduino\libraries" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers" -I"D:\Arduino\hardware\arduino\avr\libraries" "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers\VM_DBG\VM_mem_check_sam.cpp" -o "C:\Users\rhjon\AppData\Local\Temp\VMBuilds\nRF24L01_Test_Receiver\nano_atmega328\Debug\VM_DBG\VM_mem_check_sam.cpp.o"

Using library BJBufferManager version 1.0.0 in folder "file:///D:/Documents/Arduino/libraries/BJBufferManager"
  Using previously compiled file: C:\Users\rhjon\AppData\Local\Temp\VMBuilds\nRF24L01_Test_Receiver\nano_atmega328\Debug\BJBufferManager\BJBufferManager.cpp.o

Using library BJRF24SendReceive version 1.0.0 in folder "file:///D:/Documents/Arduino/libraries/BJRF24SendReceive"
"D:\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -Wall -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -flto -mmcu=atmega328p  -I"D:\Documents\Arduino\Communications\nRF24L01\nRF24L01_Test_Receiver" -DVM_DEBUG_BREAKPAUSE -I"D:\Arduino\hardware\arduino\avr\variants\eightanaloginputs" -I"D:\Documents\Arduino\libraries\BJBufferManager\src" -I"D:\Documents\Arduino\libraries\BJRF24SendReceive\src" -I"D:\Documents\Arduino\libraries\RF24" -I"D:\Arduino\hardware\arduino\avr\libraries\SPI\src" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers\VM_DBG" -I"D:\Arduino\libraries" -I"D:\Documents\Arduino\libraries" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers" -I"D:\Arduino\hardware\arduino\avr\libraries" "D:\Documents\Arduino\libraries\BJRF24SendReceive\src\BJRF24SendReceive.cpp" -o "C:\Users\rhjon\AppData\Local\Temp\VMBuilds\nRF24L01_Test_Receiver\nano_atmega328\Debug\BJRF24SendReceive\BJRF24SendReceive.cpp.o"

BJRF24SendReceive.cpp:6: In file included from

BJRF24SendReceive.h: 34:31: error: 'WIFI_CONTROLLER_ADDRESS' was not declared in this scope
   byte controllerAddress[6] = WIFI_CONTROLLER_ADDRESS

BJRF24SendReceive.h: 35:26: error: 'WIFI_ROBOT_ADDRESS' was not declared in this scope
   byte robotAddress[6] = WIFI_ROBOT_ADDRESS

BJRF24SendReceive.h: 36:34: error: 'WIFI_RECEIVE_TIMEOUT' was not declared in this scope
   unsigned long receiveTimeout = WIFI_RECEIVE_TIMEOUT

Using library RF24 version 1.3.1 in folder "file:///D:/Documents/Arduino/libraries/RF24"
  Using previously compiled file: C:\Users\rhjon\AppData\Local\Temp\VMBuilds\nRF24L01_Test_Receiver\nano_atmega328\Debug\RF24\RF24.cpp.o

Using library SPI version 1.0 in folder "file:///D:/Arduino/hardware/arduino/avr/libraries/SPI"

  Using previously compiled file: C:\Users\rhjon\AppData\Local\Temp\VMBuilds\nRF24L01_Test_Receiver\nano_atmega328\Debug\SPI\SPI.cpp.o
Error compiling libraries
BJRF24SendReceive.h: 64:21: error: 'WIFI_CE_PIN' was not declared in this scope
Debug build failed for project 'nRF24L01_Test_Receiver'
   RF24 radio = RF24(WIFI_CE_PIN, WIFI_CSN_PIN)

BJRF24SendReceive.h: 64:34: error: 'WIFI_CSN_PIN' was not declared in this scope
   RF24 radio = RF24(WIFI_CE_PIN, WIFI_CSN_PIN)
BJRF24SendReceive.cpp: In member  

Back to top
« Last Edit: Jul 25th, 2018 at 5:22pm by Visual Micro »  
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline



Posts: 207
Bellingham, WA
Re: Strange Compiler Behaviors
Reply #2 - Jul 25th, 2018 at 9:11pm
 
Tim,

I tried compiling the same code with the Arduino IDE and VS/VM and came up with radically different results. There are three .txt files in the ZIP file:

  • Arduino IDE Compiler Output.txt
    Visual Micro Compiler Output.txt
    Combined Compiler Errors.txt <-- Shows the different errors detected by each


One reply on the Arduino Forum suggested that I the "project output of tree /F /A", but I have no idea what that means or how to accomplish it. I will continue pounding on this code, but I am pretty stumped about what is happening.

Thanks,

Bob Jones
Back to top
 
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline



Posts: 207
Bellingham, WA
Re: Strange Compiler Behaviors
Reply #3 - Jul 25th, 2018 at 9:45pm
 
I thought that a screen shot may help. The attached shows both the successful declaration of the BJBufferManager and BJRF24SendReceive objects (see lines 11-12) and their unsuccessful use (see lines 23++).

I will post one more image of the Solution Explorer panel.



Back to top
 
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline



Posts: 207
Bellingham, WA
Re: Strange Compiler Behaviors
Reply #4 - Jul 25th, 2018 at 9:46pm
 
Here is one more image showing the Solution Explorer contents.
Back to top
 
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline



Posts: 207
Bellingham, WA
Re: Strange Compiler Behaviors
Reply #5 - Jul 25th, 2018 at 9:55pm
 
Tim,

I have compiled both with and without IntelliSense. The same errors occur either way. I have checked and rechecked the referenced libraries and they are good.

And I still get different errors when I compile the same code using the Arduino IDE vs. VS/VM code.

Bob
Back to top
 
WWW  
IP Logged
 
Visual Micro
Administrator
*****
Offline



Posts: 10565
United Kingdom
Re: Strange Compiler Behaviors
Reply #6 - Jul 25th, 2018 at 9:57pm
 
Let me see if I can sum things up?

  • You have an arduino project and some libraries that you have created
  • You are getting errors in one or more of your libraries that reference missing defines such as 'WIFI_CONTROLLER_ADDRESS'
  • You have a header file in your arduino project where you have #defined all the variables that are reported as missing in your library

Is this correct?
Back to top
« Last Edit: Jul 25th, 2018 at 9:57pm by Visual Micro »  
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline



Posts: 207
Bellingham, WA
Re: Strange Compiler Behaviors
Reply #7 - Jul 25th, 2018 at 10:12pm
 
Close, but not completely accurate.

I am including two libraries that I have created (the BJ... ones) plus two others (SPI and RF24).

The errors are happening in the .INO file, not in the libraries. The errors are different in the Arduino IDE than in the VS/VM ide.

The defines all come from a file that is included in the .INO file. I have proven that each of these defines is recognized successfully by the VS/VM compiler, but have not made the same proof of the Arduino IDE.

Your third assumption is correct.



Back to top
 
WWW  
IP Logged
 
Visual Micro
Administrator
*****
Offline



Posts: 10565
United Kingdom
Re: Strange Compiler Behaviors
Reply #8 - Jul 25th, 2018 at 10:26pm
 
Yes I know you are using some other libs too but the errors relate only to your code.

I posted a clear error for you earlier. which came from the real build output window and not the  Errors List which is hard to read.

My recommendation is to close the Errors List and never open it again. With the output window you will have something that is close to what the arduino ide will produce.

As I have stated the error clearly shows that a #define from your project header file is not available in your library code.

You have said you can see your defines in your project but that is because you have header file that creates the defines in the project. The file is RemoteControllerDefinition.h

So the problem put simply is that #defines from project\RemoteControllerDefinition.h are unavailable in a library code BJBufferManager\BJBufferManager.h

That is correct. An Arduino library has no access to project code. It's a basic rule.

In the BJBufferManager.h you have commented a previous attempt to #include RemoteControllerDefinition.h. That attempt would have failed intellisense parsing and also the build would fail objecting to a missing RemoteControllerDefinition.h. Vs shows you it can find your #defines without need for #include because it assumes the code will build as one program but libs are separate.

Solution

You should un-comment the #include in BJBufferManager.h but change it to this:-
Code:
#include <RemoteControllerDefinition.h> 



Then add a compiler include for the project folder as follows using "project property>extra flags". No need to hard code a path use the build {variable}:-
Code:
-I"{sketch_path}" 












Back to top
 
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline



Posts: 207
Bellingham, WA
Re: Strange Compiler Behaviors
Reply #9 - Jul 26th, 2018 at 4:16am
 
Tim,

Thanks for the extensive feedback, but I still have a problem. Actually two problems. I put together a test case to prove or disprove your assertion that defines included in a sketch are not available to a library. It is attached.

In this test, DefineScopeTest.ino includes Defines.h and a library class called NewClass.h. the sketch creates an instance of NewClass which does not include Defines.h (the line to include it is commented out). Defines.h contains only "#define FOO true". The NewClass constructor displays the value of FOO.

This seems to prove that defines included in the .ino file are accessible to library files.

I have literally thousands of lines of code that support this assertion, so I am puzzled by your statement that "An Arduino library has no access to project code. It's a basic rule."

Bob

Back to top
 

WWW  
IP Logged
 
Visual Micro
Administrator
*****
Offline



Posts: 10565
United Kingdom
Re: Strange Compiler Behaviors
Reply #10 - Jul 26th, 2018 at 8:02pm
 
Yes it is confusing but correct.

You have code in a .h file not a .cpp. You will see in the verbose output that header files are not compiled, .cp;.cpp and .s files are compiled.

If you add a cpp to your library then it won't compile with the code your would normally put in the .cpp

One little tip, I realize this was just a test, is that library resolution is better if the library contains a header file with the same name as the containing folder. . For example \DefineScopeTestClass\DefineScopeTestClass.h.





Back to top
 
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline



Posts: 207
Bellingham, WA
Re: Strange Compiler Behaviors
Reply #11 - Jul 26th, 2018 at 10:55pm
 
Tim,

I have spent all day pointing on this and am deeply puzzled by what I see. I have included three screen shots and the compiler output. Here's the summary. Img1 shows that the compiler is including the Robot.h file correctly for this sketch. Img2 shows that it is also including the BJBufferManager and BJRF24SendReceive headers properly. Img3 highlights (but not so obviously) the problem. There is an error message being generated that says, the WIFI_CE_PIN and WIFI_CSN_PIN "was not declared in this scope." But if I hold the mouse over this code, the definition pops up correctly, so the compiler DOES know about them but is somehow getting confused.

I am so baffled by this that I did a complete hardware memory scan just to see if it was some sort of hardware problem.

Any clarity you can shed on this mess, gratefully appreciated.
Back to top
 
WWW  
IP Logged
 
Visual Micro
Administrator
*****
Offline



Posts: 10565
United Kingdom
Re: Strange Compiler Behaviors
Reply #12 - Jul 26th, 2018 at 11:48pm
 
Hi Bob,

The visual studio intellisense and the visual micro compiler are two separate things. Intellisense should be considered as help/tips only and in this case, as explained earlier in this post, visual studio does not know that arduino libraries and core are compiled as separate items. You could open one ide for libs and one for your project but that's a faff so the downside of the simplicity of vs shared projects is that vs thinks libraries to be part of the project.

It would help to know you have read my previous post about sharing defines from the project inside libraries and how to #include and set the -I compiler switch before I look at your files.

Thanks
Back to top
 
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline



Posts: 207
Bellingham, WA
Re: Strange Compiler Behaviors
Reply #13 - Jul 27th, 2018 at 12:12am
 
Tim,

I have read every line of each of your posts several times, but that doesn't assure either of us that I understand what I am reading.

You make several references to intellisense, but with I compiling with indellisense, or at least I don't think I am.

I am religious about using the -I switch. In the img1, you should be able to see that Robot.h seems to be being included properly. are you saying that when I hover over the references to its values (see IMG3), that is intellisense lying to me? I guess what I am asking is that if the file with the definitions is included, shouldn't the definitions in that file be visible?

Thanks again for all your help.
Back to top
 
WWW  
IP Logged
 
Visual Micro
Administrator
*****
Offline



Posts: 10565
United Kingdom
Re: Strange Compiler Behaviors
Reply #14 - Jul 27th, 2018 at 1:20am
 
I see. Yes it's intellisense "lying" to you unless you have added the project folder as a -I compiler include. It's a 90% solution if you want to edit libraries in the same solution as your project without giving access to -I{sketch_path}. Of course you do not have to do that but you have to weigh accuracy with convenience.

Hovering a variable is intellisense, red squiggles are intellisense, the errors list with intellisense selected is intellisense, right click f12 goto definition is intellisense, view code snippets and everything in the editor is intellisense.

When you build the "Micro Build" output window is the real compile. It does also pump errors and warnings into errors list but, as I said, it is hard to read. The Micro Output window after a verbose build should show similar information to the arduino ide when it builds in verbose mode. So a real arduino build should always be something clear.

Back to top
« Last Edit: Jul 27th, 2018 at 5:47pm by Visual Micro »  
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline



Posts: 207
Bellingham, WA
Re: Strange Compiler Behaviors
Reply #15 - Jul 27th, 2018 at 4:27pm
 
Tim,

Thanks again for the help. What I still don't understand is why can Intellisese see the value of defines that aren't visible to the compiler? They have been read in and captured somewhere, but the compiler seems oblivious to this. How is that?

Bob
Back to top
 
WWW  
IP Logged
 
Visual Micro
Administrator
*****
Offline



Posts: 10565
United Kingdom
Re: Strange Compiler Behaviors
Reply #16 - Jul 27th, 2018 at 5:45pm
 
Have you set the -I compiler include? if so what is it set to and what is the name of the property you have used? Does the include path show in the compiler output when compiling your lib code?

If you lib code cached from a previous compile? Did you click Build>Clean to ensure the libs are rebuilt? The compiler output clearly shows when building from cache. If you have not changed lib source but have added the project -I include then this could be the issue.

Have you added the #include in the lib code for the defines.h that exists in the project folder?
Back to top
 
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline



Posts: 207
Bellingham, WA
Re: Strange Compiler Behaviors
Reply #17 - Jul 27th, 2018 at 7:39pm
 
Tim,

The Extra flags property is set to -I"{sketch_path}" and I have an include statement in every lib header that references the defines in question.

I do Build->Clean and I also delete the contents of the temp folders and even the .vs and__vm folders.

I will repeat this exercise the next time I run these tests (later today) and again, thanks for your great support.

Bob
Back to top
 
WWW  
IP Logged
 
Visual Micro
Administrator
*****
Offline



Posts: 10565
United Kingdom
Re: How to reference #defines created in a project from library code - SOLVED
Reply #18 - Jul 27th, 2018 at 8:21pm
 
Just do the build clean.

There is no need to run anymore tests. I have described how both visual studio and arduino work.

If you want to access defines created in project code from cpp library code then you should add the -I{sketch_path} compiler extraflag.

In the library code you can #include <header_name.h>

You correctly pointed out that non-compiled files such as .h files that are referenced via project code will use the project defines



Back to top
« Last Edit: Jul 27th, 2018 at 8:23pm by Visual Micro »  
WWW  
IP Logged
 
Page Index Toggle Pages: 1
Send Topic Print