| View previous topic :: View next topic |
| Author |
Message |
jeremiah
Joined: 20 Jul 2010
Posts: 1410
|
|
 Posted: Fri Jan 27, 2017 9:51 am |
 |
|
| temtronic wrote: | OK, I've never used a GLCD module but, silly basic question.
Is there a command or setup feature that allows you to make it behave like a common character based LCD module?
If so, it'd be a great way to confirm basic operation before getting into the 'math' of pixels,colors and 'other stuff'.
Jay |
Most of the time, you decide on a font in terms of pixels, and create a 2D array that has the correct pixel representation for each printable character. Generally, this is very standard among a lot of GLCDs so you can usually just use someone else's font table and plug it into your driver with minimal mods, even if it is done for a completely different chip on a different compiler.
Here is an example of a standard 5x7 font table (5pixels in X vs 7 pixels in Y):
https://github.com/andygock/glcd/blob/master/fonts/font5x7.h
Basically for each character, you just setup a for loop to go through each column and send that data to the GLCD in sequence.
It sounds more complicated than it actually is though. |
|
 |
jamalavedra
Joined: 25 Oct 2016
Posts: 62
|
|
| Posted: Fri Jan 27, 2017 10:54 am |
|
|
| jeremiah wrote: | | temtronic wrote: | OK, I've never used a GLCD module but, silly basic question.
Is there a command or setup feature that allows you to make it behave like a common character based LCD module?
If so, it'd be a great way to confirm basic operation before getting into the 'math' of pixels,colors and 'other stuff'.
Jay |
Most of the time, you decide on a font in terms of pixels, and create a 2D array that has the correct pixel representation for each printable character. Generally, this is very standard among a lot of GLCDs so you can usually just use someone else's font table and plug it into your driver with minimal mods, even if it is done for a completely different chip on a different compiler.
Here is an example of a standard 5x7 font table (5pixels in X vs 7 pixels in Y):
https://github.com/andygock/glcd/blob/master/fonts/font5x7.h
Basically for each character, you just setup a for loop to go through each column and send that data to the GLCD in sequence.
It sounds more complicated than it actually is though. |
this is the code I have in order toensure that the screen is receiving data. i am certain that the PIC is making the "n" operations because every once in a short while the current in my source increases to 0.01A so the chip is doing some action. but still, nothing is appearing on the display, problably something wrong with the "refresh screen" code that I attached?
| Code: |
void glcd_test_card() {
int n;
unsigned char p = 0xF0;
for (n = 1; n <= (SCREEN_WIDTH * SCREEN_HEIGHT / 8); ++n) {
glcd_buffer[n - 1] = p;
if (n % 4 == 0) {
unsigned char q = p;
p = p << 4;
p |= q >> 4;
}
}
//output_high(GLCD_CS1);
glcd_refresh();
}
|
thanks |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9632
Location: Greensville,Ontario
|
|
| Posted: Fri Jan 27, 2017 11:05 am |
|
|
hmm. this..
unsigned char p = 0xF0;
Pretty sure a 'char' is an unsigned 8 bit variable in CCS C .
Though it might not have any effect....maybe check the listing to see what 'p' is ?
Still think it's too bad you can't 'dum down' a GLCD to 'character LCD' mode for a quick 'am I working' test.
Jay |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1410
|
|
| Posted: Fri Jan 27, 2017 11:24 am |
|
|
| temtronic wrote: | hmm. this..
unsigned char p = 0xF0;
Pretty sure a 'char' is an unsigned 8 bit variable in CCS C .
|
It depends. For example, PCD v 4.121, chars were signed 8 bits and in v 4.114 they were unsigned 8 bits. I haven't checked recent versions though honestly. |
|
|
jamalavedra
Joined: 25 Oct 2016
Posts: 62
|
|
| Posted: Fri Jan 27, 2017 11:50 am |
|
|
ok guys, so now I have been able to write thinks on the display. Apparently the problem was the contrast ratio. It was too high and nothing appeared . Now though when I write thinks on the display i think the "clear" function is not working properly and random lines are appearing.
| Code: |
unsigned int16 p = 0, c = 0;
for(p = 0; p < 8; p++)
{
glcd_command(0xB0 | p);
for(c = 0; c < 129; c++)
{
glcd_command(0x10 | (c & 0xf));
glcd_command(0x00 | ((c >> 4) & 0xf));
glcd_data(0x00);
}
}
|
thanks |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Jan 27, 2017 12:37 pm |
|
|
| jamalavedra wrote: | After changing the type specifier "short" to int it doesn't seem to work either.
The "clear" function is not working properly and random lines are appearing.
|
You still don't know your data types and your math and it's killing you.
And also the lack of curiosity and a desire to check everything.
Curiosity and a "detective" mentality are essential in programming.
Let's work out the maximum value that 'array_pos' can be, and see if
an 'int' can hold it.
| jamalavedra wrote: | | unsigned int array_pos = x + ((y / 8) * 128); |
Let's give x and y their maximum values of 127 and 63 and do the math:
array_pos = 127 + ((63/8) * 128) = 127 + (7 * 128) = 127 + 896 = 1023
So 'array_pos' can be a value from 0 to 1023. But in CCS (PCM and PCH
compilers) an int can only go from 0 to 255.
It's obvious that 'array_pos' must be declared as an int16.
An 'int16' can hold the value of 1023. An 'unsigned int' can not hold it.
It's important to do these little tests. You will solve problems by doing so. |
|
|
jamalavedra
Joined: 25 Oct 2016
Posts: 62
|
|
| Posted: Fri Jan 27, 2017 12:51 pm |
|
|
| PCM programmer wrote: | | jamalavedra wrote: | After changing the type specifier "short" to int it doesn't seem to work either.
The "clear" function is not working properly and random lines are appearing.
|
You still don't know your data types and your math and it's killing you.
And also the lack of curiosity and a desire to check everything.
Curiosity and a "detective" mentality are essential in programming.
Let's work out the maximum value that 'array_pos' can be, and see if
an 'int' can hold it.
| jamalavedra wrote: | | unsigned int array_pos = x + ((y / 8) * 128); |
Let's give x and y their maximum values of 127 and 63 and do the math:
array_pos = 127 + ((63/8) * 128) = 127 + (7 * 128) = 127 + 896 = 1023
So 'array_pos' can be a value from 0 to 1023. But in CCS (PCM and PCH
compilers) an int can only go from 0 to 255.
It's obvious that 'array_pos' must be declared as an int16.
An 'int16' can hold the value of 1023. An 'unsigned int' can not hold it.
It's important to do these little tests. You will solve problems by doing so. |
I did write int16 into my code. Just took it for granted that it would be 16 and I did not write it here. Sorry for the confusion. Any thoughts on the clear screen problem ? What I send gets written but also random lines appear on the screen |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9632
Location: Greensville,Ontario
|
|
| Posted: Fri Jan 27, 2017 2:06 pm |
|
|
re: random lines
Are they vertical or horizontal ?
Are they always vertical or horizontal ?
Do they appear before or after what you display?
Are they just 1 pixel in 'width', IE a single row of pixels?
What is the power supply for the project?
What kind of filtering caps are used,esp. near PIC and display !
What is seen using an oscilloscope on all the data and power lines?
ie: is there ANY noise on ANY of the lines ?
I've reread the post from start....and one thing now POPS out..
.. should have seen it a lot earlier..
Are you aware that the PIC18F2685 is a 5 volt PIC? It is NOT designed to work at less than 4.25 volts AND that GLCD (from the link you provide) is a 3 volt device. Unless you have some form of logic level conversion the 'system' will NOT function properly.
If you've got that PIC wired and powered by 3 volts, it explains the 'random' garbage you're getting.
Jay |
|
|
jamalavedra
Joined: 25 Oct 2016
Posts: 62
|
|
| Posted: Sat Jan 28, 2017 12:44 pm |
|
|
| temtronic wrote: | re: random lines
Are they vertical or horizontal ?
Are they always vertical or horizontal ?
Do they appear before or after what you display?
Are they just 1 pixel in 'width', IE a single row of pixels?
What is the power supply for the project?
What kind of filtering caps are used,esp. near PIC and display !
What is seen using an oscilloscope on all the data and power lines?
ie: is there ANY noise on ANY of the lines ?
I've reread the post from start....and one thing now POPS out..
.. should have seen it a lot earlier..
Are you aware that the PIC18F2685 is a 5 volt PIC? It is NOT designed to work at less than 4.25 volts AND that GLCD (from the link you provide) is a 3 volt device. Unless you have some form of logic level conversion the 'system' will NOT function properly.
If you've got that PIC wired and powered by 3 volts, it explains the 'random' garbage you're getting.
Jay |
Hi;
The lines are a set of thick horizontal lines. There are about 3 of them on the screen and between them random pixels are on.
yes, they are always horizontal.
First, the initialization sequence goes one. Once I send the first pixel command on the screen is when the random lines appear as well as the pixels I turned on on purpose. They do appear simultaneously.
No, the lines are at least 3 pixels thick and between lines a random pattern of pixels appear. When sending a square shape to the screen, for example, The square shape appears as well as the random lines.
The Pic is powered by with 3.3V. I know this pic isn't meant to work with under 4.2V but as the screen doesn't require any ADC ports, when making a digital output of high it gives 3.3V correctly. The oscilloscope signals appears correctly.
The system is being tested in a low noise environment, so this shouldn't be the problem. I think it has to be something regarding with the code.
Thank you |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9632
Location: Greensville,Ontario
|
|
| Posted: Sat Jan 28, 2017 3:14 pm |
|
|
You MUST run a 5 volt PIC at 5 volts......
Your 'random' data on the GLCD can easily be caused by the PIC not executing instructions correctly, tossing random data into RAM, firing the SPI improperly, internal EMI due to low logic levels...in fact a book could be (and probably has) been written on the effects of 'substandard' or improper powering of a micro.
Others here have sucessfully run GLCD on PICs so it is possible but you MUST follow the datasheet specs !
Jay |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Jan 28, 2017 5:10 pm |
|
|
Example of a failure when running a PIC at 3.3v when the datasheet
says it's a 5v part (4.2v minimum Vdd):
| Quote: |
To add some info to the previous answers, we had a circuit operating a
PIC18F2580 at 3.3V with a 10 MHz crystal and the 4x PLL enabled (thus
40 MHz clock). Usually, this configuration was working without problems.
But we eventually noticed that when operating this way, the CAN bus
was not communicating anymore starting from a temperature
of around 35 °C. We eventually replaced the part with a PIC18LF2580
and a 20 MHz crystal (no PLL anymore), and the CAN problem disappeared... |
http://electronics.stackexchange.com/questions/111047/running-pic18f2580-at-3-3v-are-there-any-consequences |
|
|
jamalavedra
Joined: 25 Oct 2016
Posts: 62
|
|
| Posted: Mon Jan 30, 2017 8:15 am |
|
|
Hello;
I see your point guys, and I'll be changing my PIC to the 18LF2685. My problem then is that my system, PIC, is connected to a CAN network that is working at +5V. The MCP I was using until now was the MCP 2551 with datasheet http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf . As the PIC will be powered by 3.3 V, do you know any MCP that will work at 3.3V for the PIC and 5V for the CAN line? |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1934
|
|
| Posted: Mon Jan 30, 2017 8:45 am |
|
|
| jamalavedra wrote: | Hello;
I see your point guys, and I'll be changing my PIC to the 18LF2685. My problem then is that my system, PIC, is connected to a CAN network that is working at +5V. The MCP I was using untill now was the MCP 2551 with datahseet http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf . As the PIc will be powered by 3.3 V, do you know any MCP that will work at 3.3V for the PIC and 5V for the CAN line? |
You're worrying about nothing. You can definitely connect a 3.3V CAN transceiver to another CAN transceiver that's running at 5V. I have several thousand so-called "mixed" CAN network (5V and 3.3V) transceivers in the field and they're operating perfectly.
The best CAN transceiver I've ever found or used in a design is the TI SN65HVD233. It's not cheap, but it's very robust and extremely reliable. Just choose a package and temperature range that suits your application. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 20059
|
|
| Posted: Mon Jan 30, 2017 9:21 am |
|
|
Read:
<www.ti.com/lit/an/slla337/slla337.pdf>
and
<http://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/142/4747.2012_2D00_11_2D00_02-CAN-Transceiver-3V-and-5V-Mixed-Network-Basics.pdf>
3.3v CAN, transceivers are specifically designed to be interoperable on 5v CAN networks.
The recessive logic H voltage is deliberately offset relative to the supply so that it matches the 5v level.
So if you have to use a 3.3v display, redesign and use 3.3v throughout. |
|
|
jamalavedra
Joined: 25 Oct 2016
Posts: 62
|
|
| Posted: Mon Jan 30, 2017 12:49 pm |
|
|
Okei!, I will try it out with the TI transciever
My "blank display" code though is only clearing columns of aproximately 7 pixels every other time. Always behaving in the same way. Any idea why?
| Code: |
unsigned int16 p = 0, c = 0;
for(p = 0; p < 8; p++)
{
glcd_command(0xB0 | p);
for(c = 0; c < 129; c++)
{
glcd_command(0x10 | (c & 0xf));
glcd_command(0x00 | ((c >> 4) & 0xf));
glcd_data(0x00);
}
}
|
thanks |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
