I salvaged a CC2640 out of Bluetooth keyboard. I desoldered it in a attempt to reuse it. Can it be transformed to a USB Dongle adapter in any way? I'm doing this for knowledge, not for the outcome (It may be easier or cheaper to buy one, still want to do it)
you have to reprogram the flash (http://www.ti.com/lit/an/spraal3/spraal3.pdf). for this you can use SmartRF Flash Programmer and you need access to the pins of debug port (JTAG) or serial port (UART) and possibly there is a lock (fuse set). the OEMs often set locks to ensure that nobody reads out the code with what they programmed their devices ... if you get access to the flash of the CC2640 you can reuse it. as the CC2640 has no USB port you can only make an USB dongle of it with an external chip i.e. a FTDI chip (connect the serial port of the FTDI with the serial port of the CC2640...)
Related
A method to Connect / Disconnect a USB device "softly".
Hey, Assume I have a USB device connected to my PC, I want to enable/disable the port it is connected via computer so that I don't have to unplug/plug my device each time.
P.S : Device is a Microcontroller Board ( powered by USB port ) , so I don't want it to be active all the time. I want to deactivate it when appyling changes to code etc. and then activate that port so I can load my code into it again.
Is there a method to do so ?
Thanks in advance.
Device is a Microcontroller Board ( powered by USB port )
Most USB enabled µC types can "unplug" themself.
The idea is to put the USB data pins (usually called D+ and D-) into "output low" state for about one second at startup. This forces USB to be recognized as "disconnected".
After that is done, re-configure the pins to for their USB function and initialze the USB as usual.
Note that this method is not possible on old style boards that still use USB2UART chips instead of hardware USB inside the µC itself.
I've got usb cable plugged to my computer, which D+ and D- pins are connected to multimeter. I want to send some raw bytes to get some voltage.. is it possible at all?
I'm 99% sure that usb port I've plugged cable in is something like /dev/bus/usb/002
I know that there was possibility to do the same with LPT or RS232 ports.
RS232 and LPT are not bus ! USB devices need to be addressed in order to become reachable.
Maybe unloading and reloading usb driver that drive your usb host... or trying to make a reset on usb hub host...
For doing this kind of operation on usb port, you have to break usb kernel driver and whipe all addressing operation to address directly the chipset...
At all, due to USB concept, I'm not sure you may successfully hold some power state on outlet.
For playing with that kind of physical IO, two solution:
Install a low-cost RS-232 <-> USB adapter
or better
Buy an Arduino micro-controller for prototyping and development.
I'm nearly 100% sure that you can't send anything down your USB lead unless you actually have a device at the other end. If you still want to play with this, get a cheap memory stick, break the casing off it [not too roughly], and measure whilst doing a large file-transfer to the memory stick, or some such.
But I'm not sure your multimeter will show much, as they tend to be a bit slow, compared to USB rates.
USB uses pull-up / pull-down resistors on the data lines to detect whether or not a port is connected (1.5k pull-up to 3.3v on the device side, 15k pull-down on the host side IIRC). The exact connection depends on the device speed.
So if you connect an appropriate resistor, the host should attempt to start signalling. Because of the data-rate, you might not be able to see that on a multimeter; an oscilloscope would be more appropriate.
If you want to by-pass the normal USB protocol and just blindly send data, I think you'll need to get your hands dirty and write code to bypass the usual device drivers and access the USB hardware directly. Even then I'm not sure what's possible - the USB hardware is a lot smarter than good ol' LPT and RS232 ports, which might get in the way of doing this sort of low level stuff.
I have been asked to figure out how to achieve bluetooth communication through an off-the-shelf dongle (in this case a dongle utilizing the Broadcom BCM2045 chip) using the FTDI Vinculum 2 (VNC2) USB controller. I have custom firmware written for the VNC2 to communicate with a generic USB device with the VNC2 acting as the host, and I can successfully read the VID and PID from the dongle as well as the USB device class, subclass, and protocol. I can also send data to the dongle using the bulk data endpoint and I believe the device is receiving though I have no way to tell at the moment.
So I believe I can communicate with the dongle, the problem is I have no idea WHAT to communicate to it in order to set it up in discoverable mode or to pair it with another discoverable device, nor how to actually transmit data through the wireless link once it is paired. I don't even know if there exists a standard communication protocol for this type of thing or if every device will be different. I have a vague understanding of the bluetooth protocol stack and it is my understanding that I won't be required to fully understand that as it should be implemented in the dongle on one end and in the android smartphone that we hope to connect to on the other end. Like I said, I can currently send data to the bulk endpoint, is it true that this endpoint is only for data transfer over the wireless link and I will need to connect to a different endpoint in order to send setup/configuration messages to the dongle?
In short, I need to know what data to send over the USB bus to control any generic bluetooth dongle if possible or at least one specific bluetooth dongle. I have a USB port sniffer but the complexity of the output while using the dongle to communicate is staggering and I doubt I'll ever figure it out.
Thank you in advance.
Bluetooth dongles communicate with host software stack using HCI (host control interface), which is defined in the Bluetooth spec. For reference, you can look at source code for the open source BlueZ stack (standard linux stack). You could run BlueZ on linux talking to your USB dongle, and use hcidump to capture actual packets going across HCI. You can also check out hcitool and hciconfig for performing specific actions.
I bought one of those tiny bluetooth USB dongles that you can plug on a PC and make bluetooth communications. I am wondering if I just plug this dongle to a USB power source, like the USB charger that comes with iPad, can the bluetooth dongle power up, and be discovered as a bluetooth device? This sounds reasonable, since the bluetooth dongle should be able to broadcast itself, at least using some low-level protocol, i.e. showing its Mac address.
However, I tried to do the following:
1.Plug the bluetooth dongle on my iPad's usb charger
2.Search bluetooth devices on my laptop
and I could not find it. Is it because the bluetooth dongle needs the PC to initialize it, so that it can be discovered? Or I am not doing it right?
Thanks
It depend on the dongle
Typical PC dongles depends on the host (pc) to initialize and start any bluetooth activity - including scanning etc
It is practically possible to make dongles that can start becoming discoverable without waiting for host initialization. This has to be a custom build
I have a Linux virtual machine running on VMWare Fusion (on Mac OS X) that I intend to use as a development environment for an embedded system. Would it be possible for my Linux VM to talk to my embedded system's serial port using a USB-to-serial adapter? Any recommendations for what sort of adapter I should get?
There are two ways to do it:
Your host-OS supports your USB<->serial converter (very likely). If so you can just allow your VM to talk to the serial port. If so the VM will see a standard serial port and everything will be fine.
Your guest-os in the VM supports the USB<->serial converter, AND your host-OS allows raw USB forwarding.
All in all the chances are good that it works..
Btw: there are good and bad USB<->Serial converters. If you find out that the serial connection seems to work (everything detects/works as expected for a couple of seconds), but you can't get a reliable connection for a longer time, then it's very possible that the usb<->serial dongle sucks....
You get what you pay for... When buying these things I'd check comp.arch.embedded and ask which usb dongles are known to just work, and which not. (My recommendation is to stick with products from Assmann. You can order them at digikey).
I've found USB serial adaptors to be a bit hit & miss with embedded work. One thing to be aware of is that the buffering tends to work differently from "real" serial ports, and latency of characters through the system can be quite variable. Some embedded development systems (think bootloaders, cheap JTAG probes etc) can be quite sensitive to this and will give timeouts and so on.
Note this doesn't only apply to USB serial adaptors, I've had similar problems with high end multi-port serial cards, but usually with those you can tweak the FIFO / IRQ settings to get something working.
I have experienced that a USB to serial adapter with a FTDI chipset and drivers is more reliable and compatible with more devices than the Prolific chipset
Depends upon the VM software, but VMWare Fusion does support USB devices. The question becomes, does your IDE support talking to a USB device instead of an old-fashioned serial port? With Linux, probably yes.
I had no problems whit serial adapters from ATEN.
USB serial adapter is USB standard device (just like mass storage) that mean that any USB compliant adapter should work.
pl2303: I have found this device to be very reliable and are often in the generic and cheap USB to RS232 adapters. I've seen expensive adapters fail and my generic adapter from geeks.com work great.
I just picked up a USB 1.1 - RS232 adapter (Digitus DA-70119) from WeirdStuff for 10 bucks. I plugged it into my Mac mini and VMWare Fusion showed me this.
Once I clicked on the USB icon, my Ubuntu 9.10 VM had no trouble seeing it
$ lsusb
Bus 002 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
$ dmesg
usb 2-1: new full speed USB device using uhci_hcd and address 4
usb 2-1: configuration #1 chosen from 1 choice
pl2303 2-1:1.0: pl2303 converter detected
usb 2-1: pl2303 converter now attached to ttyUSB0
I can now use /dev/ttyUSB0 in my Linux VM to talk to my target system.