Like let’s say I have a few old HP alphanumeric LED displays that have a simple bit pattern protocol. I’ve gotten them working in Arduino a long time ago. If I can find some unused pins how can I bit bang them into a custom protocol from user space using pins that may be unrelated as far as I/O ports on a modern computer? Is it even possible without a kernel module? Am I stuck with using a serial channel like SPI/I2C/UART to talk to an external controller?

  • ChubakPDP11+TakeWithGrainOfSalt@programming.dev
    link
    fedilink
    arrow-up
    12
    ·
    edit-2
    4 months ago

    You don’t need any garbage 3rd party packages. Just use ctypes.

    Read the documentation for ctypes. You can use any native object in Python the way you do in C using ctypes.

    Whatever you do, don’t trust some god-forsaken 3rd party package. I think people have forgotten to be clever and resourceful these days. A binary object is itself a package, why would you use s another package to communicate with it?

    Here’s how you can import libc into Python:

    from ctypes import CDLL
    
    libc = CDLL(None)
    

    Just pass it path to the binary object that holds the symbols for GPIO.

    Some tricks. Here’s how you can use libc to make a syscall in Python:

    libc = CDLL(None)
    
    TIME_NR = <syscall nr for time(2) on your arch>
    
    libc.syscall(TIME_NR)
    
    
    
  • martinb@lemmy.sdf.org
    link
    fedilink
    arrow-up
    5
    ·
    4 months ago

    I recall that there is a USB GPIO dongle which gives you a bunch of pins to play with. You would have to hunt around to find it though.

  • ryannathans@aussie.zone
    link
    fedilink
    arrow-up
    2
    ·
    4 months ago

    Could you use a small microcontroller running micropython? Then you can just type into the repl on that over usb, or run your python on it directly

    • j4k3@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      4 months ago

      I’ve done that before, and with Forth. I’m more interested in bridging what I know with hardware into the desktop environment… or understanding why it seems so disconnected.

  • computergeek125@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    4 months ago

    Possibly important detail - what type of computer do you propose running this? Most methods that are common if you search the internet or ask here will likely apply to Raspberry Pi and it’s clones, but if you have something more esoteric it might not work.

    • j4k3@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      4 months ago

      I’ve thought about messing with something in an old router with OpenWRT since they have a maintained Python repo and there are documented I/O for buttons and LED’s, along with SPI and UART that are broken out.

      I also had an old laptop where the board came with several unpopulated I/O. The board came in multiple configurations and I had the base model, so it had a bunch of connections I could have reverse engineered (something I am much more confident doing rather than software). I was curious about the potential to break out these connections but knew it was beyond my abilities at the time. Now that comp is not needed so messing about is much more feasible.

      I’ve got a raspberry π. The point is not to have something that just works, but to understand what just works really means. And like, how to interact more dynamically with a microcontroller with less protocol formality where I tend to get lost in the weeds when I have some simple need and don’t want the overhead of all that complexity.

      • computergeek125@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        4 months ago

        It being a laptop will almost undoubtedly make that endeavour more challenging. Off hand, I can’t think of a single non -proprietary internal connector from a major vendor that doesn’t already have a protocol established.

        If there’s spare I/O, it’s most likely either not hooked up, was only used as a debug header, or fused off as a feature not available on that model. If it is indeed connected to something, you’d need to find documentation on that exact model of laptop since boards can sometimes vary even within the same series (such as whether a GPU is available). Chances are, whatever your find will need a specific vendor library that may or may not work on your version of the OS.

        Unlike RPi and similar devices, you won’t find many consumer x86 devices that leave GPIO available and documented.

        Off-hand, I think almost every LCD display I’ve encountered on x86 is plugged in to either a serial (for character displays) or higher-level protocol (for more complex displays)