GPIO module
Pages: 1 2
Dave Higton (1515) 3404 posts |
I’m struggling again, this time with the GPIO module on the BBxM. The BBxM with RO5.25 from this April has a GPIO module in ROM, which was a surprise to me. However, I can’t find any documentation for it (if there is and I’ve missed it, please point me at it). There is documentation for the TankStage GPIO module, but if you look at the calls that they implement, it immediately becomes clear that the TankStage and ROOL GPIO modules are very different. Where they both implement a SWI of a given name, they share the same number, but that’s it. Even if the TankStage module’s StrongHelp manual were applicable to the ROOL module, the help it gives is so scant as to be useless to me. (I’ve also noticed several errors.) What I’m trying to do is to set a GPIO135 as input with pull-up and detect any edge on it. When an edge occurs, I expect to discover it by repeatedly null polling (10 times a second is plenty), and clearing the signal when I take my action. I think it’s an input, although whether that’s because I’ve set it thus or whether it’s just the way it is after reset, I don’t know. I can’t seem to enable the pull-up or detect any change at the input. Any help would be appreciated. |
Dave Higton (1515) 3404 posts |
I can read the state of the GPIO135 input by GPIO_ReadData and see 1s and 0s, but still I can’t see transitions as events, nor can I understand how to enable them. |
Dave Higton (1515) 3404 posts |
Looking at Tank’s Event Tester demo app, I can see that it does a “GPIO_WriteFalling, pin, 1” commented as “enable event”. But the ROOL GPIO module doesn’t implement the GPIO_WriteFalling SWI. Where does this leave me? Is it impossible to enable events (in which case why is it possible to read and clear them?) or are events enabled by some other means? |
Andrew Conroy (370) 724 posts |
Yes, I’ve commented before that the new GPIO module is a poor relation to the previous version, and the documentation is dire! |
Dave Higton (1515) 3404 posts |
Thanks, Andrew, I had already looked at your example code. It doesn’t appear to be appropriate for a BeagleBoard, sadly. We are in agreement about the state of the documentation! Tank’s module doesn’t implement the ReadEvent or WriteEvent SWIs for the BeagleBoard, although it does implement ReadFalling, WriteFalling, ReadRising and WriteRising (so it can enable edge detection but not allow you to read the events), and the ROOL one implements ReadEvent and WriteEvent but not ReadFalling, WriteFalling, ReadRising or WriteRising (so you can read the events but not enable their generation). Which is most odd. Reading through the Texas PRM for the SOC, it looks like the edge detection can only generate interrupts. I got too tired before I worked out whether it’s possible to read non-enabled interrupts. i.e. I want to see the event but not to generate an IRQ from it. Ultimately I want to run the code on a RasPi, but I no longer have a spare one – they’re both in use, one controlling the heating and hot water system, the other a VPN server. I want my code to run on the former but I need to write and test it first. There’s nothing for it but to buy another one. |
Andrew Conroy (370) 724 posts |
Yes, they do seem to have taken a quite fully-featured module and butchered it for no obvious benefit :( I guess you could get a Pi Zero, they don’t break the bank :-) |
John Williams (567) 768 posts |
I guess that’s the way to go! After all, they’re not that expensive! I have more than I have uses for, tho’ I’m thinking of a dedicated R4 and a separate FIP player! |
John Williams (567) 768 posts |
Is this written-up somewhere? |
Neil Fazakerley (464) 124 posts |
Dave, there’s a StrongHelp manual for GPIO v1.00 supplied with the latest version of RO. Don’t know where it would be on the XM’s RO installation, but on the Pi it’s in $.Utilities.Manuals. With GPIO v1.00, the previous versions’ 40-odd individual SWIs have been reduced to just 10 general purpose SWIs, with individual details needing to be added via extra parameters. The original v1.00 StrongHelp manual was a bit of a bodge-up and caused a lot of confusion when it first appeared last year, but I think the current one just about covers everything, although a lot of the nitty-gritty info is only revealed by clicking on some of the links in the short explanations. The bottom line is that almost no GPIO programs written for earlier versions of the module will work with v1.00. They need to be rewritten after consulting the StrongHelp manual. ISTR Tank did request forum opinions about whether he should continue with the old system of separate SWIs for different machines, or rewrite the whole module to suit the then new HAL. There wasn’t much of a response so he just went ahead and wrote v1.00 for the HAL. AFAIK there’s nothing relevant to GPIO v1.00 on Tank’s website. |
Dave Higton (1515) 3404 posts |
Thanks, Neil. However, I can’t find anything supplied with RO. Given the location you said, it would have to be in the HardDisc4 image, but I’ve not found it in any version I’ve looked at. It’s not on my BBxM, nor the RasPi that I want to run the final code on. I found what I believe to be the most recent version of the manual on the ROOL web site. It’s at this point that I reached despair. The manual does refer to earlier modules, and has a table of the SWI numbers for each of three platforms and whether they are implemented on each. OK, it must be for version 1.(something) of the module. But it doesn’t say what version of manual it is, nor what version of module it refers to – nor even what platform(s) it refers to. It lists the ReadEvent and WriteEvent SWIs, which are not implemented in the BeagleBoard version of the module, so clearly it can’t refer to the BeagleBoards (at least, not correctly). For WriteMode, it refers to a 5 bit field for mode “from pin info” – but nowhere does it say what the values should be, nor where they might be found. In short, it’s crap. I’ve reached the conclusion that the BB and BBxM don’t allow the user to read events – only to generate them, resulting in IRQs, which is not what I want. |
Dave Higton (1515) 3404 posts |
No. I’ve contemplated doing it, but not done anything about it. It might be nice for some people to read about out of idle curiosity, but it wouldn’t be any use to anybody AFAICS. The write-up I did for the original one appeared on Drobe. It was Slashdotted, and the resulting traffic brought the Drobe site down. Funny, really. |
Dave Higton (1515) 3404 posts |
It’s not the money, it’s the earache I get every time I buy anything :-) |
Andrew Conroy (370) 724 posts |
It’s on my Pi in the place Neil says, as part of the RC16 disc image, not part of the HardDisc4 download, however. The manual does, however, launch into a tutorial of how to use the module, which is sadly useless as it refers to the SWIs from an earlier version, not this version :( |
Andrew Conroy (370) 724 posts |
The Pi Zero is small, you might be able to smuggle it in under the radar :-) |
Jeffrey Lee (213) 6046 posts |
Clarification: The SWIs are not implemented for the BeagleBoard in the pre-1.00 version of the module. For 1.00-plus, the list of SWIs on the main index page are supported, for all platforms. And the GPIO 1.00 should be supported by the BeagleBoard (it’s included in the RISC OS 5.24 BB ROM; in the months/weeks leading up to the 5.24 release both OMAP3 & OMAP4 were converted to use the new GPIO interface).
The pin information is available from the GPIO_Info SWI. |
Rick Murray (539) 13405 posts |
This? https://www.riscosopen.org/viewer/view/bsd/RiscOS/Sources/ThirdParty/TankStage/HWSupport/GPIO/Docs/GPIO%2C3d6
Sadly, I have to agree. I’m looking now, and GPIO_WriteMode says quite nicely that bits 0-4 are the mode from pin info. The “how to use the module” documentation (step 1) mentions twice that the mode value varies depending on the SoC in question (and suggests you look at the SWI documentation which is not useful, unless that means wading around the HUGE list of SWIs provided previously?). Question is – why? Shouldn’t the module be trying to present a consistent interface as best possible?
I believe it’s unified. Well, unified in the sense that it’s the same smaller selection of SWIs and may return different data for some stuff depending upon what board it is… that sort of unified… Where is GPIO anyway? ModuleDB says here: https://www.riscosopen.org/viewer/view/bsd/RiscOS/Sources/ThirdParty/TankStage/HWSupport/GPIO/ |
Jeffrey Lee (213) 6046 posts |
You’ll want to look at the HAL branch (and un-hide the attic files, because the CVS viewer is weird like that). |
Neil Fazakerley (464) 124 posts |
In the SH GPIO manual that came RO 5.23 (13-April-17), the WriteMode page has ‘pin info’ underlined as a link. Clicking on that leads to a page headed Pin Information Structure’, containing all the various bit data. b0-b4 are said to represent the ‘physical GPIO pin number’. I think there must be at least two versions of this v1.00 manual kicking around, one is an incomplete bodge and the other is the later, fully written up version. Perhaps the earlier one is still being released with some versions of RO, by mistake. As you say, there’s no version number so no easy way for ROOL to tell the two versions apart. It’s a major screw-up from the physical computing point of view and likely to put a lot of people off using the GPIOs. |
Andrew Conroy (370) 724 posts |
That still refers to GPIO_EnableI2C in the primar, a SWI which no longer exists! |
Neil Fazakerley (464) 124 posts |
Yes, those bottom three items on the primer list still need to be removed as they’re not relevant to v1.00. As far as I know, the rest of the manual is OK though. I think the real problem is that users have not been warned that a large proportion of their previous GPIO progs will need to be rewritten to suit the new command list and parameters. Perhaps the new module should have been given a different name, to flag up its new approach. Or perhaps it could have included code to detect the old redundant commands and then failed gracefully with an informative warning. |
Dave Higton (1515) 3404 posts |
Thanks for everybody’s help. It’s working on the BBxM in the way that I want – I am able to read events. The StrongHelp file is still demonstrably crap. The “mode” is not defined anywhere, neither in absolute terms, nor as a pointer to where to find the information. All we have is a circular reference between two pages. In the end I decided that the mode I need is 4 (in the OMAP and BBxM documentation, 4 is the mode for GPIO), and it works. I presume that I’ll need the number to be 0 when I transfer the app over to the RasPi. But it’s nice that the other bits in the field seem to be platform-independent. For anybody who’s interested: the application is a doorbell notifier. I bought a cheap doorbell system with one push and two receivers. One receiver is plugged in in the hall. I’ve taken the other one apart and discovered that it’s actually quite reasonable. There’s a direct-off-line switched mode regulator that outputs 5V (probably very noisy), which goes to a 4.4V linear regulator (yes, really 4.4V; it’s the first time I’ve ever seen that voltage in use) that feeds the decoding and audio generation chips, and in turn feeds a 3.3V linear regulator that powers the RF chip. I found a pin that generates a train of 4.4V pulses when the button is pushed. A simple common emitter inverter shifts that to the I/O voltage of the ARM chip; in this case it’s 1.8V for the OMAP, but it’s immaterial over a wide range. I detect negative-going edges and use that, with a timeout, to send a message to IFTTT, which in turn sends me a Telegram message. When I transfer the hardware to the heating control box, the receiver will be powered directly from the main 5V supply, thus not requiring any mains isolation. The “bell” in the hall isn’t very loud on its highest volume, so we can’t always hear it in the sun lounge, and in any case no reasonable sounder would be loud enough for us to hear it when we’re in the garden. So it’s not just a daft project to occupy my time, it has a (minor) useful function. |
Jeffrey Lee (213) 6046 posts |
I believe the intent is that you use GPIO_Info to enumerate the GPIO pins. For each pin, GPIO_Info will return a list of “modes”. For each mode, look at the group type and group number to work out if it’s the entry you’re interested in. Once you’ve found it, read the mode number from bits 0-4 of byte 1 of the mode structure, and then pass that to GPIO_WriteMode. |
Dave Higton (1515) 3404 posts |
Thanks, Jeffrey. Wow. That’s hard. But at least it has confirmed that the mode I want is indeed 4. |
Andrew Conroy (370) 724 posts |
So does it involve enumerating the pin info for every GPIO pin just to get the details for one? The SH manual hints that it’s possible to not enumerate the full set, but doesn’t say how you’d do it (R1 is claimed to be always the magic number “FULL”). Compared to the previous SH manual which gave a helpful table of mode numbers and what each meant it seems a lot of hoops to jump through to find the right mode for one pin. |
Jeffrey Lee (213) 6046 posts |
If you don’t specify “FULL” in R1 then the second part of the GPIO_Info page kicks in: When full information is not requested this SWI returns the lowest and highest GPIO pins, though note that there's no guarantee all pins in that range are available or even exist: <= R0 = lowest logical GPIO pin number R1 = highest logical GPIO pin number R2 = pointer to list of useable pins in the order expansion port (1 byte per pin, &FF end of table) aux port (1 byte per pin, &FF end of table) camera port (1 byte per pin, &FF end of table) user (1 byte per pin, &FF end of table) I.e. “FULL” selects the GPIO 1.0 API, non-FULL uses the pre-1.0 API
True. However, I think the (new) GPIO API is based around the assumption that your code is aiming to be machine independent. E.g. it knows it wants to use the SPI interface, but it doesn’t know what GPIOs the SPI interface is available on, or what machine-specific modes those GPIOs need to be switched to. So it enumerates all the pins looking for ones which can be configured for SPI, and then remembers the details of those pins. A GPIO_Find SWI would probably make this easier, of course! Also this doesn’t really cater for the case where you want to use GPIOs in GPIO mode – i.e. you know the (physical?) pin number you want, and you just need to put it into GPIO mode. (Also the manual doesn’t really explain how, or even if, it’s possible to map from e.g. “pin X on header Y” to a logical pin number as used by the GPIO module) |
Pages: 1 2