Auch wenn ich nur die Hälfte verstanden habe, hört sich das nicht sooo gut an

Dann wars eben Wunschdenken. Habe mir das einfacher vorgestellt.

Dann sind die Sendernamen halt statisch auf die Stationsknöpfe gelegt.

Das Wechseln der Sender lässt sich ja zum Glück auf Hardwareebene realisieren. Das krieg ich hin.


Ich danke nochmal allen, die mir so gut geholfen haben.

Hallo martix,

nana, versuchs wenigstens mal .

Vielleicht, ja hoffentlich irre ich mich und die C-Control ist doch flott genug .

Probieren schadet nicht!

_________________

So.
Habe mir gestern den ULN2003 besorgt und folgendermaßen anschlossen (siehe Bild).

Mein Programm sieht so aus (ja ich weiß, es ist großer Pfusch, weil ich ständig Sachen lösche und wieder hinzufüge... aber von der Logik her sollte es stimmen)

Code :

define Zaehler Word define Light Port[16] define data BYTEPORT[1] define data1 Word Light = Off Zaehler = 0 lcd.init interrupt Impuls #Loop if Zaehler = 1 then if data1 = on then lcd.print 1 else lcd.print 0 end if Zaehler = 0 end if goto Loop 'Endlosschleife #Impuls Zaehler = 1 data1 = data return interrupt end

Ich kriege jetzt pro Tastendruck entweder 5, oder 10 Nullen hintereinander. (Die 10 gefallen mir schon gut, weil es auf dem Bild ja auch Takte waren).

Ich weiß, bis jetzt suche ich noch nach fallenden Flanken, aber trotzdem müsste da doch durch Zufall irgendwo wenigstens eine 1 dabei sein, oder?

Ich befürchte, dass entweder meine Verkabelung noch falsch ist, oder aber das Radio gerne einen Handshake hätte, bevor es anfängt "echte" Daten zu senden. Letzteres glaub ich eigentlich nicht, weil es keinen Eingang dafür gibt (habe nochmal etwas recherchiert. Data-In ist für Titelinformationen eines evtl. angeschlossenes CD-Wechslers).

Stimmt die Verkabelung denn so?

Danke, auch für die Ermutigung, weiter zu machen!

Sooooo - wieso sagt hier keiner was?

Wenn diese Schnittstelle als Slave arbeitet, muss der Master ja eh den Takt erzeugen

Also sieht das Programm eher so aus:

1. Slave aktivieren (via Enable)

2. Daten lesen

3. Slave deaktiveren (via Enable)

Dein Programm ist Murks.


Eine Möglichkeit wäre folgende:

Function ByteLesen()

  Dim i As Integer
  Dim B As Byte

  B = 0

  For i = 1 To 8

    'Alle Bits eine Stelle nach links schieben
    B = B + B

    'steigende Flanke erzeugen
    Clock = 1

    'Daten einlesen
    If Datenleitung = 1 Then
      B = B + 1
    End If

    'fallende Flanke erzeugen
    Clock = 0

  Next

  ByteLesen = B

End Function

So oder so ähnlich kann das aussehen.
Clock = x muss durch den Befehl ersetzt werden, um einen Ausgang auf High oder Low zu schalten.

Dabei spielt natürlich die Geschwindigkeit der C-Control absolut keine Rolle, weil sie den Takt erzeugt.
Frag mich bitte nicht, wieso ich die ganze Zeit so einen Quatsch mit zu langsam etc. erzählt habe.
Muss am Stress liegen

_________________


[ Diese Nachricht wurde geändert von: DonComi am  8 Apr 2011 13:37 ]

Moment, das hab ich jetzt leider nicht verstanden.
Warum muss ich jetzt eine fallende/steigende Flanke erzeugen?
Den Takt gibt doch das Radio an?


Ich glaube dir absolut, dass dein Code richtig ist, aber verstehen tu ich ihn nicht.

Wo ist z.B. der Interrupt hinverschwunden?

Ich versuche nochmal meinen Code zu erleutern.
Ein Interrupt (Taktsignal) unterbricht die Dauerschleife und setzt Zähler auf 1. Noch im Interrupt ließt sie den Dateneingang und schreibt ihn in eine Variable.
Danach gehts zurück in die Dauerschleife.
Findet diese nun den Zähler mit dem Wert 1 vor, schreibt sie die Variable, in der der Datenwert des Eingangs liegt aufs Display.
Eine Umwandlung in ein Byte ist noch nicht erfolgt. Ich wollte nur sehen, ob die Bits richtig und sinnvoll ankommen.

Gruß Martin

Hallo,

Also, wenn man davon ausgeht, dass das Radio ein Slave ist, dann muss ein Takt erzeugt werden. Ist das Radio ein Master, erzeugt den Takt also selber, dann muss man sich mittels Interrupt mit dem Takt synchronisieren.


Sollte es sich um einen Master handeln dann ist dein Programm einfach zu langsam. Wie gesagt, ausgehend vom Oszillogramm am Anfang dieses Threads lägen zwischen zwei Taktimpulsen nur ein paar 10µs, das schafft die C-Control nicht, erst recht, wenn du schwwischendurch aufs Display schreibst..

Es muss jetzt erstmal geklärt werden:

Wer muss den Takt erzeugen - tut das das Radio selbst und wenn ja, wie kann derjenige, den die Daten interessieren, das Radio dazu bringen, die Daten auszuspucken (ENA?).


Am besten du schreibst dem Typen, der dir das Oszillogramm geschickt hat, nochmal eine Email:

Frage ihn, woher der Takt auf dem Bild kommt, ob er den erzeugt hat. Ein Oszi hast du ja nicht selber, oder?
Frage ihn weiterhin, ob ENA Ein- oder Ausgang und welche Bireihenfolge gilt (LSB oder MSB zuerst).

Alles andere ist nicht zielfördernd.


P.S.: Wenn dein Interrupt tatksynchron wäre, dann müsste er exakt 8 mal auslösen, nicht seltener und nicht öfter.

_________________

Gut, habe ihm geschrieben... er wird bestimmt bald antworten.

Nochmals zur Anzahl:
Müssten es nicht vielmehr 64 Takte pro Übertragung sein?
8Bit pro Byte und RDS-Namen sind immer achstellig, also 8x8?
10 ist natürlich Quatsch, weiß nicht wie ich da drauf gekommen bin.

Ich werde das Programm jetzt nochmal ändern.
Es soll nichts tun, außer die Takte zählen und am Ende irgendwann die Anzahl der Takte ausgeben.

Evtl. ist es dann schnell genug.
Mal schauen, was dabei rauskommt.

Ich melde mich dann nochmal, sobald er geantwortet hat.

Gruß Martin

Auf jeden Fall müssen es Vielfache von 8 Bit sein .


Ja, warten wir seine Antwort ab.
Alles davor bringt wenig.

_________________

Hallo,
er hat zwar noch nicht geantwortet, aber ich hab die alten Mails nochmal durchgelesen. Da stehen interessante Dinge drin, die ich so gar nicht mehr im Kopf hatte.
Kurze vorab-Info: Er hat damals versucht, einen Tacho mit Display, der nicht für das Radio gemacht war, an das Radio anzuschließen.

Zitat :

Hi, hab Dir mal Fotos von meinem Versuch gemacht. Ich wollte das Blaupunkt Radio an den Tacho anbinden und habe dazu eine Platine gebastelt. Was das Protokoll von VW angeht so ist Taktfrequenz bei 50 kHz was bedeuten würde Du müsstest mindestens mit dem doppelten (100kHz.) "sampeln". Das einfache an dem Blaupunkt war dass es mit dem I²C Protokoll sendet -> dieses Protokoll können die Controller meistens auf Hardware. Du kannst aber auch das Gamma- Radio verwenden. Auf jeden Fall würde vorschlagen einen Controller zu verwenden und an Deinen PC anzubinden. Dann bekommst Du z.B. die Daten seriell und kannst zusätzlich noch die Sender über den Controller umschalten. Schau es Dir einfach mal an !

Zitat :

kurze Erklärung zum Bild: Bei dem Bild handelt es sich um die Anfrage welche vom Gamma- Radio zum Tacho. Channel 1: Data - jedoch von der Logik umgekehrt (0=1 und 1=0) weil Low-aktiv. Die Anfrage ist immer "hex" 81. Channel 2: Clock - die Daten werden immer zur positiven Taktflanke eingelesen. Kannst mal probieren ob Du auf "0111 1110" dann negieren "1000 0001" (hex81) Channel 3: ENA - bei der Anfrage zieht das Radio den Pegel auf 5 Volt, bei den weiteren Paketen gibt der Tacho vor ob er bereit ist Daten zu empfangen. Ich hab noch ein Bild wo der Tacho positiv antwortet angehängt !

Das Bild, das angehängt ist, gehört zur zweiten Mail.
Ich hätte die Mails gleich am Anfang nochmal durchlesen sollen.
Mir war nicht mehr bewusst, dass drin stand, dass der Tacho auch antworten muss.



Ich bin jetzt doch vollends verwirrt.
100kHz???
Ich weiß auch nicht, auf welchem Pin das Radio die Antwort des Tachos empfangen will.
Ich glaube nicht, dass das so jemals noch was wird.


Mir ist aber noch eine zweite Idee gekommen:
Das Display IM Radio muss doch auch mit relativ simplen Daten versorgt werden. Könnte ich evtl. einfach die Datenleitung des Displays benutzen?


Gruß

Wenn du zum Display-Controller im Radio keine Daten hast, wird es schwierig bis unmöglich diese Daten zu verwenden bzw auszuwerten.

Hast du jetzt schon ausgetestet ob die Geschwindigkeit der C-Control reicht?

Also ja, ich denke die Geschwindigkeit reicht.

Ich habe gerade ein bisschen herumexperimentiert:

Pro Interrupt über den IRQ-Eingang inkrementiert er eine Variable. Sonst nichts.

In eine Dauerschleife gibt er, sobald diese Variable eine Grenze, ich habe jetzt willkürlich 64 genommen, überschritten hat, gibt er die Variable auf dem Display aus.
Während den Interrupts muss er also nur einen Vergleich "Variable >= 64" machen.

Dann habe ich die Sender durchgezappt.
Immer nach 7 Senderwechsel hat er 67 Interrupts ausgegeben. Konstant(fast). Bei zwei von ca. 12 Versuchen hat er 68 ausgegeben.
Das erkläre ich mir damit, dass er ab 64 eben anfängt auf des Display zu schreiben, was ihn "ablenkt" und er dadurch evtl. doch ein Interrupt nicht mitbekommt.

Daraus schließe ich, dass er jeden Interrupt mitbekommt. Wäre er zu langsam würde meiner Meinung nach, durch die Asynchronizität mal mehr, mal weniger Interrupts übersprungen.
Ich bin mir also recht sicher, dass er schnell genug ist.


[ Diese Nachricht wurde geändert von: martix am 10 Apr 2011 18:05 ]

Da steht jetzt aber noch was von I²C - das sollte die C-Control sogar in Hardware beherrschen.

Dennoch, ein komisches Ding.

Getreu den Spezifikationen für SPI und/oder I²C arbeitet das Ding als Master.
Man würde eher einen Slave erwarten, der auf Anfrage Informationen rausrückt.


Eine Anfrage sowie eine folgende Bestätigung (ACK) ist bei I²C eigentlich normal. Bei SPI hat meist kein ACK.

Komisches Ding, das....

_________________

So wie ich das verstanden hab, hat das Blaupunktradio, das er zum Testen verwendet hat, die I²C-Schnittstelle. Mein Gamma-Radio aber nicht.
Die C-Control unterstützt I²C. Jedenfalls gibts ein paar Pins die so bezeichnet sind.

Habe davor allerdings noch nie etwas davon gehört.