I am developing an PC interface that connect to an embedded device. From this interface I can modify some parameters, and I can both load data and dump data. Also I can upgrade the firmware.
How should I call the buttons on my interface?
Download data or Upload data when the goal is to send data from my PC where the interface is running, to the embedded device on which the interface is connected.
The exact same question about the button "Download firmware" or "Upload firmware"
Of course during the transfer, a message should display "Downloading" or "Uploading".
I am confused between the choice of Download/Upload which is perfectly clear between a PC and Internet.
Where there is also the notion of the interface which is running on the PC, but which remote control the embedded target by sending commands to it. So should I see the problem from the target remote controlled through the interface running on the PC or from the PC?
This is confusing....
This is confusing....
It is; so whatever you call it how would you expect your users to know what it means!? The solution is to use less ambiguous terms that do not depend on the point-of-view. Just be clear:
Update firmware.
Write device parameters.
Read device parameters.
Related
i am making a micro-controller based dongle and i need it to interrogate host state when connected and display status (status={HOST_OFF,HOST_BOOTED,SERVICE_DOWN,SERVICE_STARTING,SERVICE_UP,SERVICE_ERROR}
i can get all the statuses from a terminal so i wanted the device to be able to login and run some commands to check stuff.
I considered the option of using CDC-ACM and a monitoring service running to update the device but that only works if the monitoring service doesn't fail (say because of disk space or port unavailable etc), and when it fails i cannot get errors.
I am basically trying to eliminate the reason for sending a tech just to look at the screen to see whats going on.
I tried just identifying device as tty device but this seems to expect a service to connect to it from the host side before i can send and characters
I am trying to talk to a MSC USB device (interface class 8, subclass 6, protocol 0x50) via a plain USB API with endpoints (all set up for me).
Provided I have a valid CDB, such as for "Test Unit Ready", how to I send that over the USB interface?
Where can I find examples or docs for how this is done?
Background: The actual platform is macOS, which doesn't provide SCSI-passthrough for block devices, and the native SCSI API is also not available in this case.
I have, however, been able to initiate communication on the USB level with the device, and am now trying to circumvent the blocked SCSI device level access by talking thru USB directly.
Most such devices implement the so-called “Bulk Only” protocol, which is specified here: https://usb.org/document-library/mass-storage-bulk-only-10
Essentially, you send a 31-byte “Command Block Wrapper”, which includes the CDB and is specified in section 5.1 of the spec, to the device via the bulk out endpoint. You then read or write the data to be transferred from the input bulk endpoint or to the output bulk endpoint and finally read the 13-byte command status wrapper from the bulk in pipe.
However, note that you’ll need to make sure the OS hasn’t already loaded a driver for the device - from user space, the system won’t give you access to the endpoints when a kernel driver has claimed them anyway, but if you were to attempt to use the same pipes as the default driver from a kext, you’d get unpredictable results.
I have an issue where WiFi is not available on an Android device. We want to stream image data from the device using a websocket server (written using WebSocket++) through to the PC. However, I'm not sure if this is possible without operational WiFi. So, the position we are in is that we may only have the USB link available.
Someone today suggested we might be able to get Websockets working using adb port forwarding (see https://developer.android.com/studio/command-line/adb#forwardports), but I'm not sure if that's correct. Could this work, and what would that solution look like?
Are there any other reasonable options. I'm not certain if tethering is available on the device and if that could be another solution?
I'm making an application in which a device will send a photo to my ftp server and I shall display that photo in a webpage. Now, I have configured the Windows FTP Server(2008 R2) and Everything Works fine. i.e. when i copy and paste files into ftp via my windows explorer it shows up. But however I'm unable to receive files from the remote device. I called up the other team, they say that the device is sending photo and showing success message. Any idea how to cure this?
Actually, the device was sending data via GSM connection, which had a slow speed. I had to set higher timeouts in FTP to made it work.
So I have a bluetooth device, this device uses SPP to transfer data between the PC and itself. It connects fine through Windows as a bluetooth device. I can find it, enter the paring code and assign it to a COM port. Now I want to be able to send data through the com port using Windows API but it is refusing to do so.
I suspect that I need to setup the COMMCONFIG Structure correctly (see below)
http://msdn.microsoft.com/en-us/library/aa363188(VS.85).aspx
Unfortunately I have no idea what is the proper setting. I know SPP is supposed to emulate the RS-232 communication... so maybe I have to study up on that to figure out the right setting? Or is there some automatic way to set the COMMCONFIG structure.
I seriously doubt it. If it would be used then you'll have no chance at guessing at the custom provider data without docs from the driver author. Pay attention to the handshake signals, serial port devices routinely ignore anything sent to them when the DTR signal is turned off. And not send anything back with DTR off. A driver would emulate that. Use EscapeCommFunction() to turn them on. Also try a serial comm program like HyperTerminal or Putty to test this so you can isolate the source of the problem.
Why not use the Bluetooth sockets API? No need for troublesome (virtual) COM ports then.
If you're using managed code then see my library 32feet.NET
If using native code, use SOCKADDR_BTH with Winsock connect etc, see e.g. Bluetooth and connect (Windows) Then you can use the standard Winsock send/recv API
Ok, I found that you can use the
GetCommConfig and GetCommState functions to figure out the settings.