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 hereto figure out what the issue is.A quick note on your glcd pinout -you didn't mention that you had two different displays.--- bill
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 statethats 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 entrythat 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 matterwiper --------------------------------------------------------------------- Vo/Contrastleg ----- 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 underextreme temperatures it may need to be slight above ground and that is whyyou 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 limitingresistor on pin 19 (second pin on from the left) but in the breadboard setup all the glcd connectionsappear to be reversed.It's usually the simple stuff that trips things up.Thats where the 2nd pair of eyes helps.--- bill
There is still the issue of how to handle the different Arduino pin mappings for the differentmighty-1284p variants.It is critical that code that does pin mapping know the specifics of the target being builtand today that simply is not possible because the core and variant information is notavailable to the code being compiled.As example, the code I have in the glcd library that updates the 8 data pinstalking to the glcd is 800X faster updating the 8 pinswhen it can use an 8 bit port access vs havingto use 8 individual digitalWrite() operations.While setting the AVR pins to talk to the glcd is only a portion of the overall overheadit is still very noticeable in that it can lower the overall performance by as much 20xwhich is very noticeable when trying to do rapid updates to the glcd.The only way to do these kinds of optimizations is todetect this at compile time is by having a mapping tableand the only way to have a proper mapping table is to know which core and variantyou are building.Maybe you can push on the mighty-1284p code maintainers about the needfor this kind of information for i/o intensive libraries.---- bill
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.
Please enter a valid email to subscribe
We need to confirm your email address.
To complete the subscription, please click the link in the
email we just sent you.
Thank you for subscribing!
via Egeo 16