In the days of parallel printers one used to be able to send a command on LPT1 and receive back standard info such as life count etc.
Now, with USB devices, have we lost that capability? Or is there still a way to read the info?
I assume your question is Windows centric. On some devices the manufacturer (like Epson and Star for example) provide utilities that let you access the device as a 'legacy serial' interface. It's still USB but the software gives you a virtual serial port you can talk to it with. I've been doing some digging trying to figure out what features are exposed by the low level drivers, but haven't had much luck there as Windows drivers really aren't my forte.
In the windows printers you get to select from a variety of ports. For parallel and serial you can open them as \.\LPT1 or \.\COM1 etc and get bi-directional behaviour that way. But for USB the ports are often USB001, and trying to open \.\USB001 for example doesn't seem to work. Such an approach might work, if you can figure out exactly what name to open. But that name will probably have a big ugly GUID in it if the information you see in winobj is anything to go by...
If you come up with any better answers please let me know!
Related
I recently acquired a Microchip EVB USB7252. I can use it as a USB hub. There are some pins on the board, and I have been looking for ways to use these as an interface between my computer and other devices (preferably my LCD screen).
So I got the IDE + compiler that is supposed to work for this product (MPLAB), but I could find no way to choose my model and get the correct target board.
I was hoping anybody (with likely more experience than me) could steer me in the right direction here. My only previous experience with dev boards is Arduino, where boards show up automatically as COM ports in the IDE. My ultimate goal here is to connect my peripherals to USB without using virtual COM-ports.
https://www.microchip.com/en-us/development-tool/EV33X03A
You can Try The IDE call "MPLAB" you said
and i think arduino CANT use "Microchip EVB USB7252"
So Try it And Good luck
It's a long way because USB is not easy protocol. You need to read USB specs first. Take a look at http://www.usb.org. Generally USB communicate between host and devices. There is special protocol used in this communication.
Perhaps the easiest way to do this will be using Linux and libusb or similar library. When you achieve some experience with this protocol you may be trying to write your own USB driver. I could also recommend to analyse some USB stacks like in Linux or in U-Boot one first.
If you have possibility then I'd also try to use some hardware/software USB protocol analyzers for some overview how does the communication look like.
I am a very novice embedded developer and I am trying to develop a commercial product using Windows Embedded Compact and a Toradex Apalis T30 COM. Firstly just excuse me here, I am not a professional nor a trained engineer, merely a hobbyist trying to push the boundaries so forgive me if this is supposed to be trivial. I should also state that because of this I have no low level USB experience. I would like to use WEC 2013 but Toradex does not quite have it ready yet so for I guess at least another month I am stuck on WEC 7 if that makes any difference.
My problem is that I cannot seem to figure how one goes implementing USB Client functionality in WEC. As in, I want my device to be able to connect to my PC as a USB client with the PC being the host. Now by default it connects with the Active Sync (now Device Center or something) application and that allows serial communication of sorts if I am not mistaken but I really don't want to make my device dependent on ActiveSync as that will leave a very bad impression on customers as it doesn't look very professional and bears to much of an association with yesteryear's Windows Mobile.
My device is a 3D printer and I am assuming that there is no native USB class for 3D printers. All 3D printers I know of merely use a USB COM port to communicate and I guess that that should be fine for me two. Now what I want to know is how I can make my device appear as a plug and play USB COM port (able to support all the major desktop operating systems)? I know I can use an FTDI chip to do this with a UART port on my device but I am thinking that that is a bit of a waste given the fact that my COM has a built-in USB client port.
One would think that WEC would have built-in support for something like this but I cannot find any documentation regarding how to use it if it does indeed exist. The best I can find is http://msdn.microsoft.com/en-us/library/ee481935.aspx but the page does not really say anything useful.
PS. I cannot really afford to buy a USB vendor-id so I am hoping there is a solution to this that does not require one.
For windows embedded, you have to manually write a driver or a set of registry entries with the right Device Class ID, Vendor ID and Product ID. Once that is done, you need to integrate it in Windows Embedded and rebuild the solution.
I am a physicist, and I had a revelation a few weeks ago about how I might be able to use my personal computer to get much finer control over laboratory experiments than is typically the case. Before I ran off to try this out though, I wanted to check the feasibility with people who have more expertise than myself in such matters.
The idea is to use the i/o ports---VGA, ethernet, speaker jacks, etc.---on the computer to talk directly to the sensors and actuators in the experimental setup. E.g. cut open one side of an ethernet cable (with the other end attached to the computer) and send each line to a different device. I knew a postdoc who did something very similar using a BeagleBone. He wrote some assembly code that let him sync everything with the internal clock and used the GPIO pins to effectively give him a hybrid signal generator/scope that was completely programmable. It seems like the same thing should be possible with a laptop, and this would have the additional benefit that you can do data analysis from the same device.
The main potential difficulty that I foresee is that the hardware on a BeagleBone is designed with this sort of i/o in mind, whereas I expect the hardware on a laptop will probably be harder to control directly. I know for example (from some preliminary investigation, http://ask.metafilter.com/125812/Simple-USB-control-how-to-blink-an-LED-via-code) that USB ports will be difficult to access this way, and VGA is (according to VGA 15 pin port data read and write using Matlab) impossible. I haven't found anything about using other ports like ethernet or speaker jacks, though.
So the main question is: will this idea be feasible (without investing many months for each new variation of the hardware), and if so what type of i/o (ethernet, speaker jacks, etc.) is likely to be the best bet?
Auxiliary questions are:
Where can I find material to learn how I might go about executing this plan? I'm not even sure what keywords to plug in on Google.
Will the ease with which I can do this depend strongly on operating system or hardware brand?
The only cable I can think of for a pc that can get close to this would be a parallel printer cable which is pretty much gone away. It's a 25 wire cable that data is spread across so that it can send more data at the same time. I'm just not sure if you can target a specific line or if it's more of a left to right fill as data is sent.
To use one on a laptop today would definitely be difficult. You won't find any laptops with parallel ports. There are usb to parallel cables and serial to parallel cables but I would guess that the only control you would have it to the usb or serial interface and not the parallel.
As for Ethernet, you have 4 twisted pair with only 2 pair in use and 2 pair that are extra.
There's some hardware that available called Zwave that you might want to look into. Zwave will allow you to build a network of devices that communicate in a mesh. I'm not sure what kind of response time you need.
I actually just thought of something that might be a good solution. Check out security equipment. There's a lot of equipment available for pc's that monitor doors, windows, sensors, etc. That industry might what your looking for.
I think the easiest way would be to use the USB port as a Human Interface Device (HID) and using a custom built PIC program and a PIC that includes the USB functionality to encode the data to be sent to the computer and in that way be able to program it independently from the OS due to the fact that all mayor OS have the HID USB functionality.
Anyways if you used your MIC/VGA/HDMI whatever other port you still need a device to encode the data or transmit it, and another program inside the computer to decode that data being sent.
And remember that different hardware has different software (drivers) that might decode the raw data in other odd ways rendering your IO hardware dependent.
Hope this helps, but thats why the USB was invented in the first place to make it hardware and os independent.
I've been looking for a detailed description for how USB protocol and cabling works for a long time with no luck. I am looking for a detailed yet not overcomplicated explanation of how things work on the software and hardware side of USB. Links and explanations would be appreciated. I've really run out of ideas, so it would be great if you can help me out.
This is what I do know:
USB hardware carries 4 lines- 5V power, ground, and 2 full duplex lines.
When connecting, the device can ask for a specified amount of current.
The transfer speeds for USB are quite fast compared to traditional serial connections.
When connecting, a device will output descriptors to the host describing itself. These descriptors will also be used for data.
What I don't know:
How does a program in C/C++ write directly to a USB port? Does it write to an address in the port?
How do some devices describe themselves as HID?
How do drivers work?
Everything else...
Thank you!
Identification
Every device has a (unique) Vendor and Product ID. These are provided (sold) by usb.org to identify a device. You can use a library like libusbx to enumerate all connected devices and select the one with the Vendor and Product ID you are looking for.
HID Descriptors
The point of HID descriptors is actually to do away with drivers. HID descriptors are a universal way of describing your device so you don't need to waste time on a driver for every system/architecture/etc/. (Same concept as the JVM.)
Reports
You will use either the input, output, or feature reports to read or write to your device. You send a stream to your device on the input or feature report. This is typically 8 bytes I believe. Only one of which is a single character you wish to write. The HID descriptor contains all the information you need to put together a report. Although I'm struggling to find a related link to clarify this.
Potential Libraries
In an effort to be open-minded here are all the libraries I am familiar with and some info about them.
libusb-0.1
First off is libusb-0.1. This used to be the go to and was built in to many Linux kernels and Windows I believe. It is very easy to use and there is a lot of documentation. However, the owner never updated and it wasn't edited for many years. It supports only synchronous transfers. (If an error occurs, the program can wait infinitely while it expects a transfer.)
libusbx
Next is libusbx. This is what most people would suggest today and I agree. It was published by those frustrated by the owner of libusb-0.1. The code is much more lightweight, up-to-date, and importantly does not require root privileges like libusb-0.1 and libusb-1.0 (Discussed in a second). It supports synchronous or asynchronous transfers.
libusb-1.0
Then there is libusb-1.0. This was the first update to libusb-0.1 in some number of years. It is not compatible with libusb-0.1. This was published the same day as libusbx as a retaliation (I assume) and an attempt to rectify the lack of updated content and conserve a user-base. It supports synchronous or asynchronous transfers.
hid.h
Finally, there is the hid library. This was built on top of libusb as another layer of abstraction. But honestly, I think it's just really confusing and it just adds more overhead than necessary.
Some Good Resources
Understanding HID Descriptors
Control Message Transfer Documentation (Very Good Link IMO)
Rolling Your Own HID Descriptor
Good Visual of HID Reports for Transfers
Great List of bmRequestType constants (You will need this or similar)
A simple terminal app for speaking with DigiSpark using libusbx and libusb-0.1
I know this isn't exactly what you are looking for, but maybe it will get you started!
This website has a general overview of how USB devices work:
https://www.beyondlogic.org/usbnutshell/usb1.shtml
Particular sections give answers to things from the list of things you don't know yet about USB.
E.g. to find out how USB devices identify themselves, read about USB descriptors:
https://www.beyondlogic.org/usbnutshell/usb5.shtml#DeviceDescriptors
To learn how a C/C++ program can talk to a USB device, see examples on using the libusb library:
https://github.com/libusb/libusb/tree/master/examples
To learn how USB drivers work, see a tutorial from Bootlin:
https://bootlin.com/blog/usb-slides/
I have been doing desktop programming for a while but want to get started with interfacing with hardware. Specifically, I would like to learn how to use serial ports to take an external event and alert my application (so for example, I can turn on a camera when motion is detected by an external sensor).
Please tell me how to get started, what type of sensors, what books (or online resources) are available. I tried Bing and Google but I need more pointers.
Serial interfaces are fairly simple to work with. But they do require some sort of a decoder on the other end (such as a UART.) Another option would be using the parellel port. The advantage of using a parallel port is you start with a break out of the I/O pins. You can typically control 8 devices with a very simple to build interface.
Most platforms gave a simple way to gain access to the LPT ports without too much effort and again they are very easy to interface.
Quick results for tutorials...
Parallel Port Programming
Parallel port output circuit
A tutorial on Parallel port interfacing
LPT Port Info...
Parallel Port (PC)
LapLink Cable
Printer Cable
IEEE 1284-B
IEEE 1284-C
Centronics (36 pin)
I would recommend you the book Linux Device Drivers 3rd Edition
Although I haven't programmed any hardware interface yet, I think this book will get you ready to start hacking.
There really aren't a lot of one-size-fits-all tips for this. You're going to need to look at the documentation for your device, it should specify the protocol of what it will send over the serial port and what commands you can send in return.
Make sure you understand things like what means to have a text encoding like ASCII or UTF8. Most any device that sends and expects text will use an ASCII encoding.
I'm not sure what OS or language you're using, but be aware that you're sending raw binary data through a serial port, so for example if you're using C# you would want to wrap your serial port data stream with a StreamWriter or StreamReader with the correct text encoding.
If you can find an old modem online or craigslist that might be a good start. The serial comms specs for those are pretty well documented.
After that I would just start investigating things that you are interested in - your interest in the project will drive the learning and progress more than anything IMO.
I think this site has some fun things to try:
http://blogs.msdn.com/coding4fun/
You should get a data acquisition hardware and interface with that.
http://www.dataq.com/products/hardware/
If you just want to learn how to use the serial port, get another PC with HyperTerminal (included free with Windows), and use it to send and receive data from your development machine over the serial port. This will give you very manual control over what's sent to your development box, so you can get some confidence that what you're reading and writing is correct. Once you've got the basics of serial I/O down, you can move on to your camera/motion sensor/etc.
You don't mention what OS or development environment you're using, but in VS 2005/.NET 2.0, there is actually a SerialPort class. If you're doing raw Windows API, MSDN has an article at http://msdn.microsoft.com/en-us/library/ms810467.aspx which covers the basics. If you're using another OS, sorry I'm not that familiar (I know, boo hiss on me).
The most important thing is just remember to set your communication parameters on both sides of the connection the same. There are four parameters that govern if both sides can understand each other : baud rate, bits-per-byte (usually 8), parity bits (even parity, odd parity, none, or always 1 or 0), and stop bits. HyperTerminal also lists a "Flow Control" option, I recommend setting it to "None" until you get comfortable. Xon/Xoff flow control is a fairly common way of making the other side pause while you process a bufferfull of data.
Buy a microcontroller and build a simple robot, cnc mill or something. Atmel AVR and/or PIC is the most common from what i understand.
Also gives a lot of electronics experience