Cannot Aquire Pin Level with Processor Expert - MC9S08GT32CFB

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Cannot Aquire Pin Level with Processor Expert - MC9S08GT32CFB

1,633 Views
aale2025
Contributor I

Description: Hello ! I'm using MC9S08GT32CFB on an ultrasonic flowmeter project with a PING ultrasonic sensor from parallax. This sensor uses the same pin for excitation and the pulse with time to target info. After excitation, it sends back a square pulse whose time witdth corresponds to the double time of flight to target. So, I'm using pin 24, named PING with output configuration, and pin 25, named LEVEL with input configuration. I placed a diode after pin 24. Using a periodic interrupt with 1 us period, I ask if the level on pin 25 is high, so as to increment a counter (named h), after the pulse finishes, I could get the number of microseconds with that counter. The counter barely increments to 17, when should expect 500 microseconds. I've also tried with time capture bean, though program crashes.
Something is wrong when reading the logical level of the pin.... Please, help !


void TI2_OnInterrupt(void)
{
  /* Write your code here ... */
 
  i = i++;
 
  PING_ClrVal();        // Set 0 on pin 24
                                 
  
  if (i == 100) {           // Wait 100 microsecs
   PING_SetVal();      // 1 on pin 24. Excitation pulse
  }

  if ( i > 110) {
 
         if( i < 25000) {
            if(LEVEL_GetVal()) {              // Check if pin 25 is high from ultrasonic echo
           h=h+1;                                    // Increase h if so.
            }
        }       
  }


  if (i == 25000) {                                  //   25 ms
    i = 0;                                                 //   Restart counters.
    h = 0;
  }   

}

 
 
Added p/n to subject.


Message Edited by NLFSJ on 2008-12-16 09:43 PM
Labels (1)
0 Kudos
4 Replies

383 Views
aale2025
Contributor I
Thank you so much for all your help !!!
It has helped me a lot.
Definitely, the issue was I was assuming the interrupt period was 1 us, when it tooked 3.5 us, to accomplish all the required processing.
I can now read the sensor output and measure within reasonable precision.
The process of sharing the problem with you was overkill !!!
Thank you !!!

Alejandro


0 Kudos

383 Views
aale2025
Contributor I
Thank you for your message.
Modifying the interrupt period, this is what I get:

5 us    -> h = 18
10 us  -> h = 17
30 us  -> h = 16

This is what I can see on the oscilloscope:

Excitation pulse: square wave, 3.4 V, about 20 us wide (strange considering having it high for 1 us in code...)
Echo pulse:  square wave, 3.4 V, 0.5 ms

A return echo of 0.5 ms (500 us), corresponds to a range of 8.5 cm aprox, which is the real distance to target.
The ping datasheet specifies a longer excitation pulse, though it works fine as it is. It seems that the important thing is to leave room for the echo.

I am not using an external crystal, only the internal one.

Still cannot get a reasonable number in the counter h....
0 Kudos

383 Views
bigmac
Specialist III
Hello,

I think that you have grossly underestimated the number of bus cycles needed to execute your ISR code.  It is simply not possible to have a periodic interrupt every microsecond.

Let's assume that your bus frequency is 8 MHz, giving 8 cycles per microsecond.  The overhead cycles required to execute an "empty" ISR function will greatly exceed this amount.  You then need to add the cycles required by your specific code - this  is also likely to be significant since 16-bit values need to be incremented and tested.

I think that a different approach will be required.  One possibility might be to use a TPM channel, in input capture mode, to read the returned pulse width.  The excitation pulse would probably be generated outside of any ISR (within the main loop), and input capture mode then enabled at the conclusion of the pulse.  Two capture readings should then take place, the first for a positive edge, and the second for a negative edge.  After the negative edge, input capture should be disabled, and the whole process repeated.

For simplest coding, you will need to ensure that the TPM overflow period exceeds the maximum delay to be measured - if more than one overflow interrupt should occur during the measurement period, this would require more complex pulse period calculation.

Regards,
Mac

0 Kudos

383 Views
ProcessorExpert
Senior Contributor III
I have checked the functionality of BitIO and TimerInt beans on GT32 and they are working properly. Here are some comments, where may be a problem:

- The code in the OnInterrupt event (part of the ISR) has to be executed within 1us and that depends on the instruction clock of the CPU ("Internal bus clock" property in the CPU bean). If the bus clock is too low in comparison with total ISR overhead, period of OnInterrupt will be longer than 1 us.

- I have found the information that the excitation pulse has to be 2 us minimally and 5 us typically, please for more detailed information refer to the datasheet of the Parallax PING))) ultrasonic distance sensor. The time of this pulse is one timer cycle in your application, that is 1 us (assuming that the ISR routine is really completed within 1us).

best regards
Vojtech Filip
Processor Expert Support Team
UNIS
0 Kudos