Ideas for next revision

[MitchBradley]

• Schmitt trigger on limit and probe inputs for better noise immunity. For example 74AHC14 (6 channels - need 2 of them, 12 cents ea from LCSC) or NL27WZ17 (dual, need 4; LCSC has them for < 6 cents). Either way it is about 25 cents.
• And/or optocouplers on the inputs to make the board "bulletproof" (<- idea for board name).
• Add 4 pads at 0.1" or 2.5mm pitch in parallel with the terminal block, so either a JST XH 2.5 connector or dupont pins could be optionally stuffed, thus permitting easy plug-in of the connectors that are commonly found on NEMA 17 motors. If you don't want to make the board larger, the pads could be on the bottom for SMT connectors. Smaller is not always better when you are trying to connect a bunch of cables...
• Bulk decoupling cap near ESP32 5V input.
• Layout all pin header connectors on a global 0.1" grid so that shields that span connectors can be made from protoboard. For example a DB25 interface shield that picks up step/dir/ena from multiple pololu sockets and also inputs from the input module socket.
• Add series resistors, say 50R, to the shift register outputs, to reduce edge rates when the outputs go directly (via pololu socket bridge adapters) to external lines. Could put the resistors on the adapters but then they are not just wires.

[bdring]

Thanks

2 sided SMT would be very expensive for just one set of parts. I could put the pattern in front of the terminal blocks (unsoldered). If you installed the connector you could still use the terminal block in the vertical mode only.

[MitchBradley]

Either way. For the bottom mounted SMT thing, I was thinking that it would not be stuffed, just the pads so a user could hand solder if they wanted. Addendum: The PCB layout for the SMT version extends to 11 mm from the board edge, so the bottom mount idea would not work without more space. You would need something like 4 mm extra to have room for the terminal block holes.

[MitchBradley]

On my printer board the 0.1 pads are between the stepper module and the terminal block, but that arrangement needs a little extra space. I am less impressed with tightly packed boards than I used to be, having recently refurbished two 3D printers with RAMPSy boards. Fumbling with all the closely spaced connectors gets tedious. Making the control board as small as possible just doesn't seem all that valuable for a DIY machine that is not likely to be optimized for space in every possible dimension.

[bdring]

Do you have a SMT part number in mind. I would like to look at the FP.

[MitchBradley]

The JST part is S4B-XH-SM4-TB The DigiKey PN is 455-2262-1-ND

[MitchBradley]

Optocoupled inputs? PC817 optos are 5 cents.

[bdring]

@MitchBradley This is a circuit I used on another controller. Do you think there is a way to eliminate the diag jumpers? Maybe use an in-line resistor to protect any fighting outputs.

[KingMo5h]

For what do you use these jumpers, do you even need them? If i understand Diag right, it pulls the 3V3 to ground too. I mean the only problem could happen when you have an external sensor. Then both of them can give u a stop or an error but isnt that even better? Is there a possibilty to deactivate Stallguard by software? Btw. why u dont use EL847 or similar with 4 inputs and outputs. And can you tell me when the i2c stuff is ready? I designed a pcb, but iam gonna wait till the software is done.

[KingMo5h]

Also i would recomment you a big capacitor in the 5v rail in front of the esp32, since the esp32 sucks at wifi up to 200ma and can even reach 400ma for a short time and that causes the esp32 to fail/reboot. Iam not sure if this ever happend for your boards. Got it from this page (german):https://arduino-hannover.de/2018/07/25/die-tuecken-der-esp32-stromversorgung/

[MitchBradley]

1. @KingMo5h is correct that it is possible to connect the DIAG0 or DIAG1 output from a TMC2130 or TMC5160 directly across the optocoupler output, since DIAG0/1 defaults to open-drain operation, active low on error. TMC2209 cannot be used this way, since its DIAG is totem-pole, active high. References: TMC2130 Datasheet Section 16 Page 72 TMC5160 Datasheet Section 16 Page 97 TMC2209 Datasheet Section 15.4 Page 66 To use TMC2209 without jumpers, it would be necessary to interpose an open collector buffer, or the equivalent made from transistors, between the DIAG output and the optocoupler transistor outputs.
2. 4-channel optoisolators would certainly work. When I checked pricing at various distributors, one-channel optos were more cost-effective - about half the per-channel price of x4 optos. It is a tradeoff between cost and board real estate and board layout and assembly cost.
3. A bulk decoupling cap near the ESP32 5V input would indeed be a good idea. I don't know if @bdring has experienced any of the boot failures cited, but it's good engineering practice to have one.
4. Regarding "when will the i2c stuff be ready": Do you mean I2S instead of I2C? The I2S code is working pretty well right now, certainly well enough for beta testing. It is in the "i2s" branch. We hope to promote it to the Devt stage within the next week or so - but "hope" is not the same as "will be". There is also some working code to use I2C input devices in PR#358.

[bdring]

I was worried about abuse. Like if the TMC was driving high and a switch closed.

[MitchBradley]

The TMC2130/5160 default is correct - open-drain - so the only way for it to drive high would be to actively reconfigure the DIAGn output to push-pull by writing 1 to bit 12 or 13 of the GCONF register. Clearly it was designed to be wire-or'ed - and it seems they got that wrong on TMC2209 and then fixed it.

[KingMo5h]

Thanks for clarify that, i thought the had all the same diag layout. @MitchBradley I would also recomment at least 12v for the endstops, since the most of them need at leat 12v dc. Iam talking about the inductive or capacity ones. You could use the 12v on one side of the optos and on the other the normal 3v3 for the signal to the esp.

@bdring Regarding to the problem with the stallguard jumpers you could maybe use AND-Gates, so if one of both is giving a low state the output to the esp also low. But this will still not work for the tmc2209 since it drives high on failure.

[bdring]

Prox sensor

Currently the circuit uses an isolated 5v power supply. It would need to find a cheap isolated 12v. That either runs off 5v or 12v to 24v. The resistor should be moved to the gnd side.

Those are 3 wire sensors so I would need to add more terminals. I am not sure it is worth the added cost and size for the few people that would use them.

[bdring]

I wonder if an input module concept, similar in concept to the spindle modules might be a good idea. I t could allow for different types of sensors, voltages and connection types.

[KingMo5h]

Sounds great but it would better if the modules would be more universal in my opinion. So you can put any module in any slot. But this would be an overkill, I guess. Iam talking about the spindle modules. I assume its easier to do it universal for the input module, since they only need I0 Pins. Do you want to put the power supply on the module pcb?

[KingMo5h]

Or do your slots are universal?

[MitchBradley]

Let's investigate the ramifications of input modules and universal modules. I think it could work. It would require routing more signals over to the module area. The connector would need more pins, but modules could mate with only some of the pins if that would be useful.

Another possibility would be to use I2C I/O expanders, or I2S input expanders. We have code for the former already; the latter would require some more software work.

[bdring]

The size might not be the same as a spindle module. I'll try a few ideas and see what happens.

I think the an input module could be designed for about 4 inputs each. That way a 3 axis might use one and a 6 axis would use 2.

I think they should be able to be used without I2C. If you wanted to put an I2C or ADC on an input module you could as long as the 4 I/O used can support those.

Any features should go on the module, including optos, power supplies, filters, etc.

[MitchBradley]

I2C needs only 2 pins, one output only and one bidirectional. And then use a third for interrupt. An MCP23017 would give you 16 external input/outputs in in any combination, limited by connector space and supporting circuitry for signal conditioning. Good I2C ADCs are also readily available. Or talk to an ATTiny via I2C and get GPIOs and ADC in the same part.

[MitchBradley]

MCP23017 claims to have Schmitt trigger inputs - ref http://ww1.microchip.com/downloads/en/devicedoc/20001952c.pdf section 1.1. That would provide some noise immunity to work around the problem that ESP32 inputs basically suck.

[KingMo5h]

I dont know how good your wifi is on this board but i read some issues with the wifi connection, if the antenna is on the board side and not on the board edge. It is also recommended here (https://www.espressif.com/sites/default/files/documentation/esp32_hardware_design_guidelines_en.pdf, page 10).

[bdring]

That is primarily directed at the module not the dev kit boards. You don't want to lay the antenna down directly on copper. The dev kits mount about 11 mm above the board.

I usually buy the official Esprissif module where the antenna extends.

Some do not extend the antenna, but probably don't put copper there.

You can also buy external antenna versions.

[Bleeptech]

I/O expansion thoughts..

Since I2S0 on the ESP32 module is already being leveraged to provide 32 digital outputs why not invert the process on I2S1 ? This will give 32 digital inputs and 32 digital outputs while only using 6 I/O lines..

4 - 74HC165s and a CD4050 should provide 32 inputs and handle the 3.3V<>5V level shifing. This will require 3.3V and 5V power rails but those are already on your module specification..

Inputs can be made 24V tolerant with the addition of a 220ohm resistor and a 3.6V zener diode on each input line.. Chip_Select is shown broken out here but it can simply be tied HIGH..

RTFM 3 times and you might only get flamed once..

[MitchBradley]

I2S input is definitely a possibility, and we chose the I2SO naming convention to allow I2SI as an option. 74xx597 is an alternative to '165. The advantage of '597 is that the inputs are edge-triggered, whereas '165 are latched. Edge triggered is more compatible with the I2S framing scheme. On the other hand, there is at least one '165 (Nexperia 74LV165) with Schmitt Trigger inputs. It is a little more difficult to support interrupt-on-change with I2S inputs compared to I2C, but do-able.

I think it might be possible to use the same clock and framing lines for I2SO and I2S1, reducing the number of additional GPIOs to 1.

[Bleeptech]

That was another possibility I was exploring was re-using the I2S0_WS and I2S0_BCK.. But I thought it might turn into a major headache in the code to synchronise signals between I2S0 and I2S1 reliably..

[MitchBradley]

I have not looked at this aspect of the ESP32 I2S interface in enough detail to know for sure. On another SoC where I did extensive work with an I2S audio codec, there was an option to use a common clock for input and output. I'm just guessing that is a common enough use case that the ESP32 might support it.

That said, I plan to make a very flexible input module around an STM32 microprocessor. They are inexpensive and can do a lot of really useful things, for example offloading functions like display, encoder handling, and a menu system, in addition to bare I/O. I find those possibilities so compelling that I think that is a better use of time than going the I2SI route.

[Bleeptech]

I had considered offloading the inputs to another micro-controller but I don't like the idea of introducing another MCU that can hang, crash or just feed garbage data to a system controlling a laser, spinning cutter or other source of sudden pain..

[INSERT GORY IMAGE HERE]

Non-critical things like displays, bells, whistles, etc no problem but anything where an MCU has to communicate with another MCU in a critical system introduces another point of possible failure..

With TTL ICs a BCK of 320kHz [40MHz max via the I2S ports] can easily be used which will result in a sampling rate of 10kHz per input and then it feeds to the same MCU controlling the driver outputs..

The x4xx165s were chosen for the load latches as the data on the inputs 'now' is what I want as I think that even with my lack of code-fu I can keep the overall latency to <0.005 seconds..

Bleeptech's corollary to Newton's Second Law: Mass * Velocity = "OUCH! That freaking hurt!"

edited to deal with dropped decimal place..

[MitchBradley]

If the clocks are the same as for output, the bit rate is 8 MHz and the frame rate (sample rate) is 250 kHz. Then you can choose how often you want to interrupt the processor to look at the data.

I don't understand what you mean about the latches. The '597s also have input flip flops separate from the shifting stage. The difference is in the details of the control signal sequencing.

I think the latency can be in the 100 us range, with the proviso that there will be CPU load to continually poll it.

There is probably nothing I can say about the other MCU argument; it is hard to counter a FUD (fear, uncertainty, doubt) position.

[MitchBradley]

Let's consider a concrete example of a 14-bit I/O expander using a STM32F030 ($1) which has 15 GPIOs. Use one GPIOs as TxD connected to an ESP32 UART RxD, at a baud rate of 1 MHz. The code on the STM32 is essentially

uint16_t port_data = 0;
while (1) {
   uint16_t new_port_data = IN(PORTA);
   if (new_port_data != port_data) {
      port_data = new_port_data();
      UART_OUT(port_data & 0x7f);
      UART_OUT((port_data >> 7) & 0x7f | 0x80);
   }
}

The ESP32 code interrupts when a character is available and updates the port mask. That only happens when the value changes, so the interrupts are infrequent, timely, and very easy to handle. The latency is on the order of 20 bit times at 1 MHz, so 20 uS.

Making something like that reliable is far easier than what we went through to make the I2S output work correctly. In the I2SO case the effort was worthwhile because the scheme's attributes are a perfect match for stepping. That's not the case for input.

I chose 14 bits because that fits easily on an inexpensive micro. Extending to many more bits is trivial, but would require a part with more pins, and the I/O module format would soon run out of connector space. The latency could be reduced by running the UART faster; it would probably go at least 2 Mhz and maybe 4, but it seems hardly worth it.