The middleware should autodetect the breakout board connected and show the capabilities to the user programs. It should also connect to a monitor/simulator to show the current status of any inputs, and allow outputs to be driven. The monitor should provide helpful suggestions/warnings e.g. if the user tries to drive an input pin. Consideration needs to be given to allow multiple boards to be connected, and how they are distinguished.


The top of the middleware connects to a range of programming environments that the young people will use. These will likely include scratch, ruby and python. The calls should be consistent across languages for corresponding functions. The API will provide either a memory mapped style, for more advanced programmers, or a more friendly version for beginners. Where possible safety checking should prevent harm and raise a friendly pointer. Helper functions may be available to wrap certain processes. e.g. format conversion or smoothing over time.

The bottom of the middleware connects to the device drivers which abstract away, how the board is communicating with the Raspberry Pi. Clearly it shouldn’t be hidden magic, but it’s not something that needs to be visible right away.

Most importantly it should be a friendly experience and not get in the way of achieving exciting results when integrating with hardware.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s