Hallo in die Runde!

Im laufe der Jahre sind bei Bascom immer mehr CRC-Routinen oberhalb der üblichen CRC8 hinzu gekommen, aber leider noch keine CRC-Routine die "beliebig modifizierbar" wäre.
Es scheitert weniger an dem Setzen andererer Generatorpolynome, als viel mehr solch Parameter wie Polynomlänge.

Aktuell geht es bei mir um bestehende Übertragungsprotokolle die ich nachbauen will, hier anhand von Pocsag:

Codewörter mit 32Bit Breite, davon 21Bit Nutzdaten, gefolgt von 10Bit CRC und zuletzt ein Parity-Bit.
Etliche solcher Codewörter werden in einem DWORD-Array gesammelt. Mein Test-Datensatz besteht z.B. aus 50 solcher Codewörter, die geprüft werden sollen.

Gebastelt habe ich mir folgendes:



Es wird also in der ersten Phase die Parity geprüft.
Im zweiten Schritt wird die CRC jedes DWORD's geprüft.

Im Prinzip funktioniert das auch....Protokollausdruck:

Soweit funktioniert alles, allerdings mit etwas suboptimaler Effizienz:
Während der Parity-Check der 50 Dwörter gefühlt im einstelligen ms-Bereich durchrast, dauert die CRC-Berechnung über alle 50 Testdatensätze gefühlt 20 Sekunden.

Läuft auf einem ATMEGA324PB mit Baudquarz auf 3,6864MHz.
Freilich: Die UART-Ausgaben (115200Bd) mögen etwas bremsen und können freilich raus genommen werden.
Aber die Rechenzeit ist derart brutal das es m.E. kaum was mit dem UART zu tun hat.
Und in der Phase wo diese Routine oben läuft, macht der µC sonst nichts anderes nebenher.

Ergo: Das DWORD-Array, das Kopieren von DWORD und die Parity prüfen läuft fix,
Das was bremst muss irgendwas im unteren Teil, dem Label "PocCRC" sein.
Also die Select Case-Funktion, die Verschiebug des Generatorpolynoms in DWORD PolShift, oder die XOR.Berechnung.

Das solch eine CRC-Prüfung zufuß nicht im µs geht ist klar. Aber wünschenswert wäre in jedem Fall etwas im Bereich 10-100ms maximal statt knappe 20 Sekunden.
Allerdings sehe ich den Flaschenhals gerade nicht...wo dran harkt es?

Jürgen

Hallo in die Runde!

Mit ein Kernproblem war offenbar der komplette Programmumfang.

Da das Evaluationsboard zum SX1231 / SX1231h vom Semtech nicht mehr produziert wird, habe ich mir vor einiger Zeit zwei eigene Evaluationsboards zu den RFM69H Transceiver gebastelt nach groben Vorbild der Evaluationssoftware von Semtech.

Quasi ein Mega324PB mit 24 LowCurrent-LED's und eben dem RFM69H Modul.
Und das Bascom-Projekt hatte dann schnell mehrere tausend Zeilen an Unterfunktionen die aktuell nicht gebraucht wurden, das selbe mit etlichen ungenutzten Variablen.

Hatte das gestern Abend noch weitgehend so aufgeräumt das nur die aktuellen Funktionen übrig blieben. Statt einer Flash-Auslastung von 89% sagt Bascom beim Combilieren nun 21%.

Und siehe da: Er braucht für die CRC-Berechnung nur noch deutlich unter 1 Sekunde, eher ne halbe Sekunde.


Das wäre absolut OK gewesen. Wobei dennoch die Frage bleibt ob es da effizientere Tricks gibt.


Ok, werde ich mal versuchen.

Da hast du recht! Ich würde das so auch nicht machen. In eigenen Projekten habe ich mich bislang immer mit den CRC8 und CRC16-Funktionen von Bascom verlassen.

Nur in diesem Fall muss ich berücksichtigen was Entwickler vor knapp 40 Jahren entwickelt haben und bis heute standardisiert ist.
itu.int/dms_pubrec/itu-r/rec/m…584-2-199711-I!!PDF-E.pdf


Umgekehrt, nämlich so wie du es zum Verschlüsseln geschrieben hast:
Verschlüsseln vor dem senden: Die 10 CRC-Bits von den 21Nutzbits berechnen und anhängen = 31 Bit, zuletzt am Schluss das Paritibit = 32Bit.

Entschlüsseln zuerst die Parität prüfen und das Paritybit im LSB verwerfen, übrig bleiben 31Bit. Dann so oft mit dem Generatorpolynom XOR bis Restwert = 0
Bleibt ein Restwert von >0 liegt ein Bitfehler vor.

Achja...und das mit 10Bit CRC + Parity ist nicht das Einzige an Hau.
So werden, bei unverschlüsselter Informationsübertragung in diesen 21 übertragen: MSB-Bit.21 Unterscheidung ob nachfolgend eine Adresse (0) oder eine Nachricht (1) folgt.
In den restlichen 20Bit wird dann i.d.R. ASCII mit 7Bit übertragen womit in einem solchen Codewort 2,86 Zeichen passen.
Daher braucht es ein Array von verflixt vielen solcher 32Bit-Häppchen um sinnvollen Inhalt zu übertragen.

Jürgen

Hallo!
Ok...UART-Buffer habe ich bislang nur für das einlesen des UART's benutzt, zuletzt bei nem GPS-Empfänger.
Zum ausgeben bislang nicht
Das mag auch daran liegen, das ich den UART in gefühlt 95% all meiner Projekte eher als Entwicklungstool nutze. Eben um zu sehen in welcher Schleife er gerade hängt

Jürgen

Hallo!

Hmm, mit Assembler habe ich mich noch nie auseinandergesetzt.
Muss ich noch ein wenig grübeln wie dein Assembler-Code funktioniert.

Denn das Dingen ist ja:
Um das Pocsag-Projekt "anständig" zu machen mit einem RFM69H muss ich den Parity-Check in Echtzeit machen.

Heißt:
Der RFM69H erkennt das Dotting, immerhin über 500Bit 101010...und startet seine internen AFC und RSSI-Funktionen.
Sobald er das Synchronisationswort empfängt, schaufelt er die Daten mit 1200Baud in sein FIFO.
Mittels FIFO Level-INT hole ich die Daten in Häppchen von 32Bytes ab.
Blöder weise aber erkennt der RFM69H kein Ende der Daten. Werden keine Nutzdaten mehr empfangen, landet in der selben Geschwindigkeit (1200Bd) Mülldaten im FIFO.

Somit muss ich bei jedem 32Byte-Häppchen das ich aus dem FIFO hole die Parity checken um ein Indiz zu haben wo die Nutzdaten aufhören.
Meine alte Parity-Prüfung war flott genug dafür - aber 10x schneller mit Assembler hört sich verlockend an.

Auf der anderen Seite ist aber mein Projekt noch im reinen Versuchsstadium.
Vielmehr will/wollte ich gucken, ob die günstigen SX1231h die auf den RFM69H sitzen prinzipiell Pocsag-tauglich sind.
Für eine Endanwendung wird wahrscheinlich ein gänzlich anderer Funkchip zum Einsatz kommen. Entweder was moderneres von Semtech wie SX1261/2 oder SX1276/8 oder von Texas Instruments.

Jürgen

Hallo Mitch!

Jawoll, auch wenn ich mal wieder an mehreren Bascom-Projekten parallel werkel und dieses Projekt gestern pausierte.

Einer meiner Evaluationsboards :
Board2.jpg
Hat ein Array an Testdaten mit anfangs 50 Dwords und seit Sonntag erweitert auf 84 Dwords und sendet diese bei 865MHz im Minutenzyklus aus dem Nachbarzimmer aus.
Parallel daneben empfange ich die Aussendungen via SDR und einem Decodierprogramm "Poc32" um das gesendete Format zu prüfen.
Das andere Evaluationsboard liegt neben mir und soll versuchen die Aussendungen möglichst Effizient zu empfangen.

Und ne: Ich versuche da nicht dieses deutlich über 40 Jahre alte Protokoll zu erlernen um damit ernsthaft Daten zu übertragen.
Das ginge mühelos und deutlich effizienter mit anderen Funkprotokollen.

Mir ginge es eher um einen Decoder für die messtechnische Bewertung von Pocsag-Netzen, wo die Datendecodierrate und die RSSI nur die halbe Miete ist.
Denn für anständige Messprotokolle braucht es auch zwingend die decodierten Netzdaten aus den ersten zwei Codewörtern einer Batch, dem Frame0.

Und genau da wird es verflixt teuer und selten bei fertigen Lösungen.
Da will ich mir daher zeitnah was eigenes bauen was mir solche Bewertungslogs ausgibt.


Oh ja, probiere ich nachher mal aus.
Als ich gestern die Assembler-Parityroutine ausprobieren wollte was das Forum hier ausgefallen wegen Zertifikatsablauf.
Aber nun geht hier ja alles wieder.

Jürgen