Atmel Studio compiler errors - Page 1
Forum section: electronics / general

author: Simon
author_rank: Unknown
timestamp: August 29, 2014, 09:03:08 am
content: What does this warning mean ?Warning 2 control reaches end of non-void function [-Wreturn-type]It relates to this code:Code:TIMER0_COMPA_vect(){count++;}The count variable has been declared as a volatile variable.I am also getting other complaints around the watchdog timer reset code but I can't work out why as I'm just using thewdt_reset ( );that is specified in the manual but errors have been asking me for "(" in front of parts of code in the library file that is none of my business. This was after commenting some of the code out and then trying to put it back. Basically the compiler is unstable at best.

author: andersm
author_rank: Super Contributor
timestamp: August 29, 2014, 09:46:25 am
content: The warning means that there is a function that is declared to return a value (eg. int foo(...)), but there is an execution path that reaches the end of the function without returning a value. I doubt it is related to the code you showed.I don't mean this as an insult, but you have a history of making lots of beginner's errors. Before blaming the compiler, make sure you have all your i's dotted and t's crossed.

author: Simon
author_rank: Unknown
timestamp: August 29, 2014, 10:03:32 am
content: According to responses i got on avr freaks i should have used ISR(TIMER0_COMPA_vect) So that one is sorted.The code previously worked, I commented some of it out and then removed the comments and now I get errors relating to code in the watchdog header file which is out of my control, I think that's unusual is it not ? I also experience instances where first the code refuses to compile and on a second attempt it does, I think that constitutes unstable.

author: Simon
author_rank: Unknown
timestamp: August 29, 2014, 10:39:57 am
content: Using my original code works again, but still it took two attempts to compile and things that compiled correctly on one computer don't compile on another despite having the same versions. it also seems to make a difference as to where my cursor is when i hit build which i don't understand.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 29, 2014, 01:58:35 pm
content: To guarantee consistent builds, you should probably wipe output data every once in a while. C compilers are not inconsistent (they're deterministic programs), but they are stateful, in that if you have compiled modules that weren't changed (or so it seems), it will include them without recompiling. Which can lead to inconsistent results, perhaps if some header files changed or something.Tim

author: Simon
author_rank: Unknown
timestamp: August 29, 2014, 02:23:55 pm
content: ah that is interesting, and how do i clear "output data" ?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 29, 2014, 02:45:51 pm
content: Project / Clean Project, or something like that. I forget where Atmel/AVR Studio has that at. Or you go into the output directory and delete it yourself.

author: Simon
author_rank: Unknown
timestamp: August 29, 2014, 05:16:57 pm
content: hm, pretty roundabout when your making minor code changes and want to keep verifying them.

author: sporadic
author_rank: Regular Contributor
timestamp: August 29, 2014, 05:55:54 pm
content: In regards to error references within a system header file, that's usually caused by a macro expansion gone bad or malformed code block in the users code. The cleaning referred to above will cleanup all the intermediate compiled objects and what not required to create your final binary. Very much like a "make clean". An object won't re-compile unless it needs to (source changed or compiled object removed), so if you see a warning the first time around in say "mystuff.c", make a change in "main.c", and recompile, you won't see the warning from mystuff.c again until you do a "make clean", or in Atmel Studio's case, "Build->Clean Solution". Have a link for the thread you have going on avrfreaks?

author: Simon
author_rank: Unknown
timestamp: August 29, 2014, 06:31:11 pm
content: So basically i need to do a clean build each time to make sure ?

author: sporadic
author_rank: Regular Contributor
timestamp: August 29, 2014, 07:24:29 pm
content: Quote from: Simon on August 29, 2014, 06:31:11 pmIf you're wanting to re-compile all files each time and see the warnings for them again, yes. Atmel Studio's default build configuration turns on many of GCC's warning flags so it can be pretty verbose at times. Many warnings are just that and won't cause runtime issues, but its best to deal with them if you can. So generally, you don't need to do a clean build unless you want to go back and check your warnings for all modules or you've been prodding around doing something that messed up the make system / causing the linker to fail. I rarely have to do a clean, but its good for a sanity check every now and then.

author: Simon
author_rank: Unknown
timestamp: August 30, 2014, 07:52:31 am
content: Yea apparently now I have variables that are not being modified when they clearly are..........

author: andersm
author_rank: Super Contributor
timestamp: August 30, 2014, 09:00:20 am
content: Quote from: Simon on August 30, 2014, 07:52:31 amPlease post an example.

author: David_AVD
author_rank: Super Contributor
timestamp: August 30, 2014, 09:01:40 am
content: Without seeing the whole project it's hard to tell, but maybe the variables are not correctly defined? I've had no issues with variables marked as volatile.Maybe check for other silly mistakes such as calling a function without the parenthesis. Things like this can really screw things up without generating errors.So far, each time I've seen something weird going on it's been a typo or me not completely understanding C.

author: Simon
author_rank: Unknown
timestamp: August 30, 2014, 09:56:48 am
content: Well I'll continue probing monday and be able to post some code

author: mikerj
author_rank: Super Contributor
timestamp: August 31, 2014, 05:49:58 pm
content: Just bear in mind that weird compilation errors are 99.999% caused by user code. Missing brackets etc. can cause errors to be shown in apparently unrelated code, but with experience you get a feeling for where the real problem is likely to be.

author: Simon
author_rank: Unknown
timestamp: August 31, 2014, 05:53:59 pm
content: It's just weird that first it fails and then it succeeds with no code change, I need to look at the second computer i am using as most problems occur moving to that.As pointed out previously a clean built is the best option to clear any old bits of code the compiler is hanging onto that I may have changed anyway.I havewatchgod reset codewhile(1)watchdog reset codeand I'm getting error in the watchdog header file........Reverting to a previous copy of the program fixes it all.

author: c4757p
author_rank: Super Contributor
timestamp: August 31, 2014, 06:02:22 pm
content: Quote from: Simon on August 31, 2014, 05:53:59 pmIt'd be seriously helpful if your pseudocode was, well, pseudo-code. With structures and all that. Is the third line inside the while(1), or have you tried to make the processor halt at the while(1)? That could make a difference.QuoteRemember that the compiler lumps all the headers together at the beginning of your file. Errors in a header that ought to be okay are often actually latent errors from things before the header's #include line. What did you dobefore#include <avr/wdt.h> ?QuoteUsually a sign that you changed something and broke it, not a sign that the compiler's "unstable".Would you be so kind as to share a minimal diff?

author: Simon
author_rank: Unknown
timestamp: August 31, 2014, 06:05:35 pm
content: Sorry to be cleare it was and i forgot a parenthesis:Code:main(){watchgod reset codewhile(1){watchdog reset coderest of code in loop}}[code/]The 3 errors I got pointed to before and after the while in my code but stated that there needed to be "(" in some code, the code it referred to is in the watchdog header file.

author: miguelvp
author_rank: Super Contributor
timestamp: August 31, 2014, 06:16:22 pm
content: It actually will be helpful to put the actual code snippets if you are getting compiler errors.

author: Simon
author_rank: Unknown
timestamp: August 31, 2014, 06:20:07 pm
content: I'll post some tomorrow

author: Simon
author_rank: Unknown
timestamp: August 31, 2014, 06:22:18 pm
content: I'll do that tomorrow although I've gone back to my original and in any case identical copy and got no errors, hence my comments about instability, these may be down to not doing a clean build.

author: true
author_rank: Frequent Contributor
timestamp: August 31, 2014, 07:16:59 pm
content: No, it very likely isn't.I'll wait for code.

author: Simon
author_rank: Unknown
timestamp: August 31, 2014, 07:18:20 pm
content: Well then as far as i can tell i have 2 pieces of code that say the same thing but only one works.

author: David_AVD
author_rank: Super Contributor
timestamp: August 31, 2014, 09:55:05 pm
content: My money is on them not being the same. About the only other thing I can think of is the file has gotten mangled with bad CR/LF ?

author: miguelvp
author_rank: Super Contributor
timestamp: August 31, 2014, 10:01:58 pm
content: And some c++ compilers don't like not to have an empty line at the end of the file.Edit: Which make perfect sense to be required.

author: westfw
author_rank: Super Contributor
timestamp: August 31, 2014, 10:38:39 pm
content: QuoteProbably not.Look. avr-gcc and Atmel Studio have bugs; they're huge programs.But the chances that they have catastrophic bugs that cause a program to not compile one time, and compile the next, or similar are VERY slim. It's MUCH more likely that it's YOU.QuoteNo, unfortunately. If you leave some stray characters behind during the removal, it's quite possible that those will cause error messages "in" the system include files. For a good time, try running the following through any desktop compiler:Code:char *bar(int, int) // Function prototype#include <stdio.h> // get standard IO code.C seems to be really, horribly, awful when it come to figuring out the source of parsing errors. That's probably a result of it having its syntax designed back in the dark ages before language designers understood the importance of ... pickyness. And in between "clever" programmers and purist compiler designers, it somehow seems necessary to output 100+ lines of errors about stable system include files, rather than saying "Did you really mean to use a #include in the middle of a C statement?"(This is one of the reasons that there used to be "teaching compilers" like WATFor and PL/C. They would do a much better job of indicating, and continuing, in the face of common sytax errors than their "professional" equivalents. I don't know if there's a "teaching" C compiler. I guess some of that lack is being taken up by the IDE. Keil puts a big read X next to that prototype, but Atmel Studio isn't as helpful...)

author: andersm
author_rank: Super Contributor
timestamp: September 01, 2014, 05:06:44 am
content: Quote from: westfw on August 31, 2014, 10:38:39 pmCode:$ clang -c a.ca.c:1:20: error: expected ';' after top level declaratorchar *bar(int, int)^;1 error generated.$GCC has improved its diagnostics a lot in recent versions (largely a response to Clang), but they've got some ways to go yet.

author: Simon
author_rank: Unknown
timestamp: September 01, 2014, 07:03:11 am
content: Code is:Code:#define F_CPU 8000000UL#include <avr/io.h>#include "simon_atmega328_avr_c.h"#include "tacho.h"#include <avr/wdt.h>#include <avr/interrupt.h>#define speed0 950 //PCM value for a stopped motor#define speed1 50 //timing value for speed1#define speed2 33 //timing value for speed2#define PCM_VALUE OCR1A // OCR1A holds the PWM duty value for the PCM output#define PCM PB1#define S1_o PB2#define S2_o PD4#define Fault_o PB5#define S1_i PB6#define S2_i PB7#define Fault_i PB4#define scavenge PD1#define bounce 100 //time in ms to wait for switch de-bounceint main(void){uint16_t pwm1 = 1500; //starting PCM value for speed1uint16_t pwm2 = 1800; //starting PCM value for speed2sei(); //globally enable interruptsbit_s(DDRB, PB0); //set output for startup test signalbit_s (PORTB, PB0); //turn on test pin_delay_ms(1000); //wait 1000ms to get a pulse that is easy to detectbit_c(PORTB, PB0); //turn test pin offwdt_enable(WDTO_2S);//enable watchdog timer with a 2S timeoutbit_s(DDRB, PCM); //PCM outputbit_s(DDRB, S1_o); //speed1 outputbit_s(DDRD, S2_o); //speed2 outputbit_s(DDRB, Fault_o); //fault outputbit_s(DDRD, scavenge); //scavenge outputbit_s(PORTB, S1_i); //enable pull-up for S1_ibit_s(PORTB, S2_i); //enable pull-up for S2_ibit_s(PORTB, Fault_i); //enable pull-up for fault inbit_s(EICRA, ISC01); //set interrupt0 to fire on a falling edgebit_c(EICRA, ISC00);counter0_CTC(50);bit_s(EIMSK, INT0); //enable external interrupt 0pwm16_fast_setup();PCM_VALUE = speed0;wdt_reset();while(1){wdt_reset();time_calc();//if both speed inputs are high set PWM at 1000 (1.5mS pulse) reversed logic with mcu pull-up'sif ( (bit_get (PINB, S2_i)) && (bit_get (PINB, S1_i)) ){delay_ms(bounce); //wait for switch bounceif ( (bit_get (PINB, S2_i)) && (bit_get (PINB, S1_i)) ) //recheck state{PCM_VALUE = speed0 ;bit_c (PORTB, S1_o) ;bit_c (PORTD, S2_o) ;bit_c (PORTD, scavenge); // Turn off scavenge fan}}//Set speed 1//if speed 1 low AND speed 2 high set speed1 pulse reversed logic with mcu pull-up'sif ( (bit_get (PINB, S2_i)) && (!bit_get (PINB, S1_i)) ){_delay_ms(bounce); //wait for switch bounceif ( (bit_get (PINB, S2_i)) && (!bit_get (PINB, S1_i)) ) //recheck state{bit_s (PORTB, S1_o) ;bit_c (PORTD, S2_o) ;if (time > speed1)pwm1++;if (time < speed1)pwm1--;PCM_VALUE = pwm1;bit_s (PORTD, scavenge); //Turn on Scavenge fan}}//Set speed 2//if speed 2 low AND speed 1 high set speed2 pulse reversed logic with mcu input pull-up'sif ( (!bit_get (PINB, S2_i)) && (bit_get (PINB, S1_i)) ){_delay_ms(bounce); //wait for switch bounceif ( (!bit_get (PINB, S2_i)) && (bit_get (PINB, S1_i)) ) //recheck state{bit_c (PORTB, S1_o) ;bit_s (PORTD, S2_o) ;if (time > speed2)pwm2++;if (time < speed2)pwm2--;PCM_VALUE = pwm2;bit_s (PORTD, scavenge); //Turn on Scavenge fan}}//fault signal//if the fault input is 1 then turn on fault output else turn it offif (bit_get (PINB, Fault_i))bit_s(PORTB, Fault_o);elsebit_c(PORTB, Fault_o);}}

author: Simon
author_rank: Unknown
timestamp: September 01, 2014, 07:08:04 am
content: I'm really curious to know why pwm1 and pwm2 are giving me warnings about the variables not changing, last time i checked pwm1++ or pwm1-- is a change.

author: David_AVD
author_rank: Super Contributor
timestamp: September 01, 2014, 08:20:52 am
content: Where is "time" defined ?

author: Simon
author_rank: Unknown
timestamp: September 01, 2014, 08:48:54 am
content: tacho.hCode:volatile uint16_t tacho1, tacho2, time, count; //reading pulled off counter1ISR(INT0_vect){tacho1 = tacho2;tacho2 = count;}ISR(TIMER0_COMPA_vect){count++;}void counter0_CTC (uint8_t TOP){//setup counter for CTC modebit_c(TCCR0B, WGM02);bit_s(TCCR0A, WGM01);bit_c(TCCR0A, WGM00);//set div8 prescaler (counts in uS on a 8MHz clock)bit_c(TCCR0B, CS02);bit_s(TCCR0B, CS01);bit_c(TCCR0B, CS00);OCR0A = TOP; //set the compare match value to the one specified in the function argument.bit_s(TIMSK0, OCIE0A); //enable channel A compare/match interrupt flag.}void time_calc (void){bit_c(EIMSK, INT0); //disable external interrupt 0 to stop false readingsif (tacho1 > tacho2)tacho2 = tacho2 + 0xFFFF;time = tacho2 - tacho1;bit_s(EIMSK, INT0); //re-enable external interrupt 0}

author: westfw
author_rank: Super Contributor
timestamp: September 01, 2014, 09:25:00 am
content: Can you copy and paste the actual output from the compiler? I'm seeing:Code:avr-gcc -Os -mmcu=atmega328p avrbar.c -WallIn file included from avrbar.c:5:0:tacho.h:5:1: warning: return type defaults to 'int' [-Wreturn-type]ISR(INT0_vect)^tacho.h:11:1: warning: return type defaults to 'int' [-Wreturn-type]ISR(TIMER0_COMPA_vect)^tacho.h:11:1: error: redefinition of 'ISR'tacho.h:5:1: note: previous definition of 'ISR' was hereISR(INT0_vect)^tacho.h: In function 'ISR':tacho.h:14:1: warning: control reaches end of non-void function [-Wreturn-type]}^caused by not including interrupt.h before you try to use ISR.But apparently you're seeing additional/different errors and warnings?

author: firewalker
author_rank: Super Contributor
timestamp: September 01, 2014, 09:31:38 am
content: Enter#include <avr/interrupt.h>to tacho.hEdit: Should refresh before posting.Alexander.

author: Simon
author_rank: Unknown
timestamp: September 01, 2014, 09:32:53 am
content: @westfwI've run so many versions that I've lost track, according to avr freaks I should have included the interrupts header file in my tacho header file. At the moment it builds ok.I may also be having problems because I've not been doing clean builds and as I've had copies of the project it might be that different versions of a file have been accidentally used.

author: mamalala
author_rank: Unknown
timestamp: September 01, 2014, 12:09:21 pm
content: Quote from: Simon on September 01, 2014, 08:48:54 amIf that really is a .h file, then you are doing it wrong. Regular code should not be in there, and neither should variable declarations.Greetings,ChrisEdit: Oh, and stuff like "tacho2 = tacho2 + 0xFFFF;" can also be written as "tacho2--;", because that is what it will effectively do in this case.

author: Simon
author_rank: Unknown
timestamp: September 03, 2014, 07:00:40 am
content: It would seem that I made a mess of splitting my code into different files, I don't know where I got the idea from but yes apparently header files is not the place.I've now split my files into C files and added them to the project and it all works.

author: David_AVD
author_rank: Super Contributor
timestamp: September 03, 2014, 09:01:14 am
content: Using various h and c files is not a bad thing if done correctly. You can reuse those modules on other projects.It took me a while to get the hang of variable declarations, definitions, the use of the extern keyword, etc.Get that wrong and it all becomes a steaming pile with endless warnings, errors and unexpected results.

author: Simon
author_rank: Unknown
timestamp: September 03, 2014, 09:14:21 am
content: Yes I think I have the hang of it now....