Devcon Disable Port vs Digital Relay - usb

I have a device connected to a USB and it periodically sends data to my PC. During the time it is not sending data, the USB cable needs to be removed, else, the device won't work (a fail-safe feature, if the USB cable is connected and attached to pc, the device is in communication mode, if the USB cable is disconnected from pc, it is in stand-alone operation mode).
I was thinking to use the Devcon so I font has to use another hardware, I'll just disable the USB port during an operation mode, then enable it during communication mode. However, the periodic transfer of data can be set to every 5,10,15,30 minutes depending on the settings.
My question is, will it be okay to disable/enable the USB port periodically? Say every 5 minutes? Won't it cause any problem in the long run? Or would it be more efficient for me to use external hardware, a switch to connect/disconnect the USB? Appreciate any advice or thoughts.

If devcon works for you, I don't see why it would cause any problems in the long run. There is no inherent reason why the hardware should get damaged when you run some commands in your software to disable a USB port.
Using external hardware to accomplish the same thing would not be more efficient because you'd have to pay for the hardware and maintain it.

Related

Detect USB connection on atmega168 v-usb

I'm using atmega168 with AVRUSB. (yeah, old version of V-USB. already integrated and seems to work otherwise, so no hurry to change)
My hardware can be powered by USB or via other source. How can I detect if the host is actually connected? It would be also nice to init USB whenever it's connected, but not necessary. Most important is that I need to skip the blocking USB polling if there's no host.
The hardware I'm using doesn't have USB VBUS connected to any GPIO, so a software-based method is required. Maybe I could add some timeout to the USB init routine or something similar?

How to reverse-engineer a USB device without monitoring traffic?

How is it possible to determine the commands to operate a usb device, if that device comes from another operating system and traffic monitoring software cannot be installed on that OS. The only method i can think of is sending random commands to the device, until the device responds, but this seems implausible for more complex commands, and potentially dangerous. For example, consider the DualShock 4 controller. Sony has not made an official driver for this device, so what method can i use to create a linux driver for it?
Get a hardware protocol analyzer. Then you won't need to install any software on the host or device under test. Here is one that I have used:
http://www.totalphase.com/products/beagle-usb12/

How to to run program when USB is inserted?

Hi I have one program that I need to run on my server but the problem is that my server don't have any monitor, keyabord and mouse attach to it so I can confirn when windows 7 ask me to run program so is posible to just plug USB Mass Storage device in a computer and computer would execute this without any qestions?
Perhaps you could look into using autorun or some variant thereof (e.g. a program that would monitor the USB bus for devices, and automatically run some program when it detects that an appropriate storage device has been connect).
Bear in mind that, depending on the physical setup, this could be used as an attack vector.
As Celeriko said, you should try to find a way into connecting to your server remotely. Whether that be through SSH or a tool such as PUTTY (basically SSH right? I'm not sure off top of my head).
Having a usb automatically execute something would be a security risk and I believe it is restricted for that reason.
Best of luck trying to connect remotely into your server, it shouldn't be too difficult.

Virtual COM Communications Issue

I'm working on a Communications Device Class (CDC) driver for an embedded device, a Full Speed implementation of USB 2.0. The COM port settings are 115200, 8-bit, no parity, 1 stop bit, no flow control. Our PC application (32-bit, Windows 7, .NET 2.0) communicates with the target device through a virtual COM port, which on the target device can connect to either a FTDI (USB-to-SCI bridge) chip or the integrated USB peripheral in the microcontroller, depending on which port is selected by the application.
Both virtual COM ports work without any problems using Realterm. However, while our desktop application works using the virtual COM port connected via the FTDI chip, it hangs when attempting to use the virtual COM connected via the microcontroller's integrated USB peripheral.
When connected via the virtual COM port using the integrated USB, the application consistently hangs on the second call to SerialPort.Write(...). Using Serial Monitor from HHD Software I can see that the data is transmitted on the first call to SerialPort.Write(...). However, that data is never received by the target device.
It's odd because the only time I have seen similar problems on previous projects was when the flow control settings on each side of the bus were mismatched.
Additional info...
Here is the data captured from various port monitoring tools while running our PC application connected to the target device via its integrated USB peripheral. Any insight would be appreciated.
Sysinternals Portmon
Advanced USB Port Monitor
Device Monitoring Studio - Request View
Device Monitoring Studio - Packet View
For those that are interested, I am using CodeWarrior 10.2 with the MCF51JM128 from Freescale.
Any ideas or suggestions would be appreciated. Thanks.
It is clear from the logs that you are making the classic mistake of not taking care of the hardware handshaking signals. That only ever works by accident, a terminal emulator like Realterm will never make that mistake.
You must set the DtrEnable property to true. That turns on the Data Terminal Ready signal. It is important because RS-232 is an unterminated bus so is subject to electrical noise when the cable is disconnected or the power turned off. DTR convinces the device that it is in fact connected to a powered device. This is emulated of course in your case but the driver or firmware will still typically implement the RS-232 behavior.
And the RtsEnable property is important, used to handshake with the device and prevent the receive buffer from overflowing when the app isn't emptying the buffer in a timely matter. You really should set the Handshake property to Handshake.RequestToSend, the most common way a device implements it. Which then also takes care of turning RTS on. If you have to use Handshake.None for some reason then you have to turn it on yourself by setting RtsEnable to true.
This ought to take of the problem. If you still have trouble then use PortMon to spy on the way Realterm initializes the driver. Compare the commands you see against the commands that the SerialPort class sends. Make sure they are the same. In value, not in sequence.

Raspberry Pi - how to load RAM programmatically through SD interface?

I would like to have some kind of mechanism to somehow load the RAM on the Raspberry Pi programmatically from a controller computer (I assume through the SD interface) and then let the Raspberry Pi's CPU execute. Is there some kind of device that does this? And what is it programmed in?
It would also be great if there's a way to interrupt the whole thing from the controlling computer if needed.
SD is a fairly poor choice for an interface to try to push data into from an external source; generally the computer hosting the SD device wants to be the master of operations.
But the Raspberry pi has both uart serial ports and (on the model B) an ethernet interface. Downloading code through either is quite normal.
You haven't mentioned if you want to run an application atop a typical linux installation, or if you want to do bare metal programming. In the first case you would typically transfer the program to the file system (either ramdisk or the SD card) and then execute it.
In the second case, you would need a stub of code already on the device (which is to say, the boot partition of an sdcard) which knows how to configure peripherals sufficiently to enable reception of code via serial or ethernet (the latter complicated by needing a USB host stack), and then jump into it.