| View previous topic :: View next topic |
| Author |
Message |
qwwe
Joined: 17 Sep 2017
Posts: 59
|
| Error value in serial communication |
 Posted: Mon Oct 16, 2017 2:15 am |
 |
|
Hi, I've debugged my program by mplab, but as soon as the first character is received from the modem, the error variable is set to 0x90 or 0x94. Can I figure out what the programming forms are?
Of course, answers are received from the modem
But in the error variable that we defined in rs232, the value is 0X90 or 0X94.
Last edited by qwwe on Wed Oct 18, 2017 10:59 pm; edited 1 time in total |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19553
|
|
| Posted: Mon Oct 16, 2017 2:36 am |
|
|
Are you using RS485?.
I think you are using RS232. If so, why have you got 'ENABLE' defined in the #USE RS232?...
Bit 7 is not used for 8bit RS232.
Bit 2 is saying you have overflowed on transmit.
Now this won't happen normally, but because you have 'ENABLE' specified, if the compiler cannot raise this line, it can give this error.
What compiler version are you using?
You need to start doing some debugging _yourself_. Also _comment_ the code. If you look at the sections that have been posted by other users they have some comments. Every subroutine should say 'what it does'. Every major call should say what it expects to happen. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9247
Location: Greensville,Ontario
|
|
| Posted: Mon Oct 16, 2017 5:01 am |
|
|
this...
| Quote: | | #useRS232(ENABLE=PIN_A2,baud=9600,xmit=PIN_C4,RCV=PIN_C5,parity=n,bits=8,errors) |
as MR. T says , implies you ARE using RS485, or similar that requires an 'enable' pin to control direction or which serial device you are using.
I haven't seen an RS485 GSM modem, so you should really post a link to your datasheet.
Also in the datasheet will be the setup times, configuration information and other need to know stuff. It is possible that the GSM is not correctly initialized.
I'd connect to a PC with ONLY a terminal program installed and manually send the commands just as the PIC does. Be sure to send 'scripts' and NOT keypresses.
Jay |
|
|
qwwe
Joined: 17 Sep 2017
Posts: 59
|
|
| Posted: Mon Oct 16, 2017 7:08 am |
|
|
I use the A2 pin I activated in rs232 just to turn on a led.
To realize that the information is now being sent.
Of course, I deleted it(enable=pin_a2) now, but as soon as the first information is received, this 0 x90 in the error variable Placed .
Mr.Ttelmah
I did not understand this part of your words:
Bit 7 is not used for 8bit RS232.
Bit 2 is saying you have overflowed on transmit.
I'm doing the modem's initial settings in the setting_gsm() function.
And the modem responds (ok) to these settings.
And these settings are done correctly until the end.
Then I send the SMS to the modem and the modem sends it to the microcontroller.
The microcontroller sometimes works correctly and sometimes not.
The microcontroller must receive the message and by editcmti() function it is the number of the house where the stored message is found.
And then sends the house number to the modem to display SMS.
When the SMS is displayed, the microcontroller decompresses the text and SMS text messages by the editcmgr() function and sends the SMS again to the SMS sender.
I first thought that the program works well until the end of the modem settings, and it only creates a problem when receiving SMS.
But after I debugged it with mplab and pickit3, I saw that as soon as the first character receives a microcontroller, it stores 0x90 in the error variable.
With Proteus, you can also debug it and get the same results.
Now, if you test this in Proteus, once the first response in the error variable is set to 0x90.
Modem used is sim808.
Rs232 should be used to communicate with this modem.
I use ccs compiler v5.049 .
Take a screenshot of how to run the program in Proteus on the link below.
I sent my OK reply to Micro.
As you can see, the program works and sends the next command, but also stores the 0X90 value in the error variable.
 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19553
|
|
| Posted: Mon Oct 16, 2017 8:09 am |
|
|
Does your LED have a current limiting resistor?. It doesn't appear to have...
If not, it'll prevent the enable pin from going high enough to work...
Bit 7 or RS232_ERRORS _means nothing unless you are using 9bit serial_. Ignore it.
Bit 2 was going high because of the wiring error on your LED. Basic electronic fault. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9247
Location: Greensville,Ontario
|
|
| Posted: Mon Oct 16, 2017 8:50 am |
|
|
also..
the xtal and caps are not wired correctly in the schematic.
while Proteus coudln't care less about this basic CRITICAL error, the PIC sure does !!
OK, the 'sim808' is JUST a chip did you add external parts or did you buy a 'module' tht has the sim808 AND a lot of other parts ?
AND
What is the power supply ? According to the sim808 data sheet, it MUST have at LEAST a 2A power supply. ADD to that the PIC power requirements, LEDS, etc. you should be using a 5 AMP power supply.
Jay |
|
|
qwwe
Joined: 17 Sep 2017
Posts: 59
|
|
| Posted: Mon Oct 16, 2017 9:39 am |
|
|
This image I put on is simulation in Proteus.
In an orbit that is bad on the board, all these connections are done correctly. Of course, in Proteus, I fixed these problems as you said, but did not change, and the error variable was set to 0X90.
Like the following: (Of course, I deleted the enable=pin_a2 from the program)
[img] [/img] |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19553
|
|
| Posted: Mon Oct 16, 2017 10:50 am |
|
|
It will be. 0x90, is not an error.
0x94 _was_ an error. 0x90 is not. Only the low 4 bits of RS232_ERRORS have any meaning unless you are using 9bit mode (which you are not).... |
|
|
qwwe
Joined: 17 Sep 2017
Posts: 59
|
|
| Posted: Mon Oct 16, 2017 10:51 am |
|
|
I changed the program to the following, but still entering the first character 0x90 in the error variable.
| Code: |
#include <16f1829.h>
#fuses HS //High speed Osc (> 4mhz for PCM/PCH)
#fuses NOWDT //Watch Dog Timer
#fuses NOPUT //Power Up Timer
#fuses NOLVP //No low voltage programing
#fuses NOCPD //No EE protection
#fuses NOPROTECT //Code not protected from reading
#fuses NOWRT //Program memory not write protected
#fuses NODEBUG //No Debug mode for ICD
#fuses NOBROWNOUT //No brownout reset
#USE DELAY (crystal=11059200)
#USE RS232(BAUD=9600,XMIT=PIN_C4,RCV=PIN_C5,PARITY=N,BITS=8,STOP=1,ERRORS)
#include <stdio.h>
#include <string.h>
/////////////////////////Define variables and arrays////////////////////////
int1 have_line=FALSE;
int8 i=0; //vaiable for function geti
int8 len,j; // variable for function clear
char recive[200];
char dq=0x22;
char enter=0x0D;
char cz=0x1A;
char linefeed=0x0A;
//////////////////////////////Definition of functions////////////////////////
void geti();
void clear();
///////////////Definition buffer and isr and read character/////////////////
#define BUFFER_SIZE 300
char buffer[BUFFER_SIZE];
int16 next_in = 0;
int16 next_out = 0;
#int_rda
void rda_isr() {
int16 t;
char g;
g=getc();
if(g==0x0A)
return; //Throw LF
if(g==0x0D)
have_line=TRUE; //set flag that there is a line
buffer[next_in]=g; //store the character
t=next_in++;
if (next_in==BUFFER_SIZE)
next_in=0; //wrap at buffer end
if(next_in==next_out)
next_in=t; // Buffer full !!
}
#define bkbhit (next_in!=next_out)
char bgetc() {
char c;
while(!bkbhit) ;
c=buffer[next_out];
next_out=(next_out+1);
if (next_out==BUFFER_SIZE)
next_out=0;
return(c);
}
///////////////////////////////main code///////////////////////////////////
void main()
{
enable_interrupts(int_rda);
enable_interrupts(GLOBAL);
while(true)
{
clear(); //clear recive array
if(bkbhit)
{
geti();
}
}
}
/////////////////////////////////Functions///////////////////////////////
void geti()
{
if(bkbhit)
{
do
{
if(bkbhit)
{
recive[i]=bgetc();
i++;
}
}while(recive[i-1]!=enter);
recive[i-1]='\0';
i=0;
}
}
////////////////////////////////////////////////////////////////////////////
void clear()
{
len=199;
for(j=0;j<=len;j++)
{
recive[j]='\0';
//restart_wdt();
}
j=0;
}
|
Debugging is shown in the figure below:
This indicates a bug in the settings. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19553
|
|
| Posted: Mon Oct 16, 2017 12:55 pm |
|
|
Read what you are being told.
The top 4 bits of RS232_ERRORS _have no meaning in the system you are using_. If you want to use the variable you need to only be looking at the low 4 bits. You can write the top bit. It is set to '1' by default, and is used as the 9th bit if you enable 9bit transmission. Bit 5 is actually the continuous receive enable bit for the chip which has to be on for the receive to work. It's used by the cleanup code if there is an overrun error, but is not an error.
0x90 is not an error. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9247
Location: Greensville,Ontario
|
|
| Posted: Mon Oct 16, 2017 5:52 pm |
|
|
sigh.....
PROTEUS is BUSTED !! It's BROKEN !! It's NOT WORKING and NEVER EVER will.....
It even 'runs' without POWER to the PIC.......
I cannot comprehend why everyone believes Proteus is flawless. I've yet to see ONE Proteus schematic that WILL function in the real world.
I could write a book about all the things that are wrong within Proteus but frankly, I've got better things to do..though IF I got $1 per book, I'd be rich overnight.
Honestly GET RID OF PROTEUS. Spend $20 get a PIC breadboard and another $50 for a scope, even a 30 year old 2 channel analog. With that investment you can get your PIC project 'up and running' in 2-3 nights or less.
I'm not sorry for the rant...but life is too short to waste so much time on busted software.
Jay |
|
|
qwwe
Joined: 17 Sep 2017
Posts: 59
|
|
| Posted: Tue Oct 17, 2017 1:02 am |
|
|
Thanks, however, when I got rid of the circuit again, the following point drew me:
As you can see in the pictureŘ
As you can see in the screenshot, the address of the variables I have defined in the program is identical with the houses in the recive array and the values of those variables are in the recive array.
I did this debugging both in Proteus and in the mplab software and pickit3 , and the results were the same.
Of course, another drawback point is that it displays a number of home arrays as "Restricted Memory".
Debugging with mplab software and pickit3:
 [/img]
 [/img]
Debugging with Proteus software:
 [/img]
 [/img]
What is it about? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9247
Location: Greensville,Ontario
|
|
| Posted: Tue Oct 17, 2017 5:31 am |
|
|
re: restricted memory... error/warning
You really need to read the datasheet and the CCS manuals. mid range( 16 series ) PICs have banked memory NOT a linear array. As such you have to inform the compiler you wish to use more than 1 bank of RAM. Ther's a simple precompiler directive for that.
While others may tell you the exact way to deal with this, you should read and investigate. That way you will learn and remember 'details'.
Jay |
|
|
qwwe
Joined: 17 Sep 2017
Posts: 59
|
|
| Posted: Tue Oct 17, 2017 8:11 am |
|
|
| I now know that the RAM memory microcontroller has banks that need to do things to access all of them. Please give me more tips on what to do in ccs. This guide is on the ccs guide page |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19553
|
|
| Posted: Tue Oct 17, 2017 8:15 am |
|
|
| Code: |
#include <16f1829.h>
#device *=16
|
This tells the compiler to generate 16bit addresses, and automatically memory switch.
However this is the _default_ behaviour, otherwise it'd not be allowing you to use the amount of RAM you are.
It is putting the linefeed at the same 'address' , but in a different bank.
The debugger does not fully understand this.
This is a limitation of the interface between the compiler and the debugger.... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
