I have to use the HC-06 bluetooth module (the one usually used for arduino projects) with a de0-nano altera fpga kit.
I really have no idea how to go about it. Am I suposed to treat the HC-06 as a simple serial port and just implement the UART communication? I have to develop a verilog design for it.
Apparently the communication with HC-06 and the FPGA must happen over a UART interface. so, go ahead and write some logic to implement UART on FPGA so the communication can take place. In the process of doing so, a lot of things will get clear for you.
Does this look like doYourHomeWork.com? lol I would start here.
They have some examples of connecting hc's to different systems, and it's only 16 pages with loads of pictures.
edit: Additionally this provides some great information about working with your hc chip in the context of arduino. As far as how things are done (enter at mode etc...) It explains nicely.
Related
I wonder whether it is possible to emulate a specific bluetooth device like a Remote Controller for a TV or another device with my PC. I'd be okay with installing an additional hardware device for my computer (e. g. a BlueTooth PCIe card).
I imagined something like "recording" all single commands of my original remote controller using my Bluetooth card and afterwards use these recorded commands to turn on my TV for example.
Is something like this possible (with additional hardware maybe)?
Of course this is possible. Bluetooth is just a protocol and you can impliment it in your custom software to emulate all kinds of devices. If you need to emulate simple devices like keyboard or mouse, there are many ready solutions like this.
But if you have non standard device, there won't be any ready solutions and you will have to implement it yourself. What can help you:
If you have some kind of controller for PC and you want to emulate device with unknown protocol, you can use WireShark or other sniffer to understand what's going on.
There is an emulator called BT-Sim, but it is so poorly documented that I can't even guess what it does.
You can can take as example different android software like described in answers to this question.
You can check different program samples for PC like this.
For hardware you need only simple Bluetooth dongle. However, if you want to spy on some BLE (Bluetooth Low Energy) devices, you can buy hardware sniffer like this.
(At least in Windows 10) Microsoft Store has an application called "Bluetooth LE Explorer" which is able to simulate different kind of Bluetooth GATT profiles as a peripheral.
People,
I have always seen references about how to use a SPI interface to operate a SD memory card.
This is not what I want. I need to do exactly the opposite.
I want to be able to use the SDIO controller (through SD slot) in my "host" (any PC having a SD-card interface) to talk to my devices (basically microcontrollers) that can only "speak" SPI.
If my understanding is not too wrong, I cannot simply tell my SD controller to talk in a raw SPI mode but I can teach my microcontrollers to behave as a SDIO device that can be controlled by my host.
This way I still have two challenges left:
Correctly implement a generic SDIO device in my microcontroller.
Implement/configure the correct drivers in the host to be able to interact with my devices.
Implement the SDIO device seems to be a matter of following the spec.
The host-side driver, though, is something I hope I can accomplish with a user-space driver in Linux using some already existing kernel-space driver to SDIO.
That's the point that I come to ask for help.
Can anyone please point me any samples, documents or any kind of resources that can help me in my task?
On the PC side, this is all you need: http://sourceforge.net/projects/sdio-linux/
This may be useful for reference: http://www.varsanofiev.com/inside/WritingLinuxSDIODrivers.htm (although, I don't think you would be writing a driver)
On the microcontroller side, use "bit-banging" to implement the SDIO spec.
However, first consider why do this. SDIO and SPI are just serial protocols, so is USB; wouldn't you rather make an SPI-to-USB bridge? USB is much more user-friendly on the host side, as well as being more standard/more common. And if you do want a SPI-to-USB bridge, turns out it already exists, the SPI Shortcut (probably other options, this is just the first one that comes to mind)
EDIT Or, you could bit-bang I2C on the micro, if the host supports I2C (many do). Actually, go through every serial protocol the host supports, and see if you can support it easily from the micro side (by bit banging, since the micro is likely to not have a slave mode for that protocol built-in). RS232 (with level shifter), I2C, and SPI are likely to be the preferred choices. SDIO is pretty much the last choice, I think.
SDIO is very tightly specified. Unless your microcontroller has an SDIO block that is designed to act as a device rather than host, I don't think this will be possible. I know of a few special purpose communications controllers that implement an SDIO device, but I haven't come across any general purpose microcontrollers.
You would need a fairly fast microcontroller to be able to bit-bang SDIO initialization at up to 400 kHz. If running an STM32F4 at 180 MHz, this gives you only microcontroller cycles between SDIO clock cycles. If the host turns up the clock speed to the maximum of 25 MHz after initialization, then you're down to 7 cycles between SDIO clocks.
For perspective on the SDIO spec, the one you linked is a simplified spec that doesn't cover the signalling and timing of the bus. The full spec is many times larger.
As Alex I mentioned, there may be better alternatives for what you need. If your SDIO host supports SPI mode, most microcontrollers do have SPI peripherals that can act as slaves rather than hosts, so this may be an avenue without a peripheral. If your data rates are low enough, a simple UART may suffice (you can reasonably hit 1 Mbit over short distances).
I've seen several references to this capability being available with Bluetooth 4.0/LE but I'm not sure where to start or how to implement it.
To be clear, I mean truly connectionless with only a receiver on one device and a transmitter on another. (or, more specifically a powerful transmitter on one device and a weak transmitter on the other, so the devices can be paired).
Something like the "Immediate Alert Service" sounds good, but is it too good to be true? It's difficult to tell over which layer a signal is 'connectionless'. Could anyone perhaps point to some documentation/implementation examples of this?
Take a look at the Core Spec V4.0 and do a search for "connectionless". There's details about using a connectionless L2CAP method.
I am working on a project where I need to attach a sensor to the computer like laser sensor or an infrared sensor, to use in a foul line detection. Basically the idea is, if someone steps on the foul line, the laser or infrared will be blocked by person's foot, and the laser/infrared won't be received by the receiver, causing the sensor to send a signal to the computer.
The problem is, I don't know where to start something like this. How would I go about attaching a sensor to a normal computer (like a normal PC that we use)? If someone could direct me into a direction or has any inputs, that would be really appreciated. Thanks a lot!
You may want to look at Arduino (http://www.arduino.cc/). It is an open-source microcontroller that can be used along with a computer and is designed to be hooked up to various types of sensors. It also has an extremely helpful, active support community.
There are several approaches to the task of bringing the sensor signal into a PC (to take advantage of PC's computing power, good user interface, connectivity to the web).
Look for integrated sensors that have an interface for attaching to a PC (RS-232, USB, Ethernet). For example, you may find something useful by googling photodetector USB.
There are I/O (input/output) devices for PC. They have analog and digital inputs and outputs. Look up LabJack, National Instruments USB-6008 and dozen other types of commercial USB I/O boxes.
Connect sensors to a microcontroller (uC), then connect uC to the PC through a USB or RS-232 or Bluetooth (the list goes on). This involves more hardware. You'll need to write firmware for the microcontroller too.
Obviously, which approach to choose depends on your skills (or willingness to acquire new ones), timing, budget, team structure (if it's a team effort).
You could use a photo-transistor and a Yocto-Knob. The Yocto-knob is an USB device able to quickly detect resistivity changes, you just have to connect the photo-transistor to it. Here is an application which looks pretty similar to yours: they use a light barrier to detect and photograph a fast object:
http://www.yoctopuce.com/EN/article/how-to-drive-a-camera-shutter-automatically
I want to be able to connect a computer A's USB port to computer B's USB port so as to make computer A act as computer B's keyboard.
Any idea how I would go about doing that?
I'm not looking for a ready-made solution (though if one already exists and is open-sources I
would not object), but for a starting point or a good resource.
I imagine I'd need to write a driver that simulates the keyboard's protocol, and I would also need to sort out the entire USB master/slave scenario.
Anyway, any help would be appreciated.
P.S.
I want to do it with the mouse as well, but I imagine it will be a very similar process, and I think (but I might be wildly mistaken) that starting with the keyboard will be easier.
I am really excited to have found something that will do this from Hagstrom Electronics. It take a serial input and sends a USB keyboard output to another PC. If you combine this with a readily available USB to serial adaptor, then you are golden.
http://www.hagstromelectronics.com/products/usbkm232.html
I have been searching for weeks to find this, so I decided to go back to some forums and share the discovery.
Linux has support for USB gadget mode, but I think you need special hardware for that. I.e. the USB port in a normal PC can not do gadget mode.
An alternative is to wire an LPT port to a PS/2 keyboard input, this is technically simpler.
If it wasn't for the USB, I'd connect the two via LAN and have a client/server C# program that emulates a keyboard / mouse (e.g. via DirectInput).
For the USB part as far as I can tell you'll need some hardware adapter. If you're into hardware development or at least unafraid of a soldering iron and some µc programming, have a look at http://www.obdev.at/products/vusb/hidkeys.html where a HID stack for a small atmel chip is available for free. For this solution you'd need two atmega chips which communicate via I²C or SPI or such.
I'd recommend electrical separation of the two pcs, too. You never know if they share the same electrical ground or not.