Improved UART handling

[hfog]

This fixes a number of problems encountered when connecting Octoprint to the TFT over UART3 (or 4).
When Octoprint is connected over UART, the TFT can now be in either Touch mode or Emulation mode and it will still work. You can even switch between the two during printing from Octoprint (although I think there is still some risk of dropping a command - more testing is needed there).
It also passes unsolicited ack messages through to Octoprint, which enables Octoprint to stay connected when using autoreporting (ex: M105 T2).
The code is also now smart enough to not poll for temps if it's already passing temp messages on to Octoprint, avoiding unnecessary traffic over the serial line.
The next step from this would be to come up with a way for the TFT to reliably detect when a print is started from Octoprint. I can't think of any reliable way to do this though without requiring Octoprint to send some additional messages to the TFT, similar to what Marlin sends during an SD print. Technically this isn't really necessary though as the current behavior works quite well and it wouldn't really add much.

This fixes a number of issues but the primary one is bigtreetech#281

[hfog]

Apologies for forking from your repo instead of the main one but I really wanted the new menu functionality you've been working on and this turned out to be a more stable place to build from, given the problems I was trying to solve.

[guruathwal]

Great work... I do not use Octoprint so I can not test it.
it will be nice if @gneu42 , @Scope666 & @JWolfJr can test.

Also there need to be an option to enable / disable this for users who do not use Octoprint and use USB to connect the main board to PC. This may interfere when printing via PC with 12864 emulator enabled on TFT.

[Scope666]

Great work... I do not use Octoprint so I can not test it.
it will be nice if @gneu42 , @Scope666 & @JWolfJr can test.

My original TFT35 was returned to Amazon because of all the Octoprint issues, BUT BTT is sending me one from China as a result of my original SKR Mini E3 having bad driver issues. I'll definitely test but it will take awhile before it arrives.

[hfog]

Great work... I do not use Octoprint so I can not test it.
it will be nice if @gneu42 , @Scope666 & @JWolfJr can test.

Also there need to be an option to enable / disable this for users who do not use Octoprint and use USB to connect the main board to PC. This may interfere when printing via PC with 12864 emulator enabled on TFT.

Agreed. If you comment out #CLEAN_MODE_SWITCHING_SUPPORT in config.h then that will disable the polling when in emulator mode. If you would rather put that behind a setting in the setting menu then be my guest.

Along similar lines, I'm fairly sure that the firmware is interacting with the serial port even with that code disabled (before my changes). See this conversation: bigtreetech/BTT-TFT35-E3-V3.0#10

[hfog]

And while I have your eyes, I have a couple of questions.

1. Is there any logging going on in the firmware, and if so, how does one enable/disable it and get access to the generated logs.
2. Is there any facility for instrumenting for performance data? I'd love to know which routines are using the most cycles and why.
3. What is the recommended procedure for hooking up a debugger to the TFT? There must be a way to do it. Right?

[JWolfJr]

I'd be happy to check this out. A couple of questions though. Should I still have the octopi hooked up through the USB cable? Also use this version of Marlin and uncomment clean mode switching is all that is needed?

[hfog]

@JWolfJr This is primarily for hooking octopi up through one of the UART ports on the TFT. The primary benefit to doing this is that the TFT becomes aware of the traffic coming from Octoprint so it can keep its locations, temps, fan settings, etc. up to date and it ensures that Marlin only sees a single serial stream, reducing possible contention on the device. The secondary benefit is that you can switch between touch mode and emulation mode and Octoprint will still work when hooked up this way.
It shouldn't make using Octoprint over USB any worse but that isn't the primary use case and you won't get the benefits if you don't hook Octoprint to the TFT.
See my comments here: bigtreetech/BTT-TFT35-E3-V3.0#10 if you need to know how to hook your Octopi to the TFT.
And this is not a version of Marlin. This is a version of the TFT firmware. You'll have to build it with #CLEAN_MODE_SWITCHING_SUPPORT uncommented (which it is by default) and flash your TFT.

[JWolfJr]

Ok, gotcha. I got the specs how to hook it up to the tft, from what I saw it's going to the wifi headers? I apologise, I thought I was on the MB GitHub page. I'm at work now, I will give this a try soon as possible and report back . Thank you.

[hfog]

You could hook it through the wifi headers but honestly, it's easier to hook it to UART3 or UART4.
Any of the serial inputs on the TFT should work.

[hfog]

Oh and BTW, You only need CLEAN_MODE_SWITCHING_SUPPORT if you want to be able to drive Octoprint through the TFT while in emulation mode. If you're only interested in driving Octoprint through the TFT in touch mode then you don't need this uncommented.

[JWolfJr]

I'm interested in both. I'll build the updated version and try it out. Thanks for clarifying.

[guruathwal]

@hfog

Agreed. If you comment out #CLEAN_MODE_SWITCHING_SUPPORT in config.h then that will disable the polling when in emulator mode. If you would rather put that behind a setting in the setting menu then be my guest.

ok. sorry I failed to review the code at that time.

Along similar lines, I'm fairly sure that the firmware is interacting with the serial port even with that code disabled (before my changes). See this conversation: bigtreetech/BTT-TFT35-E3-V3.0#10

It does not look like there is any thing related to serial comm. in the Simulator Loop and in the function calls through it (this need more digging into the code):

BIGTREETECH-TouchScreenFirmware/TFT/src/User/API/UI/ST7920_Simulator.c

Lines 139 to 156 in 5777f41

	while(infoMenu.menu[infoMenu.cur] == menuST7920)
	{
	while(SPISlave.rIndex != SPISlave.wIndex)
	{
	ST7920_ParseRecv(SPISlave.data[SPISlave.rIndex]);
	SPISlave.rIndex = (SPISlave.rIndex + 1) % SPI_SLAVE_MAX;
	}
	Touch_Sw(LCD_ReadTouch());
	if(LCD_BtnTouch(LCD_BUTTON_INTERVALS))
	Touch_Sw(1);
	#if LCD_ENCODER_SUPPORT
	loopCheckMode();
	#endif
	}

It may be possible to confirm this by connecting the TFT Controller to PC via USB-Serial instead the main board. One point to note is that the serial pins on the TFT Controller are being set to Input Floating State when the serial is disconnected:

BIGTREETECH-TouchScreenFirmware/TFT/src/User/Hal/stm32f10x/usart.c

Lines 20 to 25 in 7a370bd

	void USART_GPIO_DeInit(uint8_t port)
	{
	//set tx/rx to input
	GPIO_InitSet(uart_tx[port], MGPIO_MODE_IPN, 0);
	GPIO_InitSet(uart_rx[port], MGPIO_MODE_IPN, 0);
	}

And while I have your eyes, I have a couple of questions.

1. Is there any logging going on in the firmware, and if so, how does one enable/disable it and get access to the generated logs.
2. Is there any facility for instrumenting for performance data? I'd love to know which routines are using the most cycles and why.
3. What is the recommended procedure for hooking up a debugger to the TFT? There must be a way to do it. Right?

There is no logging/debugging code in the actual firmware and the comments are in Chinese which also got scrambled when the commits were merged due to wrong text encoding, but the libraries used are mostly from STMICROELECTRONICS. So it should be possible to debug it using the serial wire debugging (SWD) port on the device using ST-LINK. I have not gone any further into this.
Every page on the firmware has its own while loop, it should not be that hard to point out the current loop when it is on a certain page.
Loop inside loop also means that the variables in the parent function of the parent loop will also stay in the memory until the the end of the function??

[hfog]

One point to note is that the serial pins on the TFT Controller are being set to Input Floating State when the serial is disconnected:

BIGTREETECH-TouchScreenFirmware/TFT/src/User/Hal/stm32f10x/usart.c

Lines 20 to 25 in 7a370bd

	void USART_GPIO_DeInit(uint8_t port)
	{
	//set tx/rx to input
	GPIO_InitSet(uart_tx[port], MGPIO_MODE_IPN, 0);
	GPIO_InitSet(uart_rx[port], MGPIO_MODE_IPN, 0);
	}

Which is why I've made the changes I've made in Mode.c. When CLEAN_MODE_SWITCHING_SUPPORT is defined, the serial resources are left initialized when you switch out of Touch mode.

[gilliands]

Tested on the TFT35 E3 V3 with an ESP-01S and a TFT24 V1.1 with an ESP12-E and confirmed working in emulation mode. Great work.

[hfog]

Thanks!