Compatibility with defined behaviour of variables in another programming language (overflow etc) is another reason, like recently discussed in Trying to translate overflowing JS code to Perl. It might just be easier to load an existing library or interpreter than to recreate all that behaviour in Perl.

Another popular reason is security. I'd rather trust some XS bindings to the always updated and audited OpenSSL library, written by security experts, used by some of the biggest companies in the world) to secure my connections than i would to some pure-perl reimplementation made by a one-person team in their spare time.

Plus, why go to all the hassle of designing a complicated set of Perl modules to, say, implement an interpreter/interface/protocol/crypto library when some nice chaps on the internet have already gone through all the hard parts and gave you a perfectly fine C library with all the trimmings and bugfixes and workarounds. All you have to do is write a nice XS wrapper(*) around it and you're done. Unless the developers of that lib decide to change the interface, you even get all the updates for free ;-)

(*) If you're lucky and the interface is simple enough, h2xs might even do a lot of the work for you. Thumbs up for Perl scripts that writes Perl scripts for you!

No, it's primarily about interfacing with an existing C library

Thanks...that makes a lot of sense. cavac's point about security resonates here -> Re^2: XS Modules - why and when?

But in RPi::DHT11, there doesn't seem to be any reason to use XS unless the C code already existed. I had assumed stevieb wrote the C code as well as the Perl code, but I have nothing to base that on.

If we look at RPi::PIGPIO::Device::DHT22 we can see a pure Perl method of reading the output from the device (DHT11 and DHT22 are read the same way). As Perl is rather good at bitwise and mathematical operations, it just seems weird to me that XS would be used in this situation.

I quickly scanned the POD for RPi::DHT11 and found:

> This module requires the wiringPi library to be installed

And http://wiringpi.com/ states:

> WiringPi is a PIN based GPIO access library written in C

And

> is intended for use by experienced C/C++ programmers.

So, doesn't this answer your question?

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

If we look at RPi::PIGPIO::Device::DHT22 we can see a pure Perl method of reading the output from the device (DHT11 and DHT22 are read the same way).

Ahhh, but wait! Understand that the library you mention is a TCP connector to a daemon that is running on the Pi hardware. That daemon is what does all of the GPIO register manipulation directly. That daemon is written in guess what? C! So the library you mention does not interact with the hardware directly. It communicates with software that does. My software directly interfaces the hardware, which is why I needed C/XS to do so. This library communicates with someone elses software via a TCP socket that does the down and dirty work.

See here for info on pigpio.

From the pigpio web page:

The pigpio library is written in the C programming language. The pigpio daemon offers a socket and pipe interface to the underlying C library.

So that's why the library you mention can be written in Pure Perl. Note that the author of the Perl library you mention and the author of pigpio are not the same person.

Just a quick note on those DHT11/DHT22 sensors. Ignoring the fact that their humidity sensor is absolutely craptastic and permanently breaks if humidity goes too high(*), the one wire sensor protocol needs very tight timing, see Basics of Interfacing DHT11/DHT22 Humidity and Temperature Sensor with MCU.

The problem with running these (or other protocols that have implicit timing requirements like WS28xx LED strings) is that you simply can't guarantee that from a user land process (or even "at all") on a system like Linux or Windows. Especially, if you have a high process load. Your process simply might not get scheduled at the right times. In all likelyhood, the sensor will work most of the times, but you'll sometimes get random data and/or errors. For me, a cheap microcontroller and Device::SerialPort usually solve the trick for these kind of problems.

---

(*) DHT11 - temp ok, but RH values wildly off. I generally now recommend using a Bosch BME280 breakout board instead. At least from the limited tests i've done on my projects, this sensor seems to be a lot more reliable long term.

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP