Libgpiod vs pigpiod vs wiringPi

[Eugene_Dakin]

Hi Jeff,

Glad to see that the example works for you.

The general format of the book will likely remain the same (commands, electronics fundamentals, transistor-transistor-logic), and the parts that will definitely change is the code. An example is pigpio_start does not exist in the new library and instead uses lgGpiochipOpen. In general the same ‘type’ of steps exist, where the board is opened, pins are selected as input/putput, and then each pin is assigned a value through a write command.

[Jeff_Borghoff]

ok, lol. I printed out the book/pdf. I look forward to the update.

[Eugene_Dakin]

Thats alot of paper

It going to take a while for the update (months?) if everything goes well. If there is a major issue with either the programming language or the library then this could take considerably more time to fix (years?). From the old saying “A bird in the hand is worth two in the bush”

[Jeff_Borghoff]

Ok, I’ll continue with the current doc and library builds. Thanks, Eugene.

[James_Sentman]

Does this new library support access to the serial ports, or for bit banging on a regular pin to make a software serial port? I was also using the weird scripting available in pigpio to do things like pwm fades on pins via the remote server. I suppose if I want a server process for the new library I’ll need to write my own and install it on the pi and build a new interface to it for the remote app? I really liked the server functionality of it as well.

That being said it was not entirely reliable and the serial port stuff was hit or miss as far as reliability. I’ve got one machine where the pigpiod process goes to 100% of a CPU core even though it’s not actually doing anything.

[Eugene_Dakin]

@James_Sentman

My first presumption is it ‘should’, although I haven’t created an example yet. When I look on the website (lg library) the features are:

• reading and writing GPIO singly and in groups
• software timed PWM and waves
• GPIO callbacks
• pipe notification of GPIO alerts
• I2C wrapper
• SPI wrapper
• serial link wrapper
• a simple interface to start and stop new threads

I optimistically think it should support access to the serial ports and bit banging. Being that this is calling pure C code, then there should be less resources being consumed. As you mentioned, data over a serial port shouldn’t consume 100% of the CPU.

[Ivan_Tellez]

@Eugene_Dakin

GPIO callbacks

I stoped using Xojo for GPIO, it was a lot of trouble to have decent response to multiple events. Does the new lib have better support for real time events in xojo?

[Julia_Truchsess]

Very much hoping the new book will describe how to do “real” SPI rather than bit-banging.

[Eugene_Dakin]

@Ivan_Tellez

I stoped using Xojo for GPIO, it was a lot of trouble to have decent response to multiple events. Does the new lib have better support for real time events in xojo?

Hi Ivan,

The events seems to work well in other programming languages, and there seems to be issues in Xojo. The short answer is, I don’t know about the response time in Xojo with multiple events.

Could you provide me with a simple example? I am just making this example up: Reading 3 distance sensors on a robot to make sure it doesn’t run into wall.

[Eugene_Dakin]

@Julia_Truchsess

Very much hoping the new book will describe how to do “real” SPI rather than bit-banging.

Thanks Julia. I’ll look into this a little more and see what I can do. Thanks for the good suggestion

[Eugene_Dakin]

After thinking a little more about Julia’s great request, are there other areas that should be looked at when I am working on the lgpio library?

If its something easier to work with, such as real-SPI then I can definitely look at it. If the request is something like: create a robot, or make a room scanner, then this is likely a larger project that would be considered as a separate project. There are no promises

[James_Sentman]

@Eugene_Dakin

I optimistically think it should support access to the serial ports and bit banging. Being that this is calling pure C code, then there should be less resources being consumed. As you mentioned, data over a serial port shouldn’t consume 100% of the CPU.

That looks fantastic actually I should be able to adapt the current source to use the new libraries. The 100% CPU thing I don’t think has anything to do with the serial ports, it’s just how I’ve found it sitting there sometimes even when it’s not doing anything. I will definitely put this on my list to start experimenting with soon.

[Eugene_Dakin]

Hi Julia,

Over the last few days I tried to have SPI work and unfortunately was not able to make it work with Xojo.

Here is the code in python that I could make it work with the pigpio library.

#!/usr/bin/env python

import pigpio

def read_MCP3008(adc, channel):
count, data = pi.spi_xfer(adc, [1, (8+channel)<<4, 0])
value = ((data[1] << 8) | data[2]) & 0x3FF
return value

pi = pigpio.pi()

if not pi.connected:
exit()

adc1 = pi.spi_open(0, 50000, 0) # CE0
adc2 = pi.spi_open(1, 50000, 0) # CE1

for c in range(8):
print(read_MCP3008(adc1, c), read_MCP3008(adc2, c))

pi.spi_close(adc1)
pi.spi_close(adc2)

pi.stop()

Maybe I’ll be able to get it to work in the future with Xojo.

[Julia_Truchsess]

@Eugene_Dakin

Over the last few days I tried to have SPI work and unfortunately was not able to make it work with Xojo.

Well, that stinks, but thanks for trying. Bit-banging in 2021 with computers more powerful than the supercomputers of a couple of decades ago How about UART - same thing?

[Eugene_Dakin]

@Eugene_Dakin

Maybe I’ll be able to get it to work in the future with Xojo.

@Julia_Truchsess,

I created an example program that works with PIGPIO and SPI. The converted code from the above Python code is shown below:

Public Function Read_MCP3008(adc as Integer, channel as Integer) as Int32
Var Data as UInt64

Dim txBuf as New MemoryBlock(4)
txBuf.UInt32Value(0) = 1
Dim rxBuf as New MemoryBlock(4)
rxBuf.UInt32Value(0) = 128 // CE0
//Sends and receives data from SPI device
//adc = handle, txBuf = transfer data to SPI,
//rxBuf = receiving data from SPI
//data contains the number of returned bytes (8 in this case)
data = pi.spi_xfer(adc, txBuf, rxBuf , 8)
//Returned data is an array of returned number of bytes

//Format the data specific to the MCP3008 chip
Var m as New MemoryBlock(4)
m.Byte(0) = Bitwise.BitAnd(rxBuf.Byte(2),&hF0) + Bitwise.BitAnd(rxBuf.Byte(3),&hF)
m.Byte(1) = Bitwise.BitAnd(rxBuf.Byte(1),&hF)
Var value as Int32 = Bitwise.BitAnd(m.Int32Value(0), &h3FF)

return value //returns raw value
End Function

Below is the main event in a button action event:

Sub Action() Handles Action
//Get the voltage value (VoltValue) from the MCP3008 using SPI
//Clear the listbox
Listbox1.RemoveAllRows

//Retrieve the handle for an SPI device on channel
Var adc1 as Integer
// Successfully returned handle is =>0
// (0 = CE0 channel, 50,000 is baud (bits per second), flags are 0)
adc1 = pi.spi_open(0, 50000, 0) //CE0

//Use method to get value (0 - 1023)
Var x as Integer = Read_MCP3008(adc1, 0) //MCP3008 pin
// Determine voltage (3.3V reference)
Var Voltage as double = x/1023*3.3

Listbox1.AddRow("Raw Value: " + x.ToString + ", Volts: " + Voltage.ToString)

//Closes the spi device
call pi.spi_close(adc1)

End Sub

This uses SPI (CE0) on a MCP3008 to measure the voltage (3.3v reference). I have only been able to read one of the pins, and its a start and doable.

[Eugene_Dakin]

Version 1.17 of the free pigpio-GPIO library has been updated to Version 1.17 (7 Jan 2021) with the three new methods used in this example.

The free github file can be downloaded here:

eugenedakin/pigpio-GPIO

[Julia_Truchsess]

That’s great, thanks so much @Eugene_Dakin for persevering!

[Eugene_Dakin]

Hello Everyone,

Just a friendly update. I have been able to start working on the Libgpiod library and am working on a book with Xojo functions. I am impressed with the speed of the library so far.

Here is the link to the starting functions of the libgpiod library, and it will continue to be updated as I write more examples in the book.

GitHub - eugenedakin/Libgpiod-GPIO: Raspberry Pi Libgpio for the Raspberry Pi...

My wild guess is that the book will be ready in 6 months or so and it is written with Xojo API 2.0 language and API 2.0 controls.

As a side note, could Xojo call Xojo API with the language changes API 2.0, and Xojo API with the control changes API 2.1? It would make it much easier to answer questions from colleagues and prevent miscommunication.