I have a doubt on the following scenario in device tree, could you please help.
We have a device node entry in the device tree and corresponding driver exists in the Kernel source, but actual device is not present on the board then what will happen?
Will the driver build with the kernel source, if the driver builds then driver binding happens?
Thanks in advance.
If your device is actually not present in the board, and you want to keep the device node in the device tree structure. you should use status = "disabled" in your device node. This property tells that device is not currently available. In future whenever your device is available you can make this status = "ok".
And yes driver will be built always, only bindings won't happen, as there is no corresponding device exists.
Related
I'm trying to connect a serial device with Webusb, under linux.
I have been able to list the device and open it, but I can't claim the interface. Chrome complains that the device is busy, and to fix that I need to unregister the CDC-ACM driver.
Is there a way to prevent the CDC-ACM driver from loading the device, without changes on the destkop? maybe I can change the USB descriptors?
If you can change the device descriptors then modify the protocol, class and sub-class reported by the CDC-ACM interface so that it is marked as vendor-specific (0xff). The CDC-ACM driver will no longer recognize the interface and bind to it.
Just for completeness, if you could make changes to the desktop then you can either blacklist the usb-serial driver entirely in /etc/modprobe.d/blacklist or you could write a udev rule which runs for that device in particular (recognized be either bus path or vendor and product ID) and executes a script to unbind the driver.
I was looking for accessing device information like current device WLAN MAC address, IMEI, OS type etc. using Gluon mobile. How can I do it?
Currently the Charm Down Device service provides some of the features you are requesting.
Model: device's model or product
Uuid: device's universally unique identifier
Platform: the platform string that the operating system uses to identify itself
Version: the version number of the device platform
Serial: the device hardware serial number.
Wearable: true if the device is a wearable
In your view, you can call the service like:
Services.get(DeviceService.class).ifPresent(service -> {
System.out.printf("Device Model Name: %s", service.getModel());
});
Also, you can find implementation details for android here and for iOS here.
If there is any other feature you require, and you want to implement it, you can either clone and modify the service (see this question on how to do it), or create a new one (see this sample).
I'm working on a project that involves connecting a single-board computer (either a BeagleBone Black, or a BeagleBoard X15) to a Mac via USB OTG, and then delivering basic mouse/touch input (pointer coordinates and left/right-click events).
This process should be technically very similar to connecting a mouse (or, more accurately, a touchscreen-style device that receives precise mouse coordinates) and passing some ordinary HID input to MacOS. So I don't need most of the complexity of IOKit - I don't think I need to create a kernel extension; I should just be able to create an instance of a HID for which MacOS already has generic kernel extensions.
So I'm delving into IOKit to figure out how to create the device instance and provide input. However, nearly everything I'm reading about IOKit involves creating and registering new kernel extensions, services, etc. - none of which is germane to my project.
So far, the only relevant leads I've got are the I/O Registry Explorer and the contents of /System/Library/Extensions. Several items in there look promising, such as AppleDHIDMouse.kext. However, I cannot find any examples of code to bridge the gap: how my USB-connected device can connect with the kernel extension, create an instance for itself, and send commands.
Any help? Thanks in advance.
Either your device is fully USB HID compliant, in which case you shouldn't need any code at all on the Mac side, or you'll need to create a kernel extension.
How far have you got? What does your device look like in ioreg/IORegistryExplorer? (The latter is from the "Additional Tools for Xcode", downloadable from https://developer.apple.com/download/more/ )
Does your USB device's interface report as HID? (bInterfaceClass 3) The device itself normally reports as a composite device (bDeviceType 0). bInterfaceProtocol and bInterfacSubClass also have defined meanings in the context of HID, and should probably both be 0 for a "tablet" style device. With that in place, macOS should pick up your device as a HID device and try to drive it with one of its built in HID device drivers.
The way HID devices work is through "reports" - event data structures with a flexible format/layout, which is defined via the device's "report descriptor". What buttons, input axes, etc. your device has is defined there.
For an example of a USB "tablet" device (absolute coordinate pointing device) that works with macOS, check out the code for the USB Tablet device that Qemu emulates. That might be a good starting point for the report descriptor of your own device.
If your device doesn't conform to general USB HID conventions and uses some custom protocol, you'll need a custom kext (up to macOS 10.14) or dext (from macOS 10.15 onwards) which will most likely implement a IOHIDDevice subclass. An example of such a driver is the open source Mac driver for the Xbox 360's game controller, which doesn't behave like a standard USB HID device.
I have an Arduino Uno that is successfully registered as a device with IBM IoTF. It can send information to the Bluemix Node-RED app without any issues now.
Now, I would like the Node-RED app to send commands to the device (the Arduino Uno). The Arduino is subscribed to the MQTT without any error. But, it is not receiving any commands from the Node-RED. I followed the directions at the link below to create another flow in Node-RED to show when a command is published and the commands are being shown, so they seem to be going to the MQTT broker. But, the device (Arduino) is not receiving them.
How can I figure out how to get this working?
Node-RED, IOT Foundation Out Node Not Sending Commands
I have the IBM IoT Out Node parameters set as follows:
Authentication: Bluemix Service
Output type: Device command
Device type: Arduino-tempsensor (this is the same string I used for the device type (name) when I registered it in IoTF)
Device ID: I put the MAC address here, should it be more
Command Type: status (I used the word "status" here. Does capitalization matter? Where should I get this value from? I used "status" because it is in the topic: "iot-2/cmd/status/fmt/json" is that correct?)
Format: json (does capitalization matter here?)
data: {"d":{"myName":"Arduino Uno", "temperature":989}} (I used this because it's JSON and I wanted to just see anything at the device)
Name: IBM IoT App Out
I typed up this whole question and then it occurred to me that the test flow to look for the published command should have all of the parameters set to exactly the same as the output. When I tried that, I was not getting the command message coming back. Then, I realized that my mac address (device ID) was capitalized in one place, but not the other. The MAC address (Device ID) I used to register the device was all in caps, so I make the Iot-out node for the command so that it was all capitalized and made the Iot-in node to test for the message so that it was all capitalized. Now it works! Then, I looked back at the device (which was printing to the serial monitor so I could see what was happening) and I am now seeing the messages! So, make sure your parameters follow the same capitaliztion!
Can anyone help me with the AT command to write characteristic value, Or how to send data from arduino to another ble device using Hm10 module.
The HM10 after sending the AT+START, does advertise packets, and can detect the service and characteristic, But the characteristic value is the default 0x00, How can I change that?
Have checked the data sheet multiple times but can not find an AT command that is capable of doing the same.
UPDATE: Similar problem with setting the HM10 in Central Mode:
Central Mode Setup!
1) AT+ROLE1 - Set up to Central Mode
2) AT+IMME1 - Start from RESET
3) AT+SHOW1 - Show discovered devices
4) AT+DISC? - Discover Devices
Get Device MAC ID,
5) AT+CON[MAC ID]
RESULT: Always gives OK+CONNA and after 10seconds OK+CONNF
I am confused, Use of "AT+START" before "AT+DISC?" causes AT+START to not work and viceversa.
Using AT+START results into a loop of OK+CONN followed by OK+LOST continuously and no more AT commands are accepted. I believe it does result in a
Can you advice on the right order?
Using LightBlue iOS app as the peripheral. How am I to select a service and subscribe to a characteristic to receive data from the application?
Thank You.
There is no AT command to set a characteristic value.
The HM10 is a serial-port emulation device - whatever serial data you send to the HM10 module (aside from the AT commands) is made available on it's BLE characteristic. Unfortunately the data sheet doesn't document the service and characteristics, but this code suggests that the serial RX/TX characteristic is 0000ffe1-0000-1000-8000-00805f9b34fb
So, data written to the serial port should appear as the value of that characteristic. Data written to that characteristic should be delivered out of the TX serial port pin on the HM10 module.
This thread is a bit dated. But the HM-1X firmware now supports changing the characteristics of a module.
"AT+CHAR?" Will get the current characteristic setting for RX/TX
"AT+CHAR0xFFFF" will set the TX/RX characteristics to 0xFFFF
Send: AT+CHAR0xAAA0
Recv: OK+Set:0xAAA0
These features were added v518.
If you need to update your firmware,
Link to Huamao's download site.
I don't have enough reputation to comment on Ladvien's answer, but...
Just a word of warning regarding updating the firmware with a new version from Huamao's download site. http://www.jnhuamao.cn/download_rom_en.asp?id=83
In my experience there were issues with V539, which prevented the firmware operating as an iBeacon - and there may be other problems.
I was fortunately enough to find someone emailed me a copy of the V538 firmware and was able to downgrade again.
Huamao doesn't have old versions of the firmware available for download and AFIK there is no way to backup your current firmware version.
But it was possible to downgrade from V539 back to V538 if you have the bin file for V538 etc. i.e At least up as far as V539 the firmware does allow downgrades and was not checking version numbers to only allow upgrades.
No need to use any AT-commands to send data as it works like transparent serial. Currently it works good to upload sketches from iOS devices to Arduino. Check out http://www.apploader.info