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

NRF52840 USB Dongle and general NRF5x support #89

Open
bezmi opened this issue Apr 2, 2019 · 8 comments
Open

NRF52840 USB Dongle and general NRF5x support #89

bezmi opened this issue Apr 2, 2019 · 8 comments
Labels

Comments

@bezmi
Copy link

bezmi commented Apr 2, 2019

the Holyiot store on Aliexpress has some nice compact NRF52840 usb dongles. They also expressed interest in releasing a "nano" version of the dongle if there was enough of an order quantity.

I have bought this dongle and intend to integrate with my mitosis style keyboard and do away with the pro-micro style receiver, and I'd like to contribute to keyplus if development is going to be picked up again.

There are two approaches I see to adding nrf51/nrf52 support. The first would be to use Nordic's ESB libraries - which would allow backwards compatibility with nrf24 based designs. The Nordic SDK has allowed redistribution of SDK files from v12 onward, however, the ESB library is released under a restricted 5-clause BSD license that might not be compatible with the MIT license of this firmware. I'm not sure about the legalities of reverse engineering the protocol and writing our own ESB library.

The other option would be to write a custom link layer via the free nrfx drivers. This would obviously be a lot more work and there would be no backwards compatibility with nrf24 devices.

I have also thought about the BLE implementation (nrf51 peripherals and nrf52/PC host), but my 16kB nrf51 boards do not seem to be enough to run FOSS BLE implementations like mynewt or zephyr for anything but the most basic BLE beacon examples without security. The Nordic s130 softdevice will work with a 16kB nrf51822 and leave enough RAM for a basic application, but the majority of Keyplus would have to be implemented on the central/host side. 32kB devices should have no problem either way.

How should we approach this? It would be simpler to use the Nordic ESB library and softdevices. It would also allow implementation of concurrent ESB and BLE connections. Obviously for the softdevice, people would have to download it from the Nordic website and flash it themselves/copy it into the Keyplus directory. The ESB library should be okay to distribute with the source, provided we can work with the 5-clause Nordic license. Apologies for the large post, just putting my thoughts on this matter down.

@LovesTha
Copy link

LovesTha commented Apr 2, 2019

Interesting thoughts.
Having a easy to buy smallish dongle would be nice, but I doubt we would generate enough volume for a true nano dongle to be developed. So personally I'm more likely to stick to the Logitech dongle.

@ahtn
Copy link
Owner

ahtn commented Apr 2, 2019

This is something that I'm interested in too. I actually ordered this nrf52840 dongle the other day to play with.

The first would be to use Nordic's ESB libraries

A while ago I used the nrf24 ESB library to get some basic matrix scanning + nrf24 RF working. It seems pretty straight forward to get it working. Haven't got any USB/BT stuff going yet. That code is a bit old (I was using the preview dev kit), but I try clean it up and get something committed to the repo soon.

The Nordic SDK has allowed redistribution of SDK files from v12 onward, however, the ESB library is released under a restricted 5-clause BSD license that might not be compatible with the MIT license of this firmware

The MIT license is compatible with Nordics 5-clause license, so no worries there.

Obviously for the softdevice, people would have to download it from the Nordic website and flash it themselves/copy it into the Keyplus directory.

The way keyplus is designed, you can configure it via USB. So most people can just flash a pre-compiled binary which includes the softdevice.

@ahtn ahtn added the nRF52840 label Apr 2, 2019
@bezmi
Copy link
Author

bezmi commented Apr 2, 2019

Awesome. While my nrf52 dongle arrives in the next 20-60 days, is atmega32u4 support working? I would like to get the nrf51 communicating with nrf24 modules but only have a couple of pro micros available.

@nine-fox
Copy link

Hi there,

This is a really great project! Just see this for a while, and must say something about nrf52840 because I am working on it. See trkeyboard.com and nine-fox.com, nine-fox.com/pad

  1. To use a module like holyiot or other.
    This would be really great if the pcb has enough space and only 1 module is needed. Thats to say, the price is affordable and looking is acceptable. However, for a space limited keyboard, eg, a 4x4 pad, 40%, 60%, using a such large module is quite limited. For a split keyboard, eg, wireless split keyboard like mitosis, you may need 3 modules, the prices will be really high. In my keyboard, eg, https://geekhack.org/index.php?topic=99719.0, I need four 840 chips. If I used a module, the price will be very high. So I would suggest to use chip directly instead a module.

  2. Avoid to use atmega32u4
    If you choose to use this nrf52840, get rid of avr. AVR is not a wireless targeted chip, that's to say, its high power cost. If you want to create a keyboard with a long battery life, leave it.

  3. The firmware is different
    If you choose to use nrf52840, get rid of all source codes of avr parts. You may need to implement a totally new one. It needs huge work but it is needed, because the mechanism is totally different between avr and 840.

  4. 840 is still buggy.
    I just got the product notification before China New year from nordic that the improved product will be on market later this year. Also, the latest sdk 15.3 contains bugs(It cost me a lot time to find them and fix them), see the devzone.nordicsemi.com

  5. The communication protocol.
    I would suggest to use BLE to communicate. Not only its simple and easy to implement, but also the device with BLE support can connect to it, without the dongle, for example, iPad or iPhone. With the same work, the code can be used in another scenario.

Anyway, this is really a great chip and you can implement a lot of keyboard using it. Good luck with it!

Thanks,
nine-fox

@ahtn
Copy link
Owner

ahtn commented May 20, 2019

@bezmi Hey made a lot of progress on this now. The nrf52840 dongle code now is basically equivalent to the nRF24LU1+ version. Here's some pre-compile code if you want to give it a go: keyplus-f9a0f8c.tar.gz. The hex file was compiled for the Nordic nRF52840 dongle and you can flash it easily with nRFconnect. I'm not sure if it will run on the Holyiot dongle without modification since it expects a bootloader/mbr to be in place.

Do you know if the Holyiot dongle comes flashed with a bootloader? I looked at the store page and it breaks out the SWD pins, but it'd be annoying for people if that's required to flash it.

I've also made a lot of progress on BLE. I've got multi-protocol BLE and ESB working. Right now I'm using my two Xmega+nRF24 and unifying mouse with a nRF58204-DK relaying the keystrokes/mouse over BLE. The performance seems to be pretty good for the keyboards. You can notice that the latency of the mouse is bit higher, but it's still usable.

The main things left to do now are combine the different modes (USB+ESB-rx, BLE+ESB-rx, ESB-tx) so that they will work all together. And there's a couple of things that still don't work over BLE yet (layout updates, mouse pairing). I might start look into making a PCB for an nRF52840 board too.

@ahtn
Copy link
Owner

ahtn commented May 20, 2019

@nine-fox
1. Yeah, I'll have to look around cheap options, but price isn't too much of a concern for me run now since I don't plan on mass producing it or anything.

3. The code runs on a few different chips already, so it's modular enough to support both AVR/ARM without too much difficulty.

5. Yeah BLE is more convenient. I'm going to try and support both ESB and BLE since they both have there advantages. Also, in my firmware you can remap the mouse buttons of Logitech Unifying mice like a keyboard with the ESB firmware, so it's nice to have both options.

@bezmi
Copy link
Author

bezmi commented May 20, 2019

That's awesome! Unfortunately I'm super busy with my final semester of uni until mid June, so i won't be able to do much testing until then. The HolyIOT dongle doesn't come with a bootloader, but the casing is easy enough to remove for access to the SWD pins. Obviously this isn't ideal for the average keyboard builder, but I purchased it solely based on the compactness.

This gives me more motivation to work on ESB compatibility for my nrf51 keyboard, because I should now have a device that will work with keyplus for testing.

How is the current draw over BLE? I've assumed it would be a little too much for the coin cells, so was envisioning a scenario where we could have the split transmitters (esb tx) communicating to PC via nrf52840 (esb rx + USB), with the nrf52840 dongle also able to relay keystrokes to secondary devices over BLE.

@ahtn
Copy link
Owner

ahtn commented May 22, 2019

How is the current draw over BLE? I've assumed it would be a little too much for the coin cells

Yeah, BLE+ESB will probably use about ~10mA when it's in use since it needs to leave the RF receiver on to listen for ESB packets. So too much for a coin cell. You could get this lower by using BLE for inter-keyboard communication like I think nine-fox is doing, but I think there'd be some extra complications especially if you have more than 2 devices.

Wake-up receivers might allow for a really low power version, but they're still being developed/researched so not viable at the moment. However, they are being considered for WiFi (802.11ba), so they'll probably make their way to Bluetooth chips too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants