If #include doesn't work, there's a problem with your installation, because the AVR GCC compiler (including WINAVR) certainly supports that.
With inttypes.h included, all the usual uint16_t and similar work as expected.
If you want to find out how big your standard types are, you can do something like this:
printf( "int has %d bits\n", 8*sizeof(int) );
Thanks. I wasn't aware of ISO C99.
I taught myself C for 8085's back in the 80s, Avocet C running on a Z80 plug in an 8MHz PC. I dabbled with Boreland turbo C around 1991/92 and a few times since.
Other than switching to various PIC compilers I haven't had to look too closely at C. If I've need to check anything I've just grabbed my copy of K & R.
type
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
Just been hit by another irritation and I'm curious if this is WINAVR or ISO C99.
A flag set on interrupt wasn't being tested in the main routine. Googling tells me I need the key word volatile which indeed solves the problem.
I can't remember other versons of C having a problem knowing a variable is used on and off interrupt. What smart ass compiler writer optimizes out code that someone has written? Does he think we put it there for fun???
That's standard C behavior.
Generally, you want your compiler to optimize the code. The 'volatile' keyword was introduced to allow maximum optimization while still producing correct code in these circumstances.
Other versions of (PIC?) C may not have been as well constructed.
Given a code snippet:
int tick;
main() { ... tick = 0; while (1) { if (tick != 0) { // do something } } ... }
it is quite reasonable for the compiler to observe that the only assignment to tick is to the constant 0 and to elide the if statement, just as if it had been written
if (0)
That's why the volatile type-qualifier is supplied, to inform the compiler that an object could be modified in ways unknown to the implementation.
Pedantic: since tick above has static storage duration it will be initialized to zero before program startup. The explicit assignment is redundant, and is included for clarity.
-- Rich Webb Norfolk, VA
Seems like bog-standard behavior to me.
From the ISO/IEC 9899 standard:-
-- 114) A volatile declaration may be used to describe an object corresponding to a memory-mapped input/output port or an object accessed by an asynchronously interrupting function. Actions on objects so declared shall not be "optimized out".
So I'm out of date, again.
One of the problems of effectively working on your own andone of the reasons I hang out here. Like flowers engineers need to cross pollenate.
It's not "on or off interrupt", it's just the semantics of the volatile keyword:
-- Les Cargill
That's a curiously sexual metaphor for such an unpromiscuous group!
Tim
-- Deep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms
Almost every high-grade compiler is going to do those sort of optimizations, unless you suppress them. If you globally suppress
*all* optimizations of the sort which can get you into trouble when sharing variables between mainline and interrupt code, you'll probably find the size of your application's generated code has grown... a lot!There are probably two sorts of code optimation which, when combined, trip you up in this situation:
- Register load optimization... the compiler will not load a variable from RAM into a register, if it "knows" that the current code sequence already has that same memory location loaded into a register.
- Use-of-knowledge-of-constants: if the compiler "sees" a conditional expression or some other use of a variable, and "knows" that the variable was set to a constant by earlier code in this code-path (i.e. with no chance that a subroutine call or etc. could have overwritten the constant), then it will often substitute the value of that constant, for the variable, in generating the code. The net effect is something like this:
staticflag = false; ... other code if (staticflag) { do something }
In this case, if there are no subroutine calls in the "other code", an optimizing compiler may treat the conditional as
if (false) } do something } and treat it as a "dead" code sequence, and completely optimize it away.
You'll see this behavior in many, if not most highly- optimizing compilers.
Basically, you're dealing with a fundamental conflict... C is a sequential programming language (and a compiler necessarily takes advantage of this sequentiality to figure out what to do) but you're using it to provide code which can break that sequentiality (interrupts).
You can defeat it, in many cases, by globally disabling certain compiler optimizations. If you do, though, you'll end up with significantly less efficient run-time code, because *every* individual reference to a memory variable is likely to generate an individual "load into register" instruction... this can lead to a lot of register churn, unnecessary and slow access to RAM, etc.
Using the "volatile" keyword is a *selective* way to disable this, for individual variables, by informing the compiler that it cannot "trust" this variable to remain unchanged by external circumstances (and, by implication, that a value written to this variable might not "read back" the same way, even in the very next instruction).
The "board support package" for a CPU will often include an #include file which defines the CPU's hardware registers as C variables or structures... and these definitions will usually include the "volatile" keyword, for just this very reason.
You just need to apply the same principles when you're defining your own variables or structures which are being shared between two different execution contexts e.g. between mainline and interrupt code, or between two different POSIX (or other) threads, or between code running on two loosely- or tightly-coupled CPUs.
--
Dave Platt AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
In addition, the volatile keyword also ensures that the compiler will not optimize away writes, or reverse the order between them.
So, if you have:
volatile int x;
x = 3; x = 4;
The compiler will leave the first assignment in, instead of optimizing it away. Without the volatile, the compiler is free to remove the first assignment, and just keep the second one.
This can be important when writing to peripheral registers with a side effect.
For simple hard-coded delays, you may also need volatile.
A simple:
int i;
for( i = 0; i < 100; i++ );
may get optimized away completely. If you declare 'i' as volatile, the compiler will leave it in.
Could you please cite a reference for that. Also about synchronization points wrt volatiles.
AFAIK "volatile" means no more and no less then the value of a variable can change in the way not seen by compiler.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
ISO C99:
5.1.2.3 Program execution
many
er.
e.
ck
that
Follow-up:
The "Yes" is answering the PS3 Jail-Breaking part, not "WinAVR as crap". Gcc, where WinAVR is derived, is great software.
---------------------------------------------------------------------------=
-Before 2010: Sony's factories use the buffer overflow technique to QA/QC/install the system. Upon power up, immediately reject the blue-ray disc. This will cause the system to look for another device on USB (most likely a 4-port hub). However, if the device emulates a 6-port hub, it will cause a buffer overflow and start executing on the stack. Sony itself use this to control the manufacturing.
Early 2010: Someone got the detail information from the factories and started selling USB devices to boot Linux, as well as backing up blue-ray discs.
Sept 2010: Open source psgroove project released to the public, using the Atmel At90usb162 USB micro. Many other micros and devices were ported as well. Psgroove injects a 4K boot loader into the PS3. However, additional programs need to be installed on the hard drive or other device for Linux.
Mid-Sept 2010: Sony released on-line updates to stop the exploit. Sony urges retailers such as Best Buy and Walmart to upgrade (more like downgrade) the PS3 before selling. Some will do the favor with fee from the consumer. Sony should have paid the retailers to do so.
Today: Many small shops around the world can restore the PS3 Flash to version
3.15. Linux developers are using the UDIP/UKEY with custom SD/CF/ATA devices.
Yes, you certainly do.
There's probably a setting where you can get the optimizer to issue warnings when it completely removes a chunk of code.
However, the idea is that -- in many cases, with more complex code -- it might not be obvious to the casual observer that a particular chunk of code is constant-value or otherwise always does the same thing and hence can be eliminated; if you were to examine a large, complex piece of code such as a web browser, you'd probably be quite surprised just how many optimizations the compiler is able to find (including how many lines of code can be eliminated). Heck, these days many people advocate writing code that makes it more obvious what's happening under the assumption that the compiler will perform optimization, e.g., writing "if ( x & (1
If you're really concerned, use objdump to generate a mixed listing, then go over that.
Well, C is definitely a language where one often "gets lucky" and things do still work even though -- per the strict interpretation of the C standard -- there's no guarantee that it had to. :-) This is particularly true in un-optimized code -- you can commit all sorts of sins and often the code still works as intended!
This is actually one of the reasons I *like* optimizers -- they can be very useful for helping find what really was buggy code... or just not being aware of some of the finer points of the language itself.
---Joel
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.