search

lancaster-university / microbit-dal

http://lancaster-university.github.io/microbit-docs
Other
254 stars 130 forks source link

p12 reserved? #256

Open OwenBrotherwood opened 7 years ago

OwenBrotherwood commented 7 years ago

Current microbit.org doc has p12 reserved. It is also thought that this is/was a DAL reservation. Has or is DAL reservation of p12?

http://tech.microbit.org/hardware/edgeconnector/

/cc @jaustin

jaustin commented 7 years ago

David and I were discussing this today and realised we needed to write something up.

The accessibility pin was something that the BBC thought might be a good thing to do but unfortunately I don't think it ever got fully specified.

The BBC did do a lot of interesting accessibility work though. Sadly, I don't think it uses this pin at the moment - @finneyj is that right? I believe the idea was that this pin could be UART TX for a stream of accessibility data that an accessory could interpret/display,etc. It could be one-way, or we could try and do a 1-wire protocol over that pin?

@DavidWhaleIET and I wondered if the following could work: Have a weak pull-down on the pin by default. At boot, the DAL can check whether the pin is pulled down (possible issues with a shorted edge connector, etc?). If it is, then this accessory wants the accessibility data and we should configure this pin as UART TX and redirect the accessibility data over there instead of over USB.

Another option might be to boot with this line as a UART RX, and have the accessory send some specific commands, after which the TX and RX at both ends swap?

The reason to be convoluted about this is (a) to only use one pin and (b) to allow a completely normal DAL-based hex file to do the "right thing" without rebuilding with accessibility options turned on.

finneyj commented 7 years ago

@jamesadevine @OwenBrotherwood

Quite right - this pin was flagged early on in the project to support accessibility, but as the BBC started to work on apps etc, they concluded that routing accessibility over the USB UART was initially the most useful, so their effort was focussed on that. The current implementation streams relevant events and bitmap data from the LED display in a simple JSON format over UART. The view at the time was that this approach might lead to this pin being freed up for general GPIO use in the future, but we left it flagged as reserved in case other use cases came to light (in which case the UART TX line could be redirected to the accessibility pin)

We also thought about how an "accessibility mode" for the micro:bit could be enabled/disabled. As the BBC were developing accessibility solutions without any additional hardware, approaches as you describe above wouldn't really work (there'd be nothing to pull the pin high/low if the accessibility support took the form of a piece of software attached via the USB UART). Instead we opted for a bit of non-volatile storage in here: https://lancaster-university.github.io/microbit-docs/ubit/storage/ That way, a micro:bit could be configured to use accessibility mode, then all subsequent programs flashed to it would have accessibility features automatically enabled at boot time.

This is all implemented and tested through within a branch of microbit-dal (but I don't think it ever quite made it past stage testing before the BBC handed over to the foundation). Afraid i lost track of progress at that point.

This is another good reason for us to get that DAPLink patch resolved to enable persistent data to be stored, such that this can be enabled and made use of methinks...

If we also want to support accessibility hardware through the edge connector (which I think would be great), I'd suggest having a slightly different mode that would automatically bring up the micro:bit UART TX line on the accessibility pin. If we also need UART RX, things get interesting. :-)

OwenBrotherwood commented 7 years ago

Joe's ideas sound interesting. A soft way of allowing something that can be good to use. Please remember that there is still a possibility of a micro:bit v2 with more flash/memory but also more i/o.

If it can be done to the same price, the access to more i/o on the micro:bit could be i2c with the back pins receiving i/o from the device: however more flash/ram is a priority for onboard python/javascript ...

However, this would mean the use of a processor pin for interrupt and this could be the flagged pin 12. If micro:bit peripheral makers have used p12: it was flagged The other digital i/o pins have not been flagged.

Of course, more i/o in the same edge connector can be achieved with a back board as I have described in https://github.com/microbit-drill/baggybit

OwenBrotherwood commented 7 years ago

I am unable to try any DAPLink patches: no compiler that works without money 👎 I have an issue somewhere about that in the appropriate repo that I cannot remember just now,

finneyj commented 7 years ago

yes, using the I2C interface makes a lot of sense to me for external accessibility support. We could come up with a well defined interface for accessibility peripherals, and scan for them at power up. This would then transparently these devices and not take up any GPIO pins.

finneyj commented 7 years ago

p.s. yes, you're right about DAPLink build process - is a shame we can't use gcc here. We have some binaries of a beta somewhere...

OwenBrotherwood commented 7 years ago

I have one crazy idea about pin nr's.

A side comment: I don't like P0, P1 etc names We also have the processor names P0_1 (P0.1) We could also have P(i2c address)_1 with a problem of mapping the i/o used for interupt One could also have P0_1 for front and P1_1 for back connections (if they ever came) with name confussion for P0_1 for processor. "Life, don't talk to me about 'Life'"

DavidWhaleIET commented 7 years ago

Hi all,

Can you all hang fire on this until BETT is out of the way? I had a good long discussion with Ben last night, who did the original accessibility work. I'm going to write a 1 page spec first, make sure it meets the needs of our users, then propose it to the team for technical implementation. I think that is the best way. So, while all these ideas are great, let's not get carried away at this point with any implementations until I have confirmed the spec.

Thanks

On 19 January 2017 at 10:20, Owen Brotherwood notifications@github.com wrote:

I have one crazy idea about pin nr's.

A side comment: I don't like P0, P1 etc names We also have the processor names P0_1 (P0.1) We could also have P(i2c address)_1 with a problem of mapping the i/o used for interupt One could also have P0_1 for front and P1_1 for back connections (if they ever came) with name confussion for P0_1 for processor. "Life, don't talk to me about 'Life'"

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lancaster-university/microbit-dal/issues/256#issuecomment-273735279, or mute the thread https://github.com/notifications/unsubscribe-auth/AQFgdvYE9ugyAkf4TyVu-2tpzm2FnCPVks5rTzjygaJpZM4Lajet .

OwenBrotherwood commented 7 years ago

DAPLink build process: no Lancaster student fresh for a project? https://github.com/mbedmicro/DAPLink/issues/197#issuecomment-267016380

(BETT === http://www.bettshow.com/ ...?)

OwenBrotherwood commented 7 years ago

@DavidWhaleIET closing??? we have now found out that the pin is for great things in accessibility and full power has been applied. https://twitter.com/Laila_Mikaeel/status/827968552279871490

ngammarano commented 4 years ago

@DavidWhaleIET closing??? we have now found out that the pin is for great things in accessibility and full power has been applied. https://twitter.com/Laila_Mikaeel/status/827968552279871490

@OwenBrotherwood I cannot see the tweet as it says "This account's Tweets are protected." What does it say?