Design feedback

[pylogger-html]

I just saw the youtube video you posted and it looks like you've made a lot of good progress on this project. I decided to check out your schematic/layout and here's some feedback. I just did a quick review of it, so if I got an old design let me know (I went dev and the latest "complete looking" board).

I did not review the firmware, but I do have some STM experience so maybe I'll be inspired to do that later.

• You should start using 0201 components for all your smaller cap's (anything below 100nF) and small resistors (pull-ups, 0 ohm jumpers, etc). Most fab places do not charge extra anymore for this size (jlcpcb hasn't for several years) and those parts can be cheaper sometimes than 0402's. I realize reworking 0201's is tough, but for all the little bypass caps you probably won't be reworking those. Plus the design seems more refined now.

• 100mil is standard for headers, but they do make 50mil headers. Might save you some room if you're doing a multi-board thing (you make the LCD board right?)

• Kicad now supports multiple sheets in version 7.0, so you could split up the schematic into logical blocks (maybe power, uC/com/display, motor control). The board isn't too complex though, so it's kind of a toss-up.

• The routing around C38 is really tight, but you have tons of room on the back layer below it. Same with the motor controller (C40, D6, D5, C11 could all go on the back side. keep the 100n bypass caps on the same side)

• J2 didn't load for me, but is this just a 2-pin terminal block? (the green connectors with screw adjusts)

• Do you really need an 8MHz crystal? The STM32 has a decent (+/- 2% over full temp range) RC oscillator called the HSI that runs at 8MHz. This would save you a bit of cost and a "giant" part in the middle of your board.

• If you want an easy flashing header that adds zero cost, look into tag-connect. Another option would be writing a little bootloader in the STM32 that has just enough code to do ethernet IO & flash memory. Then you could do all the programming entirely with ethernet (you flash the bootloader via a header, then upgrades are done via ethernet).
  ** To do this you can create a separate linker file and relocate your code somewhere else in memory. The STM32 will boot into the bootloader, the bootloader will check the "upgrade image" and if it's okay boot from it. Then you just need a mechanism to revert back to the upgrade image if needed (push button maybe?)

• You should look into adding ESD/EMI protection to all exposed ports and accessibly supply rails (probably 5V, must you can skip 3.3V). There are single chip options for USB and you'll need them for the stepper motor driver. The TMC2209 has example protection circuitry in the datasheet that you should have. Aim for at least 16kV rating on the ESD stuff (32kV would be better, but it isn't required).

Crazy ideas:

• Switch to USB-C for power and get one chip that drives the CC1/2 lines so you can get 28-48V via USB power delivery. Yeah, I old PD 3.0 doesn't go past 20V, but the new USB PD standard supports 28V/36V/48V at up to 5A. You can still use the DP/DM lines for the UART. Here's a chip that'll do PD 3.1 (28V): https://en.hynetek.com/pddrp.html HUSB311

• I know you just switched to a new uC, but have you looked at the RPI Pico? It has a dual core M0 running at >100MHz and it's cheaper than the STM ($0.97 vs $1.41 at JLCPCB, although you'll need a crystal & flash for it - so probably same cost). The C/C++ API for the RPI Pico is really well tested and you can probably port a lot of code. No motor controller though, so you'll probably need to dedicate one core to the motor/feedback sensor.

• For the ethernet control format, how about supporting a queue of commands with precise timing? You could then build up a small language of motor operation and queue them all up on the controller (ex: sweep 20 degrees at x steps/s, wait 40ms, repeat 10 times)

[Neumi]

Very good and valuable feedback. Makes sense to me and I will change it on the next version.

The RP2040 might be a good candidate. I only knew it running micro python and didn't like it. Having two cores with C++ would actually be very beneficial for the motor control.
USB PD was on the list of requests but I didn't want too many chips/complex parts on the board for now and keep them all on one side for cost reasons. Maybe this could change in the future. (but for now, keep complexity low)
The Ethernet software update would be very cool. But it should be easy to understand and doable for the average maker.
ESD/EMI protection was not really taken care of due to a lack of knowledge and testing equipment.
Tag-connect is cool, but I think having USB is also cool if you only need to run one Ethersweep controller from your computer. Not using the USB/Serial bootloader feels like a waste of potential.
A 2% oscillator would most likely be okay. It might be good to free up some space.
The pin headers have to be 16mm long. I'm not sure if you get them with the low pitch. So I kept the normal ones.
J2 is an xt30 connector. Standard in RC copters and planes and some motor controllers. Maybe this could change to a more professional/strain-reliefed connector.

Thanks again!

[gchenfc]

Just a quick note on RP2040, IIRC its ADC is not super great; something like 1 hardware ADC multiplexed to 3 pins and low bit resolution. I haven't looked at your stepper driver code to see how much real closed loop servo control you're doing, but I did see you have a pair of shunt resistors so the RP2040's ADCs might not be suitable depending on the accuracy you're targeting.

Also would like to upvote the ESD protection - adding protection and ideally opto-isolating anything going in/out. Not sure about the projects you typically do, but in my medium-sized projects, anything without opto-isolation of communication ports always blows up eventually due to EMI & ground loops.

And this is an unrelated comment, but I personally would love to see (eg in README's):

• timing precision / latency + reliability (# packets lost) tests, ideally with e.g. 3 motors running simultaneously, including with motors enabled since EMI is presumably significant
• rough bandwidth figures you'd be able to achieve - I assume 100Mbps ethernet so maybe 250Hz or something? Not sure
• a rough JLCPCB cost estimate in one of the README's would save the trouble of uploading the zip to jlc to investigate whether I want to more seriously consider trying out a run of these boards
• schematic & board pdf's uploaded to github, so I can do a review without cloning :)

Super cool work and I'm really excited by this!

[pylogger-html]

Yeah, that's a good point about the ADC. You can improve the accuracy a bit (https://youtu.be/F0o1C7nEgw0?si=pLa2Wp7sBuP2In6G&t=422), but still the number of channels is kinda rough compared to the STM32.

Getting the UART output working with the RP2040 in C/C++ is super easy and you can redefine the USB descriptor if needed (vid/pid/sn/description can all be redefined with pre-processor macros). Can't really say if ethernet will be easy or not, but Bluetooth was pretty simple.

I agree that Opto-isolators would be great, but it'll be tough to do that for every stepper motor signal. RX/TX are easy, but then you have the analog signals to worry about (current shunt voltages, power supplies, etc). Totally doable, but you'll probably have to totally redo the layout.

Couple more items:

• You're using a ~300uF aluminum capacitor which I think has <1A ripple current rating (my translated datasheet for the part could be wrong), but you're probably using more than that to drive the stepper. Aluminum polymer caps can do 5-10x more current, they're more reliable, have better failure modes, but they cost more. You can probably get away with a bit less voltage de-rating too (I have a commercial design with 35V alum-poly caps running at 33V). The DC current isn't the issue here, but the instantaneous peak current you're getting from the cap and how often that happens.

• I saw in one video that you cut PCB's with a saw. If you do that, be sure to wear a mask due to the harmful dust. A paper cutter can work too and should easily slice through thinner boards (32 mil should be easy, might need a few passes for 62 mil)

*RF chokes are nice to have on your supply. You can use to block conducted emissions from cables or isolate some part of your analog circuit (can improve ADC performance).

SW - STM32 code

• wow, I didn't realize arduino like stuff would run on the STM32. I thought you'd go the STM32IDE & STM32CubeMX route, but a networking stack would be a challenge. I don't do much work with this API, so I'll skip this.

SW - I looked in python on the master/main branch

• You've got your venv in version control (venv should always be in your .gitignore and never in a commit). You should have a setup.py for your project or requirements.txt to build your venv. You can do "pip freeze > requirements.txt" to generate this and it'll help if anyone else runs this. I like to do some had refinements of mine to just have the few high level packages I actually need and let the maintainers deal with dependencies.
  ** pycharm should recognize these files once you have them and it'll make setting up your project on another machine really easy.

• I recommend making an "ethersweep" python package that has a central class object and member routines that abstract the details of sockets, command formating (json, url's, etc). For development you can install this as a local editable module with "pip install -e ." provided you have a setup.py. Your code would then do something like this:

from ethersweep import ethersweep
foo = ethersweep()
foo.connect(ip=192.168.1.55, port=8888)
foo.info() # returns motor SN, sw/hw rev, maybe a user configurable name
foo.getpos() # returns the stepper angle
foo.hold() # holds current position
foo.getStatus() # returns currents/voltages
foo.setpos(angle=33.3, angPerSec=0.1) #you can use **kwargs to define several possible parameters, like deltaAngle, absAngle, moveTime. This way you don't have a ton of required parameters)
foo.close()

• Once you have this basic framework going, you'll need automated tests (to test python & your firmware). I like using pytest and I can give you a ton a tips when you get to that stage.