HURSLEY, U.K. - 11 Mar 2011: More than 450 students from 80 schools across the South of England will be celebrating National Science and Engineering Week at IBM’s 16th annual Blue Fusion event. The students will need to use quick thinking, scientific knowledge and teamwork in a number of fun activities, designed to inspire and encourage young people to develop their interest in Science, Technology and Engineering.
“Communication” is the theme for National Science and Engineering Week 2011 and volunteers from IBM Hursley, Europe’s largest software development lab, have put together a wealth of fun, inspiring and engaging activities.
Each day, teams from 16 schools will participate in a variety of specially-designed activities promoting innovation, teamwork, problem solving and communication skills. Students solve puzzles and technological challenges that explore basic concepts in some of the most interesting areas of modern technology. The activities will include building network communications to cracking codes to designing an ecologically friendly house. The students will experience first hand how science benefits our everyday lives and how instrumented, interconnected and intelligent technology can help build a smarter planet.
Approximately 200 IBM employees volunteer their time and experience to Blue Fusion, many of whom are recent graduates who can share their passion and experience of working in the industry with the next generation. Local dignitaries will be attending the event throughout the week to see the impact and success of Blue Fusion in inspiring young people into Science, Technology and Engineering.
I look forward to hosting schools on Thursday – it has been fun being involved for the last five years, so should be great this year too! I wrote briefly about Blue Fusion and Bright Sparks in 2007 (I can’t remember if that was the year I organised and ran Blue Fusion with Dan)
There are one or two videos about Blue Fusion which really show what the event is about:
I had a spare Matrix Orbital 20×4 character LCD floating about so I decided to try and connect it up to my Arduino. The display is a LK204-25, which is a brilliant little serial display, with support for a 25 button keypad and six outputs that can be used to control power to something else.
Being a serial display, I could just write to it from my Arduino using the serial interface, but that would mean that I lose the ability to communicate with my Arduino from my computer over serial. Fortunately the display also supports I2C as an interface (some similar, but newer, models also contain a 1-wire interface and a temperature sensor built in).
It turns out that getting the display to work with my Aruino Uni, using I2C is rather trivial. The display needs power, that is easy enough, and then there are just two wires to connect from the Arduino – Analog pin 4 for is SDA, analog pin 5 is SCL. Connect those two up to the display (the display docs show which pins SDA and SCL are) and you are ready to write the code to control it.
It turns out that I2C has fantastic support in Arduino, Wire.h contains all you need. The code below will read a character from the serial connection from your computer and write it to the display. Easy, eh?
// Note the space after the . in the imports below - This blog seems to object to not having it there#include < wire.h>// default MatrixOrbital lcd address (0x5C) converted from 8bit to 7bit#define LCD (0x2E) void setup(){
Serial.begin(9600);
Wire.begin();// Initialise display with clear command
Wire.beginTransmission(LCD);
Wire.send(254);
Wire.send(88);
Wire.endTransmission();}void loop(){if(Serial.available()>0){char c = Serial.read();
Serial.write(c);
Wire.beginTransmission(LCD);
Wire.send(c);
Wire.endTransmission();}}
This is a very geeky topic, but I was having a conversation at work today with someone who was trying to do several really simple things in parallel in perl because they didn’t want to wait several minutes for each one to finish. They had knocked up a change to the existing perl, but had tried to do it using perl threads. Normally, that would be fine for most boxes, but when you are running rather old perl on various unixes, including under USS on the IBM z/OS Mainframe, you tend to find out that perl was not compiled with thread support (and recompiling perl for the mainframe is not the easiest thing in the world).
I suggested that they simply use fork() to do the same thing with multiple perl processes, and having not done this in quite a while I tried to search for a good example but couldn’t find anything that looked both complete and simple enough to explain quickly – Hence this post…
#!/usr/bin/perl use strict;use warnings;sub main
{my@children;foreachmy$i(reverse(1..3)){my$pid=fork();if($pid){#If $pid is non zero, then the parent is runningprint"PID $pid forked ($i)\n";push(@children,$pid);}else{# Else we are a child process ($pid == 0)my$rc= child($i);exit($rc);}}foreachmy$n(@children){my$pid=waitpid($n,0);# waitpid returns the pid that finished, see perldoc -f waitpidmy$rc=$?>>8;# remove signal / dump bits from rcprint"PID $pid finished with rc $rc\n";}}sub child
{my($arg)=@_;print"$arg: start\n";sleep$arg;print"$arg: end\n";return$arg*2;}
main();exit;
And the output of running the above code is as follows:
PID 16767 forked (3)
PID 16768 forked (2)
PID 16769 forked (1)
3: start
2: start
1: start
1: end
2: end
3: end
PID 16767 finished with rc 6
PID 16768 finished with rc 4
PID 16769 finished with rc 2
It is worth remembering that because each process gets an entire copy of the memory, you have to do more clever things to actually get the processes to talk to each other – but if all you want to do is run something and get a return code back, the above example should get you going pretty quickly.
Are you using an Arduino Uno on Linux? If so, you may have noticed that writing to the serial port in a loop can cause the Arduino Editor/Programmer software to appear to lock up, or even Linux having trouble using the serial port for your Uno.
It turns out there was a bug in the USB->Serial firmware on the chip which caused this [1], and it is quite easy to update your arduino to fix it. According to the author of the USB->Serial firmware, it is not possible to break your Arduino permenantly doing this [1], but I can’t promise anything (though it worked fine for me and others)
The md5sum of the Arduino Uno file from the 4th December is 8e01ee236e70bbea43f7eb4e11c9688a
You will need the dfu programmer tools, which are conveniently in Lucid/Universe, so just run
sudo aptitude install dfu-programmer
You need to do a hardware-reset to put the chip into the correct DFU programming mode, which is simply best explained with the picture at http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1285962838/10#10 (you will need to register on the arduino site to login, but a picture speaks a thousand words)
The Uno’s use a AT90USB82 serial-usb chip, so we then reflash the firmware with the following commands
Recent Comments