I'm designing an APA102 controller for the RFDuino.

Archive FastLED Archive
1

I’m designing an APA102 controller for the RFDuino. The problem is the limited amount of pins, so I need to combine some pins.

I don’t need RX/TX when a programming is running, so I can use this pins. However for debugging it can be handy to have TX free, so I can check printed information (although I have a BLE connection as well).

I was thinking to combine the APA102 clock with the RX pin. That will free GPIO2 for the switch/sensor.

So when programming the clock signal receives pulses as well, but that’s not a problem because during programming the strip doesn’t have to behave in a specific way of course.

GPIO configuration on RFDuino
0 RX / APA102 clock (remapable SPI)
1 TX
2 Switch/Vibration sensor
3 APA102 data (remapable SPI)
4 MOSFET (to completely power of the strip)
5 SCL (remapable i2c clock)
6 SDA (remapable i2c data)

I’m wondering if I overlook something. I choose not to use the I2C clock pin for the pull-up resistors on the line, but maybe something internally in the APA102 does the same?

Any other ideas. A work-around might be using a jumper to switch the pin during programming, but that’s not with I prefer.

2

Why 4 MOSFETs? If you use the right PNP MOSFET you can switch all off with just one digital output.
Have a look at my Wiki: you could use an external push button for on/off

3

@Juergen_Bruegl no the MOSFET is on GPIO pin 4…

4

A nice thing with the apa102 - if you hold the data line low you can strobe the clock line all you want and the 102’s won’t do a thing. This is how I get four hardware SPI outs on the teensy 3.x.

5

@Daniel_Garcia I suppose I just hold the data line low just by not updating the leds with Fastled.show()? Good to hear the APA102 clock line would be the best bet for a shared pin then.

6

Not while also using Tx/rx, yes. And the library resets data/clock lines to low when finished writing data out. (Or at least it should)

7

I can confirm that the clockline on pin 0 (by default RX) on the RFDuino is not a problem. Even sending data with the monitor doesn’t corrupt the update of the leds (at least not visible directly). Of course that data is not received :slight_smile: