Go Down

Topic: v3 dec 2011 GLCD on 1284p with Arduino 1.0 (Read 5972 times) previous topic - next topic

bperrybap

Wow.
That has to be by far the best information I've seen for helping diagnose a glcd problem.
It will take a little bit to review it, but there is definitely enough information here
to figure out what the issue is.

A quick note on your glcd pinout -
you didn't mention that you had two different displays.

--- bill




cowasaki


Wow.
That has to be by far the best information I've seen for helping diagnose a glcd problem.
It will take a little bit to review it, but there is definitely enough information here
to figure out what the issue is.

A quick note on your glcd pinout -
you didn't mention that you had two different displays.

--- bill



I have a box load of different displays as I bought a job lot from China.  Most are normal LCDs but I thought that both of these were standard type B displays.  I hope I am right or that might explain some things.  I will just double check now......

I thought that I would give you every bit of information that I possibly could in order to make sure that it was possible to find the answer :)

cowasaki

Just checked the data sheets and they are both type B GLCDs {I got rid of the others :)}


01 - VSS
02 - VDD
03 - V0
04 - D/I
05 - R/W
06 - E
07 - 0
08 - 1
09 - 2
10 - 3
11 - 4
12 - 5
13 - 6
14 - 7
15 - CS1
16 - CS2
17 - RST
18 - VEE
19 - LED+
20 - LED-

bperrybap

Just starting to look at it.
One thing I noticed right off the bat is the reset line. glcd pin 17.
On most glcds you cannot leave that disconnected.
It must be high for normal operation. On some glcds you can simply tie it to vcc.
Others need a pulse on it to reset the module to a sane state
thats why it is often connected to the Arduino reset line.

For now the best would be to allow the glcd library to control it.
You can do that by using another AVR pin.
You need to create a define for glcdRES in the pin configuration file.
(I just noticed that the Sanguino pin configuration does not have a sample entry
that is commented out for this like all the other pin config files. I'll get the fixed for the next release).
Just add the define and let the glcd library control it.

A quick note on the pot.
The pot should be hooked up as:

leg ---- GND (or VCC) doesn't really matter
wiper --------------------------------------------------------------------- Vo/Contrast
leg ----- Vee

The pot acts as voltage divider between the negative voltage of Vee and gnd/vcc.
The actual voltage needed to set the pixels is usually slightly negative but under
extreme temperatures it may need to be slight above ground and that is why
you may seem some variation on where one of the legs is hooked.
At room temperature gnd or vcc can be used. Using gnd will waste slightly less power.



Now for the BIGGIE.......

It looks to me like all 20 glcd pins in the bread board setup are wired backwards. DOH!
i.e. pin 20 should be on the left and pin 1 is on the right.
The wiring on the shield looks ok as I can see the current limiting
resistor on pin 19 (second pin on from the left) but in the breadboard setup all the glcd connections
appear to be reversed.

It's usually the simple stuff that trips things up.
Thats where the 2nd pair of eyes helps.

--- bill

cowasaki


Just starting to look at it.
One thing I noticed right off the bat is the reset line. glcd pin 17.
On most glcds you cannot leave that disconnected.
It must be high for normal operation. On some glcds you can simply tie it to vcc.
Others need a pulse on it to reset the module to a sane state
thats why it is often connected to the Arduino reset line.

For now the best would be to allow the glcd library to control it.
You can do that by using another AVR pin.
You need to create a define for glcdRES in the pin configuration file.
(I just noticed that the Sanguino pin configuration does not have a sample entry
that is commented out for this like all the other pin config files. I'll get the fixed for the next release).
Just add the define and let the glcd library control it.

A quick note on the pot.
The pot should be hooked up as:

leg ---- GND (or VCC) doesn't really matter
wiper --------------------------------------------------------------------- Vo/Contrast
leg ----- Vee

The pot acts as voltage divider between the negative voltage of Vee and gnd/vcc.
The actual voltage needed to set the pixels is usually slightly negative but under
extreme temperatures it may need to be slight above ground and that is why
you may seem some variation on where one of the legs is hooked.
At room temperature gnd or vcc can be used. Using gnd will waste slightly less power.



Now for the BIGGIE.......

It looks to me like all 20 glcd pins in the bread board setup are wired backwards. DOH!
i.e. pin 20 should be on the left and pin 1 is on the right.
The wiring on the shield looks ok as I can see the current limiting
resistor on pin 19 (second pin on from the left) but in the breadboard setup all the glcd connections
appear to be reversed.

It's usually the simple stuff that trips things up.
Thats where the 2nd pair of eyes helps.

--- bill


I've built at least 4 devices with GLCDs and they've all worked straight off, never had a problem before. 

I can't believe I had the entire connector wired backwards {sorry need a screaming smilie}

Yes it really does help having a second set of eyes and also having all the information to hand.  I'm a mod on a photography forum and you would be amazed how many questions we get with "Whats wrong with this image" and they've shrunk it and removed all the EXIF data.  I was trying to do the opposite by giving you a complete information overload.

I have never had to do anything with the reset line yet but will look at that once I have reversed the reversed wiring.

Seriously thanks for taking the time, I will report back shortly.

cowasaki

[font=Verdana]THANK YOU.  IT IS NOW WORKING.[/font]

I did add the reset control line in but once it was working I pulled it and restarted and it is still working so luckily it's one of those that didn't need it.

I am well pleased now......

bperrybap

There is still the issue of how to handle the different Arduino pin mappings for the different
mighty-1284p variants.

It is critical that code that does pin mapping know the specifics of the target being built
and today that simply is not possible because the core and variant information is not
available to the code being compiled.

As example, the code I have in the glcd library that updates the 8 data pins
talking to the glcd is 800X faster updating the 8 pins
when it can use an 8 bit port access vs having
to use 8 individual digitalWrite() operations.
While setting the AVR pins to talk to the glcd is only a portion of the overall overhead
it is still very noticeable in that it can lower the overall performance by as much 20x
which is very noticeable when trying to do rapid updates to the glcd.

The only way to do these kinds of optimizations is to
detect this at compile time is by having a mapping table
and the only way to have a proper mapping table is to know which core and variant
you are building.

Maybe you can push on the mighty-1284p code maintainers about the need
for this kind of information for i/o intensive libraries.

---- bill

cowasaki


There is still the issue of how to handle the different Arduino pin mappings for the different
mighty-1284p variants.

It is critical that code that does pin mapping know the specifics of the target being built
and today that simply is not possible because the core and variant information is not
available to the code being compiled.

As example, the code I have in the glcd library that updates the 8 data pins
talking to the glcd is 800X faster updating the 8 pins
when it can use an 8 bit port access vs having
to use 8 individual digitalWrite() operations.
While setting the AVR pins to talk to the glcd is only a portion of the overall overhead
it is still very noticeable in that it can lower the overall performance by as much 20x
which is very noticeable when trying to do rapid updates to the glcd.

The only way to do these kinds of optimizations is to
detect this at compile time is by having a mapping table
and the only way to have a proper mapping table is to know which core and variant
you are building.

Maybe you can push on the mighty-1284p code maintainers about the need
for this kind of information for i/o intensive libraries.

---- bill


ManiacBug is talking about the 1284P becoming part of the main Arudino build so hopefully we will get a standardisation then and a system that stops a lot of the issues.  GLCD working is just one of a few issues I was having along with uploading of sketching via serial FTDI and SDA/SLA comms with RTC etc.  I can see Bob's call for using the same pins in order to get shield compatibility but at the moment I think there are maybe 4 or 5 alternatives.  If the 1284P is not accepted into the standard core soon it is likely it will be too late as lots of hardware is built along the opposing standards.

I will post about this too, the 1284P is too good a chip to go to waste.

bperrybap

I hadn't really looked much at the "Sanguino" until now.
I really like the 1284P. That is a nice chip. It is WAY better than a m328, which
I never really liked because of the way Atmel assigned the pins.
You can't get an 8 bit port out of it if you want to use a crystal and the serial port.

As far as Arduino pin # mapping goes for 644/1284P and support in the glcd library.
It is possible to tell the difference between the 3 variants in the mighty-1284p core.
It is VERY ugly but it can be done.

You can look at the result of analogInputToDigitalPin(0)
If it is 31 then you using the "avr_developers" pin mapping.
If it is 24 then you are using the "standard" pin mapping.
If it is 21 then you are using the "bobduino" pin mapping.

While I prefer the "standard" variant pin mapping and wish the others would go away,
I'll add all three when I add in 1284p support to the glcd library.
It will make for long pin mapping macro, since it has to handle all three variants
but it is easy to do.

And while this can be done, I still want say VERY LOUDLY, that there needs to be
a consistent way for the board, core, and variant to be known at compile time
by the code being compiled.


--- bill

Madhu

Hello all,

In my zeal to use the 1284P with a "type B" GLCD (JHD12864E), I have made this board.

Can anyone please review this and comment / suggest changes?

However, please note, because of size constraints, the PCB can be only 4"(W) x 3"(H).

Thanks,
Madhu.

Madhu

All,

As much as I hate to do this, Please comment and post your suggestions.

thanks,
madhu.

cowasaki


Hello all,

In my zeal to use the 1284P with a "type B" GLCD (JHD12864E), I have made this board.

Can anyone please review this and comment / suggest changes?

However, please note, because of size constraints, the PCB can be only 4"(W) x 3"(H).

Thanks,
Madhu.



Your LCD connector doesn't appear to be grounded.

Madhu

Hi Cowasaki,

Thank you for your input. I am sorry, I do not understand what you mean when you say that the LCD connector is not grounded; please find attached a magnified area of the connector.

Also, there was a slight problem in one of the power rails - I have corrected and attached the same.

Let me know in case I need to make more corrections.

Thanks,
Madhu.


cowasaki

Pins 1 & 20 are normally ground on a type B GLCD I didn't realise that those pins were in the ground plane.

It looks ok from a cursory glance.  Is it aiming to be used for something in particular or as the basis for something else.

Madhu

Cowasaki,

Well, this aims to be a PS2 Controller interface. The 6 pin pads under the 1284p is the interface connection.

I dont know how successful this shall be; only time will tell.

thanks,
Madhu.

Go Up