Question regards to the repo

[xXHexaKillXx]

Hi i am new to this. I just wondering is the repo be future supported? or is being dropped completely. I also have dwin screen i would like to make use with it. but i notice it hasn't been updated.

[Desuuuu]

Development has pretty much stopped. I somewhat lost interest and my current printer has a different screen.

I planned to add some finishing touches to the most recent version I released (which is customisable) but I have no idea if that will ever happen to be honest.

There might be other people who have picked this project up, I'm not sure. You'll have to search around to find out.

[xXHexaKillXx]

That is a shame. But thank you so much for the dedication to this project.

[slavaz]

Worst to hear it as I have a printer with DWIN touchscreen (https://github.com/slavaz/klipper-cr10Smart) , but I'm newbie in Klipper world, so I have installed stock Klipper, but I'm watching at the project too. In general, I didn't try to install your fork, but I had plans to do it and I'm still watching your project...

Would you tell, please, what are the minimum changes that need to be made to the parent Klipper project in order for TWIN displays to work? Is it possible to implement support of TWIN displays like a plugin for Klipper? In this case, we will have some changes in parent Klipper project (eg. add some API) and we will have separate independent project (Klipper plugin?) with support for TWIN displays...

I would love the idea of TWIN displays and Klipper, but would be great to continue development into parent Klipper project...

[slavaz]

Well, as I see, your 'bus-serial' branch has conflicts with the current 'master' branch from parent repo (because there were some canbus-related changes in stock repo). I think,I can try to rebase your branch, but I have a question: have you tried creating a pull request into stock repo with your changes? If so, why your changes were rejected (what else should be done)? If you haven't tried it - why? :)

I think, it would be nice to push your implementation into the stock repo instead of having a separate repo with its own changes and with constant conflicts while syncing with the parent repo... And I may try to go on this way (merge your changes into parent repo) with your permission (since it's your implementation), but I want to know if we have any pitfalls along the way...

[Desuuuu]

Indeed, the branch hasn't been updated in a while.

I'm not submitting pull requests due to Klipper's contribution guidelines.

I don't have any objection to you (or anyone else) using/modifying my code, whether it is to submit a PR or anything else. Make sure to follow the guidelines though.

[slavaz]

Ok, thanks, lets try to do it. First step is: https://klipper.discourse.group/t/feature-request-extend-protocol-with-uart-commands/2414/7

[slavaz]

@Desuuuu sorry for disturbing you, but I've faced with very interesting situation and looks like I need your little consiltation...

in your 'bus-serial' branch the file 'src/stm32/stm32f0_serial.c' was deleted, but there are several changes of the file in parent 'klipper/master' branch, like:

• f31540b stm32: Minor changes to stm32g0b0 ifdefs
• e33b41a stm32g0: add stm32g0b0 support
• c5d56f4 stm32g4: implement build,usb,can,i2c,spi,serial,adc.
• 972ae4a stm32: Use stm32f0_serial.c on stm32h7 chips
• 26e6ade stm32: fix USART ORE status flag handling

eg, git show 26e6ade src/stm32/stm32f0_serial.c command shows:

diff --git a/src/stm32/stm32f0_serial.c b/src/stm32/stm32f0_serial.c
index c214ed01..da76be42 100644
--- a/src/stm32/stm32f0_serial.c
+++ b/src/stm32/stm32f0_serial.c
@@ -66,7 +66,7 @@ void
 USARTx_IRQHandler(void)
 {
     uint32_t sr = USARTx->ISR;
-    if (sr & (USART_ISR_RXNE | USART_ISR_ORE))
+    if (sr & USART_ISR_RXNE)
         serial_rx_byte(USARTx->RDR);
     if (sr & USART_ISR_TXE && USARTx->CR1 & USART_CR1_TXEIE) {
         uint8_t data;
@@ -93,6 +93,7 @@ serial_init(void)
     uint32_t div = DIV_ROUND_CLOSEST(pclk, CONFIG_SERIAL_BAUD);
     USARTx->BRR = (((div / 16) << USART_BRR_DIV_MANTISSA_Pos)
                    | ((div % 16) << USART_BRR_DIV_FRACTION_Pos));
+    USARTx->CR3 = USART_CR3_OVRDIS; // disable the ORE ISR
     USARTx->CR1 = CR1_FLAGS;
     armcm_enable_irq(USARTx_IRQHandler, USARTx_IRQn, 0);

how these changes should be reflected in your branch? Or may it be ignored at all?

Thanks in advance.

[Desuuuu]

This is because I unified the serial handling across STM32 chips in commit 815fae9 (except for STM32F031 which has too little memory for runtime UART).

I'm sure there's a good reason for these changes (which the commit message will most likely give you), you shouldn't discard them.