Daten einlesen mittels Sounddatei, ATtiny13a, totales Verständnisproblem

[mandy1]

Liebe Forengemeinde,
bin gänzlich neu hier, hoffe aber trotzdem, dass ich mich halbwegs verständlich ausdrücke.
Folgendes Problem: habe mir eine billige Lichteffektplatine gekauft, welche 8 LED über 5 Pin eines ATiny13a ansteuert. Auf der Platine befindet sich neben einem 5V Stabi und einem 47µ Elko nur noch der Miniprozessor. Mittels "Programmierkabel", welches aus einem USB-Stecker (nur Spannungsversorgung 5V) und einem 3,5mm Klinkenstecker (mono!) besteht. Nf-Ausgang wird über 100n an einen Spannungsteiler je 220k an GND und Vcc geführt. Zum Programmieren dient eine 3 polige Stiftbuchse, welche GND, +5V und das Nf-Signal führt. Auf dem winzigen Board wird diese Buchse auf die entsprechenden 3 Stifte gesteckt.
Jetzt das eigtl. Problem meinerseits - das Nf-Signal führ nur zum ansonsten nackten Resetpin 1 des Prozessors.
Ein mitgeliefertes kleines Programm ermöglicht auf einfachste Weise das völlig freie "Programmieren" jeder einzelnen LED. Funktioniert völlig Problemlos und wird auch ohne Fehler auf den Prozessor übertragen - hört sich an wie die Signale eine Datasette falls dies noch jemand kennt - eine Sounddatei halt.
Wie funktioniert das Einlesen allein über den Restpin ohne zusätzliches Taktsignal?
Das Netzt wirf mir absolut nichts hierzu aus, auch Versuche mittels Datenblatt etwas Licht ins Dunkel zu bringen sind bei mir gescheitert. Wie gesagt, es geht mir nicht prinzipiell um das Programmieren mittels Sounddateien, sondern um das reine "Resetpin-Programmieren".

Wäre schön, wenn mir jemand von den "Alten Hasen" hier ein wenig weiter helfen könnte.

MfG mandy1

[Searcher]

"Alten Hasen"

Hallo,
ich fühle mich angesprochen Aber ob das weiterhilft? Genau Dein beschriebener Fall ist mir noch nicht untergekommen.

Der RESET Pin (PB5) am Tiny13 kann über eine Fuse zu einem I/O Pin umgestellt werden. Ich könnte mir vorstellen, daß auf dem Tiny ein Programm läuft, das die LEDs ansteuert, aber auch auf Signale am ehemaligen RESET Pin (PB5) lauscht. Kommen da jetzt Töne an um die LEDs umzuprogrammieren, erkennt das Tiny13 Programm das und speichert die neue LED Sequenz ab und läßt die LEDS dann entsprechend leuchten. Eine RS232 auf dem Tiny bräuchte auch nur RX und GND um Daten zu empfangen. Das Infrarot Fernbedienungsprotokoll RC5 brohäuchte auch nur eine Ader plus GND wenn man es drahtgebunden verwenden würde.

Weil das ja anscheinend problemlos funktioniert, ist da möglicherweise irgendeine Taktrückgewinnung mit eingebaut? Denkbar ist auch eine Hin- und Rückrichtung über eine Ader. Eventuell eine Quittung oder Verhandlung über die Geschwindigkeit? Hersteller proprietär?

Um zu erkennen, wie das mit den Tönen funktioniert müßte man das Programmier-Protokoll versuchen aufzuzeichnen und zu entschlüsseln.

Gruß
Searcher

[mandy1]

Danke für die schnelle Antwort. Die Vorstellung, dass hier schon etwas vorinstalliert ist hatte ich auch schon, hatte aber bislang noch keine Möglichkeit dies aus zu probieren. Habe mich bislang lediglich ein wenig mit PIC-Programmierung rumgeschlagen und daher leider keine Prozessoren auf Lager - passende sollten in wenigen Tagen verfügbar sein. Ich werde dann das Einlesen mit einem "jungfräulichen" Exemplar probieren - wird wahrscheinlich nicht funktionieren. Ich berichte auf jeden Fall.
Ein "Hochvoltprogrammieren" findet definitiv nicht statt. Das sich einstellende Signal am Resetpin bleibt im Vcc-Bereich von hier 5V (mit Oszi 10M Re kontrolliert). Eine Art Rückkanal ist mit Sicherheit nicht vorhanden, lediglich die angeschlossenen LED stellen ihren normalen Dienst ein und blinken wild im Takte des Soundsignals. Nach Beendigung des Signals nehmen sie sofort die Arbeit im gewollten Rhythmus auf.
Melde mich, sobald ich weitere Erkenntnisse habe (2-3 d).
Gruß mandy1

[Moppi]

Hallo,

ich hätte noch einen Lösungsvorschlag:

Der RESET-Pin ist auch mit PCINT5 bezeichnet, außerdem mit ADC0.
Das NF-Signal wird also wohl auf den ADC-Eingang gelegt. Ein Programm auf dem Tiny13 wandelt das Signal am A/D-Wandler um und wird es als Programmierbefehl interpretieren und etwas im Speicher ablegen/verändern oder die Signalbandbreite vom A/D-Wandler (1024 Werte vermutlich) direkt in 5 Teilbereiche aufteilen, zu je 204 Byte. Also bekommst Du aus einem NF-Signal so Stufen, wobei vermutlich jede Stufe einer LED zugeordnet ist, entsprechend der Stufe wird die zugehörige LED ein/aus-geschaltet.

Du musst aber das NF-Signal irgendwie gewinnen, also musst Du irgend etwas haben, was Du abspielen kannst, um es über diesen NF-Eingang einzuspeisen.



MfG

[Gnom67]

Wenn es tatsächlich ein Signal wie seinerzeit auf der Datasette ist, werden die zeitlichen Abstände ziwschen den Nulldurchgängen gemessen. Das geht mittels Interrupt auf dem Pin. Ich nehme an, wenn man den Interrupt der fallenden Flanke erfasst, hat man das gleiche Ergebnis, wie wenn man die Nulldurchgänge erfassen würde. Aus den Abständen werden 1 und 0 rekonstruiert. Wenn du dir das "Soundsignal" in einem Waveditor anschaust, müsstest du die Bitfolgen lesen können.
Ich glaube nicht, dass ein AD-Wandler bemüht wird, aber gehen könnte da auch - man würde messen, messen, messen und wenn der analogwert bei null ist die Zeit erfassen. Käme wahrscheinlich aufs gleiche raus wie die Interrupts fallender Flanken.
Ich kann mir auch nichts anderes vorstellen, als dass ein Programm auf dem Tiny die Signale einliest und irgendwo die darin gespeicherten LED-Steuerbefehle ablegt. Warum man aber nicht einfach ein serielles Signal auf Rx gelegt hat, ist mir schleierhaft - das wäre doch viel einfacher.

[Moppi]

Interessant. Ich habe mir nie Gedanken um die Datasette gemacht. Aber interessant ist diese Datenspeicherung, wußte bisher gar nicht genau, wie das funktioniert hat. Ich habe so einen IBM-PC mal gesehen, der so ein Teil hatte. Jetzt bin ich über die Schallfolien im Text auf meine kleinen Kinderschallplatten gestoßen, die ich früher hatte. Da kommen Erinnerungen hoch

Über Interrupt? Dachte ich auch erst. Würde ich aber nicht machen, wegen Problemen mit dem Auslösen, man braucht doch ein sicheres LOW und HIGH. Wenn es einen A/D-Wandler gibt, kann man das damit sicherer erfassen, selbst, wenn die Amplituden gering wären. Er beschrieb doch einen Spannungsteiler aus zwei 220k-Widerständen. Das gibt doch im Mittelabgriff genau die Hälfte der Versorgungsspannung, also 2.5V am Eingang, wenn kein Signal anliegt. Vielleicht habe ich da die Konstruktion falsch verstanden, wie mandy1 sie beschrieben hatte:

Auf der Platine befindet sich neben einem 5V Stabi und einem 47µ Elko nur noch der Miniprozessor. Mittels "Programmierkabel", welches aus einem USB-Stecker (nur Spannungsversorgung 5V) und einem 3,5mm Klinkenstecker (mono!) besteht. Nf-Ausgang wird über 100n an einen Spannungsteiler je 220k an GND und Vcc geführt.

Wo führt den da das Signal am Spannungsteiler hin. Einfach einen Spannungsteiler gegen GND und VCC, dort im Mittelabgriff einen 100nF-Kondensator, über den ein NF-Signal eingekoppelt wird?


MfG

[mandy1]

Vielleicht noch kurz ein paar Erläuterungen. Dass der Prozessor bereits vorprogrammiert ist scheint wohl sicher zu sein. Der Mittelpunkt vom Spannungsteiler geht ohne Umwege auf Pin1. Die Spannung ohne Signal liegt bei ca. 3,5V (hochgezogen durch Pull-up nehme ich an). Das Soundsignal (wird durch das mitgelieferte Miniprogramm generiert) zeigt deutlich erkennbar eine Frequenzmodulation - Nulldurchgänge dürften Impulslänge bestimmen. Am Pin 1 - welcher angesteuert wird - zeigt sich bei entsprechend hoher Aussteuerung ein Signal, welches einem Rechteck sehr nahe kommt. Die Amplitude reicht jedenfalls aus um dem Pin sicher Low und High zu signalisieren - es funktioniert auch erst zuverlässig, wenn die Nf-Amplitude einen gewissen, recht hohen, Wert übersteigt. Soweit das, was ich schon mal gemessen hatte.

MfG

[stochri]

Wie funktioniert das Einlesen allein über den Restpin ohne zusätzliches Taktsignal?

Ich habe das mal vor längerer Zeit gemacht.
Es geht mit der Manchestercodierung, genauer gesagt mit der "differentiellen Manchestercodierung", weil die Polarität der Line-Ausgänge der PCs leider nicht genormt zu sein scheint.

[oberallgeier]

.. Manchestercodierung ..

Dazu gibts ne prächtige Beschreibung von San Bergmans hier.

In meiner Quellcode *h-Datei steht das so notiert:

/* ============================================================================= =
        Beispiele für RC-5-Signalgang/Manchester-Codierung

  |       |  |       |  Bitdauer 2x889 µs (2*17,78 tupsi) => 1,778 ms/35,56 tupsi
  +---+   |  |   +---+  Für den Wert des Bits ist Übergang in Bitmitte massgebend
  |HHH|   |  |   |HHH|  
  |HHH+---+  +---+HHH|  ==> Übergang von 1 nach Null <=> Bitwert 0
  |Logic 0|  |Logic 1|  ==> Übergang von 0 nach 1    <=> Bitwert 1
                        
  Beispiel (Graphik zeigt neun Bits) :
      |   |   |   |   |   |   |   |   |   | 
      | +-+-+ | +-+-+ | +-+ +-+-+ +-+ +-+ |   1 Bit   1,778 ms /  35,56 tupsi
      | | | | | | | | | | | | | | | | | | |  14 Bit  24,892 ms / 497,84 tupsi
      +-+ | +-+-+ | +-+-+ +-+ | +-+ +-+ +-+     Gap 114     ms / 2800   tupsi
Bit-  |   |   |   |   |   |   |   |   |   | 
Wert    1   0   1   0   1   1   0   0   0   
// - - - - - - - - - - - - - - -

    Der Rest der RC-Variablen (die folgenden) ist im Prinzip unnötiger Schotter
    und wurde am 08 Nov 2013 entfernt (bis Rev. ~x30 enthalten)
   =============================================================================*/

Anmerkung: tupsi =: Timer Unit Per Sensor Interrupt =: 50 μs Interrupt-Abstand, wird hochgetickert von 1 bis 20000

[mandy1]

Es scheint sich tatsächlich um etwas angelehntes zu handeln (übrigens hoch interessant, obwohl ich`s nicht im Detail nachvollziehen kann - bin da der absolute Dummi - analoge Hardware liegt mir mehr ).
Ein fabrikneuer ATtiny lässt sich, wie erwartet, nicht mit den Ausgabedaten des Tools zum Laufen bringen. Das Auslesen der vorprogrammierten Daten gestaltet sich natürlich auch sehr schwierig. Jetzt bitte nur schmunzeln - ich verwende PonyProg in Verbindung mit LPT-Schnittstelle, in Ermangelung vernünftiger Adapter (ist aber schon auf dem Weg aus Fernost für ein Paar ct.). Auslesen erscheint zwar möglich, jedoch bei jedem Auslesevorgang mit völlig anderen Ergebnissen - unbrauchbar also. Werde mich wohl noch ein wenig intensiver mit der Problematik beschäftigen müssen. Sollte ich doch zu neuen Erkenntnissen gelangen, würde ich an dieser Stelle wieder von mir hören lassen.
Vielen Dank auf jeden Fall für die aufklärenden Beiträge hier im Forum. Bis demnächst.
MfG mandy1