From: tnp@invalid.invalid   
      
   On 25/03/2024 11:31, Pancho wrote:   
   > On 24/03/2024 11:13, The Natural Philosopher wrote:   
   >   
   >> However on trawling the internet I discovered a conversation  with   
   >> someone else *on here* (c.s.r-pi) last year, who was finding that   
   >> *sleep_us(x)* was highly inconsistent for certain (small) values of x.   
   >> Sometimes taking a day to end.   
   >>   
   >> Further investigation reveals that in fact it really is a 'sleep' with   
   >> the processor being put in low power mode and requiring an interrupt   
   >> to 'wake it up'.   
   >>   
   >   
   > Why not use threads/timers, wait on a lock/semaphore rather than sleep.   
   >   
   Good point Pancho, but I was really looking for the simplest code   
   possible.  Interrupts can be tricky things on a platform whose   
   architecture you do not understand completely. In any case it was a   
   learnning curve I preferred not to negotiate if i didnt need to   
      
   > But looking at PICO code samples, they commonly use sleep, so I'd be   
   > surprised if it was that bad.   
   >   
   I am veering away from that explanation, as with the test board located   
   at some distance from any target, the problem has not reappeared.   
      
   I am beginning  to think that it may be possible for the echo pulse to   
   'come *and* go' before the high level PICO code has got round to   
   actually looking for it in the first place.   
      
   That is, some asynchrounous event in this sequence   
      
   	gpio_put(ULTRASONIC_OUT,1);   
   	sleep_us(10);   
   	gpio_put(ULTRASONIC_OUT,0); //reset the input   
   //if asynch event lasting more than 100uS occurs here...   
   	// wait for echo pulse start   
   	while(!gpio_get(ULTRASONIC_IN))   
   		;   
   //then the low-high-low echo pulse will never be detected.   
      
   It is also not clear from the documentation whether it is the low to   
   high, or the high to low sequence, that triggers the ultrasonic board.   
      
   If it is low to high, then there is an opportunity for an occasional   
   very  long delay in the	   
      
   sleep_us(10);   
      
   to delay resetting the pulse until Elvis has left the building,. so to   
   speak...   
      
   So I have tow things to do. Understand how the ES module works in terms   
   of timings, and replace that sleep_us with a different delay mechanism.   
   It's now been 24 hours with no lockup with a distant target...   
      
   OIL-SENSOR   
   OIL-TANK   
   -85dBm   
   57.60cm   
   23.7°C   
   4.6V   
      
   I have noticed that with absoluteley no change in sensor location I get   
   up to ± 0.5cm variation in delay.   
      
   --   
   If I had all the money I've spent on drink...   
   ..I'd spend it on drink.   
      
   Sir Henry (at Rawlinson's End)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)