Max baud rate for UART

[stevempotter]

I see that the UART for the Teensy 4.1 is set to 115200 in this firmware. Why is that? It seems that the Teensy ought to be able to Tx and Rx much faster than that. I saw somewhere on the PJRC forum that its UART uses a 24MHz clock, so that should allow bauds at least 20x faster than 115200.

Has anyone tested out faster baud rates for the Teensy's UART ports?
If I wanted to try this, where are all the settings in the code I would need to alter?

[terjeio]

Has anyone tested out faster baud rates for the Teensy's UART ports?

I have only tested slower rates (for VFD control).

If I wanted to try this, where are all the settings in the code I would need to alter?

iMXRT1062/grblHAL_Teensy4/src/driver.c

Lines 2309 to 2314 in f860aac

	#if USB_SERIAL_CDC
	const io_stream_t *st = usb_serialInit();
	stream_connect(st);
	#else
	stream_connect(serialInit(BAUD_RATE));
	#endif

BAUD_RATE is defined in grbl/stream.h if not provided on the compiler command line.

iMXRT1062/grblHAL_Teensy4/src/driver.c

Lines 2408 to 2420 in f860aac

	#if MPG_MODE == 1
	#if KEYPAD_ENABLE == 2
	if((hal.driver_cap.mpg_mode = stream_mpg_register(stream_open_instance(MPG_STREAM, 115200, NULL), false, keypad_enqueue_keycode)))
	protocol_enqueue_rt_command(mpg_enable);
	#else
	if((hal.driver_cap.mpg_mode = stream_mpg_register(stream_open_instance(MPG_STREAM, 115200, NULL), false, NULL)))
	protocol_enqueue_rt_command(mpg_enable);
	#endif
	#elif MPG_MODE == 2
	hal.driver_cap.mpg_mode = stream_mpg_register(stream_open_instance(MPG_STREAM, 115200, NULL), false, keypad_enqueue_keycode);
	#elif KEYPAD_ENABLE == 2
	stream_open_instance(KEYPAD_STREAM, 115200, keypad_enqueue_keycode);
	#endif

[stevempotter]

Success! (mostly) Thanks, @terjeio
I have edited driver.c starting at line 2408 to use 2000000 baud and verified with my scope that UART bits are 500ns long.

#if MPG_MODE == 1
  #if KEYPAD_ENABLE == 2
    if((hal.driver_cap.mpg_mode = stream_mpg_register(stream_open_instance(MPG_STREAM, 2000000, NULL), false, keypad_enqueue_keycode)))
        protocol_enqueue_rt_command(mpg_enable);
  #else
    if((hal.driver_cap.mpg_mode = stream_mpg_register(stream_open_instance(MPG_STREAM, 2000000, NULL), false, NULL)))
        protocol_enqueue_rt_command(mpg_enable);
  #endif
#elif MPG_MODE == 2
    hal.driver_cap.mpg_mode = stream_mpg_register(stream_open_instance(MPG_STREAM, 2000000, NULL), false, keypad_enqueue_keycode);
#elif KEYPAD_ENABLE == 2
    stream_open_instance(KEYPAD_STREAM, 2000000, keypad_enqueue_keycode);
#endif

I also edited line 82 of config.h to uncomment the checkmode pause option:

// Add a short delay for each block processed in Check Mode to
// avoid overwhelming the sender with fast reply messages.
// This is likely to happen when streaming is done via a protocol where
// the speed is not limited to 115200 baud. An example is native USB streaming.
#define CHECK_MODE_DELAY 2 // ms

However, I am still tweaking the timings of 2000000 baud comm between the Teensy and my pendant receiver (an ESP32-S2) to deal with too-fast responses being lost.

I have seen no garbled chars and the pulses are very clean on the scope so I think both devices can easily handle this speed, which is 17x faster than the default 115200.