| View previous topic :: View next topic |
| Author |
Message |
Raisin
Joined: 15 Apr 2008
Posts: 4
|
| Random LCD corruption/stops refreshing(code lockup?) |
 Posted: Tue Apr 15, 2008 4:21 pm |
 |
|
Hello everyone,
I am currently testing an LM35 and an HIH 3605-B to measure temperature and relative humidity respectively. My PIC18F4685 uses A0 and A1 to make the ADC conversions. I can successfully refresh my HDM64GS12 graphic LCD with temperature on the first line and humidity on the second line in an infinite loop for a couple of minutes. For some reason, the screen can stop refreshing or start to go crazy randomly and then come back to normal, or not. Does anyone have a clue of what's happening? I've added some delays for tests that are probably useless, I should take them out once I fix this problem. Feel free to ask for more details...
Please take note:
humidite is humidity
LireTemp() reads temperature
LireHum() reads humidity
| Code: |
#include "C:\testlcdcapt\main.h"
#include <stdlib.h>
#include <math.h>
#include "C:\testlcdcapt\HDM64GS12.C"
#include "C:\testlcdcapt\GRAPHICS.C"
float LireTemp()
{
long lLectAdcTemp = 0;
float fTemperature = 0;
set_adc_channel(0);
delay_ms(10);
lLectAdcTemp = read_adc();
delay_ms(10);
fTemperature = (lLectAdcTemp*0.0048828125*100);
delay_ms(10);
return (fTemperature);
}
float LireHum()
{
long lLectAdcHum = 0;
float fHumidite = 0;
set_adc_channel(1);
delay_ms(10);
lLectAdcHum = read_adc();
delay_ms(10);
fHumidite = ((((float)lLectAdcHum/1023.0)-.16)/.0062)/(1.0546-0.00216*LireTemp());
delay_ms(10);
return (fHumidite);
}
void main()
{
char cTemperature[5];
char cHumidite[5];
setup_adc_ports(AN0_TO_AN1|VSS_VDD);
setup_adc(ADC_CLOCK_DIV_64|ADC_TAD_MUL_20);
setup_psp(PSP_DISABLED);
setup_spi(SPI_SS_DISABLED);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
setup_comparator(NC_NC_NC_NC);
setup_vref(VREF_HIGH);
//Setup_Oscillator parameter not selected from Intr Oscillotar Config tab
// TODO: USER CODE!!
glcd_init(ON);
do
{
glcd_fillScreen(OFF);
delay_ms(10);
itoa((int8)LireTemp(),10, cTemperature);
delay_ms(10);
glcd_text57(0, 0, cTemperature, 1, 1);
delay_ms(10);
itoa((int8)LireHum(),10, cHumidite);
delay_ms(10);
glcd_text57(0, 9, cHumidite, 1, 1);
delay_ms(10);
}
while(1);
}
|
As you can see, I am using GRAPHICS.C and HDM64GS12.C but I have made modifications to HDM64GS12.C after hearing a trusted classmate telling me to add some time to my delays. I have done the following:
| Code: |
// Purpose: Write a byte of data to the specified chip
// Inputs: 1) chipSelect - which chip to write the data to
// 2) data - the byte of data to write
void glcd_writeByte(int1 side, BYTE data)
{
if(side) // Choose which side to write to
output_high(GLCD_CS2);
else
output_high(GLCD_CS1);
output_low(GLCD_RW); // Set for writing
output_d(data); // Put the data on the port
delay_cycles(10); // ADDED SOME TIME TO INITIAL DELAY
output_high(GLCD_E); // Pulse the enable pin
delay_cycles(10); // ADDED SOME TIME TO INITIAL DELAY
output_low(GLCD_E);
output_low(GLCD_CS1); // Reset the chip select lines
output_low(GLCD_CS2);
}
|
|
|
 |
Raisin
Joined: 15 Apr 2008
Posts: 4
|
|
| Posted: Tue Apr 15, 2008 4:33 pm |
|
|
After taking a look at the thread my classmate saw to influence his decision to increase delays in HDM64GS12.C(http://www.ccsinfo.com/forum/viewtopic.php?t=29163&highlight=graphics), I find myself wondering if 10 is enough. Could it be that the GLCD happens to be busy sometime during my infinite loop and it corrupts the display?
the PIC18F4685's crystal is 20Mhz. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Apr 15, 2008 4:48 pm |
|
|
| Quote: | | For some reason, the screen can stop refreshing or start to go crazy randomly |
Post the contents of this file:
| Quote: | | #include "C:\testlcdcapt\main.h" |
We need to see your #include, #fuses, #use delay() , other #use
statements, #define statements and variable declarations. |
|
|
Guest
|
|
| Posted: Tue Apr 15, 2008 4:56 pm |
|
|
Contents of main.h:
| Code: |
#include <18F4685.h>
#device ICD=TRUE
#device adc=10
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES HS //High speed Osc (> 4mhz for PCM/PCH) (>10mhz for PCD)
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //Reset when brownout detected
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES PUT //Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES DEBUG //Debug mode for use with ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOPBADEN //PORTB pins are configured as digital I/O on RESET
#FUSES BBSIZ4K //4K words Boot Block size
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES MCLR //Master Clear pin enabled
#FUSES XINST //Extended set extension and Indexed Addressing mode enabled
#use delay(clock=20000000)
|
Also, programming my pic by USB ICD always results in having a bad verification where the fuse for LVP(low voltage programming) stays put and should be NOLVP. Code still works though, so teacher told me to ignore it. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Apr 15, 2008 4:59 pm |
|
|
This is the problem. The extended instruction set is not supported by
the compiler. If it's enabled with the XINST fuse, as in your code above,
the program will have erratic operation. To fix the problem, change
it to this:
Do that in all your programs. |
|
|
Raisin
Joined: 15 Apr 2008
Posts: 4
|
|
| Posted: Tue Apr 15, 2008 5:09 pm |
|
|
| Having that option checked by default in PICC's Wizard is really misleading. Thank you soo very much for your help. Bless you! |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Apr 16, 2008 2:27 am |
|
|
Yes.
It has been changed in the latest compiler revisions, but for several months, was a real 'annoyance'....
Best Wishes |
|
|
horkesley
Joined: 20 Feb 2007
Posts: 48
Location: Essex UK
|
| #fuses |
| Posted: Wed Apr 16, 2008 3:35 am |
|
|
Hi
Version 4.071 wizard still sets the #fuse to XINST.
Regards,
_________________
Horkesley Electronics Limited |
|
|
Raisin
Joined: 15 Apr 2008
Posts: 4
|
|
| Posted: Wed Apr 16, 2008 6:31 am |
|
|
Ok, removing the XINST fuse directive has caused me more trouble than anything else. I can't even get my humidity sensor's reading on the lcd anymore. Even worse, i can't put the fuse back on. Just like LVP stays on even when I put NOLVP, NOXINST stays on even if I put it back to XINST.
I can't figure out why the verification results always have problems. Even though my main.h has #FUSES NOLVP and #FUSES XINST, the expected column shows NOXINST and NOLVP expected and has actual column listing NOXINST and LVP. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
