Printable View
I've got many VB programs written in order to obtain a communication between PC and PIC.
I always used COM port at 19200 bps or USB.dll; How can I send the same kind of commands, almost simple string, using the LAN?
Can I use IP Address just like a COM??
I'll be glad to read some answer...
No,you can't. The COMM port is RS232 and will be driven via a UART on the PIC. ie it's a serial interface.
You will need a PIC that has an Ethernet Interface (eg PIC18F97J60 see here: http://www.microchip.com/stellent/id...param=en027905)
In addition you'll need TCP/IP Software running on the PIC as well as re-writing your PC code to use something like Winsock instead of MSComm (or its equivalent)
Hi Doogle,
I'm sorry but I don't agree with you!
I know there are some system that can send String message on COM and LAN network.
My goal is to maintain the same protocol and switch on LAN network.
For sure, I have to change my hardware, I have to use LAN I/O instead MAX232 on PIC side, but what I have to change in my VB routines?
You can keep the same Application Protocol, but if your VB routine is using a serial interface you'll have to change it to use an Ethernet interface (eg Winsock). ie to match the hardware interface of the PIC which will be Ethernet. You can't connect an Enthernet interface to a Serial Port. The wiring and voltage levels are different to start with.
Oh yes, I know all about the HW, but I was talking about the SW.
From the PIC side I have to use a module with LAN interface and own MAC-addres instead the MAX 232; but how can I connect with the MAC-add(IP) from a PC side?
What I have to use inside my VB routine? I guess not the MSCOMM. controls and events.....
Are there some dll to use? Just like un USB devices!?!?!?!?
I also believe, the match between MAC-Add and IP-Add should be executed from PC side!
I hope I have been enough clear in my explanation!!!
bytheway, thanks a lot for the attention!
Ciao
One normally doesn't worry much about MAC addresses or Ethernet. You can use IP over a lot of transport media and link level protocols, but I guess Ethernet is so ubiquitous the others aren't worth talking about. You can even use IP over a serial or parallel port.
If you plan to use IP those become issues for the lower layers of software to worry about though. If you mention MAC addresses you're probably talking about Ethernet.
Your device will need an IP address assignment of course. The usual ways are to either hard-code an available fixed IP address for the subnet or use DHCP. While it is possible for a Windows PC to act as a DHCP server for local devices, more often people rely on some network appliance for that. In small networks this would usually be a function delegated to the router you use as an Internet gateway.
A DCHP client has to be smart enough to use the DHCP protocol to broadcast a request for Internet settings and process the response(s). If you can't/don't use DHCP you have to set these yourself, generally the IP address, subnet mask, and default gateway are the minimum settings. The DHCP server maintains a list of active interfaces, active media addresses (for Ethernet those are MACs) and leased IP addresses. These leases can expire, so the mapping is not guaranteed to be permanent.
In a routerless network (crossover cable between two boxes?) something like ARP is used to find the media address to use for a given IP address, and in small networks same-segment addresses are often ARPed even if there is a router.
Your software doesn't normally worry about that: the TCP/IP protocol stack handles these details. However on a tiny device you might have to, it depends on what the device has in ROM or in the load-image you're running on the device.
MSComm is for COMx: ports, so forget that. Typically one would use the Winsock control instead for TCP or UDP communication. The object model is somewhat different but the operation is essentially similar to MSComm.
The beauty of this is that while it is actually quite complex most people can cargo-cult their way to a working application with little or no knowledge of the details.
Yeah Dilettante,
you get in your sight what I'm looking for!
From pic side, there is no problem, I'm a FW developer, so I can implement all the needed functions and saving configuration in the embedded system, in order to maintain stable the private network, but from the pc side I have not idea how can I swap from a Comm controls to an "Ethernet" control, expecially in VB.
Inside this network of HW devices, the pc is used to collect data.
Some years ago I meet a guy that wrote something really similar in 'C' (for an Industrial-RFID application), but unfortunately now I've lost contact with him.
I also believe the same enviroment could be written in VB!!!!
So, does someone could share some source code!!???
I know, maybe is not easy... for many reasons, but it will be really appreciate.
I understand only in this moment what you mean about Cargo-cult, and.... I can tell you only that you are completely wrong, but I appreciate the honest tought!
How I wrote in other rows, I'm a FW and SW developer, during the years I developed and installed many systems and devices inside my house, they works in RF 433[MHz], any Devices got own Address, a master RF device is connect to a PC using the COM interface, and it collects data!
So, my only tought was to migrate from an RF system communication (developed by my own) to a standard communication trought WiFi system RF.
Take a look at the Winsock control I suggested above.
You'll find it works very much like MSComm does, aside from the fact that its object model is somewhat different.
Probably the first difference you'll run into is that you must decide whether the PC or the device will be the "server." This means one end must start by "listening" for a connection request from the other end (client). Your best bet would probably be to have the PC be the listener/server.
One thing that will indicate you are going to have a tough time doing this is if you have been using DoEvents loops with MSComm instead of the OnComm event.
I will overstate this to make a point: programming this way is wrong.
To say it more moderately: neither MSComm nor Winsock are meant to be used with DoEvents calls.
After all, do you program a tight loop calling DoEvents and checking the current state of a Command Button control to wait for it to be clicked? No.
Visual Basic is not designed to be used for "straight line" programming. The use of DoEvents is almost always because somebody is trying to make it work that way. This isn't a VB issue, it's a Windows programming issue and is common to GUI window managers on many OSs, not just Windows.
If you aren't using MSComm with DoEvents now, you'll probably find that the tons and tons of Winsock examples you can find here and widely on the Web will be pretty easy to understand. Your experience with MSComm should be helpful to you.
People often stumble over the fact that using TCP the Winsock control's DataArrival event means only some data has arrived. There is no automatic preservation of message boundaries, and each DataArrival might only mean one byte has been received, or it might mean 3 1/2 messages have been received. It is up to you to define what a "message" is and to extract whole messages from the stream of received data to process them.
Receiving via MSComm is very similar.