As i am new to embedded field i am facing difficulties in understanding the clear difference between i2c device/driver and platform device/driver.
i have read this link:
What is the difference between Platform driver and normal device driver..?
which say platform devices/driver are use for not discoverable device like devices connected at i2c bus and Platform devices are bound to drivers by matching names.
I have gone through a board file, in which audio codec(non discoverable device) connected at i2c bus is registered using i2c API (i2c_register_board_info, omap_i2c_add_bus etc.), so my questions are
What is difference between i2c device/driver and platform device/driver ?
When to use i2c related API and when to use platform related API(platform_driver_register,platform_device_register) for registration of device/driver in kernel. or if we can use i2c related API for non discoverable device(connected on i2c) registration then where we need platform device registration.
Every SOC(Silicon on Chip) or microcontroller will have a I2C controller, which provides a way to connect and communicate to I2C devices like camera sensors, PMIC, temperature sensor etc. The driver used for configuring and using this I2C controller is called platform driver. This I2C controller is called platform device. Mostly platform devices will be part of the SOC. The registers of the I2C controller are programmed using platform driver. These registers are in say ARM memory mapped and will be available on TRM of the SOC.
Now all the I2C devices that can be connected to the SOC or microcontroller via I2C controller like Camera sensors, PMIC, temperature sensor etc need a driver to control them. This driver is called device driver. The registers of these devices are not part of memory map of SOC. Need the datasheet of the I2C device like OV5640 Camera Sensor to program the registers. I2C data are sent out to program the registers and access data.
The official link for platform drivers can be found here LWN.
Platform devices are inherently not discoverable, i.e. the hardware cannot say "Hey! I'm present!" to the software. Typical examples are i2c devices, kernel/Documentation/i2c/instantiating-devicesstates:Unlike PCI or USB devices, I2C devices are not enumerated at the hardware level (at run time). Instead, the software must know (at compile time) which devices are connected on each I2C bus segment. So USB and PCI are not platform devices.
Platform devices are bound to drivers by matching names,
Platform devices should be registered very early during system boot. Because they are often critical to the rest of the system (platform) and its drivers.
So basically, the question "is it a platform device or a standard device?" is more a question of which bus it uses. To work with a particular platform device, you have to:
register a platform driver that will manage this device. It should define a unique name,
register your platform device, defining the same name as the driver.
Are platform drivers for those devices that are on chip?
Not true (in theory, but true in practice). i2c devices are not onChip, but are platform devices because they are not discoverable. Also we can think of onChip devices which are normal devices. Example: an integrated PCI GPU chip on a modern x86 processor. It is discoverable, thus not a platform device.
Are normal device drivers for those that are interfaced to the processor chip? Before coming across one i2c driver ??
Not true. Many normal devices are interfaced to the processor, but not through an i2c bus. Example: a USB mouse.
What is difference between i2c device/driver and platform device/driver ?
i2c device driver API is used to control the i2c peripheral from the i2c client driver like audio-codec
platform device driver API are used by non-discoverable devices say audio-codec to get the hardware related configuration via device tree or board file
Related
I have a Realtek RTL8188FTV wifi adapter, but the official document says IT DOES NOT SUPPORT HOSTEDNETWORK (Access Point, AP Mode is NOT AVAILABLE), does AP mode reauires some special hardware that RTL8188FTV donesn't have or the software firmware on the flash of this chip didn't turn the AP feature on.
I have a USB camera that does work with iOS devices on a specific application made by the manufacturer. When connected, it creates an ethernet interface for which I'm always assigned the same IP address and then when launching the app the camera shows up.
There is no documentation for this device or known API to make it work on other devices or apps.
How can I monitor the traffic between the device and the USB camera in order to find out endpoints (wether HTTP/HTTPS or not) to be able to use the camera on other devices?
The virtual network created by MacOS is (at first glance) not the good approach because my iOS device port is already in use by the USB camera.
I'm interested in both non-jailbreak and jailbreak ways of doing that.
I have a idea that requires connecting an ios device to a Raspberry Pi without the end user having to do anything special. The device will not be connected to an existing wifi network so BT or wifi hotspot seem to be my only options, BT preferred.
I'm aware that Apple does require some sort of BT hardware approval which I wont have I'll be using generic BT hardware. Once a connection is established I then want to be able to request data or call API's running on the Raspberry PI.
Does any of this sound achievable and are there any links that may help.
There are two flavours of Bluetooth: the so-called Bluetooth Classic, and the newer Bluetooth Low Energy (also called Smart Bluetooth or Bluetooth 4.0, though this is actually incorrect as BT 4.0 includes both Classic and Low Energy).
On iOS, Bluetooth Classic devices do indeed need to go through specific processes (MFi), or use an existing BT protocol supported by iOS to be used.
However, you can connect to any Bluetooth Low Energy (BLE) device, without any need for MFi, approval, or support by iOS. This is done though the Core Bluetooth framework.
As long as Bluetooth is enable in the iDevice, you can connect to a BLE device without any user interaction (though UX usually dictates doing so, so a user can actually select a specific device if there are many "matching" devices in range).
Is it possible to send an ASCII code on an external device through USB port using IOS API? I assume that it is possible through bluetooth connection, but I'm not sure through USB connector. Any thoughts?
I would appreciate if someone could put me in the right direction.
Thanking you in advance
That largely depends on the level of sophistication of this "external device". If this external device is just a bare metal embedded device without some sort of operating system you definitely need MFI.
Otherwise, you can run a usbmuxd server (e.g. on Raspberry PI with Linux) to establish a connection via USB. Usbmuxd is basically the technology that Apple uses to communicate between iOS devices and Desktop apps such as iTunes or Xcode. And yes, it is App Store compliant, e.g., Duet Display uses this approach to make an iPad a secondary display for your Desktop via USB.
There are several open source libraries that provide a high level API, e.g., PeerTalk or DarkLightning.
I have a specific requirement to communicate an iOS device with a wifi/bluetooth enabled device. At this moment, I'm confused with some points and requires an expert advice.
Can I use adhoc wifi method for communicating? but in this case, can I connect to another network? On my research, I found no so I'm opting for Bluetooth.
If I go in bluetooth communication,
Do the device need MFI licensing or can we use classic bluetooth?
From few blogs I found out that Bluetooth low enrgy devices with 4.0 can be used to communicate with ios without licensing. Will this work?
PS: My requirement is to send strings of data to and fro from the ios and other wifi/bluettoth enabled devices.
An iOS device can only be connected to a single Wi Fi network at a time, so an Ad-hoc network connection probably won't work for you.
If you join the MFi program you can use the Wireless Accessory Configuration (WAC) feature to simply the process of connecting your device to the user's existing network.
If you use Bluetooth Low Energy/Bluetooth Smart/Bluetooth 4.0 then you don't need to go through the MFi program, but you are limited to iPhone 4S and later and iPad 3 and later. If you use "classic Bluetooth" (Say Bluetooth 2.1 Serial Port Protocol) then it will work with all devices but you need to go through MFi.
Bluetooth Low Energy isn't great for high data volumes (say video streaming) but is fine for smaller amounts of data (you talk about "strings" so it will probably be suitable for you).
The other advantage of BLE is that it is independent of the iOS device's Internet connection so the user can cary the BLE device around and maintain communication regardless of their WiFi connection.