I'm new to using a C file in conjunction with an Arduino sketch. The sketch including the C code is full running but now I'm trying to change the C code and I need to debug it.
I'm new to C. How do I set up and use printf from the C code so that it will output to the Arduino serial monitor? Is there a preferred method other than printf?
Thanks. That's what I first tried but the compiler is complaining that it doesn't understand the serial function in the C code. Is there a library I need to #INCLUDE in the C code?
You shouldn't need to #include anything for Serial.print. I use it all the time for debugging, and have never needed to include a thing. Are you putting Serial.begin(9600) in your setup function? I don't think it will work without that. Also make sure you're using one of the more recent versions of the Arduino IDE. I'm using Arduino 0017, but Arduino 0018 is out already. If you're still having problems, post your code and I'll see if I can help.
I have Serial.begin(115200); in the arduino code in the setup section. For grins, I tried also adding this to the C file (where the Serial.prints are being called out and received the following message from the compiler while highlighting Serial.begin(115200);
error: expected '=', ',', ';', 'asm' or 'attribute' before '.' token
I really don't know what this message means.
This is different than the prior message about 'Serial' undeclared (first use in this function)
You will usually get an error like that if you're missing something like a ';' or ')' in your code. I can't count the number of times I forgot to put a ';' at the end of a line. In any case it sounds like a syntax error. Hard to say exactly what's causing it without seeing the code, but I would very carefully check over each line and make sure all your syntax is straight.
EDIT: I was re-reading your post and I don't quite get what you mean by "...adding this to the C file...". Do you mean the .cpp file? You shouldn't be adding that anywhere else but the main sketch unless you're writing a library.
2nd EDIT: I think I get what's happening. You're referring to having multiple tabs open at the top of your sketch and one of them is named something like 'myfile.c' right? Honestly, I've never used them in that manner, but the reference for the build process Redirecting indicates that .c files are compiled separately. That's probably where most of your headache is coming from. The first thing I'd try is to just simply remove the .c extension and see if that works.
Yes, this is a second tab with a .c file where I'm having the challenge. No problem at all getting serial monitor output from the usual Arduino code file...it's just the .c file where I'm guessing there's a slightly different approach that I need to understand.
If you rename your ".c" file to ".cpp" you will have the choice of using the "C" language subset or C++ in your source.
There's no support for "stdout" as used by printf on the Arduino so that's a dead end unless you write/add support for this yourself. If you set out to do so you may want to use Serial.print anyhow and then you're pretty much back to where you started.
There's nothing wrong with insisting on using pure "C", but doing so within the framework of the "C++" compiler (using .cpp extension) will allow you to use the full range of Arduino core and contributed libraries.
So you are saying that if I rename to CPP, I can use any of Arduino's functions in that file? To use Serial,print, will I just need to #include WProgram.h or others as well?
If using CPP allows one to inherit all the Arduino functions, then here's another dumb question: Wouldn't CPP then be the preferred choice for any add-on code...excepting for the case that one needs some C function not allowed in C++? Are there other downsides?
Context: I am using Asynclabs WiShield. The webserver code which they provide is .c and now I'm wondering why not cpp.
You may run into some issues when porting C to C++, but it would typically be minor and quite often no issues at all. C is somewhat more liberal/relaxed when it comes to type conversions compared to C++. The errors (or warnings) issued by C++ compilers however will more than likely help towards improving your code.
AVR Studio is a popular development platform for ATMega microcontrollers, but it does not support C++ well. Some manufacturers will use this platform for driver development rather than Arduino and I think this may be one reason why C is still preferred by some.
Hey, I found this page looking for a solution to exactly the problem charlieo is having. I'm trying to debug the WiShield code.
I've changed the file 'g2100.c' to 'g2100.cpp', but now I have the following issue. If I don't include anything in the file it complains: "error: 'Serial' was not declared in this scope".
That is kind of expected, so I included this: "#include <WProgram.h>". But then I get a lot of errors: "WiServer.cpp.o: In function Server::server_task()' undefined reference to zg_drv_process'". etc, etc...
It looks like it didn't even compile the new g2100.cpp anymore, because it can't find any of the functions inside it. That's a bit weird, because it DOES try to compile it when I don't include the WProgram.h file.
There's a weirdness in the way that the Arduino decides what needs to be compiled. A .cpp file is compiled only if all include files that the .cpp file references are also included in the sketch that includes the .h file that goes with the .cpp file.
So, you will need to include WProgram.h in the sketch, too.
OK, so I tried including the WProgram.h in the PDE file. No difference.
If I understand correctly I should include all the .h files my newly renamed .cpp references. Those are: #include <string.h> #include "witypes.h" #include "config.h" #include "g2100.h" #include "spi.h" #include "global-conf.h"
When I try to do that (I'm not convinced this is the right thing to do), I get error: expected class-name before '{' token
in a file that has nothing to do with any of this, so I figure the interpreter is not liking the C code wrapped in a CPP file and incorrectly interprets the whole thing...
When I try to do that (I'm not convinced this is the right thing to do), I get error: expected class-name before '{' token
in a file that has nothing to do with any of this, so I figure the interpreter is not liking the C code wrapped in a CPP file and incorrectly interprets the whole thing...
Post the code down to the line that it complains about, please, from the file that triggers the error.
C code can be placed in a cpp file, if done correctly.
Hmmm, it's rather complicated as there are a lot of files involved.
The line it's failing at is: class MAX3421E : public SPI {
So the problem is with the class SPI, which is apparently is not recognizing as a class anymore. I must say that what I'm trying to do, is combining two examples into one. Both of which are using SPI but the WiShield libraries aren't using the Arduino SPI library.
The funny thing is that when I don't do this extra 'including' (and don't rename the .c to .cpp) everything compiles just fine.
So I'm probably best off to try and modify the WiShield code to use the Spi library, because I'll have to work on that anyways, because there are likely conflicts between the settings of the two SPI devices I'm trying to use. (The other SPI device is the USB Host Controller by Circuits@Home).
(damn, I typed a long story but lost it due to Firefox opening something else in the same tab).
Basically, yes, I included the Spi.h file. I now noticed that I have two Spi.h files (because of the two examples using different Spi libraries). So I renamed one and updated all references. That cleared up the weird error, but now I'm back to where we were before I included any .h files in the sketch.
Aha, while writing this I realized something. There were a bunch of other .c files referencing this g2100.h file. Since I now converted the g2100.c to g2100.cpp they would no longer 'understand' the CPP code. So I converted all the .c files to .cpp files that were referencing g2100.h.
That cleared it up and I'm now happily calling Serial.println() from g2100.cpp...
Now on to the work of finding what actually goes wrong. Thanks all.