I have a smart card-like miniSD card (it's a javacard as far as I know) and I'm trying to write an emulator for it that runs on Windows and Linux. The emulator will be used in software integration tests. I want to test my client without using the actual hardware for several reasons. One reason is that the actual hardware will change its state irreversibly and doesn't allow a complete reset.
The device implements a mass storage with FAT32 file system. It contains a special device file that is being used for controlling the device via simple file write/read operations.
My goal is that the virtual (emulated) device appears with drive letter in Windows explorer as soon as the emulator is started, similar as if someone would actually plug a real device.
I wonder if there is any open software project that I can base my program on? The biggest challenges are obviously
Providing/developing a "virtual" (USB/SD) mass storage device
Intercepting file I/O operations on the special device file.
According to Wikipedia, device files are a common way to simplify driver development. So I wondered if there are existing emulation solutions for driver developers. At least I couldn't find any.
Simulating the device file itself would be an important first step. My first idea was to use a normal file and to communicate with the client by actually reading/writing to this file while observing it. I.e. clear the file as soon as the client wrote to it and write the response into it. I don't know if this could work at all. One problem is that the client doesn't open the file with shared mode, so my simulator cannot access it at the same time.
Then I found out that QEMU can emulate mass storage, however it seems that it only supports image files and that probably doesn't allow device file.
Microsoft has some documentation about how to write USB device emulators and drivers but it seems to be very complex and I wondered if there is an exisiting solution that could be extended:
Finally there is the USB/IP Project, but I don't know if it is helpful as I still need to develop a driver and then I'm back at the complex MS documentation above.
Related
I'm using a LPC178 development board and I want to read a file present on a Windows PC. My dev board only has a RS2323 interface to communicate with.
How can I go about transferring the file from my PC to my MCU using a RS232 (serial) link? I found a reference which explains how to transfer data between a MCU and PC but it isn't about file transfers.
Afaik there is no easy solution for this like calling something like "copy" or "fopen" over RS232. I would be happy to be proven wrong here.
The fastest solution might be to write a little programm running on your Windows Host, which listens to your RS232 communication and pipes your communication into/out of the file based on your communication protocol. This can be done with standard file operations in the language of your choice, for example C, C++ or Python.
Your problem is one of the oldest in the book. How do you transfer files without fancy operating system abstractions. For RS232 (or any other serial method) there exists many file transfer protocols.
One of them is kermit. This is a protocol from 1981 and can transfer binary and text files. It is able to be embedded in a micrcontroller and there exists programs to transfer/receive using kermit.
alternative old site for reference
In the simplest case you would use a file transfer protocol such as XMODEM, YMODEM, ZMODEM or Kermit - these protocols were designed in the days before networking and the Internet were ubiquitous and deal with simple point-to-point transfers between two computers. They are supported bu most terminal emulator tools such as TeraTerm Pro or PuTTY so no specific PC software need be written, just the microcontroller end.
A more complex but flexible solution is to implement a TCP/IP stack and a PPP driver, and an FTP application layer - probabaly only practical if using a third-party TCP/IP stack and application layer. You can then use any FTP client for the PC end, so again no PC software required. While this may be overkill if all you need to do is transfer files, it has the advantage of allowing you to use the the single serial port concurrently for other data streams and application protocols such as Telnet. The disadvantage perhaps is that while Windows does support PPP it is buried within the dial-up networking and to be frank a pain to get working.
Very first step you have to do is ensure serial communication is working fine.
Send a byte continuously from mcu to PC and display it on some io console (for example: HyperTerminal, Dock light )
Receive a byte to mcu from PC and echo it back to PC.
Once you are sure that serial communication is working fine then select some file transfer protocol and implement it.
While you can select any of the available protocols or write your own protocol and implement it.
For purpose of discussion i select Xmodem protocol.
If you consider some other protocol you may stop reading answer here.
XMODEM is a simple file transfer protocol.
Refer http://web.mit.edu/6.115/www/amulet/xmodem.htm for detailed information.
You may implement Xmodem mcu side by reading protocol. Or may consider using open source also ( if available )
PC side i prefer to use HyperTerminal io console as it is compatible with Xmodem.
In HyperTerminal all that i have to do is configure settings and select file for transfer to mcu.
Now transfer any file to mcu using Xmodem protocol from PC.
What you do with received file in mcu is up to you : )
Let's say I have a webcam, and I installed the device driver for this webcam in my Linux OS, now a device file will be created for the device driver (for example: /dev/video0).
Now say I want to create a program in C that wants to access this webcam. How can my program access the device driver for the webcam, should my program use the device file (/dev/video0) to access the device driver, or is there another way?
You asked a general question, and then gave a specific example. I'll try to address both.
When you load a driver, the way to communicate with it from user space is by whatever means this driver defined. Typically, this is through a /dev device created for the driver. If that's the case, yes, that's the only way to communicate with it.
This is not universally true. Many drivers also have entries under the /sys sysfs pseudo file system, and some aspects can be modified through there. In fact, there are whole classes of drivers that are only accessible through the /sys fs. Prominent examples are GPIO and Led devices, that can be turned on and off via access to /sys/class/gpio and similar paths.
Another option, considered deprecated but still sometimes used, is to use the /proc pseudo file system. Again, this is up to the driver to define its communication method. As the user, you will have to follow whatever protocol the driver defined.
Also, some drivers don't have any file system presence at all. The most obvious standard example are network interfaces. The only way to communicate with them is via the networking system calls.
In the particular example you provided, you talked about a video camera that appears as /dev/video0. Such a camera is, usually, a Video4Linux (or v4l) camera, and those are accessed via their character devices.
With that said, the protocol for communicating with the camera might have wrappers that makes life easier. If you open the actual device, you might have to implement a rather complicated handshake with it. Instead, you can use the v4l library to wrap the details of the access.
Make no mistake. You're still talking to the character device in /dev. It's just that it's not your code that does it, but the library's.
I am working on an application that runs on a small Linux computer with an SD card for storage. The application runs automatically on startup and we want to be able to easily check the logs that it produces. Normally I would just write to a file, since that also seems to be what most normal software would do. But I am hesitant about doing this because I think continuously writing logs is a bad idea because of the SD card for storage.
The problem is that sometimes when we want to check what is happening on the system, say for debugging purposes, we have stop the application via SSH and then start it again so that we can see the output messages.
So my question is: is there a way to say write logs to some kind of circular list that can then be viewed when connecting to the system over SSH? The application is written in C and C++ if that matters.
Is your application on a Raspberry Pi?
The Linux Operating system, and all other technology, is probably writing so much to the SD card, that your 500 KB/ hour would be next to nothing in comparison.
I would personally just have the program log to the file.
If you really do not want this, you have a few other options:
Have the application send the logs via the internet to some service, which you can then monitor
have your application store the logs in a buffer in-memory, and then write to file when you reach some threshold. Expose an endpoint on localhost which listens for a message, and when received, writes the in-memory contents to the file. This allows you to see log-files for current in-memory logs without having to wait.
First thing, I think that the SD driver care about writing and about I/O operation scheduling them in the better way for the safety of the SD card itself (using a virtual filesystem). Maybe you can work on your log level to be sure to write the necessary information and nothing more.
Based on shared inputs SD card wear-out might not happen easily, however, there are many ways to handle this scenario based on the hardware and software architecture of your system :
Check if you can write the logs to some other storage device within your system (Depends on your architecture).
If external communication peripherals are available in your system, check if logging can be done by redirecting the logs to remotes servers or other devices.
Perform selective logging based on some log-level as per your architecture / framework. Also, you can do only critical logging in SD card and the other logs can be re-directed based on your architecture. This can reduce the number of writes.
Based on your need/architecture, check if the data can be compressed and logged. This can reduce the number of times, the logs are written to SD card.
To continue working and simultaneously view the logs :
Based on your architecture/need, check if you can write to a file periodically or based on threshold so that you can view the file irrespective of operation.
Send selective logs to external server / device
I would like to programmatically copy a section of a file on another file. Is there any Win32 API I could use without moving bytes thru my program? Or should I just read from the source file and write on the target?
I know how to do this by reading and writing chunks of bytes, I just wanted to avoid doing it myself if the OS already offers that.
What you're asking for can be achieved, bot not easily. Device drivers routinely transfer data without CPU involvement, but doing that requires kernel mode code. Basically, you would have to write a device driver. The benefits would have to be huge to justify the difficulties associated with developing, testing, and distributing a kernel mode driver. So unless you think there is huge benefit at stake here, I'm afraid that ReadFile/WriteFile are the best you can do.
Ideally, I would connect an Ingenico/VeriFone terminal to the net via an Ethernet cable, the terminal will exclusively run a program that I wrote. This program would poll a webservice, beep when it detects some kind of info, wait for somebody's input, transmit said info back to the webservice, and print a ticket.
Is this possible with terminals from Ingenico/VeriFone/someone else?
I'm looking for the form factor/semi-ruggedness of said terminals. We don't need/want something bigger like an PC or laptop.
I have built applications on Verifone, Hypercom and Trintech terminals. The Verifones are by far the easiest to devlop for. They have a simple flash and RAM file systems, apps are downloaded and run as files, the OS (Verix) is POSIX like with good C/C++ libraries etc. Only downside is tool cost, VerixV use ARM SDT (5K Euro per seat) and older Verix terminals (Coldfire based) use SDS compiler. Dev kit comes with default keys to sign your apps (not most secures, but you can password protect download access on terminal). I have written lots of apps on these terminals, not just payment app. Verifone multi-app controller (VMAC) is a crock of shit but it's very easy to run multiple apps yourself using pipes for inter-app comms (your apps won't run on third party terminals which use VMAC though). We used ethernet connectivity for FTP to manage app and config download as well as transaction batching. Also used WIFI on latest terminals for same (also used 3G terminals but I didnt do any of code on these). Verifone is PC-like in terms of code development and we shared lots of library/app code between WIN32/Verix/VerixV and Linux. Verifone terminals are well built and can take a lot of abuse but then most serious terminal manufacturers do a good job these days.