Hey, ich muss 4 Schiftregister über ISP ansprechen. Kann ich dann mein Clock und Datensignal mit einem "SMD 74HC4052" von Reich*** entsprechend schalten? Übertragungsrate 8MHz, nicht kontinuierlich. Mfg Matyro
Dominik B. schrieb: > Hey, ich muss 4 Schiftregister über ISP ansprechen. Kann ich dann mein > Clock und Datensignal mit einem "SMD 74HC4052" von Reich*** entsprechend > schalten? Ja. Aber warum? Schieberegister kann man auch kaskadieren. Da brauchst du keine weiteren Bauteile. mfg.
Leider kann ich die in dem Fall nicht kaskadieren, weil sonst das Befüllen zu lange dauert. Ich muss ~500Byte in jedes Register (ok es sind eigentlich schon 3 Kaskadierte) seehr schnell übertragen. Daher hab ich mich entschieden diese zu trennen und nacheinander Abzuarbeiten, da so die "Tot-Zeit" von den einzelnen Register im Schnitt kürzer ist.
Warum eigentlich analog Multiplexer? Brauchst Du den "Rückwärtsgang"? Vielleicht kannst Du ja mal Dein Problem zeichnerisch ausarbeiten. Meine Glaskugel sagt: Es ist Nebel angesagt.
@ Dominik B. (matyro) >Hey, ich muss 4 Schiftregister über ISP ansprechen. Eher SPI, gleiche Buchstaben, andere Reihenfolge. > Kann ich dann mein >Clock und Datensignal mit einem "SMD 74HC4052" von Reich*** entsprechend >schalten? Warum? >Leider kann ich die in dem Fall nicht kaskadieren, weil sonst das >Befüllen zu lange dauert. >Ich muss ~500Byte in jedes Register (ok es sind eigentlich schon 3 >Kaskadierte) seehr schnell übertragen. Wie schnell? Siehe Netiquette. >Daher hab ich mich entschieden diese zu trennen und nacheinander >Abzuarbeiten, da so die "Tot-Zeit" von den einzelnen Register im Schnitt >kürzer ist. Wenn es sehr schnell gehen muss, nimmt man parallele Latches ala 74HC273.
Dominik B. schrieb: > Daher hab ich mich entschieden diese zu trennen und nacheinander > Abzuarbeiten, da so die "Tot-Zeit" von den einzelnen Register im Schnitt > kürzer ist. Was für Schieberegister hast du denn? mfg.
Hi >Leider kann ich die in dem Fall nicht kaskadieren, weil sonst das >Befüllen zu lange dauert. Warum sollte das 'Befüllen' über Multiplexer schneller gehen? Du hast dann auch nur ein SPI. Wenn das wirklich der Flaschenhals ist, dann nimm einen neueren ATMega mit mehreren UART. Z.B ATMega164/324/644/1284 . Die UARTs können auch SPI und sind wegen der gepufferten UDR noch schneller als das normale SPI. MfG Spess
Ok, erstmal sry ich meinte SPI, den Buchstabendreher habe ich öfter -.- Bei den Registern handelt es sich unteranderem um TLC5940 (PWM-Controller), diese sollten in Größenordnung µs mit Daten gefüllt werden. Insgesammt sind alle Register nur seriel beschreibbar und ich nutze die Bezeichnung "Schieberegister" hier als einfache Umschreibung, weil ich an dieser Stelle auch nichts änder kann (BlackBox). Einen anderen µC kann ich nicht nehmen, weil ich USB Support benötige -> AT90USB, aber ich hatte vor den UART-Port im SPI modus zu betreiben, schon alleine wegen der Pufferung. Prinzipiell ist das Problem nur das ich ein Packet Daten möglichst schnell übertragen möchte und dann "ewig" (~50ms) Zeit habe bis zum nächsten Packet. Während ich das Packet übertrage kann in meinem Fall das Schieberegister nicht weiterarbeiten. Wenn ich nun alle kaskadiere, müsste ich alle Packete zusammenfassen und ein langes schicken, was mir einen langen timeout der register erzeugt und damit weitere Probleme. Die Rückwärtsrichtung brauche ich bei dem Multiplexer nicht, ich hab nur einen gesucht der auch bei angesprochenen 8MHz Dateneingang noch funktioniert und eine relativ geringe Latenz (passt das Wort hier) hat. Wenn es eine bessere Lösung des Problems gibt wäre ich glücklich, allerdings ist mir keine bessere Alternative eingefallen. Hoffe hier hab ich mein Problem besser dargestellt als in den obrigen Posts
Ich glaube du solltest dir mal anschauen wie ein TLC5940 funkioniert. Beeilen muss man sich da, bei richtiger Programmierung, an keiner Stelle. Wobei das hier: Spess53 schrieb: > Warum sollte das 'Befüllen' über Multiplexer schneller gehen? Du hast > dann auch nur ein SPI. Dein ganzes Vorhaben eh sinnlos macht.
Ich bin mir bewusst wie der IC-Funktioniert Ich kann aber hier nicht einfach die Daten reinschieben und dann übernehmen. Deswegen habe ich auch geschrieben das in meinem Fall während des Vorgangs NICHT weitgearbeitet werden kann.
Dominik B. schrieb: > Ich bin mir bewusst wie der IC-Funktioniert > > Ich kann aber hier nicht einfach die Daten reinschieben und dann > übernehmen. > Deswegen habe ich auch geschrieben das in meinem Fall während des > Vorgangs NICHT weitgearbeitet werden kann. Dann erklär doch mal genau was wieso nicht funktioniert, deine multiplexer Lösung ist eher suboptimal. Vielleicht fällt jemandem hier ein bessere Idee ein? Dafür musst du aber ein paar mehr Infos rausrücken ;)
@Dominik B. (matyro) >diese sollten in Größenordnung µs mit Daten gefüllt werden. Warum? >Insgesammt sind alle Register nur seriel beschreibbar und ich nutze die >Bezeichnung "Schieberegister" hier als einfache Umschreibung, weil ich >an dieser Stelle auch nichts änder kann (BlackBox). ??? >Prinzipiell ist das Problem nur das ich ein Packet Daten möglichst >schnell übertragen möchte und dann "ewig" (~50ms) Zeit habe bis zum >nächsten Packet. Warum? Wieviele Daten? >Während ich das Packet übertrage kann in meinem Fall das Schieberegister >nicht weiterarbeiten. Warum? > Wenn ich nun alle kaskadiere, müsste ich alle >Packete zusammenfassen und ein langes schicken, was mir einen langen >timeout der register erzeugt und damit weitere Probleme. >Wenn es eine bessere Lösung des Problems gibt wäre ich glücklich, >allerdings ist mir keine bessere Alternative eingefallen. Weil du einen Tunnelblick (entwickelt) hast. Beschreibe dein Problem umfassend, nicht deine Lösung. Dann kann man dir helfen. Siehe Netiquette.
Auch wenn man die "Schieberegister" nicht hinter einander schalten will, braucht man eigentlich keinen Multiplexer. Man könnte auch die Daten parallel in alle 4 Chips reinschieben, und dann nur beim gewünschten Chip die Daten auch wirklich übernehmen (per XLAT). Da könnte man dann so etwas wie einen Decoder zur Auswahl eines der 4 Chips gebrauchen. Das spart aber auch nur einen IO PIN gegenüber direkt 4 Signalen.
Ok, ich versuche es einmal möglichst neutral zu erklären was ich benötige: Ich habe 12 TLC5940 die >20 mal pro Sekunde neue Daten bekommen sollen. Hier ist das Problem das ich PWM und DotCorrection ändern muss. Die TLC dürfen nicht weiterlaufen solange nur eins von beiden geändert wurde. -> Daher ich habe eine tot-Zeit zwischen PWM-Daten übernehmen und DotCorrection-Daten übernehmen. PWM-Packet: 192 Bit DC -Packet: 96 Bit tot-Zeit : <50µs (wäre am besten) Desweiteren hängt ein FPGA, den ich nicht ändern kann (stammt nicht von mir), daran. Diesen beschreib ich identisch wie die TLC5940 mit seriellen Daten. Dies stellt aber soweit kein Problem dar, da das Beschreiben hier nicht wirklich Zeitkritisch ist. Die Idee die Daten in alle Register zu schreiben und nur bei dem benötigten mit einem XLAT-Puls zu übernehmen hatte ich auch, allerdings dachte ich das die Lebensdauer der Schieberegister darunter leidet. Ich hab auch nirgends gefunden wieviele Schreibzyklen dieses überlebt. Das ganze soll über einen im SPI modus laufenden UART-Port mit 8MHz laufen. µC ist ein AT90USB. Hoffe diesmal ist es besser
Dominik B. schrieb: ... > dachte ich das die Lebensdauer der Schieberegister darunter leidet. Ich > hab auch nirgends gefunden wieviele Schreibzyklen dieses überlebt. HA-HA-HA-HA-HA Das ist so schlimm, da kann man sich nur noch in Sarkasmus flüchten. XL
Dominik B. schrieb: > Hier ist das Problem das ich PWM und DotCorrection ändern muss. Die PWM-Werte kann man beliebig langsam kaskadiert reinschreiben, sie werden erst mit der XLAT-Flanke für alle ICs gleichzeitig übernommen. Das könnte auch der UART-TX Interrupt im Hintergrund machen. Das gleichzeitige ständige Schreiben der DotCorrection ist nicht vorgesehen. Vermutlich hat der IC-Hersteller nicht damit gerechnet, daß Deine speziellen LEDs ständig ihre Kennlinie ändern. In der Regel behalten LEDs ihre Kennlinie über die gesamte Lebensdauer bzw. ändern sie nur sehr langsam. Deshalb ist auch der EEPROM vorgesehen, daß man die Kennline einmalig ermittelt und einprogrammiert.
Axel Schwenke schrieb: > > *HA-HA-HA-HA-HA* > > Das ist so schlimm, da kann man sich nur noch in Sarkasmus flüchten. Gehen Schieberegister nicht nach einigen Schreibzyklen kaputt? Mit der Methode würde ich mehr als 6*10^9 Bits am Tag in jedes Register schreiben. Das finde ich etwas viel... Peter Dannegger schrieb: > Das gleichzeitige ständige Schreiben der DotCorrection ist nicht > vorgesehen. Vermutlich hat der IC-Hersteller nicht damit gerechnet, daß > Deine speziellen LEDs ständig ihre Kennlinie ändern. > In der Regel behalten LEDs ihre Kennlinie über die gesamte Lebensdauer > bzw. ändern sie nur sehr langsam. Deshalb ist auch der EEPROM > vorgesehen, daß man die Kennline einmalig ermittelt und einprogrammiert. Stimmt, leider ist es dass nicht, aber wenn ich LED's multiplexe (Stichwort: Matrix) und bei "Missbrauch" der IC's für andere Zwecke bleibt einem leider nichts anderes übrig. Wobei es aktuell eher um die Matrix geht.
Dominik B. schrieb: > Gehen Schieberegister nicht nach einigen Schreibzyklen kaputt? > Mit der Methode würde ich mehr als 6*10^9 Bits am Tag in jedes Register > schreiben. Das finde ich etwas viel... Nein. Nach maximal 100000 Schiebeoperationen muss man den Zahnriemen wechseln. Wenn man sich daran hält, halten sie ewig. mfg.
Wegen der Lebensdauer muss man sich bei den Schieberegistern keine Sorgen machen. Bei 12 ICs parallel wäre höchstens der minimal erhöhte Stromverbrauch und die etwas größeren Störungen auf der Versorgung. Der AVR sollte auch 12 Leitungen treiben können - bzw. man hängt sowieso einige davon in Reihe. Das einzige wieso es sich lohnen könnte die SPI Schnittstelle wirklich zu trennen, wäre wenn das IC bei übernehmen der Daten ins EEPROM keinen SPI Takt gebrauchen kann, und man in der Zeit bei anderen ICs Daten rein schieben will.
@Dominik B. (matyro) >Ich habe 12 TLC5940 die >20 mal pro Sekunde neue Daten bekommen sollen. Kein Thema. 12x 192 Bit = 2304 die man mit 8 MHz SPI-Takt innerhalb von 288µs geschrieben werden können. >Hier ist das Problem das ich PWM und DotCorrection ändern muss. Warum glaubst du das? Ausserdem kann man die Dot Correction vorher per CPU in die PWM-Werte reinrechnen, wenn es denn WIRKLICH nötig ist. >dachte ich das die Lebensdauer der Schieberegister darunter leidet. Bist du ein Troll? > Ich >hab auch nirgends gefunden wieviele Schreibzyklen dieses überlebt. Die SCHIEBEREGISER halten ewig! Die sind verschleißfrei. Aber die EEPROMs haben eine endlich Anzahl Schreibzyklen, je nach Typ 10.000-1 Million.
Falk Brunner schrieb: > Die SCHIEBEREGISER halten ewig! Die sind verschleißfrei. Aber die > EEPROMs haben eine endlich Anzahl Schreibzyklen, je nach Typ 10.000-1 > Million. Um das nochmal zu verdeutlichen: Die dot correction Werte liegen im EEPROM, das ist nach zu vielen Schreibzyklen irgendwann kaputt. Man benutzt aber ein EEPROM weil man mit hilfe der dot correction Streuungen in der Helligkeit der LEDs ausgeleichen kann die diese aufgrund ihres Herstellungsprozesses haben. Das macht man üblicher weise 1 mal.
Achso, und natürlich weil die Werte im EEPROM auch erhalten bleiben wenn man die Spannung abschaltet :)
-Die DC muss nicht zwingend im EEPROM des TLC5940 geschrieben werden, es steht auch ein Register zu verfügung. Den Speicherort (Register/EEPROM) kann man über DCPRG einstellen. -Das reinrechnen würde gehen, aber unnötig CPU "last" verursachen. Die Werte werden als Konstanten im EEPROM des µC liegen, dann für jede Spalte der "Matrix" gelesen und zum TLC5940 übertragen. -Das shiftregister quasi keinen Verschleis haben wusste ich leider vorher nicht, sonst wär das Problem garnicht erst entstanden ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.