We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello !! I've following problem: I use a ATMEL T89C51CC01 Mcu with the Keil C51 c-compiler/simulator. When I use the ADC in pseudo idle mode (I set PSIDLE bit) the MCU doesn't wake up any more (although the ADEOC flag occurs !! and all other bits are set (EA,EADC,Priority highest and also tested lowest)). Until now I've tested the software only on the simulator... Has anybody an idea, what the problem might be ?? thx for your help, florian mair. P.s.: using the idle mode of the PCON sfr (IDL bit) the Mcu wakes up again ...
Yes I cleared it.... My ADC interrupt function works when I use the ADC in 8 bit modus (PSIDLE not set), but in 10 bit modus the MCU doesn't wake up anymore (but the ADEOC gets set !!) (the only difference between the functions is that I set the PSIDLE bit....) thx... florian.
The other difference is that you read 2 bytes in the 10 bit mode. Here is a wild guess, read them in the reverse order.
that's not the problem !! my problem is that the MCU doesn't wake up any more ! (it locks up .. and no interrupt is able to wake it up again ! (I've nearly tried all of them ...)but this is only if I set the Psidle bit) florian.
Not knowing the part well, I made a guess that the ADC bytes have to be read in a particular order. Otherwise, maybe the micro is left in a "waiting for the next byte to be read state". This might inhibit an interrupt. Doing things in a proper order is very critical to getting a micro to work. This might not be your problem. However, I see no basis for your grand arm waving statement that this could not possibly be the the problem. When I made the suggestion that maybe would were not clearing the ADEOC bit EVERY time in your ISR, you replied: "but the ADEOC gets set !!". (If you do not clear the bit every time you'll get only one interrupt, even though the ADEOC gets set.) I hope you realize ADEOC being set is just a necessary, but not sufficient reason the interrupt to be seen. Just because the "ADEOC gets set" does not mean you do not have a bad program. If all you do is wave off suggestions, why do you request help?
I'm sorry that it turned up to you that I'm not interrested in your suggestion, (that's not at all) but you suggested me to read the bytes in reverse order but I'm not even be able to read a byte... here is the exact situation / code: (gadc_b is a global bit) this is my ADC interrupt routine: void Adc_int_(void) interrupt ADC_INT { ADEOCOFF; //sets ADEOC = 0 gadc_b = 1; } this is my routine: (sfr status: EA = 1, EADC = 1;ADEN =1;) gadc_b = 0; ADCON &= 0x78; //Pin 0 PSIDLEON; //sets PSIDLE ADSSTON; //sets ADSST while (gadc_b == 0){ //waiting till interrupt occours... ; //here the ADEOC flag gets set by hardware but nothing happens.. (when I don't set the PSIDLE bit everything works...) } thx for your help, florian.
I can see a possible problem. The micro goto to sleep before the ADSSTON line executes. I would goto to sleep, start the conversion and clear the last end of conversion flag, all in one statement. In this case the ISR does not need to do anything.
void Adc_int_(void) interrupt ADC_INT { } WORD ReadAdc( BYTE Channel ) { ADCON = 0x48 | Channel; //= PSIDLE | ADSST | ~ADEOC //the only way to get to this line is for the conversion to be completed return( ADDH << 8 | ADDL ); }
Dear Mr. Young ! Now we have it ! It was a fault of the Simulator Version 2.14. I've updated it to Version 2.20a and now it works fine.... thx for your help again, florian.