Hallo zusammen, ich versuche mich gerade am TLC5940 + Mega328P. Zur Steuerung des Chips sende ich zuerst 12 Byte an Daten, dann soll ein Puls auf SCK folgen und dann noch einmal 24Byte an Daten. Das ganze funktioniert mit dem HW-SPI, jedoch macht das Toggeln der SCK-Leitung Probleme. Es scheint nach dem SPI-Setup kein Toggeln des SCK-Pins mehr möglich sein. Im Datenblatte finde ich leider nichts diesbezüglich (nur die DDR-Register werden verändert). Könnt ihr die SCK-Leitung nach dem Senden toggeln ohne, dass ihr das SPCR manipuliert?
Hi
>Im Datenblatte finde ich leider nichts diesbezüglich
Dann suche mal nach 'I/O-Ports -> Alternate Port Functions'.
MfG Spess
spess53 schrieb: > Hi > >>Im Datenblatte finde ich leider nichts diesbezüglich > > Dann suche mal nach 'I/O-Ports -> Alternate Port Functions'. > > MfG Spess Danke, aber sas hatte ich ja gefunde: Hier steht nur dass der DDR geändert wird. Zugriff auf den PIN sollte folglich doch trotzdem möglich sein (SPI ist Master, PIN ist Output) > SCK/PCINT5 – Port B, Bit 5 > SCK: Master Clock output, Slave Clock input pin for SPI channel. > When the SPI is enabled as a > Slave, this pin is configured as an input regardless of the setting > of DDB5. When the SPI is enabled as a Master, the data direction of > this pin is controlled by DDB5. When the pin is forced > by the SPI to be an input, the pull-up can still be controlled by > the PORTB5 bit.
Hallo Spiffman Spess hat ja schon auf das Datenblatt des m328p verwiesen. Siehe Seite 83 Danach würde ich die serielle Ausgabe komplett per Software machen. Dazu schreibt man sich ein paar Funktion oder Macros, wie: toggle_spi_clk(), reset_spi_bit() und set_spi_bit(). Auf der nächsten Abstraktionsebene dann eine Funktion zum senden eines Bytes send_byte_to_spi(uint8) und eine zum senden eines Arrays of Byte send_array_to_spi(uint8 *, size_t). Damit sollte das Protokoll des TLC5940 in einer weiteren Funktion sed_data_to_tlc5940(..) abzubilden sein.
:
Bearbeitet durch User
Uwe S. schrieb: > Hallo Spiffman > > Spess hat ja schon auf das Datenblatt des m328p verwiesen. > Siehe Seite 83 > > Danach würde ich die serielle Ausgabe komplett per Software machen. > > Dazu schreibt man sich ein paar Funktion oder Macros, wie: > toggle_spi_clk(), reset_spi_bit() und set_spi_bit(). > > Auf der nächsten Abstraktionsebene dann eine Funktion zum senden eines > Bytes > send_byte_to_spi(uint8) und eine zum senden eines Arrays of Byte > send_array_to_spi(uint8 *, size_t). > > Damit sollte das Protokoll des TLC5940 in einer weiteren Funktion > sed_data_to_tlc5940(..) abzubilden sein. Hallo Uwe, danke für deine Antwort und Vorschläge. Ich wollte eigentlich ohne Bit-Banging auskommen. Damit sind die 193Bit natürlich problemlos möglich. Eigentlich wollte ich nur wissen ob und wie ich SCK toggeln kann. Geht dies auch ohne das SPI vorher zu deaktivieren?
Hallo Spiffman, zum einen sehe ich im Datenblatt die 193 Bit nicht, aber benutzen keinen TLC5940 und könnte dieses Bit auch überlesen haben. Aber ich gehe, davon aus, dass die Ports exklusiv von der SPI Hardwareeinheit belegt sind.
:
Bearbeitet durch User
Hi >Eigentlich wollte ich nur wissen ob und wie ich SCK toggeln kann. >Geht dies auch ohne das SPI vorher zu deaktivieren? Lt. Table 14-4. Overriding Signals for Alternate Functions in PB7...PB4 ist bei SPE • MSTR der Pin mit dem SPI-Clock belegt. MfG Spess
@ Spiffman G. (spiffman) >ich versuche mich gerade am TLC5940 + Mega328P. Zur Steuerung des Chips >sende ich zuerst 12 Byte an Daten, dann soll ein Puls auf SCK folgen und >dann noch einmal 24Byte an Daten. Nein. Man braucht nur die 12x8 Takte, welche das SPI selber generiert. Der Zusatztakt ist nicht nötig bzw. falsch. Ich hab ein Board mit dem IC in Betrieb, und es läuft genau so wie es soll. >Könnt ihr die SCK-Leitung nach dem Senden toggeln ohne, dass ihr das >SPCR manipuliert? Nein.
Uwe S. schrieb: > Hallo Spiffman, > > zum einen sehe ich im Datenblatt die 193 Bit nicht, aber benutzen keinen > TLC5940 und könnte dieses Bit auch überlesen haben. Mir gehts wie dir. Ich sehe im Datenblatt nicht, wieso man nach den ersten 12 Bytes (die wohl die Grayscale Daten darstellen sollen) einen Puls auf SCK benötigen würde. Das wäre auch schön dumm von TI, einen Chip zu bauen, bei dem man derartige Klimmzüge machen müsste und Taktanzahlen benötigen würde, die kein Vielfaches von 8 sind. Es ist zwar schon einen Weile her und er war kein 5940 sondern ein 5955, aber das Prinzip der Dateneintaktung ist da wie dort ja dasselbe. Ich denke auch, dass Spiffman da irgendwas im Datenblatt fehlinterpretiert hat. Das 'Problem' das er gerade zu lösen versucht, existiert in Wirklichkeit gar nicht. Womit die Beantwortung der eingangs gestellten Frage zwar einen gewissen interessanten Wert hat, aber im Grunde uninteressant ist, weil sich dieses Problem in dieser Aufgabenstellung überhaupt nicht stellt.
:
Bearbeitet durch User
Danke für eure Antworten! Uwe S. schrieb: > Hallo Spiffman, > > zum einen sehe ich im Datenblatt die 193 Bit nicht, aber benutzen keinen > TLC5940 und könnte dieses Bit auch überlesen haben. > > Aber ich gehe, davon aus, dass die Ports exklusiv von der SPI > Hardwareeinheit belegt sind. Ja, das Bit ist sehr versteckt und wir nur kurz erwähnt. Es wird zur Übernahme der Daten beim ersten GS-Zyklus benötigt und um die LOD ins SOUT-Register zu übernehmen. spess53 schrieb: > Hi > >>Eigentlich wollte ich nur wissen ob und wie ich SCK toggeln kann. >>Geht dies auch ohne das SPI vorher zu deaktivieren? > > Lt. Table 14-4. Overriding Signals for Alternate Functions in PB7...PB4 > > ist bei SPE • MSTR der Pin mit dem SPI-Clock belegt. > > MfG Spess Hi Spess, danke für den Hinweis! Ich kannte PVOE und PVOV noch nicht! Wieder was gelernt! Super!
Spiffman G. schrieb: > Ja, das Bit ist sehr versteckt und wir nur kurz erwähnt. Es wird zur > Übernahme der Daten beim ersten GS-Zyklus benötigt und um die LOD ins > SOUT-Register zu übernehmen. Meinst du das hier?
1 | LOD: LED OPEN DETECTION |
2 | |
3 | The TLC5940 has an LED-open detector that detects broken or disconnected |
4 | LEDs. The LED open detector pulls the XERR pin to GND when an open LED is |
5 | detected. XERR and the corresponding error bit in the Status Information |
6 | Data is only active under the following open-LED conditions. |
7 | 1. OUTn is on and the time tpd2 (1 ms typical) has passed. |
8 | 2. The voltage of OUTn is < 0.3V (typical) |
9 | The LOD status of each output can be also read out from the SOUT pin. |
10 | See STATUS INFORMATION OUTPUT section for details. The LOD error bits |
11 | are latched into the Status Information Data when XLAT returns to a |
12 | low after a high. Therefore, the XLAT pin must be pulsed high then |
13 | low while XERR is active in order to latch the LOD error into the |
14 | Status Information Data for subsequent reading via the serial shift |
15 | register. |
Ich seh immer noch nicht, wozu man da jetzt einen Puls auf SCK benötigen würde.
Karl Heinz schrieb: > Spiffman G. schrieb: > >> Ja, das Bit ist sehr versteckt und wir nur kurz erwähnt. Es wird zur >> Übernahme der Daten beim ersten GS-Zyklus benötigt und um die LOD ins >> SOUT-Register zu übernehmen. > > Meinst du das hier?LOD: LED OPEN DETECTION > > > Ich seh immer noch nicht, wozu man da jetzt einen Puls auf SCK benötigen > würde. Es gibt zwei Stellen:
1 | The first GS data input cycle after dot correction requires an |
2 | additional SCLK pulse after the XLAT signal to complete the grayscale |
3 | update cycle. All GS data in the input shift register is replaced with |
4 | status information data (SID) after updated the grayscale register. |
Das ist Unproblematisch, man sendet einfach nach dem XLAT noch ein Byte Dummy-Daten.
1 | SOUT outputs the MSB of the SID at the same time the |
2 | SID are stored in the SID register, as shown Figure 20 . |
3 | The next SCLK pulse, which will be the clock for receiving |
4 | the SMB of the next grayscale data, transmits MSB-1 of SID |
Hier ist es doof, da wir einen SCK-Puls benötigen um die SID-Daten zu schieben, so dass sie im MISO richtig angekommen. Man sieht es in Figure 20 bei SCK. Hat man diesen Puls nicht, kommen die Daten alle um ein Bit verschoben an. Wäre auch kein Problem, man kann ja den Buffer ein Byte größer machen. Aber mir ist noch kein effizienter Weg zum Bit-Shiften von so großen Daten eingefallen.
Falk Brunner schrieb: > Nein. Man braucht nur die 12x8 Takte, welche das SPI selber generiert. > Der Zusatztakt ist nicht nötig bzw. falsch. Ich hab ein Board mit dem IC > in Betrieb, und es läuft genau so wie es soll. Hat das überhaupt einer von euch gelesen?
Spiffman G. schrieb: > Hier ist es doof, da wir einen SCK-Puls benötigen um die SID-Daten zu > schieben, so dass sie im MISO richtig angekommen. Man sieht es in Figure > 20 bei SCK. Tatsächlich. Dann muss ich wohl eingestehen falsch gelegen zu haben. Ich muss allerdings auch sagen, dass ich noch nie Status-Information vom Treiber zurück gelesen habe.
San Lue schrieb: > Falk Brunner schrieb: >> Nein. Man braucht nur die 12x8 Takte, welche das SPI selber generiert. >> Der Zusatztakt ist nicht nötig bzw. falsch. Ich hab ein Board mit dem IC >> in Betrieb, und es läuft genau so wie es soll. > > Hat das überhaupt einer von euch gelesen? Ich denke das ist hinfällig. Der entscheidende Punkt ist eine fehlende Information im Eröffnungsposting. Nämlich das es um das Zurücklesen der Status-Information geht. Benötigt man das nicht, dann ist der zusätzliche Takt uninteressant.
Ja genau. Mir ging es nur darum, mein Verständnis des SPI zu erweitern. Eigentlich ist die Frage ja Slave-Unabhängig. -> Wieder was gelernt.
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.