GPIO callback on rising signal

Hi to all,
I’m new with RISCOS and I’ve installed it on my RasPI3 a week ago.
My intent is to build a simple callback routine (BASIC Assembly) that rises when a signal
present on a GPIO change state from 0→1 (rising edge).
How can do this ? I’m using the default GPIO module present inside the RISCOS distribution.

Which is the max rate that the signal may have (10 us, 200us, 1ms) ?
Thanks in Advance

HELP ME :)

Sorry I mean the MIN rate …

The GPIO module will allow you set an event, triggered by a rising edge on a GPIO pin, so you don’t have to be specifically looking at that pin when it goes high, but next time you look it will tell you there was an event. You’d need to keep looping around to check if the event had occurred, and then clear it ready for the next. Unfortunately the documentation for the module is very ropey and parts of it are incorrect as it still refers to a now-superceded version and so isn’t that useful at all :(

I can’t help with the max/min rate question, I’m afraid.

Hi Andrew,
many thanks for your reply, so can’t you show me a little snippet code with the right GPIO function ?
Just to see the right parameters to pass at the function.

Best Regards

This is a cut-down version of the code I’m using. Going against the recent flow on here, I’m using meaningful variable names and nicely formatted code that can hopefully be understood. (Proper programmers should look away now.)

REM To detect a rising edge event on GPIO 14 (pin 8)

REM Set GPIO 14 as input
SYS "GPIO_WriteOE",14,1

REM Read mode info for GPIO 14
REM mode info held in bits 0-4
SYS "GPIO_ReadMode",14 TO mode%

REM Set GPIO 14 as:
REM     pull enable    (bit 5)
REM     pull type=up   (bit 6)
REM     enable events  (bit 7)
REM     a rising event (bit 8)
REM     an edge event  (bit 9)
mode%  = mode% OR %1111100000
SYS "GPIO_WriteMode",14,mode%

REM Clear any event on GPIO 14
SYS "GPIO_WriteEvent",14,0

REPEAT
  SYS "GPIO_ReadEvent",14 TO event%
  REM event%=1 if event detected
  IF event% = 1 THEN
    REM clear event flag
    SYS "GPIO_WriteEvent",14,0
    REM Now do something with the knowledge an event occurred
    PROCdo_somesomething
  ENDIF
UNTIL FALSE

I hope this is helpful.

Hi Andrew,
I tried your code and it works fine … but I think my signal on GPIO is too fast.

The scenario is: the signal with a period of 160 micro sec and the RasPI that must
detects the rising edge every 160 micro sec; then it must do some little processing and
detect the next rising edge.

I thought RiscOS was more reactants of Raspian (minor latency) … I saw that the code
side RasPI sometime losses some rising edge …

Thanks
Leonardo

160us is a bit tight to do anything really. You can shave a few microseconds off by using the SWI number rather than the name. A quick test (with TimerMod) using GPIO_ReadEvent suggests the named SWI takes approx 25us to execute whereas the numbered SWI takes around 2us to execute. This might save you a bit of time, depends what else you need to do in terms of “some little processing”.

To respond reliably every 160 microseconds is a very hard real time requirement. It’s not the sort of thing that a desktop operating system can be expected to do. It’s the province of a Real Time Operating System.

What is the consequence of failing to see an edge? And how quickly must the response be completed? Is it OK to queue a number of edges and respond to all of them a bit later? If so, you might be able to add a bit of external hardware – perhaps as simple as a counter.

If you must infallibly get a response every 160 us, within 160 us, then RISC OS, Raspbian and most other OS’s are not appropriate choices. Look for an RTOS, or use dedicated hardware.

160µs works out to be 6250Hz. The theoretical read maximum of the GPIO pins are in the 10MHz bracket, however to get any sort of reliable behaviour you’re going to need to use assembler.
Does your GPIO pin generate interrupts? If it does, that might be an avenue to consider; but if it is unreliable (you’ll have interrupts, but so will everything else) then you may need to switch interrupts off and just sit on the hardware reading it directly (effectively stalling the entire OS and doing it bare metal).
If your Pi is clocking 800MHz, then I calculate¹ that you ought to have 128,000 CPU ticks² per 160µs event. That’s not out of the realms of possibility, but it precludes the use of BASIC and any sort of multitasking. Having said that, the big question is what you plan to do with each event.

¹ Disclaimer: I’m famously crap at maths. Wait for Dave or Jeffrey to point out that I’m an order of magnitude wrong…

² Converting ticks to instructions is hard with dual issue, out of order execution, some instructions taking longer than others (AND is quick, LDM less so), and stalls due to cache misses… That said, 128Kticks is a lot to work with unless you need to do heavy crunching every event.

suggests the named SWI takes approx 25us to execute

On what? If my figures above are correct, then the 23us extra for the named SWI lookup implies that it’s taking a little over eighteen thousand processor ticks (on an 800MHz processor). That seems like a lot just to look up a SWI by name.

I’m certainly not claiming a rigorous scientific study here.
On my Pi Zero, I simply set a FOR…NEXT loop going to call the SWI 10000 times, using TimerMod to get the time to the microsecond before and after the loop. I subtracted one from the other and divided by 10000 to get a time per loop. With the SWI name, it took approx 25us per loop, and with the SWI as a variable or a number it took approx 1.5us per loop.
I’m sure lots of other things come in to play that I haven’t accounted for, but it gives a rough idea that using SWI numbers is faster than SWI names.

That seems like a lot just to look up a SWI by name.

There’s a lot of SWIs and there’s no clever hashing – it’s not meant to be fast.

Hi to all,
I’m very happy to read all this replies :). I’ll try to answer to everybody.
First of all I’m using a RasPI 3 (1.2Ghz, B model) and I wrote the code in Assembly.

It’s interesting to know that if I use a number instead of a string with a SWI call, I can
gain about 25us .. I’ll do a test and I’ll let you know.
With “little processing” I mean that the code must calculates a 16bit address and an 8bit
word, by a SPI-like protocol (SCLK runs to 160us).

I can’t loss a single rising edge: i’m implementing an FPGA’s “simple CPU” and I want use
RasPI to test it, so for each SCLK I must send/receive the 8bit word.
Currently I’m using an external HW (Arduino) and I must say that it works fine (160us works
fine and 50us too!). It’s natural, Arduino is a dedicated microcontroller …

I made many tests with Raspian (without/with RealTime patch). On my experience side, without
the patch it works only with 200us (with a driver in kernel space) though it’s not 100% reliable.
With the RT patch the limit is 160us but it’s less reliable …

Many thanks to all
Leonardo

It’s interesting to know that if I use a number instead of a string with a SWI call

SWI name/number only had relevance to BASIC’s SYS command. Everything else expects a number to be embedded in the SWI (by whatever mechanism suits the language).

The next questions: can a GPIO pin generate an interrupt (quite likely yes) and how is that interrupt presented to RISC OS (that’ll be the harder part)?

Hi Rick,
you’re right I got a misunderstand … Andrew rightly meant BASIC but I wrote my code
in Assembly and a SWI call uses number :), so I can’t improve the performances “easily”.

I wrote my code in Assembly

I thought you said earlier that you were using the BASIC assemler?

Usually, in a BASIC program which includes assembler, the BASIC assembler source is only executed twice (for the two passes normally required). This is when any SWI names are converted to a number.

Once assembled, the assembled code is usually called once (but may be many times), and some of the instructions may be execucuted many thousands or milllions of times (depending how the code branches and loops). Any SWIs executed will be using the assembled ARM instructions which include the number as part of the instruction word. No further name lookups are required.

Any normal BASIC using SYS calls needs any names converting to numbers by BASIC every time they are executed.