 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Jim Hearne
Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK
|
| I2C and SAA1064T display driver. |
 Posted: Mon Feb 25, 2013 8:41 am |
 |
|
Hi,
2 questions:
1.Does anybody know why i need the delays in between each I2C function call below.
If have the delays all is fine, without them the display just shows random flickering digits.
There seem to be plenty of code examples around without the delays.
2: I really wanted to use the hardware I2C but i found out after much crashing that despite specifying 70khz in the code, that the minimum I2C clock speed is limited to a much higher values due to my PIC clock speed.
(The SAA1064T doesn't like a I2C clock faster than 70khz).
While i now know why the hardware I2C was crashing the display chip why does it manage to do it in such a way that the watchdog timer in the PIC is still being reset ?
(it crashes the PIC as well although interrupt code is still running.)
PCWH version 4.130
Many thanks,
Jim Hearne
| Code: |
#include <18f25K22.h>
#device ADC=10
#device *=16
#fuses INTRC_IO, put, WDT, nolvp, nocpd, PROTECT, NOMCLR, WRT, BROWNOUT, NODEBUG, BORV29, NOFCMEN, NOIESO,PLLEN, NOPBADEN
#use delay(clock=64000000,RESTART_WDT)
#use i2c(master, sda=pin_c4, scl=pin_c3,SLOW=70000,FORCE_SW)
#define LED_BRIGHTNESS 5 //range 0 to 7
#define DISPLAY_ADDRESS 0x70
#define I2C_DELAY 10 // delay in cycles between i2c byte transmit.
int8 const lcd_map[16] = {0x3f,0x06,0x5b,0x4f,0x66,0x6d,0x7d,0x07,0x7f,0x6f,0x77,0x7c,0x39,0x5e,0x79,0x71}; // lcd character set 0-9, A-F
int16 jim=0;
void display(int16 value)
{
int8 loop,temp;
int8 display_buff[4];
display_buff[3]=value/1000;
value = value % 1000;
display_buff[2]=value/100;
value = value % 100;
display_buff[1]=value/10;
value = value % 10;
display_buff[0]=value;
i2c_start();
delay_cycles(I2C_DELAY);
i2c_write(DISPLAY_ADDRESS);
delay_cycles(I2C_DELAY);
i2c_write(0); // select first byte
delay_cycles(I2C_DELAY);
i2c_write(0x07 | (LED_BRIGHTNESS*16)); // control byte
for(loop=0;loop<4;loop++)
{
temp=lcd_map[display_buff[loop]];
i2c_write(temp);
delay_cycles(I2C_DELAY);
}
i2c_stop();
delay_cycles(I2C_DELAY);
}
void main()
{
setup_ccp2(ccp_off);
setup_ccp1(ccp_off);
setup_adc (adc_off);
setup_adc_ports(no_analogs);
while(1)
{
if(jim<10000)
jim++;
else
jim=0;
display(jim);
delay_ms(100);
restart_wdt();
}
} |
|
|
 |
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Mon Feb 25, 2013 9:31 am |
|
|
I'm really skeptical that a Phillips IC is not I2C compliant which in order to be, has to meet I2C specs.
Looking at the datasheet, it looks to be considering the use of the I2C logo... and Phillips was part of the I2C specifications writing.
I would check your pullup resistors and length of bus.
What are your I2C pullup resistor values?
Have you put a scope on those bus lines to see the waveforms?
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
Jim Hearne
Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK
|
|
| Posted: Mon Feb 25, 2013 9:37 am |
|
|
Hi Ben,
Pullups are 2K2 (to 5 Volts).
The SAA1064 is only about 4cm from the PIC and there are no other devices on the bus.
The clock and data waveforms on the scope look good and i've used it to confirm the clock speed is 70khz (i've tried down to 10khz and still need the delays).
Many thanks,
Jim |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Mon Feb 25, 2013 9:52 am |
|
|
Hope this isn't viewed as hijacking this thread.
Sometimes I find that a short delay is needed between writes on I2C.
An example that comes to mind is writing to an eeprom. It seems reasonable since the PIC and the eeprom have differing time issues when the eeprom has to say write a whole page. I'm uncertain if the I2C protocol and CCS built in I2C support will automatically delay the PIC so as it doesn't overrun the eeprom. The LCD in this thread probably requires time to update the screen so it is similar to the eeprom issue.
Can someone add further advice. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Mon Feb 25, 2013 9:54 am |
|
|
Question.
How are you connecting the ADR pin?. It is vital that this is stable relative to the incoming supplies. Directly to Vee?.
I really would say you have a hardware problem somewhere. Ground not connected properly or something. I've used these chips in the past, and ran standard 100K I2C, with no delays, and it just worked.....
Best Wishes |
|
|
Jim Hearne
Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK
|
|
| Posted: Mon Feb 25, 2013 9:54 am |
|
|
I've just tried turning the PIC clock down from 64mhz to 32mhz and i can remove the delays.
Looking at the data and clock signal on the scope at 32mhz and 64mhz clock there is a major difference that i missed before.
At 32mhz the data line is correctly high during idle, at 64 mhz the data line is idleing low and i can see randomness in the data transmitted.
No other changes, just switching between 32mhz and 64mhz.
I think there is a bug in the CCS software I2C at 64mhz clock.
Thanks,
Jim |
|
|
Jim Hearne
Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK
|
|
| Posted: Mon Feb 25, 2013 9:57 am |
|
|
| Ttelmah wrote: | Question.
How are you connecting the ADR pin?. It is vital that this is stable relative to the incoming supplies. Directly to Vee?.
I really would say you have a hardware problem somewhere. Ground not connected properly or something. I've used these chips in the past, and ran standard 100K I2C, with no delays, and it just worked.....
Best Wishes |
Vee is connected directly through to the groundplane. This is the second design where we have used these chips with this problem, the previous one just has the delays left in as it didn't cause a problem.
Running hardware I2C at 100 khz i get ocassional flickering from the displays and sometimes the display driver chip locks up, and this then locks up the PIC in the I2C code.
The only way to reset the display driver chip is a power cycle, reseting the PIC doesn't reset the display.
I put this down to the hardware I2C minimum speed being too fast at 64mhz clock
Thanks,
Jim |
|
|
dyeatman
Joined: 06 Sep 2003
Posts: 1933
Location: Norman, OK
|
|
| Posted: Mon Feb 25, 2013 10:16 am |
|
|
It looks to me that he is writing to the display every 100+ms or so which is
really too fast. I would change the delay to 500ms at least.
_________________
Google and Forum Search are some of your best tools!!!! |
|
|
drh
Joined: 12 Jul 2004
Posts: 192
Location: Hemet, California USA
|
|
| Posted: Mon Feb 25, 2013 10:17 am |
|
|
In your
#use i2c(master, sda=pin_c4, scl=pin_c3,SLOW=70000,FORCE_SW)
According to the manual, FAST=70000 would set the speed.
_________________
David |
|
|
Jim Hearne
Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK
|
|
| Posted: Mon Feb 25, 2013 10:21 am |
|
|
| dyeatman wrote: | It looks to me that he is writing to the display every 100+ms or so which is
really too fast. I would change the delay to 500ms at least. |
I changed it to 1000ms , i just get 1 second updates of random data.
Thanks,
Jim |
|
|
Jim Hearne
Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK
|
|
| Posted: Mon Feb 25, 2013 10:24 am |
|
|
| drh wrote: | In your
#use i2c(master, sda=pin_c4, scl=pin_c3,SLOW=70000,FORCE_SW)
According to the manual, FAST=70000 would set the speed. |
According to what i read FAST=70000 is identical to SLOW=70000, once you have the = in they are identical.
I have confirmed the I2C clock is running at 70khz with both.
The key thing is why is the I2C data line idleing low when running at 64mhz PIC clock.
Thanks,
Jim |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Mon Feb 25, 2013 10:25 am |
|
|
What have you got as Cext?.
If you are running multiplexed, this determines all the update timings on the chip. There is a (hidden) minimum time between being able to do things, based upon this.
Best Wishes |
|
|
Jim Hearne
Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK
|
|
| Posted: Mon Feb 25, 2013 10:27 am |
|
|
| Ttelmah wrote: | What have you got as Cext?.
If you are running multiplexed, this determines all the update timings on the chip. There is a (hidden) minimum time between being able to do things, based upon this.
Best Wishes |
Yes, it is multiplexed.
Cext is 2n7
The datasheet i have for the SAA1064T has very little about any timings for the I2C bus, do you have link to a better one ?
Many thanks,
Jim |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Mon Feb 25, 2013 11:10 am |
|
|
I have a spec PDF from 2000-ish here:
http://www.benjammin.net/~bkamen/pdf/i2c-specification-v2.1-jan2000.pdf
As on page 3, to be I2C compliant means to at least meet that 100KHz spec. The fact that a Philips IC isn't I2C compliant is pretty wild.
I would look at lengthening out the inter-byte delay and see if I still get ACK/NAK's as appropriate from the slave device.
Essentially, isolate whether it's a bus speed issue or just the inter-byte issue.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
Jim Hearne
Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK
|
|
| Posted: Thu Feb 28, 2013 9:00 am |
|
|
Thanks Ben, i was actually looking for a more up to data version of the SAA1064T data sheet.
Jim |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
