INTL 3:770/1 3:770/3   
   REPLYADDR josef@invalid.invalid   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  937069bf   
   REPLY: <66b008f5@news.ausics.net> 224774f9   
   PID: SoupGate-Win32 v1.05   
   On 05.08.24 01:04, Computer Nerd Kev wrote:   
   > Josef M?llers  wrote:   
   >> I used to use the sysfs interface to the GPIO pins (/sys/class/gpio) but   
   >> I understand that is deprecated nowadays. So I tried to switch to lgpio   
   >> which looks OK.   
   >   
   > Personally I switched to using the "gpio" command that's one of the   
   > example programs included with the bcm2835 library. If you're just   
   > trying to build C programs to replace the /sys/class/gpio devices   
   > in a shell script, it's an existing option. It does have some bugs   
   > though.   
   >   
   > https://www.airspayce.com/mikem/bcm2835/   
   >   
   > See examples/gpio/gpio.c in the source code.   
      
      
   I'll have a look at that, thanks!   
      
   >> However, I have problems writing and reading back pin   
   >> states from different programs.   
   >> [snip]   
   >> However ... When I set the pin's state to "1", I still read back "0"!   
   >>   
   >> What am I doing wrong? Thanks in advance for any pointers.   
   >   
   > At a GUESS, you're reading the input buffer instead of the output   
   > buffer. In output mode the input is disabled and always reads zero   
   > or is meaningless.   
      
   Well, the documentation (https://abyz.me.uk/lg/py_lgpio.html#gpio_read)   
   says "This command will work for any claimed GPIO (even if a member of a   
   group). For an output GPIO the value returned will be that last written   
   to the GPIO."   
   So, I was thinking that that would happen.   
      
   > Unfortunately I've forgotten whether this is the case with the Pi,   
   > or at least where to look to confirm I'm not mis-remembering, so   
   > check for yourself. But this is a common way for IO hardware to   
   > work.   
      
   OK, that sounds logical ... at the hardware level. However, I read the   
   documentation such that either it works eg like the ATMega port pins,   
   where you can read back the state of an output pin, OR the kernel driver   
   would keep a copy of the output state and return that upon a read  OR   
   the library function would do that, but shame on me I have not checked   
   the latter myself.   
      
   Thanks anyway,   
      
   Josef   
      
   --- SoupGate-Win32 v1.05   
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)   
   SEEN-BY: 1/19 16/0 19/37 80/1 90/1 105/81 106/201 123/130 129/305   
   SEEN-BY: 142/104 153/757 7715 203/0 218/700 840 220/70 221/1 6 242   
   SEEN-BY: 221/360 226/17 30 100 227/114 229/110 111 114 200 206 300   
   SEEN-BY: 229/317 400 426 428 470 550 616 664 700 230/0 240/5832 266/512   
   SEEN-BY: 267/800 280/5003 282/1038 291/111 292/854 301/1 310/31 320/119   
   SEEN-BY: 320/219 319 2119 322/757 762 325/304 335/364 341/66 342/200   
   SEEN-BY: 396/45 423/81 460/58 633/280 712/848 770/1 3 100 330 340   
   SEEN-BY: 772/210 220 230 5020/400 5053/58 5058/104 5075/35   
   PATH: 770/3 1 218/840 221/6 1 320/219 229/426