Accessing Beagle XM I/O expansion pins from Basic

OK, GPIO_LoadConfig and GPIO_SaveConfig added.
Slightly different to Peters suggestion as LoadConfig only needs r0=pointer and the list to be -1 terminated.
SaveConfig uses r0=pointer or -1 to use the modules workspace to save and r1=flag that allows extended info to be saved.
The test program will save a data file with the setup as displayed on the mimic (to the same directory as the program). Another button just loads the file back in (or if no file just sets a couple of lines up).

Thanks for all your work on this, I too now have a bank of flashing LEDs plugged into my BB :-) Planning on maybe making a little PCB that will bring the (level translated to 3.3/5V) GPIO lines from the expansion connector out to a header, and give me a (level translated too) I2C port too.

Just a thought – it might be helpful if interactive help would tell you the GPIO number of the pin you were hovering over?

The only level translator (bi-directional without control) IC’s I could find were Farnell 1702548 but they are TSSOP package… Very tiny!!
Just got them soldered onto a converter boards today, so will test them this weekend.
Also made off some connectors for the Camera port and the Aux port, so will test as well.

Andrew, [grin] Feel free to add the help to the RES file [/grin]

For info, The Expansion port on powerup is setup as follows.
GPIO 143,144,145,146 are set up as UART2 RX,CTS,RTS,TX
GPIO 168,183 are I2C2 SCL,SDA
GPIO 130,131,132,133,134,135,136,137,138,139,156,157,158,159,161,162 are GPIOs
The Aux port is
GPIO 12,13,14,15,16,17,18,19,20,21,22,23 are HUSB1
GPIO 57 is DMAREQ3
GPIO 170 is GPIO
The Camera port is
All as you would think Camera except GPIO 98 which is GPIO.

OK, GPIO_LoadConfig and GPIO_SaveConfig added.

Good work.

What you already did is enough to use the GPIO line on the BeagleBoard but:

Another button just loads the file back in.

Wouldn’t it be more convenient to drop the file on the Test Program window?

Peter, the test program is just that, and was mainly for my own use and was a quick and dirty product. What might be appropriate now is a setup program (that would be registered !) that could setup the GPIO pins as a user might need them and then save the file (with a registered filetype !)

The only level translator (bi-directional without control) IC’s I could find were Farnell 1702548 but they are TSSOP package… Very tiny!!
Just got them soldered onto a converter boards today, so will test them this weekend.
Also made off some connectors for the Camera port and the Aux port, so will test as well.

Yes, those were the only ones I could find too! It will be interesting soldering them up to a convertor board!

Andrew, [grin] Feel free to add the help to the RES file [/grin]

I will try and get them added, but no promises for when just yet though!

Quick question, probably showing my ignorance here – when you use GPIO_WriteExp32, how do you get a 32bit wide write when you’ve only got 22 GPIO lines to write to?

The writexxx32 SWI’s use a mask to only write to the pins that are available within the 32 bits. So even if you try to write &FFFFFFFF only the masked pins will actually be written.This was added to allow faster setting of multiple pins. The !SWIsDetail file in the source lists the GPIO pins affected.

I have also now started to write a program for creating the config file. I have added the help values to that program, so unless you use the test program a lot, it may be pointless. Request for app name and filetype sent.

The writexxx32 SWI’s use a mask to only write to the pins that are available within the 32 bits. So even if you try to write &FFFFFFFF only the masked pins will actually be written.This was added to allow faster setting of multiple pins. The !SWIsDetail file in the source lists the GPIO pins affected.

That’s what I thought was happening. So we can do 18bit wide read/writes per call in reality.

Yes, the SWI’s can actually access the following in one operation,
18 pins on the Exp port
12 pins on the Aux port
14 pins on the Cam port
but you do have to know the position of the pins within the 32bits to work with them.
(See the Hdr file in the source, lines 367-369)
Any of the Readxxx32 SWI’s pass the mask relating to that connector back to you in r1.

I’m using some level translator boards sourced via eBay US, based on the Maxim MAX3002 chip. Ebay item number 200418656111.

They’re more expensive than the Farnell part but they do come pre-mounted on a pcb with 0.1" dil pin sets included so they’re a lot less fiddly to deal with and can be popped straight onto proto-boards for quick I/O port tests. The postage is £5.50 but, as there’s no extra shipping charge for any number of boards, I ordered four to cover extra ports and keep the cost per channel down.

Allow a week or two for delivery though.

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

Looks fun!

• If you think it’ll be of interest to others (not currently using RISC OS) you could also post to the BB mailing list
• If so, it may be worth considering the inclusion of a few seconds showing the RISC OS screen, e.g. scrolling through the source before running
• Be prepared for possible adverse reaction to RISC OS code but I hope that won’t be too much of a dissuasion.

New download available now with the first version of the configuration program in.
Slightly updated module as well.
Download

Ooo, ooo, please someone wire up the GPIO pins to the light on the front of the ARMini so that it pulses back and forth like Knight Rider :-)

Finally got all my level shifters and LED drivers wired up. I’m now looking at a line of 45 LED’s running in sequence!!
(Also 6 input lines (as they are marked as input only in the OMAP TRM) and still kept the I2C lines free).
A couple of GPIO lines were incorrectly marked as in the Camera port, so that’s corrected and the config app has been updated as well.
Same download location as before.

OK, 45 LED’s running in sequence 6 input lines reading buttons state AND I2C reading the temperature !!!

(Currently 18 degrees). (Doh… &18 degrees so 24 in real life)

In typical off-topic red herring style, has anyone investigated the Khepera III (PIC microcontroller) with KoreBot II (XSCALE PXA-270)? In my naivety, I’m wondering whether the robot could be controlled natively from RISC OS… although the apparent lack of a video connector would complicate things :-(

[Edit: Some of the K-Team founders at EPFL are aware of the A310 and RiscPC at the Musée Bolo. Also, a further ref which may be of interest.]

Right , my first practical use of the GPIO interface….
Testing PCB’s that are assembled at my place of work.
12V I/O, send a pattern of outputs, and read back another pattern (if the board is working correctly)

More robot stuff.

[Edit: And a GPIO video.]

[Edit2: What’s the point of a blog which doesn’t accept comments? And the YouTube version doesn’t seem to accept URLs either!]

A new version of the GPIO module available for download.
Now uses the GPIO device added by Jeffrey to determine the board type, and a bug fix for accessing the board table structures.

So far I have used the GPIO interface to test 3 PCB types and 4 wiring loom check programs.

(Off topic) What are the chances¹ of a RISC OS program solving a Rubik’s Cube in less than 4.762 seconds, using an -A9 device?

¹ If it’s able to work with a camera-equipped tablet and Bluetooth.

Tank: I haven’t used your software yet, but I hope I will get to play in the not too distant future. One of my home projects is to replace the A3010 with a BeagleBoard as my central heating controller.

It will have to control an LCD module, which means I’m going to have to generate strobe pulses of maybe 1 microsecond (ish) duration. It’s silicon from several generations ago.

Are there things to be aware of when trying to change the state of a pin twice in a short time?

Any suggestions as to the best way of determining a minimum pulse duration? (The application is in BASIC, and I’m not averse to a FOR..NEXT loop, if that’s the simplest solution.)

Does anyone think that the ability to generate a pulse would be a useful addition to Tank’s module?

So as soon as I can get my sticky hands on [an RPi] I’ll update the module.

Tank, there’s an amount of info available already, although not much good yet without a board or available ROM build! 1, 2

For Info:
An I/O expansion board has just been announced for the Raspberry Pi, GertBoard.
It’s at a surprisingly advanced stage, given it’s a ‘spare time’ effort.
http://www.raspberrypi.org/archives/411
Regards, Martin.

Dave, there’s no problem accessing the pin quickly, but at 1 millisecond you would hardly need a delay loop !!
To see the speeds I have measured with a logic probe

Trevor, Yes, I have seen this info, and I have asked for more information in the RPi forums. For the module to work, I need to know the control register address and the actual GPIO numbers (it seems strange that the available GPIO’s are numbered 0 upwards).

at 1 millisecond you would hardly need a delay loop !!

1 microsecond, actually…