gabled LCD

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hey everybody, just want to say that this is a valuable forum and i have learned a lot by following some of the threads here.

   

I have inherited a PSOC1 EVAL board from a freind and am playing with it in my spare time. since ive recieved it i have began to learn c for programming the device and have gone through many of the PSoC examples. long story short, i have succefully been able to communicate AT commands through simple c code from the psoc MCU to a GSM to send me an sms.

   

Now i have simulated communication through windows hyperterminal:

   

MCU sends command "AT" as an unassigned char and it is displayed in hypertrm, I type in "OK" followed by enter, program saves charachter by using UART_cGetChar(); and displays it back to hyperterminal through UART_PutChar();

   

this has worked well.

   

Now i want to do something similar with an LCD interface as i would like to monitor the flow of communication between MCU and GSM, but the charachters displayed by LCD_from _cGetChar(); on the LCD are garbled. i have tried obtaining the parameters by using UART_szGetParam(); and that returns nothing, using UART_szGetRestOfParams(); returns "AT" to the LCD which is odd.

   

ihave scattered the forums and treid a lot of what has been discussed but have given up, could anybody offer some insight as to why i am getting garbled info using _cGetChar, or why i am recieving the AT command that was supposed to be sent by Tx when using _szGetRestOfParams? thanks in advance for any input

0 Likes
12 Replies
Anonymous
Not applicable
        Hi 2stroke   
I might be didn't understand what you say, what you want to do, anyway   
Some questions...   
" LCD_from _cGetChar(); " What is this?   
Your special made API?   
I know, general LCD device can do Write and Read   
But usually, mainly use to output to LCD.   
PSoC standard API for LCD has no Read functions.   
   
What PSoC1 device and LCD do you use?   
"garbled info" How wrong?   
Please describe more in detail.   
0 Likes
Anonymous
Not applicable

Hey PSoC73

   

sorry, i was typing faster than i was thinking :-))) i meant UART_cGetChar(); i use it by saving it into a variable. i am pasting my code, please dont laugh as i have been teaching myself c for the last two weeks and my structure is probobly very primitive/inefficient

   

    char *strPtr;             //variable to save response from DCE
    char AT[] = "AT\n\r";      //Command to send from DTE
   
    // Initialize receiver/cmd buffer
    UART_CmdReset();    
     //Turn on interrupts
    M8C_EnableGInt ;   
    //Enable RX interrupts
    UART_IntCntl(UART_ENABLE_RX_INT);      
    //set parity as zero and start the UART
    UART_Start(UART_PARITY_NONE);
    //Initialize the LCD
    LCD_Start();                      
    LCD_Position(0,0);
    LCD_PrCString("Sending Command:");
    LCD_Position(1,0);
    LCD_PrCString("      AT        ");
    //Send AT command "expected response is OK"
    UART_PutString(AT);
    //Give DCE time to process command and send back response
    Delay10msTimes(200);
    //Save response into variable strPtr
    *strPtr=UART_cReadChar();
    //Display response in LCD
    LCD_Position(0,0);
    LCD_PrCString("   Recieved:    ");
    LCD_Position(1,0);
    LCD_PrString(strPtr);
    UART_CmdReset();

   

with a few modifications this code works fine when communicating with hyperterminal provided i add a loop to wait for the command terminator.

   

the problem seems to be that im reading the transmitter buffer and not the recieved buffer

0 Likes
lock attach
Attachments are accessible only for community members.
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

The two main character printing functions, for printing
ASCII characters, are -

   

LCD_PrString   Description: Prints a null terminated RAM-based character string to the LCD at the
present cursor location.

   

LCD_PrCString  Description: Prints a null terminated ROM-based character string to the LCD at the
present cursor location.

   

So basiacally you send/receive ASCII via UART and pass that onto display.

   

The character font is in the attached datasheet, if you have that specific controller
version.

   

Regards, Dana.
 

0 Likes
Anonymous
Not applicable
        Maybe, you have to check UART buffer, exist data or not   
before get a character by [ *strPtr=UART_cReadChar(); ]   
This is a working sample that using UART buffer.   
/////////////////////////////////////////////////////////////////   
byte RX8_Recv( byte buf[] )   
{ byte *pRecv, i, len;   
... buf[0]= 0;   
... while( !UART_bCmdCheck() ) {}; // Wait New Packet here   
... // Find new packet   
... len= UART_bCmdLength(); // Returns the current command length   
... if( len>0 )   
... { pRecv= UART_szGetParam(); // get command and parameters   
...... strcpy( buf, pRecv );   
...... buf[63]= 0;   
... }   
... UART_CmdReset(); // Reset command buffer   
... return( len );   
}   
/////////////////////////////////////////////////////////////////   
I gatta sleep, see tomorrow   
0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

@2stroke

   

It is alwaqys advisable to create a project archive with Designer (under the File-menu) and upload the resulting file here. So we all can see your settings and definitions instead of a code-snippet.

   

Additionally: Keep in mind that a string has to be null-terminated or LCD_PrString() will not know where it ends.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

 @Bob

   

I understand, but im fairly sure that the system design is functioning correctly as proven by communication with simulation in hyperterminal, i do believe that the problems lay in my code as i am very new to c and programming in general. in any even i can post the whole project if you think it will help you determine the problem

   

@Dana

   

I actually dont have a problem with the display itself when using UART_cGetChar or UART_cGetRestOfChar then printing it with LCD_PrString();. the problem is that it seems to be returning the same command that i sent to the DCE. However, when using UART_cReadChar(); the LCD returns a garbled display so im assuming this command returns non-ascii data.

   

@PSoC73

   

Thanks for the reply and example code, i will try it first thing tommarow after work.

   

I have noticed that when communicating with the GSM using the GSM developer software (qNavigator) which is essentially the same as hyperterminal. when typing a command in this software it denotes what has been sent with an S and what has been recieved with an R. when sending the command AT the command windows indicated that AT has been sent and also recieved before OK. this is odd because in hyperterminal if i send the command AT it simply returns OK. example of qNavigator command window:

   

S:AT

   

R:AT

   

R:OK

   

it seems that im getting two responses using the gsm software but hyperterminal simply returns

   

AT

   

OK

   

now im a little lost... but thank you all for the insight so far

0 Likes
Anonymous
Not applicable
        You have review the setting of Hyperterminal   
Maybe, echo function was enabled   
So, every character you sent should loop back   
Look at option setting   
0 Likes
Anonymous
Not applicable

echo simply repeats the charcter i typed in hyperterminal back to hyperterminal. so AT becomes AATT

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

The font table in the LCD controller maps all 8 bits of any character

   

it receives. So what you are feeding it is the culprit.

   

 

   

0 Likes
Anonymous
Not applicable

 PSoC73 and Dana

   

 

   

Thanks for both of your help here, you are giving very relavent answers.

   

 

   

@PSoC, it turns out that you were not far off. The GSM has an echo command (ATE<#>) which for some reason is always set to 1 "on", so i was always reading back this command, ive inserted a command to turn this to 0 "off" but now all i get to the LCD are symbols.

   

 

   

@Dana, Thank you for the chart, alot of those symbols look familiar to what i am getting on the LCD, i will try to grasp what is being sent to the LCD and post back

0 Likes
Anonymous
Not applicable

Hey everybody

   

just thought id let you know that i have overcome my issue, the problem was that i was delaying the uC while data was being sent back by the GSM, thus getting incomplete data. romoving all delays, saving the recieved data and then printing to LCD after my getdat loop work perfectly. thanks for all the input

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

... and it is very kind of you to inform us about your solutions and project progress! Thank you.

   

 

   

Bob

0 Likes