RNB FRA 1.22 oder RN Control über I2C ansprechen

Zitat:

---

Zitat von jagdfalke

Nee bin ich zum Glück nicht, ...

---

Sei froh :mrgreen:

"Gerät":
1 du hast recht, soll wohl sein "A", dann aber wohl "Gerät = 65", sonst ist der BasCom stinkesauer
2 der ganze Klammerausdruck ist ein Kommentar. und ich denk, das siehst du völlig richtig
3 keine Ahnung, wo das herkommen kann, vielleicht eine Konstante
4

Ich versteh das Ganze so, daß das erste Byte von der RS232 eine Geräteadresse darstellt ("A")
Ist es nun wirklich ein "A", liest er die nächsten "Anzahlbytes", weil sie sind für dieses Programm/AVR bestimmt
Wenn nicht, gehört die Nachricht ignoriert und weitergeleitet zum nächsten AVR

Du hast aber recht, so wie es konkret geschrieben ist, funktioniert das in der Realität nicht.

Sind wir jetzt wieder Freunde ? :-({|=

Zitat:

---

Sind wir jetzt wieder Freunde ?

---

Waren wir je Feinde? Klang meine Frage irgendwie provokativ? Wenn ja möchte ich mich in aller Form entschuldigen.
Hast du denn ne gute Lösung für ne Kommunikation zwischen PC und AVR parat? Am Besten doch ein RS232-Interrupt oder? Sonst kann ja der Controller nix mehr machen, wenn er ständig auf einen Input wartet.

mfg
jagdfalke

Zitat:

---

Zitat von jagdfalke

Am Besten doch ein RS232-Interrupt oder? Sonst kann ja der Controller nix mehr machen, wenn er ständig auf einen Input wartet.

---

Ja, klar. Der Interrupt macht das Lesen der Bytes (sind ja meist mehrere) völlig im Hintergrund. Erst wenn die Meldung / Kommando komplett ist,
wird das Hauptprogramm in Anspruch genommen. In der Zwischenzeit macht es irgendwas anderes (Schrittmotoren tickern oder sowas)
d.h natürlich, über die RS232 müssen richtige Messages kommen, mit Header und Längenangabe, eventuell + Checksum
Ein bißchen Protokoll halt.
PC muß aber auch mitspielen, klaro.

Zitat:

---

mit Header und Längenangabe, eventuell + Checksum

---

Ähm, naja, wie gesagt ich bin ja kein professioneller Programmierer. Kannst du des genauer erklären? Oder vielleicht ein kurzes code beispiel oder vielleicht n' Tut wo sowas erklärt wird? Es fängt ja schon bei dem Wort "checksum" an, dass ich net check, was des bedeutet.

mfg
jagdfalke

Hallo Jagdfalke,
entschuldige, dass ich nicht "richtigen und lauffähigen" Code geschrieben habe und mich jetzt erst äußere (z.Zt. sehr viel zu tun - wenig Zeit für Privates) . Natürlich ist mit "A" 65 gemeint - war so einfacher zu verstehen. Das in der Klammer bei "enable int0" ist nur Kommentar, wie PicNic schon richtig angemerkt hat - genau wie "schicke weiter zum Gerät B". Es sollte nur klar machen, dass ich den Interrupt bevorzuge anstatt "ischarwaiting" und die Struktur beschreiben.
Danke PicNic für die Beantwotung des Beitrages von Jagdfalke!
=D>
Grüße,

ich glaube ich verstehe: der obige code war ein beispiel für die kommunikation mehrerer Geräte über RS232, richtig? Als erstes wird ein Buchstabe bzw eine Zahl übermittelt um ein bestimmtes Gerät anzusprechen (ähnlich wie die Adresse bei I2C oder?). Dann kommen die Kommandos nach.

@Dr.U.Bianchi:
Hast du die Kommunikation so protokollartig gestaltet wie PicNick es beschrieben hat (Checksum, Längenangabe, Header) ? Ist das wirklich nötig? Ok Längenangabe seh ich ja noch ein, aber checksum? Und was bitte ist mit Header gemeint?

mfg
jagdfalke

Es geht um die Sicherstellung, daß alle Beteiligten, auch wenn einer davon irgendwie ins Schleudern gekommen ist, zumindest bei der nächsten Message sicher sein kann, wo sie anfängt und wo sie aufhört. Das ist ja bei binären Daten auf einer UART nicht selbstverständlich. Der Header bei einer Message ist ein bißchen sowas wie der I2C Start, wo jeder weiß, jetzt kommt wieder eine Device-Adresse.
Die "Checksum" ist eine Kontrollzahl, die der Sender erzeugt und der Empfänger nachrechnet. (CRC, BCC, etc.) Paßt das nicht, schmeißt der Empfänger die gesamte Message weg und verarbeitet sie nicht.

Wie soll so eine kontrollzahl denn generiert werden? Ich könnte mir vorstellen alle ASCII-Codes zu addieren. Aber dadurch stellt man ja nicht 100%ig fest, dass es sich jeweils um den selben String handelt, oder?

Du hast recht, 100% sicher ist nix
Jedes Kontrollverfahren bringt nur eine gewisse Wahrscheinlichkeit, daß die Daten stimmen. Im "richtigen Leben" wird deshalb gerne CRC-16 verwendet, das ist eine 16-Bit Prüfzahl, da klappt das schon extrem sicher. Ist aber alles eine Wissenschaft.
Das von dies genannte Addieren gibt es, das findest du z.B. in der HEX-File
fur den AVR.
Beim BCC (Rs485) werden die Bytes nacheinander mit XOR verknüpft.
Die Sicherheit hängt auch davon ab, wie lange diese Messages sind.

Hallo Jagdfalke,
bisher schicke ich einfach nur den Gerätecode als erstes und dann die Daten, die bei mir aber immer die gleiche "Päckchengröße" haben. Einen "Header" oder eine Prüfsumme habe ich bisher noch nicht eingebaut - bin dabei aber noch im Entwicklungsstadium.
Zur Zeit denke ich noch über einen Kommandosatz nach (so ähnlich wie bei der RN-Motor) und außerdem über die Übermittlung von ganzen Abläufen, bzw. Figuren für die Steppermotoren.
Grüße, :-b