@gongji, the A and B connectors are to distinguish a host from an endpoint. The A connector plugs into a host and the B connector plugs into an endpoint. So, the cable between your PC and your printer has an A connector on the end going to the PC and a B connector going to the printer. This helps keep the signal polarities correct as well as preventing someone from trying to use the printer as a USB host.
In fact, I dont think any USB cable has the A connector on both ends. If it did, somone could really mess things up by trying to connect two hosts together.
Your flash drives have only an A connector because, in essence, the functional equivalent of the cable with its B-end is an integral part of the flash drive, so only the A end of the "cable" is actually used.
One of the slides mentions that USB cables are made with wires size 28 AWG. This is the minimal size, but the actual configuration of the cable depends on the current consumption of the load and the overall length of the cable.
You say that I need a CPU in my FPGA controller because I need to implement a "stack". But a stack is nothing more than a bunch of registers. I can very simply build a bunch of registers in my FPGA. Also, I can construct finite state machines of virtually any complexity. So, what also am I missing? I really would like to think about using USB, but I would like to keep the implementation in my FPGA-based controller as simple as possible. Thanks, Christian.
Great. All the equipment is going into a 19" rack so it would be nice to have just one hub. Is the maximum cable length per device? from the host or hub? or total length of all cables as in the IEEE-488 spec.?
I was wondering about the USB ports embedded in laptops. It appears that the front USB ports aren't the same as the rear USB ports. One set will show a modem folder in Device Manager while the other set will not. Is there a hierarchy in USB? Is this a Host Controller issue?
Yes, in this case the front ports are driven by one USB Host controller and the rear ports by a different (second) one.
It is a capability issues. There is not hierarchy.
I am interested in having a cpu communticate with a "smart" power supply controller, or controllers. I am interested in using USB for interconnections between host and "device" rather than use boards communicate using ISA bus, or even PCI bus--using the PC104 format. This would drastically reduce the number of I/O connections to the FPGA on the "device" which must communicate with the host. I need to know if the protocol is simpiler to implement that the alternative protocols. I don't know the USB protocol AT ALL. So, would I gain anything using USB bus rather than ISA? What is required in the "device" to communicate over USB? Can I implement the protocol without the need for a CPU in my controller's FPGA? This question is particularly of interest to me. I imagine the host (PC104 CPU) has plenty of software support already to communicate, but what do I need in my smart controller ("device") to communicate over USB?
Thank you Christian. Unfortunately I was experiencing audio issues, so I missed the beginning part where you spoke of Host Controller speed. I was wondering about the USB ports embedded in laptops. It appears that the front USB ports aren't the same as the rear USB ports. One set will show a modem folder in Device Manager while the other set will not. Is there a hierarchy in USB? Is this a Host Controller issue?
When you connect a hub to a host port. the hub is reconized as a HUB device and will report the number of ports it has. The Host will know. We will see tomorrow how electrically the host is made aware of the existence of a device
Telling me the device only uses the B connector tells me I bought the wrong connectors for my projects. Looking for one with Ethernet and USB in the same connector housing. Won't find similar for IEEE-488.2.
@ Admin / Jennifer: For some reason the slide numbers stopped starting in slide 12. Also, the slide numbers are very hard to see since they are buried beneath the "DigiKey Continuing Education Center" banner.
I am interested in investigating USB as the protocol for interfacing a computer to devices, controllers, and sensors in industrial processing equipment. I am finding the environment to be too noisy for reliable USB. What can I do do improve the robustness in this environment?
I would like to learn more about enumeration. I would like to send information to the embedded device while enumerated as an HID device. I woule like to learn how to enumerate as multiple types from, i.e. HID and cdc.
Our company designs user interfaces for various industries and we typically use USB as the direct interface for standalone modules, or as the communication protocol between our part and the main processor board.
Primary intention for using USB in our embedded products would be focused on transfer speed. Getting data from point A to point B as fast as possible. It would be nice to use USB 3.0 but that doesn't seem likely for low-power embedded devices in the near future.
Engineers at Fuel Cell Energy have found a way to take advantage of a side reaction, unique to their carbonate fuel cell that has nothing to do with energy production, as a potential, cost-effective solution to capturing carbon from fossil fuel power plants.
To get to a trillion sensors in the IoT that we all look forward to, there are many challenges to commercialization that still remain, including interoperability, the lack of standards, and the issue of security, to name a few.
This is part one of an article discussing the University of Washington’s nationally ranked FSAE electric car (eCar) and combustible car (cCar). Stay tuned for part two, tomorrow, which will discuss the four unique PCBs used in both the eCar and cCars.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.