Open Source Firmware für Lishui Controller

[skwad]

@Hochsitzcola bin mit deinen Java tool zu faul geworden , hatte den vector table offset vergessen.
Jetzt krieg ich das hin zu kompilieren und flashen, aber trotzdem hängt es irgendwo, habe ein Paar printf hinzugefügt.

Irgendwie scheint es nicht diesen loop durchzugehen.

    for(i=0;i<32;i++){
        while(!ui8_adc_regular_flag){}
        ui16_ph1_offset+=adcData[2];
        ui16_ph2_offset+=adcData[3];
        ui16_ph3_offset+=adcData[4];
        ui8_adc_regular_flag=0;

    }

Kann als einziges Problem nur denken das ui8_adc_regular_flag nie auf 1 geht, heisst würde nie HAL_ADC_ConvCpltCallback aufgeruft ?

edit: ganz komisch wenn ich einen printf drinnen stelle geht es ...

    for(i=0;i<32;i++){
#if (DISPLAY_TYPE == DISPLAY_TYPE_DEBUG)
    printf_("looping\n ");
#endif
        while(!ui8_adc_regular_flag){}
        ui16_ph1_offset+=adcData[2];
        ui16_ph2_offset+=adcData[3];
        ui16_ph3_offset+=adcData[4];
        ui8_adc_regular_flag=0;

    }

 

[skwad]

bei mir sind auch alles Offsets deutlich anders voneinander ^^.

 phase current offsets:  2000, 2021, 1985
 angle: -177, hallstate:  4, hallcase 4
angle: -161, hallstate:  5, hallcase 45
angle: -95, hallstate:  1, hallcase 51
angle: -34, hallstate:  3, hallcase 13
angle: 20, hallstate:  2, hallcase 32
angle: 85, hallstate:  6, hallcase 26
angle: 147, hallstate:  4, hallcase 64
angle: -160, hallstate:  5, hallcase 45
angle: -95, hallstate:  1, hallcase 51
angle: -33, hallstate:  3, hallcase 13
angle: 21, hallstate:  2, hallcase 32
angle: 83, hallstate:  6, hallcase 26
angle: 148, hallstate:  4, hallcase 64
angle: -159, hallstate:  5, hallcase 45
angle: -96, hallstate:  1, hallcase 51
angle: -33, hallstate:  3, hallcase 13
angle: 19, hallstate:  2, hallcase 32
angle: 84, hallstate:  6, hallcase 26
angle: 149, hallstate:  4, hallcase 64
Motor specific angle:  -1908874088, direction 1
 Lishui FOC v0.9
 Motor specific angle:  -1908874088, direction 1

 

[Atmelfreak]

Kann als einziges Problem nur denken das ui8_adc_regular_flag nie auf 1 geht, heisst würde nie HAL_ADC_ConvCpltCallback aufgeruft ?

edit: ganz komisch wenn ich einen printf drinnen stelle geht es ...

Ich habe zwar keinerlei Erfahrungen mit diesem Projekt hier, aber bin schon in der Microcontroller Programmierung zu Hause.

Es könnte sich evtl. um eine Auswirkung der Compileroptimierung handeln. Wenn der Compiler „denkt“, dass dieser Code keine Auswirkung hat, dann optimiert er ihn einfach weg. Dieses könnte man zumindest beim mir bekannten gcc durch die Definition der Variablen als volatile verhindern.

 

[Hochsitzcola]

Mit dem Branch aber bitte noch vorsichtig sein

Ich habe heute noch einen Bugfix für die Batteriestrombegrenzung bei Rückwärtslauf eingebaut. Eine Batteriestrombegrenzung für Reku gibt es derzeit noch nicht, ich habe die Reku aber noch mal auf dem Rollentrainer probiert. Mit dem aktuellen Defaultwert von current_target = -50 beim Betätigen des Bremshebels merkt man einen moderaten Tretwiderstand, gegen den aber locker angestrampelt werden kann. Mit steigender Geschwindigkeit steigt der Rekustrom, bei um die 20 km/h auf immerhin knapp 2A. Man muß natürlich strikt aufpassen, daß das BMS nicht plötzlich die Füße hochnimmt und die Batterie vom Motor trennt, dann gibt es garantiert magischen Rauch. Wie ich hier eine sichere Batteriespannungs- und Batteriestrombegrenzung einbaue, muß ich mir noch ausdenken, Vorschläge sind gern willkommen!

Gruß
hochsitzcola

 

[tomsen61]

Hallo @Hochsitzcola, habe den master aufgespielt und mal meine Sondersachen eingebaut (Daumengas ohne Treten nur bis 6km/h u. Temperaturüberwachung).
Funktioniert.
Nur der Wert vom Temperatursignal passt nicht.
Dazu fällt mir auf, das adcdata [2 ] für die Temperatur und für ui16_ph1_offset verwendet wird.

Gruß tomsen61

 

[Hochsitzcola]

Nur der Wert vom Temperatursignal passt nicht.

Du musst nur das richtige Arrayelement nehmen, AD1 und AD2 werden jetzt immer mitgelesen.
EBiCS/EBiCS_Firmware

Gruß
hochsitzcola

 

[reinosmart]

Wie ich hier eine sichere Batteriespannungs- und Batteriestrombegrenzung einbaue

man könnte doch einfach die Reku oberhalb einer Zellenspannung von ca. 4,1 Volt disablen. Das BMS schaltet ja erst oberhalb von 4,2 Volt ab. Ist im Auto ja auch so.

 

[Hochsitzcola]

die Reku oberhalb einer Zellenspannung von ca. 4,1 Volt disablen

ja, die Überspannungsabschaltung ist vergleichsweise einfach. Wir regeln aber ja auch bei Reku nicht den Batteriestrom, sondern den Motorstrom. Und auch hier befürchte ich, daß das BMS einfach dicht macht, wenn der Reku-Strom zu hoch wird. Und das ist was, was ich selber nicht testen kann, bei mir in der Gegend gibt es weit und breit keine langen Abfahrten. Und 20A Reku auf dem Rollentrainer bekomme ich wohl nicht getreten

Gruß
hochsitzcola

 

[reinosmart]

wenn der Reku-Strom zu hoch wird

den Reku Strom können und müssen wir ja doch auch begrenzen. Und was die Zwangsreku angeht, halte ich das in der Praxis für völlig überbewertet. Der Controller mit der Original Firmware kann dagegen auch nichts tun, da müssten die Dinger ja schon häufig abgeraucht sein.

 

[Hochsitzcola]

den Reku Strom können und müssen wir ja doch auch begrenzen.

Ja schon, ich kann auch einen Vorschlag machen, nur ausprobieren kann ich es mangels Berg halt nicht gescheit. Und ich hoffe natürlich das die letzten paar freien Bytes dafür noch reichen. Ich habe heute morgen das Anfahren aus dem Stand unter Last etwas verbessert, ich weiß gar nicht, wie viel Bytes jetzt noch frei sind und ob überhaupt noch alle Optionen aus dem Java-Tool funktionieren. Ggf. passt irgendeine Options-Kombination jetzt schon gar nicht mehr in den Speicher

Jetzt komme ich grad wieder an meine Grenzen, was den Compiler angeht. Wenn ich als Release compilieren will, um keine platzraubenden Debug-Informationen mitzuschleppen, gibt es nur Fehlermeldungen . Er scheint da irgendwelche includes nicht mitzunehmen...

Spoiler: Fehlermeldungen

C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4623:3: error: unknown type name 'int32_t'; did you mean '__int32_t'?
int32_t * pTapDelay,
^~~~~~~
__int32_t
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4624:3: error: unknown type name 'uint16_t'; did you mean '__uint16_t'?
uint16_t maxDelay,
^~~~~~~~
__uint16_t
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4625:3: error: unknown type name 'uint32_t'; did you mean '__uint32_t'?
uint32_t blockSize);
^~~~~~~~
__uint32_t
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4661:3: error: unknown type name 'uint32_t'; did you mean '__uint32_t'?
uint32_t numSamples);
^~~~~~~~
__uint32_t
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4672:3: error: unknown type name 'uint32_t'; did you mean '__uint32_t'?
uint32_t numSamples);
^~~~~~~~
__uint32_t
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4684:3: error: unknown type name 'uint32_t'; did you mean '__uint32_t'?
uint32_t numSamples);
^~~~~~~~
__uint32_t
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4696:3: error: unknown type name 'uint32_t'; did you mean '__uint32_t'?
uint32_t numSamples);
^~~~~~~~
__uint32_t
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4708:3: error: unknown type name 'uint32_t'; did you mean '__uint32_t'?
uint32_t numSamples);
^~~~~~~~
__uint32_t
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4720:3: error: unknown type name 'uint32_t'; did you mean '__uint32_t'?
uint32_t numSamples);
^~~~~~~~
__uint32_t
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4795:10: error: unknown type name '__INLINE'
static __INLINE float32_t arm_pid_f32(
^~~~~~~~
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4795:29: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'arm_pid_f32'
static __INLINE float32_t arm_pid_f32(
^~~~~~~~~~~
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4829:10: error: unknown type name '__INLINE'
static __INLINE q31_t arm_pid_q31(
^~~~~~~~
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4829:25: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'arm_pid_q31'
static __INLINE q31_t arm_pid_q31(
^~~~~~~~~~~
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4876:10: error: unknown type name '__INLINE'
static __INLINE q15_t arm_pid_q15(
^~~~~~~~
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4876:25: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'arm_pid_q15'
static __INLINE q15_t arm_pid_q15(
^~~~~~~~~~~
C:/Users/gaswerke/git/EBiCS_Firmware/Drivers/CMSIS/Include/arm_math.h:4987:19: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
static __INLINE void arm_clarke_f32(

Gruß
hochsitzcola

 

[skwad]

Jetzt komme ich grad wieder an meine Grenzen, was den Compiler angeht. Wenn ich als Release compilieren will, um keine platzraubenden Debug-Informationen mitzuschleppen, gibt es nur Fehlermeldungen . Er scheint da irgendwelche includes nicht mitzunehmen...

Vielleicht @Atmelfreak ?

Ich muss noch den volatile probieren, vielleicht morgen

 

[reinosmart]

Ja schon, ich kann auch einen Vorschlag machen

ich würde mal ganz pragmatisch einen maximalen Rekustrom von 10 A vorschlagen. Das sollte jeder Akku abkönnen. Wegen defektem UART kann ich leider auch keine sinnvollen Probefahrten machen.

Ich habe heute morgen das Anfahren aus dem Stand unter Last etwas verbessert

ich hoffe das ist besser als beim BMT

 

[Hochsitzcola]

Wegen defektem UART kann ich leider auch keine sinnvollen Probefahrten machen.

Hast du mal versucht UART3_TX über den Anschluß SL ans Laufen zu bekommen?

Gruß
hochsitzcola

 

[reinosmart]

Hast du mal versucht UART3_TX über den Anschluß SL ans Laufen zu bekommen?

hab leider keine Ahnung wie ich das der Software mitteilen soll

 

[Hochsitzcola]

hab leider keine Ahnung wie ich das der Software mitteilen soll

da muß ich auch zurückrudern, die STM32F103 "low densitiy" haben nur zwei UARTs. Die "medium density", wie auf den Bluepill-Boards verbaut, haben drei.

Gruß
hochsitzcola

 

[reinosmart]

und nur Tx und Rx tauschen? Tx liegt nämlich auf genau 5V ist also defekt, Rx könnte noch i.O. sein.

 

[Hochsitzcola]

und nur Tx und Rx tauschen?

Das geht nicht, das ist ja Hardware UART. Arduino macht gern Software UART per Bit Banging, da kann man beliebige digitale IO Pins für Tx nehmen. Software UART passt aber garantiert nicht mehr in den Speicher, selbst wenn es da eine Library für gäbe, die wir nutzen können....

Gruß
hochsitzcola

 

[reinosmart]

Und ich hoffe natürlich das die letzten paar freien Bytes dafür noch reichen.

könnte man nicht die jeweils nicht benötigten Displays rausschmeißen?

 

[skwad]

könnte man nicht die jeweils nicht benötigten Displays rausschmeißen?

die werden nicht alle mitkompiliert, bloss den ausgwälten.

 

[Hochsitzcola]

die werden nicht alle mitkompiliert, bloss den ausgwälten.

Ich habe grad den Tipp bekommen, daß die wenigen floats, die ich bisher nicht durch Ganzzahloperationen ersetzt habe, jede Menge Speicher fressen.

mit floats

ohne floats

Aber ob ich das wirklich alles im Ganzzahlenbereich gerechnet bekomme, weiß ich noch nicht...

Gruß
hochsitzcola