Is there a generic way to access device specific functionality from within the MBED development stack or am I S.O.O.L and need to go to a lower level tool chain? (want to use the integrated op-amps of the STM32F303RE device)
You can just use the STM32 HAL functions like you'd normally do. Mbed OS wraps around these. Note that these functions are not guaranteed to be thread safe (unlike the Mbed HAL).
I need to control a measurement instrument from within GNU Octave. The instrument has an USB HID interface. I just need to read or change the settings of the instrument. It's not about getting measurement data from the instrument.
What options are there to do this from within GNU Octave, and how do they work?
The simplest approach would be to use an already made Octave package (like the instrument-control package). Then you could check the documentation and read /write to and from a USB device.
The package linked above (and here again) has a USB TMC set of functions if the USB device works with this library. See the function list to find out how to use the package. As far as I am aware this package only works on Linux for USBTMC (according to the wiki).
Otherwise if you are not running Linux, or the device is not supported, I cannot specifically see any other already-written set of Octave functions for communication.
However, if you have the time it could be worth writing just a singular MEX (C/C++) function to open the communication channel and read settings from the device.
You could then make this work on Windows as well. Most of this functionality is already implemented in libraries such as signal11 (just to name one...), which that library itself is already cross-platform. Using that library inparticular makes it look like a very short MEX file to write.
I hope this helps and check out the links for further information about the topics discussed :)
I want to try and make my own application for my Novation Nocturn, which is a USB DJ controller surface. The application software interacts with it to send out MIDI messages to software like Traktor, Ableton and Cubase.
I'm aware of libusb, but that's as far as I've got. I've successfully installed it to interact with my device but stopped there.
I'm after some suitable reading material basically. USB specs, MIDI specs and such. If I'm honest the full USB 2.0 spec looks like it holds loads of stuff I don't need.
Just looking for something interesting to do now that I've finished my degree (Computer Science). My current programming knowledge is C++ and mainly C#.
Could do with some direction on how to get stuck into this task.
edit:
Update to include some info from the Device Manager on the Nocturn.
Hardware IDs:
USB\VID_1235&PID_000A&REV_0009
USB\VID_1235&PID_000A
Compatible IDs:
USB\Class_FF&SubClass_00&Prot_00
USB\Class_FF&SubClass_00
USB\Class_FF
Device Class:
MEDIA
USB MIDI is probably one abstraction layer lower than you want to deal with. I'd suggest finding a good MIDI framework and interacting with the device via MIDI instead.
For C++, Juce is probably the way to go, as you didn't mention a target platform or any other specific requirements.
If you want to go the .NET route, the easiest way to get started is with the C# MIDI Toolkit code:
http://www.codeproject.com/KB/audio-video/MIDIToolkit.aspx
In there, you'll find all the basics for opening an device, reading input, and writing output. Alternatively, NAudio has some MIDI classes, but they are somewhat incomplete.
As you develop, you'll want a reference for the MIDI spec handy.
A tool that you will find invaluable is MIDI-OX. In fact, I suggest that before you start coding, you fire up MIDI-OX and use it to sniff the messages coming from the Novation. It will give you a good idea of what the Novation sends. You can use it in conjunction with MIDI Yoke (a configurable virtual MIDI port) to insert itself between the Novation, and Ableton Live (or whatever software you normally use with your Novation) so you can see all of the messages in normal use.
Done... Kidding, but I've started on this in Python - I personally want linux support. I am teaching myself python, but I only dabble in programming.
You can see basic functionality at https://github.com/dewert/nocturn-linux-midi. The guy who reverse engineered it (i.e. the leap I wouldn't have been able to make myself) doesn't seem to be doing any more with it. His code is at https://github.com/timoahummel/nocturn-game
I am using PyPortMIDI and PyUSB, both of which I believe are wrappers for the C equivalents. I think this is all ok on Windows, but haven't tried.
What is currently on my github is crap, but it is proof-of-concept. I'm working on doing it properly now, with threading and proper configuration options.
The driver for the Nocturn makes it appear to system as a MIDI device, even though it isn't a USB MIDI device at the hardware level. The Automap software works entirely at the MIDI level, receiving MIDI instructions and sending different instructions in response - it is separate from the driver and not neccesary.
Alternatively, look at https://github.com/timoahummel/nocturn-game for an example of talking to it directly over USB from Python. You can probably port this to another language with libusb bindings.
Old thread, but I've just recently started looking into this.
I had a look at the Python application that dewert has written. Interestingly, it turns out that the data that the Nocturn emits is in fact MIDI, although it doesn't register itself as a USB MIDI device.
But looking at the actual data coming from the device, it actually emits control change messages (0xB0 controller value) for everything. Also the control commands that are sent to it are also control change messages, albeit only the data bytes, as the Nocturn seems to support MIDI running status (i.e. when sending multiple control change messages, it is not necessary to repeat the data byte).
Indeed, the looking at the magical initialization data it is actually just a bunch of control changes: it starts with 0xb0 and from there on the data comes in twos. For instance the last two bytes in the init string are 0x7f 0x00 which simply turn off the LED for the rightmost forward button. (There is something subtle happening as a result of the initialization being sent though, as the Nocturn sometimes emits some messages which appear to be some form of timeout events, and that behavior changes depending on whether the initialization string has been sent or not.)
Using MIDI-like messages makes sense, as Novation would be well aware of the MIDI protocol, so it would be easiest for them to use it for the communication even if the device is not strictly a MIDI device.
Note though that the incrementors just send the values 1 or 127, i.e. +1 or -1 step, so even with some trivial mapping software it's not really useful as it is. (Actually, if turned quickly, one can get 3 or 125 for instance, with the 125 corresponding to -3.) The only controller which sends a continuous value is the slider, which emits an 8 bit value when moved.
I suppose you'll want to know about USB classes in general and USB MIDI class in particular. The latter is the best what you can hope for in case you don't posess documentation for some proprietary protocol (whether it's used there instead).
I'm trying to write something that will allow a user to use a keyboard/mouse combination on a games console. The approach I've thought of is to do the following:
Figure out how input maps to output in the console's controller. This is good old trial and error, basically connecting the controller via USB to a computer and figuring out how the controller responds to input using detailed USB logging.
Then, write a userland program that takes keyboard/mouse input and converts it to the controller's output.
So far so good. Now comes the complicated bit. I need to figure out a way to connect my computer to the console, while making the console think that what is actually being connected is a standard controller. For this, I will need a way to create a fake USB device, which communicates over a USB port to the console. This is the part that I have no idea whatsoever how to do.
I guess I'm looking for a USB spoofing library of some sort, but I'm not sure where to start looking for something like this. Python bindings for the library would be great, but I'm not fussy. Similarly, something that works on Mac or Linux would be perfect, but I could live with a Windows-only library in a pinch.
USB doesn't work this way. USB involves a directed hierarchy of devices, and trying to connect two host devices (your computer and a console) will only result in bad things happen (like destroying the USB controllers in both devices).
Probably the best thing to do would be to use some sort of embedded processor like an Arduino to sit between your keyboard/mouse and the console to do the conversion.
I want to develop a USB host on an embedded device that will talk to printers from various vendors. Drivers for the vendor specific printers would be available on PC which is ultimately communicating with printer but my device is facilitating this communication and needs to perform the basic handshaking/setup of the printer (i.e, it needs to know when the printer is connected, what are the socket IDs that needs to be opened for CTRL and DATA transmissions etc). All of these printers are supposed to comply with IEEE 1284.4 standards but I see that many of them vary quiet a bit.
One approach I have is to take the USB traces of handshaking from each of these printers and write various sections of code respectively (I know, that sounds ridiculous!). Is there a generic way to do this? Is there any available forum where these standard informations are mentioned? For eg: EPSON uses 'EPSON-CTRL' and 'EPSON-DATA' for its control and data services which needs to be provided to get the socket ID for these services. I am pretty sure HPs, Canon's etc would have their own service names as well. As per the standards, this was supposed to be captured in IANA but I dont see anything there. Any help on this would be greatly appreciated.
Thanks and regards,
Ullas
No, you can't do this because EPSON and HP will implement their printers differently even if they do the exact same thing. Your "generic" driver will have to explicitly account for each type of printer.
That being said, you could theoretically implement each driver type in your generic driver suite and have it determine which driver to use when the printer becomes available. But, this seems like a bit of overkill since you can just get the drivers free online at the manufacturer's website.