WebbotLib - new device drivers

[Webbot]

So with all my recent messing around I have added quite a number of sensors etc. See http://webbot.org.uk/iPoint/35.page

So looking at what else I've been asked for is the Nokia LCD display. Yep - either ripped out of, or an ordered replacement part from Sparkfun etc.

A colour screen very cheap. See http://www.sparkfun.com/commerce/product_info.php?products_id=569

Early days yet - so whether you need the breakout board or not (doubles the price) - then I haven't looked that far. Of course it can also be used to dump chars as a cheaper alternative to a multi-line char display.

Anyone think they have anything more pressing! Tell me what and why/

[madsci1016]

What about a standard LCD screen via the HD44780 parallel interface? It would be nice to be able to add a screen to rprintf() to, and LCD's are cheap. You can fit more text in a 20x4 LCD screen then on the Nokia, right? And 16x2 are cheaper then the nokia, and don't need a breakout.

[Ro-Bot-X]

Yes, I agree, a standard parallel interface for LCDs from 16x2 up to 20x4 is needed. Of course, people that get the serial enabled LCDs can already use them on any free UART without much trouble. SparkFun has a serial backpack for regular LCDs, perhaps that could be used as a base for serial LCDs command format.

About the Nokia color LCD. A breakout board should be used by people (me) that can't solder a tiny SMD connector needed for the LCD. Also, the breakout board brings the proper voltage to the backlight directly from the battery (if it's not greater than 7.2V, if I remember correctly), or from the regulated 5V or even 3.3V supply. Anyway, the Nokia LCD is a 3.3V device, make sure don't give it 5V or you'll burn it.

[madsci1016]

The only thing I don't like about the serial backpack, is that it's not free. And a parallel interface isn't that hard to code, there's a lot of existing lib's out there.  (and it's free :-)

It also takes up a hardware Uart, or software uart, if you are in to that sort of thing. :-P

[Ro-Bot-X]

SparkFun has the schematics and the code for their serial backpack, so it CAN be free, well, almost free, as you still have to buy some microcontroller and parts to build it. They use a PIC so I think an open source serial backpack using an AVR micro would be nice for our community. I know that the parallel interface is easy to use, but it needs many IO pins that sometimes you don't have available, unless you're using an Axon, or you have a simple robot. I have a serial enabled LCD (not from SF) and I like how easy it is to use it foe anything, even for debugging a serial link. With Webbot lib I was able to use it on both hardware and software UARTs. All I had to do was create my own functions to write on line one or line two and to clear the LCD.

[Asellith]

Webbot I have the Sparkfun serial to lcd module installed on my axon with your code on it. If you want to get a driver working for that and need some testers let me know. It works ok with rprintf now but its not great and if it gets its own driver it would be nice to be able to do all the special functions easily.

[Webbot]

You can fit more text in a 20x4 LCD screen then on the Nokia, right?

The Nokia is a graphic display. So how many characters you get depends entirely on the font size you choose to use to draw the text. So yes - slower that a text display. But it also means you could draw images - ie a map of the room or your sonar ping results etc. Or how about an animated (small) face for your 'bot?

[madsci1016]

You asked if we had any ideas for something more important then a 128x128 Pixel display. Well, let's compare:

A usable LCD would have a breakout that's easy to interface, so that's

$35 for the Nokia    vs.    $14 for an 16x2 LCD    vs.     $25 for a serial enabled LCD.

So, for the tight budgets of most robot builders, more will use the cheaper and more standard 16x2 LCD. A full color 128Pixel graphic display is more for people with a specific application that requires it.

I'm not saying it wouldn't be nice to have a nokia display driver (and I'd be one to use it eventually), but I think it's more important to have a standard LCD driver first, as it will benefit more people, more then a specialized (and more expensive) graphic display.

[Admin]

I think your time is better spent supporting serial LED displays. Parallel displays waste too many pins.

For example, I've been wanting to buy this for ages:
http://www.picolour.com/

Never mind that 'colour' is spelled wrong

[SmAsH]

Never mind that 'colour' is spelled wrong

Hey! That's how we spell it over here!
Sorry, i had to...

[Webbot]

I think your time is better spent supporting serial LED displays. Parallel displays waste too many pins.

Ooops too late. Have started on the parallel displays. But I'm doing it as a generic 'display' driver.
Each display will support commands like 'clear screen', 'cursor home', 'cursor on/off/blink', 'cursor to X,Y' etc

ie you will be able to swap from a parallel to a serial without changing your code. If you are using the display for a scrolling log then all is well but if you use lots of 'cursor to x,y' to print an 'instrument panel' and you've got it working on a 40x4 display then dont expect to see the same results on a 20x2 display!!

Ive got a MatrixOrbital serial display I can play with but the parallel version will be an 'in the dark' release after scouring lots of data sheets and other peoples code. AVRlib has some support for parallel displays - but according to datasheets and others code then it has a few minor bugs in it.

Parallel displays waste too many pins.

Yeah - that why I dont like them either. However: I will support 4 bit mode and 8 bit mode. 4 bit mode requires 4 less I/O pins but is slower to write to.
Most libraries force you to connect 4 or 8 wire data lines to the same port - which I hate and wont be enforcing. They do this to make the code easier, faster and smaller. But IMHO its hard to choose a port where you can write off all 8 lines - as they tend to also contain things like PWM outputs etc etc.

So who wants to be a guinea pig for the parallel display code?

[madsci1016]

It was my suggestion, so i will stick by it.

I have both 20x4 and 16x2 parallel displays, I can test both.

Edit: Idea(s):

About the cursor x,y for text displays, why not remap the locations to a standard position set. IE, space 1 is upper left and space 32 is lower right on a 16x2, or space 80 on a 20x4. If you defined a 16x2 and tried to write to space 50 you get a flashy lib error.

Also, could we define an LCD as where we point rprintf() and error print to?

[Webbot]

It was my suggestion, so i will stick by it.

Good man.

I have both 20x4 and 16x2 parallel displays, I can test both.

4 line is useful as its a different beast to 1 or 2 lines. Anyone got a parallel display that can do more than 80 chars in total - as thats yet another thing.

About the cursor x,y for text displays, why not remap the locations to a standard position set. IE, space 1 is upper left and space 32 is lower right on a 16x2, or space 80 on a 20x4. If you defined a 16x2 and tried to write to space 50 you get a flashy lib error.

The main issue comes when someone decides the top left N chars are for 'compass'. Bottom right 10 chars are for 'tilt' etc. An instrument panel. Now use a one row x 8 char display. It will look crap. No way around it.

Also, could we define an LCD as where we point rprintf() and error print to?

Yep - all displays will be Writer destinations.