Re-reading the AT45DB041D Flash memory datasheet, using the chip like an oversized eeprom looks like it could cause us a few problems, namely because of the architecture of the memory. On page 4 of the datasheet, we can see that data needs to be written in 256-byte blocks, or pages as they are called.

Data is stored in an internal buffer before being transferred to/from main storage.
Although this might be useful for us in future, at the minute we're using Flash memory like a mini hard-drive: just somewhere to dump data to be read back at a later date. The use of buffers just adds an extra layer of complexity, so we'd prefer to skip these. Luckily, it is possible to do just this:

A main memory page read allows the user to read data directly from any one of the 2,048 pages in the main memory, bypassing both of the data buffers and leaving the contents of the buffers unchanged.

By sending the appropriate opcode (command to you and me) and a 3-byte memory address, it's possible to set the page number for reading/writing data. Data can be read/written serially from the start of each page. Should more than 256 bytes be written at a time, the chip simply crosses the boundary without delay or error. However, because we now have a bit more RAM to play with on the PIC chip, we're going to try to use our own buffering system in the PIC and transfer entire "pages" of 256-bytes to the Flash memory at a time.

After making up a board for our ScoreSure game score keeping device, and while waiting for the new QVGA LCD screens from Xing at NuElectronics we put together some code to try reading/writing to the new AT45DB041D 4Mbit flash memory.
As this will be a major part of the ScoreSure v2.0 device, we had to put a bit of thought into it.

The Flash memory organises data into sectors, blocks and pages and supports FAT file systems. It was very tempting to use this - to store bitmap images as JPEGs so that data can be easily dropped onto the device - but decoding images on the PIC so that they can be displayed one pixel at at time would take up a large part of the program space in the mcu. We decided in the end to use a relatively simple storage format, and use a header byte to tell the PIC which method to use to decode the image data.

For example, data could be stored in a palletised sort-of-gif format (albeit slightly different as GIF images need to be licenced!).An alternative method might be RLE (run length encoded) image formats - ideas for images with large blocks of colour. We may yet discover another (simple) way of compressing image data (JPEG is far too complicated to achieve decoding on a PIC) so the first byte of any image "file" stored in Flash memory will be a marker to tell the PIC how to decode it. This should give us plenty of flexibility to use different image storage methods.

The fastest way to get data in and out of the flash memory is serially - set a memory location, then clock the data in one byte after another. The PIC will be running at 20Mhz, and the Flash memory supports clocking data as this speed, so getting images out of RAM should be almost instantaneous.

Our first test will be to retrieve data for a bitmap 320x240 pixels wide.
We will do something simple like flash an LED on at the start of data retrieval, then off once all data has been dragged out. This should give us an idea about how long it would take to retrieve the image data for a full screen, full colour image.

Because we expect our images to be less than 320x240 and to use some form of compression for storing them, this test will give us absolute worst-case scenario values to work from....

We've been pretty busy here at Nerd Towers these last few days.
After receiving some information about the soon-to-be ScoreSure photo-frame-based-pocket-devices, we've been looking into creating and building a whole new PCB to put inside each one. The new device will be built around the PIC 18LF4550 and use a massive 4Mb Flash memory SPI eeprom (that runs at 20Mhz, not the pathetic 400khz used in the earlier device).



Some of the chips - the flash memory and, although not on the schematic there's a battery charge chip too - which are tiny little SMT (surface mount) chips. The flash memory was mounted onto a custom board quite easily (since our collective soldering skills seem to have improved in recent weeks) but the battery charge IC was a nightmare. We started out with about ten of them, but pretty soon were down to four: ping! "where's that one gone?" sh*te! Dropped one on the floor. These things are seriously tiny!




Look at the size of this tiny little tiddler. About the size of a speck of dust!


The flash chip was relatively easy to solder, after spending 45 minutes getting
the battery charge chip onto the PCB. As the eagle-eyed amongst you might have spotted, we've numbered the pins "upside-down"!

Here's an example of how a micro-joystick could be replaced with a three-button interface (click the buttons to try it for yourself).

The left- and right- most buttons are used to control the menu highlight bar (up/down) and the centre button is "select".

The "edit players" option makes use of mobile-phone style "soft-buttons". The increase/decrease letter buttons have not been coded, but it should demonstrate how player details would be edited. Although functional, we might change this and use a sort-of hybrid "soft-menu" approach: place a menu along the bottom of the screen and highlight the menu options (soft buttons) using left/right (similar to the way the menu option 5 screen works). So instead of pressing one of three buttons to perform an action, the user would highlight the action to perform, then act on it by pressing the middle select button.

This not only means a consistent interface (the red highlight being present in all screens, not just those with menus) but also it would be possible to have more than three "soft" buttons if necessary.

A (flash) demo will be posted here to demonstrate as soon as it's built!

It's the killer question, loaded with malice and intent. What do you mean "you thought you'd finished?". Just because the question has been asked, you know it's not finished.

The ScoreSure range of devices are almost ready to pop into an enclosure and put onto the shelves, just in time for Xmas. (in fact, they probably wouldn't be anywhere near ready for putting onto shelves, but making them in small batches and shipping them out for mail order might be a possibility). All that's left to do is to put all those delicate bits of electronic trickery into a nice plastic box and we're done.

After a bit of emailing around, it seems that the most cost effective way to achieve this is to use an existing enclosure. i.e. find something that uses a Nokia display, battery, eeprom and microcontroller already, and replace the gubbins with the ScoreSure contents. Easy.

The thing is, once we'd found something like this (a cheap LCD keychain for example) the end product is in danger of looking like an, erm, well... a cheap LCD keychain. And given that the cost of producing each ScoreSure device is much, much more than the retail cost of an LCD keychain, it would be difficult to convince customers to part with their hard-earned for something that looked like a, erm, cheap and nasty LCD keychain! So just at the final hurdle, we've hit hit upon (yet) another problem.
How to make something at a reasonable cost, but make it look like a top-end product.

Enter, our old friend Xing from NuElectronics. Luckily, he's interested in helping us out, not just in finding an enclosure, but in sourcing and assembling the ScoreSure device and he's found some lovely pocket-sized digital photo albums, complete with luxury leather-effect wallets!



So now all we need to do is find out what type/model screen it uses (apparently, it's a nice big QVGA 320x240 full-colour jobbie) and replace it's guts with our own MCU, eeprom and battery charge circuit and we're done.

Oh yeah, and re-write the code to work with this new, bigger display.
And since we've a nice big screen, it'd be a shame not to use it, so perhaps rewrite the font bitmaps so they're not so little and fiddly.
And if we can work out how to use a bigger eeprom, it'd be nice to get full-colour graphics instead of the monochrome ones we're using now.

So in short, once we've started all over again from scratch, spent a few weeks learning how to use the new hardware, then re-written all the microcontroller code to use a three-button interface instead of a micro joystick, we shouldn't be too far off having a working prototype.......

That's right!
We've taken the time to put together a YouTube video of the ScoreSure Petanque Pro device. It includes "quick" and "pro" game modes. Don't know what that means? Watch the video to find out!

With the first ScoreSure device finally complete and ready to put into an enclosure, work has begun on the software used to transfer data to and from the onboard eeprom.
This custom VB app sends byte streams over USB to the device, and can

• edit/update player details on the device
• retrieve any new players added to the device
• download scores from the device
• upload scores to the scoreresults.co.uk website

At the minute, the software is just a bunch of VB forms, but screenshots will be posted here shortly!

That's it.
Finished.
Finito.
Done. Complete. Put to bed.
ScoreSure Petanque Pro is coded up, utterly and completely, with no further coding needed. It's done. And works. And all the nasty little bugs have been ironed out, and all the failsafes are in place (such as saving info to eeprom as you go along, so nothing gets lost in the event of a power failure).

In fact, adding in the power-failure auto-save-as-you-go code has allowed us to implement a new idea - it's one that's bugged us from the start: how to tell whether the device is running off the battery, or from a USB supply. In our early schematics, we used a diode from the USB port, onto the power rail, with a connection "behind" the diode to a pin on the microcontroller. If a signal is received on this pin, power is being supplied by the USB port. If there's no signal, power must be coming from the battery.



The only problem with using a diode is the voltage drop across it is about 0.7V, leaving just 4.3V from the USB port into the device. This is right on the limit of working voltage for the LCD screen - our original idea was to power the LCD from the PIC micro, and if we were in USB-powered mode, the LCD simply does not switch on (the PIC and EEPROM are low-voltage versions: 18LF2455 and 24LC256 - the "L" in each means "lower voltage" - and can operate at voltages as low as 2.5V).
This is a bit of a kludge, but a workable solution.
The only issue with this is that the "check to see if you need to start in USB mode" occurs only at the beginning: once the device has been started in USB/non-USB mode, no further checks are made. So it's quite possible that the device could be running off the battery, then is plugged into the USB port. Although the device is now powered from the USB port, it still thinks it's being powered by the battery, so does not try to communicate with the host PC.

Now, by allowing the power to be dropped at any time, we've allowed ourselves the luxury of a slide-switch to change modes. This is perfect as not only does it provide a definite switch over between battery and USB mode, it also provides physical isolation between the two power circuits. The switch means that ONLY battery OR usb power can be drawn, and never the two together.

The slide-switch can also be used as an on-off switch for when the device is used "out in the field". Slide to "battery powered" and the device not only boots up using the battery as a power source, but it restores itself to the last state it was in: no more having to go through the start menu and choose player etc, simply switch on and carry on from where you left off.
Likewise, once you're done, slide the switch over to "usb-mode" and the battery is completely isolated from the circuit, meaning no unnecessary power drain.

Genius!!

Coding is almost complete for Petanque Pro and we've introduced a new feature which will become standard on all ScoreSure devices - a player "database". In using the Petanque Pro at a recent game, it quickly became obvious that entering player names, one character at a time - however impressive the achievement is technically - is a bit of a pain in the arse. Especially when playing in the Brighton and Hove Rolling Melee tournament, where you team up with a different player for each and every game. What a nightmare that was!

So it seemed far better to have a number (up to twenty) different player names pre-loaded into the device EEPROM memory, and to make these available to select, when entering/selecting players for each tournament.

This is a brilliant improvement to the device and makes it much more user-friendly.
The only problem is that is requires a lot more memory space, so results need to be stored differently and at different addresses. In short, any device which wishes to make use of the player database idea (i.e. all of them) will need to be re-coded to allow for this: not just a bit of code added to the beginning (as we'd hoped) but any routine that makes use of EEPROM will need to be updated.
In short, more or less (another) complete re-write for each device!

Bugger.


The menu and bitmap need a little tidying up!


Use up and down to select menu items. In this case, we've even included the
tricky "3 versus 2" team set-up (one doubles + one triples)


Up and down changes the highlighted player. Left and right scroll through
the player "database" and changes the entire player name without having to edit
them one letter at a time


See how the entire name changed in one go? (of course not, this is a series of
still photographs. But trust me, it does!) Press the joystick button down to edit names


It's not gone away you know! That's right, the "old" method of entering individual
player names, one letter at a time, is still there. In case you made a spelling mistake,
or someone turns up to play who isn't in your database of players. To edit a name
press the joystick button down. Up and down changes the letter, left and right highlights
the next letter in the name. Click the button down again when you're done.


The screen we've all been waiting for - entering results. In "Pro" mode you can
record the distance the end was played at, as well as who scored the points for each "end".


As the scores for each "end" are entered, the final score is automatically updated.
Repeat and play for as many points as you like (in Petanque, the default is 13, but
sometimes a short game is only played up to 7). When you're done, return to main menu.
Your scores are safely tucked away in the onboard EEPROM, ready to be uploaded to the scoreresults.co.uk website.

On top of all the work that's going on at Nerd Towers, we're looking to launch a Geeky Gadgets Store in the next few weeks, with a view to going live before Christmas
(so by current standards, we'll be ready to go live in July 2010!).

There's been a link on this website for some time, but no store behind it. Well that's about to change! The store will include most of the projects that we've discussed on the blog, in ready-to-make kit form. Each kit will include background about the project - how the idea was developed, the technologies used in the final product and ideas on how to expand or "hack" the kit to make it do other stuff.

First kits will include:

• Radio-controlled switching gear
• Servo controller board with playback
• Cube/dice interface
• Theremin-type MIDI-based sequencer/controller

as well as the prebuilt ScoreSure game-keeping devices!

After discussing the idea through with Ben Ten we've decided that the cube tray/holder should be big enough to hold just a single cube. The idea is that the trays are "chainable". Each tray has two input and two output pins which talk to the next and previous trays in the "chain" (the idea was based on a chain-linked list, a commonly used data structure in programming and something we've successfully implemented in Robot Steve's Robot Studio software).



All trays set and keep RA4 (prev out) and RC2 (next out) high.
These pins are used to send a signal to adjacent trays in the chain, to tell those trays that another tray exists "previous" or "after" it.

Pin RC2 (next out) on one tray is connected to RA2 (has previous) on the next tray in the chain. The first tray in the chain has RA2 (has previous) pulled low via the pull-down resistor, so that it knows if it's the first in the list. If a tray has a high input on RA2, it knows that there's a tray earlier on in the chain. Each tray starts its dice-reading sequence either when RA2 is low or, if RA2 is high, when it receives a signal on RA0.

The tray starts its dice-reading routine, activating each pin of RB0-RB3 in sequence, and checking for a response on the serial pin. If a response is received when any of the RB0-3 pins are high, the response is deemed to have come from the dice in the tray. When a response is received, the tray sends the message back to the previous tray in the list (via pin TX) if it's part of a chain, or drops the message onto the USB buffer if RA2 is low. So a tray can receive messages either from a dice in its holder (message comes in while one of the pins RB0-5 are high) or from a tray further up the chain (the receiving tray will have finished its dice checks and pins RB0-3 are all low).

If a tray decides that the message has come from the dice, it appends it's own tray ID to the message and either sends it to the previous tray in the chain, or drops the entire message onto the USB buffer.

After completing the dice-reading routine, the tray sends pin RC0 (to next) high.
RC0 from one tray is connected to RA0 on the next tray in the chain. (RA0 is the trigger pin to start a tray off on it's own dice-reading routine).
The mcu then enters a "wait" state, monitoring RC1 (from next) for a high input.
RA1 (to previous) on one tray is connected to RC1 (from next) on the next in the chain. So when a high signal is received on RC1, this tells the tray that all other trays up the chain have completed their checks.

If RA3 is low (there is no tray next in the chain), the tray immediately sends RA1 (to previous) high.

When a tray receives a signal on RC1 (from next) it exits its wait state, and goes into "wait for signal to start" state - either waiting for a high on RA0 (from previous) or RA2 to go low (when "has previous" is low, it means there's no tray earlier in the chain).

This way, we've built a "collapsable" signal and each tray in the chain knows whether

• it's waiting for a tray earlier in the chain to complete
• needs to perform a dice-reading routine
• or that it's completed its checks and is waiting for trays later in the chain to complete

In theory it sounds ok. It make take some time to make up four or five prototype devices to test the whole message-up-and-down-a-chain idea fully!

One of our earlier posts mentioned a small, quick turnaround project which was a cube-based interface.
A few hours down at The Skiff with Ben Ten of RobotBrighton and BuildBrighton fame, and a working prototype was made on a breadboard. The proof-of-concept was complete: a PIC microcontroller was coded to simply broadcast a message, when powered up, outputting a unique device ID, and a value from 1-6 to say which of six input pins were activated. The data was broadcast to an Arduino board using serial communication and it looks like the disco dice idea is off the blocks.

Over the coming few days, we'll inviting Ben to join the rest of the nerds, to build a tray/holder for the cubes, and actually developing some software to make use of this unique interface idea. Ben already has ideas for developing the cubes into a kit form, allowing people to make their own, at home, for very little cost.

This is an exciting little project which has a lot of potential - especially if handled correctly: a bit like an iPhone, what Ben's developing is really a platform, for which other people can write apps and use in any way they like.
Already we've discussed possible uses, including

• multi-track midi sequencer
• wav/mp3 based sample player
• puzzle games
• combination/puzzle lock
• interactive/digital board games

There are probably loads of other things this could be used for.
The key thing now is to get one built and see if it lives up to it's promise!

In preparation of a demonstration to a business class at Brighton University, arranged by none other than Dr Clifford Conway, we've been busy making up clones of the (only) ScoreSure prototype device.


It was an interesting experience. It certainly taught us that the current prototyping method is only good for prototypes and not for "production quality" manufacturing, given that only one out of the extra three we made actually worked first time. Then again, it may be down to the fact that our collective soldering skills are just short of "shocking", and that one too many bridged connections meant more than one fried microcontroller. The newer, smaller PCB is on the left, and includes sockets for the MCU and EEPROM chips (because we couldn't afford to keep soldering them to the board, then frying them with a dodgy connection). The actual PCB is exactly the same for both - the difference being a bit more time was spent cutting the later one, actually following the cut-guidelines!

As far as the demonstration went, it was an interesting - albeit brief - opportunity to gauge interest in the ScoreSure device, and at least three different groups asked for more details and an email address to pursue the idea further. Chris Holden went up to the uni to represent us and concentrated on launching the ScoreSure range of devices, so here's hoping that, with a bit of assistance, it won't be too long before we're ready for a commercial launch.....

It's been a few days since "Black Wednesday" but the Score Results website is up and running again, in it's new found glory (it got a makeover during the rewrite). Not completely, mind, but enough to display league tables and to allow players to log in and view their result histories. Still in progress is the "submit results" section so the league tables for boules/petanque that are on there are a little out of date (there were another nine games played in the howling winds yesterday which need their results entering!)

There's also a lot of excitement about the BuildBrighton group "Theremin" project and it's illegitimate bastard offspring, the Not-a-Theremin

Not forgetting the disco cube idea from Ben Ten of RobotBrighton/BuildBrighton fame, there's been quite a bit of development on this too (ok, a few ideas kicked around and a few mock-ups made on breadboard proto-boards).

And of course, the ScoreSure range of devices are still in development (yes, STILL not boxed off and put in an enclosure yet, but it's getting there!) but that's mainly because in order to demonstrate them fully to potential retailers, the full end-to-end process needs to work (and the entire website for hosting the results got mysteriously deleted!)

All in all, October looks like it's going to be a busy old month!