Accessing Beagle XM I/O expansion pins from Basic

I thought I’d better remove the LCD connector SWI’s as they kill the display !!
If we ever get the S-Video output working, they can be added again…

Tank, just looking through your source from GPIO v0.15 which I downloaded last night.

Your LCD interface list (table 6) shows 30 LCD GPIOs as available. I can only see 27 on the charts in the SRM. You have GPIOs 80, 184 and 187 listed as available on the LCD but there’s no sign of them in my docs.

Could it be that one of these ‘extras’ is mapping to pin 18 on the P11 LCD interface – it’s marked as GPIO 170, which enables/disables the DVI-D chip and might account for the display kill that you are seeing.

Those three extra GPIOs must be hitting pins on the LCD interface somewhere – chances are one of them must be messing with pin 18.

I was playing with some LEDs on the LCD interface a couple of nights ago using bodged up individual register write routines and I don’t remember having any display issues, so I was surprised to see your note above.

Page 110 of the SRM shows the GPIO mux for the LCD . It does not list the two I2C3 registers in the mux 4 column. Also DVI_Data10 is actually GPIO_80. GPIO_79 is listed twice!
The PUP signal is controlled by GPIO_129 on the SRM-A2-01 document.
Unless you know something more, I believe the LCD connector and the DVI controller share signals. Maybe Jeffrey knows more ?

Unless you know something more, I believe the LCD connector and the DVI controller share signals. Maybe Jeffrey knows more ?

Yes, the OMAP only outputs the one digital video signal, which gets sent to both the DVI & LCD connectors. So you wouldn’t be able to change the pin mux settings for the LCD pins without affecting the DVI output.

If we ever get the S-Video output working, they can be added again…

If you can live with the fact that it doesn’t make much of an attempt to fit the image to the screen, then you should be able to get NTSC S-Video output working with the following:

*tvout 0 1 0
*tvmode 1
*wimpmode 28

Note that so far I’ve been unable to get PAL output working properly, and if you use 16bpp/32bpp screen modes then the red & blue channels will be swapped. See the wiki page for a bit more info. If you think you’ll find S-Video output useful then let me know and I can have a go at polishing it up a bit.

Also, for the IIC port on the expansion header – assuming the pin mux settings are set correctly, you should be able to access them using the revised OS_IICOp interface, by specifying the bus number in the top byte of R1. Since RISC OS numbers them from zero, I2C2 would be bus 1, and I2C3 (for the DVI/LCD connector) would be bus 2.

Darn. I must have remembered flashing LEDs on the Aux rather than the LCD connector. I was playing with both at the time, as well as trying to debug my register access routine. I should have studied the schematics in the SRM, then I would have seen it wasn’t worth bothering with the LCD interface. Sorry for giving you a bad steer on that one Tank.

Oh well, looks like my robots will have to make do with the camera connector as a sort of runner’s up prize ;-)

Dont forget, with a little external logic and latches, you can have almost limitless IO capabilities (Remember Jim, Fred and Sheila on the Beeb?).
Just use say 8 GPIO’s as address lines and another two as R/W and a latch enable, and you have got (with a total of 49 GPIO’s available (not counting the I2C interfaces)) 39 wide x 256 addresses. (How many do you need Neil LOL).
Obviously this takes a little more programming, but as you may not need a lot of speed it would be fine.

Talking of speed, I ran a little Basic prog to test the free-running GPIO bit-cycling speed, using GPIO149 (LED0) as a guinea pig test bit. Max toggle rate seems to be about 290kHz on my rev. A2 board. Not bad, but not quite as quick as I’d hoped it would be. (The GPIO module is obviously going to be a fair bit slower with all the extra ops involved – around 46kHz).

Also, to achieve maximum speed for a typical 8-bit GPIO port, all 8 chosen bit lines will need to be in the same GPIO module group, otherwise up to 6 separate operations could be needed for each read or write cycle and port speed would plummet accordingly.

More crucially though, and regardless of speed, all 8 chosen GPIO lines will need to be in the same module group so that their individual states can be read or written at the same instant, i.e. with a single register op. Otherwise extra hardware buffering and latching of the output will be required for any critical applications.

Further to my quest to become a GPIO speed freak, I’ve now managed to squeeze 938kHz continuous read speed and 560kHz write speed out of my XM board, calling assembler LDR/STR fragments from Basic. This is much more respectable timing than my previous effort. Of course, there’s likely to be a slow down once coding to actually use the data is added, but at least it gives some ultimate, perfect-world start point.

I would think that really speed critical applications could read/write in bursts to/from buffers and process at leisure later, so those max speeds might be close to achievable in some cases.

Have you considered using any of the other hardware? E.g. I2C, I2S, the UARTs, McBSP, etc. They’re probably a better choice if you want high-speed reliable data transfer. Of course it would require you to have suitable hardware on the receiving end, which may be outside the scope of your project.

Neil, this is a little off topic but do you know whether Rob Ward is running RISC OS on any new hardware? (links to Robotics Pages at the bottom of his blog post there)

Neil, a couple of test results from my Beagle running at 800Mhz.
All calling the module SWI’s toggling the output.

Simple Basic loop running in a task window using 32 bit wide writes (new in the latest module !!) 81Khz-89Khz
Simple Basic loop running in a task window using bit wide writes 61Khz-70Khz
Assembler Wimp program using 32 bit writes every wimp poll 168Khz-174Khz
Assembler Wimp program using bit writes every wimp poll 742Khz-1013Khz

Why the bit wide writes from assembler are so much faster is a bit of a mystery…
Frequencies measured with a Intronix LogicPort logic analyser.
P.S I’ve tested the Expansion port, driving 3 UDN2981A-T LED/Relay driver IC’s (they seem to work without level shifting the 1.8v outputs) driving LED’s.
Latest module from here

Did you run those tests with or without the Portable module loaded? Remember that if the Wimp thinks the machine is idle (I think it goes by the number of idle polls per second) then it will try to reduce power consumption by using a combination of reducing the CPU speed and wait-for-interrupt.

I can’t say I know what Rob is up to, Trevor. His RISC OS page is dated 2008, so anything could have happened since then. His robotics pages feature Arm Basic code fragments though, so I guess he still feels at home in that medium.

OK, Tank, here’s my ‘screaming’ version :)

4.75MHz continuous read speed, 2.42MHz continous write speed. That’s reading/storing or writing (toggling) a GPIO line for 1 second via an assembler loop called from Basic (single tasking).

I RMkilled the Portable module beforehand but it only gave a marginal speed up.

That’s a x5 speed up on my previous test, so I’d expect the same increase when inserting the GPIO module SWIs in the loop in place of my LDR/STR pairs (haven’t tested the latest version yet).

Jeffrey, with the Portable module, after a few seconds the wimp program results will slow down (by a factor of about 10). The Basic loops do not suffer this.
In normal running, as Neil said, only a small difference is made.

A bigger difference is made if other apps are running at the same time.

Also, Neil, can you try your test when the other GPIO lines, in the same physical group, are set as output and high out, as that seems to make the difference between my bit wide and 32 bit wide results. It’s almost as if the system polls the high level outputs, so slowing down individual opps.

A bit of tweaking to the module and my results are
86Khz-96Khz
408Khz-431Khz
198Khz-210Khz
655Khz-670Khz
Same tests as before.
The second measurement may be higher because the other outputs were set low.
The last measurement seems more in-keeping with the other tests than my previous results (which is a shame!!).

If you don’t mind sending me your test prog, I’ll compare on my board.

Some more strange results…
Writing a couple of assembler write routines in Basic and then calling them from a Basic loop, I get a bit wide result of 760Khz and a 32 bit wide write of 4953Khz….(Yes 5Mhz)
Then making the assembler loop itself (Needs Alt Brk to quit) the results are the same for bit wide and for 32 wide 7740Khz !!!(7Mhz)

Slowing the board clock speed down to 600Mhz makes no little or no difference to the readings.

Here’s the Basic prog I’m using to test rough burst speeds, Tank. I have to include a count test inside the assembler to time it as I don’t presently have any physical way (scope etc) to monitor the output frequency directly. Currently I’m getting 2.42MHz (write) and 4.9MHz (read) speeds, but I suspect my figures would be similar to your faster times if I removed the count test:

REM Simple read/write routine for Beagle XM single GPIO register
REM Expansion port speed tester
REM Assumes MUX, OE etc registers already set up

MODE MODE
OFF
ON ERROR ON: REPORT: PRINT" at line "; ERL: END
SYS “OS_Memory”,13,&49056000,&100 TO ,,,mem%
PRINT “Read/write speed test of GPIO 130 using assembler loop:”’
PROCassemble

A%=&3: B%=mem% + &90
C%=&3: D%=mem% + &94
E%=2420000
T%=TIME
CALL set_unsetGPIO%
PRINT ;E%;" cycles written in “;TIME – T%;” centiseconds"’

DIM F% 100
B%=mem% + &3C: C%=4550000
T%=TIME
CALL readGPIO%
PRINT ;C%;" cycles read in “;TIME – T%;” centiseconds"’’’
END

DEF PROCassemble
DIM readGPIO% 100
DIM set_unsetGPIO% 100
P%=readGPIO%
[OPT 0
SWI “OS_EnterOS”
.more
LDR R0,[R1]
STR R0,[R5]
SUBS R2,R2,#1
BPL more
SWI “OS_LeaveOS”
MOV PC,R14
]
P%=set_unsetGPIO%
[OPT 0
SWI “OS_EnterOS”
.more
STR R0,[R1]
STR R2,[R3]
SUBS R4,R4,#1
BPL more
SWI “OS_LeaveOS”
MOV PC,R14
]
ENDPROC

OK, Ignore all my previous results !!!
It looks like the outputs do need to be level shifted after all.
Altho the output from the LED/Relay driver does switch levels when the output switches, it is “Twitering”.(Not the new fangled meaning)
This explains the higher results for the 32 bit wide SWI’s, as the interference was affecting the measured frequency.
This came to light when I was testing Neil’s program and was getting nowhere near his results.

Moving my probe to the actual GPIO output shows a better waveform, and clean results.

Neil, I can confirm that your prog is indeed running at 2.4Mhz.
Making it loop with “B more” and removing the count has little effect on the speed.(this kills the machine though !)

My results as follows. (consistent over a couple of days now)
Basic loop, bit wide in task window – 22Khz
Basic loop, 32 bit wide in task window – 41Khz
Assembly loop, bit wide called from Basic in task window – 517Khz
Assembly loop, 32 bit wide called from Basic in task window – 583Khz
Assembly loop, bit wide needing Alt/Break to quit – 709Khz
Assembly loop, 32 bit wide needing Alt/Break to quit – 840Khz
Called from an assembly WIMP app, in the poll loop, both 32 and bit wide 23Khz

With the I2C protection on, the speeds are about 15% slower for the bit wide tests. The 32 bit write does not need the protection to work as the I2C lines are not in the same GPIO group on the expansion port.

These values do seem more in-keeping with Neils test prog speed as well.

Sorry if my previous startling speeds got anyone exited…

Thanks to all for pushing this area forward (especially Tank). I’ve uploaded a YouTube video of my XM driving all the GPIO lines on the Expansion port, running a few light-chaser sequences via 22 LEDs just to give the board something to do:

http://www.youtube.com/watch?v=RFSCJCbRwcI

I found I didn’t need to level shift to drive the LEDs as they are low voltage, low current types that seem happy with the 1.8v available.

-Neil F

That’s brilliant Neil, thanks for that! Loved the chasing LEDs, all you need now is for it to say “Hello Michael”, and you’ve got yourself a Knight Rider board :-)

Tank, lot of work you did, very nice.
I only noticed that you sometime didn’t save all used register, for example in the Write_Exp_OE32 routine.

Good spot Peter. That serves me right for just copying other sections of code !! Spotted a few others as well…

Download updated.

Neil, (and others of course) is there any other function that you think would be useful in the module ?

Neil, (and others of course) is there any other function that you think would be useful in the module ?

Tank, if you want to use GPIO pins from a program and use your program to configure it, it would be nice if you can save the configuration from your desktop program and use it with the GPIO module. A GPIO_LoadConfig swi. This way you don’t have to dive into the datasheets to make a program that works with GPIO.

Peter, do you mean by passing a pointer to the module that points to a list with entries of GPIO number followed by Mode, O/I, Pull-up/Pull-down flags (as a minimum) ?.
If so, then that would be quite easy, and also, you could have a GPIO_GetConfig that saved out the same format of information and passed a pointer back to the user that covered all of the available (on connectors and the LED’s/Switch) GPIO lines.
I hope I have made the module quite friendly to the user anyway, as you only need to give it the GPIO number to control all of its functions.
Another thing may be to pass back to the user the Logical address and mask for the GPIO line, so they don’t have to map in memory to access directly.

Peter, do you mean by passing a pointer to the module that points to a list with entries of GPIO number followed by Mode, O/I, Pull-up/Pull-down flags (as a minimum) ?.

I think I mean that. The module should have something like:

GPIO_GetConfig
input  : r0=buffer
         r1=size of buffer
output : r0=number of bytes used to store config data
gives an error if buffer to small

GPIO_LoadConfig
input  : r0=buffer with config data
         r1=size of config data
gives an error if it could not load data