Open Source Firmware für Lishui Controller

Diskutiere Open Source Firmware für Lishui Controller im Controller/Regler, Fahrerinformation, Elektronik Forum im Bereich Diskussionen; @Hochsitzcola bin mit deinen Java tool zu faul geworden :), hatte den vector table offset vergessen. Jetzt krieg ich das hin zu kompilieren und...

skwad

Dabei seit
23.10.2019
Beiträge
37
@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.
C:
    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 ...
C:
    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;

    }
 
Zuletzt bearbeitet:

skwad

Dabei seit
23.10.2019
Beiträge
37
bei mir sind auch alles Offsets deutlich anders voneinander ^^.

Code:
 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

Dabei seit
06.07.2015
Beiträge
861
Ort
Berliner Umland
Details E-Antrieb
Bafang SYX-E HR, EBS Plug & Drive V2
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

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
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

1610304432700.png
 

tomsen61

Dabei seit
18.09.2014
Beiträge
82
Ort
Raum Würzburg
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.
1610311851215.png

Gruß tomsen61
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
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 :eek:

Gruß
hochsitzcola
 

reinosmart

Dabei seit
29.04.2017
Beiträge
498
Ort
Remseck
Details E-Antrieb
BionX mit KT36/BluOsec, BionX mit BMT
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

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
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 :eek:

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 :rolleyes:. Er scheint da irgendwelche includes nicht mitzunehmen...

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
 
Zuletzt bearbeitet:

reinosmart

Dabei seit
29.04.2017
Beiträge
498
Ort
Remseck
Details E-Antrieb
BionX mit KT36/BluOsec, BionX mit BMT

reinosmart

Dabei seit
29.04.2017
Beiträge
498
Ort
Remseck
Details E-Antrieb
BionX mit KT36/BluOsec, BionX mit BMT
und nur Tx und Rx tauschen? Tx liegt nämlich auf genau 5V ist also defekt, Rx könnte noch i.O. sein.
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
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
 

Hochsitzcola

Dabei seit
04.09.2009
Beiträge
3.304
Details E-Antrieb
Gazelle mit BionX IGH3 + OpenSource Firmware
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
1610471478823.png

ohne floats
1610472413694.png


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

Gruß
hochsitzcola
 
Thema:

Open Source Firmware für Lishui Controller

Open Source Firmware für Lishui Controller - Ähnliche Themen

Offene Firmware für viele "Discounter-Räder" (Fischer, Prophete, NCM, ....) mit Lishui FOC Controller: Die Firmware hatte ich schon in verschiedenen Threads angesprochen. Ich habe ihr jetzt noch eine nutzerfreundliche grafische Benutzeroberfläche...
Oben