Newbie plea: Pico and GPIO on Pi

Hello all

I have downloaded RC5 RISC OS Pico and am presently running it on a Pi Zero W I had to hand. Great.

Can anyone point me towards how to access the GPIO on the Zero (or any other supported Pi)? Specifically, I need to read 8-bit parallel data and probably read and write a couple more status lines connected to the Pi port.

Why? Well, I am considering building a one-off interface to a vintage thermal camera (more info is here: https://tinyurl.com/G1MFG-Agema-870 , which links to a groups.io post discussing the analogue to digital hardware). Something like a Pi would probably provide enough processing power to do what I need – and using Pico means I am (a) able to program in BASIC, which I can do, and (b) I don’t have to mess around with Linux, of which I have a largely-irrational – but strong – dislike.

I really just need a pointer to a command, or details of where I can find info on what memory locations to PEEK and POKE, or the location of (and how to install) an extension (if such is necessary). Building the rest of the software should be easy and I’m comfy with the principles, or at least how to find the info I need.

Please treat me gently. I’m new to this, though I go back a long way (I had a ZX81 then a BBC Micro first time round). One reason I have a problem with Linux is gurus’ tendency to say things like “it’s easy – you just have to pseudo the libraries and stack them in Reverse Polish, YOU WORTHLESS NOOB UNFIT TO WORSHIP MY FEET”. You know what I mean!

Thanks again,

Giles

Can anyone point me towards how to access the GPIO on the Zero (or any other supported Pi)?

“PiLED”, one of the example programs supplied with RC5 Pico, shows how to bit-bash a GPIO pin. That introduces you to three of the commands – known as SWIs – available for GPIO use (there are something like 20 GPIO SWIs in all).

A full list of GPIO SWIs can be found in the “GPIOManual” package available here.

Please note that the manual is in StrongHelp format, which you won’t be able to read on Pico. I suggest you install either RISC OS Pi or RISC OS Direct – either of those would be able to read the manual, and would provide a better development environment. Once you’ve written your program, you can transfer it back to Pico if you wish.

“it’s easy – you just have to pseudo the libraries and stack them in Reverse Polish, YOU WORTHLESS NOOB UNFIT TO WORSHIP MY FEET”. You know what I mean!

Somewhere on StackExchange there is semi-working (and completely unreadable) Perl code to pseudo all of your libraries and stack them in reverse polish…

:-)

I second the suggestion of installing RISC OS Pi or Direct but you might also want to check out Andrew Conroy’s website He has a couple of nice BBC BASIC libraries, including one for ModMyPi’s JAM HAT, that might be interesting or help you get started with GPIO access from BASIC.

Thanks to everyone who has replied. I will follow up on the suggestions – this is exactly the level of assistance I was hoping for so I am extremely grateful.

As an aside, via a different, unrelated forum, someone has provided me with the maintenance manual of an original 1980s vintage accessory that did (mainly in hardware) what I plan to do mainly in software. The important thing is that it includes circuit diagrams and connector pin numbers, greatly simplifying my task of reverse-engineering. It’s not worth trying to re-create the original hardware (for instance it used 2k x 8 memory chips and only stored one of four fields making a frame) – but all the control signals are highly relevant and useful.

One further question, then – assuming I manage to get this project going without further need for steers, is there any interest here in seeing what becomes of it, and where would be appropriate to post any results?

is there any interest here in seeing what becomes of it

Yes :)

Hmmm. I’ve done some detailed playing and I’ve run into severe speed problems with

SYS “GPIO_ReadData”,pin TO variable

First, the SYS call is very slow (for what I need). I believe there’s a way of using a different call along the lines of

SYS&58F81,24,1

(which I think is a write, not a read, but it’s the principle I’m looking at).

Trouble is, I can’t find a cross reference between SYS “GPIO_whatever” and SYS&somewhere – the Wiki is silent (beyond making it clear in bright grey that someone really ought to write this up)

Does such a list exist, and can someone point me to it please? I have looked, without success.

Secondly, is there a fast way of reading the state of more than one pin at once? I really need to read an 8-bit value from an ADC (at about 500kHz!) and with the best will in the world, reading a bit at a time will be too slow.

I have looked at *GPIODevices
which seems to return the state of all pins (as text, with extra text) but I haven’t yet investigated it any further because I suspect the overhead of turning the text into a value would be prohibitive.

So,
- has anyone seen any code that lets one access GPIO pins in a way comparable to the old Beeb’s parallel User Port?
- is there a way of reading several (8) GPIO pins simultaneously?
- is there a cross-reference between SYS “instruction” and the equivalent SYS&address?

Oh, and a coffee would be nice. NATO standard, thanks.

I cannot help with GPIO itself, but there are SWIs OS_SWINumberFromString and OS_SWINumberToString which can do conversions between any SWI number and their textual names. Using the name is slightly slower than using the number – because it has to do the conversion first. For highly used speed critical SWIs it can help to do the conversion once at the start of a program, and then use a variable with the numeric value.

SWI &58F81 is indeed “GPIO_WriteData”

Note also that ‘pin’ and ‘variable’ are floating point variables, which are slightly slower than integer variables, so it is best to add % to most numeric variable names. Resident integers (A% to Z%) are slightly faster again. And a integer variable may be faster than a constant (which has to be evaluated each time it is executed).

You can get the GPIO SWI numbers from the GPIO StrongHelp manual (search “GPIO_” for a list).

If the GPIO module is loaded, you can also get the number from BASIC, for example

SYS “OS_SWINumberFromString”,,“GPIO_ReadData” TO A%: PRINT STR$~A%

(https://www.riscosopen.org/wiki/documentation/show/OS_SWINumberFromString)

Thank you both – that looks promising.

@Martin – I was aware of % for integers (and that they’re faster than floating point) and I was also aware of special status of A% to Z% but I didn’t know that these were (even marginally) faster than other integers. I might have figured that I_am_an_integer_variable% would be slower than Me2% if only because it’s a few more characters to interpret each time, but not that A% would be faster still – thanks. And it would definitely not have occurred to me to compare the speeds of SYSA% and SYS&xxxx.

@Julie – many thanks to you too; I wouldn’t have guessed that there was a function for that!

Right, back to the coding keyboard for a while.

I might have figured that I_am_an_integer_variable% would be slower than Me2% if only because it’s a few more characters to interpret each time.

I’m not convinced that’s worth obfuscating your code for, though. :-)

If you’re hunting for speed, also remember that BASIC looks up PROCs, FNs and variables using linked lists for each initial letter (so A-Z, a-z, _, and `). This means that if you name your routines using the fairly standard practice of codeblock_and_purpose%, you’re going to be concentrating the names into a few longer lists.

Again, I’m not convinced that making the code harder to read is worth the speed gain on modern hardware, but using the_only_variable_starting_with_t% might make things quicker in some really obscure cases.

If this really matters, could I encourage you to ignore it when writing your code, then pass the BASIC source through one of those utilities which will reduce all of the names down to the minimum length possible and use all of the available namespace? I believe that Crunchie might be one option.

“Fast” BASIC is very hard to maintain.

Edit: Thank You, Textile!

How fast do you need to go, Giles? On a Pi 2, Basic can drive the GPIOs at up to 20MHz.
That’s not a great deal of use as the outputs will be slurred and distorted by noise etc due to poor tracking, lack of shielding, long loose or bare wires etc. 4-5MHz is probably a useable limit.
Of course, a Pi3 or Pi4 will run even quicker, but the signal distortion limitations will be the same.

To run the GPIOs at max speed with Basic you’ll need to bit-bang them direct, using Basic’s in-line assembler – that’s how I managed 20MHz a few years back.

I’m not convinced that’s worth obfuscating your code for, though. :-)

+1

Here are a couple of other reasons not to.

First, ARM BASIC uses something that was called Synergistic Cache Technology by the author, Sophie Wilson. This means that direct pointers to variable values and routines (PROC/FN) are cached, and do not have to be looked up each time they occur at the same location in a program. The cache is a fixed size and sometimes the information is overwritten, triggering a lookup in the linked lists, but for shortish loops it should make the length of names almost irrelevant.

Second, BASIC now implements a last found to first position for variable names. That means that commonly used variables migrate to the front of the linked lists and are looked up more quickly.

A further word on the resident integers, A% to Z%. On the BBC Micro these were very much quicker than other integers, but the advantage in RISC OS is tiny and speed should not be a consideration in using them.

I believe that Crunchie might be one option.

As the author, I can confirm that it uses the namespace evenly. ;-)

Edit: Crunchie also substitutes numbers for SWI names for you. Many BASIC applications doing only that were written early in the life of RISC OS and will still work.

Thanks Steve, Neil and Steve

How fast do I need to go? Well, I’m hoping to frame-grab a peculiar video standard from a 1980s thermal camera, which needs sampling to 8 bits at somewhere in the region of 500k to 1m times per second.

So, “fast”!

The ADC hardware is fairly easy.

Yes, I know that BASIC isn’t the best approach and an interrupt-driven piece of assembler would be the way to go. But I also know that the BASIC that comes with RiscOS Pico is pretty speedy and can execute at 20 million lines per second (or so, depending on the length of your particular piece of measuring string).

And, I can write BASIC. I’ve used it in all kinds of applications, including bit-banging a 16MHz PIC micro to provide an onscreen display for a video monitor, programming synthesisers and various other applications, some of which helped pay the mortgage. But I digress.

I am perfectly prepared to accept that a Pi 3 running (any kind of) BASIC isn’t going to be fast enough. In which case I will probably abandon the project, because the alternative (building a more complex ADC subsystem with memory that can be read out in slow-time) is probably more effort than the old camera is worth. Again, take a look at https://tinyurl.com/G1MFG-Agema-870 for some background info and https://www.eevblog.com/forum/thermal-imaging/the-big-lens-finally-shines/ for pictures of the images it can make. I have other thermal cameras that are decades more modern, much higher resolution and a fraction of the size & weight. But hey, if I can get the old beastie talking to something other than a glorified oscilloscope, I’ll feel I’ve achieved something! Even if the code isn’t maintainable.

Just re-reading Steve F’s post. I plan to try getting the software into some kind of shape and to optimise it before starting to work on hardware – largely because if it’s clear I can’t get the speed I need I’ll have to rethink. One possibility might be a big fat FIFO between the ADC and processor – for instance the 72V05L15JG is an incredibly easy to use 8k word x 9 bit FIFO that would hold ‘enough’ to buffer the fast ADC into the slower Pi. Farnell have them for about £15 and the PLCC package with 1.27mm pitch pins means breadboarding would be ‘easy’ (compared to BGA packages!)

The ADC hardware is fairly easy.

Too many variables (background interrupts etc) will make that a bit of a nightmare to do directly in real-time. Better to sample into a cache memory device
and then read the data out at your leisure.