I am getting a feel of it now. There are a lot of such declarations especially extern in the project. I am doing this on AS7 (is that what you meant?) and all the files are in C(with reference to the io stream declaration - does it matter if I go for the uppercase or lowercase declarations - I read that the upper case is used as an initializer for a variable type 'FILE'
Amateur programmer.
Believe when I tell you that my struggle on here is real.
Edited: I am getting a feel of it now. There are a lot of such declarations especially extern in the project. I haven't made much changes to the code yet - I will try doing it and keep it posted. and all the files are in C(with reference to the io stream declaration - does it matter if I go for the uppercase or lowercase declarations - I read that the upper case is used as an initializer for a variable type 'FILE'
How do you delete a comment on here?
Amateur programmer.
Believe when I tell you that my struggle on here is real.
As Cliff says in that thread, the first post in it is more or less a repetition of what is written in the official avrlibc documentation.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
Posted by JohanEkdahl: Tue. Oct 17, 2017 - 08:07 PM
1
2
3
4
5
Total votes: 1
azimmali wrote:
When does one use vfprintf and vfscanf?
Possibly never (explicitly). the vfprintf(...) function is primarily the "worker" behind both printf(...) and sprintf(...). When documentation mentions vsprintf(...) it most likely does so to document that behavior that printf(...) and sprintf(...) shares, rather than documenting it for both of those two functions.
azimmali wrote:
What I am doing wrong here?
We can't tell.
You've shown a snippet of code, of about 100 lines. Yet all error messages in your screen dump are at line number 410, except for the venerable "recipe failed" - which is a stupid error message, better explained by the complete build output.
Speaking of that, haven't we told you before to switch to the output tab and post complete build output rather than those meaningless screen shots? If we've missed that, here it comes: Don't post screen shots. For build errors, post complete build output (switch to output tab, mark everything, copy and paste in a post here.
When posting such errors, also post the complete source file(s) (perhaps as attachments).
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
Posted by JohanEkdahl: Tue. Oct 17, 2017 - 08:51 PM
1
2
3
4
5
Total votes: 1
azimmali wrote:
I am still getting the signal.h warning.
Look at the lines just before it in the build output. Here's one example from your build output:
Building file: .././level3_4026.c
Invoking: AVR/GNU C Compiler : 5.4.0
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -x c -funsigned-char -funsigned-bitfields -DDEBUG -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.132\include" -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=atmega64 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.132\gcc\dev\atmega64" -c -std=gnu99 -MD -MP -MF "level3_4026.d" -MT"level3_4026.d" -MT"level3_4026.o" -o "level3_4026.o" ".././level3_4026.c"
Finished building: .././level3_4026.c
In file included from .././level3_4026.c:64:0:
c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\signal.h(36,2): warning: #warning "This header file is obsolete. Use <avr/interrupt.h>." [-Wcpp]
#warning "This header file is obsolete. Use <avr/interrupt.h>."
^
All those line together tell the true story:
It starts with the build system saying it compiles .././level3_4026.c , and ends with the warning about avr/signal.h . So, there is no question about avr/signal.h being included in .././level3_4026.c . You have several such errors.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
A lot of your questions are really just about basic C programming rather than AVR in particular. You may find it easier to learn C first using a PC development system writing programs for Windows/Linux (faster results and easier to debug) then switch to AVR development when you have a stronger understanding of C. Things like:
error: 'uart_str' undeclared (first use in this function)
are the kind of error you will get from a C compiler whatever you are building for:
#include <stdio.h>
int main(void) {
uart_str = 1;
}
That program will cause the same error whether you build for AVR, x86, ARM, AMD64 or whatever.
Once you understand what "undeclared" means you can bring that knowledge to your AVR programs
I know its a declaration error. I am not aware what value should I assign to it. stdout and stding are storing the address of uart_str. Doesn't that mean the value of uart_str can be anything?
Amateur programmer.
Believe when I tell you that my struggle on here is real.
Posted by JohanEkdahl: Wed. Oct 18, 2017 - 03:15 PM
1
2
3
4
5
Total votes: 0
azimmali wrote:
I did that. I am still getting errors.
This is getting ridiculous!
Are you sure you're not trolling us? )-:
What did you do? We can't tell exactly what you did only from the word "that" and an implication that tou've taken some earlier advice and applied it. SHOW CODE!
Which errors did you get? We can't guess (especially since we don't know what you did). SHOW ERROR MESSAGES! I.e. build output.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
You just can't put lines to assign values to variables outside of function bodies. It would be like:
#include <stdio.h>
somevar = PINB;
int main(void) {
}
You can't have "stray lines" like this. Sure there is the "special case" of assigning an initial value at creation:
#include <stdio.h>
int somevar = 37;
int main(void) {
}
but in this case the assigned value must be known at compile time and it can only be as part of a variable declaration - so should include a type specifier.
As Stefan said a candidate position to do it would be:
void UARTIni(void) {
// UCSRA is not necessary to set up, using initial values
// no double transmission speed, no multi-processor mode
UART_UCSRA = UART_UCSRA_INIT;
UART_UCSRB = UART_UCSRB_INIT;
// set up : RXCIE, UDRIE, RXEN, TXEN
// (interrupt enable from receiver,
// UART receiver enable, UART transmit enable)
UART_UCSRC = UART_UCSRC_INIT;
// asynchronous operation, 8 data bits,
// no parity, 1 stop bit
UART_UBRRL = UART_SPEED; // baud rate - see UBRR register setting table
// in AVR ATmega8 specification
// UBRRH - using initial values
// UBRRL - 25 for 38k4Bd and frequency f=16 MHz
// (using SINGLE transmission speed)
uart_in_read = uart_in_write = uart_in_end = 0;
uart_out_read = uart_out_write = uart_out_end = 0;
uart_state = UART_EMPTY;
// ADD IT HERE...
stdout = stdin = &uart_str;
}
but for that to work "uart_str" must be "known" by the time the compiler gets to this line. But as it stands you have this function at line 271 and the uart_str you want to use being defined at line 409. So that definition of uart_str:
needs to move. A common practice is to put such variable declaration/definitions up near the top of a C file. So maybe slot it in around line 216:
/*#define fdev_setup_stream(stream, p, g, f)
do {
(stream)->put = p;
(stream)->get = g;
(stream)->flags = f;
(stream)->udata = 0;
} while(0)*/
uint8_t uart_state; // current state of incoming message analysis
// ADD IT HERE ...
static FILE uart_str = FDEV_SETUP_STREAM(uart_putchar, uart_getchar, _FDEV_SETUP_RW);
However this then raises another issue. This is referring to uart_putchar() and uart_getchar() but at line 216 the compiler has not encountered those functions yet (they are defined at lines 299 and 316). So initially this would appear to be a problem. You need uart_str "early" in the file so it is before the UARTIni() function where it is now used but it is created by making reference to uart_putchar() and uart_getchar() that are now after it.
This is the whole point of C having declarations and definitions. For a function they look like:
int add(int a, int b); // declaration
int add(int a, int b) { // definition
return a + b;
}
You can tell a declaration because it ends with ';' and you can tell a definition because it ends with "{ some_code }". You can put a declaration very early in a C file (or even in a .h header file that it #include's) to say "expect to see a function with this name, these parameters and this return type coming up later". In my example:
int add(int a, int b); // declaration
could be on line 5 and
int add(int a, int b) { // definition
return a + b;
}
on line 417. In between the two I could have at line 207:
void some_function() {
PORTB = add(37, 52);
}
and the compiler would already understand how to use add() because although it hasn't seen the full function definition yet it has seen the declaration:
int add(int a, int b); // declaration
which told it enough about the function (takes two integers, returns one) so it can be used in some_function().
This is exactly what you need to be able to refer to uart_putchar() and uart_getchar() "early" in the FDEV_SETUP_STREAM before the real functions have been encountered. So somewhere up near the top of the file add:
} while(0)*/
uint8_t uart_state; // current state of incoming message analysis
// ADD DECLARATIONS HERE..
int uart_putchar(char c, FILE *stream);
int uart_getchar(FILE *stream);
// ADD IT HERE ...
static FILE uart_str = FDEV_SETUP_STREAM(uart_putchar, uart_getchar, _FDEV_SETUP_RW);
Now the FDEV_SETUP_STREAM can work because it "knows" about the two functions before they have been defined.
To create declarations I simply went to the point of definition of each function:
int uart_putchar(char c, FILE *stream)
{
int uart_getchar(FILE *stream)
{
uint8_t c;
and simply picked up the first line (everything up to but not including '{') then pasted that in as the declaration with a ';' on the end.
This, the second definition of uart_str, is where the conflict arises. Next, the compiler is nice enough to tell you where the first definition was:
int uart_str = 1;
Isn't the situation quite clear? In fact, crystal-clear?
1. It is totally obvious that you are not good friends with C programming yet. Maybe take a step back and learn the basics first? Preferably using and targeting a PC.
2. I know you won't follow the advice under 1. above so here's another idea: You have stated earlier that you have software engineers in the project. Even if they are not specifically C programmers they will surely be skilled enough to be able to help you sort out things like the above.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
I have a doubt here. INT stores only a fraction of the range of numbers on an 8 bit system. I would like to use either a uint8_t or uint16_t in these lines:
I am getting a feel of it now. There are a lot of such declarations especially extern in the project. I am doing this on AS7 (is that what you meant?) and all the files are in C(with reference to the io stream declaration - does it matter if I go for the uppercase or lowercase declarations - I read that the upper case is used as an initializer for a variable type 'FILE'
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopEdited: I am getting a feel of it now. There are a lot of such declarations especially extern in the project. I haven't made much changes to the code yet - I will try doing it and keep it posted. and all the files are in C(with reference to the io stream declaration - does it matter if I go for the uppercase or lowercase declarations - I read that the upper case is used as an initializer for a variable type 'FILE'
How do you delete a comment on here?
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopAny views on this one?
https://www.avrfreaks.net/forum/o...
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopDo you have specific questions about it?
As Cliff says in that thread, the first post in it is more or less a repetition of what is written in the official avrlibc documentation.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
- Log in or register to post comments
TopIn my previous attempt, I had done this:
Errors:
After adding the code in the link with some changes, instead of the previous one:
I still get errors:
Question: What I am doing wrong here? When does one use vfprintf and vfscanf?
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopPossibly never (explicitly). the vfprintf(...) function is primarily the "worker" behind both printf(...) and sprintf(...). When documentation mentions vsprintf(...) it most likely does so to document that behavior that printf(...) and sprintf(...) shares, rather than documenting it for both of those two functions.
We can't tell.
You've shown a snippet of code, of about 100 lines. Yet all error messages in your screen dump are at line number 410, except for the venerable "recipe failed" - which is a stupid error message, better explained by the complete build output.
Speaking of that, haven't we told you before to switch to the output tab and post complete build output rather than those meaningless screen shots? If we've missed that, here it comes: Don't post screen shots. For build errors, post complete build output (switch to output tab, mark everything, copy and paste in a post here.
When posting such errors, also post the complete source file(s) (perhaps as attachments).
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
- Log in or register to post comments
TopI wanted a green signal to do that. Thanks Johan.
I am still getting the signal.h warning. I am using the interrupt.h
Warning #warning "This header file is obsolete. Use <avr/interrupt.h>." [-Wcpp] EMTestRun c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\signal.h 36
Attachment(s):
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopThis is line 410, right?
You can't do that outside of a function.
Edit: in your latest post it is line 413
Stefan Ernst
- Log in or register to post comments
TopOk. So in what function do I put that in?
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopLook at the lines just before it in the build output. Here's one example from your build output:
All those line together tell the true story:
It starts with the build system saying it compiles .././level3_4026.c , and ends with the warning about avr/signal.h . So, there is no question about avr/signal.h being included in .././level3_4026.c . You have several such errors.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
- Log in or register to post comments
TopStefan Ernst
- Log in or register to post comments
TopSolved that error. Thanks Johan, I hardly take a look at the build output. That was an eye opener.
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopI did that.
uart_str - undeclared error
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopYou also need the
prior to the
David
- Log in or register to post comments
TopA lot of your questions are really just about basic C programming rather than AVR in particular. You may find it easier to learn C first using a PC development system writing programs for Windows/Linux (faster results and easier to debug) then switch to AVR development when you have a stronger understanding of C. Things like:
are the kind of error you will get from a C compiler whatever you are building for:
That program will cause the same error whether you build for AVR, x86, ARM, AMD64 or whatever.
Once you understand what "undeclared" means you can bring that knowledge to your AVR programs
- Log in or register to post comments
TopI know its a declaration error. I am not aware what value should I assign to it. stdout and stding are storing the address of uart_str. Doesn't that mean the value of uart_str can be anything?
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopI did that. I am still getting errors.
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopEdit:
David
- Log in or register to post comments
TopThis is getting ridiculous!
Are you sure you're not trolling us? )-:
What did you do? We can't tell exactly what you did only from the word "that" and an implication that tou've taken some earlier advice and applied it. SHOW CODE!
Which errors did you get? We can't guess (especially since we don't know what you did). SHOW ERROR MESSAGES! I.e. build output.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
- Log in or register to post comments
TopI am attaching the .c and .h files of the UART with this message.
Attachment(s):
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopNo trolling.
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopHere's the code. I haven't attached the solution.
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopI've lost track of what "current code" is in this but I took the .rar in #58 and tried to build it and the fatal errors were:
The first error here is:
The :413: in that says it is line 413. As Stefan noted this is because you have:
return c; } static FILE uart_str = FDEV_SETUP_STREAM(uart_putchar, uart_getchar, _FDEV_SETUP_RW); //static FILE mystdout = FDEV_SETUP_STREAM(uart_putchar, NULL, _FDEV_SETUP_WRITE); //static int uart_putchar(char c, FILE *stream); //stdout = &uart_str; stdout = stdin = &uart_str; //stdin = &uart_str;
You just can't put lines to assign values to variables outside of function bodies. It would be like:
#include <stdio.h> somevar = PINB; int main(void) { }
You can't have "stray lines" like this. Sure there is the "special case" of assigning an initial value at creation:
#include <stdio.h> int somevar = 37; int main(void) { }
but in this case the assigned value must be known at compile time and it can only be as part of a variable declaration - so should include a type specifier.
As Stefan said a candidate position to do it would be:
void UARTIni(void) { // UCSRA is not necessary to set up, using initial values // no double transmission speed, no multi-processor mode UART_UCSRA = UART_UCSRA_INIT; UART_UCSRB = UART_UCSRB_INIT; // set up : RXCIE, UDRIE, RXEN, TXEN // (interrupt enable from receiver, // UART receiver enable, UART transmit enable) UART_UCSRC = UART_UCSRC_INIT; // asynchronous operation, 8 data bits, // no parity, 1 stop bit UART_UBRRL = UART_SPEED; // baud rate - see UBRR register setting table // in AVR ATmega8 specification // UBRRH - using initial values // UBRRL - 25 for 38k4Bd and frequency f=16 MHz // (using SINGLE transmission speed) uart_in_read = uart_in_write = uart_in_end = 0; uart_out_read = uart_out_write = uart_out_end = 0; uart_state = UART_EMPTY; // ADD IT HERE... stdout = stdin = &uart_str; }
but for that to work "uart_str" must be "known" by the time the compiler gets to this line. But as it stands you have this function at line 271 and the uart_str you want to use being defined at line 409. So that definition of uart_str:
needs to move. A common practice is to put such variable declaration/definitions up near the top of a C file. So maybe slot it in around line 216:
/*#define fdev_setup_stream(stream, p, g, f) do { (stream)->put = p; (stream)->get = g; (stream)->flags = f; (stream)->udata = 0; } while(0)*/ uint8_t uart_state; // current state of incoming message analysis // ADD IT HERE ... static FILE uart_str = FDEV_SETUP_STREAM(uart_putchar, uart_getchar, _FDEV_SETUP_RW);
However this then raises another issue. This is referring to uart_putchar() and uart_getchar() but at line 216 the compiler has not encountered those functions yet (they are defined at lines 299 and 316). So initially this would appear to be a problem. You need uart_str "early" in the file so it is before the UARTIni() function where it is now used but it is created by making reference to uart_putchar() and uart_getchar() that are now after it.
This is the whole point of C having declarations and definitions. For a function they look like:
You can tell a declaration because it ends with ';' and you can tell a definition because it ends with "{ some_code }". You can put a declaration very early in a C file (or even in a .h header file that it #include's) to say "expect to see a function with this name, these parameters and this return type coming up later". In my example:
could be on line 5 and
on line 417. In between the two I could have at line 207:
and the compiler would already understand how to use add() because although it hasn't seen the full function definition yet it has seen the declaration:
which told it enough about the function (takes two integers, returns one) so it can be used in some_function().
This is exactly what you need to be able to refer to uart_putchar() and uart_getchar() "early" in the FDEV_SETUP_STREAM before the real functions have been encountered. So somewhere up near the top of the file add:
Now the FDEV_SETUP_STREAM can work because it "knows" about the two functions before they have been defined.
To create declarations I simply went to the point of definition of each function:
and simply picked up the first line (everything up to but not including '{') then pasted that in as the declaration with a ';' on the end.
- Log in or register to post comments
TopWhere do this come from all of a sudden? It was not in your earlier code. Looks like incomplete and wrongly copied stuff from stdio.h.
Remove that!
What was your idea behind adding that line?
Remove that too!
Stefan Ernst
- Log in or register to post comments
TopThank you for that detailed explanation. I am now getting this error:
Build output:
------ Build started: Project: EMTestRun, Configuration: Debug AVR ------
Build started.
Project "EMTestRun.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "E:\EMTestRunDev\EMTestRun\EMTestRun\EMTestRun.cproj" (target "Build" depends on it):
Task "RunCompilerTask"
Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all --jobs 4 --output-sync
Building file: .././level4.c
Invoking: AVR/GNU C Compiler : 5.4.0
E:\EMTestRunDev\EMTestRun\EMTestRun\level4.c(214,6): error: conflicting types for 'uart_str'
FILE uart_str = FDEV_SETUP_STREAM(uart_putchar, uart_getchar, _FDEV_SETUP_RW);
^
E:\EMTestRunDev\EMTestRun\EMTestRun\level4.c(213,5): info: previous definition of 'uart_str' was here
int uart_str = 1;
^
make: *** [level4.o] Error 1
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -x c -funsigned-char -funsigned-bitfields -DDEBUG -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.132\include" -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=atmega64 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.132\gcc\dev\atmega64" -c -std=gnu99 -MD -MP -MF "level4.d" -MT"level4.d" -MT"level4.o" -o "level4.o" ".././level4.c"
E:\EMTestRunDev\EMTestRun\EMTestRun\Debug\Makefile(149,1): error: recipe for target 'level4.o' failed
Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreBuild" in project "EMTestRun.cproj" -- FAILED.
Done building project "EMTestRun.cproj" -- FAILED.
Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
Topint uart_str = 1; } ERROR IS HERE ----> FILE type?? FILE uart_str = FDEV_SETUP_STREAM(uart_putchar, uart_getchar, _FDEV_SETUP_RW);
That is a C program with two different variables called "uart_str". What makes you think you can do something like this in C? You wouldn't write:
would you?
- Log in or register to post comments
TopNo. But I was asked to assign some value to uart_str before using it in the function.
Update: I removed it and the build was successful. Now does that mean I can use printf and scanf statements in the code?
THANKS A LOT!!!!
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopWhat are you talking about?
The FDEV_SETUP macro is used in the creation of a variable (a complex struct) to assign a new value to it. No other assignment is required.
- Log in or register to post comments
TopI probably misinterpreted your post #66.
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopWhy are you defining uart_str twice, first as an int and then as a FILE?!?
int uart_str = 1; } ERROR IS HERE ----> FILE type?? FILE uart_str = FDEV_SETUP_STREAM(uart_putchar, uart_getchar, _FDEV_SETUP_RW);
Don't do that.
The error message is quite clear, and you should be able to understand it yourself:
First "conflicting types for 'uart_str'" should be quite clear, and unambiguous, right? It is set at the line
This, the second definition of uart_str, is where the conflict arises. Next, the compiler is nice enough to tell you where the first definition was:
Isn't the situation quite clear? In fact, crystal-clear?
1. It is totally obvious that you are not good friends with C programming yet. Maybe take a step back and learn the basics first? Preferably using and targeting a PC.
2. I know you won't follow the advice under 1. above so here's another idea: You have stated earlier that you have software engineers in the project. Even if they are not specifically C programmers they will surely be skilled enough to be able to help you sort out things like the above.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
- Log in or register to post comments
TopI will do both as advised. Thanks Johan.
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopI have a doubt here. INT stores only a fraction of the range of numbers on an 8 bit system. I would like to use either a uint8_t or uint16_t in these lines:
But I am getting a warning at this line:
Build Output:
Warning:
initialization from incompatible pointer type [-Wincompatible-pointer-types]
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
Topint (on AVRs) is 16-bit (signed)
David
- Log in or register to post comments
TopThis link: https://arduino.stackexchange.co...
OK.
Amateur programmer.
Believe when I tell you that my struggle on here is real.
- Log in or register to post comments
TopHave you looked at the definitions of putchar/getchar in stdio.h as an example?
The return value on error is EOF (-1), so using an unsigned type cannot return the correct value...
David
- Log in or register to post comments
TopPages