If I want to make a GPIO usb device, could I resolve filesystem corruption with realtime linux?hamjudo wrote:The model B has a built in 2 port USB hub, which does not know how to act as a USB device. The model A directly connects the processor USB interface, which can be configured either as a USB device or USB host.
Obviously, that won't work until people have Model A's to develop on, and someone has the talent, the time, the inclination, and the documentation, to write the device driver.
Bit-banging a slow speed USB device over GPIO should be possible on the model B. This could be a simple port of one the many examples for 8 bit micro controllers. Emulating a USB mouse or keyboard is the classic first application. The timing constraints may not play well with the non-realtime stock Linux kernel on the R-Pi. But if you're just doing it to learn, you can treat the Pi as a micro controller. You can write a device driver that takes control of the hardware, and doesn't return control until it is done doing its timing critical parts. Old time Unix and Linux hackers are horrified by the thought of a device driver that disables the other interrupts, potentially breaking any open network connections, starving the graphics system, and corrupting the filesystem. This is horrifying on a machine that is being used for other things. Not a problem on an inexpensive system that isn't being used for anything else. Just back up your SD card before messing with the your own device driver. Locking up the system a few times is a sure thing. Corrupting the filesystem is just incredibly likely.
Users browsing this forum: No registered users and 9 guests