As the video shows yesterday we can toggle relays from the PC. Today we can read the voltage in from an analogue sensor. Since all (until we realise we’ve forgotten something) the hardware is tested, next step, is the PCB design!
We decided to change the hardware architecture more details will be announced soon. We decided to make it so piface would work with mobiles (with Android and USB OTG) and desktop PCs. It’ll still work with Raspberry Pi, through SPI but it will also work through USB. Here’s the hardware equivalent of ‘hello world’ – a led that flashes through PC control.
Initial Hardware Design with microchip IO expander to drive outputs
and corresponding PCB
- It’s fairly simple and cheap, easy to build etc. but might be a bit limiting as components are fixed and it’s limited to SPI – I’ve still got concerns about how hard it will be to write the drivers without knowing the SPI registers for SOC
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.
It is proposed to abstract the hardware away from beginners and provide a consistent api across different I/O boards and different methods of connecting to the raspberry pi. This also allows for a monitor and simulator to aid in debugging and experimenting.
It is proposed to abstract the hardware away from beginners and provide a consistent api across different I/O boards and different methods of connecting to the Raspberry Pi. This also allows for a monitor and simulator to aid in debugging and experimenting.
What are we trying to build?
It’s got to be easy and it’s got to let you have fun — we’re targeting kids. So what does that relate to.
- Easy to get going – plugin and go
- Easy to see what’s going on
- Forgiving – robust and provides guidance on errors.
- Cheap/easy to obtain (be that pre-made or as a kit)
It doesn’t need to provide top level performance (beginners would tend to struggle to write fast enough code anyway), so we don’t need to worry too much about response times or latency.