In depth with the TwitALU software

We’ve touched on this area before with the software layout and planning post but a lot has happened since then. This includes a GitHub repository where the latest version of our code can be found here. If you fancy having a read through it and reckon you have spotted any problems or know a better way of doing things then let us know and we’ll look into what you’ve spotted.

Work in progress system class diagram

Work in progress system class diagram

For the most part it is structured just like the diagram suggests we had it planned. A cool feature of the project is that the code is portable to other platforms, with just a simple rewrite of the lowest level classes – I2C and Quick2Wire. This means that you could implement the TwitALU on completely different hardware – for instance on the BeagleBone Black or even an ARM based mobile phone.

It hasn’t changed much throughout the development process except at the very top when we have been choosing between a program that runs continuously vs one that has to be run whenever we would like the system to go and get ‘jobs’ from Twitter to process them.

We chose one that runs constantly in the end as it allows us to keep track of how long it is since we last went to Twitter automatically. Now, you’ll be wondering why that matters, well, Twitter limits the number of API calls that can be made in a set time period. The upshot of this is basically; you are allowed to make 15 calls (for the most part) to each API item in a 15 minute period. If you exceed this then you get blocked for the rest of the 15 minute period you are in. If you make a habit of exceeding the limit then your API access keys will be revoked completely.

The middle section of ‘translation’ between incoming commands from Twitter and the hardware control below has somewhat changed but it’s doing much the same job. Turning the high level command information into what amounts to 6502 assembly instructions which then are turning into the commands to be send out to the hardware.

To save long boring explanations of every last bit the best way to get to know the code is, as we said before, to go and have a nose through the code base on GitHub and see how it does things.


Leave a Reply

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

You are commenting using your 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