TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)

[orfait]

Very nice work.
I may join for helping the dev. Are you using linux or windows ?

Concerning 850C, I am not able to find the source code. Did you publish it ?

 

[casainho]

Very nice work.
I may join for helping the dev. Are you using linux or windows ?

Concerning 850C, I am not able to find the source code. Did you publish it ?

I am using Linux but other developers are using Windows as well.

850C sources: https://github.com/OpenSource-EBike-firmware/Color_LCD/tree/master/Bafang_LCD_850C/Bafang_LCD_850C_firmware

 

[casainho]

Bluetooth on SW102 LCD is now working!!

I used the Nordic SDK sample "ble_app_beacon" because I though would be the fast and simple way to have Bluetooth working.

Here is the source code where I changed the UUID to some number easy to spot:

And here is the beacon listed on my mobile phone, using the nRF Connect app from Nordic, specific to help on the development:

I guess for future, we can use the sample code "ble_app_uart" that is a UART/Serial Port Emulation over BLE, so we could work on the firmware side to have 2 UARTS on the system, 1 for communicating with the TSDZ2 motor controller and the other with the mobile app.

Also, I would like to connect to that visible xiaoxiang BMS that are installed on my battery packs and I would like to read the battery pack temperature and each voltage cell. The idea to read the BMS temperature is similar to read motor temperature... my cells can't discharge fast, otherwise they should increase the temperature and the their lifetime will be reduced.

 

[buba]

I am still alive!

But I do apologize for not being that active. Today was the first day in a very long time where I was free from work. I still consider myself a developer to this community but I hope everyone understands that it is hard to free up time.


Anyway, the show must go on.

Casainho suggested a greater resolution on the assist level multipliers (great idea for the better human power measurements) and thingeight suggested some cool energy/consumption data. Also there are the usual bugs and problems users have reported. And on top of this I see some other improvements to make. The plan is to develop and solve all problems but let us take it one step at a time and first create a new version with the changes made so far.


The pull request:

I have submitted a pull request to Casainho and I hope he will release a new official beta for the 0.19.0 version. This includes all my work and also some other updates such as a much more accurate calculation of human power from Casainho.

Combined log of changes since version 0.18.0:

* Added estimated range since power on depending on how much capacity is left
* Added option to set motor power limit in the configuration menu
* Added option to enable or disable motor power limit quick-set-menu
* Added two new main screen setup items
* More accurate watt-hour measurement
* More accurate time measurement
* Heavily optimized code size and speed
* Safer Walk Assist and Cruise
* Added a function that measures and calculates consumed watt-hours per traveled distance since power on
* Added a new sub field in the odometer field temporarily called Energy where user will see energy consumption and estimated range
* Merged previous configuration menu LCD Setup with configuration menu General Setup for better and faster setup. This also optimizes program size, removed configuration menu LCD Setup
* Added a new sub field in the odometer field temporarily called Energy where user will see energy consumption and estimated range
* Added option that enables user to enable or disable display of motor temperature in the odometer field
* Changed order in the Main Screen Setup menu in the configuration menu
* Changed order in the odometer field
* Updated READ ME document
* Overall optimizations in regard to size and speed
* Cleaned up code and comments
* Created and updated the wiki that has been updated with all the changes

Wiki:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.19.X-(BETA)

 

[buba]

I found this new video on youtube channel of Buba, seems he is busy recently

[youtube]LVqvzC2e2sE[/youtube]

Haha!

Fun that you noticed but that is not my project :wink: As I have said before that is my fathers YouTube account that I borrow time to time. It is actually his project and development!

The account buba here on Endless Sphere is also hijacked from him!

Here is a picture:

 

[casainho]

I am back to business with the 850C display, I just received a new unit today.

I want to finalize the graphs and for now I just used an array with constant values to print the very first graph. What is seen on the image is a graph (no labels for now) with values from an array in memory, in this case I used the values of the voltages of voltages that are applied to motor phases - it is not a sinewave but it is not far.

My plan for next step is to implement the graph, with correct label and max and min values, for the pedal human power. Then I will test on my bicycle and later I can move forward to implement for all other variables on the system other than the pedal human power.

 

[thineight]

Good afternoon!
A question for buba and casainho.

I see you both have released a v0.19beta (buba few weeks ago and casainho recently).. is the current casainho's the master one, obtained from buba's + latest torque factors?

I am a bit puzzled which wiki refers to which LCD3/motor release.
I've found the 0.19beta wiki here:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.19.X-%28BETA%29
but i'm not sure if this applies to latest casainho version only.. or buba one.. or both.

Thanks a lot

 

[dameri]

I'm not buba or casainho but I answer. Buba released as you say earlier v19 beta and it was only for KTLCD3 and now casainho has released beta version for motor too.

 

[casainho]

Good afternoon!
A question for buba and casainho.

I see you both have released a v0.19beta (buba few weeks ago and casainho recently).. is the current casainho's the master one, obtained from buba's + latest torque factors?

I am a bit puzzled which wiki refers to which LCD3/motor release.
I've found the 0.19beta wiki here:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.19.X-%28BETA%29
but i'm not sure if this applies to latest casainho version only.. or buba one.. or both.

Thanks a lot

I think I did not release 0.19, I think. I want to review the commit of Buba and maybe, add the code to disable the PWM while resting.

 

[thineight]

Good afternoon!
A question for buba and casainho.

I see you both have released a v0.19beta (buba few weeks ago and casainho recently).. is the current casainho's the master one, obtained from buba's + latest torque factors?

I am a bit puzzled which wiki refers to which LCD3/motor release.
I've found the 0.19beta wiki here:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.19.X-%28BETA%29
but i'm not sure if this applies to latest casainho version only.. or buba one.. or both.

Thanks a lot

I think I did not release 0.19, I think. I want to review the commit of Buba and maybe, add the code to disable the PWM while resting.

I think I saw a 0.19beta in your repository.. or maybe that is not yours (I'm not an expert of GitHub).
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.19.0-beta1

What is the setup wiki valid for this one? The 18.2?

So I conclude that the above 0.19beta for LCD3 and motor are not directly from Buba earlier 0.19beta code.

 

[buba]

What is the setup wiki valid for this one? The 18.2?

So I conclude that the above 0.19beta for LCD3 and motor are not directly from Buba earlier 0.19beta code.

I think it is best to wait for the official beta that Casainho will release and test it from there It will be compatible with the wiki I previously linked in the thread:

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.19.X-%28BETA%29

A question for buba and casainho.

I see you both have released a v0.19beta (buba few weeks ago and casainho recently).. is the current casainho's the master one, obtained from buba's + latest torque factors?

It is my code + the new human power calculation + some more updates. Here is the complete changelog from 0.18

* Much more accurate calculation of human power
* Added estimated range since power on depending on how much capacity is left
* Added option to set motor power limit in the configuration menu
* Added option to enable or disable motor power limit quick-set-menu
* Added two new main screen setup items
* More accurate watt-hour measurement
* More accurate time measurement
* Heavily optimized code size and speed
* Safer Walk Assist and Cruise
* Added a function that measures and calculates consumed watt-hours per traveled distance since power on
* Added a new sub field in the odometer field temporarily called Energy where user will see energy consumption and estimated range
* Merged previous configuration menu LCD Setup with configuration menu General Setup for better and faster setup. This also optimizes program size, removed configuration menu LCD Setup
* Added a new sub field in the odometer field temporarily called Energy where user will see energy consumption and estimated range
* Added option that enables user to enable or disable display of motor temperature in the odometer field
* Changed order in the Main Screen Setup menu in the configuration menu
* Changed order in the odometer field
* Updated READ ME document
* Overall optimizations in regard to size and speed
* Cleaned up code and comments
* Created and updated the wiki that has been updated with all the changes

Wiki:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.19.X-%28BETA%29

 

[sidmodi]

I am running Ubuntu 18.04 and this is what I see when I type 'sdcc -v':

SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.8.0 #10562 (Linux)

You can see that I am on master branch, with latest code and I can build correctly BUT my SDCC build version seems different from yours, even if is 3.8.0... please give a look:

cas@cas:~/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/src/display/KT-LCD3$ git branch 
  15-rider_pedal_human_power_shown_on_LCD
  19-Implement_button_fast_multiple_clicks
  21-stall-protection
  33-Improving_wheel_speed_sensor_reading
  35-Improve_battery_SOC_bars
  39-Make_EEPROM_reset_and_writing_variables_robust
  46-Assist_level_and_start_power_boost_now_work_as_a_factor_of_rider_pedal_human_power
  46-assist_level_and_start_power_boost_now_work_as_a_factor_of_rider_pedal_human_power
  49-Implement_battery_current_ramp
  50-Stall_protection_kicks_in_on_startup-0.15.0
  7-Correct_calculated_value_of_Watts_hour
  74-Correct_pedal_human_power
  8-cadence-low-pass-filter
  EEPROM_fail_default_values_fix
  assist_level_as_factor_of_pedal_power
  development
* master
  origin/14-walk-assist-mode
  test_0.17_beta
cas@cas:~/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/src/display/KT-LCD3$ git pull
Already up to date.
cas@cas:~/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/src/display/KT-LCD3$ make -f Makefile_linux clean
Cleaning files...
Done.
cas@cas:~/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/src/display/KT-LCD3$ make -f Makefile_linux
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_iwdg.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_iwdg.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_clk.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_clk.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_gpio.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_gpio.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_adc1.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_adc1.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_tim1.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_tim1.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_tim3.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_tim3.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_uart2.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_uart2.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_flash.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_flash.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -ogpio.c gpio.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -oht162.c ht162.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -oadc.c adc.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -otimers.c timers.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -olcd.c lcd.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -ouart.c uart.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -oeeprom.c eeprom.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -obuttons.c buttons.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -outils.c utils.c
sdcc -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  main.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_iwdg.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_clk.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_gpio.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_adc1.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_tim1.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_tim3.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_uart2.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_flash.rel gpio.rel ht162.rel adc.rel timers.rel lcd.rel uart.rel eeprom.rel buttons.rel utils.rel
main.c:82: warning 126: unreachable code
stm8-size main.elf -A
main.elf  :
section             size         addr
DATA                 286            1
INITIALIZED          198          287
SSEG                   1   4294967295
HOME                  99        32768
GSINIT                26        32867
GSFINAL                3        32893
CONST                 12        32896
INITIALIZER          198        32908
CODE               32176        33106
.debug_line        31457            0
.debug_loc         40545            0
.debug_abbrev       2401            0
.debug_info        47598            0
.debug_pubnames     9784            0
.debug_frame       34022            0
Total             198806


stm8-objcopy -O binary -R DATA -R INITIALIZED -R SSEG -R .debug_line -R .debug_loc -R .debug_abbrev -R .debug_info -R .debug_pubnames -R .debug_frame main.elf main.bin
stm8-objcopy -O ihex -R DATA -R INITIALIZED -R SSEG -R .debug_line -R .debug_loc -R .debug_abbrev -R .debug_info -R .debug_pubnames -R .debug_frame main.elf main.hex
cas@cas:~/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/src/display/KT-LCD3$ sdcc -v
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.8.0 #10557 (Linux)
published under GNU General Public License (GPL)
cas@cas:~/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/src/display/KT-LCD3$

Hey Casainho,

I installed the same release of SDCC as you have (v3.8.0 r10557) and I am still seeing the same 'buffer overflow' error after the led.c file as before. In the Makefile, I moved the led.c file to the bottom of the list and tried building again and saw that all the files are building correctly except for the led.c file.

To do some basic debugging, I checkout out an older commit and found that my build was succeeding. After some back and forth, I found that my build is succeeding until the following sha: a3d06ca65f7a3226ddacb321ec1d4c975bb91681. Any commit after this one is causing my build to fail with the 'buffer overflow' error for the led.c file. I am really quite lost as to what exactly changed between this commit and the next one that is causing my builds to fail. Is there a flag or a setting in SDCC or in the source that I need to set prior to compiling? I must be missing something if the builds are working for you guys.

Also, after failing on my Linux computer, I retried the entire process on my Windows 10 computer but in the Windows Subsystem for Linux with Ubuntu 18.04. I saw the exact same results...

I am at a loss as to what could be causing this. Any help would be really appreciated!

Thank you,
Sid

 

[Rydon]

I think I did not release 0.19, I think. I want to review the commit of Buba and maybe, add the code to disable the PWM while resting.

I have the coaster brake bike back in the shop and will do the tests you asked for. Need to disable PWM with wheel speed >0 for the coaster brake.

 

[casainho]

I am running Ubuntu 18.04 and this is what I see when I type 'sdcc -v':

SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.8.0 #10562 (Linux)

You can see that I am on master branch, with latest code and I can build correctly BUT my SDCC build version seems different from yours, even if is 3.8.0... please give a look:

cas@cas:~/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/src/display/KT-LCD3$ git branch 
  15-rider_pedal_human_power_shown_on_LCD
  19-Implement_button_fast_multiple_clicks
  21-stall-protection
  33-Improving_wheel_speed_sensor_reading
  35-Improve_battery_SOC_bars
  39-Make_EEPROM_reset_and_writing_variables_robust
  46-Assist_level_and_start_power_boost_now_work_as_a_factor_of_rider_pedal_human_power
  46-assist_level_and_start_power_boost_now_work_as_a_factor_of_rider_pedal_human_power
  49-Implement_battery_current_ramp
  50-Stall_protection_kicks_in_on_startup-0.15.0
  7-Correct_calculated_value_of_Watts_hour
  74-Correct_pedal_human_power
  8-cadence-low-pass-filter
  EEPROM_fail_default_values_fix
  assist_level_as_factor_of_pedal_power
  development
* master
  origin/14-walk-assist-mode
  test_0.17_beta
cas@cas:~/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/src/display/KT-LCD3$ git pull
Already up to date.
cas@cas:~/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/src/display/KT-LCD3$ make -f Makefile_linux clean
Cleaning files...
Done.
cas@cas:~/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/src/display/KT-LCD3$ make -f Makefile_linux
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_iwdg.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_iwdg.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_clk.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_clk.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_gpio.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_gpio.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_adc1.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_adc1.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_tim1.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_tim1.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_tim3.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_tim3.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_uart2.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_uart2.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -o../../common/STM8S_StdPeriph_Lib/src/stm8s_flash.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_flash.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -ogpio.c gpio.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -oht162.c ht162.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -oadc.c adc.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -otimers.c timers.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -olcd.c lcd.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -ouart.c uart.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -oeeprom.c eeprom.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -obuttons.c buttons.c
sdcc -c -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  -outils.c utils.c
sdcc -I../../common/STM8S_StdPeriph_Lib/inc -I. -I../../ -mstm8 -Ddouble=float --std-c99 --nolospre --opt-code-size --out-fmt-elf --debug  main.c ../../common/STM8S_StdPeriph_Lib/src/stm8s_iwdg.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_clk.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_gpio.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_adc1.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_tim1.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_tim3.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_uart2.rel ../../common/STM8S_StdPeriph_Lib/src/stm8s_flash.rel gpio.rel ht162.rel adc.rel timers.rel lcd.rel uart.rel eeprom.rel buttons.rel utils.rel
main.c:82: warning 126: unreachable code
stm8-size main.elf -A
main.elf  :
section             size         addr
DATA                 286            1
INITIALIZED          198          287
SSEG                   1   4294967295
HOME                  99        32768
GSINIT                26        32867
GSFINAL                3        32893
CONST                 12        32896
INITIALIZER          198        32908
CODE               32176        33106
.debug_line        31457            0
.debug_loc         40545            0
.debug_abbrev       2401            0
.debug_info        47598            0
.debug_pubnames     9784            0
.debug_frame       34022            0
Total             198806


stm8-objcopy -O binary -R DATA -R INITIALIZED -R SSEG -R .debug_line -R .debug_loc -R .debug_abbrev -R .debug_info -R .debug_pubnames -R .debug_frame main.elf main.bin
stm8-objcopy -O ihex -R DATA -R INITIALIZED -R SSEG -R .debug_line -R .debug_loc -R .debug_abbrev -R .debug_info -R .debug_pubnames -R .debug_frame main.elf main.hex
cas@cas:~/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/src/display/KT-LCD3$ sdcc -v
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.8.0 #10557 (Linux)
published under GNU General Public License (GPL)
cas@cas:~/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/src/display/KT-LCD3$

Hey Casainho,

I installed the same release of SDCC as you have (v3.8.0 r10557) and I am still seeing the same 'buffer overflow' error after the led.c file as before. In the Makefile, I moved the led.c file to the bottom of the list and tried building again and saw that all the files are building correctly except for the led.c file.

To do some basic debugging, I checkout out an older commit and found that my build was succeeding. After some back and forth, I found that my build is succeeding until the following sha: a3d06ca65f7a3226ddacb321ec1d4c975bb91681. Any commit after this one is causing my build to fail with the 'buffer overflow' error for the led.c file. I am really quite lost as to what exactly changed between this commit and the next one that is causing my builds to fail. Is there a flag or a setting in SDCC or in the source that I need to set prior to compiling? I must be missing something if the builds are working for you guys.

Also, after failing on my Linux computer, I retried the entire process on my Windows 10 computer but in the Windows Subsystem for Linux with Ubuntu 18.04. I saw the exact same results...

I am at a loss as to what could be causing this. Any help would be really appreciated!

Thank you,
Sid

Well, maybe you should forget this because the LCD3 project is finnished now because the memory is full, we can't add more code to it.

The next LCDs are really different beasts in processing power and use ARM microcontrollers ARM GCC compiler which is like at least 1000x better.

I think developers should now focus on the new 850C LCD and SW102 LCD, and sure, also on the motor controller.

 

[thineight]

What is the setup wiki valid for this one? The 18.2?

So I conclude that the above 0.19beta for LCD3 and motor are not directly from Buba earlier 0.19beta code.

I think it is best to wait for the official beta that Casainho will release and test it from there It will be compatible with the wiki I previously linked in the thread:

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.19.X-%28BETA%29

A question for buba and casainho.

I see you both have released a v0.19beta (buba few weeks ago and casainho recently).. is the current casainho's the master one, obtained from buba's + latest torque factors?

Wiki:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.19.X-%28BETA%29

Thanks Buba, maybe you meant to say "wait for the stable v.0.19" not the beta, as the latter is already out on casainho repository.
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.19.0-beta1

I would like to try this out (as I'm currently with your 0.18beta) , but I'm not sure which wiki applies to this new beta.

Last question: is the LCD3 display development "officially" closed?

 

[casainho]

Last question: is the LCD3 display development "officially" closed?

Buba wrote this on the change log: * Heavily optimized code size and speed.

I think he must had a lot of work to optimize the code size so it could go to LCD3 memory, so I think not many will want to do that type of optimizations every time they want to change some bits on LCD3. And I really hope there are some free bit there available for maintenance (as there is no point to have the memory full of code with some bugs, in the case that bugs do appear).

 

[buba]

Thanks Buba, maybe you meant to say "wait for the stable v.0.19" not the beta, as the latter is already out on casainho repository.
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.19.0-beta1

I would like to try this out (as I'm currently with your 0.18beta) , but I'm not sure which wiki applies to this new beta.

Thank you for your willingness to test and give feedback!

No, I meant it is best to wait for the official beta with all the most recent changes and updates. And try that one out. It is probably released very soon.

The beta released now is not built with the latest code and it has no wiki. But when Casainho accepts my most recent pull request he will release a new 0.19 beta and it will be the very latest in development. The wiki for that soon-to-come beta is this one:

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.19.X-%28BETA%29

Sorry for any inconvenience!

Last question: is the LCD3 display development "officially" closed?

The KT-LCD3 will always be maintained and updated if any bugs show up. But as far as program memory goes it is at its limit.

I also think Casainho would really like that all the development is focused on the other displays, 850C and SW102. I respect that decision and think it is the right way forward for future development and the community. I will probably take a look at the source codes for those. And also maybe focus on some reported bugs and issues such as the Lag. Not really sure. The priority for now is to finalize version 0.19.0 and after that we will see what happens.

 

[buba]

Buba wrote this on the change log: * Heavily optimized code size and speed.

I think he must had a lot of work to optimize the code size so it could go to LCD3 memory, so I think not many will want to do that type of optimizations every time they want to change some bits on LCD3. And I really hope there are some free bit there available for maintenance (as there is no point to have the memory full of code with some bugs, in the case that bugs do appear).

It was a lot of work and it slows down the development so much. When I tried to add the higher resolution on the assist level multipliers it was like taking one step forward and two steps back. Also had severe time constraints. Therefore it is sadly not committed in the current pull request.

Luckily, there are some free bytes available for future bug fixes and maintenance.

 

[thineight]

Many thanks for the answers!
I will wait then the official 0.19beta with the relevant wiki.

I plan also to test on the other bike the latest marcoq release for the VLCD5 display, in particular the backwards resistance removed. No main issues reported so far, so I expect this can be soon implemented as first attempt, until more sophisticated (if any) code will be developed.

Hope to give my personal feedback on this function soon.
Cheers

 

[casainho]

I also think Casainho would really like that all the development is focused on the other displays, 850C and SW102. I respect that decision and think it is the right way forward for future development and the community.

It was a lot of work and it slows down the development so much. When I tried to add the higher resolution on the assist level multipliers it was like taking one step forward and two steps back.

Yes, let's move to the more capable and flexible LCDs.

Current status 850C:
- full control of the LCD hardware and optimized write fast to LCD and UART
- firmware is well structured and do not lost communication packages
- configuration menu already implemented
- works well but has some bugs related to buttons combinations
- missing to implement:
-- customized numeric fields
-- customized graphs

SW102 Bluetooth LCD:
- Bluetooth works (tested with Bluetooth Beacon firmware sample)
- LCD do not works yet but I already logged the electric signals (should be easier than 850C LCD)
- only piece of hardware missing to have full control are the 3 buttons but should be very fast to get them. The power on/off button already works.

I want to focus myself on 850C but if anyone is interested to help on SW102, I can help mainly on get the full hardware working.

 

[sidmodi]

Hi casainho, buba,

I would be interested in helping out with the SW102 bluetooth LCD. In one of my past internships, I had to develop a couple of simple Bluetooth applications using an nRF51 board so I have some basic experience with the Nordic uC products. I'll have to order one of those first. Once I receive it, I will reach out to you for some help on getting started. I'll give up on trying to set up the LCD3 for now.

Cheers,
Sid

 

[casainho]

Hi casainho, buba,

I would be interested in helping out with the SW102 bluetooth LCD. In one of my past internships, I had to develop a couple of simple Bluetooth applications using an nRF51 board so I have some basic experience with the Nordic uC products. I'll have to order one of those first. Once I receive it, I will reach out to you for some help on getting started. I'll give up on trying to set up the LCD3 for now.

That would be great!!

Please take care when open the keyboard to solder the flash/debug pins. Try to find a way a user would do that, as I didn't did that yet and I would like to know how hard is doing it and the final aspect on the handle bar, etc.

 

[thineight]

Hi casainho, just for my information are you planning to release the new 0.19beta soon? should I wait or is it better to install the 18.2 in the meantime?
Thanks

 

[casainho]

Hi casainho, just for my information are you planning to release the new 0.19beta soon? should I wait or is it better to install the 18.2 in the meantime?
Thanks

Maybe in 1 or 2 weeks as I need to develop and test the change I mentioned before.

 

[perryscope]

I'm currently working on a new trike conversion using a TSDZ2, in this case the rider has one prosthetic leg and a short crank on the right hand side, so tends to generate most power on the left crank only. She does still push with the prosthetic leg on the right but maybe 50% of the power compared to the left.

I was just wondering is the torque sensing fast reacting enough to detect and adjust power based on each half rotation? or would it simply average out the left and right torque values? I want to avoid it 'Hunting' as the torques changes on each push.

I have tried to simulate this on my own bike (with a TSDZ2) and only push on one side and it seams to mostly keep a constant power assistance but i just wondered what people though from the 'code' point of view?