|
|
View previous topic :: View next topic |
Author |
Message |
raKzo_82
Joined: 12 Jun 2014 Posts: 4
|
pic16f886 serial read problem |
Posted: Thu Jun 12, 2014 4:24 pm |
|
|
I am using the pic16f886 with the fingerprint sensor ZFM-20 Series, which is communicated using serial. By checking the Arduino example, and the data sheet i was able to send the handshake command. But i am unable to read all the acknowledgment sent by the sensor, only able to read the header of the acknowledge.
I am able to receive data from the hyper terminal of a pc using a max232, and i am able to read a message sent by the pic by connecting rx to tx. The problem is that i am unable to read all the information sent from the sensor.
The baud rates are the correct ones, I can see the acknowledge in the hyper terminal and it sends all the information.
This is the function I use to read from the serial port:
Code: |
void sscanf(){
int i;
while(!kbhit){}
for(i=0;i<=11;i++){
packet[i]=getc(COM_A);
}
}
|
With this function i expect 12 bytes sent from the sensor.
Thanks in advance. |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Thu Jun 12, 2014 4:45 pm |
|
|
DUH get rid of the not sign !!!!
but that is just part of your trouble
consider using the serial receive interrupt system and parse out your data .
you just have a failure prone approach , as the construct you use is faulty
look at EX_SISR in the examples folder |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19553
|
|
Posted: Fri Jun 13, 2014 12:28 am |
|
|
The 'not' is not the problem. The layout is so bad, that it looks as if it is...:
Code: |
void sscanf()
{
int i;
while(!kbhit) ; //wait for character to arrive - pointless
for(i=0;i<=11;i++)
{
packet[i]=getc(COM_A);
}
}
|
However the while if not needed (since 'getc' will just wait if a character is not available). Problem is though that like gets, the function will 'block' till 12 bytes are received, and there is nothing to check the synchronisation of received data with the array.
Big problem is that the packets aren't necessarily 12 bytes,
The format is:
Header (2 bytes)
Adder (4* 'FF' bytes - used as a marker)
ID (1 byte)
Length (2 bytes)
Length*bytes (0 to 256 bytes)
Csum (2 bytes)
So generically the packet can be anything from 11 bytes, to 267 bytes in length.
The code has to read the 'adder' bytes, and reject the packet if 0xFF is not received in these, then read the 'length' value, and loop for up to 256 data characters depending on the value received in this.
Then read the checksum, and again reject the packet if this is wrong.
Now the acknowledge packet is sometimes 12 bytes long. On this one the length is '1', and a single data byte is sent to gives status. However depending on the status, and what command was issued, extra bytes may be included:
"Acknowledge packet includes 1 byte confirmation code and maybe also the returned parameter."
Obviously with the fixed 'length' fetch code, if the parameter is returned, then the code will go wrong, and an extra byte will then be sitting 'unread' in the UART. Future fetches will make the problem worse as extra bytes build up not being read, and the data will no longer align with the array....
So the read code, needs to handle the generic packet, taking the 'length' value and using this to handle how many bytes are sent. The 'returned parameter', varies with the command being sent, but is documented in the data sheet. |
|
|
raKzo_82
Joined: 12 Jun 2014 Posts: 4
|
|
Posted: Fri Jun 13, 2014 12:31 pm |
|
|
thanks for the reply.
The code I posted earlier was a reduced function of the one i actual use, in the actual code, instead of using a fixed value, I use a variable that it's value is determined before the function is called by the main program.
The problem that I have is that i only received 2 bytes from the sensor, and when I checked what was sent by it using the hyper terminal, it sent a bigger string.
My problem is that this code doesn't read all the characters the sensor sends.
thanks in advance. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Jun 13, 2014 1:07 pm |
|
|
Quote: | The problem that I have is that i only received 2 bytes from the sensor |
The hardware UART's receive fifo is only 2 bytes deep. If the UART
receives more than 2 bytes, and you don't quickly remove them
from the buffer (with getc), the UART will lock up. You won't be
able to read any more bytes. This is probably what is happening.
You are very likely waiting, or doing something else in your program
when you should be reading the bytes out of the UART's receive buffer.
The recommended fix for this problem is to use an interrupt-driven
software receive fifo (circular buffer) for the incoming serial bytes.
The #int_rda interrupt routine will automatically read bytes from
the UART and save them in a RAM buffer.
Look at the Ex_sisr.c example file in the CCS directory:
c:\program files\picc\examples\ex_sisr.c |
|
|
raKzo_82
Joined: 12 Jun 2014 Posts: 4
|
|
Posted: Fri Jun 13, 2014 1:15 pm |
|
|
thanks i will try that |
|
|
raKzo_82
Joined: 12 Jun 2014 Posts: 4
|
|
Posted: Tue Jun 24, 2014 1:49 pm |
|
|
i tried what you suggested me to do(used the example to create a program), and it worked on the first try, and i left to my house that weekend, then on Monday i returned to continuing programming to finish the project, and it didn't work, at all.
do you know a reason of how something that worked fine, suddenly didn't work at all?
thanks in advance |
|
|
ezflyr
Joined: 25 Oct 2010 Posts: 1019 Location: Tewksbury, MA
|
|
Posted: Tue Jun 24, 2014 2:15 pm |
|
|
Hi,
Based on the information you provided, it could be anything at all. A loose connection, a failed component, not running the code you think you are running, or it never *really8 worked in the first place, etc., etc...... All these possibilities come to mind..... Are you sure the PIC is still operating? You should have a power LED connected to an I/O pin that flashes a few times on every start-up. This clearly, and unequivocally shows that your code is actually running....
If that is working, show us the code that you've got now, and let us have a look!
John |
|
|
|
|
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
|