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.
Related
I wanted to update the application of an ESP8266 that I have very little physical access to. The new application uses the function uasyncio.create_task(coro) which is not available in Micropython 1.12. Fortunately I was able to replace the function with uasyncio.ensure_future(obj).
Nevertheless, I have the question of whether the area in the flash with Micropython can be updated via WLAN at the runtime of the "OS" Micropython?
Does Micropython run completely in RAM?
A Linux kernel, for example, can easily be exchanged at runtime so that the new kernel is loaded at the next boot.
Yes, Over The Air (OTA) updates are possible. Your device has to be configured for OTA updates before hand with two OTA partitions. MicroPython will run from one of the OTA partitions. You can use MicroPython to retrieve and write new firmware to the other OTA partition. When you perform a reset the processor will start the application in the other OTA partition. You can do this over and over again ping-ponging between the two OTA partitions.
See these links for some examples
I am developing a smartcard UMDF windows driver. I would like to achieve following behaviour:
When listing all connected readers by using API call SCardListReaders I want to retrieve the correct friendly names for each attached reader. So for example if I have two readers of same brand I want this to be returned by the driver:
SmartcardBrand USBReader 0
SmartcardBrand USBReader 1
I know that the friendly name is composed of the attributes SCARD_ATTR_VENDOR_NAME, SCARD_ATTR_VENDOR_IFD_TYPE and SCARD_ATTR_DEVICE_UNIT the driver returns.
My question is, in my driver, how can I distinguish between SmartcardBrand USBReader 0 and SmartcardBrand USBReader 1?
What shall I return to the OS when SCARD_ATTR_DEVICE_UNIT is requested. I cannot use and increment a global static variable in my driver because every time a new reader gets connected a new UMDF host process is launched (I can see it in the task manager) resulting in a separate new memory area.
What is the proper way of counting device instances in a UMDF driver?
I solved the problem by using memory-mapped files. Basically each UMDF process of my driver creates a memory-mapped file with name of the reader's friendly name. When an other process tries to create a file with the same name it indicates that a driver is already running.
However, there is inconsistency when I connect a reader which uses my driver and afterwards connect a reader which uses Windows native driver. The Windows driver will not see my memory-mapped file I created and apply index 0 for its device.
I found out that, when the Windows driver is loaded it queries SCARD_ATTR_VENDOR_IFD_TYPE, SCARD_ATTR_VENDOR_IFD_TYPE and SCARD_ATTR_DEVICE_UNIT from my driver (and from all other drivers currently loaded). I guess this way the Windows driver can know which device units are taken and apply a free one to its reader.
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.
I'm trying to set up a Wi-Fi repeater on Ubuntu PC or embedded Linux with Wi-Fi dongles, using one dongle at a time. Drivers and firmwares for dongles are done and worked on my PC/embedded board for AP mode and station mode. Then what can I do next?
In my thought, I have to simulate 2 interfaces with only 1 dongle. Than run Hostapd on a interface, run wpa_supplicant on another interface. Is that a workable method? If yes, how can I "create" 2 interface with 1 dongle, say, wlan0/wlan1 or wlan0.1/wlan0.2 or something like that?
Is the whole scenario workable just through some operation about interface and system, or the scenario MUST be supported by driver of dongles, if driver doesn't provide this scenario, then it is impossible?
I tried it on Ralink Soc before(it's called ap-client mode by Ralink). On Ralink platform with its own SDK including Linux source and Wi-Fi drivers, it is done by iwpriv commands. There are interfaces call "apcli0" to work in station mode and "ra0" work in AP mode, but there is only 1 physical Wi-Fi interface built-in in Ralink Soc. It works just fine but I'm not using Ralink Soc now. Is that feature also available for other dongles?
After working on driver compiling, I got some idea.
The chip I'm using supports "dual mac" feature, and the driver must support this feature.
If the driver is successfully compiled, inserted and the dongle is plugged in, there will be 2 interfaces coming out, for example, wlan0 and wlan1. Therefore I can configure one interface as AP and another interface as station.
So the key point is the chip and driver must support dual mac feature.
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.