I have a problem.
Im connecting to a device using serial port, and this dev use 2 stop bit, parity
par.
Im simulating 2 stop bit when sending, just waiting 5 milisecs between bytes,
like this:
for (i=0;i
{
wfd cof_serDputc(data[i]);
waitfor(DelayMs(5));
}
Seems to work fine, my problem is on receiving, i do this:
reply = serCread(data,lengthdata,1000);
Some times i dont get the whole packet. and every time if i check for even
parity i get a parity error, on all the packages.
So, i start thinking maybe the reception routines dont work as expected because
the sender is using two stop bits. Im worng? Or that must work whith the code i
use?
Any help please.
Thanks in advance.
Simulate 2 stop bit on reception
Started by ●May 22, 2011
Reply by ●May 22, 20112011-05-22
On 5/22/2011 8:35 PM, DonaldShimoda wrote:
> So, i start thinking maybe the reception routines dont work as expected because the sender is using two stop bits. Im worng? Or that must work whith the code i use?
Not a problem on receive. Additional stop bits just looks like a gap
between characters.
Is it 8-bit+ parity or 7-bit + parity>
--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
Rabbit libs: http://shdesigns.org/rabbit/
------
> So, i start thinking maybe the reception routines dont work as expected because the sender is using two stop bits. Im worng? Or that must work whith the code i use?
Not a problem on receive. Additional stop bits just looks like a gap
between characters.
Is it 8-bit+ parity or 7-bit + parity>
--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
Rabbit libs: http://shdesigns.org/rabbit/
------
Reply by ●May 23, 20112011-05-23
If you're using a recent version of Dynamic C (10.60 or later), I believe
it has native support for 2 stop bits.
Take a look at the RS232 function for setting parity (view function help with Ctrl-H). One of the flags should include 2 stop bits.
If it's not there, try searching RS232.LIB for the string "2STOP". I haven't used it recently, and I'm on my personal computer right now so I can't look it up.
As for the receive, are you setting the correct number of data bits? That could explain the parity errors. As Scott stated, you don't need to do anything special to receive data with 2 stop bits.
-Tom
On May 22, 2011, at 5:35 PM, DonaldShimoda wrote:
> I have a problem.
>
> Im connecting to a device using serial port, and this dev use 2 stop bit, parity par.
>
> Im simulating 2 stop bit when sending, just waiting 5 milisecs between bytes, like this:
>
> for (i=0;i > {
> wfd cof_serDputc(data[i]);
> waitfor(DelayMs(5));
> }
>
> Seems to work fine, my problem is on receiving, i do this:
>
> reply = serCread(data,lengthdata,1000);
>
> Some times i dont get the whole packet. and every time if i check for even parity i get a parity error, on all the packages.
>
> So, i start thinking maybe the reception routines dont work as expected because the sender is using two stop bits. Im worng? Or that must work whith the code i use?
>
> Any help please.
>
> Thanks in advance.
Take a look at the RS232 function for setting parity (view function help with Ctrl-H). One of the flags should include 2 stop bits.
If it's not there, try searching RS232.LIB for the string "2STOP". I haven't used it recently, and I'm on my personal computer right now so I can't look it up.
As for the receive, are you setting the correct number of data bits? That could explain the parity errors. As Scott stated, you don't need to do anything special to receive data with 2 stop bits.
-Tom
On May 22, 2011, at 5:35 PM, DonaldShimoda wrote:
> I have a problem.
>
> Im connecting to a device using serial port, and this dev use 2 stop bit, parity par.
>
> Im simulating 2 stop bit when sending, just waiting 5 milisecs between bytes, like this:
>
> for (i=0;i > {
> wfd cof_serDputc(data[i]);
> waitfor(DelayMs(5));
> }
>
> Seems to work fine, my problem is on receiving, i do this:
>
> reply = serCread(data,lengthdata,1000);
>
> Some times i dont get the whole packet. and every time if i check for even parity i get a parity error, on all the packages.
>
> So, i start thinking maybe the reception routines dont work as expected because the sender is using two stop bits. Im worng? Or that must work whith the code i use?
>
> Any help please.
>
> Thanks in advance.
Reply by ●May 23, 20112011-05-23
Hi there,
I am curious to why you need 5ms between each byte? This is not something I
have seen before except for Modbus reception where it is used to detect the
end of a message.
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
From: r... [mailto:r...] On
Behalf Of DonaldShimoda
Sent: 23 May 2011 07:35
To: r...
Subject: [rabbit-semi] Simulate 2 stop bit on reception
I have a problem.
Im connecting to a device using serial port, and this dev use 2 stop bit,
parity par.
Im simulating 2 stop bit when sending, just waiting 5 milisecs between
bytes, like this:
for (i=0;i {
wfd cof_serDputc(data[i]);
waitfor(DelayMs(5));
}
Seems to work fine, my problem is on receiving, i do this:
reply = serCread(data,lengthdata,1000);
Some times i dont get the whole packet. and every time if i check for even
parity i get a parity error, on all the packages.
So, i start thinking maybe the reception routines dont work as expected
because the sender is using two stop bits. Im worng? Or that must work whith
the code i use?
Any help please.
Thanks in advance.
I am curious to why you need 5ms between each byte? This is not something I
have seen before except for Modbus reception where it is used to detect the
end of a message.
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
From: r... [mailto:r...] On
Behalf Of DonaldShimoda
Sent: 23 May 2011 07:35
To: r...
Subject: [rabbit-semi] Simulate 2 stop bit on reception
I have a problem.
Im connecting to a device using serial port, and this dev use 2 stop bit,
parity par.
Im simulating 2 stop bit when sending, just waiting 5 milisecs between
bytes, like this:
for (i=0;i {
wfd cof_serDputc(data[i]);
waitfor(DelayMs(5));
}
Seems to work fine, my problem is on receiving, i do this:
reply = serCread(data,lengthdata,1000);
Some times i dont get the whole packet. and every time if i check for even
parity i get a parity error, on all the packages.
So, i start thinking maybe the reception routines dont work as expected
because the sender is using two stop bits. Im worng? Or that must work whith
the code i use?
Any help please.
Thanks in advance.
Reply by ●May 23, 20112011-05-23
--- In r..., Scott Henion wrote:
> Not a problem on receive. Additional stop bits just looks like a gap
> between characters.
Thanks for clarify.
>
> Is it 8-bit+ parity or 7-bit + parity>
8 bit E parity
> Not a problem on receive. Additional stop bits just looks like a gap
> between characters.
Thanks for clarify.
>
> Is it 8-bit+ parity or 7-bit + parity>
8 bit E parity
Reply by ●May 23, 20112011-05-23
--- In r..., Tom Collins wrote:
>
> If you're using a recent version of Dynamic C (10.60 or later), I believe it has native support for 2 stop bits.
I cannot use Dynamic C 10.xx because im using RCM3000 series.
> Take a look at the RS232 function for setting parity (view function help with Ctrl-H). One of the flags should include 2 stop bits.
>
> If it's not there, try searching RS232.LIB for the string "2STOP". I haven't used it recently, and I'm on my personal computer right now so I can't look it up.
Theres no support to 2 STOP BITS in dynamic C 9.xx , confirmed.
> As for the receive, are you setting the correct number of data bits? That could explain the parity errors. As Scott stated, you don't need to do anything special to receive data with 2 stop bits.
Yes, 8 bits + E parity.
Thanks.
>
> If you're using a recent version of Dynamic C (10.60 or later), I believe it has native support for 2 stop bits.
I cannot use Dynamic C 10.xx because im using RCM3000 series.
> Take a look at the RS232 function for setting parity (view function help with Ctrl-H). One of the flags should include 2 stop bits.
>
> If it's not there, try searching RS232.LIB for the string "2STOP". I haven't used it recently, and I'm on my personal computer right now so I can't look it up.
Theres no support to 2 STOP BITS in dynamic C 9.xx , confirmed.
> As for the receive, are you setting the correct number of data bits? That could explain the parity errors. As Scott stated, you don't need to do anything special to receive data with 2 stop bits.
Yes, 8 bits + E parity.
Thanks.
Reply by ●May 23, 20112011-05-23
--- In r..., "Dave McLaughlin" wrote:
>
> Hi there,
>
> I am curious to why you need 5ms between each byte? This is not something I
> have seen before except for Modbus reception where it is used to detect the
> end of a message.
To be sure the extra STOP BIT not sended dont impact the other device.
>
> Hi there,
>
> I am curious to why you need 5ms between each byte? This is not something I
> have seen before except for Modbus reception where it is used to detect the
> end of a message.
To be sure the extra STOP BIT not sended dont impact the other device.
Reply by ●May 23, 20112011-05-23
On 5/23/2011 8:43 AM, DonaldShimoda wrote:
>
>> Is it 8-bit+ parity or 7-bit + parity>
> 8 bit E parity
How are you checking parity? The data is 9 bits and only 8 will be
stored by the receive function.
--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
Rabbit libs: http://shdesigns.org/rabbit/
------
>
>> Is it 8-bit+ parity or 7-bit + parity>
> 8 bit E parity
How are you checking parity? The data is 9 bits and only 8 will be
stored by the receive function.
--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
Rabbit libs: http://shdesigns.org/rabbit/
------
Reply by ●May 23, 20112011-05-23
On May 23, 2011, at 5:51 AM, Scott Henion wrote:
> On 5/23/2011 8:43 AM, DonaldShimoda wrote:
> >
> >> Is it 8-bit+ parity or 7-bit + parity>
> > 8 bit E parity
>
> How are you checking parity? The data is 9 bits and only 8 will be
> stored by the receive function.
And how are you sending with 8 bits and even parity?
Have you looked at data on the serial line to confirm how it's actually being sent? I haven't worked with an extensive number of serial devices, but 8E2 doesn't sound very common.
-Tom
> On 5/23/2011 8:43 AM, DonaldShimoda wrote:
> >
> >> Is it 8-bit+ parity or 7-bit + parity>
> > 8 bit E parity
>
> How are you checking parity? The data is 9 bits and only 8 will be
> stored by the receive function.
And how are you sending with 8 bits and even parity?
Have you looked at data on the serial line to confirm how it's actually being sent? I haven't worked with an extensive number of serial devices, but 8E2 doesn't sound very common.
-Tom
Reply by ●May 24, 20112011-05-24
--- In r..., Scott Henion wrote:
>
> On 5/23/2011 8:43 AM, DonaldShimoda wrote:
> >
> >> Is it 8-bit+ parity or 7-bit + parity>
> > 8 bit E parity
>
> How are you checking parity? The data is 9 bits and only 8 will be
> stored by the receive function.
No, is 8 BIT for data and 1 BIT for parity. I just check the flag povided for Dynamic C
errorparidad = ((serCgetError() & SER_PARITY_ERROR));
If errorparidad is true, a parity error is present.
I startthinking about some dynamic c internal error related to cofuncitons, will try to use latest 9.62 version, if dont help you lib coexec as first and probably migrate to softools. The problem with softools is you must buy a license before start anything...
>
> On 5/23/2011 8:43 AM, DonaldShimoda wrote:
> >
> >> Is it 8-bit+ parity or 7-bit + parity>
> > 8 bit E parity
>
> How are you checking parity? The data is 9 bits and only 8 will be
> stored by the receive function.
No, is 8 BIT for data and 1 BIT for parity. I just check the flag povided for Dynamic C
errorparidad = ((serCgetError() & SER_PARITY_ERROR));
If errorparidad is true, a parity error is present.
I startthinking about some dynamic c internal error related to cofuncitons, will try to use latest 9.62 version, if dont help you lib coexec as first and probably migrate to softools. The problem with softools is you must buy a license before start anything...
