gpiolib and gpiomem, RPi

[Newlands]

I started with a Pi5 and a 64 bit OS. I am now using a Pi4, which initially came with a 64bit OS, but I have now wiped the SD card and it has a fresh install of the 32 bit OS. It is with this last setup that I have been able to run your blink.bbc program :

Code: Select all

10 REM blink.bbc  
20 REM Simple blink program in BBC BASIC
30 REM by Richard Russell, http://www.rtrussell.co.uk/
40
50 INSTALL @lib$ + "gpiolib"
60
70 REM Initialise GPIO:
80 gpio% = FN_gpio_setup
90 
100 REM Set GPIO pin 7 to output mode:
110 PROC_gpio_inp(gpio%, 7) : REM Must use PROC_gpio_inp() before PROC_gpio_out()
120 PROC_gpio_out(gpio%, 7)
130 
140 pin7% = %10000000 : REM Bit mask
150 REPEAT
160		PROC_gpio_set(gpio%, pin7%)
170		WAIT 50 : REM 0.5 seconds
180		PROC_gpio_clr(gpio%, pin7%)
190		WAIT 50
200 UNTIL FALSE
210 END

Connecting an led to pin 25 instead of 7, and using your suggestion of pin7% = 1 << 7 :, changing the 7 to 25, means that I can get it to work on other pins as well.

Code: Select all

10 REM blink.bbc  
20 REM Simple blink program in BBC BASIC
30 REM by Richard Russell, http://www.rtrussell.co.uk/
40
50 INSTALL @lib$+"gpiolib"
60
70 REM Initialise GPIO:
80 gpio% = FN_gpio_setup
90 
100 [b]REM Set GPIO pin 21 to output mode:[/b]
110 [b]PROC_gpio_inp(gpio%, 21)[/b] : REM Must use PROC_gpio_inp() before PROC_gpio_out()
120 [b]PROC_gpio_out(gpio%, 21)[/b]
130 
140 [b]pin25% = 1 << 25 : [/b]  REM Bit mask
150 REPEAT
160		[b]PROC_gpio_set(gpio%, pin21%)[/b]
170		WAIT 50 : REM 0.5 seconds
180		[b]PROC_gpio_clr(gpio%, pin21%)[/b]
190		WAIT 50
200 UNTIL FALSE
210 END

I can't say that I really understand what the bit mask actually does, as opposed to what it is. The pin7% = 1 << 7 : REM Bit mask line is a bit more understandable, or at least I can use it as a basis to make other pins work, but trying to work out the binary, along with the shift and whether it is ANDed, ORed or XORed has eluded me so far.
On a general note, much of this code looks nothing like the BASIC I learnt years ago - obviously there will be some unfamiliar terms because of making the program talk to the gpio pins of a Linux OS, but there are a lot of symbols that I've never come across before - sorry, you must be getting tired of trying to help such a hopeless case!

[Newlands]

I found the source of your blink.bbc file at last, towards the bottom of this page:
https://elinux.org/RPi_GPIO_Code_Samples#BASIC

[Newlands]

Did you try it with the RPi 4 and 64-bit OS or not? That should have worked (with the previously discussed mods to gpiolib.bbc and blink.bbc); if it didn't I need to investigate why here.

Yes, I did, and I made the changes you suggested (gpio%% instead of gpio%). Looking at it just now, would I have needed to also change the bit mask expression from << to <<< ??

That really is quite explicit. It states that, in the case of PROC_gpio_set, 1 bits in the mask cause those pins to be set (go high) and that 0 bits in the mask cause those pins to be ignored (no change). Similarly in the case of PROC_gpio_clr, 1 bits in the mask cause those pins to be cleared (go low) and that 0 bits in the mask cause those pins to be ignored (no change).

That really helps - I'll take some time to read through it all slowly.

I learnt BBC BASIC, but I don't recall ever using libraries, and it would have been on BBC Acorn machines, so no gpio pins to talk to. But your help has enabled me to at least partially understand, to the point where I now have a the basis of a program I can work with.

[JeremyNicoll]

Code: Select all

pin7% = %10000000 : REM Bit mask

is peculiar to pin 7 ... To be quite honest, I have no idea where 10000000 comes from (presumably binary for 128???). Is there somewhere that I can refer to so I can find out how to write this line for other pins?

Bit masks are used for manipulating individual bits in a byte.

A single 8-bit byte is often used internally in OSes etc to hold eight independent yes/no flags. That is although the value above would be decimal 128 (if you regard the byte as an unsigned integer) in this situation what really matters is that it's one yes flag and several no ones.

Reading left to right those eight flags possibly refer to operations that could be performed on

pin7 pin6 pin5 pin4 pin3 pin2 pin1 pin0

so if eg you wanted to do something to pins 1,2,6 all in one operation, you'd set the flags as

no yes no no no yes yes no

which in binary would be %01000110 and then perform the operation.

Does that help? If so, now go and read the wikipedia article that Richard posted a link to.

[Newlands]

A single 8-bit byte is often used internally in OSes etc to hold eight independent yes/no flags. That is although the value above would be decimal 128 (if you regard the byte as an unsigned integer) in this situation what really matters is that it's one yes flag and several no ones.

Ah, right. I was getting hung up on the values they represent. That is really helpful, thanks.

The BBC Micro was, after all, known for its ability to control external devices such as robotic arms or music synthesisers and the like.

The one I remember using was a BBC Master - it boasted an internal clock as well as a port at the back for a ribbon cable - in my case that was connected to a bank of LED status indicators.

[Newlands]

The BBC Micro (Model B) had the same ribbon-cable connectors for the 1 MHz bus, the Tube, the Printer and the Disc Interface. I'm not sure that the Master was different at all in that regard, was it?

I had a feeling that the master had two ports - the one I used had a floppy disc drive as well as the port I used for the status indicators - but I may be wrong of course. The big plus was the RTC, as I needed to access the date and time for the program used to control the position of a solar panel.

[Newlands]

I've just sent you a pm - at least it said it had been sent but when I checked it said it was in the outbox rather than the sent messages folder! Let me know if you haven't received it and I'll try again.

[Newlands]

Raspberry Pi's have always seemed to be fussy about their power supplies. Apparently the newer USB-c standard specifies a maximum 15 watts normally, and the 27 watt power supply uses a different standard and a power management chip for the higher current, which needs a special USB-c cable rather than any old cable from eBay (which is why the Pi power supply has a captive cable).

[Newlands]

This means that the gpiolib library will need significant changes to work on the RPI5, if indeed it is even possible (I think it should be, but locating the necessary information is proving difficult).

You may well have seen this - https://datasheets.raspberrypi.com/rp1/ ... herals.pdf - not that I understand any of it but it may be relevant. And you may have already supplied this link, but for the sake of completeness - https://forums.raspberrypi.com/viewtopic.php?t=364473 - the reply to the original post has a load of info.

I also found a few links relating to Python and GPIO on the Pi5, but again I have no idea if the library the Python programmers use has any 'transferable' information eg https://www.tomshardware.com/how-to/con ... h-python-3, which says:

With the Raspberry Pi 5, we are unable to use RPi.GPIO due to how the GPIO pins are memory mapped. This forces us to use an alternative, and libgpiod is the focus of this how to.
Libgpiod, specifically python3-gpiod is a pure Python module for interacting with the GPIO. It feels similar to RPI.GPIO in that we have to explicitly set the GPIO pins before we use them. We see gpiod as more of an intermediate module for Python and the GPIO. If you are new to this, use GPIO Zero which also works with the Raspberry Pi 5. GPIO Zero was created by Ben Nuttall and Dave Jones and greatly simplifies the GPIO.

The tests I did last week on the Pi4 (32 bit OS) worked ok - sending 1s and 0s to two GPIO pins (It's just your original Blink program but with two pins instead of one, plus some other irrelevant lines):

Code: Select all

900 INSTALL @lib$ + "gpiolib"
  910
  920 REM Initialise GPIO:
  930 gpio% = FN_gpio_setup
  940
  950 REM Set GPIO pin 25 to output mode:
  960 PROC_gpio_inp(gpio%, 25) : REM Must use PROC_gpio_inp() before PROC_gpio_out()
  970 PROC_gpio_out(gpio%, 25)
  980 PROC_gpio_inp(gpio%, 24) :
  990 PROC_gpio_out(gpio%, 24)
 1000 pin25% = 1 << 25 : REM Bit mask
 1010 pin24% = 1 << 24 :
 1020 a = 0 : REM a is the counter that determines number of pulses sent to the stepper driver
 1030 REPEAT
 1040   PROC_gpio_set(gpio%, pin25%)
 1050   WAIT 30 : REM 0.3 seconds - reduce to 0.01 secs for the stepper driver
 1060   PROC_gpio_clr(gpio%, pin25%)
 1070   WAIT 30
 1080   PROC_gpio_set(gpio%, pin24%)
 1090   WAIT 30 : REM 0.5 seconds
 1100   PROC_gpio_clr(gpio%, pin24%)
 1110   WAIT 30
 1120   a = a + 1
 1130 UNTIL a = 10 : REM '10' is replaced by the angle difference from the calculated altitude and azimuth angles
 1160 END

[Newlands]

The fourth post down in the R Pi forum link says:

Re: Raspberry Pi 5 GPIO Docs
Quote
Mon Oct 16, 2023 10:53 am

pete_codes wrote: ↑
Mon Oct 16, 2023 10:39 am
Ah... Typo... I meant /dev/gpiomem... Apologies and thanks!

But, yeah, looking at it, there are now gpiomem0 to 4 instead of a single gpiomem.

Is all of this documented somewhere do you know?
the only real doc i know of right now is the source in linux
https://github.com/raspberrypi/linux/bl ... #L122-L160
this creates the 5 gpiomem interfaces, and clearly specifies the name each should have under linux

gpiomem0 is tied to the io_bank0 peripheral in the RP1, where you can bit-bang the RP1 pins

gpiomem1 is tied to the gio brcm,brcmstb-gpio block in the SoC
gpiomem2 is tied to the gio_aon brcm,brcmstb-gpio
gpiomem3 is tied to brcm,bcm2712-pinctrl
and gpiomem4 is tied to pinctrl_aon brcm,bcm2712-aon-pinctrl

my rough guess, is that 3 and 4, are for changing pin modes, including setting them into gpio mode
and 1/2 are for actual gpio actions
but 1/2/3/4, are for pins directly on the SoC, which arent exposed on the main gpio header

so 90% of users will be using gpiomem0 exclusively

which suggests that gpiomem4 is used to change the pin modes, and that gpiomem0 is what will be used most of the time.
The only thing I've managed to achieve in this regard is as I described early on in this thread:

The Pi bistro has libgpiod installed, which allows access to the pins from a terminal window, with commands such as gpioset gpiochip4 21=1 to set a pin high and gpioset gpiochip4 21=0 to set it low, and that works. (The '21' refers to gpio21 which is pin no. 40).

As a side note, typing gpioinfo gives details of five 'chips' - gpiochip0 to gpiochip4 - and it this last one that controls the 40 pins on the header. That's about as far as I can get.