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

[vshitikov]

ok so here's my take on eMTB mode:

uint8_t eMTB_exponential = EMTB_EXPONENTIAL; 	// getting the requested exponential --> from m_config_vars TBD
      uint8_t eMTB_factor = EMTB_FACTOR; 			// getting the requested eMTB factor --> from m_config_vars TBD

      if (m_config_vars.ui8_motor_assistance_startup_without_pedal_rotation == 0 ||
          ui8_pas_cadence_rpm)
      {
    	  switch (eMTB_exponential)
    	  {
    	  	case 1: ui32_current_amps_x10 = (ui32_assist_level_factor_x1000 * (uint32_t) ui16_m_pedal_power_x10 ) / 1000; break;
    	  	case 2: ui32_current_amps_x10 = (ui32_assist_level_factor_x1000 * (uint32_t) ((uint16_t) eMTB_factor * ui16_m_pedal_power_x10 * ui16_m_pedal_power_x10 / 2000)) / 1000; break;
    	  	case 3: ui32_current_amps_x10 = (ui32_assist_level_factor_x1000 * (uint32_t) ((uint16_t) eMTB_factor * ui16_m_pedal_power_x10 * ui16_m_pedal_power_x10 * ui16_m_pedal_power_x10 / 200000)) / 1000; break;
    	  }
      }
      else
      {
    	  switch (eMTB_exponential)
    	  {
    	  	case 1: ui32_current_amps_x10 = (ui32_assist_level_factor_x1000 * ui32_pedal_power_no_cadence_x10) / 1000; break;
    	  	case 2: ui32_current_amps_x10 = (ui32_assist_level_factor_x1000 * ((uint32_t) eMTB_factor * ui32_pedal_power_no_cadence_x10 * ui32_pedal_power_no_cadence_x10 / 2000)) / 1000; break;
    	  	case 3: ui32_current_amps_x10 = (ui32_assist_level_factor_x1000 * ((uint32_t) eMTB_factor * ui32_pedal_power_no_cadence_x10 * ui32_pedal_power_no_cadence_x10 * ui32_pedal_power_no_cadence_x10 / 200000)) / 1000; break;
    	  }
      }

How it works:

1. The user can set 2 additional variables: eMTB_exponential (1=linear, standard/2=quadratic/3=cubic behaviour) and eMTB_factor (1 to 100, depending on how fast the assist level is supposed to increase)

2. depending on the selected exponential the motor current increases linearly with the pedal power (exponential 1, as in the standard code) or more than linear (exponential 2 or 3)

3. the correction happens on top of the torque sensor calibration and of the selected assist level: for each riding mode the user will still have a different motor output

4. unlimited configurations are possible, for example:
this will be my motor output with an assistance level of 0.03 and eMTB_factor = 5:

Cattura.PNG

and this is in comparison the motor output at the same assistance level and eMTB_factor=10:

Cattura.PNG

In the afternoon I'll go for a ride testing the system and if the outcome willl be good I'll start working on the HMI part.

I think you should square and cube the torque and not the power. If you squeare the power you will have a very little assistance during the startup because the cadence is low. Some people complained here about this. Try it and let us know.

 

[silvocross]

I think you should square and cube the torque and not the power. If you squeare the power you will have a very little assistance during the startup because the cadence is low. Some people complained here about this. Try it and let us know.

This was my initial idea also, but in order to keep it as symple and flexible as possible I decided to give the power a try. after the first tests it will be clear which approach will fit better.

 

[casainho]

3. This as a specific explanation related to the implementation of the curves used for particular purpose.
https://oscarliang.com/throttle-curve/

That is the same as torque sensor calibration. But for this new way for emtb if user need to setup only 2 parameter, will be better to setup like 10 parameters.

 

[casainho]

1. The error "e: 8 Comms" can not be cleared by turning the system on and off. It behaves like its value is saved somewhere in a non-volatile memory perhaps at turning off the display. One way to clear the error, that can be reproduced in 100 % of the tests, is to change the asset level and then to turn off and on the system. Another approach is display settings reset.

The motor controller firmware checks here:

  // check for communications fail or display master fail
  // can't fail more then 1000ms
  if (ui8_comm_error_counter > 10) {
    motor_disable_pwm();
    ui8_m_motor_enabled = 0;
    ui8_m_system_state |= ERROR_FATAL;
  }

The ui8_comm_error_counter is set to 0 every time a communication package is received. It is incremented when a packages was received but CRC fails or at every 100ms. Note that every 100ms a package should be received, the display should send it every 100ms.

The ui8_m_system_state is a RAM variable as is initialized to ERROR_NOT_INIT. When you power off the display it should power off also the motor controller and then at start again the display, the motor controller should start again... unless there SW102 firmware for some reason has a bug....

3. Inconsistent motor torque at the same power level. This is not something new but I never reported that, as it is not easy to reproduce. So while changing the assist levels e.g. for asset level 13, I have experienced two completely different motor responses.
- the first from which I have always complaining. With the motor power burst at the place where we read the maximum of the torque sensor.
- the second is the one it should be. Very smooth and powerful response without any peaks caused by the max values of the torque sensor. I do not know what is happening but if we can reproduce this error forever this will be my favourite motor assist calculation algorithm.
The entry and exit conditions could not be identified for the moment. What is for sure, that if I enter the second scenario, power off and on does not clear it. Also changing the asset level up and down. However after many changes of the asset level we may go back to the first.

I hope we can find the source of this issue...

4. I saw in your code that there is an error related to the handbrake. I tried switching on the display with the brake applied. There was no error shown in the display no mater how long I waited. However the system will start only after I release the brake. Again nothing shown as a reason for the delay.
As far as I remember this should have been fixed and I see in the display code related errors. Experimenting I could not find any condition to invoke it.

I don't know if anything of what I am reporting could be of any help. However if there is another way for better troubleshooting using some tools or methodology could make cense.

You will find on common/state.c motor_init() function - check the logic there!!

The motor controller sends continuous an "alive" a package every 100ms to display, but only after startup. Once it receives a package from the display, will never more send that alive package.

The display waits for that alive package and after 5 seconds (ui16_motor_init_command_error_cnt = 500 shows the error but keeps trying to receive it:

    switch (g_motor_init_state) {
      case MOTOR_INIT_GET_MOTOR_ALIVE:
        ui16_motor_init_command_error_cnt = 500;
        g_motor_init_state = MOTOR_INIT_WAIT_MOTOR_ALIVE;
        // not break here to follow for next case

      case MOTOR_INIT_WAIT_MOTOR_ALIVE:
        // check timeout
        ui16_motor_init_command_error_cnt--;
        if (ui16_motor_init_command_error_cnt == 0) {
          fieldPrintf(&bootStatus2, _S("Error brakes", "e: brakes"));
          g_motor_init_state = MOTOR_INIT_GET_MOTOR_ALIVE;
        }
        break;

 

[plpetrov]

1. The error "e: 8 Comms" can not be cleared by turning the system on and off. It behaves like its value is saved somewhere in a non-volatile memory perhaps at turning off the display. One way to clear the error, that can be reproduced in 100 % of the tests, is to change the asset level and then to turn off and on the system. Another approach is display settings reset.

The motor controller firmware checks here:

  // check for communications fail or display master fail
  // can't fail more then 1000ms
  if (ui8_comm_error_counter > 10) {
    motor_disable_pwm();
    ui8_m_motor_enabled = 0;
    ui8_m_system_state |= ERROR_FATAL;
  }

The ui8_comm_error_counter is set to 0 every time a communication package is received. It is incremented when a packages was received but CRC fails or at every 100ms. Note that every 100ms a package should be received, the display should send it every 100ms.

The ui8_m_system_state is a RAM variable as is initialized to ERROR_NOT_INIT. When you power off the display it should power off also the motor controller and then at start again the display, the motor controller should start again... unless there SW102 firmware for some reason has a bug....

3. Inconsistent motor torque at the same power level. This is not something new but I never reported that, as it is not easy to reproduce. So while changing the assist levels e.g. for asset level 13, I have experienced two completely different motor responses.
- the first from which I have always complaining. With the motor power burst at the place where we read the maximum of the torque sensor.
- the second is the one it should be. Very smooth and powerful response without any peaks caused by the max values of the torque sensor. I do not know what is happening but if we can reproduce this error forever this will be my favourite motor assist calculation algorithm.
The entry and exit conditions could not be identified for the moment. What is for sure, that if I enter the second scenario, power off and on does not clear it. Also changing the asset level up and down. However after many changes of the asset level we may go back to the first.

I hope we can find the source of this issue...

4. I saw in your code that there is an error related to the handbrake. I tried switching on the display with the brake applied. There was no error shown in the display no mater how long I waited. However the system will start only after I release the brake. Again nothing shown as a reason for the delay.
As far as I remember this should have been fixed and I see in the display code related errors. Experimenting I could not find any condition to invoke it.

I don't know if anything of what I am reporting could be of any help. However if there is another way for better troubleshooting using some tools or methodology could make cense.

You will find on common/state.c motor_init() function - check the logic there!!

The motor controller sends continuous an "alive" a package every 100ms to display, but only after startup. Once it receives a package from the display, will never more send that alive package.

The display waits for that alive package and after 5 seconds (ui16_motor_init_command_error_cnt = 500 shows the error but keeps trying to receive it:

    switch (g_motor_init_state) {
      case MOTOR_INIT_GET_MOTOR_ALIVE:
        ui16_motor_init_command_error_cnt = 500;
        g_motor_init_state = MOTOR_INIT_WAIT_MOTOR_ALIVE;
        // not break here to follow for next case

      case MOTOR_INIT_WAIT_MOTOR_ALIVE:
        // check timeout
        ui16_motor_init_command_error_cnt--;
        if (ui16_motor_init_command_error_cnt == 0) {
          fieldPrintf(&bootStatus2, _S("Error brakes", "e: brakes"));
          g_motor_init_state = MOTOR_INIT_GET_MOTOR_ALIVE;
        }
        break;

Casainho,

Thank you for your support and all detailed explanations. I am sorry I did not mention that my display is 850C.

Honestly said, I don't know how to continue further with the troubleshooting of my issue. The only idea that comes to me is to go back to the previous version I used and try to reproduce the error. Do you have any other suggestion? May be I am missing something evident.

 

[casainho]

Thank you for your support and all detailed explanations. I am sorry I did not mention that my display is 850C.

Honestly said, I don't know how to continue further with the troubleshooting of my issue. The only idea that comes to me is to go back to the previous version I used and try to reproduce the error. Do you have any other suggestion? May be I am missing something evident.

I have two bicycles with 860C and I have no issues like you (I think 860 hardware is similar to 850C for communications). Are you sure you don't have power cable crossed with display cable?

I am testing a firmware version for high cadence mode, I had to increase the PWM frequency from 16Khz to 19Khz as also the UART communications frequency (now with double frequency) with display... I wounder if this will be even worst in your case or maybe be the solution. At least it keep working for me.

 

[plpetrov]

Thank you for your support and all detailed explanations. I am sorry I did not mention that my display is 850C.

Honestly said, I don't know how to continue further with the troubleshooting of my issue. The only idea that comes to me is to go back to the previous version I used and try to reproduce the error. Do you have any other suggestion? May be I am missing something evident.

I have two bicycles with 860C and I have no issues like you (I think 860 hardware is similar to 850C for communications). Are you sure you don't have power cable crossed with display cable?

I am testing a firmware version for high cadence mode, I had to increase the PWM frequency from 16Khz to 19Khz as also the UART communications frequency (now with double frequency) with display... I wounder if this will be even worst in your case or maybe be the solution. At least it keep working for me.

The power and data cables do not go in parallel after they leave the motor. There is a distance of 5 cm between them at the point they are crossing each other at 90 degrees. As I said I can reproduce the error with a stopped motor and bike not moving.

There was a complain here in the forum some days ago from a person experiencing similar issue at the power up. He said he had to disconnect the battery many times before the error is cleared.

I always prefer to move forward instead of going back. Even with untested versions. Would you be as kind as to share a version that I can test indoors just for the sake of testing the communication with the display? In case this will not solve the issue, I will downgrade the firmware and try to monitor also the serial communication between the display and the motor at the motor controller side.

 

[vshitikov]

Thank you for your support and all detailed explanations. I am sorry I did not mention that my display is 850C.

Honestly said, I don't know how to continue further with the troubleshooting of my issue. The only idea that comes to me is to go back to the previous version I used and try to reproduce the error. Do you have any other suggestion? May be I am missing something evident.

I have two bicycles with 860C and I have no issues like you (I think 860 hardware is similar to 850C for communications). Are you sure you don't have power cable crossed with display cable?

I am testing a firmware version for high cadence mode, I had to increase the PWM frequency from 16Khz to 19Khz as also the UART communications frequency (now with double frequency) with display... I wounder if this will be even worst in your case or maybe be the solution. At least it keep working for me.

The power and data cables do not go in parallel after they leave the motor. There is a distance of 5 cm between them at the point they are crossing each other at 90 degrees. As I said I can reproduce the error with a stopped motor and bike not moving.

There was a complain here in the forum some days ago from a person experiencing similar issue at the power up. He said he had to disconnect the battery many times before the error is cleared.

I always prefer to move forward instead of going back. Even with untested versions. Would you be as kind as to share a version that I can test indoors just for the sake of testing the communication with the display? In case this will not solve the issue, I will downgrade the firmware and try to monitor also the serial communication between the display and the motor at the motor controller side.

Check your ground connections or connections at all. Look like you have noise on the UART TTL line or an intermittent contact. I also have 850c and I have none of those issues. I don't use it extensively though this time. Maybe you can just move the cable from the display to the motor and see if it triggers the issue

 

[plpetrov]

Check your ground connections or connections at all. Look like you have noise on the UART TTL line or an intermittent contact. I also have 850c and I have none of those issues. I don't use it extensively though this time. Maybe you can just move the cable from the display to the motor and see if it triggers the issue

I did it already. I tried to move and also twist a bit the cables. Unplug and plug the connectors back. Make the distance between the power and the data cables bigger. No change.

I will check the ground connection again. I also was thinking for a quick and easy test setup. To power on the lights as soon as the error condition is greater than one and to switch it off as soon as the error condition is cleared with the next good packet. However I will need to set the development environment first. Playing with the switch on condition, I can get an idea what is the percentage of the lost packets.
In case that the problem is in the cables, I will replace the extension cable I have made with an multi stranded twisted pair UTP cable removing some of the standard motor or display connectors. I wanted also to make the display detachable in a similar way to the Bosch displays for safety reasons.

 

[casainho]

I will check the ground connection again. I also was thinking for a quick and easy test setup. To power on the lights as soon as the error condition is greater than one and to switch it off as soon as the error condition is cleared with the next good packet. However I will need to set the development environment first. Playing with the switch on condition, I can get an idea what is the percentage of the lost packets.
In case that the problem is in the cables, I will replace the extension cable I have made with an multi stranded twisted pair UTP cable removing some of the standard motor or display connectors. I wanted also to make the display detachable in a similar way to the Bosch displays for safety reasons.

I would not twist the cables, at least I have them in parallel on my all bicycles and everything seems to work ok.

As for debug, you can try to send that error transmission counter to the display, in exchange for the wheel speed value and then you will easily spot when the issue happen - well, that value goes only to the display as an answer to the regular package sent by the display every 100ms...

 

[casainho]

New beta release: firmware v0.8.0-beta.1

THIS IS A BETA VERSION FOR TESTING PURPOSES ONLY!!

I did test it but shortly because it is raining since yesterday.

Changelog:

- TSDZ2 max pedal cadence increased from 90 to 120, mostly without sacrificing the energy efficiency
-- increased PWM frequency from 15.6kHz to 19 kHz
-- UART communications frequency is now twice to save processing time
- ebike control loop now runs at twice the frequency in the hope to make system a bit more responsive (tested by vshitikov)

https://github.com/OpenSource-EBike-firmware/Color_LCD/releases/tag/860C_850C_SW102_v0.8.0-beta.1

 

[plpetrov]

As for debug, you can try to send that error transmission counter to the display, in exchange for the wheel speed value and then you will easily spot when the issue happen - well, that value goes only to the display as an answer to the regular package sent by the display every 100ms...

I was also thinking for that. But as you said that the error counter will be cleared in case of successful packet transmission in the next 100 ms, it might be the case I will not see anything on the display. Led blinking might be more visual effect. May be better idea could be an oscilloscope connected to the lights.

I think I will wait for your next release and see what will be the change. As I am currently locked inside, it does not make any real difference. I will just feel more relax in case there is an issue with my setup to know that it will be solved.

I just saw the update. Thank you very much for the test version. Let's see what will happen ....

 

[plpetrov]

New beta release: firmware v0.8.0-beta.1
https://github.com/OpenSource-EBike-firmware/Color_LCD/releases/tag/860C_850C_SW102_v0.8.0-beta.1

First feedback from the short testing:
1. My e: 8 Comms issue is gone. Whatever tests I did, were without any error.
2. The Negative torque for coaster braking seems OK. However may be not so sensitive.
3. The motor overrun I think will require new configuration. It is like it is not there. For the guys with the problem with motor stopping on jumps and bumps it still might be OK but for the coaster brake users it behaves like before the motor overrun fix implementation.
4. Can not really say but may be the motor is a bit more responsive whatever this could mean.

And one question about the firmware programming. I have been always using the option byte backup from the original firmware. Now when I did upload the program memory I decided to compare the 3 tabs and I got an error on the option byte. There was difference in AFR3 so I overwrote the option byte with the value from the original firmware. Is this correct? I remember seeing this recommendation on the website of one of the companies selling TSDZ2 with the open source firmware but I don't remember seeing this on the Wiki.

 

[benno]

Hello

Although Ive been following the project for some time, this
is my first post. I have two questions regarding the implementation.

(1) UART TX interrupt
When bytes are sent via UART with putchar, the code is waiting
for the transmission to complete. With a baudrate of 9600 this
takes appoximately 9 / 9600 = 0.94 ms per byte sent.
The loop

while (UART2_GetFlagStatus(UART2_FLAG_TXE) == RESET)

wastes a lot of cpu cycles.
An alternative would be to let the TXE interrupt routine fill
the tx register whenever it is ready, thus freeing up the time in-between for other computations.
Is there anything that speaks against using TXE interrupts to handle the uart data transmission?

(2) Current measurement
The following document describes a method how to reconstruct the phase currents with a single shunt resistor (p64).
https://www.st.com/resource/en/user_manual/cd00298474-stm32f-pmsm-singledual-foc-sdk-v43-stmicroelectronics.pdf
Just out of curiosity i sampled the current as many times as possible between two pwm interrupts. I was able to get approximately
six readings between two consecutive interrupts, and always got the same number for one measurement series.

As also described in the wiki (https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/TSZD2-Hardware-Information)
there seems to be some analog low pass filtering on the current signal.

My question is now why the current is sampled in each interrupt. Since it is a low pass filtered value anyway, it could be
read once in the 4ms loop.

 

[casainho]

New beta release: firmware v0.8.0-beta.1
https://github.com/OpenSource-EBike-firmware/Color_LCD/releases/tag/860C_850C_SW102_v0.8.0-beta.1

First feedback from the short testing:
1. My e: 8 Comms issue is gone. Whatever tests I did, were without any error.

That is very good!!

2. The Negative torque for coaster braking seems OK. However may be not so sensitive.

Now I need to make another version to configure that value.

3. The motor overrun I think will require new configuration. It is like it is not there. For the guys with the problem with motor stopping on jumps and bumps it still might be OK but for the coaster brake users it behaves like before the motor overrun fix implementation.

This version has the values for that type of bicycles with motor stopping on jumps and bumps, now I need to make another version to configure a selection of fast motor stop and slow stop.

4. Can not really say but may be the motor is a bit more responsive whatever this could mean.

Maybe it be a bit even more but I think we need to save processing power for the future field weakening which will be probably the last and big improvement on this project.

And one question about the firmware programming. I have been always using the option byte backup from the original firmware. Now when I did upload the program memory I decided to compare the 3 tabs and I got an error on the option byte. There was difference in AFR3 so I overwrote the option byte with the value from the original firmware. Is this correct? I remember seeing this recommendation on the website of one of the companies selling TSDZ2 with the open source firmware but I don't remember seeing this on the Wiki.

The firmware enables the bits that it needs on option bytes, you don't need to care about it. This is the code on firmware:

  // verify if PWM N channels are active on option bytes, if not, enable
  if (FLASH_ReadOptionByte (0x4803) != 0x20)
  {
    FLASH_Unlock (FLASH_MEMTYPE_DATA);
    FLASH_EraseOptionByte(0x4803);
    FLASH_ProgramOptionByte(0x4803, 0x20);
    FLASH_Lock (FLASH_MEMTYPE_DATA);
  }

 

[SuperSl0w]

2 days after the motor flash..wow, just wow, this is so great!
Have 1 question, is there a setting to not-reset trip meter every power-up?

 

[casainho]

(1) UART TX interrupt
When bytes are sent via UART with putchar, the code is waiting
for the transmission to complete. With a baudrate of 9600 this
takes appoximately 9 / 9600 = 0.94 ms per byte sent.
The loop

while (UART2_GetFlagStatus(UART2_FLAG_TXE) == RESET)

wastes a lot of cpu cycles.
An alternative would be to let the TXE interrupt routine fill
the tx register whenever it is ready, thus freeing up the time in-between for other computations.
Is there anything that speaks against using TXE interrupts to handle the uart data transmission?
RESET)[/code]

Well, once I tried to do that and I had bad results...

There are only 2 interrupts, the PWM interrupt for motor control and UART RX. I see advantage on having few interrupts, ideally only the PWM motor control only, so motor control never stops!!

Also note that while the ebike_app loop waits for UART sending, in the background the PWM interrupt motor control code runs, so not all the time is wasted.

(2) Current measurement
The following document describes a method how to reconstruct the phase currents with a single shunt resistor (p64).
https://www.st.com/resource/en/user_manual/cd00298474-stm32f-pmsm-singledual-foc-sdk-v43-stmicroelectronics.pdf
Just out of curiosity i sampled the current as many times as possible between two pwm interrupts. I was able to get approximately
six readings between two consecutive interrupts, and always got the same number for one measurement series.

As also described in the wiki (https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/TSZD2-Hardware-Information)
there seems to be some analog low pass filtering on the current signal.

My question is now why the current is sampled in each interrupt. Since it is a low pass filtered value anyway, it could be
read once in the 4ms loop.

That 4ms loop you refer do not runs critical code for motor control. I think is safe to run all motor control on the interrupt, mainly the control of the current because if it fails it is catastrophic.

The PWM motor control code checks for watch dog time out as also ebike_app main loop fail, which increases security. Some months ago there was an issue where the ebike_app main loop fail and the motor kept running at constant current and user could only disable the system by disconnect the battery connector - very dangerous still not motor burned because current control still worked, only brakes and torque sensor was not working. Currently, even brakes are checked on PWM motor control, which makes even safer.

 

[benno]

Thanks for the quick reply!

Also note that while the ebike_app loop waits for UART sending, in the background the PWM interrupt motor control code runs, so not all the time is wasted.

I agree that the pwm interrupt is always executed. If i did my math correct, then sending 25 bytes takes more
than 20ms. So, at least the 4ms loop is blocked / delayed for some time.
In case you are interested - I have implemented a version that makes use of the tx interrupt here:
https://github.com/Frans-Willem/TSDZ2-Clean-EBike/tree/benno-development

Regarding the current measurement: can you confirm that the signal at the gpio pin
corresponds to the average dc battery current and not a high frequency transient signal? I will try to take look at it with a scope.
If that's the case, i think the current reading could safely be moved
to the 4ms loop, thereby reducing the pwm interrupt execution time.

The PWM motor control code checks for watch dog time out as also ebike_app main loop fail

I like the way you also check the main loop now, i remember that this was not the case in a previous version :thumb:

 

[casainho]

Thanks for the quick reply!

Also note that while the ebike_app loop waits for UART sending, in the background the PWM interrupt motor control code runs, so not all the time is wasted.

I agree that the pwm interrupt is always executed. If i did my math correct, then sending 25 bytes takes more than 20ms. So, at least the 4ms loop is blocked / delayed for some time.
In case you are interested - I have implemented a version that makes use of the tx interrupt here:
https://github.com/Frans-Willem/TSDZ2-Clean-EBike/tree/benno-development

I understand the FOC loop is blocked once per 100ms (which now is 50ms) by 20ms and that seems to not be a problem since the begin of the firmware.

Since you did implement the UART TX interrupt and is tested by you, that is great - on the time I did that I had issues and I thought could be something about the interrupt priorities. Would you please make a pull request (and add you name to the contributors on the files) ?

Well, on the other side, this UART TX interrupt will "eat" time from the PWM interrupt, right? PWM interrupt should have the highest priority and should not be blocked by others if possible. Do you known if is possible to have PWM interrupt never being interrupted by others? Because if not, then will prefer to keep as it is right now. Maybe even try to not use the UART RX interrupt and check RX on PWM interrupt code, this way having only one interrupt running and guaranty the timing.

Regarding the current measurement: can you confirm that the signal at the gpio pin corresponds to the average dc battery current and not a high frequency transient signal? I will try to take look at it with a scope.
If that's the case, i think the current reading could safely be moved to the 4ms loop, thereby reducing the pwm interrupt execution time.

The PWM motor control code checks for watch dog time out as also ebike_app main loop fail

I like the way you also check the main loop now, i remember that this was not the case in a previous version :thumb:

Yes, the value is averaged on the hardware that is why I think it is the average of battery current.

The reduction of time on the PWM interrupt may not be that much. Currently there is no need to optimize more, now that I increased the PWM frequency to have the cadence go up to 120 RPM. The only next big step and final one is the implementation of field weakening and I don´t know yet what resources will be needed but I think that will be mostly on the FOC 4ms loop, so I don't see the need to optimize PWM interrupt time.
And as I said I prefer to keep the motor control on the most priority part of the system, I see that as having the system more robust and safe.

 

[phm2000]

Hi

Is it possible to use SW102 without "open it" to flash it and use new firmware ?

Thanks

 

[ilu]

Hi

Is it possible to use SW102 without "open it" to flash it and use new firmware ?

Thanks

No, unless you buy a pre-flashed version like this:

https://www.eco-ebike.com/collections/tsdz2-accessories-parts/products/minimalist-sw102-display-for-tongsheng-tsdz2

 

[Nfer]

Hi

Is it possible to use SW102 without "open it" to flash it and use new firmware ?

Thanks

No, unless you buy a pre-flashed version like this:

https://www.eco-ebike.com/collections/tsdz2-accessories-parts/products/minimalist-sw102-display-for-tongsheng-tsdz2

Are you sure?

I asked Eco Ebike about the bluetooth update of their SW102 display on January and they told me:

"The initial OSF upload by Bluetooth is not available yet. It is still a work in progress. For now, you have to open it, and do it manually. We recommend using the OSF 850c until the Bluetooth OSF update is available for the SW102, and then you can swap displays."

 

[ilu]

Are you sure?

I asked Eco Ebike about the bluetooth update of their SW102 display on January and they told me:

"The initial OSF upload by Bluetooth is not available yet. It is still a work in progress. For now, you have to open it, and do it manually. We recommend using the OSF 850c until the Bluetooth OSF update is available for the SW102, and then you can swap displays."

I'm not sure, as my info is based mostly on what I've read on this forum and OSF wiki pages. Maybe someone who has personal experience will answer. Also check out this:
https://endless-sphere.com/forums/viewtopic.php?f=30&t=105625#p1545439

 

[benno]

Yes, the value is averaged on the hardware that is why I think it is the average of battery current.

Thanks for your input. Ill try to move the current measurement to the 4ms loop in my branch.

Well, on the other side, this UART TX interrupt will "eat" time from the PWM interrupt, right? PWM interrupt should have the highest priority and should not be blocked by others if possible. Do you known if is possible to have PWM interrupt never being interrupted by others?

The STM8 controller has 3 software interrupt levels. So far i kept all of them at the highest level (i.e. non interruptable).
I will try to set the interrupt level of the tx and rx interrupts to 2 so they wont interrupt the main pwm interrupt.
Once i have done that i can try to port that to your current version and make a pull request.

 

[casainho]

Well, on the other side, this UART TX interrupt will "eat" time from the PWM interrupt, right? PWM interrupt should have the highest priority and should not be blocked by others if possible. Do you known if is possible to have PWM interrupt never being interrupted by others?

The STM8 controller has 3 software interrupt levels. So far i kept all of them at the highest level (i.e. non interruptable).
I will try to set the interrupt level of the tx and rx interrupts to 2 so they wont interrupt the main pwm interrupt.
Once i have done that i can try to port that to your current version and make a pull request.
[/quote]
Ok, I would like to have that and I would like to accept that pull request.