Vs2005 to PDA to Rs232 interface

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

In a privious reply it was indicated that a device like the Dell Axim X51v
PDA which supports Windows Mobile 5 could be used to deploy and test Netcf2.0
App's written in C# using Vs2005. The device supports a Usb connection to the
Pc.

What we are trying to do is use the Dell x51v as a test bed for programs
that will be used to control analytical instruments and components. Most of
the latter use a Rs232 interface.

Assuming there is a device out there that will take a Usb connection and
allow communication with a Rs232 connection, is it possible to daisy-chain
devices on a Usb. That is, have the PC (with Vs2005) communicate with the
Dell X51v via its Usb and have another Usb going to the hypothetical
Usb/Rs232 box which in turn would communicate with the external instrument?

Any suggestions would be appreciated.

--John Olbert
(e-mail address removed)
 
Yes and no. Yes, you can use USB hub to make several USB host ports out of
one and PC would be able to communicate with Axim and with serial box.

No, USB port on Axim (and most other WM devices) is not host USB ports so no
peripheral devices can be connected to it. In fact Axim is peripheral device
from USB standpoint.



You can, however, purchase CF serial card for Axim if needed, e.g. this one:
http://www.socketcom.com/product/serial.asp?Type=Single



--
Best regards,


Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

*** Want to find answers instantly? Here's how... ***

1. Go to
http://groups-beta.google.com/group/microsoft.public.dotnet.framework.compactframework?hl=en
2. Type your question in the text box near "Search this group" button.
3. Hit "Search this group" button.
4. Read answer(s).
 
I don't quite understand what you're thinking. You're going to test this on
a device that can't actually be used for this in the field? The only way to
connect from USB to serial in your situation would be an adapter that plugs
into the Dell and has an RS-232 on the output side. This would only drive a
single device, of course, as RS-232 is not a bus. Also, the Dell would have
to have a driver for that USB-to-serial device. Further, the scheme
requires that the Dell device have a *host* USB port, not just a slave port,
like that used to connect to a PC for ActiveSync communication. The two
ends of USB are different and operate differently. If the Dell has a host
port, as well as the client port that it must have, that's at least part
workable, but there are so many problems beyond that that I don't see the
overall scheme as sensible.

USB is *not* generally daisy-chainable. You could, in theory, have a couple
of USB hubs, each giving you four ports, say, each and plugged into each
port you could have a USB-to-serial device. I've never tried to do
something like that, but it seems unlikely to work smoothly, but it could,
if you can find a driver for the USB-to-serial piece for the Dell (and if
the Dell has a USB host port), in theory work.

How many external devices are connected *at a time*? If it's one and you're
just moving the screen-based device around to capture the data, use a device
that has a serial port! It's so much simpler that it's not even funny. If
you need to connect to bunches of devices all continuously and the central
device doesn't need to be portable, you should look at some other Windows
CE-based device that will handle that number of serial ports. If you're
interested, we have a unit that can handle at least 16 or 20 RS-232 ports
(they're added in groups of two or four at a time, as modules). It's an
industrial device with no UI, but you could easily use your Dell device as
the UI and use network programming to send the accumulated data from the
RS-232 'aggregator' to the Dell via 802.11 or something. www.edasce.com.

Paul T.
 
Hi,

If you mean to connect to the device using the USB from the PC (with a USB
to serial adapter), and to connect to the PPC using USB with the PPC in a
cradle -- or to connect to the PPC using a wirless or wired network
connection... Then, YES. I have examples on my web site (Remote/Local
Comm).

If you mean some sort of other connection (via the PPC) to the device, then
you would have to use a serial port adapter on the PPC. The best option is
to use an add-on Compact Flash adapter (such as Socket Communications). I
have example of this sort of thing in my book. See below.

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.
 
It sounds like this approach is either not going to work or would not be
easy. Our problem is that the device we are using which is an industrial
grade device (with Internet, Rs232 and Usb connections) is not due to be
upgraded to WinCe5.0 for some time. We wanted to use Vs2005 and Netcf2.0
which is not presently supported on this box which is still at the WinCe4.2
level.

We wanted to get a start on developing for our target devices (they are
instruments that are used by chemists and go from Mass Spectrometers to
simple liquid valves used in Liquid Chromotography). I suspect that we can
still use the Dell PDA to deploy to but to attempt to have a "PC--to PDA--to
Device" link up is asking a bit much of the PDA.

Thanks for the guidance.


--
John Olbert



Paul G. Tobey said:
I don't quite understand what you're thinking. You're going to test this on
a device that can't actually be used for this in the field? The only way to
connect from USB to serial in your situation would be an adapter that plugs
into the Dell and has an RS-232 on the output side. This would only drive a
single device, of course, as RS-232 is not a bus. Also, the Dell would have
to have a driver for that USB-to-serial device. Further, the scheme
requires that the Dell device have a *host* USB port, not just a slave port,
like that used to connect to a PC for ActiveSync communication. The two
ends of USB are different and operate differently. If the Dell has a host
port, as well as the client port that it must have, that's at least part
workable, but there are so many problems beyond that that I don't see the
overall scheme as sensible.

USB is *not* generally daisy-chainable. You could, in theory, have a couple
of USB hubs, each giving you four ports, say, each and plugged into each
port you could have a USB-to-serial device. I've never tried to do
something like that, but it seems unlikely to work smoothly, but it could,
if you can find a driver for the USB-to-serial piece for the Dell (and if
the Dell has a USB host port), in theory work.

How many external devices are connected *at a time*? If it's one and you're
just moving the screen-based device around to capture the data, use a device
that has a serial port! It's so much simpler that it's not even funny. If
you need to connect to bunches of devices all continuously and the central
device doesn't need to be portable, you should look at some other Windows
CE-based device that will handle that number of serial ports. If you're
interested, we have a unit that can handle at least 16 or 20 RS-232 ports
(they're added in groups of two or four at a time, as modules). It's an
industrial device with no UI, but you could easily use your Dell device as
the UI and use network programming to send the accumulated data from the
RS-232 'aggregator' to the Dell via 802.11 or something. www.edasce.com.

Paul T.
Click to expand...
 
So, why do you need .NET CF 2.0? Seems like 1.0 would be fine for most
things and that would allow you to use the real device immediately.

Paul T.

John Olbert said:
It sounds like this approach is either not going to work or would not be
easy. Our problem is that the device we are using which is an industrial
grade device (with Internet, Rs232 and Usb connections) is not due to be
upgraded to WinCe5.0 for some time. We wanted to use Vs2005 and Netcf2.0
which is not presently supported on this box which is still at the
WinCe4.2
level.

We wanted to get a start on developing for our target devices (they are
instruments that are used by chemists and go from Mass Spectrometers to
simple liquid valves used in Liquid Chromotography). I suspect that we can
still use the Dell PDA to deploy to but to attempt to have a "PC--to
PDA--to
Device" link up is asking a bit much of the PDA.

Thanks for the guidance.
Click to expand...
 
DataSet.ReadXml() is fairly slow in Netcf1.0. The articles online indicate a
significant speed improvement with Netcf2.0. Also there is some new
functionality.

Thanks.
 
Yes, true, but how much effort will you be putting into making something
that has no value for the final application work? Of course, .NET CF 2.0
will also be supported on 4.2 devices fairly soon, in the first service
pack. Unless you really, really need something that literally is *not* in
1.0, I see no reason to start out targeting 2.0. If you target 1.0 and then
switch to 2.0 later, you get the faster XML stuff, assuming you need that,
with no cost.

Do you need the new functionality? What part?

Paul T.
 
Hello,

there are several things:

1. officially your Axim has no RS232, but there are cable vendors which
sell RS232 Cables for the Axim, I couldn't test this yet since my
test Axim hasn't arrived yet. :-(

2. there is the mentioned RS232 Card from socket. At least in a HP it
worked fine, so it can work in the Dell as well if it has a CF slot.

3. The Dell has no USB host. For devices with USB host (which can drive
USB pheripherals) look at Acer and Fujitsu-Siemens (only europe for
FSC, but why should only U.S. citizens always have the positive
technical devices?) at least with the FSC Loox N500 I managed to get
a FTDI-Chip based USB->RS232 cable work as they provide drivers for
Windows Mobile and the same device has a RS232 builtin as well, but
this might not be compatible and can't be used while using USB host
since there is no dual cable.

4. The HP rx1950/rx1955 has a RS232 port which works well as well as the
hx2190 which has an additional CF slot as well.

Greetings

Markus
 
The main issue was the speed improvement of the DataSet.ReadXml(). The
present App (which is a migration of a Desktop to Netcf1.0 takes about 60
seconds to load in the device. The majority of that time is spent
de-serializing the various DataSet's from Xml files. We are looking at doing
a custom serialization/de-serialization on a DataSet but we are still
interested in the speedup on going to Netcf2.0.

I realize comparing the Dell x51v to our pcb is apples to oranges but it
would give us a feel for the speed improvementl. Also it would let us deploy
to a piece of hardware that support WinCe5.0. I also believe that Vs2005 does
not have a emulator for WinCe5.0 at this time.

There is also interest in the standalone DataTable (serializable) and the
support for Rs232 in the Netcf2.0.

You mentioned that the Netcf2.0 would be available soon for WinCe4.2. Do you
have any idea of the schedule. For various internal reasons we are have
difficulty getting the resources to upgrade our pcb to the WinCe5.0. I am not
a firmware developer but I assume that upgrading the WinCe4.2 would be
considerably easier then switching to WinCe5.0.

Thanks.
 
So, use that as an XML test just for reading the data set, but use .NET CF
1.0 and code the application for the real target device.

Windows CE 5.0 is not different enough from 4.2 to warrant any sort of
operation like this. The version of IE in there is newer, etc., but the OS
isn't different enough for you to care about from the application layer at
all.

Serial support in 2.0 is basically the same as OpenNETCF 1.4, so...

Your last paragraph lost me, or part of it did. No, I can't quote you a
date when .NET CF 2.0sp1 will be available. Soon, roughly. Are you asking
whether adding .NET CF 2.0 to the 4.2 build you already have should be
easier than making CE 5 run on your device? Yes, probably. I don't have
the service pack in my hands, either, so I can't speak from experience, but,
in that case, you don't have to port the board support package and other
low-level stuff to a new operating sysem, you *presumably* just have to
include a new set of run-time files for .NET CF 2.0sp1...

Paul T.
 
Back
Top