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

Support for nRF52xxx (e.g., nRF52840) #747

Open
henrygab opened this Issue Mar 3, 2019 · 7 comments

Comments

Projects
None yet
3 participants
@henrygab
Copy link

henrygab commented Mar 3, 2019

Is it possible to port to the nRF52840, at least for SPI LED types?

Although the nRF52xxx is similar to the nRF51xxx (which is supported), if I understand correctly, portions of the nRF52 core run at high interrupt level (for BLE), and they cannot be disabled by user application code. Obviously, this could impact any code depending on tight execution timing. Based on this, would some LED control types need to be explicitly excluded (e.g., NeoPixel)?

@focalintent

This comment has been minimized.

Copy link
Member

focalintent commented Mar 4, 2019

I haven’t seen anyone supply even a partial port - and I won’t be able to get to it for a while, yet.

@pcaddict

This comment has been minimized.

Copy link

pcaddict commented Mar 15, 2019

Take a look at my fork here. I have tested with the nrf52832 and it should work exactly the same for the nrf52840. I have only tested APA102 but I'd guess other SPI chipsets should work.

Video of an APA102 string being driven by the nrf52832: https://www.youtube.com/watch?v=VYZ5e_oi5cw

@henrygab

This comment has been minimized.

Copy link
Author

henrygab commented Mar 19, 2019

Wow, looks great, @pcaddict

Would you be able to help me understand a couple items?

Line https://github.com/pcaddict/FastLED/blob/master/platforms/arm/nrf52/fastspi_arm_nrf52.h#L59 appears to set MISO to port0.pin1.
Q# 1a. Is this intentional?
Q# 1b. PSEL.CSN is not explicitly set, and thus appears to be presumed to be the reset-default value of 0xFFFFFFFF. I think this is OK, as no device select is typically necessary. Do you agree?
Q# 1c. Is it legal to leave MISO disabled while using SPIM, if you never care about input values? (and if so, should this be set to 0xFFFFFFFF?)

Line https://github.com/pcaddict/FastLED/blob/master/platforms/arm/nrf52/fastspi_arm_nrf52.h#L87 appears to state that the function returns immediately after setting the register. However, it appears at line https://github.com/pcaddict/FastLED/blob/master/platforms/arm/nrf52/fastspi_arm_nrf52.h#L95 to wait for the end-of-transmission event.
Q#2. Is the comment wrong, the code wrong, or my understanding wrong?

Thanks!

@henrygab

This comment has been minimized.

Copy link
Author

henrygab commented Mar 23, 2019

After lots of tinkering, compiling, and adding compilation asserts / pragma messages, I've started to understand some aspects of this port. I think it will be possible to port this, which is great. Even better, we may be able rely upon the availability of Nordic's nrfx repo (part of at least Adafruit's BSP for Feather Express 52840. Work now underway....

@pcaddict

This comment has been minimized.

Copy link

pcaddict commented Mar 23, 2019

Sorry for the late reply, I did not see a notification that anyone had responded.
Q1a. I don't think setting MISO to pin 1 was intentional. It probably should have been set to 0xFFFFFFFF. As far as I can tell from the documentation it is perfectly fine to not specify a pin for MISO if you aren't using it.

Q1b. Agreed. I think I might have explicitly told PSEL.CSN to be 0xFFFFFFFF at some point but probably removed it for some unknown reason.

Q2. The comment is wrong. I took code from the NRF51 and Teensy platforms and it is likely something that originated elsewhere.

What features of the nrfx library are you thinking will be useful here?

I have not had much luck running this on my nrf52840. I have not been able to get the Adafruit BSP to play nicely with the Particle Xenon board I have, which is mostly used with the Nordic SDK anyway, so all of my testing has been with my feather52832.

@henrygab

This comment has been minimized.

Copy link
Author

henrygab commented Mar 24, 2019

Thanks for answers, it helps me sanity-check my understanding, and keep my sanity. :)
I'll update to indicate MISO is not needed, and explicitly set CSN for the 52840 + SPIM3 only (no other board/SPIM appears to support this).

Why use nrfx?

  1. a hardware-abstraction layer (HAL), useful for switching between SPIM instances
  2. same HAL allows common code for nRF51 and nRF52 (and other) boards
  3. built-in workarounds for chip errata, owned and maintained by Nordic (i.e., less really migraine-inducing, head-scratching hardware debugging)

I've already gotten the simplest of items showing on a dotstar strip (RGB ordering verification, simple chaser). I'll push a branch "real soon now".

Do you have any thoughts on how to test/validate the nRF52840 support is "complete"?
Also, what specific problems or types of problems have you experienced with the Particle Xenon?

@pcaddict

This comment has been minimized.

Copy link

pcaddict commented Mar 24, 2019

@henrygab I'm interested to see what improvements you've made to my hatchet job of a port. I honestly got it to a point of "hey pretty lights" one afternoon and did not explore it much further than that. I did try to understand how to get neopixels working and ran out of patience.

In regards to nrfx, I wonder if that isn't going to add a bunch of complexity that many users won't want to deal with, especially in Arduino land. Might make the possibility of porting to the Nordic SDK a little simpler though.

As far as validating that support is complete, I'd imagine that'll take some community testing with various led chipsets. This is probably something @focalintent should comment on.

For some reason Particle Xenon isn't playing nicely with the nordic QSPI libraries in the Adafruit BSP. I've tried removing everything I could find having to do with the QSPI memory and still have problems with most sketches compiling. Since I got the Xenon primarily for working with the Nordic SDK anyway I have not put too much time towards figuring out why I am having the problems I am. Other than that the Xenon is a great dev board and they were a steal at $9 during pre-order.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.