4

Please consider the following codes:

//Code Sample 1
void func_val(void) 
{
  unsigned int val;
  ADCSC1 = 0x00; // sets the required channel.
  while(!ADCSC1_COCO); //check for conversion complete flag.
  val= ADCRL;
}

//Code sample 2
void EvalProx()
{
  unsigned int proxval;
  ADCSC1 = 0x02; // sets the required channel.
  while(!ADCSC1_COCO); //check for conversion complete flag.
  proxval = ADCRL;
}

Now both the samples are snippets from a bigger code, which compiles and works. My question is about the concept of Analog to Digital Converters in MCU. ADCRL and ADCRH are the registers in which the converted values are stored. ADCSC is the status control register in which I have specified two different channels to be used.

Question: The ADCRL/ADCRH are same for the two different setting of the ADCSC i.e. same for both the channels. So does the value of proxval influence the value of val when accessed? i.e. If func_val() is executed and then EvalProx(), is the value of proxval influenced by the val? (when both the values depend on ADCRH and ADCRL)

I hope I am clear. Before down voting this question, I request, please take some time to tell me why you have down voted, so I can improve my question.

Datasheet of the used MCU: MC9S08DZ60

Specific Page Numbers: Chapter 10 :- Page 181,182- for ADCRH and ADCRL.

embedded.kyle
  • 8,411
  • 2
  • 26
  • 44
sheetansh
  • 355
  • 1
  • 2
  • 15
  • 2
    val and proxval are both local variables, known only inside their respective functions, so neither affects the other. Both functions effectively do nothing, as val and proxval are lost when the functions exit. Perhaps you've snipped too much to show your question properly? – Peter Bennett Mar 22 '13 at 16:05
  • This question has nothing really to do with ADCs per se. It's really a C question, with some incidental references to an ADC. EDIT: and now I see @DaveTweed has said exactly this in an answer below. – Connor Wolf Mar 22 '13 at 21:12

2 Answers2

7

This question doesn't really have anything to do with the ADC specifically; what you're really asking about is the use of automatic variables inside C functions. The fact is that val and proxval don't even exist at the same time — each one only exists when its corresponding function is actually executing.

Automatic variables (variables declared inside a function and not declared as static) are allocated on the CPU stack (or a simulation of a stack if the CPU hardware doesn't support it).

It is possible that the same physical location on the stack is used for both variables, if the two functions are called from the same level in the calling hierarchy, and they have the same parameters.

Dave Tweed
  • 168,369
  • 17
  • 228
  • 393
  • Technically answer. Thanks for teaching tat part, didnt know at all! – sheetansh Mar 22 '13 at 16:13
  • and i really wish i could accept two answers, but i cannot! – sheetansh Mar 22 '13 at 16:20
  • 2
    I've heard/seen this mentioned in a few places but never fully understood it: how can a CPU not support a stack? Doesn't any architecture that uses subroutines (I'm pretty sure that's all architectures) have to push the return address onto the stack so it can return to where it called the subroutine from? The stack just means a section of memory with a pointer that grows in a certain direction and acts as a stack data structure no? I just don't understand how an architecture could not support a stack. – NickHalden Mar 22 '13 at 17:04
  • 2
    @NickHalden "supporting a stack" means (1) having an explicit stack pointer register, and (2) having primitive assembly instructions for manipulating the stack pointer register (like reti, which changes the program counter based on the stack pointer in order to return from a function call). You can emulate this without hardware support through emulation, which is compiler generated code that the same sort of things in RAM using variables. It's rare / uncommon to not have direct support for stack in any modern computer architecture. – vicatcu Mar 22 '13 at 18:02
  • 2
    There are many low-level microcontrollers that have hardware stacks for subroutine call/return and interrupt handling, but make it difficult if not impossible to store data (variables) there, and implementing a purely software data stack would be terribly inefficient. The 8051 is one classic example, and low-end PICs (PIC12/PIC16) are another. On these machines, the data stack is emulated by assigning static storage locations for automatic variables, with the amount of reuse of these locations being dependent on the sophistication of the compiler. – Dave Tweed Mar 22 '13 at 18:47
  • 1
    @NickHalden, great question (and good answer from Dave, too). Ask it on the site? – The Photon Mar 22 '13 at 19:29
  • @ThePhoton http://electronics.stackexchange.com/q/61946/4159 Here ya go. – NickHalden Mar 22 '13 at 20:35
0

I doubt that would be the case, Usually in a case like this the compiler would read the value of ADCRL and store it a location in memory that is associated with the variable val or proxval. You can verify this by looking at the generated assembly code by the compiler. But if your worried that's I would declare val and proxval as volatile variable. If val and proxval where pointers to ADCRL then yes calling one function would affect the other but as regular variable the value from ADCRL gets actually stored to variable

Kvegaoro
  • 3,141
  • 17
  • 14
  • Thanks mate! that clears up a lot. a concurrent question: so what if i am not using functions and then accessing the ADCRH/ADCRL? and i really dont know how to read ALP code. – sheetansh Mar 22 '13 at 16:06
  • Even if your not using function, you should get the same behaviour because the data will be stored in some location in memory assign to the variable – Kvegaoro Mar 22 '13 at 16:32
  • 1
    No. It is not val and proxval that need to be volatile, but rather you need to insure volatile access to the ADC registers. Usually that done where they are defined. – Chris Stratton Mar 22 '13 at 16:33