Eng-Tips is the largest engineering community on the Internet
Intelligent Work Forums for Engineering Professionals
-
Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How to make USB devices with PIC
- Thread starter syset
- Start date
I recently bought a new laptop and found the same problem - no RS232 port. It's all been taken over by USB and firewire. On checking with our A-B distributor, i was told that the USB will not drive the PIC because there is no power out of the USB port for the PIC box. I have since seen products advertised which ARE drive by power from the USB port, which just adds to the confusion. Perhaps there's just 'not enough' power.
Anyway, the answer seems clear enough - find the power to drive the box. I've been meaning to check the pinouts on the PIC connector and jury-rig power from another supply - perhaps from the printer port...
Anyway, the answer seems clear enough - find the power to drive the box. I've been meaning to check the pinouts on the PIC connector and jury-rig power from another supply - perhaps from the printer port...
SteveMeisel
Automotive
Check out this Rockwell Knowledgebase Document -
Do you have any PCMCIA slots? If so, the 1784-PCMK/B card (with the appropriate cables) is another solution for DH+ and DH485 communication to various SLC models.
Steve
Do you have any PCMCIA slots? If so, the 1784-PCMK/B card (with the appropriate cables) is another solution for DH+ and DH485 communication to various SLC models.
Steve
Steve;
Thanx for the web site address. I already know that the USB will work with the RS232 DF1 protocol - as long as you don't try to 'auto-configure' (in my case anyway). My new laptop doesn't have PCMCIA slots either. I would probably balk at the price of the 1784-PCMK card anyway. In the meantime, my old laptop is relegated to A-B PIC communications...
Jeff
Thanx for the web site address. I already know that the USB will work with the RS232 DF1 protocol - as long as you don't try to 'auto-configure' (in my case anyway). My new laptop doesn't have PCMCIA slots either. I would probably balk at the price of the 1784-PCMK card anyway. In the meantime, my old laptop is relegated to A-B PIC communications...
Jeff
I'm perhaps plagerizing this, I was sent this as an explanation of the PIC's problems with USB. I hope it helps.
"unofficial" PIC fact (v1.0)
The PIC was designed in the early 90's. Since memory was expensive, it was given a very small communications buffer. To account for this, the software "Drivers" that communicate to it uses a very fast heartbeat to make sure the PIC is receiving data. Since the OS was DOS, there were really no compatibility issues. In DOS, only one software package ran a time, and software could directly control hardware without first going though a large OS layer.
With wide acceptance of Windows 3.1, it was soon realize than Windows was designed to service the comm. port at a considerably slower rate than what was capable in DOS and what was needed by the PIC. To get around this, ICOM took the approach of rewriting the windows "comm.drv" and named it "icomcomm.drv".
When Windows 95 came out, the comm. port driver again had to be rewritten. We also began to run into two new issues: other programs polling the comm. port, and programs taking control of the comm. port. An example of the first is when Window's power saving feature monitors the serial port for activity. Examples of the second are when you've used a serial mouse on the same port (requiring it be deleted from device manager) or if have your Palm Pilot software running and set to use the same comm. port.
With Windows NT, a whole new issue developed around the HAL. Any Windows and DOS programs that controlled hardware directly just don't work in NT. To work, they had to be rewritten for NT's Hardware Abstraction Layer (HAL.) Since the HAL loaded on boot, even with new driver the only time the RSLinx PIC driver could be switched in and out is when the machine boots. Hence, you also couldn't stop and start (add and remove) the driver dynamically like you could do an in Windows 95 / 98.
As you can imagine, with Windows 2000 being an updated NT, a new version of the HAL requiring the driver be updated again.
And finally with XP, while not yet officially supported, it still is very close to Windows 2000. I've personally been able to use the PIC driver on XP with out any problems. The only issue has been the need to delete the driver both from RSLinx and the Device Manager when you’re finished using it.
With all this said, the bottom line is that the PIC was developed for DOS. Rockwell has eventually found a way to support it in every new windows OS over the last twelve years, but you can’t expect them to continue rewriting the drivers indefinitely. In the future our choices will become limited to having an old PC or dual boot system, or to using the new USB to 485 converter (due late 2002.)
"unofficial" PIC fact (v1.0)
The PIC was designed in the early 90's. Since memory was expensive, it was given a very small communications buffer. To account for this, the software "Drivers" that communicate to it uses a very fast heartbeat to make sure the PIC is receiving data. Since the OS was DOS, there were really no compatibility issues. In DOS, only one software package ran a time, and software could directly control hardware without first going though a large OS layer.
With wide acceptance of Windows 3.1, it was soon realize than Windows was designed to service the comm. port at a considerably slower rate than what was capable in DOS and what was needed by the PIC. To get around this, ICOM took the approach of rewriting the windows "comm.drv" and named it "icomcomm.drv".
When Windows 95 came out, the comm. port driver again had to be rewritten. We also began to run into two new issues: other programs polling the comm. port, and programs taking control of the comm. port. An example of the first is when Window's power saving feature monitors the serial port for activity. Examples of the second are when you've used a serial mouse on the same port (requiring it be deleted from device manager) or if have your Palm Pilot software running and set to use the same comm. port.
With Windows NT, a whole new issue developed around the HAL. Any Windows and DOS programs that controlled hardware directly just don't work in NT. To work, they had to be rewritten for NT's Hardware Abstraction Layer (HAL.) Since the HAL loaded on boot, even with new driver the only time the RSLinx PIC driver could be switched in and out is when the machine boots. Hence, you also couldn't stop and start (add and remove) the driver dynamically like you could do an in Windows 95 / 98.
As you can imagine, with Windows 2000 being an updated NT, a new version of the HAL requiring the driver be updated again.
And finally with XP, while not yet officially supported, it still is very close to Windows 2000. I've personally been able to use the PIC driver on XP with out any problems. The only issue has been the need to delete the driver both from RSLinx and the Device Manager when you’re finished using it.
With all this said, the bottom line is that the PIC was developed for DOS. Rockwell has eventually found a way to support it in every new windows OS over the last twelve years, but you can’t expect them to continue rewriting the drivers indefinitely. In the future our choices will become limited to having an old PC or dual boot system, or to using the new USB to 485 converter (due late 2002.)
USB can provide +5V. Check the following page for the pinout
Check this site for more information on USB
Check this site for more information on USB
- Status
Similar threads
- Locked
- Question
- Locked
- Question