I was wondering if there was a way to simulate a plug and play event through software only. We are testing a driver and we wanted to test the installation of a driver from the start of a pnp event, but we don't want to have a real printer hooked up.
Not really. Drivers (pretty much by definition) operate so close to the hardware that the Operating System has some major challenges faking things. This is especially the case on Real Operating Systems, where performance matters. Performance is the best argument for efficiency, and that in turn is a very good argument against abstraction.
For "smart" devices like printers, the driver might very well send a series of queries. Like, "What firmware do you have installed?" Because if the firmware is 1.0, the driver might have to apply a few workarounds. That's fair game in Plug and Play driver design. Again, this will be non-trivial to fake.
I'm just going to throw this out there because it's the first thing that popped in my head.
Could you have someone create a USB dongle that registers as the printer? That way it wouldn't be inconvenient to unplug/plug.
Related
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.
Disclaimer: I am (mostly) hardware ignorant. This is probably my problem. However I find it hard to accept that it is not possible to debug hardware so therefore I just wanted to get some second opinions.
We have an issue. Where certain actions (swapping Usb devices in and out at run-time) can blow either the Usb hub or chip on our Usb board (it's custom hardware). It's a fuzzy problem (it appears that the degree of "blownness" can vary a bit) and the problem manifests itself in intermittent fashions with various symptoms that are very difficult to reliably reproduce (typically random corruption of packets).
This results in difficulty in ascertaining if a newly reported problem is due to this hardware fault or is actually a bug in the software. We have since implemented protection on these devices but if an unprotected device is used with a protected device it has a possibility of then tainting the (now protected) device. One of the ports is also not protected meaning that someone could still "kill off" a unit that should be safe by accidentally using the wrong port.
The upshot of this is that it is impossible to tell which of our devices suffer this issue without completely replacing ALL the hardware (we've bitten the bullet for most of our production hardware but there is still a lot of dev and QA hardware out there with this issue).
I would imagine that it could be possible, given a piece of hardware that one could use some kind of hardware diagnostics tools to determine whether the kit is faulty or not. Am I living in a dream world? My hardware department tell me that the only tests that can prove the fault would be software tests... but as I have stated the symptoms are very difficult to reproduce. As I'm not that experienced with hardware I don't know if this is the only answer or not. I therefore ask the world.
Built In Test Equipment is used for performing a Built In Test
BITE for BIT
(No bytes involved.)
It is completely, utterly normal for military/aerospace equipment to have extra hardware to test itself with.
The original IBM PC hard a surprising quantity of test hardware built in.
In the case of your equipment, a test device and some statistical analysis would do the trick.
This could be done in hardware in a dongle, but frankly would be easier to with some software.
Use two back-to-back USB to RS232 serial converters to make a USB loopback device.
Send lots of data , checksum packets and measure error rates.
I'm assuming your errors occur on the in->out as well as the out-<in side.
Really, your hardware guys need to look at some application notes; USB IS hotplug-safe IF done according to the book.
There is a cool example out on the net of opto-coupling a USB chip's connection to the board it's onto prevent this sort of thing. The USB chip is connected to the host, powered from the host, and the interface to the USB chip is SPI, which is opto-coupled back to the rest of the board.
As for you, the chips are failing partially. Injured devices may work fine for months then die. An electro-static discharge ("a static zap") can do the same thing that you describe. A device can be injured by shocks too small for you to feel.
The wires and features in semiconductors are microscopic, and easily damaged by stray electricity.
If the hardware design is mostly right probably the liekly cause of the problems you've been experiancing is ESD when the devices are handled to plug/unplug. Your devie has it's own power supply and it's ground voltage floats relative to the other end of the USB cable, until it is connected.
Hope this helps.
No it's not.
A lot of hardware manufacturers begin with hardware testing. Inputs and outputs (IO) is just a matter of evaluating where circuit flow is going. Consider the abstraction that both software and hardware deal in boolean operations.
Hardware is just a little less human readable!
When it comes down to it, hardware's line of communication is (at its most basic) HIGH and LOW through various pins.
I have a brother (in the automobile tech industry) who has used and electrometer to measure voltage on pins to isolate where the problem is (I'm not really smart enough in that field to go into more detail on how he does it).
Your problem is that the only known symptom is so hard to detect (packet corruption in USB stream), that you're going to need software (at some level) to detect it.
If you can work out why packets are getting corrupted (bad voltages?) then maybe you could detect that with hardware?
Otherwise you need some kind of robust testing kit, and software to send/receive lots of packets to look for corruption?
No. That's what oscilloscopes and logic analyzers are for. Also there is more specialized equipment such as USB testers.
The simpler the hardware is, and the more access you have to the signals, the more likely you are to be able to diagnose it in a 'purely hardware' kind of way. For example if you had a simple parallel port card plugged into a PCI slot, it would be relatively straightforward to put a bus analyzer on the PCI bus, and the adapter's output, and see if the outputs did the right thing when the card was addressed. But note you'd still need to attempt to access that card from the PCI bus, which would mean either (A) some kind of PCI bus simulation, which would be one heck of a big pile of test hardware, or (B) a cheap off-the-shelf PC with a few lines of test code.
But then at the other end of the spectrum, suppose you're dealing with a large FPGA. You can get one heck of a lot of logic into an FPGA, and you won't necessarily have access to all the test points you'd like. I've personally encountered a bug with a serial port embedded in an FPGA, where a race condition with the shift register preload register would occasionally corrupt a byte. Hypothetically the VHDL could have been reworked to bring out test points, and a pile of scopes and analyzers gathered, but from a management standpoint it was much more cost effective to try to tease the problem out with software. Under normal usage, the bug in question would have turned up once every blue moon. We iterated through speculation about the conditions that would elicit the bug, and refining the test code, until we had test software that could reproduce the bug 2-3 times a minute. At that point we could actually provide clues to the VHDL guys that helped them fix the problem quickly.
Long story short, inside of a week a hardware bug was smoked out via software, whereas starting with the same information and going 'hardware only' would likely have not been any faster, and would have required a lot of expensive test equipment. So, yeah, you probably can do it without software, but as usual it's a trade-off, and you have to find the right balance point between the amount of software vs hardware for the job.
Is it possible to program a wireless adapter attached to a computer?
I need to modify how they work, not just using them to perform a task such as scanning or connecting.
I have already tried the Native Wifi API, but that library is too high level. I cannot modify how exactly the wireless adapter works.
Any solution in any programming language in any operating system is very welcomed. (Sounds so desperate lol)
You need an open-source operating system then. Hardware varies in how programmable it is, but for example, Atheros wireless cards do not have an on-board processor, and therefore they do the absolute minimum of the 802.11 protocol in hardware, leaving everything else to the device driver. More info in these places: http://linuxwireless.org/ http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=summary;
If you really need to go further that what commodity hardware can do, look in to GNU Radio and the USRP/USRP2: http://gnuradio.org/redmine/wiki/gnuradio
And yes, you do have to be careful about the legal implications of this stuff, but then if you don't turn off the regulatory framework, there is software to help with that.
Generally speaking, the manufacturer will attempt to prevent you from doing this. Since what you're working with is really a radio transceiver, its operation is regulated. In the US, for example, such things fall under the purview of the FCC. Depending on the country, changing how it operates (and then operating it) is likely to be illegal.
If you have an atheros chipset on your WLAN card then load up linux and install ath5k/ath9k or madwifi and you can do some interesting things with the driver.
I had a look at this and this but no one sounded particularly sure of their ideas and I'm kind of after a different thing anyway. I want to hook my usb power cables (red and black) up to my phone so I don't have to use a battery (the battery is dead anyway and this is just an experiment). The problem is that USB standards ensure that a minimum of 4.35V is supplied, when I only want 3.7V. Does anyone know for sure that you can or cannot regulate power output programmatically? Some other queries I have are: What kind of power does the sleep mode provide? And what would I need to code something in to play with this, C++?
No, you won't find a computer that allows you to set this voltage in software. It would break the USB specification.
You can get 150mA by default, and 500mA if your USB device negotiates it with the computer (requiring a little bit of logic in the device). Multiply by 5V to get the provided power.
A bit more info on the answer from Pascal:
The normal operation (Non-Configured mode) is 100mA
In theory, the operating system should check the MaxPower value of the device's configuration descriptor to decide if to allow it to draw more than 100mA.
In practice, PCs do not do it (and have no way to control it). So you can try taking 500mA.
(Of course connecting a bus powered hub and linking more then one 500mA device, should, not work.)
If the device is not actively used, the OS may (and should) suspend it. When suspended the power is limited to 1-0.5mA (Again, in theory, since it can not be controlled by software).
I'm planning to build a USB device that has buttons that some software needs to respond to, and indicators that the software needs to control. I'm new to USB, so I'm looking for any pointers that will get me started.
When I did some USB development a while ago, I found the information at USB Central extremely valuable.
For low bandwidth requirements, you can use something like the FT232R which is a single-chip USB serial implementation. The FTDI drivers are readily available and make the device appear as a regular serial port to the host computer. This is orders of magnitude easier than rolling your own USB implementation (for either end!).
Kinda vague, but in the past I've done a little bit of USB development. The easiest stuff tends to be HID related device as the subset of USB used to commincate is very to implement on both sides. There are hardware devices which are essentially stubbed out to work with HID, you just customize some circuity and go.
The USB standard is actually quite readable. Though it might be a bit overkill if you just want to create a simple device. You could probably get something like this, which is basically an 8051 controller with a USB connector together with firmware and a DLL.
Checkout WinDriver, which is a commercial multiplatform tool what give you easy way to implement usb drivers in user mode, source code compatible between Linux and Windows.