Prev: Let's design a fake Perpetual Motion machine
Next: Currently Googling for Breakdown V of PTFE and Kapton
From: Jan Panteltje on 11 Mar 2010 17:40
I was writing a driver for a graphics LCD for PIC 18F14K22.
That went OK:
ftp://panteltje.com/pub/graphics_lcd_driver_img_1_1861.jpg

But I wrote it is asm, so it needed a lot of typing,
even more so because this display CD-19-HG1286418C has a strange
driver chip S6B0108 that comes from a planet where x is vertical and y horizontal,
and people write from to top to bottom probably on the right side towards the left...
and the display uses 2 driver chips for each half... so it took a lot of key hitting:
ftp://panteltje.com/pub/key_soup_img_1853.jpg
to get it to do things the European way, that I then reversed with x0, y0 at bottom left as
that is easier for what I want to do.

But now about the problem.
I did all this with the 8 MHz PIC internal clock, and it works perfectly.
Activated the internal 4 x PLL, so to 64 MHz internal clock, results in 16MHz processor clock.

Display stopped working, only display on and display off command still worked,.
Well, added the usual delay between I/O operations, but this time,
even with seconds delay, no effect.
Finally grabbed the scope, and looked at the PIC pins.
Now this is strange:

bsf PORTA,1 ; pin 18 LCD_C_D
bcf PORTA,5 ; pin 2 LCD_WR

should set pin 18, and then clear pin 2

This is what happens at 16 MHz clock.
But at 64 MHz clock after the first instruction pin 18 does not go high,



|||||||||||||||||||||||||||||||||||||| porta, 1
_________||||||||||||||||||||||||||||||||||||||_____________________ pin 18
16 MHz RF

-----------------------------------------------
| porta, 5
|_________________________ pin 2

^ ^
| |
bsf PORTA,1 bcf PORTA,5



but start outputting 16 MHz until the second instruction, and then goes to _zero_,
the second instruction operates normally and clears pin 2.


It seems the PIC internal output FF for pin 18 does not toggle, but just follows the internal clock.

I suspected a load problem and added an emitter follower because it drives a 20 cm long flat cable to the LCD.
pin 18 is also the PGC (program clock) for in circuit programming, but the effect persists with
pin 18 loaded with with only about 1k to ground.

I think the PIC is out of spec here, but not sure if I am allowed to use it with 64 MHz on internal oscillator.
Went back to 16 MHz clock, will work with that for now,
will have to get some more PICs too to see if it is only this one....
FYI.




From: dagmargoodboat on 12 Mar 2010 08:16
On Mar 11, 5:40 pm, Jan Panteltje <pNaonStpealm...(a)yahoo.com> wrote:
> I was writing a driver for a graphics LCD for PIC 18F14K22.
> That went OK:
>  ftp://panteltje.com/pub/graphics_lcd_driver_img_1_1861.jpg
>
> But I wrote it is asm, so it needed a lot of typing,
> even more so because this display CD-19-HG1286418C has a strange
> driver chip S6B0108 that comes from a planet where x is vertical and y horizontal,
> and people write from to top to bottom probably on the right side towards the left...
> and the display uses 2 driver chips for each half... so it took a lot of key hitting:
>  ftp://panteltje.com/pub/key_soup_img_1853.jpg
> to get it to do things the European way, that I then reversed with x0, y0 at bottom left as
> that is easier for what I want to do.
>
> But now about the problem.
> I did all this with the 8 MHz PIC internal clock, and it works perfectly.
> Activated the internal 4 x PLL, so to 64 MHz internal clock, results in 16MHz processor clock.
>
> Display stopped working, only display on and display off command still worked,.
> Well, added the usual delay between I/O operations, but this time,
> even with seconds delay, no effect.
> Finally grabbed the scope, and looked at the PIC pins.
> Now this is strange:
>
>   bsf     PORTA,1 ; pin 18         LCD_C_D
>   bcf     PORTA,5 ; pin  2                   LCD_WR
>
> should set pin 18, and then clear pin 2
>
> This is what happens at 16 MHz clock.
> But at 64 MHz clock after the first instruction pin 18 does not go high,
>
>          ||||||||||||||||||||||||||||||||||||||                            porta, 1
> _________||||||||||||||||||||||||||||||||||||||_____________________        pin 18
>                         16 MHz RF
>
> -----------------------------------------------
>                                                |                           porta, 5  
>                                                |_________________________   pin  2
>
>         ^                                      ^
>         |                                      |
>         bsf PORTA,1                            bcf PORTA,5    
>
> but start outputting 16 MHz until the second instruction, and then goes to _zero_,
> the second instruction operates normally and clears pin 2.
>
> It seems the PIC internal output FF for pin 18 does not toggle, but just follows the internal clock.
>
> I suspected a load problem and added an emitter follower because it drives a 20 cm long flat cable to the LCD.
> pin 18 is also the PGC (program clock) for in circuit programming, but the effect persists with
> pin 18 loaded with with only about 1k to ground.
>
> I think the PIC is out of spec here, but not sure if I am allowed to use it with 64 MHz on internal oscillator.
> Went back to 16 MHz clock, will work with that for now,
> will have to get some more PICs too to see if it is only this one....
> FYI.

Could this be a read-modify-write problem? You have one r-m-w
operation immediately followed by another. Is that allowed in PIC-
land? Even if it is, it ain't working here. Or maybe the RMW timing
is marginal & fails at 64MHz. MCUs often have bugs or caveats here.

What happens if you add a few NOPs between the two operations, or read
the port into W, twiddle the bits, then MOVWF back to the port?

--
Cheers,
James Arthur
From: Martin Brown on 12 Mar 2010 08:51
Jan Panteltje wrote:
> I was writing a driver for a graphics LCD for PIC 18F14K22.
> That went OK:
> ftp://panteltje.com/pub/graphics_lcd_driver_img_1_1861.jpg
>
> But I wrote it is asm, so it needed a lot of typing,
> even more so because this display CD-19-HG1286418C has a strange
> driver chip S6B0108 that comes from a planet where x is vertical and y horizontal,
> and people write from to top to bottom probably on the right side towards the left...
> and the display uses 2 driver chips for each half... so it took a lot of key hitting:
> ftp://panteltje.com/pub/key_soup_img_1853.jpg
> to get it to do things the European way, that I then reversed with x0, y0 at bottom left as
> that is easier for what I want to do.
>
> But now about the problem.
> I did all this with the 8 MHz PIC internal clock, and it works perfectly.
> Activated the internal 4 x PLL, so to 64 MHz internal clock, results in 16MHz processor clock.
>
> Display stopped working, only display on and display off command still worked,.
> Well, added the usual delay between I/O operations, but this time,
> even with seconds delay, no effect.
> Finally grabbed the scope, and looked at the PIC pins.
> Now this is strange:
>
> bsf PORTA,1 ; pin 18 LCD_C_D
> bcf PORTA,5 ; pin 2 LCD_WR
>
> should set pin 18, and then clear pin 2
>
> This is what happens at 16 MHz clock.
> But at 64 MHz clock after the first instruction pin 18 does not go high,

What happens at 32MHz? The datasheet is ambiguous about operation at
64MHz with one part saying yes and the other saying the PLLEN is only
valid for an 8MHz HFINTOSC (see page 22 OSCTUNE Reg 2-3.)
>
>
>
> |||||||||||||||||||||||||||||||||||||| porta, 1
> _________||||||||||||||||||||||||||||||||||||||_____________________ pin 18
> 16 MHz RF
>
> -----------------------------------------------
> | porta, 5
> |_________________________ pin 2
>
> ^ ^
> | |
> bsf PORTA,1 bcf PORTA,5
>
>
>
> but start outputting 16 MHz until the second instruction, and then goes to _zero_,
> the second instruction operates normally and clears pin 2.
>
>
> It seems the PIC internal output FF for pin 18 does not toggle, but just follows the internal clock.

You could always low pass filter it, provided it doesn't have to change
too fast (or pulse stretch it slightly).

> I think the PIC is out of spec here, but not sure if I am allowed to use it with 64 MHz on internal oscillator.
> Went back to 16 MHz clock, will work with that for now,
> will have to get some more PICs too to see if it is only this one....
> FYI.

Try it at 32MHz and/or with an external 64MHz xtal.

Regards,
Martin Brown
From: Jan Panteltje on 12 Mar 2010 11:47
On a sunny day (Fri, 12 Mar 2010 13:51:31 +0000) it happened Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote in
<wFrmn.92259$Ye4.50985(a)newsfe11.iad>:

>Jan Panteltje wrote:
>> should set pin 18, and then clear pin 2
>>
>> This is what happens at 16 MHz clock.
>> But at 64 MHz clock after the first instruction pin 18 does not go high,
>
>What happens at 32MHz? The datasheet is ambiguous about operation at
>64MHz with one part saying yes and the other saying the PLLEN is only
>valid for an 8MHz HFINTOSC (see page 22 OSCTUNE Reg 2-3.)

Exactly, I tried all clock speeds, and it only works at 16 MHz or lower.
I think this PIC is not able to do I/O that fast in a reliable way :-)


>> It seems the PIC internal output FF for pin 18 does not toggle, but just follows the internal clock.
>
>You could always low pass filter it, provided it doesn't have to change
>too fast (or pulse stretch it slightly).


Yes, well, I like simple circuits, adding all sort of stuff to compensate for hardware errors
in a processor is not nice.

What I *can* do is dynamically change clock speed, that is change to 16 MHz (PLL off) when doing I/O
to the LCD, and to 64 MHz when doing math, but then I also have to switch baudrate,
as it goes up and down a factor 4 then too, just tried that, seems possible.
Dunno what it does to the processing of the code, have to try that :-)
Also I need the 64 MHz for fast ADC...
From: Jan Panteltje on 12 Mar 2010 11:50
On a sunny day (Fri, 12 Mar 2010 05:16:00 -0800 (PST)) it happened
dagmargoodboat(a)yahoo.com wrote in
<b79cc9a1-6295-47ed-87c7-f79dd21ebf89(a)x12g2000yqx.googlegroups.com>:

>Could this be a read-modify-write problem? You have one r-m-w
>operation immediately followed by another. Is that allowed in PIC-
>land? Even if it is, it ain't working here. Or maybe the RMW timing
>is marginal & fails at 64MHz. MCUs often have bugs or caveats here.

Yes I think it is at the edge of what PIC can do...


>What happens if you add a few NOPs between the two operations, or read
>the port into W, twiddle the bits, then MOVWF back to the port?

I even tried a 100 mS delay loop after EACH I?O related instruction...
No difference.
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Let's design a fake Perpetual Motion machine
Next: Currently Googling for Breakdown V of PTFE and Kapton