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
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!
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
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.
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
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.
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
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
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).
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
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!
Du kannst ja nen Mega162 nehmen, mit einer UART für die Rennbahn und die andere UART als Master für die Slaves. Peter
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.