Seite 1 von 1

UDP server und I2C Erweiterungen

Verfasst: So Apr 15, 2018 3:32 pm
von Werner B
Hallo,
ich gebe hier mein Experiment zum UDP server und dem I²C Bus zum Besten …
[attachment=3]BitsAndBytes_cq.png[/attachment]
In Pavel Demins UDP server für den Red Pitaya sind viele Funktionen bereits umgesetzt.
An den I²C Bus, die seriellen und parallelen Schnittstellen wurden die verschiedensten Dinge angeschlossen um die Steuerung gemäß dem HPSDR/METIS Protokoll zu erweitern.
Der Bedarf ergibt sich weil fast alle Anschlüsse des Red Pitaya bereits vergeben wurden, die verfügbare Hardware nicht kompatibel ist oder die gewünschte Funktion noch nicht umgesetzt wurde / werden kann.
Die Auswahl an verfügbaren und sinnvollen I²C Bausteinen ist begrenzt. Leider wird identische I²C Hardware bzw. Adressen und somit identische Steuerung für unterschiedliche SDR Funktionen genutzt.
Das ARDUNIO Sketch von G8NJJ ist soweit eine Ausnahme, es kreiert ein eigenes Protokoll, welches im Prinzip von beliebiger Hardware umgesetzt werden kann. Adaptive Hardware in Form eines Mikrokontrollers.

Ich habe mir einen kleinen Teil des Datenstroms zum UDP server abgezweigt : Die 10 Bytes des Pakets an EP2 zur Steuerung und Kontrolle des SDR.
Sie werden nun auf dem I²C Bus des Red Pitaya zur Adresse 0x24 ausgegeben und stehen dort zur freien Verfügung.
Funktionen die man darin nicht vorfindet sind entweder im HPSDR/METIS Protokoll nicht vorgesehen oder in der HPSDR PC / Tablet Software nicht berücksichtigt.
Das entspricht nur rund einem Prozent des Datenvolumens, stellt jedoch für kleine Mikrokontroller bereits eine anspruchsvolle Aufgabe dar.
Um die Häufigkeit der I²C Übertragungen zu reduzieren sendet der Red Pitaya nur veränderte Inhalte.
Wie schon G8NJJ habe ich mir ein eigenes I²C IC „gebaut“, jedoch für das ursprüngliche HPSDR/METIS Protokoll.

Die seriell am Red Pitaya angebundenen Erweiterungen (I²C, RS232 usw.) behalten ihren aktuellen Zustand beim Beenden / Unterbrechen des HPSDR Betriebs.
Nicht nur für den gemischten Betrieb HPSDR und „Messgerät Red Pitaya“ a’la HAMLAB ist dieser undefinierte Zustand unerwünscht.
Der Red Pitaya adressiert nun auch bei unveränderter aber aktiver HPSDR Oberfläche die I²C Adresse 0x24 zyklisch. Mit diesem „Herzschlag“ kann der HPSDR Modus geordnet enden.
Bei Wiederaufnahme wird der gesamte Status ebenfalls wieder synchronisiert.
Das ist etwas anspruchsvoller, aber soweit es das Protokoll zulässt auch ungleich vielseitiger.

Die ursprünglichen Funktionen bleiben erhalten (QED).

[attachment=2]TWI_TEST_cq.png[/attachment]SPI, I²S, Schieberegister und I²C Leitungen sind typische Störquellen.
Meine Busse sind nur wenige Zentimeter lang und verlassen das abschirmende Red Pitaya Gehäuse nicht.
Nach außen führen möglichst nur Leitungen mit geschalteten Gleichspannungen.

Auf der I²C Adresse 0x50 ist im Red Pitaya ein E²Prom angesiedelt.
Mir zunächst nicht bewusst erklärt das aber heute einiges … „in case you wonder“

Im ATmega wird mittels TWI Hardwareinterface und auf Interruptbasis ein Abbild der Kommando- und Kontrollbytes erstellt.
Das gilt es letztendlich mit Parallelport, Schieberegister, DA-Wandlern usw. auszugeben. So wie es ist gibt es zunächst auf dem Terminal ein ungewohnt übersichtliches Bild der Bits und Bytes, und wann und warum …
Der I²C Bus läuft mit 400kHz, der ATmega bremst ihn nicht aus.
Noch macht der ATmega eigentlich nichts. Die Terminalausgabe sieht etwas verzögert aus, da sie mit nur 115200bits/s läuft und die achtfache Datenmenge ( ASCII Zeichen als 0en und 1sen ) überträgt.
Nur wenige Funktionen sind unterschiedlich bei TX/RX, die Unterschiede werden aber abgebildet.
Gerade und ungerade Kommandos.

Auf dem Codec Board sind die 1kOhm Pull-Up Widerstände des I²C Bus entfernt.
Es war etwas zu viel des Guten.

Im Quellcode zu Pavel Demins UDP server sind ein paar Änderungen mit „WBr“ gekennzeichnet.
Das BASCOM Programm für den ATmega besteht soweit eigentlich nur aus einer Assembler Interruproutine und einem Hardware Watchdog.
Immerhin ein umgänglicher Ansatzpunkt für weniger begnadete Programmierer ?

Wer damit spielen mag, bitte. Wer es brauchen kann, bitte.
Leider schreibe ich C wie Schweine klettern …

Grüße
Werner