Hallo allerseits !
Ich bin gerade dabei ein µC Programm zu realisieren. Die Idee ist da,
doch leider fehlen gute Impulse zur Umsetzung.
Mein Problem ist folgendes :
Über die RS232 Schnittstelle bekomme ich Daten im HEX Format, also ideal
um sie mit dem uC zu bearbeiten. Das ganze habe ich schon mit einem mit
dem uC verbundenen Gerät gelöst, indem ich mir einfach den Wert aus dem
Empfagsregister geholt und weiterverarbeitet habe.
Nun möchte ich aber mehrere Geräte anschließen und unabhängig
voneinander ansteuern/benutzen.
Dabei soll der uC entscheiden welches Gerät verwendet wird, ganz darauf
basierend wie die gesendeten Steuerbits von der RS232 aussehen.
Leider tappe ich hier völlig im Dunkeln wie das ganze aussehen soll.
Ich hoffe ihr könnt mir mit Ratschlägen mein Leben erleichten
Mfg, awesome
Mach dir einfach ein kleines Protokoll und übertrage am Anfang z.B. eine
Gerätekennung (entweder als Zahl oder als String) und anschließend die
Daten die das Gerät steuern. Also z.B. für einen Schrittmotor (SM1) der
auf 2000 U/Min drehen soll machst du sowas wie:
SM1,SET,2000
Um ihn auszuschalten dann z.B. sowas wie
SM1,SW,OFF
AN
SM1,SW,ON
sowas in der Art. Da kannst du deiner Phantasie freien lauf lassen, nur
sollte es eindeutig und leicht erweiterbar sein und natürlich nicht zu
viel unnütze Daten. Am ende wäre eine Checksumme noch gut um Fehler
auszuschließen. z.B. wie beim NMEA-Protokoll, einfach ein XOR über alle
übertragene Bytes, dass dann mitgesendet wird, z.B.
SM1,SW,ON*4A
Bei den anderen Geräte handelt es sich nicht wirklich um Geräte, da dies
eher in ferner Zukunft liegt.
Es sind einfach Leuchtdioden, 3 Farben Leds und ein fiktives Garagentor
für das einfach ein Endschalter simuliert wird.
D.h die Verbraucher hängen einfach an den Pins und werden über diese
ganz banal (ein/aus) angesteuert.
Das größte Problem ist die Realisierung mit Assembler (SiLabs 8051)
Könnte ich den uC mit C programmieren (was an sich möglich ist) wäre das
ganze mit if Abfragen leicht zu realisieren (if temp == 1111 0000 xxxx
xxxx) Anweisung ; usw.
Leider bin ich mir nicht darüber im klaren wie ich so etwas mit
Assembler realisieren kann (Also wenn Steuerbit = XXXX dann ... etc.)
Hoffe ich stelle mich nicht zu dumm an
Mfg, awesome
Klar ist Stringparsing in Assembler etwas komplizierter, aber so viel
nun auch wieder nicht. Ich würde es einfach so machen, dass du die
empfangenen Daten in ein Fifo packst. Am deines Telegramms machst du ein
Steuerzeichen, z.B. ETX oder so. Sobald du dies empfangen hast hörst du
auf die Sachen in den Fifo zu schreiben und beginnst dann den
String-Vergleich.
Das machst du einfach Zeichen für Zeichen bis zum "Komma" sofern das
dein Trennzeichen ist.
Mit Assembler kannst du ja meist in Compare machen, ansonsten ziehst du
das Empfangene Zeichen vom zu überprüfenden Zeichen ab und testest das
auf "0".Wenn das Ergebnis "0" ist kommt das nächste Zeichen. Sobald ein
unterschied da ist, vergleichst du die Zeichenkette mit dem nächsten
Befehl.
Wenn du den uC in C Programmieren kannst, sparst du dir ne Menge arbeit.
Und insbesondere bei solchen Sachen wird der Code auch nicht so mega
aufgebläht.
awesome wrote:
> Kann mir mal jemand die Idee hinter der Geräteerkennung erklären bitte ?> Bei dem setzt immer alles aus
Tägliches Leben:
Du bist Vorarbeiter und hast 5 Leute unter dir, die auf deine
Anweisungen warten.
Damit es nicht zu einem Kuddelmuddel kommt, leitest du jede
Anweisung mit einer 'Kennung' ein, auf die jeder Arbeiter
reagiert
'Hans, Schalter 1 ein'
'Gerhard, Schalter5 aus'
'Franz, Pumpe ein'
'Jürgen, Bier holen'
'Hans, Schalter 1 aus'
'Franz, Pumpe aus'
Der Namen der Person ist die Gerätekennung!
Wenn jede Person sowieso nur einen Schalter zu bedienen hat,
der entweder ein oder aus sein kann, dann wird das noch simpler.
'Hans, ein'
'Gerhard, aus'
'Franz, ein'
...
Jetzt ersetzt du die Namen noch durch Nummern, wobei jede Person
natürlich seine Nummer kennt und nur auf diese Nummer hört:
(Hans = 1, Gerhard = 2, Franz = 3, Jürgen = 4)
und für Ein benutzt du die Nummer 1 und Aus wird durch 0 angegeben.
1 1 (bedeutet dann Hans: Ein)
2 1
3 1
...
macht dann genau dasselbe. So: jetzt kann es passieren, dass einer
nicht gut genug zuhört und ein paar Zahlen verschläft. Dann ist
dein jetziges Protokoll nícht so gut, weil eine einsame 1 zwei Dinge
bedeuten kann. Das kann die Kennung für Hans sein, das kann aber auch
"ein" bedeuten. Als Abhilfe veränderst du die Kennung zb so, dass
die Personenkennungen immer größer als 80 sind.
Hans kriegt die Nummern von 80 bis 89, Gerhard 90 bis 99, Franz 100 bis
109. etc.
Du schreist also durch die Gegend
80 1 90 1 100 1 ...
und jeder kennt sich aus. Du kannst auch Kennung und Anweisung
zusammenfassen. 80 bedeutet zb: "Hans, ein" während 81 "Hans, aus"
bedeutet. Sinngemäss für die anderen genauso. Obige Sequenz
wird dann zu
81 91 101 ...
und wieder: jeder kennt sich aus welches Kommando für ihn war und
was das Kommando bedeutet.
Danke Karl, so hatte ich mir das auch gedacht, bin jetzt auch zum Glück
bestätigt worden.
Jetzt habe ich nur mehr eine kleine (wahrscheinlich sehr dumme) Frage.
Ich habe ein Interface mit dem ich Werte an den uC schicke. Das ganze
passiert mit 8 Bit wobei die ersten 3 Bits (High Bits, sprich 128, 64,
32) die Gerätekennung oder auch die Steuerbits darstellen. Die
restlichen 5 Bits beinhalten dann den Befehl.
Wenn ich das ganze jetzt übertrage, muss ich alles auf einmal senden,
also z.b 1100 1001 oder sende ich das ganze auf zweimal, also 1100 0000
und 0000 1001 ?
Danke im Vorraus, awesome
awesome wrote:
> Danke Karl, so hatte ich mir das auch gedacht, bin jetzt auch zum Glück> bestätigt worden.
90% der Techniken in der Informatik basieren darauf, was wir Menschen
seit Jahhunderten im täglichen Leben machen. Also einfach mal
beobachten, wie du ein gleichwertiges Problem im täglichen Leben
löst und du hast deine Verfahrensidee.
> Ich habe ein Interface mit dem ich Werte an den uC schicke. Das ganze> passiert mit 8 Bit wobei die ersten 3 Bits (High Bits, sprich 128, 64,> 32) die Gerätekennung oder auch die Steuerbits darstellen. Die> restlichen 5 Bits beinhalten dann den Befehl.>> Wenn ich das ganze jetzt übertrage, muss ich alles auf einmal senden,> also z.b 1100 1001 oder sende ich das ganze auf zweimal, also 1100 0000> und 0000 1001 ?
Was sagt die Doku deines Interfaces?
Aber da das ganze so schön in Bits aufgeschlüsselt ist und sich die
Bitbereiche in einem Byte auch nicht überschneiden, würde ich mal
sagen: kodiere Befehl und Kennung in einem Byte und schicke alles
gemeinsam in einem Byte.
PS: Man kann solche Dinge auch einfach ausprobieren!
Im schlimmsten Fall reagiert das Gerät dann einfach nicht.
awesome wrote:
> Das ganze> passiert mit 8 Bit wobei die ersten 3 Bits (High Bits, sprich 128, 64,> 32) die Gerätekennung oder auch die Steuerbits darstellen. Die> restlichen 5 Bits beinhalten dann den Befehl.>> Wenn ich das ganze jetzt übertrage, muss ich alles auf einmal senden,> also z.b 1100 1001 oder sende ich das ganze auf zweimal, also 1100 0000> und 0000 1001 ?>
Wenn Du "alles auf einmal" sendest, hast Du die 8 Bits. Sendest Du "das
ganze auf zweimal", so hast Du statt dessen aber 16 Bits.
Die richtige Antwort hängt vom Empfänger ab.
Punkt zu Punkt sollte bei dieser einfachen Aufgabenstellung eigentlich
reichen denke ich. Der uC soll dann durch Maskierung des eingegangenen
Byte entscheiden welcher Programmteil aufgerufen wird und durch
nochmalige Maskierung was für eine Aktion durchgeführt wird.
Kennt vielleicht jemand eine Seite für praktisches programmieren in C ?
Also etwas das Befehle wie invertiern, logische Verknüpfungen und
dergleichen abdeckt ?
Mfg, awesome
Ok, ich habe das ganze nun fast fertig programmiert, nur habe ich noch
ein paar kleine Fragen und hoffe jemand kann mir helfen.
Zur Info : Ich programmiere meinen 8051er in C
Ich lese nun meine empfangenen Daten aus SBUF aus. Wie kann ich diesen
Wert in einen binären Wert umwandeln und dann zwei mal und verknüpfen um
Steuerbits und Befehlsbits zu trennen. Das ganze sollte binär sein
Mfg, awesome
awesome wrote:
> Ok, ich habe das ganze nun fast fertig programmiert, nur habe ich noch> ein paar kleine Fragen und hoffe jemand kann mir helfen.>> Zur Info : Ich programmiere meinen 8051er in C>> Ich lese nun meine empfangenen Daten aus SBUF aus. Wie kann ich diesen> Wert in einen binären Wert umwandeln
Das was du aus SBUF ausliest, sind schon binäre Werte. Das ist
einfach nur ein Byte. Lass dich in C nicht davon blenden, dass
der Datentyp 'char' heist. Ein char ist in C auch nur ein
Integer-Datentyp für kleine Zahlen.
> und dann zwei mal und verknüpfen um> Steuerbits und Befehlsbits zu trennen.
Das willst du sicher nicht mit Multiplikationen etc. machen.
Dafür gibt es UND-Verknüpfungen, ODER-Verknüpfungen und
Schiebebefehle.
UND Verknüpfung in C ist ^ oder ?
bzw. wenn ich die Daten im Hex Format erhalte, liegen sie im SBUF als
binärer Wert vor oder muss ich das ganze irgendwie umkonvertieren oder
gleich mit Hex Werten arbeiten ?
awesome wrote:
> UND Verknüpfung in C ist ^ oder ?
Spätestens jetzt ist der Hinweis angebracht, dass du ohne
vernünftige Literatur mit einer Sprache wie C Schiffbruch
erleiden wirst. Und zwar ganz grauslichen, gewaltigen
Schiffbruch.
& binäres UND
| binäres ODER
^ binäres XOR
~ binäre Negation
nicht zu verwechseln mit
&& logisches UND
|| logisches ODER
(logisches XOR existiert nicht)
! logische Negation
>> bzw. wenn ich die Daten im Hex Format erhalte, liegen sie im SBUF als> binärer Wert vor oder muss ich das ganze irgendwie umkonvertieren oder> gleich mit Hex Werten arbeiten ?
Du kannst den Wert so bearbeiten, wie du ihn bekommst.
Und jetzt ab in die nächste Buchhandlung. Tutorien sind kein
Ersatz für ein Buch.
Hey Leute,
hab mir gerade den thread durchgelesen da ich vor einem gleichen problem
stehe. nur einwenig komplizierter!
es sind auch mehrere geräte die nur rs422 schnittstelle haben und keine
adressierung kennen! sie müssten jedoch alle getriggert werden was auch
nur per software-pollen möglich ist.
die idee, die ich bis jetzt hatte, war wie hier auch ein multiplexer
oder ähnliches zu verwenden nur sollte die baudrate >921600 BAUD
sein???!!!auch die trigger-rate beträgt mehrere kHz!
is so etwas überhaupt realisierbar? gibt es für solche fälle spezielle
µCs? wenn ja welche möglichkeiten gibt es?
wär über jede anregung und idee froh!!!
gruß keniff
>nur sollte die baudrate >921600 BAUD sein
Würden 921601Bd Deine Anforderung erfüllen?
RS422 ist ganz schlecht, insbesondere wenn man nicht weiß worum es geht.
Je nach dem wieviele Geräte angeschlossen werden sollen, würde ich einen
Prozessor nehmen, der mehrere UARTs auf dem Chip hat und für jedes Gerät
eine bereitstellen.
Ggf. kann man auch mehrfach UARTs verwenden, die die spezielle Baudrate
eingestellt bekommen und für Rx-Tx hinreichend Fifos als Puffer haben.
Hallo Zusammen,
ich habe mir mal eben den Thread durchgelesen, werde aber nicht so ganz
schlau daraus.
Was ich genau wissen möchte ist kann ich mehrere ATTiny2313 mit einem
ATMega8 über RS232 ansprechen?
Also ich sende einen Befehl mit dem Mega8 an die Schnittstelle und Alle
Tiny2313 verarbeiten diesen Befehl aber je nach Befehl dass nur der der
sich angesprochen fühlt ( vorher eine Adresse zugewiesen ) einen
weiteren Befehl ausführt!
Wird das so funktionieren oder muss ich das irgendwie anderest Lösen?
Um Tipps währe ich sehr dankbar!
gruß
Thorsten
Du könntest die "clients" auch durchschleifen.
Sprich:
TX vom Host auf RX von client1
TX von client1 auf RX von client2
TX von client2 auf RX von client3
TX von client3 auf RX von Host
(natürlich beliebig erweiterbar)
Jetzt musst du dir nur noch nen Protokoll ausdenken, mit dem du
sicherstellst, dass nur der angesprochene µC die Befehle ausführt.
(Eventuell ne seriennummer im µC merken und die ansprechen)
Das ganze würde dann in etwa so funktionieren:
Host sendet Zeichenfolge an client1.
Client1 stellt fest, dass der Befehl nicht für ihn ist und sendet den
Befehl weiter an Client2. Dieser verarbeitet den Befehl und sendet die
Antwort an client3. Client3 stellt fest, dass das Empfangene ne Antwort
ist und leitet die an den Host weiter.
Sinnvoll wäre vielleicht noch ein Zählbyte bei den Befehlen, damit der
Host weiß, wie viele Clients er "an der Strippe" hat.
Das alle die Nachricht empfangen haben erkennt er daran, dass er ne
Antwort bekommen hat ;-)