Click to view our Accessibility Statement or contact us with accessibility-related questions
Showing 1 of 1940 conversations about:
cino
104
Oct 20, 2015
bookmark_border
Oh looks like a match! "solder RX and TX to PD2 and PD3 and draw 5V from the nearby VCC/GND"!
Oct 20, 2015
Sgt_Fiddler
12
Oct 21, 2015
bookmark_border
cinoSo you're saying we could solder a bluetooth module to the left over pins on the pcb, right? Because that would be awesome! (Just confirming this wouldn't just work on the handwired plancks)
Oct 21, 2015
cino
104
Oct 22, 2015
bookmark_border
Sgt_FiddlerYup Teensy 2 and the Planck PCB are sharing the same Amtel micro controller, to connect a SparkFun/Roving Network Bluetooth module to the teensy you need to solder PD2 and PD3 and get some juice from somewhere, guess what? PD2 and PD3 are available on the Planck PCB as solder point/pinout so no dirty hack with Atmel legs yeppee! You need to modify the code then, read here : http://stafava.blogspot.fr/2012/12/connect-teensy-to-bluetooth-module.html The Ada Bluefruit is another beast because from what I have read it is not just passing data over BT but also acts as a control input layer itself but looks like it is more limited than the ATmega32U4 .
Oct 22, 2015
overprescribed
2
Oct 22, 2015
bookmark_border
cino"it is not just passing data over BT but also acts as a control input layer itself" isn't this a good thing? USB HID codes are not the same as BT HID codes, and I thought the bluefruit EZKEY does some translation for you, where straight sending the USB HID codes as a BT HID device is no bueno. I've been curious about this though since grabbing a bluefruit EZ-KEY and wanting to hook it up to a teensy running the keyboard firmware before the Planck shows up. This is my first time playing with any of this sort of stuff, so I'm possibly completely missing something.
I also hope I don't understand Jack correctly when he says firmware must be compiled for either USB HID or serial TX (bluetooth) mode. Though, that does mean if there's a way to use the USB TX and RX pins during serial output mode (to basically redirect the serial I/O to those pins already wired to the usb header on the PCB), I can use a custom cable to connect to my bluefruit EZKEY and have everything external without modding a case to access the RX/TX pins... that would be worth having it basically always be a bluetooth device. I'd get to show off the aluminum case, and use my 18650 2400mAh lipo battery and the 1A charger, rather than a 1200mAh flat battery and a .5A charger internally... *goes hunting for the datasheet
ED: nope, D+ and D- are only for high speed USB; there's voltage regulation and other stuff going on between the CPU and the pinout. maybe with all the work jack's doing to get it to work, it's worth it to get another case, stick everything inside, and maybe wire the two battery status LEDs from the lipo charger, and the bluefruit LED pins to the PCB (if there's pins available) and use the keyboard firmware + board LEDs to show charging and bluetooth pairing status. I'm still not giving up on a somehow more elegant than "a wire soldiered to the PCB shoved between cracks in the case connected to an external EZKEY and battery" solution for BT with the aluminum case...
Oct 22, 2015
cino
104
Oct 23, 2015
bookmark_border
overprescribedWell reading the bluetooth developper notes leads me to think BT HID *is* USB HID : "The (bluetooth)HID profile uses the universal serial bus (USB) definition of a HID device in order to leverage the existing class drivers for USB HID devices.", maybe your were meaning SPP? The bluefruit can send on HID or SPP but also raw HID which is, if I understand correctly, what you should be using with the Atmel (more easy I guess) otherwise the Atmel is doing matrix conversion then sends to the Bluefruit which is doing conversion once again, so this calls for troubles, isn't it? Are D- and D+ the only HID options we got on the Atmel? Firmware compiling for either HID or SPP makes perfect sense, I guess you can't use two ports protocols at the time with only one connection. Some devices allows the use of one or another, the bluefruit is a good example of this. Ahem, yes, RX and TX are serial pinouts so it seems you can't use them for HID… can you? So available PD2 and PD3 should be used in a SPP logic chain. You can get rid of the Atmel (theorically, in reality it would be too much of hacking traces with the Planck PCB) and use the Bluefruit alone, or make both talk the same lingo (HID or SPP).
Oct 23, 2015
manapua
68
Oct 23, 2015
bookmark_border
cinoThe Bluefruit HID has only 12 digital inputs. You could only make a very basic input pad with it alone.
HID is a protocol. You can transfer HID formatted scan codes on serial, i2c, spi, etc... It's just formatted data.
Oct 23, 2015
cino
104
Oct 23, 2015
bookmark_border
manapuaYes looks like it is limited to one modifier only on raw HID which is pretty lame indeed. Only price wise (maybe) and because you can use the BT only of out it (through RX TX) it will be a good candidate, must say I'm more interrested in the Roving Network modules or any other dedicated BT module than could work and integrate smoothly but after further reading it looks like they all can act as the bLuefruit and what we may need is Raw HID. Thanks manapua for clarifying this, so we can send either HID or SPP through serial, so this means we can use PD2 and PD3 for BT then it's just a matter of coding, sounds great.
Oct 23, 2015
A0.C
394
Oct 23, 2015
bookmark_border
Oct 23, 2015
View Full Discussion
Related Products