When I'm finished yes. I keep having setbacks when I try to run loops on the device that then freeze, then the com port seems blocked. I do wonder about how clever the COMM library is.

 

I've had to reset the device to unfreeze it, and it seems that the default discoverable infra red port plays havoc with serial comms. On cold reset it is set to discoverable mode.

eVB is on the buggy side as well.

I think I can do something with it though.

 

Thinking further how to code this. Presently I've got it working with buttons I click to do the init, then FE, then FF, then FE then FF, then TPS and read the string result. Because I'm clicking buttons there are natural delays which give time for the replies to come in. Otherwise the comm1.input and comm1.output commands don't delays execution until completion. I obviously want to tie all these together and make it automatic. Loops to check easily make it hang. Using timers to throttle it back may result in slow logging.

I think I should use the OnComm event and the RThreshold at 2 to call it each time 2 bytes are received (the echo and the result). I could make this call a service routine that would convert the result character to an ASCII value and apply the scaling to it before converting back to a string to display (having some trouble with that with type mismatches). Then it would send the next request and finish that sub and the triggering OnComm event sub and the cycle would start again. I suppose I could store the request IDs in an array and increment a counter each time to cycle through them. It is much more of a fuss than a simple series of send, receive echo, receive reply, print result statements though! Trying to be fancy and interrupt driven is far more hassle here.

Any suggestions welcome, I'm new at VB and especially eVB. eVC++ looks very complex with loads of files just to do a "hello world".

I'm also looking at NS BASIC CE.

 

Programming for eVB is similar to regular VB, you have to use the on comm event, to at least maintain a buffer and read from that buffer. If you don't, then you will have buffer overrun or some sort of flow control issue which will appear to lock up the port.

 

I think I have some eVB code that worked perfectly with the UTEC through a serial port. If I can find it I'll send it to you.

 

Thanks!

 

Wow, sounds like you're really making progress!

Unfortunately I have always avoided eVB and opted for eVC instead. I have tons of C code for 2002 devices if you need it (including some COM code).

I think handling the OnComm event will definitely be the best way to go. If you want to do a loop, you will need to force the Windows messages to process on every loop to avoid a frozen UI. I forget the command in eVB but in .NET it is Application.DoEvents ( i think) so there is probably an equivalent command.

Hamish, any info you can post on a bluetooth interface? If you have made progress on this then that may be the way to go for new devices.

I still want to get the new mobile devices working without changing the baudrate...bluetooth may be the only way...

 

I've posted a new thread as I have a screenshot of my first logging. I think it should be rewritten in eVC. Fancy a go?

 

The following devices are listed as having Host controllers onboard. They are all Windows CE 5.0

Samsung NEXiO XP40
Gotive H42
Hannuri Biz Nurian Z1

All CE 6.0 devices are supposed to have USB on the go which enables a host controller and will most likely work with a tactrix cable. Anyone with these devices speak up!

 

I think I have found a good stopgap until more onboard host devices are made:

http://www.ratocsystems.com/english/products/CFU1U.html

This will work with the Symbol MC50 or MC70 for sure (nice devices). $139 USD is pricey though...

 

I've looked at several of those, but just gave up and bought an RS232 cable.

d

 

Well, I am really trying to get the tactrix cable to work. The end result would be logging AND flashing capability plus a standard interface to the Evo

 

Well according to Trolltech, QT libraries for Windows mobile won't be ready until 2008. So while we could probably get the actual flashing code working, the interface for editing maps and such would have to wait a while.

d

 

Interface is easy. I just can't get the Tactrix cable detected yet. I could drum up an editor in less than a week.

Besides, I am not a huge fan of QT...

 

Doesn't matter, Colby is.

Although many of us could probably duplicate all the work at this point, he has done a very good job with the various kernels for flashing and rom definitions. Splintering development effort wouldn't help anybody.

So you actually have the USB host functionality working?

d