Best practices for migrating firmware from devkits to custom hardware?

[jonathanlock]

Are there any best-practices for software migration from a devkit to custom hardware? In my case, I have set up a working demo using the (now obsolete) HMI-devkit (https://www.espressif.com/en/news/ESP32-S2-HMI-DevKit-1) and have developed my own custom board using an ESP32S3 for my specific application. It would be convenient if I could reuse the LCD controller libraries, without also importing all of the other application specific modules from the devkit (audio, sensors, and so on). Pointers for getting started would be greatly appreciated as I'm entirely new to the ESP32 platform (and coming from a bare-metal STM32/C2000-background there are some pretty large differences).

Thanks!

[ESP_Sprite]

Not really, as it depends on your custom hardware. If your custom hardware is an 1-to-1 copy of the devkit, then obviously you don't need to change anything if it is not, it depends on what changed. If only GPIO mappings changed, you can change those and be done with it. If the devices themselves changed as well, then you'd need to find/build new drivers, preferably with the same API as the old ones.

[mbratch]

I suppose the best practice is to try to make your prototype design (with the devkit) align as close as possible with your target design to minimize changes. For example, be consistent with use of GPIO, selection of external components, etc. In addition to what ESP_Sprite said...

[rsimpsonbusa]

I've done several of those projects.

Use de DevKit and breadboard for SW design/testing/debugging as well as HW "assignments".

Then design the PCB with your favorite tool, I use EasyEda very simple and free.

As stated by others its not that complicated BUT... depends on what Options you are going to allow in the PCB board. For instance, will you allow the board to have firmware upgrading directly (vs OTA), will you need to Monitor output (serial) among others and in any case careful with GPIO12 it MUST MUST not be HIGH, like an external pullup. Review strapping pins are correctly used or it will not boot. Just better NOT to use GPIO12

Power rail and power source is important. Put a good Cap in the VIN and VOUT lines and a good voltage regulator like AMS1117 or HT733 with enough amps. Power traces should be appropriate for the amps used, but 0.40mil is good. Signals could be default 0.25 or whatever you use. This has been done for you in the DevKit, but now it's your job.

If you will allow direct firmware uploading then the switch/button design is relevant. Reset (EN gpio for reset) and Flash (GPIO0 for uploading) must be solid, not just direct GND connections (it could work but...) and obviously the TX and RX gpios connections (straight).

Remember when the PCB is working you are most likely not monitoring its output as when you are testing the "breadboard design" so use some LEDs to signal activity like Power is ON, WiFi is connected, a sensor is activated and so forth.

If using SMD components (most likely) don't go too small 0805 is fine cause you don't want any doubts there is a short with the solder and a component. Also the connectors for external inputs like Power, TX-RX, sensors better use JST pins 1.25 mm n pins. They are pretty solid vs pin headers for instance.

This has been my experience in about 10 PCBs with a rather limited functionality, 3-4 sensors, 2-4 chips, etc.

But when it works as designed, you will be VERY satisfied and happy .

Enjoy

[ESP_Sprite]

Note that if you use the S3, you can also do flashing/debugging/... using the built-in USB-serial-JTAG converter; that means you'd only need to design in an USB connector somewhere. You probably still want some access to something that can put the ESP32S3 into download mode manually, but you'd only need that in unusual situations (e.g. flashing firmware that reconfigures the USB pins) so yoy might not even put actual buttons there, just e.g. unpopulated headers.