Hey ich Hab ein Verständnis Problem, warum mein Code einmal läuft und einmal nicht .
Vielleicht kann mir jemand weiter helfen
wenn ich die code zeile "this->engine_state=0b00100000; //motor sperre"
als letztes in Engine_Drivers_setup::setup(), Läuft meine State Machine und die werte passen
wenn ich diese aber vor meinen Array einfüge Läuft meine State Machine nicht !! und die werte passen
logischerweise auch nicht
Engine_Drivers_setup::Engine_Drivers_setup(){
volatile uint8_t *enginePort; //port of engine
volatile uint8_t enginePin; //pin of engine
volatile uint8_t *engineDDRx; //DDRx of engine
unsigned long int engineDelay; // pulse witdh engine
unsigned long gearing; //translation engine
int myarray[15];
uint8_t engine_state;//=0b00000000; // engine stats
/*engine_state :
0
b
0 7 = pulse state 0=off/1=on
0 6 = engine state 0=left/1=right(l/r)(0/1) or in/out(i/o)(1/0)
0 5 = step enable 0=off/1=on
0 4 = stop 0=off/1=on
0 3 = ramp up
0 2 = ramp down
0 1 = limit
0 0 =
*/
}
Entweder bin ich zu alt für C++, oder Dein Code enthält etliche tote Variablen, die nur lokal im Konstruktor deklariert und anschließend weggeworfen werden. Wie sieht denn die Klassendeklaration aus?
Und wieso sollen diese Variablen volatile sein? Wodurch werden die sonst noch asynchron geändert?
@DrDiettrich: Du bist nicht zu alt. Das Problem liegt daran, dass uns der TO nur mit Fragmenten abspeisen will und damit mehr Verwirrung als Lösungsansätze liefert.
mir sind das auch zu viele Stückchen, ich kann daraus nichts ableiten. Ich wette aber das Zeiger hier gar nicht notwendig sind. Übergabe als Referenz wäre wohl angebrachter, wenn überhaupt. In allen was ich in den Fragmenten sehe.
Wenn ich solche versuchten Zuweisungen sehe, dann sind diese sowieso komplett falsch.
engine_state ist kein Zeiger, dass ist ein normales Byte.
Wenn ich solche versuchten Zuweisungen sehe, dann sind diese sowieso komplett falsch.
engine_state ist kein Zeiger, dass ist ein normales Byte.
[Select]
this->engine_state &= ~(1<<7);
Für mich sieht das eigentlich ganz gut aus.
Ob logisch richtig, weiß ich nicht.
Aber formal ist das ok.
Da wird einfach nur das höchstwertige Bit gelöscht.
Statt der Bitfummeleien wären separate Variablen einfacher und übersichtlicher. Oder Bitfields, wenn die wirklich unbedingt alle in einem Byte liegen müssen.
Doc_Arduino:
Hallo,
engine_state wurde als Byte deklariert und nicht als Zeiger. Der Compiler sollte mindestens Warnungen produzieren.
Nööö!
this->engine_state &= ~(1<<7);
Kein Zeiger.
OK, this ist ein Zeiger
Und engine_state ist offensichtlich ein gültiges Ziel dieses Zeigers.
Weitere, oder falsche, Zeiger sehe ich nicht und einen Grund für Warnungen/Errors erst recht nicht.
Ich hab mir gedacht es ist leichter das Problem runter zu brechen ,als den ganzen code zu posten .
Da es eher eine Zufalls Entdeckung war .
Ein paar leer/unnötige variablen sind vorhanden die ich aber später nutzen möchte .
#include <avr/io.h>
#include <avr/interrupt.h>
#include "usb libary/usb.h"
#include "shield libary/shield_setup.h"
#include "time/fast.h"
so sieht im Moment meine Main aus
int main(void)
{
USB.setUart(16000000,2000000); // set uart communication F_CPU,Baudrate
time_int(); //initialize timer1
Engine_Drivers_setup unten;
Engine_Drivers_setup oben;
oben.setup();
oben.influence_Axis_array[0]=&unten.ptr__pos;
*oben.ptr_influence_Axis_count=3;
USB.printChar("okay");
while (1)
{
unsigned long gettime=fastus();
oben.step_engine(&gettime);
}
}
muss dennoch fragen warum du so viele überflüssige Zeiger nutzt? Außer du magst Dinge zuverkomplizieren.
Bsp.
this->engine_state |= (1<<5)
wäre einfacher ohne
engine_state |= (1<<5)
oder das hier
*this->engineDDRx |= (1<enginePin)
wäre einfacher ohne
engineDDRx |= (1<<enginePin)
oder das hier
this->enginePin=5
wäre einfacher ohne
enginePin=5
Was mir persönlich auch nie gefällt ist der Mischmasch der Datentypschreibweise. Alles durcheinander was nur geht. Wer das Arduino Framework ausblendet sollte dann auch ohne auskommen.
Bsp.
this->engine_state |= (1<<5)
wäre einfacher ohne
engine_state |= (1<<5)
Die Dereferenzierung über this stammt aus der alten Zeit, als es noch nicht C++ hieß, sondern noch "C mit Klassen". Damals war das ein MUSS. Es gab keine Alternative dazu.
Heute macht es auch noch Sinn, wenn man explizit sein möchte.
this->engine_state
Macht völlig klar, dass engine_state eine Eigenschaft des aktuellen Objektes ist. Es besteht noch nicht mal im Ansatz die Gefahr, dass versehentlich auf was externes zugegriffen wird und das wäre ein sehr schwer zu findender Fehler.
Also:
Ein besserer Schutz gegen Tippfehler!
Unerwünschte/Unbeabsichtigte Seiteneffekte werden so wirksam eingegrenzt.
Außerdem kostet es nichts, nur zusätzliche Tipparbeit.
Das ist der Grund, warum man das so häufig in Büchern findet.
Warum auch so mancher "Coding Style Guide" das so vehement einfordert.
Es ist also für uns Arduinojünger etwas ungewohnt zu sehen, mehr aber auch nicht.
Auch der Unterstrich in this->engine_state deutet auf ein älteres Paradigma.
Moderner wäre wohl > this->engineState
Ich habe mit einen Zeiger gearbeitet das ich die Speicher Adresse von denn DDRx Register bekomme.
mit der Referenz bekam ich eine Fehler meldungen:
Severity Code Description Project File Line
Error invalid conversion from 'volatile uint8_t* {aka volatile unsigned char*}' to 'uint8_t {aka unsigned char}' [-fpermissive]
*this->engineDDRx |= (1<<this->enginePin)
wäre einfacher ohne
engineDDRx |= (1<<enginePin)
Die DDRx Register werden nur einmal gesetzt.
Aber in der State Maschine werden die PORTx register
Extrem oft genutzt für die Stepper Motorn.
Und nicht nur wegen der portabilität(eventuell umstieg auf anderen microcontroller) möchte ich auf adruino Befehle verzichten, sondern auch rein am interesse daran.
Auch wenn der Weg so etwas schwierig ist.
philaadro:
Und nicht nur wegen der portabilität(eventuell umstieg auf anderen microcontroller) möchte ich auf adruino Befehle verzichten, sondern auch rein am interesse daran.
Auch wenn der Weg so etwas schwierig ist.
Vor allem geht der Weg in die falsche Richtung.
Direkter Zugriff auf die Hardware ist das Gegenteil von Portabilität
und IMHO nur gerechtfertigt, wenn man die Geschwindigkeit wirklich braucht.
Das ist bei pinMode regelmäßig nicht der Fall.
Interesse ist selten geworden, das begrüße ich immer, aber jetzt weisst du doch wie es funktioniert, oder?
Eine Library für eine schöne Statemachine würde ich auf andere Platformen mitnehmen wollen.
Im Grunde verstehe ich sowieso nicht, was I/O in einer Statemachine zu suchen hat.