sparkfun 20x4 serLCD w/ AxonII code help

[BANE]

Hello,
Im trying to create a "hello world" program using the code from Project Designer.  I have the 20x4 serLCD (from sparkfun) connected to UART0 on the Axon II.  The code below seems to be printing gibberish to the LCD screen and i can't seem to get any of this code from webbot to making it through the compiler http://webbot.org.uk/WebbotLibDocs/42500.html#obj_42533

any help would be awesome

Code: [Select]

#include "hardware.h"

// Initialise the hardware
void appInitHardware(void) {
initHardware();


}
// Initialise the software
TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
return 0;
}
// This is the main loop
TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart) {

// -------- Start Sparkfun serLCD-------
// You can send commands to sparkfun20x4LCD by using the commands in _display_common.h
displayGoto(&sparkfun20x4LCD,0,1);
// To set rprintf to go to sparkfun20x4LCD then

rprintfInit( displayGetWriter(&sparkfun20x4LCD));

rprintf("hello world");

return 0;
}


[Admin]

Are you sure your Axon baud rate matches the default serLCD baud rate?

Also, have a read through this:
http://www.societyofrobots.com/robotforum/index.php?topic=12221.0

[BANE]

according to project designer and other threads ive looked at, the baud rate set to 9600, which is what ive got it set to.  

It works perfectly fine, displays text correctly, etc . . .

until I turn on the backlight . . . and then it turns into a stubborn inconsistent dysfunctional child.

Unfortunately i bought this before i was aware of the issues with the backlight, but at the moment i'm not sure if i'm printing to the LCD correctly (sorry, newb at C).  
admin, do you have the code you used that worked with out the backlight?

thnx

bane

update:

The displays were working fine yesterday. I turned everything on today, making no changes, yet the baud rate changed to some other unknown rate. Trying to fix it, suddenly the backlight turns on again, although I issued no command to do so. An unknown baud rate + a backlight that breaks commands = I give up.

I've noticed alot of inconsistency too......ugh, of all the lcds out there i had to buy this one.........

[Admin]

The wire you have going from the Axon UART to the serLCD, make it as short as you possibly can. Also, solder a few caps on the power lines directly on the display.

If still no luck, I'll post some code snippets for you.

I just got a new display from 4D, but haven't had time to play with it yet . . .

[BANE]

Ok, i cut the wire from 18" to 6"= no change.  
I hooked the oscope directly to the lcd power and got ~20mv of AC fluctuation.  
I put a 25v 10uf cap and two .1uf ceramic caps; this dropped the AC fluctuation within 5mv.  
Also i tried replacing the 25v 10uf cap with a 10v 2200uf for the hell of it, but still getting the same thing.  
I tested uart0 with the oscope and its transmitting data and it looks pretty clean

I tried going to project designer and noticed that it has been updated  (project designer is the shit!)
I also noticed that the code changed a little so i tried it again with the new code and now the lcd screen just sits on the start up sparkfun screen.  
here is the new code if anyone wants to take a looksy

Code: [Select]

#include "hardware.h"

// Initialise the hardware
void appInitHardware(void) {
initHardware();


}
// Initialise the software
TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
return 0;
}
// This is the main loop
TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart) {

// -------- Start Sparkfun serLCD-------
// You can send commands to display by using the commands in _display_common.h
// For example to move the cursor to position 0 of line 1 (note positions start at 0) then:
displayGoto(&display,0,1);


// To set rprintf to go to display then
rprintfInit( displayGetWriter(&display));
// You can now use any rprintf commands to output character data to the display
rprintf("hello world");
// -------- End   Sparkfun serLCD-------

return 0;
}

ps this is why i'm a mechanical engineer. i suck at electronics!!!@#$!#@!3

[Admin]

Add a delay of a few seconds into that super fast loop, which btw doesn't need to re-init the display non-stop

(I'm not sure if thats you're only problem, but it'll definitely help!)

ps this is why i'm a mechanical engineer. i suck at electronics!!!@#$!#@!3

I'm also a mechE - no excuse!

[BANE]

thanks admin

I added a 5 second delay and now a 16x2 array of black boxes are appearing on the screen and the backlight is toggling every 5 seconds...?  On a hunch, i'm leaning to a program issue rather than power and interference issues but thats newby talking.
So here is some of the options in project designer that i hopefully have incorrect

bwt, no stressing allowed  on this.  the only reason i want to get this screen working is because i'm used to debugging/displaying servo position/IR value/battery level/and pretty much everything on one and it helps a ton.  However, teraterm is handy too it just sux having to disconnect from it every time i upload a new program and playing musical-windows if you know what i mean.

[Admin]

and the backlight is toggling every 5 seconds

Sounds like your backlight was somehow turned on, perhaps caused by a corrupted command. If that's the case, you're pretty much f'ed. You can try repeatedly a few hundred times to send commands to turn if off, and if you're lucky it'll get through at least one of those times without being corrupted. Thats how I did it

the only reason i want to get this screen working is because i'm used to debugging/displaying servo position/IR value/battery level/and pretty much everything on one and it helps a ton.  However, teraterm is handy too it just sux having to disconnect from it every time i upload a new program and playing musical-windows if you know what i mean.

This is why I use a hardware programmer and not the bootloader . . .

You can also use bluetooth/xbee to wirelessly transmit to your teraterm, instead. Much easier than following your robot around to read the data

[BANE]

Great news!  I finally got text on the screen.  i turns out that you have to physically remove all power from the screen and then print to it.  appearently the axon was still suppling it with ~2v even when powered off (from caps) which i guess screws up the screen.  Now that i think of it I believe i read about this on another thread but didnt comprehend it at the time.

However, its still nowhere near perfect  but a start after the hours of tinkering.  it seems i can only print to a 16x4 array and not a 20x4.  i looked through the header file that project designer hoping to find where it defines the width and height but no luck.  Any ideas?   

This is why I use a hardware programmer and not the bootloader . . .

Im honestly considering it since i hate using my spare laptop with vista and no bluetooth

just out of curiosity, do you have to turn off and on the power manually then flashing with a programmer, or does it take care of that for you?
 

[Admin]

i turns out that you have to physically remove all power from the screen and then print to it.  appearently the axon was still suppling it with ~2v even when powered off (from caps) which i guess screws up the screen.

wait . . . what?

The Axon, even when powered off, still has voltage (charge) stored in it's caps for several seconds. The display won't power reset until the Axon voltage goes below some threshold. Unplugging the display power wires will also work, which is what I think you meant?

do you have to turn off and on the power manually then flashing with a programmer, or does it take care of that for you?

The hardware programmer pulses the reset pin for you, so no need to power/unpower the Axon with new code. The ISP connector has a reset pin - just short it to ground, and it'll reset the Axon. Although, that might cause you problems with the bootloader. I remember it being fickle when I did that.

[Webbot]

In Project Designer during the code gen you've already told it to send rprintf to the 'display'. So it will add the rprintfInit in appInitHardware so you can get rid of your rprintfInit call all together in your main loop.

As for looking at the code then try looking at: Displays/Sparkfun/serLCD.c

EDIT: As an after thought you could always change the display to be on UART1 (ie the usb) and then use Teraterm etc to view what webbotlib is sending to the display. Bear in mind that there are lots of non-ascii characters so you could show them in hex, or similar, on your terminal.

[BANE]

Quote
i turns out that you have to physically remove all power from the screen and then print to it.  appearently the axon was still suppling it with ~2v even when powered off (from caps) which i guess screws up the screen.
wait . . . what?

haha, yep thats what i was trying to say

As for looking at the code then try looking at: Displays/Sparkfun/serLCD.c

it references Displays/Sparkfun/serLCD.h which has four different screen sizes.  I couldn't seem to get it to goto the 20x4 one so i just changed them all to 20x4; kinda ghetto but it works now

EDIT: As an after thought you could always change the display to be on UART1 (ie the usb) and then use Teraterm etc to view what webbotlib is sending to the display. Bear in mind that there are lots of non-ascii characters so you could show them in hex, or similar, on your terminal.

thanks webbot i was wondering about.

So the only issues i can think of are attempting to get the backlight on (i probably will find the holy grail first ) and something screwy happens then i print more than 16 characters, but i live with it. 

just for the records, here is a pic of the setup of three ir sensors and the lcd displaying their values in cm

[Webbot]

Dont forget that there are 2 commands for the backlight: you can turn it on or off, and you can set its brightness

[Webbot]

Hey BANE,

Think I may have got to the bottom of your 16 vs 20 column display issue. Apparently if you buy the serLCD with LCD already mounted then the serLCD is already configured to cope with 20 columns. If you buy them separately then the serLCD doesn't know so I guess assumes its a 16 column one.

So I've added some stuff to the display init to tell the serLCD what you've actually got (or rather - what you've told Project Designer you've got !)

I'll send you a new libWebbot-ATMega640.a - let me know via this forum if it fixes your issue.

Webbot

[BANE]

edit: whoops, looks like webbot beat me to it

webbot, AVR studio doesnt seem to like any of the commands listed herehttp://webbot.org.uk/WebbotLibDocs/42500.html#obj_42539
For example: displayBacklight(DISPLAY* display,boolean on); it gives an error "display" undeclared.
Im i using this correctly?

[Webbot]

'display' is the name of your serLCD that you gave it in Project Designer. WebbotLib makes no assumptions as you could have 3 serLCDs connected to different uarts.

So find out what you display is called - lets assume its 'myLCD' then the code is:-
displayBacklight( &myLCD, TRUE);  // to turn on the light , or
displayBacklight( &myLCD, FALSE); // to turn off the light

[BANE]

I'll send you a new libWebbot-ATMega640.a - let me know via this forum if it fixes your issue.

fixed it.  also, i seem to be getting to same results so maybe that fixed some of the unpredictably issues.  no more jumping around of characters

So find out what you display is called - lets assume its 'myLCD' then the code is:-
displayBacklight( &myLCD, TRUE);  // to turn on the light , or
displayBacklight( &myLCD, FALSE); // to turn off the light

thanks, the backlight works now  

[Webbot]

So all is now working and cool ? Nothing else you need? ( +1 help beg  )

Will parcel the fix up for the next WebbotLib release.

Thnx for being a guinea pig !

[BANE]

( +1 help beg  )

id give you & admin a +10 if it would let me

it the moment everything is working great from the programming world.  I'm going to try and add a transistor switch to +5v on the LCD screen so i don't have to manually plug and unplug this every time.

Thnx for being a guinea pig !

My next project is getting my ps2 controller working with the axon II; do you need another guinea pig?

thnk all,

[Webbot]

My next project is getting my ps2 controller working with the axon II; do you need another guinea pig?

great offer - but the PS2 controller is already in WebbotLib 

[BANE]

wow , i guess ill be doing that project alot sooner then.  I noticed that project designer also has the ps2 controller; you know you guys are spoilers right?

[Webbot]

wow , i guess ill be doing that project alot sooner then.  I noticed that project designer also has the ps2 controller; you know you guys are spoilers right?

Yep - well it would be in both - I designed and wrote all of WebbotLib, Project Designer, Board Designer, Gait Designer etc - hence its all tied together. Admin invents the hardware you buy from him, whereas I independently invent the software to support his boards, and others, which I release for free.

No wonder I'm poor !

If anyone wants to buy me a virtual lunch then don't forget the 'donate $' button on my Sourceforge site for webbotlib. Top right button on http://sourceforge.net/projects/webbotavrclib/

[Admin]

Yep - well it would be in both - I designed and wrote all of WebbotLib, Project Designer, Board Designer, Gait Designer etc - hence its all tied together. Admin invents the hardware you buy from him, whereas I independently invent the software to support his boards, and others, which I release for free.

Hey, I lost a lot of hair heavily debugging your earlier versions, and much of my code/ideas was assimilated into WebbotLib

[Webbot]

Hey, I lost a lot of hair heavily debugging your earlier versions, and much of my code/ideas was assimilated into WebbotLib

Hair loss - yes that's the result of testing early alpha versions of ANY software.
Testers report problems.
Remember that I then did all the actual debugging/fixing/release etc to my own code
Not sure what "code/ideas" you are referring to - other than supporting one liner macros from your old lib to make it easier for roboteers to move on.

Despite WebbotLib having been hosted as Open Source for well over a year then not a single other person has signed up as a developer to contribute their time. Enough said. All the code has been written by me.

[edit] Apologies to BANE - we've hijacked your thread!

[BANE]

Ok, sounds like this needs to be settled on a robot battle field   Im going to have to say admin has to upper hand because his "ERP" knows karate, however, there is no telling what webbot is going to add to his lib at the last second so i say its a tie!