Hello everyone, totally NOOB here 
I’m trying to develop this schematic but i’m a software engineer, not an electrical engineer so i’m struggling a lot for this project…
here i need to use 2 esp32’s, one with ethernet and the second with wifi, both exposing their extra non used pins as breakout board for future use.
I’m using FTDI232 to program the ESP32 so i added a BOOT button on the schematic…
I’m looking for an advice on how to fix the mess i’ve made 
Use bus or many buses.
My typical schematics looks like this:
1 Like
I’ll look into it, many thanks for the advice, i’ll post the results 
Schematic readability is always an issue, and also a compromise between using wires and labels, and the time you invest to clean up “ugly” or unclear sections. I do find this schematic look quite reasonable. Especially for one of your first projects. It’s quite obvious you put some thought and effort into it to make it readable.
Some things I would do differently:
You used labels for GND and the different power rails (3.3V, 24V input) I would use power symbols for these. Have you run Schematic Editor / Inspect / Electrical Rules Checker? It would probably issue warnings for the open pins on your RJ45 connector, and other pins such as the open Vss pin25 ofU5. KiCad uses “no connect flags” on open pins. Some think it’s a silly feature, but I very much like it. It makes it obvious that a pin is left open on purpose, instead of simply forgotten to connect. So don’t place these flags just to get though ERC. Always verify whether such pins really should be left open.
For resistors and capacitors it is very common to use RKM_code It’s more compact, and you don’t have to find the “Ohm” key on your keyboard. Another common convention is to use signal flow from left to the right, and voltage from top to bottom.You’ve done that mostly, except for Q1 and Q2 which are “upside down”. Put R17 with the led on the top side, and the Emitter and GND on the bottom side. It’s a useful convention. It helps with quickly spotting errors.
Your schematic around U3 (LM2596) is very wrong. D1 is shorted between “GND” left and “GND” right. C1 is also shorted, the wiring is not correct for an SMPS and it’s unusual to connect the LED directly to the switching output. SMPS circuits also always need buffer (and probably decoupling) capacitors on their input, because it sucks short current peaks out of the input supply voltage. Pin 5 (on/off also looks wrongly connected, but I have not verified it with the datasheet.
There are a few wires drawn over a symbol, which is never Ideal. but I do find the wiring across U1 a “reasonable compromise”. But there is no excuse to draw a wire right though C6 (Unless it’s a “feed through capacitor”) or draw wires though texts. (RefDes of R2, U1) "I2C connector (Debug Display) would be more logical to put that in two lines (in a text box).
1 Like
And its an obsolete component . . . but lets not split hairs 
1 Like
Nono, let’s split hairs, it’s ok to fix the design, this will have to go on a production environment and be stable for years potentially… Any advice is to be taken seriously!
Which other component would you suggest?
Thank you!
Source? (of that info).
I see no indication of this @ti:
Digikey has around 70 variants of the LM2596 on stock, maybe just some variants are deemed to be(come) obsolete?
As Paul said use power symbols instead of labels. It will make things a lot easier to read.
For example:
Looks a lot easier to read like this:
And can be moved out of the way.
Using labels for power is confusing like for example around J6 where is 3.3V connected?
A few general rules to make the schematic easier to read:
- positive voltages point up and GND and negative point down.
- NPN transistors - orient the symbol so the arrow points down
- Don’t run wires through components. (U1)
Use non connected flags and run a ERC check.
The LED driver around Q1 does not make sense. With a bit of re-arranging it looks like this:
Top of R14 should be connected to some supply and not back to IO2?
1 Like
Thank you all, i’ll update the schematics and check everything, i resolved some ERC errors and now i’ll organize everything better, i’ll show you the result if you happen to be interested.
Sorry i don’t understand, which SVR component should i use?
What is an SVR?
I do not believe in obsolescence for the LM2596 any time soon. Some specific variants may go out of production, but there are plenty of others left. Mouser (as indicated by Raptor) sells them from both Ti and Onsemi. On LCSC, you see them from TWGMC, UMW, HGSEMI, GR, HANCHIP and probably more, but I stopped scrolling down the list. (The list is 182 items long.)
1 Like
There is this other thing i figured out, the ESP32-WROOM-32D Obsolescence in 2031, which yes, is very far away but still they do not recommend it’s usage in new designs…
They instead lean toward the new version which is this it seems: https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32e_esp32-wroom-32ue_datasheet_en.pdf
What do you think?
The new version costs a lot more than the old one but still… they are both so cheap that will be like counting sand grains in a beach.
I think this is a KiCad forum . . .
You are right, i’m sorry
Upon Schematic re-organization i stumbled upon the available space in a single Schematic sheet, i cannot find the Place > Add Sheet button, is it normal?
Either . . .
Or . . .
Or . . .
S
1 Like
We don’t know what version you use, know we?
Application: KiCad Schematic Editor x86_64 on x86_64
Version: 9.0.2-2.fc42, release build
Libraries:
wxWidgets 3.2.8
FreeType 2.13.3
HarfBuzz 10.4.0
FontConfig 2.16.0
libcurl/8.11.1 OpenSSL/3.2.4 zlib/1.3.1.zlib-ng brotli/1.1.0 libidn2/2.3.8 libpsl/0.21.5 libssh/0.11.1/openssl/zlib nghttp2/1.64.0 OpenLDAP/2.6.9
Platform: Fedora Linux 42 (Workstation Edition), 64 bit, Little endian, wxGTK, X11, gnome, wayland
OpenGL: AMD, AMD Radeon Graphics (radeonsi, renoir, ACO, DRM 3.61, 6.14.9-300.fc42.x86_64), 4.6 (Compatibility Profile) Mesa 25.0.7
Build Info:
Date: May 16 2025 00:00:00
wxWidgets: 3.2.8 (wchar_t,wx containers) GTK+ 3.24
Boost: 1.83.0
OCC: 7.8.1
Curl: 8.11.1
ngspice: 44.2
Compiler: GCC 15.1.1 with C++ ABI 1020
KICAD_IPC_API=ON
Locale:
Lang: en_US
Enc: UTF-8
Num: 1,234.5
Encoded кΩ丈: D0BACEA9E4B888 (sys), D0BACEA9E4B888 (utf8)