Moin, im Rahmen meines Maschbaustudiums erstelle ich derzeit ein Programm zur dezentralen Steuerung gleichartiger Systeme. Ich habe grunderfahrungen im c/c++ programieren. Mit µCs habe ich bisher allerdings noch nicht gearbeitet. Ich werde sicherlich auch in den folgenden Wochen noch Hilfe brauchen, wenn also ab und an mal der ein oder andere nach meinem Thread schauen würde währe das echt klasse. Ich arbeite derzeit mit AVR-Studio 4.14 und habe versucht mich anhand des hier vorgestellten Tutorials und "Mikrocmputertechnik mit Controllern der Atmel AVR-RISC-Familie" von Günter Schmitt einzuarbeiten. Allerdings habe ich das Problem dass die Programmierung in der AVR-Studio Umgebung etwas irritiereund ist. Sie unterscheidet sich sowohl gegenüber der im Tutorial als auch gegenüber der im Buch und einige Befehle werden nicht so ausgeführt wie sie sollten. z.B: while (1) { #if (status==1) { /*ZielID ermitteln*/ /*Übergaberichtung beibehalten*/ status++; PINF = 0x01; } #elif (status==2) { /*Zielrichtung bestimmen & ausführen*/ /*Folgeststion reservieren*/ status++; PINF = 0x02; } #elif (status==0) { SS=0; /*Auf Geradeausstellung gehen*/ status++; PINF = 0x03; } #endif } Die While-Schleife wird nicht ausgeführt! Den µC bzw. die Platine habe ich noch nicht, deswegen benutze ich AVR-Studio zum Simulieren. Danke fen_ert
Du solltest erst einmal die C Grundlagen wiederholen (if <=> #if).
Benutzt du mit Intention Präprozessordirektiven in der Schleife?
Was macht denn das '#' vor den if bzw. endif-Anweisungen? Wenn du dies wirklich so dort stehen hast, so wird dies durch den Präprozessor aufgelöst. Ist status niht mittels #define definiert, so wird die komplette Schleife wegoptimiert. Also versuchs mal ohne '#'! Michael
Danke ohne '#' funktionierts... keine Ahnung warum ich das so gemacht habe!?
sowas geht mit switch case viel schöner... und auf PIN was schreiben macht glaub ich wenig Sinn...
... ... wrote:
> und auf PIN was schreiben macht glaub ich wenig Sinn...
Bei neueren Modellen durchaus (Toggle-Funktion). Ob das hier gemeint
ist, ist eine andere Frage.
Moin, danke für die Unterstützung beim letzten mal. Mein Projekt nimmt langsam etwas Form an, allerdings benötige ich zusätzliche I/O´s und habe überlegt, ob man so etwas nicht mit Hilfe des X-Mem-Interfaces gut realisieren kann. Klar ich weiß, mit Schieberegistern ist eine klassische Lösung. Schneller und wenn´s funktioniert, komfortabel sollte es aber auch gehen, wenn mann die Adressierung dazu verwendet, zwischen den Buffern hin und her zu schalten und die Informationen wie aus einem Speicher ausließt. Ich wüsste gerne was ihr davon haltet, und ob jemand so etwas vielleicht schon einmal realisiert hat? Ich habe Versucht den Vorgang mit AVR-Studio zu simulieren, aber bisher hat das soweit ich es sehen konnte zwar funktioniert, der Zugriffsmechanismus war jedoch nicht erkannbar. Zeigt dieses Programm den Abruf von Daten über das X-mem Interface überhauft auf Pinebene an, oder werden diese Vorgänge im Hintergrund durchgefürt und nicht näher angezeigt? Gruß Steffen
Das wird dann wohl ein kleines CMOS-Grab geben. Für die Ausgabe ein D-Latch und für's Lesen einen Bustreiber mit Dastenrichtungsselektion und Tri-State... (oder so ähnlich). Als Orientierung kannst ja mal schauen, wie man ein LCD am X-MEM anschließt. Im Prinzip das gleiche Schema, nur dass die Port-LAtches etc. da schon im LCD drin sind. Ein I2C Portexpander, oder sowas in der Art, kann man prima für I/O benutzen. Und man muss sich nicht mit dem ganzen CMOS Kruscht rumschlagen. Aber für Lehrzwecke ist beides zu empfehlen ;-) Dazulernen tut man in beiden Fällen...
A. K. wrote: > ... ... wrote: > >> und auf PIN was schreiben macht glaub ich wenig Sinn... > > Bei neueren Modellen durchaus (Toggle-Funktion). Ob das hier gemeint > ist, ist eine andere Frage. Ich hatte aber vor kurzem mit nem aktuelleren GCC das Problem, das der aus der Zuweisung auf PIN Mist gemacht hat... Vielleicht ist das inzwischen auch korrigiert...hab nimmer nachgeforscht. Aber nicht einfach blind glauben (siehe .lss). Gruß Fabian
Ich hatte eigentlich vor keinen Latch zu verwenden, sondern lediglich die höheren Adressen. Natürlich könnte ich auch noch einen latch verwenden, aber so viele eingänge brauche ich auch nicht. Vergesst das mit dem auf Pin schreiben mal, da hatte ich nur etwas herumexperimentiert um die Funktionsweise der Befehle auszutesten. Gruß Steffen
N'abend,
ich bin gerade dabei die Interruptrutienen für die Datenaktualisierung
zu schreiben und hänge etwas fest.
ISR (TIMER2_OVF_vect){ //Input-/Outputaktualisierung
//Variablen auslesen und sortieren
#define OFFSET 0x2000
int i,j;
unsigned char *p[4];
*p[0] = (unsigned char *) (OFFSET + 0x0100);
*p[1] = (unsigned char *) (OFFSET + 0x0200);
*p[2] = (unsigned char *) (OFFSET + 0x0400);
*p[3] = (unsigned char *) (OFFSET + 0x0800);
if (????) licht_tast[0]=1;
else licht_tast [0]=0;
}
Der Interrupt soll Daten aus meinem bereits erwähnten pseudospeicher
"auslesen" und auf die globalen variablen verteilen/aktualisieren. Ich
weiß jetzt jedoch nicht wie ich einzelne Bits der ausgelesenen Bytes in
vertretbarem Umfang abfragen kann. Ich meine das irgendwo gelesen zu
haben, kann´s aber gerade nicht finden.
Hoffe ich konnte meine Frage verständlich machen.
Danke
Steffen
P.S. Sollte ich anderweitig Mist gebaut haben, sagt´s mir ruhig.
ich glaube es hat siche erledigt!
Hab´s jetzt so gelöst:
ISR (TIMER2_OVF_vect){ //Input-/Outputaktualisierung
//Variablen auslesen und sortieren
#define OFFSET 0x2000
char i,j,k;
unsigned char *p0 = (unsigned char *) (OFFSET + 0x0100);
unsigned char *p1 = (unsigned char *) (OFFSET + 0x0200);
unsigned char *p2 = (unsigned char *) (OFFSET + 0x0400);
unsigned char *p3 = (unsigned char *) (OFFSET + 0x0800);
i=*p0;
//Initialsensoren:
if (i & 0x01) stell_init[0]=1;
else stell_init[0]=1;
if (i & 0x02) stell_init[1]=1;
else stell_init[1]=1;
if (i & 0x04) stell_init[2]=1;
else stell_init[2]=1;
if (i & 0x08) stell_init[3]=1;
else stell_init[3]=1;
//Lichttaster:
if ((i & 0x40)||(i & 0x80)) licht_tast[0]=1;
else licht_tast[0]=0;
i=*p1; //neue Speicherstelle
if ((i & 0x01)||(i & 0x02)) licht_tast[1]=1;
else licht_tast[1]=0;
if ((i & 0x04)||(i & 0x08)) licht_tast[2]=1;
else licht_tast[2]=0;
if ((i & 0x10)||(i & 0x20)) licht_tast[3]=1;
else licht_tast[3]=0;
if ((i & 0x40)||(i & 0x80)) licht_tast[4]=1;
else licht_tast[4]=0;
//Inkremetalzähler:
j=*p2;
//Relais:
k=((motor_relais[3]<<3) & 0x08)+((motor_relais[2]<<2) &
0x04)+((motor_relais[1]<<1) & 0x02)+(motor_relais[0] & 0x01); //k
auffülen
*p3=k;
}
ist zwar recht lang...aber egal!
Schönen Abend noch!
Hallo mal wieder, mein Projekt nimmt langsam Form an und ich bin recht gespannt, ob alles wie geplant laufen wird. Für die geplante Platine fehlt jetzt nur noch ein Programmer. Bisher konnte ich mit einem STK500 Board gut experimentieren, aber der µC den ich verwenden will, wird vom Board bzw der Erweiterung (STK502) nicht unterstützt. Ich vermute, dass das hauptsächlich an der integrierten CAN-Schnittstelle liegt. Bin mir aber nicht sicher. Und jetzt die Frage: Kann ich das STK 500 Board als Programmer verwenden und über SPI mit meiner PLatine bzw. dem µC auf der Platine verbinden oder brauche ich einen zusätzlichen Programmer? Und wenn ich einen Programmer brauche, welchen könnt ihr empfehlen? Außerdem brauche ich noch eine Schnittstelle zwischen PC und CAN, habe da jede Menge gefunden (PCI-Steckkarten, USB-Geräte....) hat jemand Erfahrung damit und kann mir ein Modell empfehlen? Danke Steffen
> Für die geplante Platine fehlt jetzt nur noch ein Programmer. Bisher > konnte ich mit einem STK500 Board gut experimentieren, aber der µC den > ich verwenden will, wird vom Board bzw der Erweiterung (STK502) nicht > unterstützt. Ich vermute, dass das hauptsächlich an der integrierten > CAN-Schnittstelle liegt. Welchen Controller nutzt du denn? Wenn es ein AVR ist ;) sollte sich der neue Chip auch mit dem STK500 programmieren. Maximal eine Adaperplatine um MISO/MOSI/SCLK/RESET richtig zum Target zu routen. > Und jetzt die Frage: Kann ich das STK 500 Board als Programmer verwenden > und über SPI mit meiner PLatine bzw. dem µC auf der Platine verbinden > oder brauche ich einen zusätzlichen Programmer? siehe oben. > Und wenn ich einen Programmer brauche, welchen könnt ihr empfehlen? Ähm, welcher Controller war es nochmal?
Als controller wird ein AT90CAN128 verwendet, der bietet sich auf grund der CAN implementierung an. Die SPI Schnittstelle zum µC zu bekommen ist kein problem, ich müsste nur wissen, ob ich das STK500, anstat es wie vorgesehen mit einem µC auf dem Entwicklungsboard zu verbinden, mit einem Controller auf einer Fremdplatine verbinden kann um ihn zu programmieren, oder ob es dann Probleme gibt. Selbstverständlich die richtigen Anschlüsse vorausgesetzt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.