Software malfunction !!!

General discussion on mikroC PRO for AVR.
Author
Message
public2010
Posts: 94
Joined: 05 May 2009 18:31
Location: Somewhere in Europe

Software malfunction !!!

#1 Post by public2010 » 21 Nov 2021 20:07

Hello,

I'm trying to develop software using the Easy AVR 6 board to do this:

Code: Select all

do  {
           for(cnt=0; cnt<=1; cnt++)
              {
                 if(cnt == 0)
                    {
                    adc = 0; 
                    adc = ADC_read(cnt);        // Read ADC value pin PA0 Atmega 32
                    
                 if (adc>=0 && adc<250)
                       {  
                          PORTC0_bit = ~PORTC0_bit;  // ON-OFF output pin C0 Atmega 32  
                       }
                    else
                    if (adc>=251 && adc<500)
                       { 
                          PORTC1_bit = ~PORTC1_bit;  // ON-OFF output pin C1 Atmega 32 
                       }
                       else
                       { 
                          PORTC2_bit = ~PORTC2_bit;  // ON-OFF output pin C2 Atmega 32 
                       }
                     }
                     
                  if(cnt == 1) {
                     adc = 0; 
                     adc = ADC_read(cnt);        // Read ADC value pin PA1 Atmega 32
                     //.....
                     }
              }
            Delay_ms(100);
    } while(1);
Therefore, I designed a voltage divider with three resistors so that three voltages can be found on the PA0 input of the Atmega 32 MCU depending on the switch pressed (switches without retention - see photo below). So, only one switch can be pressed.

The problem is that I have to press the same switch several times so that the corresponding output (PC0, PC1, PC2) to switch from 0V to 5V OR 5V to 0V !!! I believe that the pressing, which normally does not take more than a second, is scanned by the software several times and in the end the MCU decides to let the corresponding output from 0V to 5V or 5V to 0V. So I have to press the same switch several times in a row to get, at some point, say, a 5V on the PC0 output and I would not want that! I mean, I don't want to press the same switch several times.

Yours have any ideas / tips that I could add in the software so that I don't press the same switch several times? Please!

Image

Levi
Posts: 55
Joined: 01 Mar 2008 20:27

Re: Software malfunction !!!

#2 Post by Levi » 22 Nov 2021 13:01

Hi ,
You suggest that you need an analogic keyboard for this you just have to read the divided voltage from the adc port like:

Code: Select all

  adc_value = ADC1_Read(4);    //analog value from voltage divider by switches
         adc_value=  adc_value>>7;
         case (adc_value)
         {
                  case 2:
         //switch 1 is pressed
         break;
                 case 4:
            //switch2 is pressed
         break;
                  case 6:
            //switch 3 is pressed
         break; 
         
         }
Regards,
Levi

public2010
Posts: 94
Joined: 05 May 2009 18:31
Location: Somewhere in Europe

Re: Software malfunction !!!

#3 Post by public2010 » 22 Nov 2021 13:45

Thanks for the reply. I have posted below the circuit I want to make.

Because in practice the A0 output from the circuit cannot take the exact value, for example, of 2.5V, I have to make the MCU orient itself after a certain ADC count range: 0...1023. For 2.5V, I think 400...600 it is enough. For this reason, I don't think using the break instruction is the best solution! Or maybe you have a more explicit example, please!

The problem is that practically when I give an impulse, say, on the S2 switch, which, how long can it last? Let's say, for a maximum of one second, the MCU reads the voltage on the ADC channel several times, during which time the output corresponding to PC1 switches sometimes to 0V, sometimes to 5V.
I want when I press once to toggle the PC1 pin output to 5V, after this episode, I press once more, then PC1 = 0V and so on.

So, I don't know how to make the MCU so that when it continuously reads the same value on pin PA0 it leaves the PC0 output in the same state, say 5V. After that, after an indefinite pause, but I repeat the operation, to switch the PC0 output to 0V...
circuit.jpg
circuit.jpg (74.09 KiB) Viewed 2566 times

Levi
Posts: 55
Joined: 01 Mar 2008 20:27

Re: Software malfunction !!!

#4 Post by Levi » 22 Nov 2021 13:58

Hi,
This is the reason for this code

Code: Select all

 adc_value=  adc_value>>7;
To round the adc value to be "steady"

And regarding the PC0 or other outputs to stay in the same state while you push the switch, you have to latch the corresponding bit, this is the reason for switch/brake statement


Regards,
Levi

public2010
Posts: 94
Joined: 05 May 2009 18:31
Location: Somewhere in Europe

Re: Software malfunction !!!

#5 Post by public2010 » 24 Nov 2021 20:23

Thanks, I finally managed with your help but I had to recalculate the resistors of the resistive divider.

I have only one problem to solve, namely:
- If I press S2 to switch the PC1 output from 0V to 5V and I hold this S2, I noticed that the LED connected to the PC1 output flashes, which is not good !!!
- Also, if S2 is pressed again after a certain time to switch the PC1 output from 5V to 0V, the phenomenon is repeated, if I keep the button pressed for more than a second, the LED flashes. Why?

Could I correct this software better? But how? I tried to change Delay from 20 to 50ms but without success !!!

Levi
Posts: 55
Joined: 01 Mar 2008 20:27

Re: Software malfunction !!!

#6 Post by Levi » 26 Nov 2021 13:04

Hi,
Your led is toggling with the delay parameter , because the main loop of the program is changing your led status bit.In this case you have to set a latching set/reset flag to overcome toggling like

Code: Select all

#include<stdbool.h>

bool flag_read_once=true;
//--------

case (adc_value)
{
case 1:
if(flag_read_once)
{
flag_read_once=false;
//here toggle output

}
break;
case 2:

break;
default: flag_read_once=true; //enable again the reading no switch selected


}


Regards,
Levi

public2010
Posts: 94
Joined: 05 May 2009 18:31
Location: Somewhere in Europe

Re: Software malfunction !!!

#7 Post by public2010 » 29 Nov 2021 20:30

Thanks again for your advice.

I started writing the software again and now it looks like this:

Code: Select all

do  {
                    adc = 0; 
                    adc = ADC_read(0);        // Read ADC value pin PA0 Atmega 32
                    adc = adc >> 7;
                    		bool flag_read_once=true;
     				switch (adc) {   				
     					case 0:  if(flag_read_once)  { 
                        						flag_read_once=false;  
                        						PORTC0_bit = ~PORTC0_bit;  // ON-OFF output pin PC0 Atmega 32 
                        					  } break;	
     					case 2:  if(flag_read_once)  { 
                        						flag_read_once=false;  
                        						PORTC1_bit = ~PORTC1_bit;   // ON-OFF output pin PC1 Atmega 32 
                        					  } break;
                        		case 4:  if(flag_read_once)  { 
                        						flag_read_once=false;  
                        						PORTC2_bit = ~PORTC2_bit;  // ON-OFF output pin PC2 Atmega 32 
                        					  } break;					  
				default: flag_read_once=true;
               }
            Delay_ms(100);
    } while(1);
Now it seems to work better, although I sometimes have to press the same switch twice or even three times in a row to change the output status of a pin. You can help me with another useful tip to get rid of this problem with consecutive pressing - I repeat, it happens sometimes, randomly. :(
Last edited by public2010 on 30 Nov 2021 18:24, edited 1 time in total.

Levi
Posts: 55
Joined: 01 Mar 2008 20:27

Re: Software malfunction !!!

#8 Post by Levi » 30 Nov 2021 10:46

Hi,
Try to put de 100ms delay after adc = ADC_read(0);
Do yo have interrupts in your code?
Regards,
Levi

dibor
Posts: 208
Joined: 29 Dec 2014 18:59

Re: Software malfunction !!!

#9 Post by dibor » 30 Nov 2021 11:48

If I remember right - was some issue with AVRs.
First ADC reading maybe wrong, so first time read ADC twice.

Regards.

public2010
Posts: 94
Joined: 05 May 2009 18:31
Location: Somewhere in Europe

Re: Software malfunction !!!

#10 Post by public2010 » 30 Nov 2021 15:52

Levi wrote:
30 Nov 2021 10:46
Try to put de 100ms delay after adc = ADC_read(0);
Do yo have interrupts in your code?
Regards,
Levi
I've tried this, things have gotten better but still not exactly right.
I think I have no interruptions in my code !
But I connected a 1x16 LCD on the EasyAVR board exactly in the example from the microelektornica help mikroC to see the adc value.
dibor wrote:
30 Nov 2021 11:48
If I remember right - was some issue with AVRs.
First ADC reading maybe wrong, so first time read ADC twice.
I tried an 'ovesamplig' on 14bit but the problem still exists.

Other ideas, please! :(

Levi
Posts: 55
Joined: 01 Mar 2008 20:27

Re: Software malfunction !!!

#11 Post by Levi » 01 Dec 2021 11:26

Hi,
Try to connect a 10-100nf capacitor between adc input and ground.
Regards,
Levi

Thomas.Pahl@t-online.de
Posts: 158
Joined: 24 May 2008 15:55
Location: Germany

Re: Software malfunction !!!

#12 Post by Thomas.Pahl@t-online.de » 03 Dec 2021 15:29

Ideas? If you need more stable values from adc: do for instance 10 measurements, add the values and devide them by 10. (arithmetic mean).
The adc of AVRs is very good when the ref-voltage is filtered.

public2010
Posts: 94
Joined: 05 May 2009 18:31
Location: Somewhere in Europe

Re: Software malfunction !!!

#13 Post by public2010 » 04 Dec 2021 10:59

Levi wrote:
01 Dec 2021 11:26
Hi,
Try to connect a 10-100nf capacitor between adc input and ground.
Regards,
Levi
@Levi, I tested the software on the EasyAVR6 board which I know has an capacitor on the ADC inputs but also on a custom PCB board where I added that capacitor on the PA0 input. In both cases, the program works the same, that is, sometimes I have to press the same button consecutively once (or twice) for the PC0 output to get the desired value, or to switch from 0 to 1 or vice versa.
Thomas.Pahl@t-online.de wrote:
03 Dec 2021 15:29
Ideas? If you need more stable values from adc: do for instance 10 measurements, add the values and devide them by 10. (arithmetic mean).
The adc of AVRs is very good when the ref-voltage is filtered.
@Thomas, as I said above, I tried a 14 bit oversampling where the adc value is read about 256 times and then the result is divided by 16. Indeed, in oversampling mode, things work better but it doesn't work exactly as should.

I remember years ago I made a software in mikroC for AVR that still didn't work properly. Then, I reproduced it in Atmel Studio and it worked 100% correctly.
Now, I'm thinking of doing the same thing with this program but using Microcip Studio. If there is anyone in the meantime who has any advice to apply it in mikroC, please let me know.

Levi
Posts: 55
Joined: 01 Mar 2008 20:27

Re: Software malfunction !!!

#14 Post by Levi » 07 Dec 2021 09:33

Hi,
Try another thing just for testing ( I don't like delays in the program loop 😊 ) tray something like :

Code: Select all

case 0:  if(flag_read_once)  { 
                        						flag_read_once=false;  
                        						PORTC0_bit = ~PORTC0_bit;  // ON-OFF output pin PC0 Atmega 32 
                        						
                        						delay_ms(1000);// put here one or two or more seconds delay
                        						
                        					  } break;	
     					case 2:  if(flag_read_once)  { 


Regarding your question you mean this? https://microchipdeveloper.com/mplabx:m ... n-atstudio

Regards,
Levi

public2010
Posts: 94
Joined: 05 May 2009 18:31
Location: Somewhere in Europe

Re: Software malfunction !!!

#15 Post by public2010 » 09 Dec 2021 08:52

@Levi, thanks for the reply.

I tried to add a long delay after pressing a button but it gets to the other end of the problem, more precisely, the program (software) identifies more difficult (or it takes more time) to see which button was pressed.

In the meantime, I reproduced software in Microcip Studio, the problem persists even there, although it seems to me that it works a little better.

Post Reply

Return to “mikroC PRO for AVR General”