I'm working on a project that involves data transfer from a host PC to the ngx Xplorer 433x microcontroller evaluation board which has a NXP - LPC 4330 uC on it.
I have read and seen that the USB Communication Class Device has interface descriptors for communication and bulk data transfer.
So far I can send commands/files via hyperterminal (TeraTerm) but the throughput is about 32kbit/s, so apparently the transfer is being done via the communication class interface descriptor. The goal should be to achieve a speed of about 10mbit/s or more and ideally it should be controled over a command window (and later a nice GUI).
So far I have been looking for example code on bulk data transfer on USB without any luck, all I found were some odd Microsoft examples that require Win8,VS2013,etc.
Basically what I'm looking is something like:
data[<some big number>] = "<many letters and stuff>";
port_send(COM8,data);
// end
I would greatly appreciate any link, tutorial, pdf, code snipped that could get me further.
Related
I am looking for a piece of software, or assistance with where to start for coding, that will let you select a USB device and convert its output signals (when buttons are pressed on the device) into keystrokes or configurable macros.
In more detail, I have this remote control (more accurately, a USB handset/phone) that sends USB signals depending on which button is pressed and the software I currently use converts those signals into keystrokes or macros. The software I currently use however is extremely limited, non-configurable and obsolete. The software which I retrieved from the CD that the device came in is simply named 'USBPhone 5 in 1' however there is no mention of this anywhere on the internet.
The device is unfortunately unbranded and also has very little visibility on the internet so I cannot see if there's any updated software or even any way to edit it.
Any help is greatly appreciated!
I think you need to start by getting basic understanding of the USB standard and device classes. Then you need to find out if your device implements a specific device class or some proprietary interfaces. Then you will either need to use a driver for the device class or implement a proprietary driver.
While USB is abbreviation from Universal Serial Bus, it is not transferring some random analogue data but well defined digital packets. The standard defines Audio Class for audio devices, Video class for video devices etc. Most devices implement one or more of those classes. For keyboards and mouse it defines HID class, which is most likely what your device implements. You can find HID device class related specifications here. It is not the most simple one to begin with, but it should work when you just plug the device to your PC and open e.g. notepad and start writing. USB device class codes are listed here.
In order to find out what device class your device implements, you need to read it's descriptors. In Windows one of the easier ways is to use usbview. You can read more about USB decriptors from here.
You do not mention what is your USB host (Windows or Linux PC, Mac or something else), so I am not going to go into actual USB driver implementation, but hopefully I was able to give you some information on what could be needed. In any case, if the device has some proprietary implementation, you will either need to have specification for it, or reverse engineer it by monitoring the USB packets. There are lots of expensive hardware solutions on the market for analyzing the USB traffic, but there are also some free SW solutions that might be good enough for your purpose. Quick Googling brought up this.
You can try joyToKey, this software do exactly what you want but with gamedpad. I don't know if it will work well with your USB controller.
http://joytokey.net/en/
So I am in a bit of a dilemma, I want to create a LED dashboard using my Raspberry Pi, the only problem is how am I going to read the data to the Raspberry Pi using C++? I am thinking about buying an OBD to USB connector and reading the data from there, but it still doesn't change the fact that I would need parse the data, but the only library I found for OBD on C++ is https://github.com/lkrasner/obd-cxx but it does not look promising.
So this is where I turn to the Stack Overflow community to help me out because I have run out of options.
Can the OBD data be read as serial? If it was serial, wouldn't that be too slow for a real-time speedometer? Should I use another port instead of OBD?
I have quickly searched and found this topic: http://blog.lemberg.co.uk/how-guide-obdii-reader-app-development
It is not usb, but it tels about AT commands to communicate with the adaptor. Thus, I would assume the USB one will be visible as a serial interface with the same communication principle. Then you might not need a library, as you can directly read-write your serial device.
Make sure only, that the adaptor you're gonna buy supports the communication protocol of your car (CAN or another). Perhaps also one option to think about is whether the adaptor provides high-level commands for you (then you need to check that the required diagnostics services are supported by the adaptor), or you need to build/parse the raw diagnostic messages yourself (I think this would be more flexible solution).
I'm currently specing out projects for my graphics class and I am thinking of writing an application that displays a visualizer for midi data. What I would like to do is sniff midi data as it passes through the system. I do not want to hijack a driver, only watch the data go by (that is, I want the MIDI data to later be accessible by a DAW). I am not familiar with programatically accessing midi in windows. The closest I could find to what I want seems to be midi spy. However I would prefer to write the app in c/c++.
I was looking at MIDI Stream API, but I can't tell if I'll be able to sniff devices that weren't opened by the library. I was also looking at SDL Mixer and QT Midi. I'm just trying to get some personal pros and cons to the options that I've presented or ones that I haven't found.
Unfortunately, there is no way to actually sniff MIDI streams under Windows. All you can do is place your application between the two MIDI devices.
Unless you are putting software between physical in/out ports, you will need to set up a virtual MIDI loopback driver that directs the MIDI stream data from an input to an output. Fortunately, there are a few off-the-shelf solutions already. The easiest method is to require your users to set up a virtual MIDI port and configure it on their own. LoopBe1 and MIDI Yoke are free.
Another method is to use a virtual MIDI driver that goes directly to your application. Tobias Erichsen has created a very easy-to-use driver for this very purpose. I don't believe he has released it yet, but if you shoot him an e-mail, he might get back to you. See this question: DDK "Hello World"
I wanted to get some ideas one how some of you would approach this problem.
I've got a robot, that is running linux and uses a webcam (with a v4l2 driver) as one of its sensors. I've written a control panel with gtkmm. Both the server and client are written in C++. The server is the robot, client is the "control panel". The image analysis is happening on the robot, and I'd like to stream back the video from the camera to the control panel for two reasons:
A) for fun
B) to overlay image analysis results
So my question is, what are some good ways to stream video from the webcam to the control panel as well as giving priority to the robot code to process it? I'm not interested it writing my own video compression scheme and putting it through the existing networking port, a new network port (dedicated to video data) would be best I think. The second part of the problem is how do I display video in gtkmm? The video data arrives asynchronously and I don't have control over main() in gtkmm so I think that would be tricky.
I'm open to using things like vlc, gstreamer or any other general compression libraries I don't know about.
thanks!
EDIT:
The robot has a 1GHz processor, running a desktop like version of linux, but no X11.
Gstreamer solves nearly all of this for you, with very little effort, and also integrates nicely with the Glib event system. GStreamer includes V4L source plugins, gtk+ output widgets, various filters to resize / encode / decode the video, and best of all, network sink and sources to move the data between machines.
For prototype, you can use the 'gst-launch' tool to assemble video pipelines and test them, then it's fairly simply to create pipelines programatically in your code. Search for 'GStreamer network streaming' to see examples of people doing this with webcams and the like.
I'm not sure about the actual technologies used, but this can end up being a huge synchronization ***** if you want to avoid dropped frames. I was streaming a video to a file and network at the same time. What I eventually ended up doing was using a big circular buffer with three pointers: one write and two read. There were three control threads (and some additional encoding threads): one writing to the buffer which would pause if it reached a point in the buffer not read by both of the others, and two reader threads that would read from the buffer and write to the file/network (and pause if they got ahead of the producer). Since everything was written and read as frames, sync overhead could be kept to a minimum.
My producer was a transcoder (from another file source), but in your case, you may want the camera to produce whole frames in whatever format it normally does and only do the transcoding (with something like ffmpeg) for the server, while the robot processes the image.
Your problem is a bit more complex, though, since the robot needs real-time feedback so can't pause and wait for the streaming server to catch up. So you might want to get frames to the control system as fast as possible and buffer some up in a circular buffer separately for streaming to the "control panel". Certain codecs handle dropped frames better than others, so if the network gets behind you can start overwriting frames at the end of the buffer (taking care they're not being read).
When you say 'a new video port' and then start talking about vlc/gstreaming i'm finding it hard to work out what you want. Obviously these software packages will assist in streaming and compressing via a number of protocols but clearly you'll need a 'network port' not a 'video port' to send the stream.
If what you really mean is sending display output via wireless video/tv feed that's another matter, however you'll need advice from hardware experts rather than software experts on that.
Moving on. I've done plenty of streaming over MMS/UDP protocols and vlc handles it very well (as server and client). However it's designed for desktops and may not be as lightweight as you want. Something like gstreamer, mencoder or ffmpeg on the over hand is going to be better I think. What kind of CPU does the robot have? You'll need a bit of grunt if you're planning real-time compression.
On the client side I think you'll find a number of widgets to handle video in GTK. I would look into that before worrying about interface details.
I want to develop code to transmit data from system to PIC through USB.
Can anybody give good link regarding data transmission through USB.
because i am new to this.
NOTE: Very simple is code is enough to me.
Thanks in Advance
The PIC16F877 does not have a USB peripheral built in. I assume that the product that you are building is a "USB Device" and that the "system" that you are referring to will provide the USB host functionality. If this is the case then you will have to add a USB interface chip to your hardware to provide async serial to USB connectivity. Suitable devices are made by TI (TUSB series) or FTDI. You then connect one of these to the PIC internal USART and pretend that you are transferring the data over a simple serial port. If you are using a pc then the connected device will appear as a standard COMn: port.
I totally agree with the FTDI route, however if you're not looking for a UART tunnel over USB then you have to get a bit more in-depth.
You'll have to write the USB routines yourself or find libraries/projects for your processor. What you will definitely have to have is a fast clock - 12MHz is necessary More is better because on small uC's like these you'll spend most of your time just handling the basics of USB - signaling and so forth. You'll also need a fair bit of memory because the USB code takes up around 1.5K I think. Then you need room afterwards for your own code.
I've seen the V-USB (http://www.obdev.at/products/vusb/index.html). It's for AVR not PIC, but it says it provides all of the USB functionality you'll need and even provides vendor and product IDs for you to use (non-commercial I believe). There's also a PIC project for USB that doesn't run on the same hardware as yours here: http://www.alanmacek.com/usb/
To make the driver you'll have to use libusb - here's a link for the win32 version: http://libusb-win32.sourceforge.net/
It's surprisingly more simple than I had expected, but I just looked at example code and not actually made anything. Good luck!
As your task will involve Windows Device Driver development, I do recommend to downlaod and install the WDK and look through the contained sample USB drivers.
This might get you some hints about the complexity of the topic. Device driver development is not the easiest thing to start with.
Maybe you can start with UART communication (RS232).
check http://www.beyondlogic.org/usbnutshell/pic16f876.gif will surely help u
also
ttp://www.beyondlogic.org/usbnutshell/usb7.htm , type h in front of 2nd link.