The micro:bit calculator (2)

As detailed in chapter 1, to read all the info off the keypad I needed 8 analogue pins.  There are only 6 on a micro:bit though, so my solution required 2 micro:bits.

At first that was a real buzz kill – it seemed way too OTT a route to go down and I put down my keyboard and gave up.  But I really wanted to see that keypad working and found myself gravitating back to the project a day or two later.

In the end it turned out I actually needed to use 3 micro:bits:

The micro:bit has 6 pins that can perform an analogue read: 3 are ‘touch pins‘ (pin0, pin1 and pin2) and the other 3 are ‘analogue pins‘ that are also connected to the screen.  This means that any activity on the screen impacts on the analogue reading for the 3 analogue pins, and THIS INCLUDES LIGHT LEVELS IN THE ROOM!  In testing I found using the screen would prevent the associated pin from working predictably.  To use the analogue pins to monitor for keypad button press events I would have to disable the screen on the 2 micro:bits I used to read the pins. 

This means using a third micro:bit as a VDU.

The 2 micro:bits used to read the keypad are connected as shown below:

Which looks quite inelegant in the real world:

The micro:bit on the left above is the ‘Master’, and it is connected to the 4 columns.  The one on the right is the ‘Slave’ and reads the rows.  Both use the same code, but each has a hardcoded global param indicating which type they are.

Note: A key-press event is recorded when the analogue reading on one AND ONLY ONE pin is greater or less than the threshold (chapter 3 goes into a lot more detail about these thresholds).  This means that if the Slave or Master record activity on 2 or more pins simultaneously it is ignored.

From the moment a key has been pressed the process progresses as detailed below:

  • When the Slave records a key-press event it sends info about the event over radio.
  • When the Master records a key-press event it monitors the radio waves to see if a similar event has been recorded by the Slave.
  • The Slave sends the info over radio a few times per event – 10 times in a 250ms period.  During that period it does not monitor activity on its pins.
  • The Master waits 250ms after a key press event to see if an event from the Slave is being broadcast.  It too stops monitoring its pins during this period.
  • Where the Master has recorded an event on its own pins, and has received details about an event on the Slave, it will compile the 2 pieces of information to infer which one of the 16 keys has been pressed.
  • The Master will compose this information into a string, which it sends over the radio to the third micro:bit, which is acting as the visual output device / screen.
  • The micro:bit serving as a screen monitors constantly for radio messages (which means that it has to ignore the messages sent by the Slave).  When a legitimate message (from the Master) is received it displays the associated key.
  • After the screen has processed a legit message it chills for 250ms and clears out its radio queue.

Now that all sounds relatively simple (albeit convoluted) and it is.  I have stated elsewhere that I found it very difficult to get this working though.  The most significant challenge was in optimising the analogue thresholds (the analogue readings at which the system would infer a key-press event has occurred).  I’ll go into more detail on that in the next chapter.

Next: The micro:bit calculator (3) – (currently WiP)