- 3D-Druck Einstieg und Tipps         
Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 28

Thema: LEDschaltung im PingPong

  1. #11
    Benutzer Stammmitglied Avatar von funk3r
    Registriert seit
    13.10.2009
    Ort
    Niedernhall
    Beiträge
    41
    Anzeige

    Powerstation Test
    Da ist natürlich was dran.
    Beim selber programmieren weiß man wenigstens was man hat
    Grüßle Jo
    ______________
    ><(((°> Son of God through Jesus Christ his Son <°)))><
    Mein Blog: funk3r.de

  2. #12
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.687
    Das PingPong ist ja etwas aus den Schlagzeilen. Aber ich bin mittlerweile weiter gekommen.

    Startsequenz und Racketsteuerung über Potentiometer läuft. Der Tongenerator im Test wird durch die Potentiometer gesteuert, die Racketstellung liefert in dieser Testversion die Information für die aktuelle Generatoreinstellung. Die Grundfrequenz ist 2 kHz => in der 4kHz-ISR für den LED-Refresh wird der Soundausgang getoggelt. Dazu die Teiler 1, 2, 3, 4, 5, 6, 7, 8 und 9 für div. Töne. Der 1-kHz-Ton hat bei meinem Beeper die größte Lautstärke. Ein 4,7 µF Elko macht den Ton des magnetischen Beepers etwas weicher.

    Eine höhere Tonfrequenz ist aktuell nicht ratsam/möglich, da der Beeperanschluss wegen der Kompatibilität mit dem Originalprogramm auf PD1 bleiben muss und die üblichen timersteuerbaren Ausgänge durch andere Belegungen nicht nutzbar sind.



    Wenn es RICHTIG weitergegangen ist und die ersten Spielversuche laufen, gibts auf Wunsch auch Code.
    Ciao sagt der JoeamBerg

  3. #13
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.687
    Die gute PingPong-Platine dient mir als schickes LED-Display. Numerische Anzeige, auch ein paar Buchstaben und Sonderzeichen, mit mega168 oder größer (ich arbeite daran) ginge auch das komplette Alphabet.

    Ciao sagt der JoeamBerg

  4. #14
    Erfahrener Benutzer Roboter Genie Avatar von Crazy Harry
    Registriert seit
    15.01.2006
    Ort
    Raum Augsburg - Ulm
    Beiträge
    1.308
    Bei dem Teil (hab auch noch so eine Platine rumliegen) fällt mir was anderes ein, das ich mal mit einer Propellerclock gemacht hab: ich habe ein grafisches LCD definiert und die Hardware-Ausgabe selber programmiert (das geht mit meinem Compiler). Der im RAM des Controllers liegende Videospeicher wurde aber über die Schieberegister der PC ausgegeben. Funktioniert hervorragend. Sinn und Zweck dieser Aktion: die PC verhält sich wie ein GLCD und ich kann alle Grafikfunktionen des Compilers nutzen.
    Auch bei der PingPong-Platine könnte man ein GLCD mit 16x16 (muß ein Vielfaches von 8 sein) Pixel definieren, HW-Ausgabe Proggen und auch dann die Grafikbefehle des Compilers nutzen.
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken PD1_3.jpg  
    Ich programmiere mit AVRCo

  5. #15
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.687

    UART parallel zu gleicher Platine stört

    Zitat Zitat von Crazy Harry Beitrag anzeigen
    ... mit einer Propellerclock ... Der im RAM des Controllers liegende Videospeicher ...
    Der mega8 hat sowieso zu wenig RAM - da ist daran wohl kaum zu denken - aber, gute Idee, danke.

    Zum Titel:
    Der weiter oben beschriebene Umbau läuft - zwei kalte Lötstellen und eine durchtrennte Leitung (wieso das? - aber egal) wurden gelötet - und nun läufts.
    Der Aufbau - komplett als Displayduo vorn und hinten beim Archie: zwei gleiche Platinen - aber einmal mega8 und einmal ein (alter) mega168 - laufen parallel an EINER UART-Leitung vom Master, 56kBd sichert trotzdem eine ausreichend, nein eine wirklich gute, praktisch fehlerfreie Funktion: beide Displays zeigen die gleichen Signale. Es sind meist drei Ziffern, aber auch ein paar Symbole wie "Pfeil-auf", "Pfeil-ab", "0/1" etc.

    RAM war das Thema beim Mega8 - daher war der Umbau auf den (schon viele Monate rumliegenden) mega168. Ich hätte vorher das Datenblatt lesen sollen: der hat auch nicht mehr RAM als der mega8. Also nen 328p besorgt. Auf einer heilen originalen Platine mit nem mega8 den Controller mit hauchdünnem Alu abdecken, Fenster in Controllergröße, Heißluft dran und Controller abheben. FAST problemlos! Der neue 328p war schnell draufgelötet und lief auf Anhieb. Aber er funktionierte nicht im oben genannten Verbund. Also doch ´n Fehler. Lupe. Löten. Testen. Mist. Lupe, löten, testen - Mist. Mehrmal. Dann mal einen Aufbau mit der umgebauten PingPong mit dem 328p alleine. Und es läuft sowas von gut. Stromaufnahme wie beim 8er - bei 5,01V rund 15-17 mA -- und das mit 120 LEDs !! Alle Befehle sind möglich, aber sie kommen eben vom Terminal über den Pro gra mmer. Platine wieder in den erwähnten Verbund eingebaut - und sie spinnt wie davor, zeigt ohne Aufforderung wilde Daten, selten etwas Sinnvolles, viele einzelne LEDs, das Programm macht nicht mal annähernd das was ich möchte. Bei all dem Chaos läuft die zweite Platine, egal ob m8 oder m168, problemlos.

    Frage1: Wieso läuft das mit mega8+mega8, auch mit mega8+mega168, aber eben nicht mit mega8(oder 168er)+mega328 ? ?

    Frage2: Was kann ich tun, damit das Signal so getrennt wird, dass die beiden Controller sich nicht mehr gegenseitig stören?

    Danke für die Hilfe.
    Geändert von oberallgeier (25.08.2014 um 23:50 Uhr) Grund: Autokorrektur-Smiley bei mega168Klammer entfernt.
    Ciao sagt der JoeamBerg

  6. #16
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Hossa oberallgeier,

    ich weiss, du wirst es geprüft haben.
    Aber wäre es möglich, dass der neue 328 mit der Verbindung über den Pro gra mmer eventuell mit einer anderen Baud-Rate betrieben wurde?
    Die Idee zur Frage ist, ob du evl. die Konfigurations-Bits vom neuen 328 nicht richtig gesetzt hast.
    Als da wären: Quarzbetrieb/Interner Takt und/oder dieses Clock/8-Konfig-Bit

    Ansonsten bin ich auch erst einmal überrascht wie du.

    cu Sternthaler
    Lieber Asuro programieren als arbeiten gehen.

  7. #17
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Die Widerstände sind so, das eigentlich immer nur eine LED pro Zeile gleichzeitig Leuchten sollte. Das passt auch zum langsamen Schieden des Schieberegisters. Der Bildaufbau erfolgt also Spalte für Spalte. Wegen der relativ schwachen Treiber der 4094 (wohl 74HC4094) wird es aber mit mehr als 1 LED Gleichzeitig schon schwer.

    Besser wäre es aber gewesen die Widerständen an die 4094 zu machen (halt 2 mehr) und dann Zeilenweise das Bild aufzubauen - die Treiber des AVRs sind meist etwas kräftiger als beim 4094. Dann wäre auch eine Ansteuerung per SPI Hardware besser.

    Der C Code wird ggf. noch etwas schneller wenn man wenn möglich lokale Variablen in der ISR nutzt.
    Es sollten auch etwa 120 Hz Widerhohlfrequenz ausreichen - die nötige Rechenzeit für die Darstellung reduziert sich damit auf etwa 1/3.

  8. #18
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.687
    ... du wirst es geprüft haben ... dass der neue 328 ... eventuell mit einer anderen Baud-Rate betrieben wurde ...
    Hallo Sternthaler, tut mir leid, dass ich die lange Beschreibung nicht noch länger gemacht habe. Ergänzung also: PingPong328 ALLEINE im laufbereiten Archie eingebaut und am Rx des Masters, mega1284/20MHz, angeschlossen funzt wie erwartet. Nachdem eine weitere PingPong, mega8- oder mega168-getrieben, an derselben Rx-Leitung angeschlossen wird, fängt die PingPong328 an zu spinnen; die mega8/-168 läuft korrekt. Eine PingPong8 und eine PingPong168 zusammen (PP328 im Körbchen) an derselben Rx-Leitung desselben (des vorigen) Masters angeschlossen laufen korrekt. Lief seit Monaten so - auch mit PP8/PP8.

    Die Widerstände ... nur eine LED pro Zeile gleichzeitig Leuchten sollte. Das passt auch zum langsamen Schieden des Schieberegisters ...
    Danke Besserwessi - Du siehst eben in Tiefen, die MIR garnicht klar sind. Ich vermute, dass Deine Darstellung beschreibt, wie das Problem bei den zwei Schieberegistern der PingPong liegen könnte - die den UART-Befehl ausbremsen. Nu ist es so, dass ein String von drei Bytes - plus Stringabschluss-Null - gesendet wird. Sendung und Empfang gehen hardwaremässig über jeweils einen Ringpuffer, der Puffer hat jeweils 128 Bytes (ist halt ne Art Standard bei mir). Im Empfangsteil wird so lange gewartet, bis der String komplett gesendet wurde - danach wird erst reagiert. Daher bin ich nicht sicher, ob ich hier wirklich weiter prüfen sollte. Zusätzlich noch die Erscheinung, dass ich in einer suspekten Konfiguration garnix senden muss - nach dem Start-Intro fällt die PingPong328 ohne jedes weitere Zutun innerhalb von ein, zwei Sekunden ins Koma . . .

    Codeausschnitt:
    Code:
        if (zeiger == 0)
        {                                           //
          if (zeichen_aus_fifo == KOMMANDO_KPLUS)   // Fahre Anwendungsprogramme
            telegrammlaenge = KOMMANDO_KPLUS_LEN;   //   mit und ohne Parameter
    
    //     if (zeichen_aus_fifo == KOMMANDO_DATS)   // Daten 
    //       telegrammlaenge = KOMMANDO_DATS_LEN;   //   anzeigen
        }                           // Ende if (zeiger == 0)
    
        // ==================================================
        /* Wenn keine Telegrammlaenge bekannt ist, dann ist auch kein Kommando
           bekannt, dann muss auch nichts weiter gemacht werden, als auf das 
           naechste Zeichen zu warten bzw. es abzuholen und dann wieder auf 
           einen Kommando-Buchstaben zu testen                      */
        if (telegrammlaenge == 0)
          continue;
    
        // ==================================================
        /* Wenn ein erkanntes Kommando seine Telegrammlaenge angegeben hat, dann
           muessen wir nun die EINZELN aus dem FIFO abgeholten Zeichen in den BUFFER
           schreiben. Da ja schon der erkannte Kommando-Buchstabe in der Variablen 
           "zeichen_aus_fifo" steht, und "zeiger" noch nicht veraendert wurde, wird 
           auch zum Glueck der Kommando-Buchstabe direkt als erstes Zeichen in
           unserem BUFFER landen.
           Und alle weiteren Zeichen werden dank "zeiger++" dahinter geschrieben. */
        mein_rx_buff [zeiger] = zeichen_aus_fifo;
        zeiger++;
    Die drei Platinen sind so ebenso wie die Controller so gleich, wie´s nur geht. Fuses stets dieselben, der Code von 328 und 168 ist identisch - die PP8 hat ein einziges Flag anders (Unterschied der Darstellung des Pfeils für Links- und Rechtsfahrt vorn und hinten - bei gleichem Kommandostring). UND natürlich sind im mega8 die Registernamen anders als bei den m168 und m328. Aber gerade die beiden PingPongs mit den ersetzten mega8 - einmal m328 und einmal m168 - haben identischen Code einschließlich ALLEM - nur das Target ist entsprechend markiert.

    Ich bin also immer noch ohne jeden Peil.
    Geändert von oberallgeier (25.08.2014 um 23:55 Uhr) Grund: Codeausschnitt nachgetragen
    Ciao sagt der JoeamBerg

  9. #19
    Neuer Benutzer Öfters hier
    Registriert seit
    29.08.2014
    Ort
    Schweiz
    Beiträge
    10
    Zitat Zitat von Besserwessi Beitrag anzeigen
    Die Widerstände sind so, das eigentlich immer nur eine LED pro Zeile gleichzeitig Leuchten sollte. Das passt auch zum langsamen Schieden des Schieberegisters. Der Bildaufbau erfolgt also Spalte für Spalte. Wegen der relativ schwachen Treiber der 4094 (wohl 74HC4094) wird es aber mit mehr als 1 LED Gleichzeitig schon schwer.

    Besser wäre es aber gewesen die Widerständen an die 4094 zu machen (halt 2 mehr) und dann Zeilenweise das Bild aufzubauen - die Treiber des AVRs sind meist etwas kräftiger als beim 4094. Dann wäre auch eine Ansteuerung per SPI Hardware besser.

    Der C Code wird ggf. noch etwas schneller wenn man wenn möglich lokale Variablen in der ISR nutzt.
    Es sollten auch etwa 120 Hz Widerhohlfrequenz ausreichen - die nötige Rechenzeit für die Darstellung reduziert sich damit auf etwa 1/3.
    Generell ist die Schaltung ein bisschen Fragwürdig.

    Wenn das Teil wirklich dafür vorgesehen ist, wie eine normale Matrix betrieben zu werden gibt es einiges zu Bemängeln.
    Schaltet man Beispielsweise Spalte für Spalte, so dass die LED eigentlich immer nur kurz an und ab geht, das allerdings so schnell das ein Bild für das Menschliche Auge ersichtlich wird, so weiss ich nicht wie gut das dem ATMega tut. Denn Pulsbetrieb bedeutet auch Pulsströme und bei 12 Spalten nimmt der Strom dann auch erheblich zu.

    Am schlausten wäre es die ganze high-side geschichte nicht direkt an den uC zu hängen sondern das ganze zu überarbeiten und da eine Treiberstufe dazwischen zu schalten. Einfache Transistoren würden schon reichen und man könnte auch Problemlos mehrere LED's gleichzeitig leuchten lassen.

  10. #20
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.687
    Generell ist die Schaltung ein bisschen Fragwürdig ... gibt es einiges zu Bemängeln ...
    Mag sein, mir ist auch klar, dass die beiden 4094 keine wirklichen Treiber sondern so ziemlich das schwächste dafür mögliche IC sind. Trotzdem ist diese Platine ein ziemlicher Renner gewesen und ist es immer noch - und wird von vielen als Anzeige benutzt. Das Ganze neu aufzubauen ist auch keinesfalls mein Ziel (das hätte ich anders gemacht) - ich habe eben aus meinem Fundus eine passende Platine genommen um eine Anzeige für Distanzen über 1m zu bekommen. Die - mögliche, bisher nicht erkennbare - Überlastung ist ja auch nicht das Thema meiner letzten Postings. Das aktuelle Thema ist die Funktion der seriellen Schnittstelle "mal gehts, mal nicht" - und da bin ich ziemlich sicher, dass der Grund für diese Erscheinung nicht in/an den Schieberegistern liegt.

    Trotzdem danke für Deinen Kommentar, Du hast damit sicher Recht.
    Ciao sagt der JoeamBerg

Seite 2 von 3 ErsteErste 123 LetzteLetzte

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Solar Speicher und Akkus Tests