Idea to make Display GPIO available as Inputs

[nevilh]

Could the DAL be changed so that for a brief moment the display multiplexer Row & Col are tri-stated allowing the logic input state of P3, P4, P6, P7, P9 & P10 be captured?

They could then be used as GPIO inputs, so long as the driving device has a high value series resistor, say 10k+.

The 10k would ensure that during normal display driving there was no conflict between the 2 driving sources (but the Display LED current would be fractionally reduced by <0.3mA which I think would be hardly noticeable)

Cheers,

Nevil

[finneyj]

@nevilh That's inspired! I think this is a really neat idea, and would indeed be achievable, but there would be a few complexities in the implementation...

Firstly, it would almost certainly stop the light sensing code from working properly. This isn't a reason to reject this feature request IMHO, but i'm pretty sure we'd have a rider in the documentation stating that "if you use these pins, then light sensing will be disabled" or something like that.

Secondly, these pins would have different temporal characteristics than the other pins, which might be a bit weird (because we'd effectively have to "cache" the most recently sampled value, and that's what you'd get if you performed a getDigitalValue() call on the pin). In other words, the update rate would be slower than the other pins, and it might be difficult to explain that to kids etc.

I guess whether the additional complexity is worthwhile comes down to the application domain. Do we think there are enough compelling applications that would need this, to warrant the complexity we'd have to introduce?

What do you think? I guess it would have to be something that needs both a lot of GPIO inputs and the display to be running...

[nevilh]

Hi Joe,

Thanks for your response.

As far as reasons to add this feature are concerned here are my thoughts:-

1. There’s the general comment that ‘you can never have too many GPIO’

2. It would be a response to comments along the lines of ‘if you can’t use those GPIO what was the point of connecting them to the edge connector?’

But for more specific applications where it could be a benefit...

3. Simple Games Controller. I have a worksheet for a simple games controller for a Raspberry Pi built on a Breadboard. (It’s a Breadboard version of my “PiTrol” see www.ThePiTrol.com ) It uses 4 push buttons and a 4 way joystick which acts like 4 more buttons. It would be good to adopt this for the micro:bit, and in fact I can since it only needs 8 GPIO and there are 9 available leaving P0 ‘spare’ to be used for sound effects. But that has used all the GPIO restricting what else could be done. In fact P5 & P11 can be re-used so 3 GPIO, say, P0, P1 & P2 could still be available for other things.

4. 2 x Simple Games Controllers. I have an extension to the above where I attach 2 Simple Games Controllers to a Raspberry Pi for 2 player games (It’s a Breadboard version of my “PiDapter” see www.PiDapter.com). With the 9 currently available GPIO, plus P5 & P11, plus P3, 4, 6, 7, 9, 10 there would be enough inputs for the 16 buttons leaving P0 for sound effects!

5. Compatibility with existing Raspberry Pi peripherals. This is the background to where I had the idea. Back in October I was working with DavidW and a guy called Trevor to work out a ‘generic’ mapping of micro:bit GPIO to RPi GPIO for my zbit:PiDapter. Like with my ‘full sized’ PiTrol and PiDapter his “GPIO Box” attaches to the Raspberry Pi via a 40 way Ribbon Cable and would like to use it with the micro:bit as well. We tried to come up with a pin mapping that suited my PiTrol and suited his GPIO Box but in the end we couldn’t come up with a mapping that would work for everything, partly due to the restrictions on P3, 4, 6, 7, 9, 10. In fact I couldn’t even get it to work for my PiTrol/PiDapter, let alone Trevor’s GPIO Box.

6. Ease of designing future peripherals that are both Raspberry Pi and micro:bit compatible. If, for instance, I were to redesign my PiTrol & PiDapter in the light of my zbit:PiDapter mapping and I could use P3, 4, 6, 7, 9, 10 as inputs, I think I could make them both RPi and micro:bit compatible. Whilst I have no plans to do so, it may give others more flexibility to allow them to make there’s compatible with both.

7. It appeals to my engineer's instinct to try and squeeze every little bit of functionality from the micro:bit :-)

Anyway, it may not be the highest priority ‘enhancement request’ but I thought it was worth officially posting it, rather than just have it rattling around in my head. And if it can be done I think it may have merit. And for the applications that it might enable, it would probably be for people who understood any restrictions it came with e.g. lack of light sensor, slower response time, etc.

Cheers,

Nevil

[finneyj]

Thanks @nevilh!

Sounds pretty convincing to me. :-)