Lighter ram memory allocation/possible long beep fix

[kisslorand]

Requirements

BTT TFT of MKS TFT

Description

This is an attempt to reduce the amount of memory allocated for serial ports DMA's buffer. My guess is that only Marlin would send huge chunks of data (see M503 response), the other peripherals would send way much less/shorter data. I do not know what other people have connected to the TFT and what does what. I only assume those deives would be more shy in filling those buffers. I can only test with SD and USB connected to my TFT.

Also I did some changes that I thought would eliminate the random long beeps. While testing my theory I couldn't make my TFT to beep, Spent 2 hours pressing like crazy on the buttons, doing the most abnormal button/menu combinations while printer was printing, halting, heating, moving, etc. Not a single long beep.

Related Issues

#1300 #1294 #1293

To be done

This has to be tested seriously because it's prone to introduce new, unforeseen issues., so people willing to test are really welcome.

[oldman4U]

What exactly has to be tested. I can help but never saw the long beep on my printer.

[kisslorand]

It should be more onboard SD friendly, that was the first thing in my mind that lead to this PR. The whole purpose is to generally have more usable RAM for present and future features.
What to test? Just simply if it doesn't bring new issues, mainly with things connected to the TFT's serial ports.
If you have a perfectly OK system it will not bring anything new, at least for now, it just leaves room for future addons.

[digant73]

@kisslorand
I would define the size of each queue as a new attribute in DMA_CIRCULAR_BUFFER (in Serial.h). E.g. "uint16_t cacheSize;".
Also I would define the size for each queue in Configuration.h (e.g. #define SERIAL_PORT_QUEUE_SIZE 3096) so anyone having specific requirements on some queues size can tune them as they need.
Also MKS TFTs have been limited to 48KB and not 65KB. The limits are defined in the .ld spec file in the project. You can easily verify that simply defining a new array of about 8KB (e.g. uint8_t buf[8000];) and you will get and heap/stack RAM error due to no minimum space left for heap (minimum 8Kb). also 8KB is the minimum for the stack. So the maximum non dynamic RAM you can use is 48KB - 16KB. When you reach this limit you get a compile error because no more minimum space can be reserved to heap or stack

EDIT: I forgot to mention that the new (un)load menu requires FILAMENT_LOAD_UNLOAD_GCODES enabled in Configuration_adv.h (marlin FW). It should be reported in the config.ini file

[Bastlwastl84]

What exactly has to be tested. I can help but never saw the long beep on my printer.

i had tested it with the Buid from 3.12. and war reducing the beep-time to 2ms at tft, than there was no long beep since that, but than i can't hear filament-change beep

[kisslorand]

Than that beep for filament runout must be rewritten, because it was in fact the effect of the bug. There is no long beep defined in this FW.

[kisslorand]

@digant73

I would define the size of each queue as a new attribute in DMA_CIRCULAR_BUFFER (in Serial.h). E.g. "uint16_t cacheSize;".
Also I would define the size for each queue in Configuration.h (e.g. #define SERIAL_PORT_QUEUE_SIZE 3096) so anyone having specific requirements on some queues size can tune them as they need.

Done. (with minor deviation from proposed actions)

Also MKS TFTs have been limited to 48KB and not 65KB. The limits are defined in the .ld spec file in the project. You can easily verify that simply defining a new array of about 8KB (e.g. uint8_t buf[8000];) and you will get and heap/stack RAM error due to no minimum space left for heap (minimum 8Kb). also 8KB is the minimum for the stack. So the maximum non dynamic RAM you can use is 48KB - 16KB. When you reach this limit you get a compile error because no more minimum space can be reserved to heap or stack

Done. MKS TFT now uses its full 64K RAM. (Actually 64K-16 bytes)

EDIT: I forgot to mention that the new (un)load menu requires FILAMENT_LOAD_UNLOAD_GCODES enabled in Configuration_adv.h (marlin FW). It should be reported in the config.ini file

Food for thought for another PR.

Additional work

In the process of playing with the RAM it happened that I saved the bootloader of MKSTFT28. I added it to this PR, someone might find it useful.

To be done

For the moment only MKS TFTs have their 64K RAM enabled so I'll have to check what other boards have actually more than 48K RAM. For those boards I will need testers because I have no way to test how much RAM is used by their bootloader so I can substract it from their max RAM. In the case of MKS boards their bootloader (if they have one) uses 16 bytes of RAM

[oldman4U]

Hi.

I have been testing @mehmetsutas PR for some hours, and there is still one issue left. Hopefully I have some time this coming Tuesday to test your PR. Do you believe your PR could help with the lagging issue, every time the speed is changed, for example? This is the worst issue for me, once all those PR's are merged.

[kisslorand]

. Do you believe your PR could help with the lagging issue, every time the speed is changed, for example? This is the worst issue for me, once all those PR's are merged.

I am not aware of such an issue. Could you please elaborate it?

[kisslorand]

So...
I took some time to check each board. I was shocked that the majority has a very capable MCU with 128K RAM but BTT decided to use only 48K. I guess this is for keeping the compatibility with older TFTs. Only BIGTREE TFT35 V1.0, BIGTREE TFT35 V1.1, BIGTREE TFT35 V1.2, BIGTREE TFT35 V2.0, BIGTREE TFT28 V1.0 have 48K RAM. All the others have 128K RAM !!!
I think it is not anyone else's job but theirs to do something about this, so I will not invest more time in BTT boards RAM usage.

[digant73]

@kisslorand they probably limited the resources just to avoid to abuse of them too quickly

[oldman4U]

@kisslorand they probably limited the resources just to avoid to abuse of them too quickly

You really believe so...;-)

[kisslorand]

Probably the truth is more simple... cough-lazi-cough-ness-cough

[oldman4U]

You mean something like - no time to do it right - or so....

;-)

[radek8]

@kisslorand
Do you want to simulate a long (permanent) beep?
Open a terminal on the TFT
send command M300 S440 P300
a short beep sounds.
exit the terminal with the back button.
A continuous tone sounds.

[kisslorand]

@radek8
Thank you for the hint, good catch!
I was unable to properly diagnose the problem without a repeatable method to trigger the long beep.
Having the possibility to trigger the long beep at will, I was able to find at least one problem that led to that. Hopefully it was the only problem.
The Buzzer.c got a little overhaul, fixed some not obvious bugs also.

[radek8]

I found another place where there was a continuous beep, but your fix solved it. Thank you.

[kisslorand]

The beep was driving me crazy happening at the least expected times, I really hope it will be in the past once this PR is (if) merged.
Regarding the main thing of this PR, the RAM usage, not much feedback came. It's been almost a week, I think no new volunteers will try this PR, so I changed it from draft to be ready to be reviewed.
Will see (if merged) how it will improve or not the "onboard SD loading hanging" issue, will it bring new issues or not.
Really thanks for the help guys!

@bigtreetech Hit that button!

[radek8]

Loading the integrated SD onboard is fine

[ChuckNoxis]

It's beeping a lot less now thanks ! <3
I still had a random beep when navigating through the menus but I don't remember how/where ^^