Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to use Bluefruit LE UART with an arduino pro micro? #2274

Closed
steinerlein opened this issue Jan 15, 2018 · 8 comments
Closed
Labels
discussion help wanted needs doc stale Issues or pull requests that have become inactive without resolution.

Comments

@steinerlein
Copy link

I am looking to hook this up to a pro micro (32u4)
So far, I had no luck getting any output over the serial port.
Is it possible? If so, how?
Thanks! QMK is awesome 🥇

@steinerlein
Copy link
Author

steinerlein commented Jan 16, 2018

After having spent some more time on this, I have been successful on my own. For documentation purposes here is what I did:
In order to use the

BLUETOOTH =AdafruitBLE 

option I recreated the 32u4 feather setup:

  1. I flashed the firmware for the bluefruit SPI friend onto the nrf module. I have a bluefruit uart friend, but the ble module is the same. Follow the Adafruit guidelines for this.
  2. I soldered six wires between a pro micro (32u4) and the nrf module directly. Follow the adafruit schematics for the feather 32u4.
    Connections are SPI, power and some for resetting the nrf module.
  3. Enabled the aforementioned option in the rules.mk of my board and connected it to my phone as a test.

This is still missing power, but that's next.

Edit: added image

photo_2018-01-17_11-55-48

The only issue I am having now is that when I press one key and then press another one, the first one gets typed again. I have read about this somewhere during my research on this, but I can't find it anymore. @wez can you remeber something like this? Thanks very much for your work on this, anyways!

@wez
Copy link
Contributor

wez commented Jan 17, 2018

FWIW, https://github.com/wez/qmk_firmware/commits/flutterby is the branch in my fork for the flutterby keyboard that I built that uses the SPIFRIEND, which is built on top of the Feather32u4 BLE code base where I prototyped the baseline support.

I also wrote up a build log here, that includes a schematic:
https://www.facebook.com/notes/wez-furlong/building-a-keyboard-ii/10154296367151787/

A couple of problems I found when integrating against the BLE modules from adafruit:

  • Depending on the firmware version, the BLE advertising intervals were too big and that resulted in a very laggy typing experience. IIRC I commented somewhere in the code which version worked for me.
  • If you send SDEP packets to the hardware faster than the Central (your computer) drains them from the BLE module, you can overflow it and cause it to reset

@steinerlein
Copy link
Author

Awesome, thanks for the feedback! Will check it out and see if the firmware update helps.

@steinerlein
Copy link
Author

@wez The firmware downgrade did improve latency a lot! Thanks for the tip. Can you make any sense of the problem with pressing multiple keys (see further up)

@wez
Copy link
Contributor

wez commented Jan 18, 2018

Sounds like something might be explicitly clearing the keyboard and sending the cleared state to the spifriend each time the matrix is changing? Hard to say.

@wizarddata
Copy link

wizarddata commented May 12, 2018

Using the Bluetooth = AdafruitBLE option worked great for me as well. My question is, since I haven't seen this in the qmk.fm documentation anywhere, where could I have learned of this option if it weren't for this thread?

In case you haven't guessed, programming isn't my strong point so thank you in advance for answering what may be a very basic question.

For the record, this is the bluetooth numpad I have built as a stepping stone to a full sized keyboard.
20180510_202031

By the way, thank you for all the work you put in to making this as simple for me as it was.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.
For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

@github-actions github-actions bot added the stale Issues or pull requests that have become inactive without resolution. label Jun 16, 2022
@tzarc
Copy link
Member

tzarc commented Jun 18, 2022

Closing due to inactivity.

@tzarc tzarc closed this as completed Jun 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion help wanted needs doc stale Issues or pull requests that have become inactive without resolution.
Projects
None yet
Development

No branches or pull requests

6 participants