Serial Communication using eVC

[ProgrammingAce]

I been trying to write a PocketPC 2002 program using eVC. I done a lot of programming using C/C++, but havent done much using Visual C or eVC. The program will basically send and receive data via a serial port on my iPAQ. Based on the data it receives, the program might parse the data and save it to a file I create. Right now, I am having problems creating the file on the iPAQ (what path do i use?) and figuring out the control signals/timing issues of the iPAQ's serial port. Normally, I would do this in DOS environment using Turbo C, but I cant do that on the iPAQ. Any help is appreciated.

[lebourhl]

Hi,

regarding the serial port, have a look at the TTY sample that comes along the Pocket PC SDK.

Regards,
Laurent

[srouleau]

Ace,

Programming the serial port on a PocketPC device is very similar to programming it on a desktop computer. Normally you open the port using CreateFile(), you write to it using WriteFile, read from it using ReadFile, and close it using CloseHandle(). You can also use WaitCommEvents() if you don't want to poll the port driver every so often.

It is also possible for you to set various parameters on the port using SetCommState(), and the timeouts using SetCommTimeouts().

As for where you want to put your file on the PocketPC, the only major different between a desktop and the PocketPC is that, on the PocketPC, there's no drive letter; so instead of "c:\" it's just "\" for the root.

Hope this helps,

Stephane Rouleau, eng.
Innobec Technologies Inc.
http://www.innobec.com

[ProgrammingAce]

Thanks for all the hints everyone. I managed to create a program that is capable of reading data from the serial port and then writing the modified data to a file. But since the device I was communicating with though the serial port wasnt a modem (I just added a null adapter to the end of the cable), I didnt mess with the CommTimeouts and such. Will this cause a problem if I am gathering a couple hundred KB of data per second?

While I am on the subject of speed, which is better: using multiple threads or multiple processes? Does anyone know what the pros and cons of each is? Which one is easier to learn and implement?

[srouleau]

Ace,

Couple hundred Kb per second, on a PDA's comm port? Unless it's an XScale (and I haven't tried with one), I don't think so.

On some devices, we had buffer overruns at speeds as low as 9600bps (that's not even 10k/second). If you still need to go this fast (say, at 115200bps) then you definitely need to use the hardware flow control, if your PDA has the proper pins on its comm port. If it doesn't, you'll need to use software flow control.

Regarding multiple processes vs multiple threads, it all depends what you want to do. If the two executing units need to talk to each other and share data, it'll definitely be easier if you use a single process with multiple threads. There's no easy answer for every situation though, it all depends on what you want to do. Processes live in their own virtual space and cannot share data directly; threads can pretty much do anything to each other.

And at this kind of speed you're talking about for a PDA (again, depending on the CPU it has, the fastest I've done this with was a StrongArm 206Mhz), you may not want to do any threads at all and just read the comm port as fast as you can. Just depends on how the OEM implemented their serial port handler. For instance, we had all sorts of problems on Panasonic's Toughbook line for some reason...

Your mileage may vary :)

[ProgrammingAce]

Sorry, I meant at about 100k bps (or as high as I can go on the comm port of a iPAQ H3830 with a StrongARM 206 MHz CPU). I would like to read the comm port as fast as I can but the program operates in four phases as a continuous loop:

phase #1: Read data from comm port.
phase #2: Manipulate data (mostly mathematically)
phase #3: Transmitt manipulated data wirelessly (only one-way)
phase #4: Write manipulated data to a file
(I decided to have the transmit first so the computer recieving the data will get it as soon as possible)

Executing these phases sequentially would result in buffer overrun, so I need to choose one of the two methods. Currently, I am leaning towards the idea of a process execute phases 1 and 2, then creates a thread each for phase 3 and 4. What do you think? And thanks for catching my mistake and responding so quickly.

[srouleau]

Ace,

Phase 1 and 2 should not be a problem.

Phase 3, depends on the iPAQ. It may or may not choke; if it does, all you have to do is bring down the speed of phase 1 until it doesn't.

Where are you planning on writing the data in Phase 4? On the SD card? Be advised that writing on these devices is nowhere as fast as writing on an hard drive. And I've even seen some vertical-market devices actually disable interrupts while disk I/O was taking place (talk about buffer overruns!) I doubt the iPAQ will have the same problem though.

Phase 4 may be your biggest hurdle; writing is also a lot slower than reading on a lot of flash devices (ie: reading is up to 10x faster than writing)

Lastly, what is your setup? A CF sleeve with a wireless card, and a comm cable hooked up at the sync port on the iPAQ?

[ProgrammingAce]

At first I was considering writing to a file located on the hard drive AND the SD card. But after taking the write speed limitation into account, I guess it would be faster to write to a file located on the hard drive and then copy that file onto the SD card after it is done gathering data (hopefully, not manually after the program ends).

The current setup is an iPAQ H3830 with a Compaq Dual PCMCIA sleeve (I wanted the extra expandablility and thought the additional battery was a nice bonus). A Compaq wireless PCMCIA card (forgot the model) is inserted into the sleeve to communicate with a laptop computer using 802.11b. A serial autosynch cable is attached to the comm port of the iPAQ. At the other end of the serial cable is a null adapter that then connects to the RS232 device I am communicating with. Its not the most ideal setup (the integrated wireless iPAQ's were not available when I started this project), but it gets the job done. Now, I am just expanding my program to take advantage of the iPAQ's power and flexability.

[srouleau]

Ace,

When you say writing to the hard drive ... you mean on the laptop?

I would not scrap the SD backup just yet; it may be fast enough. But if you do get buffer overruns, that'd be one place to look for a culprit.

[ProgrammingAce]

A file on both the iPAQ and the laptop. The iPAQ will probably save the data to a file stored in RAM. Meanwhile, the laptop will get the data sent to it and save it into another file on its hard drive. After the data is done being gathered, the file on the iPAQ will be closed and copied onto a SD Card (it doesnt sound like a difficult task to do this within a program).

I figured that having duplicate files would make it easier to ensure that data was being sent accurately and wasn't getting lost (just compare the two files). Plus, someone can view the data on either the iPAQ or the laptop at a later date without having to find which device has the data. Writing to a file saved on the iPAQ has been pretty simple, but I heard that doing the same task within a thread is a big headache.

[srouleau]

Ace,

Not to be picky, but if you're written to a file on a PocketPC before, you've already done it within a thread: the application's main thread.

So doing the same from another thread will not be any harder; just make sure what you write is not being tampered with while you write, and you should be all set.

If I were you, I'd try to write to the SD card right away and bypass the RAM-then-SD step.

[ProgrammingAce]

Not to be picky, but if you're written to a file on a PocketPC before, you've already done it within a thread: the application's main thread.

That's true. :p

So doing the same from another thread will not be any harder; just make sure what you write is not being tampered with while you write, and you should be all set.

That makes sense. I guess they were modifying the data too soon or something like that.

If I were you, I'd try to write to the SD card right away and bypass the RAM-then-SD step.

Well, I don't have a SD card so I'll just save it in RAM for now. I don't even know if the SD card is a requirement yet.

Thanks for all your help!

[jacquelinesiow]

I been trying to write a PocketPC 2002 program using eVC. I done a lot of programming using C/C++, but havent done much using Visual C or eVC. The program will basically send and receive data via a serial port on my iPAQ. Based on the data it receives, the program might parse the data and save it to a file I create. Right now, I am having problems creating the file on the iPAQ (what path do i use?) and figuring out the control signals/timing issues of the iPAQ's serial port. Normally, I would do this in DOS environment using Turbo C, but I cant do that on the iPAQ. Any help is appreciated.


hi

i am a software engineering student and my professor just assigned me a task which is writing a white paper regarding to MFC, it can be any topic..

since i am quite interested in wireless serial communication between pc and pocket pc(PDA) , so i am trying to find out some information about this field.
anyway, it's seems like not easy for me because MFC or WINAPI are quite new for me, i afraid i cannot fininshed it before my semester end which is exactly 2 months left.

i read your question and your project, it's kind of similar, do u mind to give me some suggestion about this topic?

thank you