Im sure Im missing something simple, and obvious, but I am tired of searching for the answer. Im using a PIC16F688 and XC8 compiler.
The compiler user manual says that there is a delay function __delay_ms(). It says that _XTAL_FREQ must be defined.
Here is my code, but it does not accept the command. What is wrong?
#include <stdio.h>
#include <stdlib.h>
#define _XTAL_FREQ 20000000
#include<xc.h>
int main(int argc, char** argv) {
_delay_ms(4);
return (EXIT_SUCCESS);
They are right, the problem was experienced by older versions of the IDE's. I have found it helpful to use:
while(1){
//Invert LED state
LED = !LED;
//Delay ~1 second (4MHz Internal Clock)
_delay(1000000); //specify clock cycles directly
}
To solve the problem.
Please include "htc.h"
#include <stdio.h>
#include <stdlib.h>
#include <xc.h>
#include <htc.h>
#define _XTAL_FREQ 20000000
int main(int argc, char** argv) {
_delay_ms(4);
return (EXIT_SUCCESS);
}
What does it mean "it does not accept the command"? Compiler cannot find function _delay_ms()? Maybe you should use proper name with two underscores __delay_ms()?
Moreover, why you do not close main function with }? It is only a typo in your post or in your real code?
May be you have to include or enable pic Controller library file in your compiler.
In some compiler meed to give controller info like controller series and clock frequency using ect.,
It seems problem with compiler setting.
I discovered that the IDE wasnt correctly reading the include file xc.h, so it was red lining a line that was actually correct. It wasnt compiling due to another issue earlier in the program.
Thank you for the responses.
It seems like you used only ONE UNDERSCORE for the function. Use 2 underscore, __delay_ms(1000);
#include <stdio.h>
#include <stdlib.h>
#include <xc.h>
#define _XTAL_FREQ 20000000
int main(int argc, char** argv) {
__delay_ms(4);
return (EXIT_SUCCESS);
}
I hope that the following link will help you to learn MPLAB XC8.
PIC Microcontroller Tutorials using MPLAB XC8
maybe try this directly
//Delay Definitions
#define __delay_us(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000000.0)))
#define __delay_ms(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000.0)))
Related
I am working on STM32F1 on IAR, I write a weak function using
__attribute__((weak))
main.c
#include "tmp.h"
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
int testfunc1(int a)
{
return true;
}
int main(void)
{
while (1)
{
}
}
tmp.h
#include <stdio.h>
#include <stdlib.h>
int testfunc1(int a);
tmp.c
#include "tmp.h"
__attribute__((weak)) int testfunc1(int a)
{
}
It compiles with errors:
Error[Pe079]: expected a type specifier
Warning[Pe606]: this pragma must immediately precede a declaration
Error[Pe260]: explicit type is missing ("int" assumed)
Error[Pe141]: unnamed prototyped parameters not allowed when body is present
Error[Pe130]: expected a "{"
Error while running C/C++ Compiler
However, if I use __weak instead of attribute((weak)), it works normally as expected.
tmp.c
#include "tmp.h"
__weak int testfunc1(int a)
{
}
.
Warning[Pe940]: missing return statement at end of non-void function "testfunc1"
Done. 0 error(s), 1 warning(s)
So, why is attribute((weak)) not working?
IAR compiler has its own extensions to archive it:
#pragma
__weak
I strongly suggest to put some effort and read the compiler documentation before posting questions here.
why __attribute__((weak)) in IAR can't compile?
why is attribute((weak)) not working?
Because it's not supported by the version of IAR compiler you are using.
I believe most "why" questions are bad question. An answer to "why" something happens is either too broad (requires to explain everything) or too vague (because this is how it is). In this case your compiler just doesn't support that specific syntax. To further investigate "why" exactly the IAR Systems company decided not to implement support for that particular syntax for that IAR compiler version, ask that company.
The following program can be compiled using msvc or mingw. However, the mingw version cannot display unicode correctly. Why? How can I fix that?
Code:
#include <stdio.h>
#include <windows.h>
#include <io.h>
#include <fcntl.h>
int wmain(void)
{
_setmode(_fileno(stdout), _O_U16TEXT);
_putws(L"哈哈哈");
system("pause");
return 0;
}
Mingw64 Compile Command:
i686-w64-mingw32-gcc -mconsole -municode play.c
MSVC Compiled:
Mingw Compiled:
Edit:
After some testing, the problem seems not causing by mingw. If I run the program directly by double clicking the app. The unicode string cannot be displayed correct either. The code page however, is the same, 437.
It turns out the problem is related to console font instead of the compiler. See the following demo code for changing console font.
This is happening because of missing #define UNICODE & #define _UNICODE . You should try adding it along with other headers. The _UNICODE symbol is used with headers such as tchar.h to direct standard C functions such as printf() and fopen() to the Unicode versions.
Please Note - The -municode option is still required when linking if Unicode mode is used.
After doing some research, it turns out the default console font does not support chainese glyphs. One can change the console font by using SetCurrentConsoleFontEx function.
Demo Code:
#ifdef _MSC_VER
#define _CRT_SECURE_NO_WARNINGS
#endif
#include <stdio.h>
#include <io.h>
#include <fcntl.h>
#include <windows.h>
#define FF_SIMHEI 54
int main(int argc, char const *argv[])
{
CONSOLE_FONT_INFOEX cfi = {0};
cfi.cbSize = sizeof(CONSOLE_FONT_INFOEX);
cfi.nFont = 0;
cfi.dwFontSize.X = 8;
cfi.dwFontSize.Y = 16;
cfi.FontFamily = FF_SIMHEI;
cfi.FontWeight = FW_NORMAL;
wcscpy(cfi.FaceName, L"SimHei");
SetCurrentConsoleFontEx(GetStdHandle(STD_OUTPUT_HANDLE), FALSE, &cfi);
/* UTF-8 String */
SetConsoleOutputCP(CP_UTF8); /* Thanks for Eryk Sun's notice: Remove this line if you are using windows 7 or 8 */
puts(u8"UTF-8你好");
/* UTF-16 String */
_setmode(_fileno(stdout), _O_U16TEXT);
_putws(L"UTF-16你好");
system("pause");
return 0;
}
Apologies for the dumb question. I checked all similar questions for the same error on stackoverflow, but it didn't help me understand why this error is happening in the following code.
I have one additional header file and a source file, which is included in the main file, and when I compile, I am getting the following error. I am trying to pass the char** argv from the main() to another function defined in another header file.
#include "include/Process.h"
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char** argv) {
if (argc < 2) {
printf("Please provide a path to file\n");
return (EXIT_FAILURE);
}
Process(argv);
Process.h:
#pragma once
extern void Process(char** path);
Process.c:
#include <stdio.h>
#include "../include/Process.h"
#include <stdlib.h>
#include <sys/stat.h>
#include <syslog.h>
#include <sys/types.h>
#include <unistd.h>
void Process(char** path) {
printf("%s\n", path[1]);
}
It gets compiled but the warning is
./src/Process.c:22:6: error: conflicting types for ‘Process’
void Process(char** path) {
^
./include/Process.h:17:6: note: previous declaration of ‘Process’ was here
extern void Process(char** path);
^
However, the warning disappears when I change the type of path from char** to char* and pass argv[1] instead of argv.
I am clueless why this is happening like this, and according to
this similar post, I tried adding a forward declaration for char** path above extern void Process(char** path); in the Process.h file, but it didn't help either.
Why is this error thrown when using char** path?
Why it disappears when I use char* path?
So far, I am able to see the program running, even with this warning. Is it safe to ignore this warning? If not, what could be the possible effects it can have during runtime?
Using gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13)
Thanks.
Try putting your custom includes after the system includes.
It might be possible that the custom include defines a macro which interferes with the system includes. To minimize the risk of this, I always put the Standard C includes first, then any OS includes, and then third party libraries, and then my own ones
In theory the custom include shouldn't do this, and the system includes should only use reserved names, but in practice this doesn't always happen.
I am using the Big Nerd Ranch book Objective-C Programming, and it starts out by having us write in C in the first few chapters. In one of my programs it has me create, I use the sleep function. In the book it told me to put #include <stdlib.h> under the #include <stdio.h> part. This is supposed to get rid of the warning that says "Implicit declaration of function 'sleep' is invalid in C99". But for some reason after I put #include <stdlib.h>, the warning does not go away.. This problem does not stop the program from running fine, but I was just curious on which #include I needed to use!
The sleep man page says it is declared in <unistd.h>.
Synopsis:
#include <unistd.h>
unsigned int sleep(unsigned int seconds);
sleep is a non-standard function.
On UNIX, you shall include <unistd.h>.
On MS-Windows, Sleep is rather from <windows.h>.
In every case, check the documentation.
this is what I use for a cross-platform code:
#ifdef _WIN32
#include <Windows.h>
#else
#include <unistd.h>
#endif
int main()
{
pollingDelay = 100
//do stuff
//sleep:
#ifdef _WIN32
Sleep(pollingDelay);
#else
usleep(pollingDelay*1000); /* sleep for 100 milliSeconds */
#endif
//do stuff again
return 0;
}
What is the proper #include for the function 'sleep()'?
sleep() isn't Standard C, but POSIX so it should be:
#include <unistd.h>
sleep(3) is in unistd.h, not stdlib.h. Type man 3 sleep on your command line to confirm for your machine, but I presume you're on a Mac since you're learning Objective-C, and on a Mac, you need unistd.h.
Given that sleep is a non-standard function, I created a sleep function with the standard library time.h
#include <time.h>
void sleep(double s) {
time_t cur_time = time(NULL);
while ((difftime(time(NULL), cur_time)) < s);
}
I have a code in which am trying to use outportb(), but while compiling it on MinGw i am getting below error.
C:\Users\A_TOMAR\AppData\Local\Temp\ccYPvctv.o:dsp.c:(.text+0x68): undefined reference to `outportb'
#include <stdio.h>
#include <stdlib.h>
#include <dos.h>
int main(void)
{
outportb(0x378,0xFF);
return 0;
}
I would like to know which header file is having this particular function?
Windows doesn't provide access to a hardware. You should use Win32 API calls.
This function is DOS specific and unavailable in Windows
Googling shows that your solution is inpout32.dll (example with weird font color)
#include <pc.h>
void outportb(unsigned short _port, unsigned char _data);