Beagleboard Xm

Connector should work with a RiscPC. It did last year for me, anyway.

Yes, it is puzzling. I would have expected Connector to have at least thrown the odd random character on screen, even if I had the settings messed up. Which leads me to suspect either the ports or what is in between.

I know I’ve used Connector on my Iyonix, but I’m not sure whether I’ve used it on my RiscPC, or whether I’ve ever had my RiscPC talking to a beagleboard at all. I’ll have a go tonight and see what happens. In the meantime, try making sure you followed the same steps I did for setting up the connection. And since this is a BB-xM, make sure you’re using a straight serial cable (i.e. not a null-modem/crossover one).

I use Connector (1.03) on my RiscPC and it works without problems connected to the BB-xM. Can see all the start-up messages.

If TIA-232 connections are in any doubt, I can suggest some simple principles and simple voltage measurements that may help.

Pin 5 of a 9-way TIA-232 connector is signal ground, so all voltages must be measured relative to it (i.e. put the negative or black lead of your voltmeter on pin 5). Also make really sure that pins 5 at the two ends are reliably connected to each other, or chaos will ensue!

In the idle state, output pins will be either more negative than -3 volts or more positive than +3 volts. Anything sitting near zero volts is an input. Measure the voltages on the pins with nothing else connected, and you’ll see which pins are inputs and which are outputs.

Never connect two outputs together, simply because it won’t work. If you think you need to connect two outputs together, you’ve got something wrong.

A data output line (pin 2 or 3) should only feed a data input line (again pin 2 or 3). A handshake output line may sometimes be usefully connected to more than one handshake input, but the most likely situation is for no handshaking to be required at all. Some stuff, more usually older stuff, may require the DCD line to be driven by a positive voltage (i.e. more positive than +3 volts), otherwise it will think no data are valid.

Don’t ever bother with pin 9, as it’s the Ring Indicator, i.e. it denotes that the telephone line is ringing!

If you have a properly made shielded cable with enough wires in it, use one of the wires to connect pins 5 of the connectors (signal ground), and connect the cable shield to the bodies of the two connectors. That keeps interference out of the signal circuits.

Thanks everyone for responding. Just in the last hour I have had two way comms working between BBXm & A7000+. Now for the embarassing bit, I should have read the manual (BB_Xm_SRM_A2_01) before going onto the forum. After performing a search on the word “serial” I find on page 34 two vital sentences, “No null modem cable is required.” and “If you are using a standard serial port on the PC, a straight through male to female cable is required.”. A small pale light comes on and illuminates the gloom.

The first sentence tells me I have been using the wrong serial lead. The second says I need to look up on the web what a serial straight through cable is. After browsing three sites I get the picture (literally), on the DB9 connectors join pin1 to pin1, pin2 to pin2 etc, don’t bother about pins9.

A quick rearrangement of connections on a breadboard, on with the Acorn, run Connector v1.03 change its settings, switch on the BBXm and …, blow me down, IT WORKS! After a week of head scratching this is a very happy moment, (ah, fuzzy warm glow).

So to quote Chris France who sold me my first computer, a BBC Master 128, “If in doubt, R-T-F-M”. Advise I should have recalled sooner. And thanks again for the helpful comments I have received here as well.

Tank: There’s now a new OMAP ROM available for download which contains the new HAL device. It’ll identify itself as type &403 (i.e. HALDeviceType_Comms + HALDeviceComms_GPIO), with an ID of 0 (HALDeviceID_GPIO_OMAP3). The Activate/Deactivate/Reset/Sleep entries are just dummy entries; the only interesting bit is the two words after the main structure which define the board type & revision (see Kernel.hdr.GPIODevice). So a rev A BB-xM would have a type of 0 and revision of 3, a rev B IGEP would have a type of 2 and a revision of 0, etc. I couldn’t find any docs indicating that there are multiple DevKit revisions available so they just report themselves using the single ‘unknown’ revision.

Let me know if there’s anything else you’d like to see!

(edit)

Wiki docs – should be a bit easier to read than the header file.

Thanks Jeffrey, when I get a chance I’ll update the GPIO module to use it.
Just a quick one, can the menu key be set up to produce a mouse menu press, as the keyboard I use is a wireless mutimedia one with only two buttons, so I always need to build my own ROM with that change. (this would have the by-product of saving a bit of bandwidth as I wouldn’t need to download the source so often)

See thread about the Red/Green/Blue keys – Rik just provided the necessary BASIC script to do just that (within the desktop, at any rate). And very grateful I am too – saved me a job, and I’ve had a very busy day!

i would like to post an sdimage but not sure if i can???

Sent a copy to the webmaster to put on the download page

Do you have any idea where it might/will be? This wiki page is ready for hosting images built by SDCreate. Unfortunately, we’re currently hampered by:

• Content size (2097 kilobytes) exceeds the maximum (1024 kilobytes) set for this wiki

<bump>

Just to say I have added the detection code to the GPIO module and it detects the fact its running on my rev C xM but it seems to think my rev B xM is a rev A!
Not tested on any other boards (I will test on my Devkit when Stephen Leary sends it back)

Also I have added a couple of SWI’s to read/write the SRAM (just added these to test if it worked)

Available from the usual download location

but it seems to think my rev B xM is a rev A!

When the rev B boards were released there was some confusion over what revision they actually were. I think the conclusion of the discussion was that the rev B boards are similar enough to rev A boards that software didn’t need to be able tell the difference between them, so they didn’t bother changing the GPIO lines that are used for the revision detection.

Just installed the latest Rom on Xm and i am having problems with the pinboard saying not enough memory to load spites has anyone had this problem???

I am having problems with the pinboard

Same here. Works okay if a jpeg is loaded, but ‘Not enough memory to create a sprite’.

It’s probably something that’s changed in the last few days, since the ROMs I’ve been building locally have been fine. I’ll have a look into it when I get home tonight.

Could possibly be the lack of "ooohy poohey code"?

It shouldn’t be, since that code has been disabled for years.

Oops – oh well, I expect Sprow’s got an idea on it anyway.

I expect Sprow’s got an idea on it anyway.

My recent changes to pinboard were initially checked by just ensuring the binary didn’t change. The later changes are the ones to look at – I checked it in a few times so should be easy to narrow down. Jeffrey is welcome to do this as I’ll not be able to tonight, and I did fix a stack imbalance introduced in BASIC so if Jeffrey fixes this we’re even!

I did fix a stack imbalance introduced in BASIC

Oops!

Oh well, as long as we’re both producing bugs at about the same rate then I can’t feel too bad about it ;-)

The Pinboard bug has been fixed now, so keep an eye on the downloads page for an updated ROM image in the next day or two.

What did happen to the source code archives on the download page? The latest (daily built) archive for OMAP3 is dated 2011-09-25.

Try e-mailing ROOL. It sounds like the script that builds them is broken.

Oh well, as long as we’re both producing bugs at about the same rate then I can’t feel too bad about it ;-)

“If debugging is the process of removing bugs, then programming must be the process of putting them in.” – Edsger W. Dijkstra (allegedly)