mikrocontroller.net

Forum: Compiler & IDEs Projektarbeit dezentrale Controllersteuerungen


Autor: fen_ert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du solltest erst einmal die C Grundlagen wiederholen (if <=> #if).

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benutzt du mit Intention Präprozessordirektiven in der Schleife?

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: fen_ert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke ohne '#' funktionierts... keine Ahnung warum ich das so gemacht 
habe!?

Autor: ... ... (docean) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sowas geht mit switch case viel schöner...

und auf PIN was schreiben macht glaub ich wenig Sinn...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... ... 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.

Autor: fen_ert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: fen_ert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: fen_ert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: fen_ert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: fen_ert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal ob du was von denen herbekommst. Ist bei uns Standard
http://www.vector.com/

Autor: Hmm... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: fen_ert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.