Yahoo Groups archive
Messages
Page 15 of 307 · 15341 messages matched
2012-04-20 by bayramdavies
R E Purcella wrote: > ... "the complete reference C++" by Herbert > Schildt, third edition ... [says] ... "The > modifier volatile tells the compiler that a > variable's value may be changed in ways not > explicitly specified by the program." You see, this isn't actually correct.
2012-04-20 by R E Purcella
Having a "the complete reference C++" by Herbert Schildt, third edition, I tackled his definition of volatile. He gives it 2 paragraphs. His opening statement is: "The modifier volatile tells the compiler that a variable's value may be changed in ways not explicitly specified by
2012-04-19 by bayramdavies
Gregory N wrote (in part): > It seems to me that the lack of clarity is > because people are attempting to define the > volatile storage class based on when and how > to use it, not what it is. OK, well, the above is a kind-of self-fulfilling observation, because volatile isn't a
2012-04-19 by Gregory N
> Do you have a suggestion on how we can achieve clarity? I haven't been following every message in this list, so pardon me if I am repeating something. It seems to me that the lack of clarity is because people are attempting to define the volatile storage class based on when and
2012-04-19 by Tim Mitchell
----Original Message---- From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf Of Robert Adsett Sent: 18 April 2012 23:45 To: AVR-Chat@yahoogroups.com Subject: Re: [AVR-Chat] Re: Volatile modifier > How about > > ----- > volatile controls access to a variable
2012-04-18 by Steven Holder
On 18/04/2012 23:44, Robert Adsett wrote: > > On 4/18/2012 5:18 PM, bayramdavies wrote: > > I am still grappling with my "definitive" description of volatile, > > which I hope to submit for review, but there is also work to do for > > which I actually hope to get paid, so it's no
2012-04-18 by Robert Adsett
On 4/18/2012 5:18 PM, bayramdavies wrote: > I am still grappling with my "definitive" description of volatile, > which I hope to submit for review, but there is also work to do for > which I actually hope to get paid, so it's not ready yet. How about ----- volatile controls acces
2012-04-18 by bayramdavies
Don Kinzer wrote: > If while examining a particular function > or smaller code sequence it is determined > that (a) the content of ... [etc., etc.] Well, that looks good to me, but then I've been agreeing with you all along. What I'm trying to get at, though, is why people are st
2012-04-18 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, "bayramdavies" wrote: >Do you have a suggestion on how we can achieve clarity? I think this statement describes the issue: If while examining a particular function or smaller code sequence it is determined that (a) the content of a storage locatio
2012-04-18 by bayramdavies
STEVEN HOLDER wrote: > Confusion has certainly defeated clarity. Do you have a suggestion on how we can achieve clarity? Graham.
2012-04-18 by STEVEN HOLDER
To be fair, the avrlibc does give the misleading impression that volatile is required for a variable that is only updated in an ISR routine and not in the "main" loop of the code with a very limited example but it is response to a faq. This thread started as a fairly simple quest
2012-04-18 by bayramdavies
R E Purcella wrote (although not in this order): > Perhaps, global means something different between us? > I use global to mean variables in my code declared > before MAIN, declared outside of other functions OK, let's straighten this out. "Global" means in scope (and thus able t
2012-04-18 by R E Purcella
I found this statement very helpful. "No, this is not true. If a "global" variable (one with external linkage) is not declared volatile, then the compiler will assume that it cannot change during the execution of the code being compiled other than by an assignment it can see with
2012-04-17 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, "bayramdavies" wrote: > But, doesn't a C compiler [...] limit itself to the consideration > of a single translation unit at a time? That would mean that if > a called function is in a different unit there is no way of > knowing what global variabl
2012-04-17 by bayramdavies
In AVR-Chat@yahoogroups.com, Don Kinzer wrote: > For most languages, C included, it is conceptually > easy [to determine whether or not a function modifies > a global variable]: look at a function and see what > global variables it might modify and then do the same > for any func
2012-04-17 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, "bayramdavies" wrote: >> ... unless it can determine conclusively otherwise. > Which, I think, it generally can't for the C language. For most languages, C included, it is conceptually easy: look at a function and see what global variables it migh
2012-04-17 by bayramdavies
Don Kinzer wrote: >... if there are any calls to other functions in > the code region of interest the compiler must > assume that any particular global variable > has been modified ... Good point. > ... unless it can determine conclusively otherwise. Which, I think, it generally
2012-04-17 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, "bayramdavies" wrote: > > Otherwise most global variables are by > > nature changeable at any time. > No, this is not true. If a "global" variable (one with external > linkage) is not declared volatile, then the compiler will assume > that it cann
2012-04-17 by bayramdavies
R E Purcella wrote: > As I understand it, Volatile variables are > used when the variable is expected to be > changed in Interrupt routines. That is one situation. See Don Kinzer's post of Apr 13 for others. > Otherwise most global variables are by > nature changeable at any time
2012-04-17 by R E Purcella
As I understand it, Volatile variables are used when the variable is expected to be changed in Interrupt routines. Otherwise most global variables are by nature changeable at any time. But, interrupt routines do not normally allow outside variables to be changed unless they are v
2012-04-16 by Tim Mitchell
----Original Message---- From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf Of bayramdavies Sent: 16 April 2012 12:57 To: AVR-Chat@yahoogroups.com Subject: [AVR-Chat] Re: gcc compiler bad behaviour > So, although the > compiler is not interested in the val
2012-04-16 by bayramdavies
Group, While composing my previous post in reply to Bob Paddock, I read the Dr. Dobb's Journal article he referenced only as far as was necessary to determine that it was not about my algorithm (which demonstrates passing data between threads using only volatile control variables
2012-04-16 by bayramdavies
Group, In my opinion still, Don Kinzer's posts on where to use the volatile qualifier are unassailable and Bob Paddock's disagreement, "Volatile is never the solution to a problem with threads", is without merit. Read on if you have the stomach for it. Bob, You write "I stand by
2012-04-16 by bayramdavies
Tim Mitchell wrote: > OK Thanks for the clarifications about volatile ... the > variable in question was ... being ... changed in mainline > code ... [and] being *read* in an interrupt routine. As > the compiler couldn't see the variable being used in the > current scope it optim
2012-04-16 by Tim Mitchell
OK Thanks for the clarifications about volatile... what I was distracted by was that the variable in question was not being *changed* by an interrupt routine, it was only changed in mainline code. However it was being *read* in an interrupt routine. As the compiler couldn't see t
2012-04-15 by Bob Paddock
> Bob Paddock is incorrect to assert that "Volatile is never the solution to a problem with threads", whether by "problem" we are talking about a normal design challenge or something that has gone wrong. The use of volatile variables to communicate between threads is a perfectly
2012-04-15 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, "bayramdavies" wrote: > [...] if we define "threads of execution" to include the main thread, > interrupts, exceptions, pre-emptive threads running on the same > machine and all threads running on different machines that can > access the same stor
2012-04-15 by bayramdavies
I believe that I have considered these issues in enough depth to weigh in here and try to sort out this dispute. We are talking here about the use of the volatile modifier, so I have changed the discussion subject accordingly. Don Kinzer is correct to write that "The volatile att
2012-04-14 by Bob Paddock
> --- In AVR-Chat@yahoogroups.com, Bob Paddock wrote: > > Volatile is never the solution to a problem with threads. > Nonsense. The volatile attribute is precisely the solution for *any* situation where a variable can be changed by an outside actor - even if it is another task. N
2012-04-14 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, Bob Paddock wrote: >> The volatile attribute is precisely the solution for *any* >> situation where a variable can be changed by an outside actor > No. http://blog.regehr.org/archives/28 "Nine ways to break your > systems code using volatile" See
2012-04-14 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, Bob Paddock wrote: > Volatile is never the solution to a problem with threads. Nonsense. The volatile attribute is precisely the solution for *any* situation where a variable can be changed by an outside actor - even if it is another task. As I no
2012-04-14 by Bob Paddock
> The volatile attribute must be used on any variable that may be modified > by a means that cannot be anticipated by the compiler given the code that it > can see. Examples include: > - variables representing hardware registers > - variables in multi-port memory > - variables mo
2012-04-13 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, STEVEN HOLDER wrote: > Generally if you do have variables that are global and can be > changed outside the main routine then declare them as volatile I don't think this statement describes the issue precisely enough. Firstly, the phrase "can be ch
2012-04-13 by STEVEN HOLDER
Tim, The AdcVals are being changed in a intterupt routine then ? The compiler needs to know that the values being stored or where they are being stored can changed or else it will optimise incorrectly, i.e it needs to have foresight of the fact that the values can change, if a va
2012-04-13 by Tim Mitchell
The GCC compiler optimiser seems to be doing a weird thing to me... I'd like to understand it. it seems to require a volatile qualifier when I am not expecting it. I have the following variables defined unsigned char LedLevel0=0; unsigned char LedLevel1=0; volatile unsigned char
2012-04-13 by englsprogeny1
--- In AVR-Chat@yahoogroups.com, "Alex Pereira Silva" wrote: > > hello people, > I'm coming from a knowledge of pics and I'm starting now atmel found them very good but like any beginner I have some doubts: > > 1 - I did the LED blinks on and used the gcc compiler used as command
2012-04-13 by jccordill
One of the best places for AVR info is on the AVRFreaks web site, lots of tutorials and example projects to learn from. Jim KI0BK an ImageCraft C compiler user
2012-04-10 by Alex Pereira Silva
hello people, I'm coming from a knowledge of pics and I'm starting now atmel found them very good but like any beginner I have some doubts: 1 - I did the LED blinks on and used the gcc compiler used as commands avr-gcc-g-Os-c-mmcu = ATMEGA8 teste.c avr-gcc-g-mmcu ATMEGA8 =-Wl,-Ma
2012-04-07 by englsprogeny1
I am looking into changing over to 3.3V parts (ATMega8L and ATMega16L) I have an "off the shelf" parallel port SPI programmer. Can I safely use this without ruining the 3.3V parts on my board?
2012-04-04 by Clark Martin
On Apr 3, 2012, at 5:10 PM, stu_ki6j wrote: > Thank you, gentlemen. > > I was afraid the information was hiding in the datasheet despite my search. Yes, Table 18-7 is included in my copy as well. > > A 10 Mohm divider indicated would put my standing current at a tolerable 1.x uA.
2012-04-03 by stu_ki6j
Thank you, gentlemen. I was afraid the information was hiding in the datasheet despite my search. Yes, Table 18-7 is included in my copy as well. A 10 Mohm divider indicated would put my standing current at a tolerable 1.x uA. I like the idea of a FET switch to turn the divider "
2012-04-03 by Bernd Felsche
On Tue, 3 Apr 2012 11:32:01 stu_ki6j wrote: > I am designing an tiny13 based voltage monitor. I wish to use the > internal reference to measure input voltages up to 15V, thus I > need a voltage divider at the A/D input. I wish to reduce power > consumption to a minimum. What mini
2012-04-03 by Tim Mitchell
You can get away with much higher impedance than 10K if your application can wait for a settling time after setting the A/D input MUX before you do the conversion. You have to charge up the capacitance of the A/D input, so if your impedance is very high, you need to wait for that
2012-04-03 by STEVEN HOLDER
From the datasheet, the recommendation is for the source impedance to be 10K or less as there is a sample and hold circuit inside that can give incorrect readings if not charged sufficiently quickly between samples. The sample time can be adjusted in the registers (by reducing th
2012-04-03 by Clark Martin
On Apr 2, 2012, at 8:32 PM, stu_ki6j wrote: > I am designing an tiny13 based voltage monitor. I wish to use the > internal reference to measure input voltages up to 15V, thus I need a > voltage divider at the A/D input. I wish to reduce power consumption to > a minimum. What mini
2012-04-03 by stu_ki6j
Greetings, I am designing an tiny13 based voltage monitor. I wish to use the internal reference to measure input voltages up to 15V, thus I need a voltage divider at the A/D input. I wish to reduce power consumption to a minimum. What minimum current through the divider would pro
2012-04-02 by englsprogeny1
Steven, You are correct. I don't know why but I had it in my head that uartRxBuffer was an array.... Thank you! --- In AVR-Chat@yahoogroups.com, STEVEN HOLDER wrote: > > Isn't the first argument a pointer to a type of cbuffer so should be > > UART_Buffer[count] = bufferGetAtInd
2012-04-02 by STEVEN HOLDER
Isn't the first argument a pointer to a type of cbuffer so should be UART_Buffer[count] = bufferGetAtIndex(&uartRxBuffer,1); What version of GCC are you using ? Regards ________________________________ From: englsprogeny1 To: AVR-Chat@yahoogroups.com Sent: Monday, 2 April 2012, 3
2012-04-02 by englsprogeny1
AVR GCC Atmega8 Using: Procyon AVRlib In an attempt to look into the UART_Rx buffer I make the following call: UART_Buffer[count] = bufferGetAtIndex(uartRxBuffer,1); I get the following Error: error: incompatible type for argument 1 of 'bufferGetAtIndex' -------------------------
2012-03-31 by bobgardner@aol.com
-----Original Message----- From: bobgardner To: icc-avr Sent: Fri, Mar 30, 2012 9:09 pm Subject: fatfs c source for iccv7avr anyone? Have one of you intrepid icc users ported one of the gcc syntax fat file system projects to iccv7avr yet? After hours and hours of edit/compile/scr