Lua Pi Question - Timers

I can’t find this info quickly, so I thought I’d ask the gurus:

Can the RISC OS – Raspberry Pi – Lua combination achieve finer timing graduations than using BBC Basic?

I understand BASIC reasonably well, but have never learned any other programming languages.

My application is a program to run music sequencers. These accept a clock pulse and step through preset musical notes. The clock pulse comes from a master clock, running at about 200 pulses per minute. The program needs to output multiple duplicates of the clock pulse to defined GPIO pins, within 10ms jitter or less. The output pulses need to be delayed under program control.

I have written this program on GW-Basic running on an old PC, and GW-Basic can provide timing functions (Fasttimer) that meet the criteria, but PCs are big, heavy, and need monitors. I’d love to be able to run an equivalent on a Pi. I have written a version using BBC on a Pi Zero, but can’t get below the 10ms threshold using Timer. I can do it using a dummy FOR – NEXT loop, but it’s not very clean and it’s hard to change the timing on the fly.

So:
Does BBC have any functions to improve the Timer accuracy better than 10ms?
Does Lua offer a better timer function? which would mean I need to learn Luca, I just don’t want to put in the effort unless it’s a viable use of my time.

I’ve been told to learn Lua as being a relatively easy jump from Basic?

Thanks for any and all suggestions

Lua is written in C99 ANSI C, but can be compiled with different sorts of integers and/or floating point numbers to suit the platform. For RISC OS everything depends on the platform. For the oldies, Iyonix, RiscPC and earlier, there is no floating point support in hardware. For them RiscLua tends to have 32-bit numbers. For the newer platforms there is VFP. For them RiscLua has 64-bit numbers, whether integers or floating point. The standard Lua function os.clock() returns in seconds the time since the program started, as a floating point number. I think 64-bits gives higher precision than BBC BASIC, but I am not completely sure. Maybe it depends on which BASIC.

Lua has functions os.clock(), os.time(), os.difftime(). I think os.clock() is the one you are after.

I’ve been told to learn Lua as being a relatively easy jump from Basic?

This is a drum I have been beating for nearly two decades :). Go on. You will love it.

Alas, lua’s os.clock has a CLOCKS_PER_SEC granularity, which is 100Hz.

RISC OS isn’t a realtime system; background processes could still interfere if you try to create delays using loops in the foreground task.

As others have said, you can use os.clock.

Does Lua offer a better timer function? which would mean I need to learn Luca, I just don’t want to put in the effort unless it’s a viable use of my time.

They both supports the timers offered by the OS. They both could be extended. To extend both beyond the possibilities offered by the languages themselves, you’ll need to learn more complex languages (ARM Assembly to extend BBC BASIC and C or C++ to extend Lua).

I’ve been told to learn Lua as being a relatively easy jump from Basic?

Yes, Lua is fundamentally a modern form of “BASIC”. It has a lot of advantages over traditional BASIC, for example Lua has a much more cleaner semantics, so it’s more easy to read and has a much better way of handling libraries as well as a more advanced and powerful procedural paradigm. So, learning Lua from BASIC is definitely not a waste of time and it’s very easy.

My application is a program to run music sequencers.

On the matter of the specific software you are porting/writing for RISC OS. Is it a single task program? In other words does it runs without the WIMP (Window Manager)?

If so, you should be ok, but if you are writing an application that has to run in multi-tasking, RISC OS can be hard to program when the application is time sensitive. So, in that case, I would start from something simpler than a music sequencer.

Music software is generally highly sensitive to timing and, in a cooperative multi-tasking OS, there is not warrantee of when your application will get back control. As Stuart has mentioned, it depends by what the other apps are doing and if there is any I/O going on.

Hope this helps, good luck! :)

I’ve cobbled together two version of my software.

Second version is run on an Arduino. Nice tight timing, cheap, small, but the user interface is a 16×2 LCD and has minimal control input capabilities. I’m using four analog inputs with pots to adjust timing. Arduino can’t support USB keyboards, so I can’t just punch in keystrokes to make changes. Arduino is physically small, accurate, but too fussy to be useable. Changing the software is a real pain.

I kind of think RISC OS / Pi Zero could meet all the criteria – fast, cheap, small, easy to interface to real-world using GPIO, accepts USB keyboard input, can be programmed in a language I understand (or can muddle through well enough to write what I want). The Pi Zero is small enough to fit inside a 7” LCD monitor, so no big bulky PC & monitor. And when I muck up the wiring and fry a Zero I can get another one for $19

The sequencer program will be the only thing running, when I’m using the sequencers nothing else is needed.

Have you looked at druck’s TimerMod ?

I used it to provide a TIMER keyword and TRACE timing in Basalt with microsecond precision.

@Gavin – is your copy of the RISC OS lua source modified from the upstream version with RISC OS-specifics? If so, we could easily modify its os.clock() routine to support druck’s TimerMod if that module is loaded, falling back to the current method if not.

@Stuart I have just put a link from my RiscLua page to instructions on how to build RiscLua for yourself. I wrote these originally for RiscLua 600 but they are now updated to the current version.

In summary, access to RISC OS (SWI calls) is provided by the riscos library, which is now dynamically loaded. The lua binary sources are only modified from the standard ones so that

1. ?, !, $ can be used for peeking and poking, following BBC BASIC [lctype.c].
2. Lexical changes and syntactic sugar [llex.c]
3. local vars in table [lparser.c]
4. Update operators ( e.g. x += expr ) [lparser.c]

So the RiscLua binary understands plain Lua, but also has these extra features. See the DIY instructions for the full details. We can probably package Druck’s TimerMod as a dynamically loadable module that overrides os.clock(), so lua need not be touched. No need to modify anything.

Thanks Gavin – I shall take a look!

Not much difference between the two. If I RMLoad TimerMod and then run this RiscLua program in a taskwindow

local sys in require "riscos"
f = \ ( ) end  -- do nowt
local clock in os
sys (0x490c0) -- Timer_Start
local t1 = clock ( )
for i = 1,100000000 do -- one hundred million
    f ( )
end -- for
local t2 = clock ( )
local r0, r1 = sys (0x490c1) -- Timer_Stop
print ("TimerMod: ",r0 + r1/1000000, "os.clock: ",t2 - t1)

TimerMod:       7.69518 os.clock:       7.6900000000001

That is on an Rpi4 with RO5.28. You can see that TimerMod gives more millisecond detail.

My previous remarks about packaging TimerMod were nonsense. As it is a relocatable module nothing further is required, as you see from the example use.

Not much difference between the two

That’s good!

The increased precision though should allow for (sub-10ms) timing that’s needed for applications like sequencers.

@ Stuart

Thanks Gavin – I shall take a look!

Can we share the changes on github? I have already added the RiscPkg packaging to RiscLua and also working on some extensions library for GPIO access and git support.

If it’s ok for Gavin, I’ll upload the sources to GitHub.

P.S. also working on changes to make it work fine when Iris is installed, just got latest Iris updates and testing

I’m not sure I understand exactly what is needed, 200 pulses per minute is one every 3cs, which the OS timer should be able to do. If you wanted one every 3ms or 300us, then you could sit in a polling loop reading TimerMod’s microsecond clock value.

@ Sheldon

The sequencer program will be the only thing running, when I’m using the sequencers nothing else is needed.

Ok then you’re totally fine.

I’m not sure I understand exactly what is needed, 200 pulses per minute is one every 3cs, which the OS timer should be able to do. If you wanted one every 3ms or 300us, then you could sit in a polling loop reading TimerMod’s microsecond clock value.

I think that he’s trying to introduce different millisecond-ish delays between the various outputs, and that if it’s just one in a net of sequencers, it might be important to read the input pulses faster than cs to achieve overall synchronisation.

If it’s ok for Gavin, I’ll upload the sources to GitHub.

Sure. I do not know how old Paolo is, but I am pretty sure he is a lot younger than me. As I may have hinted before, I am very pleased to leave such burdens to younger and more competent hands.

It doesn’t matter how old we are; we could all go under a bus! And where would valuable stuff be then…

It doesn’t matter how old we are; we could all go under a bus! And where would valuable stuff be then…

Yup!

Sure.

Thanks Gavin, uploading sources after Doctor Who new episode is over :)

Ok, all done.

https://github.com/RISC-OS-Community/RiscLua

Tomorrow I’ll start re-organising the sources as per our standards there (so github will also syntax colouring the sources), and run few build tests.

Thanks a lot Gavin and looking forward to work together to make Lua even better on RISC OS :)