[FR] Working TOUCH_UI_FTDI_EVE support #16628
Comments
thinkyhead
added
C: LCD & Controllers
help wanted
Needs: Patch
|
Someone will have to finish porting support for this display into |
|
@thinkyhead maybe you have any idea because the issue with sd card ? |
|
I don't know whether this thread is still active, but I suggest putting a resistor on the MISO line, as someone else had run into problems without one. If in fact there is a software fix, I would find it to be interesting and worth additional investigation. |
Interesting. I do not recommend sharing the SPI bus between the FTDI display and the SD card. If you need to use an SD card, connect it to the SPI pins and run the FTDI display off some other pins using the software SPI option.
No, the display code was developed at LulzBot (I wrote it). We could not use FTDI's closed-source tools so we wrote our own code from scratch. Some menus might get added in the future if anyone pays me to do it. Like right now I doing some work for CocoaPress :) |
I’m watching this issue since I have an FT810 that I couldn’t get working with Marlin’s version on an SKR 1.3 & 1.4 (never tried Fysetc’s fork/don’t have an S6 board). Edit: Here's the related issue with more info and what some of us have tried in the past to get these panels working: #16534 |
thinkyhead
changed the title
|
my touch_eve is arrived (Fysetc 5" (https://es.aliexpress.com/item/4000628057351.html)). i want to test it in a SKR E3 DIP and Ramps+ReARM my first test i have hit the error #16534 (comment). add diff --git a/Marlin/src/HAL/STM32F1/HAL.h b/Marlin/src/HAL/STM32F1/HAL.h
index ff42beb92..48c9e8605 100644
--- a/Marlin/src/HAL/STM32F1/HAL.h
+++ b/Marlin/src/HAL/STM32F1/HAL.h
@@ -47,6 +47,9 @@
#include "msc_sd.h"
#endif
+
+#define pgm_read_ptr_near(addr) pgm_read_ptr(addr)
+
// ------------------------
// Defines
// ------------------------in src/HAL/STM32F1/HAL.h seems silence the error now set a custom pin map add diff --git a/Marlin/src/pins/stm32f1/pins_BTT_SKR_E3_DIP.h b/Marlin/src/pins/stm32f1/pins_BTT_SKR_E3_DIP.h
index fef8eeb61..13f87a099 100644
--- a/Marlin/src/pins/stm32f1/pins_BTT_SKR_E3_DIP.h
+++ b/Marlin/src/pins/stm32f1/pins_BTT_SKR_E3_DIP.h
@@ -220,6 +220,15 @@
#endif // HAS_SPI_LCD
+#if ENABLED(TOUCH_UI_FTDI_EVE)
+ #define CLCD_USE_SOFT_SPI
+ #define CLCD_MOD_RESET EXPA1_08_PIN
+ #define CLCD_SPI_CS EXPA1_04_PIN
+ #define CLCD_SOFT_SPI_MOSI EXPA1_03_PIN
+ #define CLCD_SOFT_SPI_MISO EXPA1_09_PIN
+ #define CLCD_SOFT_SPI_SCLK EXPA1_05_PIN
+#endif // TOUCH_UI_FTDI_EVE
+
//
// SD Support
// after this now fail in: anyone know how fix this? greetings |
|
@sl1pkn07: Yah, it's a mistake in "src/src/lcd/extui/lib/ftdi_eve_touch_ui/screens/advanced_settings_menu.cpp" The lines starting on line 135 which read: Should be: And in "src/lcd/extui/lib/ftdi_eve_touch_ui/screens/about_screen.cpp" Should be: I'll submit a patch. |
|
I’d be interested if you can get this working on that board because I could never get it working on an SKR 1.3/1.4 or E3 series. |
|
Thanks @marciot now build without problem! now, the true's hour. flash the firmware.... i've edited my post with s litte changes about the pinout when use the cr10_tft_pinmap. @thisiskeithb looking with your eyes, is ok? greetings |
|
hardware conected and not works :/ anyone have the pinout of this screen? @GerogeFu ? |
|
@sl1pkn07: Try one of two things:
|
|
nope the 1). the 2) IDK how get the serial console one question. in the S6, is need to conect in EXP2, rigth? i fount this: but for example, in the E3 DIP, the connector is flipped flip the connector (disassemple in the cord and turn 180º) seems now have the rigth connect (at least, the +5/gnd). but the screen is still blank |
|
Without having this board myself, I can' really offer much guidance. There are pin specific configuration options in:
Also, there are board and display specific configurations in:
All these things need to line up correctly for the display to work. If anyone wants to donate one of these displays, I can figure out how to make it work, otherwise this is pretty much all the guidance I can offer. |
|
@marciot: If I can get you some SKR boards, would you be able to help get this TFT/screen type working in |
|
i also create a custom adapter with dupont wires from Fysect S6 EXP2 pinout and CR10_TFT_PINMAP logic in pin_mappings.h not works i also make a diff betwen https://github.com/FYSETC/Marlin-2.0.x-FYSETC/tree/S6/MASTER and marlin-bugfix-2.0.x and i not see related difference with respect the Touch_EVE Diff_fysect_s6_marlin_bugfix-2.0.x.diff.txt maybe need a more power? greetings |
If you were willing to donate an SKR board and a TFT panel of the type you need working, I could look into getting it supported. My guess is that there are parameters that aren't quite right. |
|
Try disabling SD_SUPPORT. At least for starters. It might be an incompatibility there. |
|
I’ll ping BigTreeTech about the boards and get back to you. I only have one FTDI EVE FT810 at the moment and I’m not even sure if it works since I could never get anything to display on the screen. |
|
@thisiskeithb: It's better to take things one step at a time. There are some Arduino sketches here that should light up the display: If you can get that to work, then the next step is to try getting it to work in Marlin and on the LPC chip. |
I gave it a quick test on Arduino Due (they share the same ATSAM3X8E MCU, right?), it works on device, but during compilation there are a lot of warnings like: |
|
@MESlammer: I updated the PR above with a fix for this. Thank you for reporting this bug! |
|
should it after this PR also work with SKR1.3 /1.4 than i would try this tomorrow |
|
@marciot Thanks, I will rebase when this is thru then. @TB1405 As you can test with the SKR 1.3/1.4, can you use EXP2+5V and switch to hardware-SPI for the LPC1768? I know EXP2 is on SPI0 with SSEL0 = P0.16, SCK0 = P0.15, MISO0 = P0.17 and MOSI0 = P0.18 - as the schematics says so. |
|
I checked it out but now SPI_FREQUENCY is missing in SPI.cpp. |
|
Damn it, it builds now, the firmware is flashing but my Cheetah is dead. |
|
Where would be the best place to ask for UI changes and additions? Should i open a new feature request? Best |
|
I tried to repair my Cheetah today and had to give up. Anyways, I cut of the 5V regulator and replaced D14 which connects USB_5V to 5V with a 0R0 resistor in order to supply my display from USB. And with my new adapter-board I am using the original LCD-cable from Creality now: It kind of works but now I have this timeout bug. |
|
The problem with the timeout is this in base_screen.cpp: This is supposed to do the same as the old version: But I really have no idea what TERN_ expands to in the end. @thinkyhead I really do not get what the benefit of using these macros is other than obfuscation. |
Sorry to hear this :(
Having the resolution tied to the board does not work either, because in the past I've exchanged the TFT panels on boards to get different resolutions than the default. You can't do this is the board type is tied to a particular resolution. The font size mapping is sort of a PITA, but it is meant to reduce the load on the CPU by determining font sizes at compile-time. If you have CPU cycles to spare, enable TOUCH_UI_FIT_TEXT and then before drawing any string the code will measure the text and choose a font size that fits the buttons, no matter the display resolution. This is somewhat inefficient though, because it requires the looping through font metrics objects each time a string is drawn. We do use it on our 32-bit boards, with good results.
I made a PR with fix for the timeout bug, for the moment, you can set LCD_TIMEOUT_TO_STATUS to 0 in Configuration_adv.h |
|
Why has pins_FYSETC_CHEETAH.h been modified for TOUCH_UI_FTDI_EVE? And the obfuscation with additional layers of defines is not helping at all. While the resulting pins are correct, the steps in between are all wrong. The first thing is, the footprint of the header is wrong, that is not how the pins are defined for the Cheetah or the RepRap GLCD, that is just the wrong version from Creality. Apart from the incorrect numbering of the pins, BTN_EN1 is connected to PC10 and LCD_RS and LCD_EN are the names from FYSETC for the pins in the Cheetah schematic. Without pins numbers the relation between function, RepRap and µC pin is like this: So how is anyone supposed to look at pin_mappings.h and know what pins are connected? BTN_EN1 does not exist for RepRap on EXP1. LCD_PINS_RS in RepRap Context would be PB14 for the Cheetah. LCD_PINS_ENABLE in RepRap is LCDE, that would make it PC11 for the Cheetah. LCD_PINS_SCK does not exist for RepRap on EXP1. LCD_PINS_D4 in RepRap context would be PC10 for the Cheetah. Please change this back to the original pins_FYSETC_CHEETAH.h and to whatever other pins_ file has been changed in this context. #ifdef CHEETAH_TFT_PINMAP
#ifndef __MARLIN_FIRMWARE__
#error "This pin mapping requires Marlin."
#endif
#define CLCD_MOD_RESET PC11
#define CLCD_SPI_CS PB12
//#define CLCD_USE_SOFT_SPI
#if ENABLED(CLCD_USE_SOFT_SPI)
#define CLCD_SOFT_SPI_MOSI PB15
#define CLCD_SOFT_SPI_MISO PB14
#define CLCD_SOFT_SPI_SCLK PB13
#else
#define CLCD_SPI_BUS 2
#endif
#endif |
@RudolphRiedel: I was not involved in the creation of pin mappings for FYSETC, so I can't speak to the current config, but I will chime in on why my initial pin_mappings for the Rambo and Archim used the RepRapDiscount pins as an intermediary. The reason for this is that many boards already had a 10 pin connector for the RepRapDiscount display and the AlephObjects display uses the same 10 pin connector for compatibility. AFAIK, it is the only board that uses that connector. By defining my new TFT interface pin out in terms of the old, there was at least a chance that the AlephObjects display could be used on any board with the same ribbon cable as used in the RepRapDiscount display, without having to come up with a new pin map. That was the idea, anyway, whether it works in practice I cannot know. But yes, if you are using some non-AlephObjects controller, then the pin mapping could count as obfuscation. You certainly do not need to use it for new boards. |
|
That was not about using the RepRap names per se. Then @sl1pkn07 stepped in and went overboard with it, changed pins_FYSETC_CHEETAH.h and put up annother layer of defines around the pin names - why? |
|
first for all apologizes for all disturb from the schemes the position of the pin cover is the same as other E3 board like the stock, BTT E3/DIP, so I flip the pinheader
because in all pin_foo files, the pinout draw use as reference the gap in the plastic in the right side and pin 1 in the upper left is the same i use to draw the pin connector in the pins_cheetha.h
wich is the same used in BTT_SKR_E3_DIP in first time https://github.com/MarlinFirmware/Marlin/blob/04cea864bcc197a91a162f8cc48cd6588260f8af/Marlin/src/pins/stm32f1/pins_BTT_SKR_E3_DIP.h now, in the cheetha schemas
so yes, the BTN_EN1 and BTN_EN2 is switched, is my enterely fault. sorry about use pin alias instead of real pins. is because i follow the pin_mappings.h scheme, with use alias except the CR10 pinout (what CR10 board?). like the pins_BTT_SKR_E3_DIP.h/pins_BTT_SKR_MINI_E3.h (the board i own and can test. i brougth a cheetha 1.1 and MKS E3D boards for add support for the Fysetc TFT81050 display, but both is still in transit) @marciot @thinkyhead is possible get rid the pins_mappings.h file and do the job in each compatible boards? like the other displays. also is posible reformat the pin scheme structure in all boards?, because all board have his own different structure, wich is difficult use one as reference greetings |
Of course it is possible. It is not even necessary to get rid of the "pin_mappings.h" file, as it won't come into play unless one of pin mapping constants is defined somewhere. So all you really need to do to implement what you want is to define the various IMHO, the "pin_mapping.h" file should only be used for generic non-board specific pin maps which make use of the RepRapDiscount pin assignments as an intermediary. Specific setups for boards can and should happen in the pins file for the board itself. |
|
BTW, I like how you made the ASCII diagram with the gap to show the direction of the connector. Some board schematics define the pin numbers in reverse order, making things very confusing. Usually I have to look at the ground pin to figure out which direction the numbering is going. |
|
i'm not sure is the pin number order is the correct (ISO(?) standard), i only follow other examples. and yes. draw the connector (if have a ovbiously visual point of reference like this one ) is more concise than only enumerate the pins with names greetings |
|
No, I feel a bit sorry for the noise I made but I felt this needs to be discussed.
Yes, this is correct.
And this is wrong, The Beeper pin is the top-left one in the board picture. Just one example from a datasheet for this type of connector: Note the little triangle, it marks pin 1. You will also find it on the connector.
I won't check all the files now but if this is the case, all the files are wrong.
Then this is wrong as well: This is from the BTT-SKR-E3-DIP schematic. This is from the SKR-mini-E3 schematic: Excellent, same connector, same pin-assignement, different numbering scheme. My guess is, Creality messed up.
I am not sure if there is a standard either, I found DIN 41651 though but that might regulate only some special properties for these types of connectors.
The CR10 uses the same board as the Ender-3, the CR10S uses a different board. What is the benefit of trying to hide that CLCD_MOD_RESET is connected to PC11? If you have this: You can hover with the mouse over CLCD_MOD and it will tell you that it is defined as PC11. That the pin assignment is currently wrong and that CLCD_MOD should be assigned to BTN_EN2 is an excellent showcase for how important it is to make things simple and not cover it in several layers of defines that are not even used anywhere.
Okay, I made my point and you two would like to go in the opposite direction. And if the defines are removed from pin_mappings.h it should be a lot easier to read pins_xxx.h as this is all in one place then. |
|
my point is also get out the file and o the work in each board pin file about the pin numeration, thinkyhead@28008ac. just i say, i only follow the existent code the use of a tons of alias is because is used in the pins_mapping, but my start point is in the BTT E3 DIP file, wich have setted the EXPA1_FOO alias, the i use it in the other files i modified. in this point seems i make a mistake when i lead my initiative without thinking in other devs. sorry for that but if i get rid the expa1/2 alias, i can do the same in the rest of pin files wich have seteed on? Grep Output@thinkyhead, is ok if remove the set up EXPA alias and set the pin name instead? greetings |
|
Woa, okay, I would say you got me good there. |
Yes. The point of any of these indirect header plug mappings is to make it easier to map different common display connectors to the EXP headers. However, in practice it doesn't always look as pretty or map as cleanly as we would like. Can you imagine trying to make a single |
|
Okay, I just pushed #17935 which removes the special pinout for the Cheetah from pin_mappings.h and puts the necessary defines into pins_FYSETC_CHEETAH.h. When I opened pins_FYSETC_CHEETAH.h I intended to keep the EXPA1_ definitions. I also corrected the pinout for the connector and added a couple of lines to explain this. IMHO these EXPA1_ definitions should be removed from the only three files using these, namely pins_BTT_SKR_V1_3.h, pins_BTT_SKR_E3_DIP.h and pins_BTT_SKR_MINI_E3.h. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Bug Description
The TOUCH_UI_FTDI_EVE does not work on marlin 2.0.1 or 2.0.x
i tried on Ramps, Arduino, SKR Pro, Fysetc S6 and SKR 1.3
the compiling issue #16534 is sloved.
but now only the display back light is on. i tried a lot different configurations but the result was every time the same.
Green screen while booting and after this backlight is on and display black.
Only if disconnect the MISO pin, on the display is the notification
Release to begin screen calibrationwith the marlin version from fysetc the display works pefect.
https://github.com/FYSETC/Marlin-2.0.x-FYSETC/tree/S6/BUG-FIX-CLCD
i also copied the folder
ftdi_eve_touch_uifrom fysetcs marlin in the marlin 2.0.1 branch after this the display works also but only with s6 board and SKR pro.copy the
ftdi_eve_touch_uifolder to the actual bugfix version does not work because there comes a lot of errors.My Configurations
here are my configs that i actual work on my printer. (TOUCH_ui Folder is from fysetc)
Config_SKRPRO_MMU2_FTDI2.0.1WithFysetcTouchUI.zip
Steps to Reproduce
ftdi_eve_touch_uifolder from the marlin branch Expected behavior: [Display doesnt work]ftdi_eve_touch_uifrom the marlin branch Expected behavior: [Display does work]Additional Information
I also noticed that the #defines from the cofiguration.adv are not taken over.
As an example you select //#define CLCD_USE_SOFT_SPI in config.adv but the display still works with the normal SPI pins on EXP2.
but if you change it as follows in the pin_mappings.h
the display is now controlled by the defined pins (backlight goes on) but unfortunately not correctly because the display is only switched on but nothing is displayed. so Software_SPI isnt work correctly
the same problem even if the CS and PD pin is only defined in config.adv the display is not controlled at all.
also this must happen in pin_mappings.h as mentioned above.
#define CLCD_SPI_CS PG10 //PD11
#define CLCD_MOD_RESET PF11 //PG2
`
next problem is now
if we use the LCD on the hardware spi bus we cant connect a sd card module.
as soon as i have connected the sd card module to the spi bus of the display the display shows only strange things
is it possible to use sd card modul with software spi?
I hope this is written understandably.
The text was updated successfully, but these errors were encountered: