Haschi1989 said:Hello I m using at the moment the SW102 display. But it is hard to read under direct sunlight. Is the 850 better?
Is it possible to use the 500C display with OSF ?
Other question will the "new" 850 displays for tsdz2 work with OSF.
Regards
A bit easier to find with a linkSemogonif said:See the post by: perryscope » on Aug 05 2020 3:04pm
imho this couldn't be the case after a gear revision.Haschi1989 said:..... replace the blue gear. ........ On the screen was the advise "keep pedal free...." but it dosen't disappears. ....
.... controller software is erased. Is this possible? ....
Elinx said:A bit easier to find with a linkSemogonif said:See the post by: perryscope » on Aug 05 2020 3:04pm
https://endless-sphere.com/forums/viewtopic.php?f=30&t=93818&start=6045#p1575672
Is great to see someone using the TSDZ2 motor controller, our OpenSource firmware and the wireless controller, on another mid drive motor.livello said:How to properly use the OS-ebike firmware and TSDZ2 controller v1 on another motor?
Maybe. It is always good to have new working components to test against.Peacepirate said:My question: Could it be that only the adc pin of the STM8 Chip broke? Is this possible?
casainho said:So, yesterday I took a lot of time to figure out what issues I was having because one TSDZ2 wireless board was not working... turns out I was very tired already and exchanged the UART TX and RX wires. I had to use the oscilloscope to discover that the constant "alive" signal sent by the motor controller was very small and near 5 volts, so, the wires were exchanged. But after, the system still not worked, the firmware correctly turned on/off the TSDZ2 motor controller power and the TSDZ2 wireless board was never sending any data to the UART RX line of the TSDZ2 motor controller. Finally I decided to remove the NRF52840 for a new one and the system finally started to work
So, lesson learned: if by mistake I exchange the UART TX and RX wires, possibly the NRF52840 will be damaged only on the UART RX line of the TSDZ2 motor controller and the system will never work.
casainho said:Maybe. It is always good to have new working components to test against.Peacepirate said:My question: Could it be that only the adc pin of the STM8 Chip broke? Is this possible?
I just wrote this message, where I had similar issue on the TSDZ2 wireless controller, because I exchanged the UART TX and RX wires, I had to trash the board and use a new one -- and that took me time to understand!
https://endless-sphere.com/forums/viewtopic.php?p=1668844#p1668844:
casainho said:So, yesterday I took a lot of time to figure out what issues I was having because one TSDZ2 wireless board was not working... turns out I was very tired already and exchanged the UART TX and RX wires. I had to use the oscilloscope to discover that the constant "alive" signal sent by the motor controller was very small and near 5 volts, so, the wires were exchanged. But after, the system still not worked, the firmware correctly turned on/off the TSDZ2 motor controller power and the TSDZ2 wireless board was never sending any data to the UART RX line of the TSDZ2 motor controller. Finally I decided to remove the NRF52840 for a new one and the system finally started to work
So, lesson learned: if by mistake I exchange the UART TX and RX wires, possibly the NRF52840 will be damaged only on the UART RX line of the TSDZ2 motor controller and the system will never work.
someone has the diagram to connect 6 wires with 1t4 (without throttle of course) I find only diagrams for the 8 wire cable
Woly said:someone has the diagram to connect 6 wires with 1t4 (without throttle of course) I find only diagrams for the 8 wire cable
See this post https://endless-sphere.com/forums/viewtopic.php?p=1670706#p1670767
bikelpl said:casainho said:Maybe I should change the wiki instructions and remove the 850C, as even if some old and this recent version does not work, so no point to recomend it.mctubster said:casainho said:Probably and old and incorrect hardware version of 850C. The best bet is to use the 860C display as there are no reports of such issues with it.
Thanks for the reply casainho. I did wonder that and checked the back of the screen. Looks like manufacture 2021! don’t disagree re the 860c screen.B6A8EB97-7D29-4B0B-AB93-32E5D4C4E8F9.jpeg
I also have the newest 850C display. I managed to run it with OSF.
Below init code works with newest 850C display marked as "TFTGD3V2.3LF60"
It is mix of 860C init.
I don't know how to add this to github and how to make this code to be automatically chosen between different versions of displays so i paste it here. Maybe someone else possibly could add it to github repository.
Code:void display_8x0C_lcd_init() { // next step is needed to have PB3 and PB4 working as GPIO /* Disable the Serial Wire Jtag Debug Port SWJ-DP */ GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE); GPIO_InitTypeDef GPIO_InitStructure; GPIO_InitStructure.GPIO_Pin = LCD_READ__PIN; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_Init(LCD_READ__PORT, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = LCD_RESET__PIN; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_Init(LCD_RESET__PORT, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = LCD_COMMAND_DATA__PIN; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_Init(LCD_COMMAND_DATA__PORT, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = LCD_CHIP_SELECT__PIN; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_Init(LCD_CHIP_SELECT__PORT, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = LCD_WRITE__PIN; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_Init(LCD_WRITE__PORT, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = 0xffff; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_Init(LCD_BUS__PORT, &GPIO_InitStructure); // disable reset GPIO_SetBits(LCD_RESET__PORT, LCD_RESET__PIN); // default to write mode GPIO_SetBits(LCD_READ__PORT, LCD_READ__PIN); // keep chip select active GPIO_ResetBits(LCD_CHIP_SELECT__PORT, LCD_CHIP_SELECT__PIN); lcd_IC_t type = LCD_ST7796; delay_ms(120); lcd_write_command(0x11); delay_ms(120); lcd_write_command(0x36); lcd_write_data_8bits(0x48); lcd_write_command(0x3A); lcd_write_data_8bits(0x55); lcd_write_command(0xF0); lcd_write_data_8bits(0xC3); lcd_write_command(0xF0); lcd_write_data_8bits(0x96); lcd_write_command(0xB4); lcd_write_data_8bits(0x01); lcd_write_command(0xB7); lcd_write_data_8bits(0xC6); lcd_write_command(0xC0); lcd_write_data_8bits(0xF0); lcd_write_data_8bits(0x35); lcd_write_command(0xC1); lcd_write_data_8bits(0x15); lcd_write_command(0xC2); lcd_write_data_8bits(0xAF); lcd_write_command(0xC3); lcd_write_data_8bits(0x09); lcd_write_command(0xC5); //VCOM lcd_write_data_8bits(0x06); lcd_write_command(0xC6); lcd_write_data_8bits(0x00); lcd_write_command(0xE8); lcd_write_data_8bits(0x40); lcd_write_data_8bits(0x8A); lcd_write_data_8bits(0x00); lcd_write_data_8bits(0x00); lcd_write_data_8bits(0x29); lcd_write_data_8bits(0x19); lcd_write_data_8bits(0xA5); lcd_write_data_8bits(0x33); lcd_write_command(0xE0); lcd_write_data_8bits(0x70); lcd_write_data_8bits(0x00); lcd_write_data_8bits(0x05); lcd_write_data_8bits(0x03); lcd_write_data_8bits(0x02); lcd_write_data_8bits(0x20); lcd_write_data_8bits(0x29); lcd_write_data_8bits(0x01); lcd_write_data_8bits(0x45); lcd_write_data_8bits(0x30); lcd_write_data_8bits(0x09); lcd_write_data_8bits(0x07); lcd_write_data_8bits(0x22); lcd_write_data_8bits(0x29); lcd_write_command(0xE1); lcd_write_data_8bits(0x70); lcd_write_data_8bits(0x0C); lcd_write_data_8bits(0x10); lcd_write_data_8bits(0x0F); lcd_write_data_8bits(0x0E); lcd_write_data_8bits(0x09); lcd_write_data_8bits(0x35); lcd_write_data_8bits(0x64); lcd_write_data_8bits(0x48); lcd_write_data_8bits(0x3A); lcd_write_data_8bits(0x14); lcd_write_data_8bits(0x13); lcd_write_data_8bits(0x2E); lcd_write_data_8bits(0x30); // lcd_write_command(0x21); lcd_write_command(0xF0); lcd_write_data_8bits(0xC3); lcd_write_command(0xF0); lcd_write_data_8bits(0x96); delay_ms(120); lcd_write_command(0x29); delay_ms(25); // End of display configuration // @geeksville board reads back as 0x2, 0x4, 0x94, 0x81, 0xff - a legit ili9481 write_pulse_duration = 0; // enable fast writes // Note: if we have some devices still not working, we might need to add a READ command to 0xbf (8.2.39) to read // the chip id of the failing units - this would allow us to see the vendor code of whoever made the display and // confirm it is a 9481 (or if different - what it is) // It is worth noting that the display controller has a small amount of non volatile memory. I bet the mfg of the // 850C is checking that code in their firmware, and based on that value chosing to flip the display horizontally // if needed (via command 0x36) // Initialize global structure and set PSET to this.PSET. UG_Init(&gui, lcd_pixel_set, DISPLAY_WIDTH, DISPLAY_HEIGHT); // Register acceleratos. UG_DriverRegister(DRIVER_FILL_FRAME, (void*) HW_FillFrame); UG_DriverRegister(DRIVER_DRAW_LINE, (void*) HW_DrawLine); UG_DriverRegister(DRIVER_FILL_AREA, (void*) HW_FillArea); //UG_DriverEnable ( DRIVER_FILL_FRAME ) ; // UG_DriverEnable ( DRIVER_DRAW_LINE ) ; // UG_DriverEnable ( DRIVER_FILL_AREA ) ; }
It is a hard decision as there are strong pros and cons.qfade said:Hi,
Thanks for the software open source! Is amazing.
Me and my wife are fascinated by this solution.
I ran into the problem of the new tsdz2 driver with in new bike.
Maybe this solution:
Instead of adapting the software to new drivers
make it universal
1. Using the VESC 50 A driver (it's very small)
2. Design a PCB overlay for this driver (PAS, Speed, etc)
3. Connect soft (VESC + TsdzOpenSource) together
(with vesc we only need the engine configurations)
4. Can be installed in any bike!
Casainho please tell me if you would be able to handle the microprocessor in VESC (ARM) ?
Second option:
STM32 Nucleo Boards + TSDZOpenSurce (Output PWM, not engine) + VESC (PWM control)
Let's make one universal driver
Any counter-suggestions, gentlemen?
Links:
https://f1tenth.readthedocs.io/en/stable/getting_started/firmware/firmware_vesc.html
http://vedder.se/2015/01/vesc-open-source-esc/
https://ae01.alicdn.com/kf/Hef22fb17631b4592b7b3de6b16b4c7134.jpg
As I told, I have no free time to do anything. Sorry.qfade said:Thank you for your reply.
Built VESC can be bought on AliExpress low price, don't need to build.
Personally, I can design a PCB and make it.
(inputs: PAS, torque, speed etc.)
I just don't know much about programming STM processors :-(
I am a hobbyist at Atmel. I would like to try in STM.
If you would prepare a "clean" program with PWM output, I would gladly try to implement it into VESC.
Or I can make a PCB overlay on VESC with a second STM that would contain your software and connect it with PWM signal
(VESC software would be original)
Note that TSDZ drivers have withdrawn from STM. it is possible that in a year's time there may also be a completely different driver.
Such a solution would be universal.
Even in the original bosh or shimano engines, this can be implemented and saved on very expensive batteries using the CAN bus.
Here, users can also buy a ready-made solution without soldering
qfade said:Let's make one universal driver
stancecoke said:qfade said:Let's make one universal driver
Why the 3685th project for a universal controller?! There are already many working mature projects, based on VESC, based on other cheap china hardware (Kunteng + Lishui) or completely own hard- and firmware, like the projects of lebowski, mxlemming, tecnologic, barmal, ...
You even could use a China BLDC controller as is and only add something like the CA or the FC (Forumscontroller)
As @casainho wrote already, for the TSDZ2 you would have to find a way, how to get a meaningful signal from the torquesensor: generate a square wave voltage, filter and amplify the resulting signal....
regards
stancecoke