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.
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.
I am being confused on all terminology referring to it, so here is my request:
Name at least one USB Wireless Adapter whose Wi-Fi chipset is supported by a wireless driver enabling AP mode, Monitor Mode and PSM (Power Saving Mode) in a SoftMAC implementation (PSM functions accessible and modifiable via software).
The goal is to work on a new Power Saving Mode implementation, by modifying existing implementations of either PSM or APSM.
Check out MediaTek USB dongles:
http://www.mediatek.com/en/products/connectivity/wifi/pc/usb/
Most of these can work straight away using Linux mainline rt2x00 driver. rt2x00 is open-source, supports Monitor mode (can sniff packets), AP mode (can work with wpa_supplicant/hostapd), and is a SoftMAC driver (as it works with mac80211 driver). As for PSM, I'm not sure although there seems to be a good chance that rt2x00 supports it as well..
I want to create a network intrusion detection system for iOS application. The main function is to allow the user to select a home network (maybe prompt them to simply enter the IP address only) and to be able to monitor the packets and if there is anything suspicious- we need to alert user via push notification or email. i wanted to use the features and functions of Snort, an open source network intrusion detection system.
Any Suggestions,Sample code ?! Where to start?
VM's do not have native hardware access, which is necessary for monitor mode. Maybe IOMMU PCI passthrough or bridged devices might work. It is probable that it is possible to compile the iOS kernel with a module that works for the wireless nic. I don't think it's a proprietary chip specific to apple, because a chip with multie technology capabilities in RF wouldn't be cost effective qt all. I'm just not sure if the filesystem blocks access in the OS framework or whatever. I have tried to compile linux/iOS ARM packages natively in the shell with the aircrack-ng source, but have not had any luck. Maybe someone would have better luck actually cross-compiling a package and sideloading it somehow.
I don't think this is possible for multiple reasons:
You wouldn't be able to compile snort for iOS.
In order to run snort you have to have the interface (NIC) in promiscuous mode, which I really don't think you can do on an iOS device (iPhone, iPad, etc) but I have never really looked into it, but Apple probably locks this down and restricts this for security purposes so if you could do it you'd likely have to jail-break the device first. It's not even possible to put the wifi card in an Apple laptop into monitor mode, which is similar.
There are a lot of dependencies for snort, most importantly the DAQ. You would probably only be able to monitor the wifi interface (even this might not be possible), not the interface used for the cellular network as this is probably a different daq than standard Ethernet nics.
This very likely is not possible on iOS, if it is it would be VERY difficult to pull off and even if you did the use case isn't really good. Even if you could get a daq for the cellular card, I don't know if promiscuous mode even exists and if it did all of the traffic on the cellular network is encrypted, so inspecting this with snort would be pointless. If you could do it for the wifi traffic it's probably not worth the effort honestly, especially since almost all traffic nowadays is encrypted, you'd have to decrypt it first, which certainly isn't possible to do.
In the view of Johnjg12's comments, I am wondering about your goal. If you want to make a NIDS, you can make it OS independent, anyway. If you want to consider only HIDS that monitors packet destined to it, we don't need it to be in promiscuous mode (a comment to Johgj12's response). so, now it is something to do with Snort on iOS. I am wondering if we can do it on a VM and then turning its promiscuous mode? Having said that I came across a link: https://www.securemac.com/macosxsnort.php
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.
What is the simplest way to get raw access to HID devices on OS X?
I've been looking through the IOKit examples, but even opening a device seems needlessly complex, involving multiple callbacks and include things from half a dozen libraries.
libusb is available for OS X, but the kernel grabs all HID devices for exclusive access, and I have been getting strange behavior while trying to use a codeless .kext to block it from associating with my device (it prevents the kernel from grabbing the device initially, but any calls to configure the device seem to cause the kernel to grab the device away from under the little python libusb script I am testing with).
Basically, I have a HID device that just streams data. I want to open it for (ideally exclusive) access, and just get the datastream.
All the examples I have found in the IOKit docs are really complex, compared to the ~8 lines it would take in libusb. There must be a simpler way that isn't a 3'rd party library.
It's worth noting that I am entirely unfamiliar with programming for OS X in any capability.
Python support would be a nice plus
Unfortunately there is no other way than using HID Manager apis. Raw access to HID devices in OS X it's not supported.
The documentation makes it clear:
HID family. Through the HID Manager, the HID family provides a device
interface for accessing a variety of devices, including joysticks and other
game devices, audio devices, non-Apple displays, and UPS (uninterruptible
power supply) devices.
Raw access through POSIX apis it's only available for storage, network and serial devices:
Using POSIX APIs
For each storage, network, and serial device the I/O Kit dynamically
creates a device file in the file system’s /dev directory when it discovers
a device and finds a driver for it, either at system startup or as part of
its ongoing matching process. If your device driver is a member of the I/O
Kit’s Storage, Network, or Serial families, then your clients can access your
driver’s services by using POSIX I/O routines.
So you can either use HID Manager apis directly or you can use libusb or (as the other answer mentions) hidapi which are nothing more than wrapper libraries over HID Manager apis. The benefit of using these libraries is that they abstract most of the low level calls thus making them easier to use.
Take a look at the hidapi mac backend
http://www.signal11.us/oss/hidapi/
https://github.com/signal11/hidapi