- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Labels:
-
PSoC 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Maybe, echo function was enabled
So, every character you sent should loop back
Look at option setting
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
echo simply repeats the charcter i typed in hyperterminal back to hyperterminal. so AT becomes AATT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
... and it is very kind of you to inform us about your solutions and project progress! Thank you.
Bob