From Wikipedia, I see the following written:
"When a calling program invokes a routine in the driver, the driver issues commands to the device." (https://en.wikipedia.org/wiki/Device_driver)
What happens when a program "invokes a routine" in the driver? Is the driver contacted by way of inter-process communication? Device drivers execute continuously once loaded, but I don't understand how my program can 'tap it on the shoulder' and ask for something. Are drivers fundamentally different on different platforms?
You can open specific device with whose driver you want to communicate. You can use CreateFile command to open device handle and then use IOCTL or WriteFile for communicating with driver. You can use DeviceIoControl for calling any IOCTL of driver. You should previously know the IOCTL codes for calling. I would suggest to read provided link once http://www.codeproject.com/Articles/9504/Driver-Development-Part-Introduction-to-Drivers
There is a section "Communicating to the Device Driver" which tells how to communicate with device driver. I hope this will clear much of your doubt regarding communication with drivers.
Related
The 0.5.1-devpreview BSP for RPI3 comes with libtinyalsa.so, libalasautils.so but seemingly no adb shell commandline support for audio.
We are designing a custom audio board (with audio processor) for use with Android Things and Raspberry Pi and we would typically use ALSA utilities and custom kernel drivers for accessing this board under Raspian.
It is possible the default Android Things I2S peripheral drivers and Peripheral Manager support the stream interfaces we need (the same way the VoiceHat drivers were wrapped), but we have little to no information on the default drivers in the RPI3 BSP, and we don't have any information on how to override the default drivers in Android Things without a distro rebuild.
Seems silly to write a Native C++ low-level peripheral driver when so many audio processor companies already provide ALSA-ready ASoC drivers for device source tree use.
Best practices for writing your own audio driver for Android Things?
The VoiceHat driver is one example of how to do a userspace audio driver.
If you're using a custom audio board, you should be aware of the audio chip the board uses. Looking at that chip's datasheet, you should be able to use the same peripheral I/O (UART, GPIO, I2C, SPI) to configure the connection and read/write data over the I2S bus.
In the Google Assistant sample, the app registers the VoiceHat at the beginning of the activity and unregisters it at the end of the activity.
Does exist a standard protocol for network printers? Some network printers require the installation of drivers to be used... Is there some network printer that can be used without installing additional drivers? After all, when we connect the network cable from the laptop to the router, we do not need to install drivers (any operating system already includes the driver).
Are there any open source projects related to protocols for communication with a network printer?
The standard protocols are the LPD or IPP protocols.
If you need to talk to a printer over the network, you can either attach it to a device that translates packets into USB/LPT commands, or attach it to a linux/windows PC and print through an LPD service running on that OS.
IPP Everywhere tries to be what you are asking for.
A PWG standard that allows personal computers and mobile devices to find and print to networked and USB printers without using vendor-specific software.
I am aware that there are programs out there like lojack for laptops that get installed on the BIOS, but I'm still a little confused. When reading about lojack, it seems to me that they can't fully located the laptop's location until the user logs in and tries to access the internet. So I'm thinking that it's a BIOS application so that it wouldn't matter if the thief reformats the HD.
So my question is, does anyone have any ideas of how an internet enables BIOS application would be written. I'm not looking for full answers -- just ideas or resources to get started. For example, is such a thing written in assembly? Once one such app is written, how does it get transfered to the BIOS.
Does the BIOS program itself recognize that there is an internet connection (when the thief logs on to the OS). Or upon logon, does additional processes get spawned? Are there any resources/websites that anyone can direct me too?
You didn't mention whether you were interested in legacy BIOS or EFI BIOS, but I would mention that with EFI there is the capability of writing EFI applications. See Intel Press:
Harnessing the UEFI Shell
The EFI Application toolkit comes with a complete TCP/IP network stack:
http://www.intel.com/technology/efi/toolkit_overview.htm
More at tianocore.org
Regarding "LoJack"-style solutions, one of the providers of this technology is Absolute Software's Computrace product.
Basically there are 3 components: 1) a software component that runs in the OS; 2) a BIOS component which is baked into the system BIOS (accomplished via Absolute working with the PC vendor); 3) servers at Absolute software that talk to the PC.
For more information on how it works visit:
http://www.absolute.com/en/company/Computrace-Persistence.aspx
(see especially the demo video on this site)
To learn something about BIOS, one good source is coreboot.org. It is an open source BIOS (or firmware) and support some physical machines.
Legacy BIOS is written in assembly language, but new generations, such as UEFI or coreboot, are written mostly in C language. BIOS program is stored in the ROM, and executed by the CPU automatically.
The BIOS program itself does not access the internet or perform any of the advertised functions. The LoJack addition to the BIOS firmware is a file copying/patching utility - at boot up it can check the harddrive for a copy of Windows and proceed to silently install/repair the LoJack service if it has been removed. The service itself includes several measures to lower it's profile and prevent itself from being disabled (similar to how many trojans and malware run several processes that each restore the other if one is disabled or killed).
The LoJack BIOS program can't do anything if a unsupported operating system (like Linux) is installed after the harddrive is wiped.
I have a Wi-Fi driver from a manufacturer. That driver has Plug and Play support. After the adapter has been inserted or removed, Windows CE has recognized it successfully. But at boot time, if the adapter is "inserted state", CE OS does not load it so I must remove then insert it.
I want to load the driver automatically during boot time. Is it possible?
Before, I've written a simple stream interface driver. I have edited project.reg to create a sub-key under HKLM\Devices\BuiltIn so that Device Manager can load automatically during boot time. And it was successfully loaded. But Wi-Fi driver is a non-stream driver. Can Device Manager load Wi-Fi driver automatically with the same way?
Are "all of drivers under HKLM\Drivers\BuiltIn" stream interface drivers? What differences are there between stream interface drivers and NDIS Wi-Fi drivers from the point of loading automatically during boot-time? I will very happy if you can explain it a little.
I want to load the driver automatically during boot time. Is it
possible?
Yes, it is definitely possible. That was the main purpose of plug and play devices. The WinCE device automatically loads a driver appropriate to the Plug 'n' Play device. There would not be any need for doing it manually. If so, then there is no need for a Plug 'n' Play functionality.
As this is not happening in your case, you could try the following
Have you checked with any other Plug-n-Play devices to the WinCE device?
Each time you plug-out and plug-in, is it installing the drivers or is it just loading? You can verify the debug logs to confirm this.
Are "all of drivers under HKLM\Drivers\BuiltIn" stream interface drivers? What differences are there between stream interface drivers and NDIS Wi-Fi drivers from the point of loading automatically during boot-time?
Actually, the block devices can also be loaded automatically, as similar to stream interface drivers. The HKEY_LOCAL_MACHINE\Drivers\BuiltIn registry key recognizes built-in block devices also.
You can refer this msdn link for further information regarding loading the block devices.
I am very enthusiastic in writing device drivers for a microcontroller(like PIC, Atmel etc).
Since I am a newbie in this controller-coding-area I just want to know whether writing device drivers for controller is same as we write for linux( or any other OS) ?
Also can anyone suggest some online device driver building tutorial for the same ..?
Thanks,
If you are thinking about developing the device drivers to interface your device with a host computer (probably using USB), then most of the microcontrollers nowadays implement default classes that rely on native drivers.
A concrete example:
If you use a PIC18F4555, you can use the regular HID (human interface device) windows driver to communicate with your microcontroller (given you implemented it correctly). No need to develop any driver.
Writing a device driver for an MCU is a pretty far cry from writing it for a OS. Most MCUs won't have an OS running on them at all. You'll generally end up writing some low level Interrupt Service Routines (ISRs) and filling up buffers, that your application software will end up emptying. You don't have to fit into any device driver paradigm that an O/S has defined. You basically have to read the datasheet for the device you are wanting to interface with and read and write to its memory over whatever interface it might use (e.g. SPI, I2C, UART, etc.). Ultimately the device driver ought to provide intuitive function calls to the application software.
If you are using AVR MCU like atmega then you can use vusb (https://www.obdev.at/products/vusb/index.html) for those MCU that don't have any HID and handles the interrupts by connecting D+ and D- pins of the USB to digital I/O ports of the MCU.
The atmegaU2 packages have their own USB communication ports and HID.