There's not much more to add, than these reviews of Foodilic in Brighton, just down the hill from the Clock Tower. £6 for an all-you-can-eat buffet.

Not a stupid stuff-yourself-til-sick-on-fried-junk kind of buffet either.
This is a real, home-cooked, beautiful meal on a plate. If you've never been, do yourself a favour: forego the cappucinnos for once and spend your money on a proper, healthy, tasty, delicious dinner.

And the best thing? They do take-out too!

Here's an idea that came up at a recent RobotBrighton meeting - something along the lines of siftables-meets-dice reader (but perhaps a little simpler). We hope the proof-of-concept can be achieved quite quickly, so as not to interrupt our plans for launching the ScoreSure range of devices, but it seemed like a bit of fun, so here we go:

The idea is to build a UI (user interface) that uses physical blocks, placed into a tray/holder. A bit like putting dices into a dice reader (but because that analogy caused all kinds of confusion, we'll never mention dice again). When a block is in place, we need to know:

a) which face is up (or down, as necessary)
b) the orientation of the cube
c) (maybe future development) which cube from a choice of many has been placed

Other "limitations" included how to power each cube, accessing a battery in indeed batteries were to be used (even the little button type batteries).
Because of the way the UI works, each cube would offer 24 (6 faces x 4 degrees of rotation) possibilities: a reasonable number of options from which to make a workable user interface.

Here's what we came up with:


Each cube has three contact pads on each face. When placed in the holder, these pads make contact with one set of four sets of contact pads in the tray.
Each set of contact pads consists of power, ground and a serial data line (TX from the cube, RX in the holder). The holder/tray puts +5v to the first power contact in the tray. The cube contains a PIC which is programmed do nothing except transmit an identity number over serial comms. If the cube is in contact with the pads in "position" one, the tray/holder will start to receive a message from the cube. If no message is received, we know that the cube is not turned around in position one. The holder then puts +5v on the second power contact and waits for a response. If it receives one, it now knows the orientation of the cube is "position two". The holder repeats this process on each of the four sets of pads, over and over again.


The cube has a number of common ground and TX pads. The power connections are joined through a series of diodes and each power connector is sent to an input pin on the PIC. This way, the dice knows which set of power/ground pads caused it to "wake up", and returns this information back to the base along the serial data line.

Because the cube only ever transmits data, and the tray/holder only ever receives data, we need only one serial data line.

When the cube is transmitting, it can broadcast a unique (serial number) identifier plus one byte of data (or even just a few bits superimposed over one of the bytes being sent) to tell the tray holder which set of contacts were used to activate the cube.

On the face of it, this meets all the criteria:

• The cube knows which set of contacts caused it to wake up - i.e. which face is face down in the holder/tray - and broadcasts this information whenever it is activated.
• The cube has a unique id number (perhaps in eeprom) which is broadcast along with its "facing" so that we can distinguish the messages of one cube from another.
• The cube has no need for external (battery) power - it takes power from the tray/holder and when not in place, the PIC inside it does not need to be running.
• The tray/holder knows which of the four sets of contact pads the cube responded to, and in which case knows which way around in the tray the cube must be.

In future, the tray/holder could be expanded to allow multiple cubes to be used together. An exciting hardware based UI with lots of possibilities. Already we're talking about "disco dice" - each cube face can represent an instrument, and each instrument can have up to four different "riffs" which can be played through a software app. Rock on!

That's right. No more messy wires, breadboards or power cables - the ScoreSure device is finally mobile. After building a PCB and testing it (can you believe it actually worked first time?) the only thing to do was fill the eeprom with bitmap and menu data.

Bitmap data was generated using a custom VB app and loaded into eeprom by putting the device into "usb mode" and connecting the USB cable to our 4-pin USB header (making sure the D+ and D- connections were the right way around!).

Work is in progress to convert this VB app into a Flash-based/online app.
Already done is the menu generating software. Here's an example of how we generated the menu data:




After drawing the menus and generating a "byte-stream" this data was loaded into eeprom using the same method as we did for downloading bitmap data. Here's a screenie showing (confusing as ever) the ScoreSure Golf Pro opening screen bitmap (it was the only one to hand at the time) and the start menu from the ScoreSure Petanque Pro device.

Here's the latest ScoreSure device, running from a lipo battery, in pocket-sized form (off the breadboard) and displaying the opening screen. Confusingly, I coded this particular device up as a petanque score-keeping device but the only image I had to hand (in ready-to-use-for-the-Nokia-byte-array format) was the golfer from the ScoreSure Golf Pro.

That aside, the golfer bitmap appears as expected, without the need to edit anything. What is a little confusing is that the ScoreSure logo is completely messed up (it should look something like this.)

Also the brightness/contrast on this particular shield (it's called Color[sic] LCD shield v2.0) needs tweaking a little bit - I don't know if it's overvoltage from the lipo (i.e. it's giving out more than 5v) or whether it's the shield (which appears to have changed slightly from the earlier version).

That said, it shouldn't be too long before we have a working ScoreSure device of some/any description!

The moment of truth had arrived - a brand new PCB had been made up and installed onto the back of the Nokia shield. All that remained was to connect it to power and go out for a celebratory drink:


Check it out! Powered on and fired up! The screen looks lovely - it's taking its backlight power from the microchip (which in turn tells us that the MCU is working) but where's the little golfer bitmap and our opening menu?


The screen displayed a whole load of vertical lines and very little else.
At first this was a bit disappointing. But then we remembered that the first command in the ScoreSure device (after setting up the LCD and so on) is to draw the opening screen - and that means getting data from eeprom to use for drawing the bitmap.
The brand new eeprom on the PCB reads empty values as 255. So the device is drawing a sequence of 255 pixels in one colour, the flipping the background/foreground colours and drawing another line of 255 pixels. The bitmap routine draws pixels vertically (top-to-bottom) so when you think about it, if every value read back from eeprom is 255, it makes sense that the display shows just a whole bunch of lines and very little else.

How to get the bitmap to show?
That means connecting the device to a USB port and running the various custom-built apps to fill the eeprom with bitmap and menu data. Luckily, doing that shouldn't be too difficult: after all, we have a USB 4-pin header, ready to accept a USB connection.


The device connects and appears in the device manager as a valid USB/HID-compliant device. So all that remains is to drop the bitmap/menu data onto the eeprom chip.
That could be a job that takes ten minutes, or it might prove a bit tricky and take all night. It's not quite midnight as I'm typing this, so it looks like that's a job for the morning..........

Following the (let's be honest, rather poor) 100th blog post, I spent a bit of time reading through some of the earlier posts. It strikes me that the earlier posts were a lot more in-depth, as ideas were tried out, and learning explained in a step-by-step basis. Some of the earlier posts are really quite informative, with later posts being more along the lines of "this is what we've done, here's an update".

I think it's time we went back to more informative blog posts, so here's one.
It explains how we got the ScoreSure device off the breadboard and into a pocket-sized device:

After designing the PCB layout, the next stage was to print the layout onto some Press-n-Peel. A hot iron and five minutes later, and the PCB is pressed onto the copper clad board ready for etching.


The etching powder we used this time was Ferric Chloride. It's a brilliant yellow/brown colour which stains everything it touches! On the plus side, it can etch a 4-inch square board in just a couple of minutes (just place the etching container inside a hot water bath and jiggle the board around for 3-4 minutes).


We didn't bother with ground and power planes, so the etchant had quite a lot of work to do! (including ground/power planes is a good idea for two reasons: firstly, nice big power tracks reduce the possibility of dips in voltage; secondly, large areas of exposes copper means less etching is needed - which in turn makes the whole process much quicker).


Here's the etched board after it's been drilled. Each hole (count 'em, there are seventy-four!) was hand-drilled using a PCB drill - although it sounds tedious (it was) it's actually just as quick (or slow) as using a Dremmel and pillar stand - although the actual drilling process is slower by hand, positioning and lining up the drill bit is much quicker/easier without a rotating bit to worry about.


The first thing to do after drilling the board was to install the pin header/sockets along the top and bottom edges of the PCB. Once these were in place, it was possible to check the alignment of the board against the Nokia screen and shield. The photo above shows that only some of the pins from the shield were actually used to connect to the PIC.

Here's the etched and drilled board installed onto the reverse of the Nokia screen shield:


Now that we can be sure that our shield fits onto the back of the Nokia board, it's time to install the components - which consist mainly of an 18LF2455 PIC, 24LC256 eeprom (the L in the serial number in both the PIC and the eeprom means it's a low-power version, running off 2.5v-5.5v) a few discrete components (resistors, capacitors, 20Mhz crystal) and some pin headers.


There are two headers on the board - the one at the top, to the right of the PIC, is the 5-pin ICSP header, which allows us to program the PIC without having to remove it from the board to place into the programmer (which is just as well - the PIC is soldered down!)

The 4-pin header at the bottom is for connecting a USB cable to the PC.
This will enable us to transfer data to/from the eeprom chip once the PIC has been programmed with the appropriate ScoreSure device code.


The plug hacked onto the back of the device was added as an afterthought!
With the Nokia shield in place, there was no way of getting power onto the 5v/ground pins - either via the USB header (it is obscured by the screen when it's in place) or any other means. The small plug allows us to connect the device to a lipo 3.7v battery while the screen is in place, even though it's a bit of a kludge! The +5/ground wires from the plug were soldered directly onto pins 1 and 4 of the USB header (which take 5v/ground from the PC when connected). Obviously in a final design we'll need to isolate this for now it's ok, as long as we remember to disconnect the battery before plugging in the USB cable. (in the final design, we'll probably have a simple switch or maybe even use the reset button somehow, so that the device knows the difference between being plugged into a battery - in "mobile" mode - and being plugged into a PC - in "download" mode - and can enable/disable USB comms accordingly).


So far, so good. Everything looks ok but that's no guarantee that anything will happen when we put power onto this thing. In fact, it's pretty well guaranteed to do absolutely nothing just at the moment - after all, we've not programmed the PIC yet!

Luckily, DonkeyProg recognised the PIC as an 18F2455 and programmed it at the first attempt. Validation went through a treat, so as far as we can tell, the PIC now contains our ScoreSure device code. The last thing to do is connect the PCB to the Nokia shield, attach the battery and see what happens.............

It was bound to happen wasn't it?
I noticed on the last post that the count went up to 99.
So I thought I'd try to make the 100th post really interesting and informative, rather than just some boring mindless rubbish about how great it is to have posted 100 articles and still actually have kept enough interest to keep posting on this blog.
Then again.........