Ach so.
Nun ja, ich habe leider momentan keinen MAX232 mehr herumliegen, über den ich eine Debugfunktion realisieren könnte.
Und wenn ich dem 2313 noch das Senden über den RS485 beibringe, handele ich mir ne weitere Fehlerquelle ein...
Vor allem müsste der m128 ganz schnell den Transceiver umschalten, sonst gehen die Daten unter...
Jedenfalls sendet der m128 augenscheinlich (im Terminalfenster mittels Pegelwandler beobachtet) korrekte Daten (3 Bytes, eins je Farbe und schließlich ein Byte mit der CRC8-Prüfsumme).
Im m128 habe ich das mit einem Array gelöst, ist schön kompakt und tut, was es soll.
Was das Programm im 2313 machen soll:
Zuerst wird ein Wert eingelesen.
Dann wird das letzte der 4 Bytes abgetrennt und dessen Dezimalwert als Prüfsumme abgelegt.
Anschließend wird es mit der CRC8 der ersten 3 Bytes des Werts verglichen, stimmen beide überein, wird der Wert weiter zerpflückt:
Jedes der 3 Bytes wird als eigener Einzelstring abgelegt, anschließend wird deren Dezimalwert ermittelt und dieser in die OCRs geladen.
Stimmt die Prüfsumme nicht, wird ein neuer Wert eingelesen, bis er passt.
Damit will ich sicherstellen, dass die Bytes auch an der richtigen Stelle sind.
Mit einem ernsthaften Protokoll bin ich nämlich etwas überfordert
Sollte das alles nichts werden, werde ich wohl eine Zahl verbieten und diese als eindeutigen Identifikator für den Paketanfang einsetzen.
Ist technisch unschön, aber bei den höheren Helligkeitswerten ist kein Unterschied bei 1er-Sprüngen zu sehen...
Man sieht es also wenigstens nicht


_________________


[ Diese Nachricht wurde geändert von: ElektroNicki am 16 Nov 2011 22:53 ]

Zitat : ElektroNicki hat am 14 Nov 2011 20:23 geschrieben :

Mama, der Compiler trollt mich, sag ihm, er soll aufhören!

Ich kann DonComi nur beipflichten. Wenn Du ernsthaft programmieren willst, dann schau Dir C an, mit Basic vergeudest Du nur deine Zeit. C mag zwar schwerer zu erlernen sein, aber fuer Deine Zwecke brauchst Du - zumindest anfangs - ja eh nur ein paar Grundfunktionen.

Guenther

_________________
Gruss
Guenther

Davao City, Philippines, Planet Earth, 31.0 °C (im Schatten!)

CRC finde ich zum Absichern doch ein wenig übertrieben, eine einfache Parität sollte doch ausreichen.

Wenn du bei CRC bleiben willst, dann solltest du die Korrektheit anders prüfen: nämlich den CRC-Algorithmus über die Nutzdaten plus angehängter CRC berechnen. Das Ergebnis sollte dann 0 oder ein Wert abhängig von der CRC-Implementierung von BASCOM sein.

Übrigens kann man auch notfalls den Zwischenweg zwischen rein binären Daten und Dezimalzahlen in ASCII nehmen, nämlich Hexadezimalzahlen in ASCII.
Mit ein paar Operationen kann man daraus nämlich den Binärwert errechnen und wenn man immer Zahlen kleiner 16 mit 0 auffüllt kann man ganz einfach rechnen, viel effizienter als mit der Basis 10 zu spielen.


_________________

Ich habe den Fehler gefunden!
Die Val()s waren unsinnig... da hab ich wohl schon halb geschlafen
Jetzt funktioniert es, wie es soll.
Hab vorhin mal absichtlich Daten mit der richtigen Anordnung, aber der falschen Prüfsumme per Terminal geschickt, es tat sich nix

_________________