 |
 |
| View previous topic :: View next topic |
| Author |
Message |
gokayk
Joined: 25 Mar 2012
Posts: 8
|
|
 Posted: Wed Mar 28, 2012 2:59 am |
 |
|
| Gabriel wrote: | im not able to see your diagram... link?
ok, so i guess you are hooking up the pic directly to the phone? and are only using the connector to get phisical acces to the pone pins?
then you do not need the Max 232... however the phone is operating at 3.3V..... a level converter should be used probably. in this case a voltage devider on the PIC tx line should do the trick...
if you connect directly then you dont need to swap the lines... just make sure you have tx to Rx and rx to Tx accordingly...
which pin on the cell needs to be high?
http://en.wikipedia.org/wiki/IEEE_802.11_RTS/CTS ignore this...
edit... its this link...
| Quote: | | http://en.wikipedia.org/wiki/RS-232_RTS/CTS#RTS.2FCTS_handshaking |
that should give you a hint...
however.... check the AT command list and see if it is possible to turn off the Hardware flow control.... if so, then all you need is GND. RX and TX!
G. |
Gabriel,
I am using the connector to get phisical acces to the phone, then from phone to my max232 circuit then to the pic. So i don't connect my cable from phone to PIC directly. Same setup for PC & Phone communication too.
This is original using for my circuit:
Max232 IC's 11 (for PIC Tx as my circuit picture)
Max232 IC's 14 (for phone Rx as my circuit picture)
Max232 IC's 12 (for PIC Rx as my circuit picture)
Max232 IC's 13 (for phone Tx as my circuit picture)
When i want to try my phone with PC (hyper teminal, i just remove cable from PIC side, and i connect my other cable from another I/Os of Max232 as per shown below:
Max232 IC's 10 (for PIC Tx)
Max232 IC's 7 (for PC Rx)
Max232 IC's 9 (for PIC Rx)
Max232 IC's 8 (for PC Tx)
By the way, i never connected my phone Rx Tx to PC Rx Tx directly.
"im not able to see your diagram... link?"
Please see the picture that copied from related web page:
http://img267.imageshack.us/img267/8937/84090065.jpg
+IFC this command is using for TE-TA Local Flow Control, so;
when i send this command first, i won't need any other pin pull-up from phone side,
AT+IFC=[<by_te>],[<by_ta>]
< by_te >
0: No flow control on TE.
1: Xon/Xoff flow control on TA. Control characters are removed by the TA interface.
2: RTS flow control on TA, default value
<by_ta>
0: No flow control on TA.
1: Xon/Xoff flow control on TE.
2: CTS flow control on TA, default value
All i need to send this command before try to recieve data from phone?
AT+IFC=[0],[0]
Am i right?
Thanks, |
|
 |
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Wed Mar 28, 2012 6:20 am |
|
|
Your code for detecting a received string from the mobile has several flaws. For example, you always wait for 8 characters to be received. If something happens and this is a smaller number then your code will fail. Or, what will happen if a new text is received during your 500ms delay (why?) between reception and analysing the received data.
Some minor issues to improve your code:
1) | Code: | | setup_spi(SPI_SS_DISABLED); |
This is an error in the CCS setup wizard and results in an invalid configuration with unpredictable results. Change to:
2) | Code: | recieve_string[counter_read]=getchar();
counter_read++;
if(counter_read==69)
{
counter_read=0;
} |
The buffer has a size of 70, by testing for 69 you are wasting the last character in the buffer. Instead of hard coded magical numbers it is better to use a defined value, then it is more clear where the value comes from and maintenance is easier because you only have to change the value in one location.
3) | Code: | #define green_led pin_c2
#define blue_led pin_c3 |
Good coding convention is to have all constants in capital letters.
4) | Code: | | set_tris_c(0b10100000); |
In CCS it is unusual to set the TRIS registers yourself as the compiler does this automatically for you. The compiler adds code to set the TRIS register on every I/O operation, if you don't want this to happen you have to add the #use fast_io directive. See the manual for more info.
5) | Code: | #if defined(__PCM__)
#include <18F452.h>
...
#elif defined(__PCH__)
#include <18F452.h>
...
#endif |
This makes no sense. Try to understand what this code does. In the first line you are testing for the PCM compiler, i.e. the compiler for PIC16, but you include the PIC18F452 header file. When you are only compiling for the PIC18 then get rid of the first part and remove all #if/else code constructs.
6) I have bad experiences with Hyperterm. Sometimes the program does not show the received data, even when a serial port analyser shows the data to be sent to the PC. Best is to use another program like:
- Siow (in your PICC directory)
- Putty
- Tera Term
- Br@y Terminal |
|
|
gokayk
Joined: 25 Mar 2012
Posts: 8
|
|
| Posted: Wed Mar 28, 2012 7:14 am |
|
|
| ckielstra wrote: | Your code for detecting a received string from the mobile has several flaws. For example, you always wait for 8 characters to be received. If something happens and this is a smaller number then your code will fail. Or, what will happen if a new text is received during your 500ms delay (why?) between reception and analysing the received data.
Some minor issues to improve your code:
1) | Code: | | setup_spi(SPI_SS_DISABLED); |
This is an error in the CCS setup wizard and results in an invalid configuration with unpredictable results. Change to:
2) | Code: | recieve_string[counter_read]=getchar();
counter_read++;
if(counter_read==69)
{
counter_read=0;
} |
The buffer has a size of 70, by testing for 69 you are wasting the last character in the buffer. Instead of hard coded magical numbers it is better to use a defined value, then it is more clear where the value comes from and maintenance is easier because you only have to change the value in one location.
3) | Code: | #define green_led pin_c2
#define blue_led pin_c3 |
Good coding convention is to have all constants in capital letters.
4) | Code: | | set_tris_c(0b10100000); |
In CCS it is unusual to set the TRIS registers yourself as the compiler does this automatically for you. The compiler adds code to set the TRIS register on every I/O operation, if you don't want this to happen you have to add the #use fast_io directive. See the manual for more info.
5) | Code: | #if defined(__PCM__)
#include <18F452.h>
...
#elif defined(__PCH__)
#include <18F452.h>
...
#endif |
This makes no sense. Try to understand what this code does. In the first line you are testing for the PCM compiler, i.e. the compiler for PIC16, but you include the PIC18F452 header file. When you are only compiling for the PIC18 then get rid of the first part and remove all #if/else code constructs.
6) I have bad experiences with Hyperterm. Sometimes the program does not show the received data, even when a serial port analyser shows the data to be sent to the PC. Best is to use another program like:
- Siow (in your PICC directory)
- Putty
- Tera Term
- Br@y Terminal |
I am at the bottom of the ladder about writting this type of programs. So, i'm trying to understand everything & listen all the comments. That is the mean reason of sharing my problems with you in this forum.
Item no.1: I'll change.
Item no.2,3,4: nice advice, i'll remember them.
Item no.5: To be honest, i really didn't know why i used it for. After i search sth about this issue, i realized that it is used for due to different type of PIC series. So i don't need to use this code for selection.
Item no.6: I'll download & try them.
Thanks for your all comments. |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Wed Mar 28, 2012 7:20 am |
|
|
@ ckielstra: ... no magical numbers.
buffer size is 70... the ISR uses values 0 to 69, in other words, 70 values.
however, you are right... it was a dumb mistake.
why is it 70? well... later when we get this to work, he will send the phone an SMS message... when he does AT+CMGR=1... the phone will spit out a string the size of king kong.... 70 is the perfect size for the buffer to fill 2 times and catch the message part of the sms.... no magic, just carefull observation. although i agree it could be cleaner.
what happens if you dont get 8 values? you are stuck... but who cares.. your comm with the cell is not working.... id rather have the pic program fail safely (get stuck in a harmless loop) than continue to run and start doing random things... who knows what the rest of the pic program does....
what happens if you get more characters after the 8 initial values during the 500 ms delay?
NOTHING.... they are stored in your large and safe Buffer.
you can parse them later...
how ever if your dont find an OK in the first 8.... your "action" failed in this case.....
@gokayk:
connections must be as follows:
CELL to PIC: no MAX232 chip.
put a 2/3 voltage divider on the TX line of the PIC... cell runs at 3.3V - your pic is running at 5 most likely, so you need to bring the PICs TX line from 5V to 3.3V. ... the TX of the phone is 3.3V and thats enough for the PICs RX to read properly.
from what i understood you are only using the connector to get acces to the phones pins... the phone im sure does NOT output RS232 Voltage levels....
CELL to PC Place a MAX 232 Between them, the CELL uses the TTL pins the pc uses the rs232 pins...DO NOT CONNECT THE PHONE TO THE PC WITOUT A MAX232.
PIC to PC Place a MAX 232 Between them, the PIC uses the TTL pins the pc uses the rs232 pins...
now, hardware flow control...
do a AT+IFC=?
see what values its got set...
and then as you mentioned set tem to (0,0)...
please answer this: can you talk to the phone using hyperterminal?
if you can, then disable flow control, and SAVE THE SETTINGS.
if you can NOT talk to the phone on hyperterminal... until you can, its pointless to keep helping you... you have a hardware problem.
since you probably have flow control enabled, a 3 wire (RX, TX, GND) calbe wont work with the pic or the PC...
so, you wont be able to turn Flow control off...
so,
make a cable TX, RX, GND, CTS, DTS.... using a MAX232 for the TX and RX lines... plug it to your pc...
send AT... did you get OK? NO? do next, YES? your done.
set CTS high, send AT... did you get OK? NO? do next, YES? your done.
set RTS high, send AT... did you get OK? NO? do next, YES? your done.
....still cant see your circuit... my network at work blocks everything...
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
gokayk
Joined: 25 Mar 2012
Posts: 8
|
|
| Posted: Wed Mar 28, 2012 1:15 pm |
|
|
Gabriel:
I can send AT commands to my phone by using Hyper terminal.
1-) I've sent AT+IFC? recieved +IFC: 2,2
2-) I've sent AT+IFC=0,0 recieved OK
3-) I've sent AT+IFC? recieved +IFC: 0,0
4-) I've sent AT&W0 recieved OK
Now flow control is disabled.
Then i prepared my circuit (inclusive PIC, exclusive MAX232)
I made voltage divider for Tx port of PIC. 3.3V max when 5V comes.
Then i connected Rx port of phone to Tx port of PIC, Tx port of phone to Rx port of PIC.
What happened?
Nothing 
I'm almost giving up  |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Thu Mar 29, 2012 3:26 am |
|
|
| Gabriel wrote: | | @ ckielstra: ... no magical numbers. |
As Wikipedia says it:
'Magic number' is a term used for unique values with unexplained meaning or multiple occurrences which could (preferably) be replaced with named constants.
The point I tried to make is that it is better programming style to replace the hard coded value '70' by a define, for example: | Code: | | #define RECEIVE_BUF_SIZE 70 |
This way the code becomes easier to maintain as you can change the buffer size by modifying just one line in your code.
As for the reason to why you did choose 70 it would have been nice to add this as comment to the #define line but that was not the intention of my remark.
| Gabriel wrote: | CELL to PIC: no MAX232 chip.
put a 2/3 voltage divider on the TX line of the PIC... cell runs at 3.3V - your pic is running at 5 most likely, so you need to bring the PICs TX line from 5V to 3.3V. ... the TX of the phone is 3.3V and thats enough for the PICs RX to read properly. |
Please, be very careful with this design as it is a quick-and-dirty solution that we have seen a lot on this forum and has caused many projects to fail.
See Table 22.2 of the PIC18F452 data sheet:
For TTL inputs a minimum of 2V input voltage is enough to be seen as a high level. The 3.3V of the mobile is high enough to meet this requirement.
But, now check the specifications of your receive port, Table 9-5:
All port-C pins are Schmitt Trigger type, not TTL !
Table 22.2 says that Schmitt Trigger inputs require 0.8Vdd for input high, at 5V power supply that is a minimum 4V input level. Your 3.3V mobile is failing here!
One quick-and-dirty workaround is to change the mobile to Port-B pins. Do not use Port-D as these pins are Schmitt Trigger type too.
Note that the hardware UART with interrupts is always tied to C6/C7 so you can not move the PC-serial to another port, and this is not needed.
The preferred solution would be to use a PIC that is running 3.3V, then no interface glue is required. For example the PIC18LF452 (note the 'L'), or one of the many newer PICs that run 3V and are cheaper than the old 452.
Or add a dedicated voltage level translation IC like the 5-pin, single port 74LVC1G125 (about €0,13 at 10 pieces).
Or pass the signal through a 74HCTxx chip powered at 5V
Or because it is only a single line, build a discrete circuit with a FET and few resistors. See the MOSFET paragraph at the end of this Sparkfun tutorial. |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Thu Mar 29, 2012 3:15 pm |
|
|
@ckielstra: ... You are right. it is magical.
@gokayk..
maybe ckielstra's scmitt trigger comment is the cause?... his explanation is quite clear... and makes total sense....
do you have an oscilloscope? check if ANYTHING is comming out of the phone....
try his suggestion:
| Quote: | | Or pass the signal through a 74HCTxx chip powered at 5V |
seems easy and fast...
post your latest code... and dont give up... "You can doit"
ill check back in tomorrow when i have abit more time... keep trying...
G
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
|
|
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
