Add all the FeatherWings!

[kattni]

We're working on building a CircuitPython FeatherWing library that takes care of the setup and creates and easy to use interface for each of the supported FeatherWings.

If the wing uses I2C, there is a shared I2C created that can be imported and used.

The libraries should include setup, access to each feature available on the wing, and thorough documentation for ReadTheDocs. Please see the motor_featherwing and the ina219_featherwing as examples.

We will be updating the associated Learn Guides as we go as well.

Below is the list of all the FeatherWings. Checking the box next to one in the "Remaining" list implies that you have begun work on it. Once you have submitted a PR, please edit this issue and move it to "Pending PRs". Once the PR is complete, please move it to "Pending Guide Update". Once everything is completed, please move it to "Completed".

Remaining:

• [ ] Adalogger FeatherWing
• [ ] OLED FeatherWing

Pending PRs:

Pending Guide Updates:

• INA219 FeatherWing
• Joy Featherwing
• 14-Segment Alphanumeric LED FeatherWing
• DotStar FeatherWing
• NeoPixel FeatherWing
• 7-Segment FeatherWing
• DS3231 FeatherWing
• Ultimate GPS FeatherWing
• 8x16 LED Matrix FeatherWing
• Temperature + Motion FeatherWing

Completed:

• DC Motor Stepper FeatherWing
• Mini Color TFT with Joystick FeatherWing

[tannewt]

We should update guides as these are added too. I updated the Motor FeatherWing guide and it was much simpler: https://learn.adafruit.com/adafruit-stepper-dc-motor-featherwing?view=all#usage

[kattni]

That's a great point. I've added that step to the comment above. Thanks!

[kattni]

I have much of the DotStar Featherwing lib done, so if anyone wants to help out with this issue, choose any of the others.

I've removed myself as the assignee, as I am no longer actively working on this.

[makermelissa]

I just noticed you have Quad Alphanumeric FeatherWing and 14-Segment Alphanumeric LED FeatherWing. I believe those are just different names for the same thing.

[kattni]

@makermelissa You are correct! You can purchase the board itself separately and it's under a different name when purchased without the display bits. I must have added both because of this. Feel free to edit the comment above to remove one of them (probably "Quad")!

[makermelissa]

Thanks for confirming this @kattni.

[makermelissa]

After I get all of these working, I think it might be fun to write some examples that combine several of these wings such as a clock example based on the ds3231 RTC wing and the 7-segment LED wing. Or a GPS example using the GPS wing and OLED wing.

[makermelissa]

I'm a little confused on the OLED FeatherWing. I saw a comment on the SSD1306 that said we're going to be moving from framebuf to displayio. Does this mean I should wait until then to work on the SSD1306 or since the SSD1306 library will probably have its code updated, I should just go ahead with it? I think I'll work just on the GPS one for now either way.

[kattni]

@makermelissa In theory, whatever you do here will inherit all the changes made regarding framebuf and displayio. It is a little in flux at the moment though, and it's possible that the setup could change on the SSD1306 library. So, I would recommend waiting on the OLED until we have 4.0 stable (soon!). Let me know if you run out of other FeatherWings to work on!

[makermelissa]

Thanks Kattni. I think I have all the ones on the list. I am wondering about whether newer wings that came out since this issue was originally filed such as the propmaker wing should also be added or are they streamlined enough?

[kattni]

I think if we do a PropMaker FeatherWing library, we might want it to be a separate library, similar to Crickit or CPX. Let me think about this and get back to you on it.

Take a look to see what other FeatherWings have come out since this list was created and we can discuss them as well.

[makermelissa]

I think the only other ones that have come out since the list was created which aren't obviously unfit for this issue are the NeoPXL8 FeatherWing and Mini Color TFT with joystick FeatherWing.

[kattni]

I don't think we have NeoPXL8 support in CircuitPython at the moment. Need to look into that.

The Mini Color TFT with Joystick Wing sounds like an excellent candidate. There's a lot going on there that would be nice to have in one place. If it's not a good fit for this library, then perhaps a standalone helper library would work. @makermelissa Take a look at it and let me know what you think.

[makermelissa]

The Mini Color TFT with Joystick Wing looks like it's really a combination of ST7735 (which is part of Adafruit_CircuitPython_RGB_Display) and the Joy FeatherWing, which we already have implemented. I also think it's an excellent candidate, but it may have to wait for a stable version of CP4 for the same reasons as the OLED display.

[kattni]

I agree completely with waiting. Thanks for looking into it!

[anecdata]

Is the Adafruit 2.4" (and 3.5") TFT FeatherWing captured somewhere? The display works fine with graphics using ili9341, but the touch is SPI. Thought I could borrow touch from PyPortal, they're all resistive, but that isn't SPI by default and I don't see SPI touch interface in the docs.

[makermelissa]

@anecdata according to the documents in the Download section of https://learn.adafruit.com/adafruit-2-4-tft-touch-screen-featherwing/downloads, the TFT FeatherWing uses the STMPE610 controller to handle touch. I would try using the STMPE610 library for capturing touch at https://github.com/adafruit/Adafruit_CircuitPython_STMPE610 for moment.

[anecdata]

Thanks! Saw the Arduino, missed the CircuitPython.

[anecdata]

Just got a 3.5" TFT FeatherWing and looks like it uses a different display driver than the 2.4", (HX8357D). Is that covered somewhere already? Interestingly, adafruit_rgb_display will drive it as a ili9341, but only the first 320x240 of the display (random pixels in the rest).

Also the 2.13" Tri-Color eInk / ePaper Display FeatherWing. I can get partial function from it using adafruit_epd.il0373, but it's funky.

[ladyada]

the display featherwings should wait till we have displayio support released :)

[makermelissa]

Sounds good about waiting. Also good to know about the different display chips. I think displayio will allow some level of abstraction.

[tannewt]

I'd love help getting all of the displays supported with displayio starting with FeatherWings makes sense to me.

[makermelissa]

What is needed to get a display supported with displayio? I’d like to help.

[tannewt]

Awesome! The biggest thing is to port the init sequence from the Arduino driver to a CircuitPython driver. Here are the two I've done:

https://github.com/adafruit/Adafruit_CircuitPython_ILI9341 (Ported from https://github.com/adafruit/Adafruit_ILI9341)

https://github.com/adafruit/Adafruit_CircuitPython_ST7735 (Ported from https://github.com/adafruit/Adafruit-ST7735-Library/blob/master/Adafruit_ST7735.cpp)

The featherwing library can then wrap those to do the init automatically.

[makermelissa]

Oh, ok! I was wondering what those libraries were for.

[makermelissa]

@tannewt, @ladyada, and @kattni, I've been playing around with displayio and getting various displays to work with it. We currently have the Adafruit_CircuitPython_ILI9341 and Adafruit_CircuitPython_ST7735 drivers. The ILI9341 driver works with many displays and is good, but the ST7735 is very specific to the hallowing type display and doesn't work very well with displays such as the 160x80 pixel TFT. I compared it to the Arduino driver and the init sequences are a little different for that display. It also looks like we will need drivers for the HXD8357D and ST7789 displays. I'd love to work on these, but was thinking about the organization of the files and it seems it would be cleaner to have 1 repo (like Adafruit_CircuitPython_RGBDisplay) except with displayio drivers for each of the displays. It's mostly about getting the right init sequences and some simpletests for each so I thought that would work well. Please tell me your thoughts on this.

[ladyada]

@tannewt wanted one repo per chip type, which i can agree with we could subclass the basic ones to add our own special init codes like for the 1.44" or 0.96" ? i can't think of an obvious/easy way to resolve the fact that 95% of the init is the same. you could see how we do this with arduino here: https://github.com/adafruit/Adafruit-ST7735-Library

[makermelissa]

Thanks @ladyada. I can go ahead and subclass the ST7735.

[ladyada]

you maaaay want to do what we did and have ST77XX -> ST7735 and ST7739 in one library they are nearly identical chips

[makermelissa]

Ok cool. That's good to know.

[makermelissa]

On an unrelated note after discussing with @kattni, since the AMG8833 FeatherWing is essentially a FeatherWing format of the breakout, it would make more sense to improve the Adafruit_CircuitPython_AMG88xx library to make initialization easier. However, the Adalogger, OLED, and Mini Color TFT with Joystick FeatherWing all have additional features on them and would benefit from this library. I may end up back-porting some of the improvements I implemented for the RTC and GPS FeatherWings into those libraries since those are also FeatherWing formats of the breakout. This should make maintaining the code easier.

[tannewt]

Yup, I'm all for lots of small repos.

I think it's useful to split chip level code from the product specific things such as display dimensions and rotation. This is like the split of the LIS3DH and the CircuitPlayground library. A split along this boundary ensures the chip level API is succinct and useful in all cases.

For the ST77XX it may be worth having them separate as well as a way of forcing us to document their differences.

[makermelissa]

@tannewt, after your review of ST7735, I think I better understand what you mean.

@kattni, it looks like we have another good candidate for this issue. The Adafruit ADXL343 + ADT7410 Sensor FeatherWing uses multiple sensors so it might be good to add it to the list. Let me know what you think.

[makermelissa]

@anecdata. In case you're still interested, I wrote a displayio driver for the 3.5" FeatherWing that can be found in https://github.com/adafruit/Adafruit_CircuitPython_HX8357 which was just merged in today.

[anecdata]

@makermelissa Very cool, thanks!

[StarWitch]

I was wondering if any progress had been made on the NeoPXL8 library? Worst-case, I could try to take a crack at it, but if anyone more experienced than I intends to do it in the near future, then that'd be for the best. :)

[makermelissa]

Please @StarWitch, take a crack at it. :)

[ladyada]

@StarWitch true 8-channel concurrent support would have to be done with a new C module, not pure python!

[makermelissa]

Ah, so that's why we hadn't done it yet. :)

[ladyada]

yep we 'abuse' the timer 0 to create waveforms. its very cool and very C/register-iffic

[StarWitch]

I did figure it'd require a bit of C work after looking over the Arduino implementation, yep.

I'll see what I can do. It'll probably take me a month or so, depending on my workload. I'll update when I've got something worth discussing/reviewing. :)

[ladyada]

@StarWitch ok rad - we can give you a hand, the code is written in arduino already, so you would be making a new module in circuitpython :)

[StarWitch]

Ah, cool! So the existing ZeroDMA library could work as a CircuitPython extension already? Forgive the newbie questions, I'm pretty familiar with Arduino and Python individually but this would be my first major venture into CircuitPython.

[anecdata]

Is it worth revisiting this issue re: the display FeatherWings now that displayio is stable? Are they good as-is, or are we envisioning libraries for these that would merge what's in the display chip library with the SD library?

e.g.,

• 2.4" FeatherWing using adafruit_ili9341
• 3.5" FeatherWing using adafruit_hx8357
• 2-color EPD FeatherWing using adafruit_ssd1675
• 3-color EPD FeatherWing using adafruit_il0373

[makermelissa]

I think the decision was that this library would pretty much be for featherwings that used multiple libraries, which is why those ones weren't on the list. Since the display ones are only single library use ones, they wouldn't really have any benefit to being added.

It would actually be nice to take some of the single-library featherwings that were added, like the DS3231 and GPS FeatherWings and move some of those features to the original libraries and possibly remove them from here.

[makermelissa]

Oh, I get what you're saying @anecdata because of the SD card, they aren't single-library wings. You make a good point.

[anecdata]

Or maybe they are, not sure what's best architecturally for the library. If there were separate libraries for these wings, they'd presumably merge display and SD, and maybe simplify some of the setup code (e.g., no reset on EPD FeatherWings, and no busy connected by default.

But maybe it's sufficient for the Learn guide to step through putting the pieces together. Just trying to close the loop and go one way or another.

There's some threshold above which a separate library makes sense (e.g., MiniTFT with SPI TFT and specific I2C Seesaw etc). I just don't know what that threshold is.

[kattni]

We're keeping up with adding FeatherWings as we go. I'm going to close this issue as the original list has been added. Thanks @makermelissa!