how can i know that the connected device is class complaint for MIDI
(Ex; for a yamaha keyboard)
(i'm trying to connect arduino directly to a usb midi keyboard)
in linux you can use lsusb -v the device class is in the bDeviceClass field. if it says 0 (Defined at Interface level) see the bInterfaceClass fields. MIDI devices have their own USB class cf. http://www.usb.org/developers/docs/devclass_docs/midi10.pdf
on your arduino has to run a kernel module- / driver-like program that enables communication with the USB midi device, because this communication is standardized ( http://www.beyondlogic.org/usbnutshell/usb1.shtml )
on windows you can use tools like USBView to get the information about the USB class ... https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/usbview
Related
I have a usb midi effect processor that receives midi messages is there any way I can send midi messages over usb from a qt application is there a library for midi ports ?
You can use RtMIDI to do that, which is C++ and can be used with Qt. As an alternative, I've published some open source libraries under the generic name "drumstick" for MIDI processing following Qt5 style and dependency. Some functionalities are multiplatform (Linux, macOS and Windows) like "drumstick-rt", which allows a Qt program to send realtime MIDI events to arbitrary MIDI outputs (USB MIDI devices or whatever). It is used for instance by my program VMPK. Please see the online documentation.
I trying to flash using the internal bootloader(system memory) of stm32L073Rz nucleo board. I have read the documents AN2606, AN3155 and set the BOOT0 pin=1.By default USART2 on nucleo board is accessible by stlink interface and the same USART2 is used by the bootloader to listen for data, I using GTK term in ubuntu to connect via /dev/ttyAMC0(USART2) but unable to receive an ACK from the device, as mentioned in AN3155 I am sending 0X7F to the device. is this procedure works or are there any better alternatives to communicate with the bootloader?
It sounds like you're trying to load your program via the target MCU's internal bootloader via UART2. Is that right? To do that you may have to disconnect the board's default connection between the target's UART2 and the integrated ST-Link MCU (i.e., you'll be bypassing the ST-Link MCU). See the UART Communication section in the board's User Manual (UM1724) and this excerpt.
The USART2 interface available on PA2 and PA3 of the STM32
microcontroller can be connected to ST-LINK MCU, ST morpho connector
or to Arduino connector. The choice can be changed by setting the
related solder bridges. By default the USART2 communication between
the target STM32 and ST-LINK MCU is enabled, in order to support
virtual COM port for Mbed™ (SB13 and SB14 ON, SB62 and SB63 OFF). If
the communication between the target STM32 PA2 (D1) or PA3 (D0) and
shield or extension board is required, SB62 and SB63 should be ON,
SB13 and SB14 should be OFF.
However, typically one would simply program the target MCU using the integrated ST-Link/V2-1. This is how the board is configured by default. In other words, it's not necessary to use the internal bootloader because this board has an intergrated ST-Link, which is easier to use.
I have a hardware device that controls LEDs on a panel, and it has a serial port for a PC to control the LEDs.
I would like to be able to control the LEDs from a userspace application using the Linux LED class API, i.e. via /sys/class/leds/whatever/brightness. So I'd like to make a Linux kernel driver for this device.
However, from what I've read, it seems unusual for a Linux kernel driver to open a serial device. E.g. StackOverflow question Accessing a serial port from a linux kernel module. I've read about filp_open() which can be used by kernel drivers to open device files, but its use seems to be discouraged.
On the other hand, it seems impossible to implement this in userspace because I'm not aware of a way to create a Linux LED class device from userspace.
What would be a good way to provide a Linux LED class API interface to a serial port controlled LED device?
Disregard the cautions against accessing a serial port from a Linux driver using filp_open()?
Is there some userspace way to create a Linux LED class device, so I could implement this in userspace?
Give up on the idea of using the Linux LEDs class API, and use an alternative API for the userspace application to control the LEDs?
Other?
Custom tty line discipline driver
As far as I can tell, one way to do this in Linux would be to write a custom tty line discipline kernel driver that implements the Linux LED API and sends the commands to the serial port. Then the Linux LED code can be in a kernel driver, but it's not tied to a specific serial port.
Then, to link it to a particular serial port, a userspace program would open the serial port, and use an ioctl(serial_fd, TIOCSETD, ...) call to attach the serial port to the custom line discipline driver. The line discipline driver does all the work from that point. The userspace program's only purpose is really to associate the custom line discipline driver with the right serial device.
Pseudo-driver using FUSE filesystem
One alternative would be to write a userspace program that is a "pseudo-driver", that connects to the serial device, and provides an LED API resembling the Linux kernel LED class API, but at a different location, using a FUSE filesystem.
For example, the program might be named foo-serial-leds and it could provide a number of LEDs under /var/run/foo-serial-leds/ with an API resembling the Linux kernel LED class drivers.
Then another program could control the LEDs by writing to e.g. /var/run/foo-serial-leds/status/brightness. That would be very similar to the program controlling a real Linux kernel LED class at /sys/class/leds/status/brightness, except the location on the filesystem is different. That program would be portable to another platform, with different LED devices, as long as the program has a configurable filesystem path for the LEDs it wants to control.
Two disadvantages of this:
The program that wants to control the LED must be flexible enough to access the LED file API in a different location than the normal /sys/class/leds/
These pseudo-driver LEDs can't use Linux kernel LED triggers
Custom driver to allow userspace creation of LED devices
Another option would be to write a Linux kernel driver that allows for userspace programs to create LED devices in the Linux kernel LED class. The driver could use configfs to allow userspace programs to create the LED devices, which would then appear under /sys/class/leds/. It would need to provide a way to notify the userspace program when the LED brightness is changed (maybe via sysfs_notify() on a custom sysfs attribute, which the userspace program can poll()).
With that driver in place, a userspace program could implement the LED API and write to the serial device to achieve the LED control. This program is kind of a userspace driver. I.e. it would use the Linux driver to create one or more LED-class LEDs, and open the serial port to talk to the LED hardware. When it is notified that something has written to the LED brightness, it would need to send the relevant command to the serial device.
Then other userspace programs that want to control LEDs would be able to write to the LED-class API in the usual location under /sys/class/leds/.
Linux kernel 4.10 userspace LED class driver
Update November 2017: Linux kernel 4.10 adds a userspace LED class driver, uleds. It implements something like what is described above. However, control is via a device /dev/uleds, not via configfs.
An app should open the char device file /dev/uleds once for each user LED it wants to create. It should write a struct to the file, which specifies the name of the LED. Then it should do reads from the open file handle, and will receive an int which specifies the brightness of the LED whenever that LED's brightness is changed by something else in the system. If multiple LEDs are to be created, the app should open the char device file multiple times, once for each LED.
When the app closes, and the open file handle(s) to /dev/uleds is closed, then the user LED is automatically removed.
3 Ways:
1 - You must to understand the data send to CPU Board for modify as you want data for display your message on led board.
2 - You must to have a linux API, but most of time the CPU is made in china, the chinese don't like linux.
3 - You write your own API for control LED Board with arduino or raspberry to control each pins of your LED Board.
Good luck !
I have a device connected to USB port via USB cable to my PC and in device Manager it says - > "XYZ corp Virtual COM port (COM A)"
Is this is same as Serial Com Port.?What is the underlying hardware under it both at device side and Host Side - a Uart or a USB or both at either end respectively?
It sounds like your USB device uses a driver that provides a serial port interface inside your computer. This means that other software can use the serial port APIs that Windows provides to connect to it and use it as a serial port. That software doesn't need to know the details of your USB device; it just needs to know about using serial ports in Windows. Windows ships with a driver that is often used to do this, and that driver is named usbser.sys. Your device might be using usbser.sys or it might be using some other driver.
The serial data is transferred via your computer's USB port and a USB cable. If you look at the signals on the USB cable, you will not see typical serial signals: you will see regular USB packets that just happen to be carrying that data needed for a serial port.
The USB device on the end of that cable might then translate that data into serial signals and act like a normal serial port, or that data might just be used directly inside the device. Without a link to the product in question, it is hard to tell you more than that.
I would like to use a standalone GSM Module that can interface with other systems like TV, AC, Fridge, etc.. via an SMS or a Call
For example:
1. If the GSM Module is hooked up to a Smoke Sensor, when there is an alert the GSM Module should be able to send as SMS.
I think there needs to a hardware component (that connects to the Smoke Sensor and GSM Module) where I can install program to send a SMS message when there is a signal from Smoke Sensor.
I would like to know on what this hardware component can be, what programming languages can be used and how the hardware component can interface with various devices.
Thanks!
An easy way to get a programmable GSM module is to get a cheap Android smart phone. For connectivity, you will need to build your own solutions unless the sensors already have some interface. You may want to look into Arduino microcontrollers for that. You can interface to the Android device using Wifi, Bluetooth, USB (newer devices support USB host mode, the cheap ones may not) or the audio jack.
Best solution depends on your resources and how many devices you need.
If you have big budget and hardware and software designers, then you could use naked GSM/UMTS module from some m2m module vendor like Cinterion or Telit. And own MCU for controlling it.
But if you need only few devices, then you could use some programmable GSM/UMTS terminal module, which contain all needed stuff: case, sim-holder, antenna connector, some GPIOs and modem.
For example Cinterion TC65T is this kind of terminal module. It can run a java (J2ME) program. Java programs of TC65T have access to GPIOs, which can be connected to smoke sensor for example. Java programs can also send SMS messages.
The Cinterion TC65T terminal was a 2G cellular device with a Java Virtual Machine to allow you to run J2ME 3.2 applications. Now days you could use a Terminal such as the Cinterion EHS6T-USB which is a 2G and 3G device with Java.
You might find it easier to get hold of a Cinterion "concept board" which has a Java enabled 2G and 3G cellular module on there along with an interface for Arduino style shields.
http://www.gemalto.com/m2m/development/cinterion-concept-board
It runs from a USB lead, plugged into you laptop or PC and need no other external power supply for development. I used one of these connected to a battery, and an Arduino relay board plugged in, to be able to switch our Christmas tree lights on and off via SMS.