LUFA hangs AT90USB1287?

Go To Last Post
84 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've recently started noticing that when a USB device is attached to my pretty loaded with work AT90USB1287, it would suddenly hang the microcontroller so that nothing would get it back to life except for the power off and on again (RESENT won't help).

Has anyone out here ever had this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or may it be that this has to do with the compiler optimization? I've noticed that avr-gcc is pretty crappy unless you're developing something as big as a hello world (too much fiddling with compiler optimizations to get 100% proper code working). Would the code copied over to the IAR from an AVR-GCC working environment build without problems?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Problem solved: it was that somehow we were flicking with cli()/sei() too frequently following the Atmel recommendation on the one-wire protocol. It came out that abusing the interrupt flag several times each millisecond wasn't generally a working concept.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ixremedy wrote:
Problem solved: ... abusing the interrupt flag several times each millisecond wasn't generally a working concept.
:lol:

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And... no again. In one of the last posts I was wondering if the modem was capable of pulling so much current that the stabilizer won't carry out. So it happened. I remembered that tonight I've tried with the card of a different mobile operator and guessingly the cellular antenna was so far off that the modem drew too much current from the line.

Just now I changed the mobile network and the power overdraws hanging the MCU disappeared.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I've never seen the MCU to hang so much so that even the Reset pin won't help.

Currently I've got no idea why that happens.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cool monologue bro...
how about some schematic and codes so other people could join in?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the supply drops below the BOD (if set) level the chip will not run.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This feature on the power drop is currently off

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Well I've never seen the MCU to hang so much so that even the Reset pin won't help.

If your total design is pulling more than the supply can deliver then the AVR will not strt. Remember that the RESET pin is "active low", i.e. if nothing can pull it up high enough the AVR will never go out of reset. This might happen if something else in your design tries to gulp a lot of current.

So, I second the request for schematics, or some kind of info on what you have wired up and how. Give numers from data sheet for external components, specifically their current consumption.

Sum up your current consumption figures. What is your total consumption? Can your supply deliver that?

Tell us about what power supply you are using. Might it be that you supply everything from USB? Is this USB connection capable of supplying the high 500 mA, or is it one limited to 100 mA?

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]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the device is powered up by 12 volts that are converted to 5V and 3.3V (depending on the circuit). For flash, 2xethernet (ENC28j60) and AT45DB161 - we use 3.3 volts. For USB and 1-wire sensors we use 5Volts. The USB is switched on with a 2.6A transistor. We use two stabilizers - for 3.3V and 5V respectively. The 5V (MC34063) stabilizer is of the impulse type, the 3V (linear type) stabilizer is connected behind the 5V stabilizer. The 12V power supply is up to 1.25A (on 12V).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Monitor the rest line, preferrably with a scope. Same for the supply line.

Another possibility is a firmware error: E.g. if you enable an interrupt but have not supplied an ISR for it then (assuming you compile with avr-gcc) the AVR will "soft-reset" when that interrupt condition occurs. If this happens early, then the AVR might continuously reset.

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]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

we only use two types of interrupts: the times and dryv contacts. we don't use any other. may it be LUFA? (the poor AVR-GCC may have excluded some code from compilation, as if very often does)?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

why does that hang the MCU so much that it doesn't even get RESET by the hardware pin pull-up?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

why does that hang the MCU so much that it doesn't even get RESET by the hardware pin pull-up?


That simply is not technically possible. If you pull RESET low the CPU *WILL* reset and starting fetching opcodes from the reset address onwards again. true there could be something left in SRAM (which is notcleared by the _RESET alone) that then influences the code to look like it is "locked up" but the _RESET most definitely will be resetting the CPU. It cannot "hang" over a reset.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

the poor AVR-GCC may have excluded some code from compilation, as if very often does

That is just rubbish, IMO. Show us one such circumstance where the compiler actually removed code. There is a > 99.99 percent likelyhood that it is bad C coding to begin with. The most common case is ignorance about how the optimizer works, and not using the 'volatile' keyword.

Quote:

why does that hang the MCU so much that it doesn't even get RESET by the hardware pin pull-up?

I'm still thinking that it is about the RESET pin never being pulled up enough TO GET OUT OF reset.

Did you look at the reset pin with a scope?

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]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'm still thinking that it is about the RESET pin never being pulled up enough TO GET OUT OF reset.

Well if it is reset it should take the bootloader code (which we don't touch), which, in turn, after having gone through its procedures, should startup the first byte in our firmware. Which doesn't happen.
Hard to say what is is doing when it enters this "ambivalent state", since all external interfaces are thence gone along with the console.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

That is just rubbish, IMO. Show us one such circumstance where the compiler actually removed code. There is a > 99.99 percent likelyhood that it is bad C coding to begin with. The most common case is ignorance about how the optimizer works, and not using the 'volatile' keyword.

I don't feel that appropriate to cite half the internet space dedicated to the AVR GCC here :) but take a thorough read through some Atmel docs which say that certain optimization levels may make your code be "ingen bro" :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

all external interfaces are thence gone along with the console.

There remains ... the oscilloscope...

Quote:
certain optimization levels may make your code be "ingen bro"

Then, why use them? Once they are known?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I don't feel that appropriate to cite half the internet space dedicated to the AVR GCC here but take a thorough read through some Atmel docs which say that certain optimization levels may make your code be "ingen bro"

I don't feel it appropriate to make a claim without backing it up with facts. One example, or one reference, will do. If there is an example of the optimizer breaking things I would expect it to either be bad usage of the C language, or that there is a remedy in e.g. avrlibc.

I dont get the "no bridge" thing..

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]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
That simply is not technically possible. If you pull RESET low the CPU *WILL* reset and starting fetching opcodes from the reset address onwards again. true there could be something left in SRAM (which is notcleared by the _RESET alone) that then influences the code to look like it is "locked up" but the _RESET most definitely will be resetting the CPU. It cannot "hang" over a reset.

Have you got any idea how to ensure that's always the case? so that nothing's left in SRAM that screws the whole thing and the MCU always restarts properly (I've seen different behaviours of the MCU after restarts and they were far from what I would normally expect). For example if the code is indeed broken it may get in a loop of restarts and never come back from it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

so that nothing's left in SRAM that screws the whole thing

Well it should not happen. If you write in C almost the very first thing it does is reinitialize .data and wipe .bss. However if the code happens to use .noinit (or your compiler's equivalent) then it could be affected by the "history" of what's gone before.
Quote:

For example if the code is indeed broken it may get in a loop of restarts and never come back from it.

Yes but that would not prevent the buggy code being replaced by ISP or the bootloader.
Quote:

I don't feel it appropriate to make a claim without backing it up with facts.

I too would like to see just ONE example of a program where optimization "breaks" operation (even when things like "volatile" are being properly used where appropriate). I simply don't believe it. For an insight into how Optimization affects things read this article I wrote:

Optimization and the importance of volatile in GCC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbrion0606 wrote:
all external interfaces are thence gone along with the console.

There remains ... the oscilloscope...


Sure. We've got an analogue one, but that won't help. We will order a digital one within a month, but before that happens, we can't find a way through.

Quote:
Then, why use them? Once they are known?

Well if you turn off optimization altogether, your software delays for realization of hardware protocols are all gone. So you've got to optimize your code and that's where you start.
Indeed, when your firmware is a couple of strings of code, everything is perfectly good. When you install external SRAM, make various sections for buffers and .BSS (to fit), because otherwise there is not enough physical memory for your code to fit, optimization levels may drive you insane.

AVR Memory Usage
----------------
Device: at90usb1287

Program: 78006 bytes (59.5% Full)
(.text + .data + .bootloader)

Data: 10199 bytes (124.5% Full)
(.data + .bss + .noinit)

EEPROM: 2687 bytes (65.6% Full)
(.eeprom)

That's with O1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

optimization levels may drive you insane

Not if the code is written with optimization in mind in the first place.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For AVR-GCC there are known problems for several optimization levels, but there are also known and documented remedies. Examples:

Your ISR wors just fine using -O0 but stops working when switching to e.g. -Os. This is with a very high probability due to not declaring a variable shared between the ISR and main() as volatile. This is not a compiler bug - it is a well known programmer mistake and the compiler is in this respect fully compliant with the C standard.

If you use the _delay_xx() functions in avrlibc, they do not wor when using -O0. They require optimization, and this is well documented.

Certain things have rather strict clock limitations, e.g. disabling the watchdog timer. You must write a bit to a certain register within a few clock cycles. Since the C language maes no promises whatsoever about timing on this level (actually, not on any level) it might be that code written in C doing two consecutive settings of that bit in that register might not uphold the timing. Typically it will not work using -O0. To fix this you need to switch to assembler, or use some well crafter asembler written by someone else - e.g. the avrlibc contains a function with such inlined assembler and it will work regardless of optimization level. Again, this is not a compiler bug of any sort.

Now, please supply one example. Or reference one Atmel document so that we know what we're up against. No example/reference, and we will need to put up the BS sign here.. :wink:

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]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Well it should not happen. If you write in C almost the very first thing it does is reinitialize .data and wipe .bss. However if the code happens to use .noinit (or your compiler's equivalent) then it could be affected by the "history" of what's gone before.

clawson wrote:

Yes but that would not prevent the buggy code being replaced by ISP or the bootloader.

I would want to take the base that my eyes don't betray me, so quite many times I saw the MCU entering a loop of restarts. Yes, that would happen if it executed a heavy bug, but after it restarted I would expect it to work for at least till it comes across the same bug (several minutes of time), but not 20 milliseconds. Not AVR-GCC with how it compiles and aligns the code? Well then Atmel with the hardware...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

but not 20 milliseconds

Eh?

typedef void (*fp_t)(void);
int main(void) {
  fp_t reset = (fp_t)0x0000;
  reset();

This "bug" will reset the micro only microseconds after power is applied. Why should it be the case that it has to take seconds?

But as already said several times here ISP works by holding the chip in _RESET. The ISP programmer pulls that signal low. So it won't even get to my main() here because it's in reset.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

but not 20 milliseconds

Eh?

typedef void (*fp_t)(void);
int main(void) {
  fp_t reset = (fp_t)0x0000;
  reset();

This "bug" will reset the micro only microseconds after power is applied. Why should it be the case that it has to take seconds?

But as already said several times here ISP works by holding the chip in _RESET. The ISP programmer pulls that signal low. So it won't even get to my main() here because it's in reset.

Just a couple of minutes ago a programmer complained that http.c in our project, when compiled -O2 doesn't execute any scripts below the "/scripts" directory, which is something that is written like if(strncmp("/scripts",url,8) == 0){ }. Gives the "not found" error. When recompiled -O1 it starts working. Bad code in strncmp()?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Bad code in strncmp()?

Either that or more likely the code surrounding it. If you really have an example where the optimiser breaks code then reduce it to a test case and post it here. I bet you £100 you cannot show the compiler to be at fault.

But if you really are writing code without understanding the implications that the optimizer might have I suggest one of two things: 1) turn the optimizer off or 2) learn about it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't generally understand why you're so pro-gcc oriented. In my earlier linux times I remember myself having a lot of problems with the code, compiled with gnu cc. There even were recommendations how to compile linux kernels and what versions of compilers to use.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Bad code in strncmp()?

Perhaps. Or a bug in your app code that behves benign or less malign when compiled with one optimization setting, but definitively disastrous when compiled with another optimization setting.

Examples:
- String buffer overrun thrashes what is next in memory (which in turn might differ between compiling with different optimizations).

- Missed volatile for some pointer or length or counter and the optimizer does optimize it out with one of the optimizer settings (remember that while an optimization setting might result in a specific optimization it is not guaranteed that any optimization setting will do the same optimization).

etc..

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]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But GCC is a good compiler with relatively few faults (and the wide usage means that almost all faults that do exist are already well documented). I haven't a clue what point you are making about the Linux kernel. GCC (any recent version) seems to do a pretty good job of compiling the Linux kernel whenever I do it. The very fact that it can build a ~50,000 source file project that all works without compiler induced errors would rather seem to me to be a positive recommendation not a negative?

What's the old adage about a bad workman blaming his tools? ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

Perhaps. Or a bug in your app code that behves benign or less malign when compiled with one optimization setting, but definitively disastrous when compiled with another optimization setting.

avr-nm doesn't show any memory overruns in variables, we don't use malloc. I don't see how we can overrun the memory boundaries of variables.

For GCC and Linux kernel, google for "gcc optimization site:kernel.org"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course my last message doesn't regard to the use of buffers, but we have just three big buffers and they are linked to their own named sections __attribute(section()) and so aligned by the linker.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

avr-nm doesn't show any memory overruns in variables,

Eh? avr-nm does not have the capability to check for that kind of thing. If I write:

char buff[8];

int main(void) {
  for (int i=0; i<20; i++) {
    buff[i] = i;
  }
}

Then sure avr-nm will tell me that I have an 8 byte buffer but it won't tell me that the code is over-running and writing to 20 locations, way beyond the end of the object in memory.

Quote:

For GCC and Linux kernel, google for "gcc optimization site:kernel.org"

I did that but I'm still none the wiser to the point you are making - can you provide a direct link to whatever it is you are talking about?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Eh? avr-nm does not have the capability to check for that kind of thing.

If you don't use malloc() and always use fixed size buffers, unless this is a cross-source thing where you didn't make extern _type_[size] in the header file, that is in turn included elsewhere, you can use the sizeof() macro to ensure that you're not gonna overrun the buffer. Even if you use things like for() with an incremented variable for pointing to location within a buffer, checking against the sizeof() will help you stay withing the buffer borders.
And the use of malloc() on microcontrollers is not recommended at all.

clawson wrote:

I did that but I'm still none the wiser to the point you are making - can you provide a direct link to whatever it is you are talking about?

No problem. Second link on the list https://patchwork.kernel.org/pat...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

you can use the sizeof() macro to ensure that you're not gonna overrun the buffer.

But avr-nm has no capability to check that for you and of course sizeof() does not get passed with a pointer.

char buff[8];

void fillbuff(char * buff){
  for (int i=0; i<20; i++) {
    buff[i] = i;
  }
}

int main(void) {
  fillbuff(buff);
} 

One would need to pass the length separately every time:

char buff[8];

void fillbuff(char * buff, int len){
  for (int i=0; i

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson, what's your point?:) Do you insist on GCC's optimization being sane?
Google for "gcc optimization bugzilla" and have another couple of weeks reading.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Allright...

I went here: http://gcc.gnu.org/bugzilla/quer... ,
and searched for "optimization" in the summary, left the Status at it's default selection (giving all open reports) and set Target to search for "avr-gcc".

Result:

Quote:
Zarro Boogs found

I also did your sugested Google, and as a litmus test browsed the 20 first hits. There where bugs pertaining to target like ARM, there where several resolved as INVALID (i.e. reporter claimed a bug, but it was rather ignorance or some such that was the problem), thyere where a few cases of "missed optimization" but that is not the same as a bug (i.e. generating invalid code that does not retain the semantics of the C source), etc. I could spot no actual optimnization bug re avr-gcc open among those.

Now, I do not claim that there are none. The litmus test was of-course not exhaustive. The search in the Bugzilla might not have been done quite correctly.

Still, if you could supply a link to one open bug report re optimization in avr-gcc you would hammer your point home. And I still haven't seen a link to any of the "Atmel docs which say that certain optimization levels may make your code be "ingen bro"".

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]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I strongly remember the Atmel doc on one-wire and a waiver that compiler optimizations affect timings. Since most of work with microcontrollers is timing-dependent, you are free to make your own judgements.

Second point is the use of volatile variables, which are very poorly defined in the C standard and are proclaimed "realization dependent". Due to this fact many libraries (not the specially prepared for Atmel and incorporated to avr-libc) don't use this keyword for their variables in definitions in header files. This fact makes your either rewrite the code particularly (for the GCC compiler not to spoil it) or pray that non-volatile cross-source accesses are not mixed up. If your project is not something that writes "Hello world" to the console funnily blinking with a led, you've got a mess of things wrecking on your head. I personally remember myself playing around with volatile and afterwards removing it from every single part of the project. The funniest thing is that if you start to use the volatile variables in functions, you will have to make all your global variables volatile or otherwise AVR-GCC will destroy your code (the situation with playing around I mentioned above was exactly with certain globals being non-volatile). If you REALLY BELIEVE that the use of volatile is your friend, read what other developers (particularly those writing kernel code) say about volatile http://www.kernel.org/doc/Docume...

I don't know what you guys do and how big your project are, I am a newbie to this forum, but an annoying idea crosses my mind that you help each other make the leds blink. At least so far I have been proving my eyesight straight for telling that there are bugs that make the MCUs loop endlessly till you disconnect power supply and being in states such as when the use of RESET doesn't help. Or otherwise I cannot understand how working closely with big project kept you off seeing all this. Or otherwise you would claim that all the code you write is always perfect.

Being frank, I don't see any use of being here. Hope something changes my opinion.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is also a good Russian electronics web-site if you don't mind translating it to english (or whatever language, may it be svenska), read another non-volatile justificaton http://we.easyelectronics.ru/Sof...
Half of this forum seems to be truthful followers of the volatile concept with void justification to it.
Coming back to our topic, I could waste some more time convert part of the project with different optimization levels to ASM and show it to you - what was done, but I don't have that much time now, unfortunately for myself (in the first place).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

or otherwise AVR-GCC will destroy your code

You sound like a programmer who does not understand optimization/volatile so blame the compiler rather than learning about the issue and writing code that is optimization friendly. I think all programmers using optimizing compilers (and it's not just AVR - its anything that optimizes) know that you simply cannot do:

void delay(void) {
 for (int i=0; i< 10000; i++);
}

and expect it to work. Just turning round and saying "the compiler's optimizer broke my delays" is not the solution. The solution is to know that this is not possible and do what's necessary to make it work in an optimizing environment such as:

void delay(void) {
 for (volatile int i=0; i< 10000; i++);
}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alright, it means that linux kernel developers don't understand too (including Linus) that they prohibit this in their kernel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Programming inside the Linux kernel is a very different animal to programming an AVR.

Just out of interest I did a little experiment with different optimisation levels in avr-gcc. I used something a little bigger than Hello World (over 5000 LOC + floating point library). I compiled it using O0, O1, O2, O3 and Os. I then ran each in an automated test rig. The only problems I encountered where with O0, as it took too long to boot so the tests timed out. The project makes extensive use of interrupts and communicates over 2 UARTS, an SPI bus and an I2C bus simultaneously. It also uses the volatile keyword in a few places.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Programming inside the Linux kernel is a very different animal to programming an AVR.

Indeed - kernel code cannot do soft delays - it's a multi-threaded environment. If you want a delay use jiffies and yield while waiting. See Rubini:

http://www.makelinux.net/ldd3/chp-7

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We have over 20000 of strings of code, use hardware SPI, softare SPI, two ethernet controllers, one-wire, realise TCP/IP stack, use USB. The project is huge. And optimization kills portions of code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

And optimization kills portions of code.

Then they clearly weren't written with the affects of optimisation in mind - principally the use of volatile where necessary.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kernel programming isn't much about soft delays, there is no need for soft delays in the kernel since it's got a totally different architecture. The reason why they don't use volatile is not because of soft delays.
The reasoning is strong and is very good documented. So the use of volatile in any code is an abuse of the compilation routine.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, the Linux kernel has a totally different architecture, and is irrelevant to this discussion.

ixremedy wrote:
Optimization kills portions of code.

Do you think that is because of a bug in the optimizer or because you refuse to use volatile?

How do you control access to data shared with ISRs?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cli(), sei() - kind of a mutex. prove it wrong

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We've got a grip of a digital oscilloscope, going to see why it enters the state when nothing can take it out of it (including HW Reset). Any suggestions what to look at?

Pages