Modbus support for STM32F4xx

[dresco]

Just wondering, is there a plan for Modbus support in the STM32F4xx driver?

I ask because I'm fooling around with prototyping a Modbus based control panel, and had just started looking at plugin development for further testing. But the grblHAL board sitting on my desk is an F411 Nucleo, so didn't take me long to hit my first issue ;)

[terjeio]

The driver has a secondary UART channel that can be used for ModBus, and there is a lighweight plugin in the spindle plugins folder. This can be used for other purposes as well and enabling it should be easy as there is code for that present in the driver. Setting MODBUS_ENABLE to 1 in my_machine.h would do?

A full ModBus protocol implementation is not planned. However, I have ported the FreeModbus Library by Christian Walter to a couple of TI processors - this could be added as a plugin if a full implementation is required?

[terjeio]

I have just uploaded some changes to the test branch, code was not finished... At least the TX interrupt fires so maybe it works now.

[dresco]

Thanks Terje, the strange thing is that I can see it the interrupt handler loading each byte from the modbus command into the DR data register, but the output on PA9 never toggles. (Have verified the hardware setup with a simple STMCube app that writes to USART1, which all works as expected)..

I'm left scratching my head now. If you get a chance, and you have a Nucleo F411 board, would you be able to check for the same behaviour at some point?

[terjeio]

Working for me - at least there is activity on the TX pin that looks good on the scope. Is your problem with the latest update? The previous version did not initialise the UART.

[dresco]

Thanks. Yep, I pulled the latest commits from the test branch & rebuilt, but is good to know it has to be something daft at my end. Will have another try tomorrow..

[dresco]

Aha, found my issue (eventually)! I was using the Generic Uno map, which assigns A9/A10 to stepper outputs..

[phil-barrett]

By the way, if you are looking at making changes for Modbus on the F411, the STM32F4xx UART has a half-duplex option that would fit well will RS-485 and save a pin.

[phil-barrett]

The newer layout is not currently available. The serial daughter card mounting holes for the pro board are different. I tried to keep them the same but wasn't able to. Will be posting that and the I2C daughter card outlines/holes once I have completely finalized the Pro board (very close now).

For what it is worth, I have added a transmit direction pin to the serial daughter card header for the pro board.

[terjeio]

For what it is worth, I have added a transmit direction pin to the serial daughter card header for the pro board.

Great, driver.c should be updated to handle that when the pin is defined.

[phil-barrett]

Well, since the Teensy is maxed out on pins, I made it solder-bridge configurable for one of 4 possible pins: Aux2, Lim A, Lim B and KeyPad Strobe. So, it will take a little config work in the pro map file, too.

To be honest, the 4 pins were a guess. Maybe I should switch KPStrobe with Aux 1? I2C is getting more important, not less. Or one of the digital inputs? Trying to go for maximum flexibility for different use cases.

I really like the STM32 half duplex feature - unfortunately, it doesn't look like iMXRTs have that.

[phomann]

Hi,
You can get around using a direction pin by having the UART TX pin of the micro drive the TX enable input on the RS-485 driver chip and then just tie the TX pin on the RS-485 chip to a logic 1.

Cheers

Peter

[terjeio]

To be honest, the 4 pins were a guess. Maybe I should switch KPStrobe with Aux 1? I2C is getting more important, not less. Or one of the digital inputs? Trying to go for maximum flexibility for different use cases.

AUXINPUT0 (pin 36) can be used with little loss of optional functionality?

You can get around using a direction pin by having the UART TX pin of the micro drive the TX enable input on the RS-485 driver chip and then just tie the TX pin on the RS-485 chip to a logic 1.

Would it not be better to get tranceivers with auto-direction circuitry - or is this the way it is usually implemented?