www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik UART Interupt serviceroutine


Autor: Gerhard Hagenauer (computerkora)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

nachdem ich bis jetzt mit der Suche im Forum immer wieder eine Lösung 
fand, muss ich nun mal einen eigen Tread aufmachen.

Kurz worum es geht:
Meine Jungs haben eine digitale Autorennbahn, welche einen Aux-port hat, 
welcher etliche Informationen zur Verfügung stellt.

Ich bin nun dabei, für die Rennbahn eine Startampel, Rundenanzeigeturm 
(12 x 7-Segement) und Großbildschirme (2- 3 LCD-Display) zu bauen.
Vom Grundkonzept liest der Mainmicrocontroller (Mega8515) die Daten von 
der Rennbahn und verteilt diese dann über Rs232 an die intelligenten 
Pheripherieeinheiten (Mega13, Mega8).
Alle Microcontroller werden mit Quarzen (12MHz) befeuert und ich setze 
den Bascom Compiler ein.
Für die Kommunikation habe ich mir ein 9 Byte langes Protokoll erstellt, 
wobei ein Startbyte und am Ende ein Prüfsumme übertragen werden sollen. 
Prüfsumme ist noch nicht umgesetzt, da die grundsätzlich Kommunikation 
nicht funktioniert. Alle Empfangsroutinen in den Peripherieeinheiten 
sollten mittels HW Uart und Interrupt Serviceroutinen arbeiten. Auch die 
Empfangsroutine im Maincontroller sollte mit HW Uart und Interrupt die 
Daten empfangen. Der Maincontroller verteilt dann über SW Uarts an die 
einzelen Peripherieeinheiten (bis zu 8 sind geplant).
Dazu habe ich mir zwei Testprogramme geschrieben bei welchen ich das 
austesten möchte. Ein Microcontroller sendet permanent, während der 
andere die Bytes empfangen sollte, auswerten und an den PC weitersenden.
Leider geht das nicht so wie ich mir das vorstelle, vielleicht kann mir 
jemand einen Tipp geben was ich falsch mache. Habe schon einige Tage 
jetzt mit diesem Kommunikationsproblem verbracht und bin nun an einem 
toten Punkt angelangt.

Leider hat die Suche auch nicht den erwarteten Erfolg gebracht. Habe 
schon etliche Beispielprogramme durchgesehen und mein Buch gibt auch 
nichts mehr her was weiterhilft - please help me

Anbei meine Testprogramme

Autor: Gerhard Hagenauer (computerkora)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist die entsprechende Serviceroutine.

lg.
gerhard

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich programmiere nicht in Bascom, kann sein dass ich deshalb deine USART 
- Empfangsinterrupt-Routine nicht finden kann. Der HW-USART ist 
normalerweise unkritisch, nur beim SW-USART muss man höllisch wegen 
Timing aufpassen! Timer-Interrupt-gesteuert sollte er auf jeden Fall 
sein, und bloß keinen großen Code in die Senderoutine packen!

Autor: Gerhard Hagenauer (computerkora)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab die Routine mal aus dem Programm rauskopiert.

Rec_isr:

Temp = Udr

If Temp = Erk Then Protokol_flag = 1
If Protokol_flag = 1 Then

   Rx_buffer(rx_index) = Temp
   Incr Rx_index
   Incr Protokol_l
   If Protokol_l = 10 Then
     Protokol_l = 0
     Protokol_flag = 0
   End If
   If Rx_index = 64 Then Rx_index = 1
 End If
Rx_complete = 0

Return


Ich glaube aber schon zu wissen wo das Problem ist - ich habe einen 
Print #4 , "rx_index   " ; Rx_index ; "temp  " ; Temp in der 
Interruptserviceroutine drinnen um mir Kontaollinformationen auf das 
Terminal zuschicken, ich glaube das genau davon die Problem kommen 
könnten.
Werde mir heute abend das mal etwas genauer ansehen.

Was meinst du mit Timerinterrupt gesteuert sollten er auf alle Fälle 
sein. Es ist sicher der gesamte Ablauf auf dem Maincontroller von Timing 
her sehr anspruchsvoll, da die Rennbahn die Informatinen mit 38400 Baud 
sendet, Zeit auf Tausendstel und dann noch die ganzen Info's über 
Weichenstellung, Reihung, Posiotion des Reglers und das alles in einem 
41 Byte langem Protokoll. Daher habe ich beschlossen die Daten nur zu 
Empfangen und dann sofort zur entsprechenden Peripherieeinheit zur 
Weiterverarbeitung zu senden - da aber ich mindestens 8 
Peripherieeinheiten habe, muß ich SW Uart's verwenden oder geht das 
sowieso nicht?

Anbei eine Prinzipdarstellung meiner Überlegungen.


lg.
gerhard

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tipp: Machs niemals mit mehreren Controllern, wenns auch problemlos 
mit einem geht.  Folgerung: Verwende Deine Energie darauf, Dein System 
so auszulegen, dass Du mit genau einem Controller auskommst (das ist 
relativ einfach - wozu um alles in der Welt braucht etwa die Ampelanlage 
einen eigenen Controller??), nicht darauf, eine 
Inter-Controller-Kommunikation so zu entwickeln und zu implementieren, 
dass sie am Schluss auch funktioniert.  Wie die Erfahrung lehrt, ist die 
letztere Aufgabe nämlich unglaublich knifflig und viel schwieriger zu 
bewältigen, als man das auf den ersten Blick vielleicht vermuten würde.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zustimm !

Multiprozessorkommunikation ist kein Anfängerprojekt und kostet 
mindestens 50% der gesamten Entwicklungszeit.

SW-UART bei 38400 Baud ist ganz böse, dürfte selbst in Assembler kaum 
zuverlässig arbeiten.
Ne SW-UART ist extrem CPU-Zeit gulpend, aber das kann man ja als 
Bascom-Programmierer, der nur Black Boxes zusammenschiebt, nicht wissen.


Am einfachsten ist Multimaster mit CAN, da braucht man nur einmalig das 
Datenblatt lesen, wie man die Baudrate einstellt und die 15 Puffer 
initialisiert.
Und danach macht die Hardware alles von ganz alleine.


Mit der UART und RS-232 geht am einfachsten die Kettenschaltung, also 
TXD an RXD des nächsten (natürlich mit RS-232-Treiber dazwischen).

Dann den 9-Bit Modus auswählen und jeder, für den die Daten nicht 
bestimmt sind, sendet sie einfach an den nächsten weiter.
Einer ist der Master und verhindert, daß fehlerhafte Pakete endlos 
kreisen (Lifetimecounter im Paket).


Dann gäbe es noch den Single-Master mit RS-485, d.h. nur der Master 
sendet und die anderen nur, wenn sie der Master dazu auffordert.
Deshalb sind auch RS-485-Treiber nötig, damit nur ein Slave seinen 
Sendetreiber einschalten kann.


Peter

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter.
Ich habe einen SW-USART bei 38400 Bad laufen. Auf einem Mega8, weil ich 
2 USARTs brauche. Programmiert in C (GCC). Der läuft prima, halbduplex 
natürlich. Aber wie ich oben schon erwähnte: da darf fast kein Code 
'rein, Interruptgesteuert auch und während der Operation hat alles Ander 
Pause. Ich habe ein Single-Mastersystem (Drahtlos) auf diese Weise 
aufgebaut, funktioniert prima.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sonic wrote:

> Ich habe einen SW-USART bei 38400 Bad laufen. Auf einem Mega8, weil ich
> 2 USARTs brauche. Programmiert in C (GCC). Der läuft prima, halbduplex
> natürlich.

Hab ich auch (siehe Codesammlung, vollduplex).
Aber man muß andere Interrupts saukurz halten, damits klappt.

Ich meinte auch eigentlich, daß es für Anfänger kaum zuverlässig zum 
Laufen zu kriegen ist.


Peter

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du recht, hat mich auch ein paar graue Haare gekostet!

Autor: Gerhard Hagenauer (computerkora)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich euch richtig interprediere, dann heisst das, dass ich mir etwas 
enfallen lassen muß, so wie ich mir das vorgestellt habe mit einem 
Maincontroller mittels HW Uart von der Rennbahn mit 38400 Baud entpfängt 
und dann die Massages an die anderen Pheripherieeinheiten mittels mehrer 
SW Uarts verteilt wird nicht funktionieren.
1) Die 38400 von der Rennbahn die sind gesetzt.
2) Weiters möchte ich den Verdrahtungsaufwand zwischen den einzelen 
Peripherieeinheiten so gering wie möglich halten
3) Sollte Spielraum für zukünftige Erweiterungen sein

Ist das ganze mit I2C lösbar, wenn die Peripherieeinheiten als Slave I2C 
arbeiten oder gibt es eine bessere Umsetzungsvariante.

Mir ist klar, dass die Startampel keinen eigenen Controller benötigt und 
ist auch ein wenig als Testobjekt geplant um die grundsätzliche 
Funktionsweise auszutesten, beim Rundentower wirds schon 
anspruchsvoller, wobei ich dort die 12 7 Segmentanzeigen mittels SSA 
1064 ansteuere, da würde auch noch mit vertretbaren Verdrahtungsaufwand 
sich realisieren lassen und die LCD's könnte ich auch an den I2C Bus 
hängen.

Aber bekomme ich dann von der Rechenleistung das alles mit einem 
Controller hin. Ich möchte nähmlich in einer ersten Endausbaustufe die 
aktuellen Rundenzeiten pro Spieler/Auto, die Position und die Abstände 
zur Anzeige bringen und daher war meine Überlegung dies direkt in der 
Peripherie durchzuführen und nicht mit einem Controller. Weiters 
erwartete ich dadurch, dass das Projekt überschaubarer würde - aber wie 
ihr ja dargestellt habt und mir auch klar ist, muß die 
Interprozesskommmunikation funktionieren und anscheihnend ist die mit 
meinem Designansatz nicht umzusetzen.

lg.
gerhard

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Erstes würde ich mir mal ein Konzept machen wie alles aussehen soll. 
Man sagt nicht umsonst: 3/4 der Programmierarbeit entsteht auf dem 
Konzeptblock! Du musst die Prioritäten festlegen, z.B. Rundenzeiten 
messen ist Zeitkritisch. Die Kommunikation zwischen den Komponenten 
nicht. Ob eine Ampel oder Anzeige 5ms später aktualisiert wird wirst du 
kaum merken. DerProzessor kann mehr als du wahrscheinlich glaubst, die 
zeitlichen Abläufe zu realisieren hat bei mir auch 'ne Weile gedauert. 
Aber ein Mega8 oder 32 auf 16MHz kann ganz schön was!
I²C ist auf jeden Fall eine gute Lösung, musts nur beim Programmieren 
aufpassen dass sich das System nicht 'aufhängt' (Watchdog o. Ä. 
benutzen).

Autor: Gerhard Hagenauer (computerkora)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da es eine digitale Rennbahn ist und die Daten schon teileweise 
vorverarbeitet sind, brauche ich auf keine Zeit messen. Die Rennbahn 
liefert mir die Daten über eine serielle Schnittstelle mit 38400 Baud. 
Jede durchfahrt von einem Auto wird gemeldet - die Zeit wird in 
Tausentel Sekunden übertragen - d.h. ich muß die Daten die von der 
Rennbahn kommen (41 Byte), in welcher alle Informationen über Rennmodus, 
welche Stellung hat der Regler und vieles mehr enthalten ist. Es wird 
auch die Startsequenz von der Rennbahn genau überwacht und wenn jemand 
zu früh Started wird dies von der Bahn gemeldet.
Das Problem das ich habe und viele Spieler der Rennbahn, dass das System 
nur ein kleines Text orientiertes LCD Display (8x2)hat. Daher können die 
umfangreich vorhanden Daten nicht dargestellt werden.

Es gibt schon etliche Programme, die die ganzen Daten auf dem PC 
darstellen, ich möchte aber keinen PC an der Rennbahn stehen haben, 
sondern eben vernünftige Elemente die mir die Daten gut transparent 
darstellen und die in die Deko gut zu integrieren sind.

Aber wie du richtig sagst, 3/4 der Arbeit entstehen am Konzeptblock - 
daher sind mir auch die Inputs von euch so wichtig.

Ich habe auch noch nicht richtig angefangen zu progamieren, die Sachen 
die ich bis jetzt gemacht habe, dienen eher meine theoretischen 
Überlegungen in Test zu verifizieren, aber es sind auch schon 3 Wochen 
ins Land gezogen.

Also nochmals danke für jenden Input!!

Sollte ich was vernüftiges auf die Beine gestellt bekommen, so möchte 
ich das auch anderen zur Verfügung stellen - für mich stellt das Projekt 
einen Anreiz dar nach mehreren Jahren wieder zu den Ursprüngen meines 
beruflichen Wirkens zurückzukehren und es macht einfach Spass wieder mal 
mit Oszi, Meßgerät und Lötkolm zu experimentieren.

lg.
gerhard

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na klar, das ist ein Projekt in dem man richtig Gas geben kann!
Ich persönlich mach' es immer so, dass ich die Einzelfunktionen (jede 
für sich) sauber ausarbeite, teste und hinterher nach Prioritäten 
geordnet zusammenfüge. Dann haste auch später was davon, die einzelnen 
Funktionen sind dann immer wieder verwendbar!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst ja nen Mega162 nehmen, mit einer UART für die Rennbahn und die 
andere UART als Master für die Slaves.



Peter

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.