LCD display progress (or lack thereof)

The Sure Electronics DE-LD021 LCD display module, AKA LCDSmartie whilst looking promising in the first instance turns out to be a bit of a dead loss.  The manufacturer doesn't seem to know the codes to drive the display.  Perhaps he just ripped off some other design and doesn't actually know.  He keeps repeating 'you must us CP2102 driver for Linux' like a broken record.  I guess making use of the display for Linux requires reverse-engineering the LCDSmartie software (which seems to be written in Delphi) to try to obtain the codes and then use them from Linux, which I don't have time for right now.  Big shame.

Edit:  To all those responding, many thanks for the comments, and sincere apologies for not publishing them sooner, but I've been out of the 'blogo-sphere' for some months!

LCD arrived

My Sure Electronics DE-LD021 serial LCD has arrived, unfortunately no info on how to program it (yes I did a search).  They say it works with LCDSmartie, but there only seems to be a windows version of that.  Waiting for the reply from the manufacturer about the spec for commands.  I noticed that the PDF says to use LCDSmartie, a Winblows program to communicate with the display.  There was a linux version under development, but it got discontinued.  They just recommend LCDproc or something else.  The PDF says to configure LCDSmartie for 9600 baud communication and 'matrix' driver, so I tried the MtxOrb driver in LCDproc with the same settings.  Now I got something happening when I ran LCDd, but there was a fair amount of garbage on the screen, so I don't know if I've got the right settings.

As for the display, it looks nice.  Reasonably quality and viewing angle.  Its a little large, being larger than a 5 1.4 inch drive bay height which is what I was expecting from the picture, still both dimensions and even circuit diagram are in the PDF, so I could have checked.

All in all I'm quite happy if I can figure out the command-set.  I guess they don't want to advertise the fact that it's Matrix Orbital command-set for copyright reasons or somesuch.

Biffboot enhancements.

I've long been concerned about the fact that once you close a Bifferboard box it makes it difficult to replace the firmware.  You're stuck with ethernet flashing, which is only going to work from Linux.  The plan is to run a network server when the user presses the button while powering on the Bifferboard (this would be disabled by the config if you want to use the button for other things, obviously). Had a look at lwIP, but eventually decided it's too heavyweight.  Had a look at uIP, which is better, but the code is just hideous.  I actually got the uIP 'hello world' example working on the Bifferboard, but then realised combining it with DHCP was going to be difficult.  It seems you get to run one 'tcp/ip' and one 'UDP' type of application at the same time and then that's your lot.  Since Bifferboard *needs* DHCP this made things just too awkward so I eventually gave up on that too.

Still, it gave me some ideas.  I decided I'll change things progressively because Biffboot already had bootp and some crude networking to do the tftp booting.  So I enhanced my bootp to do DHCP as well.  I got that working then decided I'd like to be able to ping the Bifferboard as well when it's running this server.  ICMP was a lot harder than I expected because it needs another checksum to be generated, but it also needs to respond with the correct packet length.  For ages my reply packets were too short, but my windows machine was telling me there was no problem with them.  Pings from Windows, fine, pings from Linux gave the error 'truncated'.  Took another few hours to figure out what was going on.  Wireshark is usually helpful in this respect, but here it wasn't displaying any errors when printing the captured packets.  Eventually I worked it out with tcpdump, so it's fixed. 

Finished too late Sunday night to do anything useful with it, like add an 'application layer', but I can now go one of two routes: Implement tftpd (quite hard, I need to make 'put' work) or just extend the protocol I've already created from raw ethernet frames to working over UDP, so it works on Windows.  I will go for the latter, because at least everyone knows how to use the bb_eth_upload8.py script.  So, Windows users will have to press and hold the button, Linux people can just use the raw packets and just power on.  I will try
to just modify the python script and keep the one.

I think this sounds like a reasonable plan.

I *hate* researching gadgets on the internet

I'm in the market for a new mobile, and I've made up my mind it's going to be Android, but which one?  I'm thinking Samsung i5700 (Galaxy Lite/Spica/Portal whatever), something entry level so I can write a few apps but not have to mortgage my house to buy it.  Since I'm likely to invalidate the warranty early on I'll try to get something 2nd hand.

LCD Displays

Finally found an LCD display that we might be able to use with the Bifferboard, but which won't cost a mint.  Sure Electronics now sell an HD44780 display but with a serial -> parallel converter and a serial USB chip (cp2102) built in.  The price certainly gives Matrix Orbital a run for their money!  Mine's on order, and I'll let you know how I get on when it arrives.  If it works out, perhaps I'll start stocking them.

TCC + Joe + JFFS == Bifferboard dev. kit

PTS TCC (Based on the Tiny C Compiler) is a really nice way to turn your Bifferboard into a C development system.  No external USB drive required.  No headers required. No libraries required.  I wasn't able to compile it from source, so I guess that prohibits shipping it with the Bifferboard, but still useful.  You can find the hardware and software description here.

Running the Bifferboard without an IO board

I've just ordered 1.8v and 3.3v regulators and am waiting for them to arrive from Farnell, and what do I discover just today?  Someone else has beat me to it