Is there a way to retrieve a Windows CE 6.0 image from a working hardware device that uses Windows CE?
This depends on the kind of device you are using.
Many x86-based devices boot from HD/CF/SSD/SD devices that are formatted as regular media devices. You can connect them from a PC and you may be able to find the boot image (you may use nk.bin or a compressed format).
But this is true only if the OEM did not put in place some measures to prevent you from doing that.
For devices that boot from flash accessing their contents is more complicated and, in any case, device specific. Some devices can boot in a different way, allowing you to load a firmware that is commonly used to update images, sometimes it can also recover the existing one, but it's not granted.
Taken for granted that you are trying to do that for legally acceptable reasons, if you can provide a "bigger picture" description of why you need to do that, you may find alternative ways to solve your problem.
Related
I am doing some research on the WebUSB API for our company because we are going to start to manufacture devices in house.
Our current device manufacture comes with an application so the team can plug the device into a computer and diagnose it. Their application allows us to read outputs from the device, as well as pushing commands/configuration to the device over a wired connection.
Since this device is 100% ours, we are also responsible for building out the diagnostic tooling. We need some sort of interface that allows a user to read outputs and send commands/configuration to the device over a wired USB connection.
Is the webUSB the correct API? If not, what are some suggestions for accomplishing the requirement? Are we limited to building some sort of desktop or mobile application?
I would recommend resources below to read to help you understand if the WebUSB API fits your needs or not:
https://web.dev/devices-introduction/ helps you pick the appropriate API to communicate with a hardware device of your choice.
https://web.dev/build-for-webusb/ explains how to build a device to take full advantage of the WebUSB API.
From what you describe, WebUSB isn't strictly required but won't hurt either.
First and foremost, you will need to implement the USB interfaces reading data and sending configurations. It will be a custom protocol, and not one of the standard USB device classes such as HID, video or mass storage. The details of the protocol and if you use control, interrupt or bulk transfers is your choice.
I'm assuming you will connect the devices to Windows PCs, and you likely don't want to put money into writing device drivers. If so, the easiest approach is to add the required descriptors and control requests required for Microsoft OS 2.0 Descriptors. That way, the WinUSB driver will be installed automatically when the device is plugged in.
Using the WinUSB API, a Windows application will then be able to communicate with the USB device. No additional drivers are needed. (On macOS and Linux it's even easier as you don't need the Microsoft OS 2.0 Descriptors in the first place.)
On top of that you can implement the additional descriptors and control requests for WebUSB. It will provide the additional benefit that you can write a web application (instead of a native application) for communicating with the USB device. (Currently, you are restricted to the Chrome browser.) WebUSB devices should implement the WinUSB descriptors as the alternative (.INF files, manual installation process) is a pain.
The already mentioned web page https://web.dev/build-for-webusb/ is a complete example of how to implement it.
I have a desktop application I've written in c#. I only want users with a license dongle to be able to use the software. I checked, there are companies that provide this facility but I find them expensive.
Is there a way I can turn an old pendrive into a dongle so it doesn't show in the file explorer, but the software can read from it ??
This is not possible with a normal pendrive. You would have to change the firmware of the pendrive controller.
I've never worked with the Yocto Project, and barely knows what it is. But I'm investigating the possibility to use a Simatic 2040 as a gateway between an USB hall sensor and industrial PLC network.
The sensor that we want to use is this one. It's designed to use with an Windows desktop PC, connected via USB.
Now my main question is, would it be possible to write software in the Yocto device to capture the sensors data, and share this information with an industrial PLC network.
The industrial PLC network is also Siemens based, so I don't see much problems around that because we can make use of the Node-Red Profinet or Modbus library's.
The question is stated in very general terms, so I will have to answer in very general terms.
Overall the answer to your question is yes, but there are a number of details to sort out (some of them might be show stoppers).
Yocto is a system to generate embedded Linux images and also SDKs (cross compiler toolchain + sysroot).
You might be fine to take an existing Yocto Image for the SIMATIC 2040 and just add your own application to it. For this a matching SDK has to exist. This approach works fine as long as your application has not too many dependencies and you don't need to many modifications off the existing image.
If this is not the case you might be better off generating a custom image as well as an SDK (based on the existing SIMATIC 2040 configuration).
Considering your USB device. The linked data sheet states windows support. Your options?
Talk to the vendor? Does he provide a driver, but doesn't advertise it? Is he willing to hand out a detailed datasheet?
Check if there is a community driver in the mainline kernel?
Reverse engineering the existing Windows driver?
Pick an alternative device with an existing Linux driver (preferably in the mainline kernel).
The right solution depends on the time and effort you are willing and able to put into this.
Is there any way in any Linux-based OS to access the instructions sent to have it transfer the instructions meant for the GPU to an external device connected via USB3.0 (and, obviously get the pixel output back)?
In Windows there is no native support for this kind of thing. Although many external graphics card exist which connect to a PCi slot, I didn't come across any USB ones.
Is there any way to accomplish this with native support of any of the Linux OSes?
EDIT: I was misunderstood, as far as I can see the comments. I want to program an external graphics card, I'm just looking for a way to get the GPU instructions to get to my device and get back the pixel array.
I am trying to connect my POS Terminal(WinCE Secure Multi-Application Operating System,200 MHz ARM 920T 32 bit CPU) to my windows 7 PC. The issue is i am getting a device driver software issue and the device is not been recognized. I didn't got any installation CD or software with the product.I couldn't find a suitable driver for the same in the web and would need to install the CAB files through WMDC into the device so that i can automate the product testing. Can someone please advice in fixing this driver issue and direct me on how to establish the connection. Any help is highly appreciated.
Thanks,
John
This can be a complex task. First, the connection type (serial, USB, Ethernet, other) is important. I'm going to assume USB, as that feels like what you're probably talking about (you should edit and clarify though).
For USB to work, you need drivers on both ends - the device and the PC - and they need to cooperate. For Windows CE devices and USB, the common way (though not only option) is to use ActiveSync. There is an out-of-the-box client application driver for Windows CE (repllog.exe) - though it requires the OEM actually plumbs it through to the transport driver. For the desktop (Vista and later) you would use Windows Mobile Device Center (WMDC).
You might simply be able to install WMDC and you're off and running, but it's always possible that the OEM disabled that, since you might not want someone to connect a PC to a POS system and subvert the normal operation. Have you asked the device OEM?