Add support for Raspberry Pi zero 2

[curuvar]

Board Type

Raspberry Pi zero 2

Operating System

Raspberry Pi OS

Swift Version

Swift version 5.5 (swift-5.5-RELEASE)

Description

Need to add official support for Raspberry Pi zero 2. Currently I have to lie an say the board is a pi3 for the PWM to work.

[uraimo]

Hi, pi3 presets and not the pi4 ones, correct?
Can you also confirm that you are using the latest Pi OS (bullseye)?
New release coming tomorrow.

[curuvar]

I was about to submit a pull request for the changes I made but I guess I’ll hold off. It works with three for me. I’m running the 64bit bullseye. I do note that I can drive either PWM 0 or 1 (pins 13 and 12 respectively) but not both at the same time. When I start PWM on the second the first one quits. Also: In SwiftyGPIO.swift line 321. Should it be: if !inited {initIO()} Instead of if !exported {enableIO(id)}

…

On 20 Nov 2021, at 15:00, uraimo ***@***.***> wrote: Hi, pi3 presets and not the pi4 ones, correct? Can you also confirm that you are using the latest Pi OS (bullseye)? New release coming tomorrow. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOAJTISFHD2DLZYLU5PAOGDUM7447ANCNFSM5IOBO2HA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[uraimo]

Released 1.3.6, with the initIO fix too.

The problem with the dual PWMs is that the PWM generator expects the PWM pattern to be stored in a single memory location, and when you want to generate two distinct signals the two patterns are expected to be stored as an interleaved sequence of elements, as in: odd positions for PWM1 and even positions for PWM2.
Normally that block of memory would just contains a pattern for a single PWM as an unbroken sequence.

I've never added support for this because it would make the code and relative API even more convoluted, I planned to implement a different PWM mode that would have solved the multiple PWMs issue in a cleaner way and would have allowed up to 8 independent PWM but never got around to it.