Serial Port Issues

[tesko905]

Hi NG,

I've recently taken on the task of creating some custom software for
a
Treo 750v. The Treo has a working serial port (tested with a
terminal
emulator) and is running Windows Mobile 5.0 with Compact Framework
2.0
installed.

Lets start off with some background first....

For my first attempt, I attempted using the emulator, and the first
issue I encountered was that I could not receive any data on the
serial
port (BytesToRead property was always 0, and yes I bound the emulator
comport to a real comport in the settings). So, for the heck of it I
compiled the same code, and ran it as a standalone app on windows XP.
Everything worked great! So I finished developing the app, running
into
many minor issues, one of which was:

serial.write(chr(data).toString) has a TX parity error 40% of the
time.
Switching to a byte array solved it (don't know why), and I went
along
my merry way.

Anyway, the app is finished, and ready to be installed on the
handheld
device. I installed it, it fired up no problem, then as soon as
communication begins I'm bombarded with frame error after frame
error.
Obviously it has to do with it being run on a handheld, and
unfortunately I don't have another model handheld to test on. Anyone
have any similar issues?

-Thanks

 

[Paul G. Tobey [eMVP]]

Remember that a string is a set of Unicode characters in Windows CE, *not* a
set of bytes, which is probably what the other end of your communication
session is expecting. If sending a set of bytes always works, that's the
whole problem and you need to take a while to understand the difference
between a byte and a Char when the operating system is Unicode based.

Paul T.

 

[Tesko905]

In the back of my head I was thinking it was probably something along
those lines, adding additional data or what not. However, that is
irrelevant, as that is not the issue I am having at the moment.

"Anyway, the app is finished, and ready to be installed on the
handheld device. I installed it, it fired up no problem, then as soon
as communication begins I'm bombarded with frame error after frame
error."

It runs perfectly fine on XP with the compact framework, however when
the same executable is copied to the device, I get frame error after
frame error.

Any more insite?

-Thanks

 

[Paul G. Tobey [eMVP]]

I'm not convinced that this means something (or I wouldn't have said
"Unicode"). What serial port parameters (baud, etc.), are set on the device
when the framing errors are reported?

Paul T.

 

[Tesko905]

Ok here's an over view of the setup.

There is a "black box" that communicates at 57600 8-N-1. I connect
this box to my PC with a 3 wire RS232 interface. I run my custom app
on the XP based PC and everything is fine. Communication is perfect,
the whole process is mint. Now, when I take the EXACT same executable
and copy it to the handheld device, hook the "black box" up to the
handheld with the same RS232 interface, I get frame error after frame
error as soon as communication starts. Also, neither my app or the
"black box" use hardware handshaking or XON/XOFF.

Some background:

I'm using VS2005
VB.Net
Compact Framework 2.0
Pocket PC SDK

 

[Guest]

57600 without handshaking may cause a problem (and handshaking with 3-wire
might be tough). Can you slow down the transmitter to see if that's the
potential problem? Also, I assume you don't have some crazy-long cable or
noisy environment?


--
Chris Tacke - Embedded MVP
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--

Ok here's an over view of the setup.

There is a "black box" that communicates at 57600 8-N-1. I connect
this box to my PC with a 3 wire RS232 interface. I run my custom app
on the XP based PC and everything is fine. Communication is perfect,
the whole process is mint. Now, when I take the EXACT same executable
and copy it to the handheld device, hook the "black box" up to the
handheld with the same RS232 interface, I get frame error after frame
error as soon as communication starts. Also, neither my app or the
"black box" use hardware handshaking or XON/XOFF.

Some background:

I'm using VS2005
VB.Net
Compact Framework 2.0
Pocket PC SDK

I'm not convinced that this means something (or I wouldn't have said
"Unicode"). What serial port parameters (baud, etc.), are set on the
device
when the framing errors are reported?

Paul T.

In the back of my head I was thinking it was probably something along
those lines, adding additional data or what not. However, that is
irrelevant, as that is not the issue I am having at the moment.

"Anyway, the app is finished, and ready to be installed on the
handheld device. I installed it, it fired up no problem, then as soon
as communication begins I'm bombarded with frame error after frame
error."

It runs perfectly fine on XP with the compact framework, however when
the same executable is copied to the device, I get frame error after
frame error.

Any more insite?

-Thanks

On Feb 13, 3:24 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Remember that a string is a set of Unicode characters in Windows CE,
*not* a
set of bytes, which is probably what the other end of your
communication
session is expecting. If sending a set of bytes always works, that's
the
whole problem and you need to take a while to understand the
difference
between a byte and a Char when the operating system is Unicode based.

Paul T.

Hi NG,

I've recently taken on the task of creating some custom software for
a
Treo 750v. The Treo has a working serial port (tested with a
terminal
emulator) and is running Windows Mobile 5.0 with Compact Framework
2.0
installed.

Lets start off with some background first....

For my first attempt, I attempted using the emulator, and the first
issue I encountered was that I could not receive any data on the
serial
port (BytesToRead property was always 0, and yes I bound the
emulator
comport to a real comport in the settings). So, for the heck of it
I
compiled the same code, and ran it as a standalone app on windows
XP.
Everything worked great! So I finished developing the app, running
into
many minor issues, one of which was:

serial.write(chr(data).toString) has a TX parity error 40% of the
time.
Switching to a byte array solved it (don't know why), and I went
along
my merry way.

Anyway, the app is finished, and ready to be installed on the
handheld
device. I installed it, it fired up no problem, then as soon as
communication begins I'm bombarded with frame error after frame
error.
Obviously it has to do with it being run on a handheld, and
unfortunately I don't have another model handheld to test on.
Anyone
have any similar issues?

-Thanks

 

[Paul G. Tobey [eMVP]]

And you're sure that the hardware for serial I/O on your Windows CE device
*supports* 57600? It's a low enough rate that it would be a bit surprising
if not, but it might not.

There are two parallel tracks that I'd take if this were my problem:

1. Verify that the hardware will support the indicated communication
parameters and that you have suitable wiring. You may need to contact the
device manufacturer for this.

2. Make sure that the serial port driver will support what you're trying to
do. To do this, forget about managed code and write some simple code to
send and receive data in C/C++. Check all return codes from Win32 API calls
to verify that they are not indicating problems with any of your parameters.

One or the other of these will no doubt point you to what is causing the
problem.

Paul T.

Ok here's an over view of the setup.

There is a "black box" that communicates at 57600 8-N-1. I connect
this box to my PC with a 3 wire RS232 interface. I run my custom app
on the XP based PC and everything is fine. Communication is perfect,
the whole process is mint. Now, when I take the EXACT same executable
and copy it to the handheld device, hook the "black box" up to the
handheld with the same RS232 interface, I get frame error after frame
error as soon as communication starts. Also, neither my app or the
"black box" use hardware handshaking or XON/XOFF.

Some background:

I'm using VS2005
VB.Net
Compact Framework 2.0
Pocket PC SDK

I'm not convinced that this means something (or I wouldn't have said
"Unicode"). What serial port parameters (baud, etc.), are set on the
device
when the framing errors are reported?

Paul T.

In the back of my head I was thinking it was probably something along
those lines, adding additional data or what not. However, that is
irrelevant, as that is not the issue I am having at the moment.

"Anyway, the app is finished, and ready to be installed on the
handheld device. I installed it, it fired up no problem, then as soon
as communication begins I'm bombarded with frame error after frame
error."

It runs perfectly fine on XP with the compact framework, however when
the same executable is copied to the device, I get frame error after
frame error.

Any more insite?

-Thanks

On Feb 13, 3:24 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Remember that a string is a set of Unicode characters in Windows CE,
*not* a
set of bytes, which is probably what the other end of your
communication
session is expecting. If sending a set of bytes always works, that's
the
whole problem and you need to take a while to understand the
difference
between a byte and a Char when the operating system is Unicode based.

Paul T.

Hi NG,

I've recently taken on the task of creating some custom software for
a
Treo 750v. The Treo has a working serial port (tested with a
terminal
emulator) and is running Windows Mobile 5.0 with Compact Framework
2.0
installed.

Lets start off with some background first....

For my first attempt, I attempted using the emulator, and the first
issue I encountered was that I could not receive any data on the
serial
port (BytesToRead property was always 0, and yes I bound the
emulator
comport to a real comport in the settings). So, for the heck of it
I
compiled the same code, and ran it as a standalone app on windows
XP.
Everything worked great! So I finished developing the app, running
into
many minor issues, one of which was:

serial.write(chr(data).toString) has a TX parity error 40% of the
time.
Switching to a byte array solved it (don't know why), and I went
along
my merry way.

Anyway, the app is finished, and ready to be installed on the
handheld
device. I installed it, it fired up no problem, then as soon as
communication begins I'm bombarded with frame error after frame
error.
Obviously it has to do with it being run on a handheld, and
unfortunately I don't have another model handheld to test on.
Anyone
have any similar issues?

-Thanks

 

[Tesko905]

I'm 100% positive it supports 57600. I've used a Terminal program on
it to connect to other 57600 devices, as well as the "black box".
Communication worked flawlessly. That's why I'm leaning towards
a .NET - Device incompatibility or something along those lines. As
for working with C/C++ to make some simple Win32 API calls, that
sounds like a good place to start. I've never dealt directly with the
Win32 API for serial access, any links to a tutorial or place to
start?

-Thanks

And you're sure that the hardware for serial I/O on your Windows CE device
*supports* 57600? It's a low enough rate that it would be a bit surprising
if not, but it might not.

There are two parallel tracks that I'd take if this were my problem:

1. Verify that the hardware will support the indicated communication
parameters and that you have suitable wiring. You may need to contact the
device manufacturer for this.

2. Make sure that the serial port driver will support what you're trying to
do. To do this, forget about managed code and write some simple code to
send and receive data in C/C++. Check all return codes from Win32 API calls
to verify that they are not indicating problems with any of your parameters.

One or the other of these will no doubt point you to what is causing the
problem.

Paul T.

Ok here's an over view of the setup.

There is a "black box" that communicates at 57600 8-N-1. I connect
this box to my PC with a 3 wire RS232 interface. I run my custom app
on the XP based PC and everything is fine. Communication is perfect,
the whole process is mint. Now, when I take the EXACT same executable
and copy it to the handheld device, hook the "black box" up to the
handheld with the same RS232 interface, I get frame error after frame
error as soon as communication starts. Also, neither my app or the
"black box" use hardware handshaking or XON/XOFF.

Some background:

I'm using VS2005
VB.Net
Compact Framework 2.0
Pocket PC SDK

I'm not convinced that this means something (or I wouldn't have said
"Unicode"). What serial port parameters (baud, etc.), are set on the
device
when the framing errors are reported?
Paul T.

In the back of my head I was thinking it was probably something along
those lines, adding additional data or what not. However, that is
irrelevant, as that is not the issue I am having at the moment.
"Anyway, the app is finished, and ready to be installed on the
handheld device. I installed it, it fired up no problem, then as soon
as communication begins I'm bombarded with frame error after frame
error."
It runs perfectly fine on XP with the compact framework, however when
the same executable is copied to the device, I get frame error after
frame error.
Any more insite?
-Thanks
On Feb 13, 3:24 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Remember that a string is a set of Unicode characters in Windows CE,
*not* a
set of bytes, which is probably what the other end of your
communication
session is expecting. If sending a set of bytes always works, that's
the
whole problem and you need to take a while to understand the
difference
between a byte and a Char when the operating system is Unicode based.
Paul T.

Hi NG,
I've recently taken on the task of creating some custom software for
a
Treo 750v. The Treo has a working serial port (tested with a
terminal
emulator) and is running Windows Mobile 5.0 with Compact Framework
2.0
installed.
Lets start off with some background first....
For my first attempt, I attempted using the emulator, and the first
issue I encountered was that I could not receive any data on the
serial
port (BytesToRead property was always 0, and yes I bound the
emulator
comport to a real comport in the settings). So, for the heck of it
I
compiled the same code, and ran it as a standalone app on windows
XP.
Everything worked great! So I finished developing the app, running
into
many minor issues, one of which was:
serial.write(chr(data).toString) has a TX parity error 40% of the
time.
Switching to a byte array solved it (don't know why), and I went
along
my merry way.
Anyway, the app is finished, and ready to be installed on the
handheld
device. I installed it, it fired up no problem, then as soon as
communication begins I'm bombarded with frame error after frame
error.
Obviously it has to do with it being run on a handheld, and
unfortunately I don't have another model handheld to test on.
Anyone
have any similar issues?
-Thanks

 

[Tesko905]

The cable is only like 2 ft long, and the environment is quiet as can
be. Also, I've used a Terminal program to connect to the device with
the same 3 wire cable and it worked like a charm. I'm leaning towards
it not being a cabling/interference issue.

-Thanks

57600 without handshaking may cause a problem (and handshaking with 3-wire
might be tough). Can you slow down the transmitter to see if that's the
potential problem? Also, I assume you don't have some crazy-long cable or
noisy environment?

--
Chris Tacke - Embedded MVP
OpenNETCF Consulting
Managed Code in the Embedded Worldwww.opennetcf.com
--

Ok here's an over view of the setup.

There is a "black box" that communicates at 57600 8-N-1. I connect
this box to my PC with a 3 wire RS232 interface. I run my custom app
on the XP based PC and everything is fine. Communication is perfect,
the whole process is mint. Now, when I take the EXACT same executable
and copy it to the handheld device, hook the "black box" up to the
handheld with the same RS232 interface, I get frame error after frame
error as soon as communication starts. Also, neither my app or the
"black box" use hardware handshaking or XON/XOFF.

Some background:

I'm using VS2005
VB.Net
Compact Framework 2.0
Pocket PC SDK

I'm not convinced that this means something (or I wouldn't have said
"Unicode"). What serial port parameters (baud, etc.), are set on the
device
when the framing errors are reported?
Paul T.

In the back of my head I was thinking it was probably something along
those lines, adding additional data or what not. However, that is
irrelevant, as that is not the issue I am having at the moment.
"Anyway, the app is finished, and ready to be installed on the
handheld device. I installed it, it fired up no problem, then as soon
as communication begins I'm bombarded with frame error after frame
error."
It runs perfectly fine on XP with the compact framework, however when
the same executable is copied to the device, I get frame error after
frame error.
Any more insite?
-Thanks
On Feb 13, 3:24 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Remember that a string is a set of Unicode characters in Windows CE,
*not* a
set of bytes, which is probably what the other end of your
communication
session is expecting. If sending a set of bytes always works, that's
the
whole problem and you need to take a while to understand the
difference
between a byte and a Char when the operating system is Unicode based.
Paul T.

Hi NG,
I've recently taken on the task of creating some custom software for
a
Treo 750v. The Treo has a working serial port (tested with a
terminal
emulator) and is running Windows Mobile 5.0 with Compact Framework
2.0
installed.
Lets start off with some background first....
For my first attempt, I attempted using the emulator, and the first
issue I encountered was that I could not receive any data on the
serial
port (BytesToRead property was always 0, and yes I bound the
emulator
comport to a real comport in the settings). So, for the heck of it
I
compiled the same code, and ran it as a standalone app on windows
XP.
Everything worked great! So I finished developing the app, running
into
many minor issues, one of which was:
serial.write(chr(data).toString) has a TX parity error 40% of the
time.
Switching to a byte array solved it (don't know why), and I went
along
my merry way.
Anyway, the app is finished, and ready to be installed on the
handheld
device. I installed it, it fired up no problem, then as soon as
communication begins I'm bombarded with frame error after frame
error.
Obviously it has to do with it being run on a handheld, and
unfortunately I don't have another model handheld to test on.
Anyone
have any similar issues?
-Thanks

 

[Paul G. Tobey [eMVP]]

No tutorials that I can think of, although there used to be a little
Hyperterminal-like sample in the Pocket PC SDK (called TTY, I think). Have
you tried not sending strings to the serial port write method and just
sending bytes?

Paul T.

I'm 100% positive it supports 57600. I've used a Terminal program on
it to connect to other 57600 devices, as well as the "black box".
Communication worked flawlessly. That's why I'm leaning towards
a .NET - Device incompatibility or something along those lines. As
for working with C/C++ to make some simple Win32 API calls, that
sounds like a good place to start. I've never dealt directly with the
Win32 API for serial access, any links to a tutorial or place to
start?

-Thanks

And you're sure that the hardware for serial I/O on your Windows CE
device
*supports* 57600? It's a low enough rate that it would be a bit
surprising
if not, but it might not.

There are two parallel tracks that I'd take if this were my problem:

1. Verify that the hardware will support the indicated communication
parameters and that you have suitable wiring. You may need to contact
the
device manufacturer for this.

2. Make sure that the serial port driver will support what you're trying
to
do. To do this, forget about managed code and write some simple code to
send and receive data in C/C++. Check all return codes from Win32 API
calls
to verify that they are not indicating problems with any of your
parameters.

One or the other of these will no doubt point you to what is causing the
problem.

Paul T.

Ok here's an over view of the setup.

There is a "black box" that communicates at 57600 8-N-1. I connect
this box to my PC with a 3 wire RS232 interface. I run my custom app
on the XP based PC and everything is fine. Communication is perfect,
the whole process is mint. Now, when I take the EXACT same executable
and copy it to the handheld device, hook the "black box" up to the
handheld with the same RS232 interface, I get frame error after frame
error as soon as communication starts. Also, neither my app or the
"black box" use hardware handshaking or XON/XOFF.

Some background:

I'm using VS2005
VB.Net
Compact Framework 2.0
Pocket PC SDK

On Feb 13, 4:01 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
I'm not convinced that this means something (or I wouldn't have said
"Unicode"). What serial port parameters (baud, etc.), are set on the
device
when the framing errors are reported?

Paul T.

In the back of my head I was thinking it was probably something
along
those lines, adding additional data or what not. However, that is
irrelevant, as that is not the issue I am having at the moment.

"Anyway, the app is finished, and ready to be installed on the
handheld device. I installed it, it fired up no problem, then as
soon
as communication begins I'm bombarded with frame error after frame
error."

It runs perfectly fine on XP with the compact framework, however
when
the same executable is copied to the device, I get frame error after
frame error.

Any more insite?

-Thanks

On Feb 13, 3:24 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Remember that a string is a set of Unicode characters in Windows
CE,
*not* a
set of bytes, which is probably what the other end of your
communication
session is expecting. If sending a set of bytes always works,
that's
the
whole problem and you need to take a while to understand the
difference
between a byte and a Char when the operating system is Unicode
based.

Paul T.

Hi NG,

I've recently taken on the task of creating some custom software
for
a
Treo 750v. The Treo has a working serial port (tested with a
terminal
emulator) and is running Windows Mobile 5.0 with Compact
Framework
2.0
installed.

Lets start off with some background first....

For my first attempt, I attempted using the emulator, and the
first
issue I encountered was that I could not receive any data on the
serial
port (BytesToRead property was always 0, and yes I bound the
emulator
comport to a real comport in the settings). So, for the heck of
it
I
compiled the same code, and ran it as a standalone app on windows
XP.
Everything worked great! So I finished developing the app,
running
into
many minor issues, one of which was:

serial.write(chr(data).toString) has a TX parity error 40% of the
time.
Switching to a byte array solved it (don't know why), and I went
along
my merry way.

Anyway, the app is finished, and ready to be installed on the
handheld
device. I installed it, it fired up no problem, then as soon as
communication begins I'm bombarded with frame error after frame
error.
Obviously it has to do with it being run on a handheld, and
unfortunately I don't have another model handheld to test on.
Anyone
have any similar issues?

-Thanks

 

[Dick Grier]

Hi,

Chris has a VERY good point about the speed. Without flow control, any
speed higher than 9600 bps will be problematic (unless the messages are very
short, and with signficant gaps between).

Also, your code itself may or may not present performance issues. Without
"hands-on" most of us will have to do some guessing.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[Dick Grier]

Hi,

I have example code in my book, for both the SerialPort class in VS2005, and
using the Windows API. Personally, I doubt that it will make much
difference if you code in C/C++, if you then use that DLL from managed code.
The constraints are (roughly) equivalent.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[Dick Grier]

One other suggestion (along the lines that Paul suggested). Double-check
the serial speed to make sure that it isn't (for some reason) 56000 bps
instead of 57600 bps. This would account for frequent framing errors. Some
UARTs may be a little less succeptable to framing errors than others with a
speed variance issue.

Usually framing errors are caused by two things: either a serial speed
problem, or a hardware fault. Flow control, which I mentioned in my other
reply, usually -- though not universally, will result in RxOverrun errors
instead of framing errors.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[Guest]

I can't see how managed code would make a difference. You might try the old
SDF 1.4 serial code so you've got everything in your code above the driver.


--
Chris Tacke - Embedded MVP
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--

I'm 100% positive it supports 57600. I've used a Terminal program on
it to connect to other 57600 devices, as well as the "black box".
Communication worked flawlessly. That's why I'm leaning towards
a .NET - Device incompatibility or something along those lines. As
for working with C/C++ to make some simple Win32 API calls, that
sounds like a good place to start. I've never dealt directly with the
Win32 API for serial access, any links to a tutorial or place to
start?

-Thanks

And you're sure that the hardware for serial I/O on your Windows CE
device
*supports* 57600? It's a low enough rate that it would be a bit
surprising
if not, but it might not.

There are two parallel tracks that I'd take if this were my problem:

1. Verify that the hardware will support the indicated communication
parameters and that you have suitable wiring. You may need to contact
the
device manufacturer for this.

2. Make sure that the serial port driver will support what you're trying
to
do. To do this, forget about managed code and write some simple code to
send and receive data in C/C++. Check all return codes from Win32 API
calls
to verify that they are not indicating problems with any of your
parameters.

One or the other of these will no doubt point you to what is causing the
problem.

Paul T.

Ok here's an over view of the setup.

There is a "black box" that communicates at 57600 8-N-1. I connect
this box to my PC with a 3 wire RS232 interface. I run my custom app
on the XP based PC and everything is fine. Communication is perfect,
the whole process is mint. Now, when I take the EXACT same executable
and copy it to the handheld device, hook the "black box" up to the
handheld with the same RS232 interface, I get frame error after frame
error as soon as communication starts. Also, neither my app or the
"black box" use hardware handshaking or XON/XOFF.

Some background:

I'm using VS2005
VB.Net
Compact Framework 2.0
Pocket PC SDK

On Feb 13, 4:01 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
I'm not convinced that this means something (or I wouldn't have said
"Unicode"). What serial port parameters (baud, etc.), are set on the
device
when the framing errors are reported?

Paul T.

In the back of my head I was thinking it was probably something
along
those lines, adding additional data or what not. However, that is
irrelevant, as that is not the issue I am having at the moment.

"Anyway, the app is finished, and ready to be installed on the
handheld device. I installed it, it fired up no problem, then as
soon
as communication begins I'm bombarded with frame error after frame
error."

It runs perfectly fine on XP with the compact framework, however
when
the same executable is copied to the device, I get frame error after
frame error.

Any more insite?

-Thanks

On Feb 13, 3:24 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Remember that a string is a set of Unicode characters in Windows
CE,
*not* a
set of bytes, which is probably what the other end of your
communication
session is expecting. If sending a set of bytes always works,
that's
the
whole problem and you need to take a while to understand the
difference
between a byte and a Char when the operating system is Unicode
based.

Paul T.

Hi NG,

I've recently taken on the task of creating some custom software
for
a
Treo 750v. The Treo has a working serial port (tested with a
terminal
emulator) and is running Windows Mobile 5.0 with Compact
Framework
2.0
installed.

Lets start off with some background first....

For my first attempt, I attempted using the emulator, and the
first
issue I encountered was that I could not receive any data on the
serial
port (BytesToRead property was always 0, and yes I bound the
emulator
comport to a real comport in the settings). So, for the heck of
it
I
compiled the same code, and ran it as a standalone app on windows
XP.
Everything worked great! So I finished developing the app,
running
into
many minor issues, one of which was:

serial.write(chr(data).toString) has a TX parity error 40% of the
time.
Switching to a byte array solved it (don't know why), and I went
along
my merry way.

Anyway, the app is finished, and ready to be installed on the
handheld
device. I installed it, it fired up no problem, then as soon as
communication begins I'm bombarded with frame error after frame
error.
Obviously it has to do with it being run on a handheld, and
unfortunately I don't have another model handheld to test on.
Anyone
have any similar issues?

-Thanks

 

[Tesko905]

Yes, all serial communication utilizes bytes now, as opposed to
strings. I'll look around for that program, and see what I can find.

No tutorials that I can think of, although there used to be a little
Hyperterminal-like sample in the Pocket PC SDK (called TTY, I think). Have
you tried not sending strings to the serial port write method and just
sending bytes?

Paul T.

I'm 100% positive it supports 57600. I've used a Terminal program on
it to connect to other 57600 devices, as well as the "black box".
Communication worked flawlessly. That's why I'm leaning towards
a .NET - Device incompatibility or something along those lines. As
for working with C/C++ to make some simple Win32 API calls, that
sounds like a good place to start. I've never dealt directly with the
Win32 API for serial access, any links to a tutorial or place to
start?

-Thanks

And you're sure that the hardware for serial I/O on your Windows CE
device
*supports* 57600? It's a low enough rate that it would be a bit
surprising
if not, but it might not.
There are two parallel tracks that I'd take if this were my problem:
1. Verify that the hardware will support the indicated communication
parameters and that you have suitable wiring. You may need to contact
the
device manufacturer for this.
2. Make sure that the serial port driver will support what you're trying
to
do. To do this, forget about managed code and write some simple code to
send and receive data in C/C++. Check all return codes from Win32 API
calls
to verify that they are not indicating problems with any of your
parameters.
One or the other of these will no doubt point you to what is causing the
problem.
Paul T.

Ok here's an over view of the setup.
There is a "black box" that communicates at 57600 8-N-1. I connect
this box to my PC with a 3 wire RS232 interface. I run my custom app
on the XP based PC and everything is fine. Communication is perfect,
the whole process is mint. Now, when I take the EXACT same executable
and copy it to the handheld device, hook the "black box" up to the
handheld with the same RS232 interface, I get frame error after frame
error as soon as communication starts. Also, neither my app or the
"black box" use hardware handshaking or XON/XOFF.
Some background:
I'm using VS2005
VB.Net
Compact Framework 2.0
Pocket PC SDK
On Feb 13, 4:01 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
I'm not convinced that this means something (or I wouldn't have said
"Unicode"). What serial port parameters (baud, etc.), are set on the
device
when the framing errors are reported?
Paul T.

In the back of my head I was thinking it was probably something
along
those lines, adding additional data or what not. However, that is
irrelevant, as that is not the issue I am having at the moment.
"Anyway, the app is finished, and ready to be installed on the
handheld device. I installed it, it fired up no problem, then as
soon
as communication begins I'm bombarded with frame error after frame
error."
It runs perfectly fine on XP with the compact framework, however
when
the same executable is copied to the device, I get frame error after
frame error.
Any more insite?
-Thanks
On Feb 13, 3:24 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Remember that a string is a set of Unicode characters in Windows
CE,
*not* a
set of bytes, which is probably what the other end of your
communication
session is expecting. If sending a set of bytes always works,
that's
the
whole problem and you need to take a while to understand the
difference
between a byte and a Char when the operating system is Unicode
based.
Paul T.

Hi NG,
I've recently taken on the task of creating some custom software
for
a
Treo 750v. The Treo has a working serial port (tested with a
terminal
emulator) and is running Windows Mobile 5.0 with Compact
Framework
2.0
installed.
Lets start off with some background first....
For my first attempt, I attempted using the emulator, and the
first
issue I encountered was that I could not receive any data on the
serial
port (BytesToRead property was always 0, and yes I bound the
emulator
comport to a real comport in the settings). So, for the heck of
it
I
compiled the same code, and ran it as a standalone app on windows
XP.
Everything worked great! So I finished developing the app,
running
into
many minor issues, one of which was:
serial.write(chr(data).toString) has a TX parity error 40% of the
time.
Switching to a byte array solved it (don't know why), and I went
along
my merry way.
Anyway, the app is finished, and ready to be installed on the
handheld
device. I installed it, it fired up no problem, then as soon as
communication begins I'm bombarded with frame error after frame
error.
Obviously it has to do with it being run on a handheld, and
unfortunately I don't have another model handheld to test on.
Anyone
have any similar issues?
-Thanks

 

[Tesko905]

Do you believe the speed restriction to be a limitation on the
handheld hardware?

Also, the most amount of data sent/received at one time is 250 bytes.

 

[Dick Grier]

Hi,

Multitasking OS's ALWAYS have speed "issues" with serial data. You never
can guarantee that the Windows serial device driver will handle all of the
data received in time to prevent a UART overflow, even with the 16-byte
receive FIFO that is in the UART hardware. For this reason, flow control is
recommended. Naturally, this "issue" is exacerbated when you are using
hardware that is of limited speed (Windows CE device), and may not be
apparent on a more capable system (desktop hardware).

You have to use real care (careful design and debug) when you implement an
application on a device that uses serial data. This is especially true if
your application does much processing of the receive data. Windows CE
devices have become much more capable in recent years, but both the OS
itself, and the enviroment (.NET Compact Framework) also demand more of the
hardware.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.