VB6 Serial Communication
Cullen
Posts: 3
Greetings--
I've seen a lot of information regarding Prop to PC serial communication, but I can't seem to find clear answers on what I'm looking for.
I need the Propeller to communicate back and forth with a VB6 app on my PC at runtime. VB will be doing most of the work--the Prop will only be handing input switches, a couple of radio TX/RX here and there, perhaps a GPS signal, outputting to relays, etc. - nothing the Prop can't handle with eight cogs (call it seven if one's tied up with VB). The Prop's code (in Spin) will be pretty simple--it's basically acting as a driver between the PC and the hardware that it needs to interact with. (I haven't written it yet so I have nothing to post.)
How do I wire up the Prop to communicate with the PC this way? I know that I can load programs with the Propstick, but can I communicate with my PC while the Prop is running that way? I'm hoping it's as simple as that. If that's the case, does anyone know how to get VB to communicate with the outside world via USB?
From what I've seen on a few forums, I don't think that VB can use the USB port--it has to use a serial port (or through a USB to serial adapter if the actual serial port isn't on the PC). This (again, I'm theorizing here) is a limitation of VB.
So, if I can't use the Propstick, how do I wire a serial port to the Propeller? Do I need to use a MAX3232? Should I use P31 and P30, or does it matter? If I do use those pins, will it impact the USB serial communication for loading programs?
I found this diagram online but wasn't sure if it fit the my particular application:
http://forums.parallax.com/forums/attach.aspx?a=23135
This is my first post and I'm new to microcontrollers--please let me know if I've left out any important pieces of information.
Thanks!
I've seen a lot of information regarding Prop to PC serial communication, but I can't seem to find clear answers on what I'm looking for.
I need the Propeller to communicate back and forth with a VB6 app on my PC at runtime. VB will be doing most of the work--the Prop will only be handing input switches, a couple of radio TX/RX here and there, perhaps a GPS signal, outputting to relays, etc. - nothing the Prop can't handle with eight cogs (call it seven if one's tied up with VB). The Prop's code (in Spin) will be pretty simple--it's basically acting as a driver between the PC and the hardware that it needs to interact with. (I haven't written it yet so I have nothing to post.)
How do I wire up the Prop to communicate with the PC this way? I know that I can load programs with the Propstick, but can I communicate with my PC while the Prop is running that way? I'm hoping it's as simple as that. If that's the case, does anyone know how to get VB to communicate with the outside world via USB?
From what I've seen on a few forums, I don't think that VB can use the USB port--it has to use a serial port (or through a USB to serial adapter if the actual serial port isn't on the PC). This (again, I'm theorizing here) is a limitation of VB.
So, if I can't use the Propstick, how do I wire a serial port to the Propeller? Do I need to use a MAX3232? Should I use P31 and P30, or does it matter? If I do use those pins, will it impact the USB serial communication for loading programs?
I found this diagram online but wasn't sure if it fit the my particular application:
http://forums.parallax.com/forums/attach.aspx?a=23135
This is my first post and I'm new to microcontrollers--please let me know if I've left out any important pieces of information.
Thanks!
Comments
I am in a hurry so I'll be brief. More to come later on.
1. I use VB6 on a notebook in the lab to monitor stuff through either serial port or USB. Target device is a propeller (of course!).
2. To use the USB, FTDI supplies a driver, free of charge, that converts the USB port into a virtual serial port, so the USB is seen as a regular serial device.
3. In VB6, you need to use MSComm object. Setup is critical if you want to make it working properly with the virtual port. I use the object configured as follow:
DTREnable = false <=== critical! It prevents the propeller from rebooting when port is closed
EOFEnable = False
Handshaking = 0 - None
InBufferSize = 1024
InputLen = 0
InputMode = 0 - comInputModeText
NullDiscard = False
OutBufferSize = 512
RThreshold = 0
RTSEnable = False
Settings = 115200,n,8,1 <=== lower rate are ok
SThreshold = 0
4. depending on how you want to use object, you may have to poll the device, or just wait until some data come your way.
I really have to go but if you point me toward what you really want to achieve, I may be able to help you with some working VB6 code.
Cheers,
Alex
Post Edited (4Alex) : 8/26/2009 12:16:48 PM GMT
I read again your posting. As far as I know, VB6 is not limited in communicating with a propeller, either serial or usb, and works real sweet.
If you want to use a serial port, in DB9 configuration, you need 3 wires:
DB9-pin2(tx/rx), DB9-pin3(rx/tx), and DB9-pin5(gnd). I ignore all the other pins as I don't bother with handshaking. I always use a max232-type of IC, mainly to protect my PC, but I've seen plenty of direct connect through resistors in this forum. If I were you, I'd stick with the max232-type with serial.
If you are using USB, simply follow the schematics provided by Parallax for the Propeller Plug (or something callled like that). You will need 4 pins: +3v3, Dat+, Dat-, and Gnd. You will need to install the FTDI virtual port driver. It works nice, at least under XP. Our labs are not cleared to use something else at this point (we also use Win2000 but driving the ports are a real pain). I have heard of serial port comms problems with Vista but I don't have any hand-on expertise on that. We hated WinMe, so please don't ask.
I am still in transit but I'd be more than happy to be of assistance in your project. So many people helped me on this forum, I'd be glad to return the favour whenever I can. Just ask.
Cheers,
Alex
Post Edited (4Alex) : 8/25/2009 11:24:26 PM GMT
Sorry if this comes in bits and pieces.
On the propeller side, you will need a serialComm spin file. My personal favourite is SerialMirror because I find it very simple to use and extremely versatile when interfacing multiple serial devices comes to play.
The way you decide to interact between the propeller and the pc is critical. I some applications, I need a cog solely devoted to monitor the polling requests.
Cheers,
Alex
I use VB6 Pro SP6 (32bits) and MSComm comes standard with it.
Cheers,
Alex
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 8/27/2009 3:26:03 AM GMTThanks again for the quick responses. These forums are incredibly helpful.
does it still work under XP....I had a hell of a time to get VB6 code that did API stuff to still work under XP
once I ported over to it....does yours work under XP....if yes then PLEASE do post it....
Thanks
@Cullen
Have a look at this document I made for communicating a PC with the propeller. I did it for
RobotBASIC which provides a VERY EASY way for you to do Serial comms.....but the
METHODOLOGY and the DETAILS of the way to do it is all there and is still applicable to
VB6 once you figure out how to do serial comms with VB6.
There are a few options mentioned in the document that should put you on the right
path.....all the stuff·aught to·be just as applicable to VB6 as it is for RobotBASIC.
http://www.robotbasic.org/resources/RobotBASIC_To_PropellerChip_Comms.pdf
Regards
Sam
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
I am using the latest .NET 3.5 and C# and to be perfectly honest the serial communication object is easy to use and very powerfull.· you can handle both synchronous and asyncronous serial communication you can even use a worker thread and a communication pipe between your GUI and the background worker thread responsible to handle the serial link(s) in real time.· On the prop side my favorite thing is using XBee or even the Bluetooth module from Parallax.· I was very successfull with both of them.· As far as I know VB6 is an obsolete techno and I do not advise anyone to continue to use it.· This url: http://www.learnvisualstudio.net/Members/Default.aspx·is a good way to learn the latest .Net techno, I am using their videos when I need to understand or learn something new.
have a good day.
jm.
·
To answer your question: no, you don't need the MAX3232 in your design if you use the usb implementation, either via the Plug/Clip or a dedicated FTDI IC will work without anything else but the virtual port driver.
So serial is out. Good. It's even simpler. Wiring diagram of Plug described on Parallax web site and Sam document works well. It's the one I use.
As for the software, yes, this is where the fun begins. You will have to decide how you want your design to work. Is it going to be a challenge-response scheme between your pc and the propeller (i.e., a command is sent by the pc, the propeller analyse it, and then reply to the pc), a passive slave scheme (i.e. either side are simply waiting for data whenever they come), or a more involving scheme. If you intend to control the propeller, query status of sensors, and trigger switches, you are better with a challenge-response scheme. If its a passive sensor that simply issues periodic data (like a gps), then a passive data collection scheme is all you need. From your initial posting, I would go with a challenge-response approach.
In that case, you need to first establish some sort of messenging protocol. If you want to take the fixed length method (i.e., the message is always the same length, the simplest of all), then you need to design the payload. Normally you should start with a header byte ("#", for example), then a command byte ("T"), then possibly a function of some sort ("R"), then some bytes for an eventual data set/reply ("0000"), and finally a tail byte (usually a checksum/CRC to ensure your message is valid). In this example, your fixed 8 bytes payload would look like this #TR0000@, meaning Read (R) Thermometer (T). The propeller could reply #TR0125*, meaning Thermometer Reading 12.5deg (you normally avoid decimal point in a reply if a fixed format is expected, in this case a division by 10). I normally reply with the Command+Function because the pc might issue several messages in a row and lenghty processing timing might not return the results in the initial arrival order. This way the pc knows what received data answers which request. If you follow this approach, then it is fairly simple to program both the VB6 and propeller to interact properly. Of course you can design your payload anyway you like. I put a data reply of 4bytes (1 long) because it covers a very large figure that you can still process easily in VB6 and propeller. The fixed lenght is simple to process because you know when a message starts (the header) and how many byte to expect. The location of each byte also convey the meaning of it al (i.e., second byte is the command). Variable lenght payload could be more efficient for wildly different payloads but they are more involving to process (you would need to code at a fixed location how many bytes are expected to be read).
Let me know if you need more assistance and which approach you are taking.
@Sam: I found XP to be very stable when VB6 is calling APIs. I use mainly graphical, memory, & internet-related APIs, though. BTW, I've followed some of your previous posts and I take this opportunity to thank you as they were useful to me. Your RobotBasic document is well written. Kudos.
@dMajo: I also have an interface with an old Perkin-Elmer spectrometer in the lab: works great using MSComm VB6 Pro, but my circuit still uses a PIC16F, not a propeller.
@LocalRoger: I agree with you that run time only DLL are a pest to deal with. I've never seen a single one coming from Microsoft, though. The only one I had to deal with were commercial (and expensive) DLL/OCX, mainly for graphical use. I also had my share of swearing at an HP DLL... As for the deployment of a program using MSComm, the installation cab generated by the Package & Deployment Wizard never failed me anywhere.
Cheers,
Alex
Post Edited (4Alex) : 8/27/2009 12:51:37 PM GMT
Personally, I like VB6.·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Alex
It's well commented and should be self-explanatory.· I use the normal VB timer to poll the port when necessary; Windows does a good job of buffering and this is almost always fast enough.· It is generally OK to transmit as much data as you want whenever you want as long as txportbusy() is false.· If txportbusy() is true you must wait until it is false signifying that the ongoing transmission is finished.· If you have a process outputting a bunch of data at random times, you can build a timer event that tacks outgoing messages onto a buffer string and blows the buffer out when it's safe.
You can call the receive function whenever you want.
I have a couple more versions of this with the names of functions changed for doing multiple ports.· To do the equivalent of a control array you need to create a class, which I've done but the way I did it isn't according to Hoyle and is messy as hell though it works.· (You can't use arrays of the control vars because in VB·dynamic arrays move around in memory, which screws up the pointers.)
The link I gave above to the PDF was to an older version of the PDF....oops
Please download this newer version and disregard the older one.
http://www.robotbasic.org/resources/RobotBASIC_To_PropellerChip_Comms.pdf
it will look very similar but there are few errors in the old version.
@LocalRoger
·· Thanks
@4Alex
Thanks for the support.....
Also you must work for GEICO.....
Sam
real nice to use.
and yu can pick up vb6 pro on ebay legitaimately usually for a bargain [noparse]:)[/noparse]
cheers,
chris
If you want high speed communications, it is more tricky. FTDI ftd2xx drivers are the way to go.
I have my own packet based asynch library that I'm thinking of releasing as a product. I can do 2mbps sustained transmit/receive using two cogs.
Thanks again to everyone for the responses!