3

I am relatively new to the Raspberry PI platform and more experienced with Arduino.

I have noticed in the examples for Infrared Receiving and 1-Wire protocol that the Python sketches to interact with these protocols revolve around native operating system support (like LIRC and reading from the /devices file.

Is this common in Raspberry PI?

Usually I like to access the GPIO sensors directly, in code, as opposed to reading files and pipes from the underlying file system.

I am wondering if there is a reason there aren't more direct libraries for things interface / protocol control.

So, phrased as a question: Why does Raspberry Pi rely so much on operating system support as opposed to direct python libraries to interface with 1Wire and IR ?

Startec
  • 297
  • 1
  • 3
  • 8
  • Ah let me see, (1) Why are so many drivers written in C, so less in python? The main reason is that drivers need to talk at low level which are always in C. Of course C is also faster. You can also wrap C software in python, for python fans. For IR I tried both LIRC and also python, I found both OK, but LIRC is poorly supported. For other devices, if control not too complicated, I use both drivers in C and also in python, eg, PN532/MFRC522 NFC/RFID chips/modules. I found NFC drivers in python very good for trying out new things. For basic MFRC522 pythong driver, it is only about 400 lines, – tlfong01 Apr 18 '20 at 10:19
  • You might like to see how I tried the C hased LIRC driver, and also python direct control: https://raspberrypi.stackexchange.com/questions/103452/rpi3-lirc-library-and-uart-ir-transceiver-setup-problem. – tlfong01 Apr 18 '20 at 10:23
  • Another example is the GPS driver/demon, GPSD, which is a complex, huge project. You just cannot use slow python to do the low level stuff. But of course you can use python API to do the high level things, eg: https://raspberrypi.stackexchange.com/questions/98840/rpi-uart-to-gps-module-connection-problem. – tlfong01 Apr 18 '20 at 10:27
  • Right now I am playing NFC drivers in both C and python. LibNFC driver is old and no longer supported. So I also tried python drivers and also rewrite mine. But using python direct is tricky, not for faint of heart newbies. You might like to see how involved it is (1) https://raspberrypi.stackexchange.com/questions/109773/how-can-rpi-python-read-a-mfrc522-pn532-nfc-rfid-mifare-smart-card-tag, (2) https://stackoverflow.com/questions/61165652/how-can-rpi-read-a-pn532-nfc-module (3) https://stackoverflow.com/questions/60819793/problem-with-detecting-badge-with-pn532-and-raspberry-pi. Cheers. – tlfong01 Apr 18 '20 at 10:41
  • I had 5 hobbyist years in Arduino and another 5 in Rpi. I enjoyed using their libraries/drivers. Same as Rpi, I usually first study the Arduino library programs, and sometimes I expand or rewrite my own. This way I learn how to write drivers, or how to be a hobbyist developer. Cheers. – tlfong01 Apr 18 '20 at 10:45
  • 1
    You say "Usually I like to access the GPIO sensors directly", but most sensors can be accessed through I2C, SPI, or UART, similarly to Arduino. There are very few sensors that you can access directly, because the interface timing is rather complicated. As an example, you may like to read my answer to the GPIO connected DS18B20 temperature sensors: https://raspberrypi.stackexchange.com/questions/100203/ds18b20-temperature-sensor-rpi-3-4-driver-wiring-detection-and-python-progr/100244#100244. Using driver takes 30 minutes, writing your own driver might take you 3 months! – tlfong01 Apr 18 '20 at 13:24
  • Yet another comment: Many drivers/kernel/daemons are huge, and based many old packages, largely in C. Some drivers, eg, GPSD, took me three hobbyists to setup and use. As I said earlier, it might take me three months to write a temperature sensor, but the GPSD takes 24 person years! References: "GPSD - A GPS Service Daemon": (1) https://gpsd.gitlab.io/gpsd/index.html, (2) https://raspberrypi.stackexchange.com/questions/98840/rpi-uart-to-gps-module-connection-problem/98919#98919. / to continue, ... – tlfong01 Apr 19 '20 at 02:03
  • GPSD Project Summary: All languages = C 56%, Python 21%, XML 10%, 8 Others 13% Total lines of code = 78,908 lines Active Contributors = 40 Man Month = 24 Personal years (avg salary = 55,000/year) Estimated Cost = US$ 1,313,594. – tlfong01 Apr 19 '20 at 02:04

2 Answers2

6

The Raspberry Pi is generally used with an operating system. The most common is the Linux based Raspbian.

Linux is a multi-user, multi-tasking operating system. Many people may be using the Pi at any one time.

My idle Pi has 120 tasks running currently.

If all those tasks were allowed to access resources in an ad hoc fashion nothing would work. The operating system has to control and arbitrate accesses to resources. Resources being things like processing time, memory, files, GPIO, etc. etc.

The Arduino has no operating system and only one program runs at a time. It doesn't matter how that program accesses resources as there is nothing else running to care.

Stuggi
  • 268
  • 1
  • 2
  • 4
joan
  • 71,024
  • 5
  • 73
  • 106
0

I stumbled across this Question and while Joan's answer is correct and her libraries (generally) use socket and pipe interfaces; there are a great number of programs (in C, Python and occasionally other languages) which directly access the Pi peripheral hardware - usually GPIO pins.

Most programs use one of the libraries to access the hardware (just as most Arduino programs use libraries). See https://raspberrypi.stackexchange.com/a/117592/8697

This directly hardware access is generally frowned on by Linux purists (for good reasons) but on a single user device or embedded system there is little problem.

Milliways
  • 59,890
  • 31
  • 101
  • 209