!NetFetch and GPIO on R-Pi

Here’s an odd one… I’m running an R-Pi rev. 1, with Tanks GPIO module loaded, and a Gertboard hooked up to the GPIO pins. All this works perfectly, and I can flash the LEDs at will.

Until I ask !NetFetch to fetch mail – at which point my Gertboard lights up like a Christmas tree, and all twelve LEDs come on. I can reset them, either by calling GPIO_WriteData, or with !GPIOConfig. But as soon as I check my mail again, it’s party time and all the lights come back on. I dunno if this is intentional behaviour on the part of !NetFetch, but it’s rather pretty.

If only you could get it to light up one LED for each new item received…! :)

This may be an opportune moment at which to remind readers of the existence of my MBoxAlert application, at http://davehigton.me.uk

:-)

I can confirm this happens on a Rev2 board as well, including the extra 4 GPIO’s on the extra header.
Any call to the Hermes module SWI’s or from * commands for EMAIL or RSS seems to initiate the behaviour.
Reboot the machine and run !NetFetch.
Run !GPIOConfig (which loads GPIO) and switch pins to output and they are all high…

Just as an update to this – it seems to be something generic in the NutPi package, as I get the same behaviour from Grapevine, SafeStore, CloneDisc and Organiser.

My guess is that it’s the pidetect program, but I don’t know enough about RISC OS assembler to verify this. The source is available in the NutPi package at RComp.SafeStore.SafeStorePi/zip.!SafeInst.s. in case anyone has a NutPi package and wants to take a look.

Its strange that they even mess with the GPIO registers, as OS_Hardware4 can return the board type, including revision to you. It has been expanded to work with the Pi as well.

Right… Should this be counted as a bug then? It’s OK for me, as I’m just flashing lights on and off anyway. But effectively this stops me from using the GPIO pins for anything useful on my Pi, as every time I run anything from NutPi it stomps all over them.