My PWM code stopped compiling after a board package update — the setup function no longer exists

On which way to go, and I would push towards rewriting rather than pinning.

Rewrite. The new calls are simpler, the code is shorter, and you stay on a package that receives fixes and supports newer chips. If you have a handful of PWM lines, this is fifteen minutes.

Pin the old version. In the boards manager you can select the last 2.x release, and everything compiles again immediately. This is the right answer when you are mid-project, or depend on a library that has not been updated, or are following a course written against the old API. It is a decision to stay on a version that will stop receiving support, so treat it as buying time.

Compatibility shim. Defining the old function names in terms of the new ones works and I would avoid it. It hides which API you are on, and the next person to read the code has no idea why it compiles.

Version 3 of the ESP32 board package removed the old LEDC functions. They are not deprecated with a warning, they are gone, which is why you get an undeclared-in-this-scope error rather than anything more helpful.

The old pattern was two calls: configure a channel with a frequency and resolution, then attach a pin to that channel. Version 3 replaced it with a pin-centric API — you attach a pin directly, giving the frequency and resolution at the same time, and then write to the pin rather than to a channel number.

So every tutorial written before that change fails to compile, and there are a great many of them. That is the entire population of people hitting this.

The rewrite is small: two calls become one, and the write takes the pin instead of the channel. Channels are still allocated underneath, automatically.

The general lesson worth carrying, because this will happen again with a different function: for a board package, the major version number is a compatibility boundary and the migration guide is the real documentation.

Espressif publish a migration document for the 2.x to 3.x change listing every removed and renamed API, and LEDC is only one entry. If your sketch uses timers, ADC, or the touch peripherals, you will meet the same wall a few compiles later.

Reading that document once is faster than solving each error as it appears, and it tells you in advance whether a rewrite is fifteen minutes or an afternoon.

One practical note for anyone following a tutorial and hitting this: check what version the tutorial was written against before doing anything else.

Board packages update silently in the background, so a fresh install today is not the environment the tutorial's author had. The mismatch is not visible anywhere on the page.

When a copied example fails to compile in a way that looks impossible, the version of the package is the first thing to check, and it is right there in the boards manager.