Pull-ups on Raspberry Pi 3B+

One other thing on testing. All the GPIO lines that are brought out to the expansion connector are in the first 32. The reduced schematic doesn’t give any clue as to the possibility that GPIO lines in the next bank might be brought out to another connector. This means that I can’t verify that the second pull up/down clock enable register is being correctly addressed. If anyone has any extra knowledge, I’d appreciate it being shared with me.

It’s unlikely to be of much importance to us, of course, but I’d like to be thorough if I can.

Why not set the pull up (or down) and then read the input status? You don’t need access to the pin.

What happens now? Who’s going to review the fix and check it in?

You can submit it yourself if you have a ROOL GitLab account, though it must be said that learning to use git could be the thing that tips you over the edge. For a 1 or 2 line change it might be quicker to email it in: the address is the same since ROOL was founded 14 years ago.

The reduced schematic doesn’t give any clue as to the possibility that GPIO lines in the next bank might be brought out to another connector.

It will be no use to you, but they are available on the Compute Module. If you happened to have a CM development board and a means to put RISC OS on a CM ¹, then you could test them, but Chris’s idea is easier. ;-)

¹ How to do that had me stumped, even if it is possible. ;-(

For a 1 or 2 line change it might be quicker to email it in

Can you just edit the file in GitLab website. I note files have an edit option and clicking on it shows that you can create a merge request from the changed file. Does this work? Never tried it myself.

and a means to put RISC OS on a CM

It is a two step process. First you download some software that presents the internal eMMC as a USB mass storage drive and then you just write an image to it as you would an SD card. You need the development board to do this.

I’ve covered both bases: I’ve applied for a ROOL GitLab account, and I’ve sent a diffs file to code@. Now I just have to wait. And so does anyone else who wants to use pull-ups on a Raspberry Pi.

And so does anyone else who wants to use pull-ups on a Raspberry Pi.

Certainly my current project is now on hold until this bug fix gets incorporated into the daily download. It also explains why I’ve had all sorts of previous issues on earlier projects!

I’ve been granted a GitLab account, and I think I’ve submitted a merge request.

You need to set the Assignee on the merge request form to ‘ROOL’ when you’ve done that ROOL appears as the assignee in the list at the right of the screen when you are looking at your merge request. Presumably that informs them of the request.

Ah. I must look very carefully if I do this again.

Well, I have replaced my earlier merge request with a new one, because Sprow pointed out that I’d only fixed the error in one of two places. Unfortunately I didn’t read your message until after I’d deleted my old branch and submitted the new merge request – which still has 0 assignees of course, now I know what to look for. There doesn’t seem to be a way to add an assignee to an existing merge request.

Bugger.

If I have to do this sort of thing again, I’ll know what to look for – that’s assuming I still remember…

I have emailed code@ again anyway, so let’s hope that has the desired effect.

Well, I have replaced my earlier merge request with a new one, because Sprow pointed out that I’d only fixed the error in one of two places.

Note that you can update existing merge requests with new changes. Merge requests are based on branches, so any update you push to your branch will automatically be reflected in the merge request.

There doesn’t seem to be a way to add an assignee to an existing merge request.

Yeah, you need the “developer” permission on the target project/group in order to set/change the assignee. ROOL should grant you that permission (although I’m not sure if they do this automatically or whether you need to explicitly ask for it)

Really gitlab should add support for a default assignee – “developer” access gives people access to a bunch of other stuff that they probably shouldn’t have access to (e.g. the ability to edit other people’s merge requests on the project)

Sprow pointed out that I’d only fixed the error in one of two places.

I was going to post that earlier, but thought you must have seen it. Sorry. ;-)

I’ve been granted a GitLab account,

So have I, but I cannot see myself going anywhere with it. If I do I will come to you for help. ;-)

It is a two step process [put RISC OS on a CM]

I got that, but failed to make it work a few years back. I think there is something missing in my experience that is assumed in instructions for a lot of things like this. ;-(

I just used the instructions as given up to the point where the CM plus dev board is plugged into a Windows machine and appears as a mass storage device. So far no RISC OS involvement. I then used Win32DiscImager to write the 2Gbytes RCxx SD card image. I could then see the FAT partition on the mass storage device (CM+Dev board) just as if I had been writing to an SD card. Then replace (or remove) the link that tells it to boot via the USB socket and an external source and RISC OS starts up.

The fix for pullup/pulldown control is in today’s nightly build.

Follow up to this, is anyone currently working on the Pi4 GPIO? The BCM2711 appears to set pull up/down resistors in a different (and nicer) way to previous versions of the Pi, meaning that, as far as I can see, we can’t currently set them from RISC OS.
It looks like The BCM2711 has individual registers for each GPIO so you can read/write the resistor state for each GPIO easily without having to remember the previous state or “waiting 150 clock cycles” as before.

Edit to add: Tested setting pull-ups on a Pi3 and Pi4, it now works on the Pi3 but doesn’t work on the Pi 4, so definitely needs fixing.

The BCM2711 appears to set pull up/down resistors in a different (and nicer) way to previous versions of the Pi

As I observed above:

• There is no BCM2838; it is BCM2711.
• There are 57 GPIO lines rather than 54
• The lines are split into 3 banks not 2
• The distribution of lines differs from BCM2835
• PullUp/Down does not require the clock rigmarole
• PullUpDown state can be read

So there are also the second, third and fourth items to consider, as well.

we can’t currently set them from RISC OS.

Well, not using the GPIO module. ;-)