home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   RBERRYPI      Support for the Raspberry Pi device      21,939 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 19,747 of 21,939   
   The Natural Philosopher to Theo   
   Re: Need help with PI PICO...   
   24 Mar 24 11:43:27   
   
   INTL 3:770/1 3:770/3   
   REPLYADDR tnp@invalid.invalid   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  4fb1246b   
   REPLY:  dc85c701   
   PID: SoupGate-Win32 v1.05   
   On 24/03/2024 09:39, Theo wrote:   
   > The Natural Philosopher  wrote:   
   >> It would seem from the pin states that it gets permanently stuck in   
   >>   
   >> while(!gpio_get(ULTRASONIC_IN))   
   >>                  ;   
   >>   
   >> Which as understand it is waiting for the module (HCSR04) to *start* to   
   >> send a pulse.   
   >   
   > Can you scope it to see if the module is actually sending a pulse?   
   >   
   I could, but in fact it was easier to simply look at it in 'stuck' mode   
   with a DVM.   
      
   > Is the pulse perhaps too short for the Pico to detect?  eg if the loop or   
   > gpio_get() function took some time, it could be the signal goes 0-1-0 in the   
   > middle of a loop iteration and so the gpio_get() never sees it go 1.   
   >   
   As you can see from my last reply that is roughly where I am headed. Or   
   similar. Lacking full ICE., its all a bit 'poke the black box with   
   different sized sticks, and try and infer from what it does, what is   
   happening inside it'   
      
   I think this must be where it sticks, because this is the only infinite   
   loop with both input and output to the module in a low state, which is   
   what I measured:   
      
   	gpio_put(ULTRASONIC_OUT,1);   
   	sleep_us(10);   
   	gpio_put(ULTRASONIC_OUT,0); //reset the input   
   	// wait for echo pulse start   
   	while(!gpio_get(ULTRASONIC_IN))   
   		;   
      
   I.e that it (allegedly) sends a 10µs wide high pulse, and then waits for   
   that to trigger a response from the unit, but that response never happens.   
      
   However that should not vary with the echo *delay*, and a longer target   
   distance seems to improve things..   
      
   ...unless, thinking a bit more, the pulse is so short it comes *and*   
   goes inside that loop, as you suggested.. it certainly should *not*  be,   
   as even on a few cm of target distance, its hundreds of microseconds (i   
   make it 58µs per cm roughly)   
      
   > Theo   
      
   --   
   “It is dangerous to be right in matters on which the established   
   authorities are wrong.”   
      
   ― Voltaire, The Age of Louis XIV   
      
   --- SoupGate-Win32 v1.05   
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)   
   SEEN-BY: 10/0 1 15/0 90/1 103/705 105/81 106/201 128/260 129/305 134/100   
   SEEN-BY: 135/225 153/135 143 148 757 802 7715 218/0 1 601 700 840   
   SEEN-BY: 218/870 930 220/70 221/1 6 226/17 30 100 227/114 229/110   
   SEEN-BY: 229/111 112 113 200 206 307 317 400 426 428 470 550 616 664   
   SEEN-BY: 229/700 240/1120 266/512 267/800 282/1038 291/111 292/854   
   SEEN-BY: 301/1 113 812 310/31 320/219 322/757 335/364 341/66 342/200   
   SEEN-BY: 396/45 460/58 633/280 712/848 770/1 3 100 330 340 772/210   
   SEEN-BY: 772/220 230 5020/400 1042 5058/104 5075/35   
   PATH: 770/3 1 153/757 221/6 301/1 218/700 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca