Has the HAL device type call changed?

As documented here https://www.riscosopen.org/wiki/documentation/show/HALDeviceComms_GPIO you can determine the device type (processor, board, revision) with the following:

SYS "OS_Hardware", 1027, 0,,,,,,, 4 TO , n%, d%

Looking at d%?2 will tell you the processor type (like OMAP3, BCMxxxx, etc), and d%?64 will tell you the board type so you can tell the difference between multiple devices using the same base CPU.

I am having reports that this is not working on the IGEPv5. It returns with n% as -1 and d% with a valid looking address (&FA000xxxx – similar to that returned on the Pi1).

The first wrinkle is the -1 in R1. It seems from the API description https://www.riscosopen.org/wiki/documentation/show/OS_Hardware%204 that R1 is -1 if “there are no (more) devices of this type”. Well, what happens if there is only one device of this type? It appears from reading the documentation that -1 if there are no more devices of that type, and also if there are no devices of that type (at all). Is this correct? How do you tell one from another? The documentation states that if R1 is -1, the address is R2 is bogus…

…which could explain why the IGEPv5 device seems to identify itself as CPU type 5, board type 44 (instead of CPU 4, board 0).

Has this API changed? It used to work, now it doesn’t (R1 = -1 on exit, that’s new).

Looking at d%?2 will tell you the processor type (like OMAP3, BCMxxxx, etc), and d%?64 will tell you the board type so you can tell the difference between multiple devices using the same base CPU.

Using these magic numbers is not reliable, and I have found they do indeed change with changes in OS version (not the hardware). One ends up with an array of different combinations for different OS and hardware. It is more reliable to look at the device description string returned by the call. The pointer returned in (in your nomenclature) d!12 gives the textual description of the GPIO device. Checking for OMAP3, OMAP4, and OMAP5 in the string will differentiate BB, PB and IGEPv5.

I could send you a c function that combines the two approaches.

As documented here you can determine the device type (processor, board, revision)

Well no, if you read further: “It is only exposed by the HAL to allow third-party programs to make use of the GPIO hardware”. So unless you’re the GPIO module, you shouldn’t be tying any significance to the private enumeration of values it returns, they are subject to change (or withdrawal) at whim.

In fact, a wise person called Rick commented on how it flew in the face of hardware abstraction to be inferring anything from a HAL device that doesn’t exist on several platforms RISC OS works on, just a few months ago.

Can you please then point me at the API that tells exactly what board the current platform is?
My module communicates using the hardware IIC and this appears on different buses on different platforms. It is not the greatest idea to attempt to probe unknown IIC devices and on (some?) earlier versions of RISC OS probing non existant IIC buses trashes the entire IIC subsystem.
RISC OS itself knows by necessity what the hardware is. Where is this information exposed to the application level?

I fear I’m going to need to poke CP15 to determine the CPU ID and infer from that…

RISC OS itself knows by necessity what the hardware is. Where is this information exposed to the application level?

Via modules such as the GPIO module.

Since the GPIO module is in charge of any pin mux settings for expansion headers (and that’s usually where user-accessible I2C is found) it would make sense to me if the GPIO module had a way of reporting to software which I2C buses are available for use. Basically for each set of pin mux settings which can be used to enable an I2C bus, it would report what the required pin mux settings are, the RISC OS I2C bus that it exposes, and a name for the bus/pins (so the user can select the right configuration, or so it can be saved to config files, etc.). This would report all possible configurations, not just the currently active ones – programs would then have to use the pin mux SWIs to check that no other software/hardware has claimed exclusive use of the required pins/bus. The same scheme could be extended to other IO interfaces (I2S, serial, actual GPIO, etc.)

Submissions welcome!

A new HAL call has been added to return a board dependant string.

HAL_PlatformName.

It is in the latest Pi build and should be in the OMAP 4 and 5 builds as well.
The GPIO HAL device is going through a bit of a transition API wise ATM, and the GPIO module will change (code) substantially.

My problem impementing the new device calls is time, but I do have a new PI build with read, write, mode and a few other houskeeping calls working.

Jeffrey, your suggestion about what I/O is available on the expansion headers is something that should be added. The module at present knows which pins are I2C and there is a call to “protect” them from mode changes, but it does not report back to the user which pins they actually are.

My new Device interface does report to the caller which modes are available on the pins it can access.

With the long weekend, I hope I can push it on a little bit .

A new HAL call has been added to return a board dependant string.

HAL_PlatformName.

However (a) that HAL call should never be used by user programs – OS_ReadSysInfo 9, 7 should be used instead, and (b) OS_ReadSysInfo 9,7 is intended to be a debug aid for humans, not a hardware identification method for use by programs.

Pardon me from intruding guys, but where a program needs to operate slightly differently on different hardware how exactly is the programmer supposed to differentiate?

Does a program really have to prod obscure bits of the system testing for each required hardware item/feature?

What Steve said.

As I mentioned above, I have an need to know up front which IIC bus is the one to use. It isn’t “safe” to probe them, and the “external bus to which bits can connect” differs from one platform to the next.

While I certainly agree that making things platform specific may be a pain and not in the spirit of things; the converse is that there can be a real and valid need to tell machines apart. All this time and all these boards and OS_ReadSysInfo still can’t offer that…

As it is right now, I have made four clones of the module, with a suffix from 0 to 3 which correspond to the IIC bus that applies.
My thoughts on this “solution” are not fit for a family audience.

Does a program really have to prod obscure bits of the system testing for each required hardware item/feature?

Yes. You don’t look for what hardware platform you’re running on, but instead look to see if the specific piece of hardware that you need is present. It’s always been that way, because it allows people to develop hardware add-ons in the future (as well as allowing software to work on new, as yet unimagined, hardware platforms in the future).

It’s always been that way,

We’ve always had one current hardware platform, usually retaining the features of the previous one and adding a few.
That’s not changed has it? Oh…

Now if someone presented an official quick method of identifying all the available features of the platform in use I’m sure people would use it.

I would disagree that we have always had ‘one current’ platform.

Think back to when loads of A310s and A3000s were in use. The A5000, A4 and Risc PC etc offered new features but applications didn’t detect the specific machine and make assumptions. You have to use the various OS calls available to check if the feature you need is available. This sort of thing has been common with RISC OS (regardless of hardware differences) when thinks like JPEG rendering (SpriteExtend) and the nested Wimp came along.

It seems that the complication for Rick is that the GPIO HAL system is under development, and/or the IIC stuff isn’t entirely HAL-ified. I would hope that platform assumptions are absolutely an interim measure.

Well, I did have a nice long ranty reply, but the forum ate it.

Here’s an abridged version:

Pardon me from intruding guys, but where a program needs to operate slightly differently on different hardware how exactly is the programmer supposed to differentiate?

Does a program really have to prod obscure bits of the system testing for each required hardware item/feature?

You can either ask the user or you can use sensible APIs to query for the features you need.

Guesswork and hardcoding will only lead to failure once a new machine or OS version is released. (Insert very long list here of all the things that have changed from one Raspberry Pi hardware revision to the next). An OS call which returns a string saying “Raspberry Pi” will not save you. You need APIs which are able to return much, much more detailed information.

While I certainly agree that making things platform specific may be a pain and not in the spirit of things; the converse is that there can be a real and valid need to tell machines apart. All this time and all these boards and OS_ReadSysInfo still can’t offer that…

RISC OS 5 is being developed by volunteers in their spare time. We don’t have the manpower to meet everyone’s needs in a timely fashion.

Designing and implementing sensible APIs to query hardware details takes time. You should be glad that Tank is interested in GPIO, and thankful that he’s working on improving the OS.

As it is right now, I have made four clones of the module, with a suffix from 0 to 3 which correspond to the IIC bus that applies.
My thoughts on this “solution” are not fit for a family audience.

You can’t blame us for your bad choices.

If you need to know something, and the OS can’t tell you, ask the user. They know what machine they’re using. They installed the I2C device. They must have read the hardware manual in order to know which pins on the expansion header to attach it to. So there’s a good chance they also know what I2C bus that is from RISC OS’s perspective.

Have a configuration file the setting can be saved in. Make your module read it. It’s not rocket science.

Well, I did have a nice long ranty reply, but the forum ate it.

It’s a feature of the Beast/Textile AI component that introduces a diplomacy assistance delay :)

Even though I’m shaking my head in disbelief, I’m not going to write a ranty reply. That doesn’t do any good in the long run…

You can’t blame us for your bad choices.

I’m interested to know how it is my “bad choice” that I’m having difficulty telling one machine from another in software.

So there’s a good chance they also know what I2C bus that is from RISC OS’s perspective.

Hands up which normal users (hmmm, that perhaps wouldn’t even be reading this?) know what IIC bus to use to talk to an add-on for the Panda? Oh, wait, that’s my job as the programmer. The normal user expects to plug the thing in and have it work…

Have a configuration file the setting can be saved in. Make your module read it.

Oh do move on from the eighties mentality… ;-)

I add the smiley so you know I’m taking the piddly ever so slightly. No point starting a war over this. I just think it is a shame that the OS doesn’t provide any way of saying “this is a X”. Acorn used to, some OS_Byte call that returned odd numbers like &A7. Thus meaning anything that wants to try to behave in an “intelligent” manner will need to do alternative things to identify the board.
For my part, if I revisit this code, I’ll most likely try to identify the board by identifying the processor type. As far as I’m aware (for my purposes) that should be sufficient (even with the plethora of Pi incarnations), and the code assumes IIC bus 0 for any device that isn’t specifically detected as needing something else, which is the usual case except on certain boards…
As for future proofing, that’s a fantasy. Or maybe a fallacy. Definitely a “fa” word. Look at the “future ready” RiscPC and ask what would have become of it had Phoebe seen a proper release. Sure the design of the RiscPC was better than some computers but it had limitations that couldn’t be addressed by adding a faster processor. Look at the Pi, even. Mine, an original 256MiB model B, seems laughably outdated. There’s already a number of packages that won’t work on it, I believe Win10 IoT doesn’t run on the early Pis (that might be a good thing, mind).

Now to my module. Chances are the IIC hardware would require a modification to physically fit any new board as expansion ports are not standardised (isn’t the Beagle IIC something weird like 1.8V as well?) so the company making the device will likely need to make a modification which gives them time to say to me “such and such a board needs this” so I can have an updated module available.
As you say, it’s not rocket science.

Oh, and I will remind everybody again in case anybody missed it: on (some?) earlier versions of RISC OS, probing non existant IIC buses would KILL the IIC subsystem. That is why I’m specifically not just scanning through the potential buses see if the device is there – because the results are rather serious (system config appears to revert to defaults and be impossible to change until the machine is rebooted) so I have to consider backwards compatibility as potentially more important than the nebulous future.

PS: Apologies if there are any weird words. The swipey-typey text on my phone sometimes picks some odd words.

Hands up which normal users (hmmm, that perhaps wouldn’t even be reading this?)

Harumph!

I’ll have you know that of the 90 something people in the department at work some of them consider me normal – I think.

You can’t blame us for your bad choices.

I’m interested to know how it is my “bad choice” that I’m having difficulty telling one machine from another in software.

You chose to use RISC OS ;-)

Oh, and I will remind everybody again in case anybody missed it: on (some?) earlier versions of RISC OS, probing non existant IIC buses would KILL the IIC subsystem. That is why I’m specifically not just scanning through the potential buses see if the device is there – because the results are rather serious (system config appears to revert to defaults and be impossible to change until the machine is rebooted) so I have to consider backwards compatibility as potentially more important than the nebulous future.

Although that bug is significant (and easily avoided by asking the OS how many buses there are), I’d be more worried about the fact that IIC doesn’t support device identification. You can easily probe addresses to find out if a device responds (and hope that the probing doesn’t interfere with its operation), but once you’ve found a device is at a given address there’s no way of finding out what it is. So probing for devices over IIC can never be fully safe.

You chose to use RISC OS ;-)

Ouch! ;-)

So probing for devices over IIC can never be fully safe.

Exactly! Which is why…….hey, hang on, are we stuck in a recursive loop?

Oh, and I will remind everybody again in case anybody missed it: on (some?) earlier versions of RISC OS, probing non existant IIC buses would KILL the IIC subsystem.

So you don’t probe on the old OS versions (which should be identifiable), and ask the user for details instead. On new OS versions, you probe. Seems much simpler than to try to identify a platform by one single result to a call.

I find it amazing that anyone thinks that one call with one result would help in more than very specific cases. What will your application do when it encounters unknown future hardware? How finely-grained do you expect the result should be – would the Pi “second edition” (the one with 512 MB instead of 256 MB main memory) be the same or different than its predecessor?

In my opinion, the only way is to query the OS about the features the system it is running on provides, just as Steve Fryatt described. If information is currently missing, the OS should be extended accordingly. Everything else just makes no sense.