I'm about to go out and purchase the Invensense FireFly eval kit so we can begin evaluation and research into the SensorStudio Platform for gesture recognition.
I'm not exactly clear on what the Segger J-Link Debugger will be used for.
Do we absolutely need the J-Link to PROGRAM from sensorstudio to the firefly board or can it also go through the Arduino sketch as a header file?
Segger J-Link is required to debug your custom sensor (your application/algo) on the embedded system (Cortex M0 in the InvenSense FireFly 6axis) with InvenSense SensorStudio. If you do not purchase the Segger J-Link you cannot effectively design/develop your application which will more likely than not require "on target" debug of the embedded system, which contains your custom application. Segger J-Link is not used to flash code to the InvenSense FireFly. Segger J-Link is therefore used for debug only.
Related
I have a Qt application that's been built to run on Embedded Linux platform (i.Mx.6). My application should support both touch screen as primary input device and an optional USB keyboard if connected. So for now, I have configured my application to be launched as mentioned below:
my-qt-app -plugin tslib:/dev/input/event0 -plugin evdevkeyboard:/dev/input/event1
My application is able to detect the touchscreen and keyboard properly, BUT, I am noticing a problem if I unplug the keyboard while my application is still running, I see the below error on the console:
Could not read from input device: No such device
And my Qt application is lagging and is very slow in responding to the touch screen. Looking at the above error message it seems my application is still expecting some sort of data from the keyboard ?
Can somebody help me to recover from this error or give pointers to what's happening please, also if there is a way that I can detect the keyboard presence runtime so that I no need to pass -plugin evdevkeyboard as command line argument to my GUI application.
I'm working on the iOS app to interact with Arduino boards. On Arduino side i use "transparent" serial implemented in HM-10/11 firmware. So i just wire HM-10/11 RT/TX pins with Arduino ones and it works just perfect and write to specific characteristic to send data and subscribe/read to some specific to read from BLE module. No need to use any SDK or BLE library in arduino sketch, no need to modify bootloader.
Now i need to support NRF51822 BLE chips. Nordic has implemented UART serial in firmware sources but for my NRF51822 board (purchased on ebay) it's not uploaded to the chip by default as i can't see 0001 service and 0002 and 0003 characteristics. Do i need to purchase NRF motherboard and compile and upload this firmware? Can i do it without purchasing this dev kit? Can i upload over USB only or over BLE too?
If your are using NRF51822 standalone module ,then to update its firmware through SWIO/SWCLK pins ,you need a compatible JTAG programmer/debugger (you can check in segger website) . You can use Keil IDE to upload your updated firm ware to the flash memory of NRF51822 .
Although you need to upload using a SWD programmer, you are not limited to Segger.
There are open source alternatives like the Black Magic Proble which you can flash into $5 hardware (stm32f103 boards) from ebay.
You are also not limited to Keil or IAR for your compiler toolchain.
Its possible to compile using Eclipse and GCC ( Nordic have a blog entry in how setup an Eclipse base dev environment)
You can even program these devices using the Arduino IDE.
It is possible to upload OTA, but you would need to flash an OTA bootloader onto the device first using SWD and even then, you would probably need to upload via a mobile phone, as Im not aware of any PC ble devices that support transfer via the DFU protocol ( though some may exist)
These devices do not natively support USB.
Some boards using these device have a separate processor that allows upload as if the chip was a mass storage device, but I am not aware of a motherboard into which you could plug this module, which has that functionality.
BTW. The module you linked to, is actually designed and manufactured by Waveshare.com . Take a look at their website, it has full documentation on the hardware including schematics
The nRF51 and nRF52 dev boards has an onboard Segger / JLink. So then you can develop on and debug on the nRF51822 and flash other nRF51822s as well.
I am designing a USB keyboard with special capabilities. What information can such a HID device receive from the host?
Can I via USB:
Read data from a form on the screen?
Find out what OS the user is on?
Find out if there's been an error message?
Even 'know' what's going on visually on the screen, i.e. what program is selected or whether the program is windowed or fullscreen?
Thank you!
The device can't get any of this information from a standard driver that the operating system supplies because that would be a security issue. It can receive any information that your own driver or application sends it. There are many ways to communicate with it - your device could present multiple interfaces (which will appear as separate devices), multiple endpoints, or use the control channel. You will definitely need to study the spec, and I also found this tutorial helpful.
I have done something similar and used the control channel to exchange feature data with a Windows application (over the standard Windows driver). On Windows, the API calls are HidD_SetFeature() and HidD_GetFeature().
On the device side, my hardware ran embedded Linux and I used the GadgetFS library to create a user-mode driver - much easier to debug than a kernel driver.
As others have said, you'll run into issues if you try this with a normal HID. However, there is a project called the USB Rubber Ducky. From their description:
The USB Rubber Ducky isn't your ordinary HID (Human Interface Device).
Coupled with a powerful 60 MHz 32-bit processor and a simple scripting language
The USB Rubber Ducky looks like a usb-device and is recognized as a HID, but is programmable. You can make a small script that will be typed onto the screen which will allow you to performs the queries you seek.
With the USB Rubber Ducky you can:
Read data from a form on the screen? Yes
Find out what OS the user is on? Yes
Find out if there's been an error message? Yes
Even 'know' what's going on visually on the screen, i.e. what program is selected or whether the program is windowed or fullscreen? Yes
If you aren't hoping to buy this device, at least their firmware is on github so it can provide you a starting point
I have an embedded Linux 3.10.17 system running a Qt Quick 5.2.1 application. It has a graphical UI that can be controlled by plugging in a USB keyboard. What I would like to do is to control the application remotely via a remote desktop connection to a Windows PC sitting next to the embedded system. Currently any STDIO is not sent in as keyboard events to the Qt application. Three ideas came to mind
Modify Qt application to take in STDIO data so it acts on those events. I thought this would be a common thing to do, but so far my searches has not yielded any good solutions.
Create a Linux kernel driver that sends any keycodes received through a char device write (pipe) through the input subsystem. Something like this should be available I'd think...
Buy some form device that plugs into the embedded system via USB and connects to the PC via USB, RS232 or Ethernet.
I'm not sure which path offers the least resistance. Any expert advice on this would be appreciated
Thanks,
Otto
I have some starter kit board based on Atmel ARM926 400MH. Powered by linux.
And I need to control power of USB, i.e. switch it off and switch it off.
I try to research for use sysfs, but there is no information about switching on/off.
You either can’t control USB power, or the OS will control it for you. As noted in this comment, “... users shouldn't be conscious of this layer.”
Port power might be hardwired to be always present, but more often hardware allows control by the driver. One example I’ve seen, host port through a 3320 USB PHY should have port power automatically enabled by CPEN output.
This area was enhanced with runtime power management framework introduced in 2.6.32 kernel. Details can depend on SoC and specific board support. New features can allow user space control to prevent auto suspend and resulting powerdown; otherwise, by default, USB should power down in suspend modes.
Lots more info in Regupathy.