Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Design feedback #18

Copy link
Copy link

Description

@pylogger-html
Issue body actions

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)

Reactions are currently unavailable

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    Morty Proxy This is a proxified and sanitized view of the page, visit original site.