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
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
... ... 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.
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.
