(TLC5947 Board erstellen.) FRAGEN zu TWI

nighty2k · 16. Januar 2010

Also ich finde die MicroMatch wirklich günstig
Wenn man davon ausgeht das die Original von TycoElectronics sind und dort ein vielfaches kosten.

Ich z.B. bin gerade auf der Suche nach 175 Paaren(Board und Kabel) und würde mit den MicroMatch auf knapp 40€ kommen.

Problem ist halt wie es Pesi auf den Punkt gebracht hat, die Pfosten/Wannen Verbinder gibt es erst ab 6 Kontakten, und die mit 6 sind die teuersten.
Alleine die Pfostenbuchse kosten das Stück um die 30 Cent

Also mit den versetzten Pins habe ich kein Problem.

Hättest denn ne gute Alternative zu bieten, sollte halt im gleichen preislichen Rahmen liegen.

Greetz

nighty2k · 21. Januar 2010

So bin gerade dabei mein Board zu Layouten, habe mich jetzt dazu entschlossen bei den IDC Steckern zu bleiben.
Da beim langweiligen Layouten viel Zeit zum Nachdenken bleibt, ist mir gerade eine Frage durch den Kopf geschossen,
eventuell könnte mir das mal Jemand erklären.

Der TLC ist ja im Prinzip ein SPI Shiftregister, mit ein paar mehr Funktionen.
Alle Pins CLCK, XLAT, BLANK liegen gleichzeitig an allen TLCs an.
Das Datensignal geht ja zum ersten TLC Sin - Sout -> 2. TLC Sin usw.......

Mit jeder Clock Flanke wird ja ein Bit übernommen, sind 24*12Bit eingegangen, ist das Register voll und die Daten gehen über SOut raus zum nächsten.

So und nun zu meiner Frage, da Clock ja überall anliegt werden ja am dem ersten Bit auch alle getoggelt und somit sind doch alle nach 24*12Bit voll.

Wie soll das funktionieren, bzw. wie funktioniert das?

Ich bin verwirrt.

Greetz

Jack1981 · 21. Januar 2010

Ich habe jetzt nicht alles gelesen, aber hört sich nach Daisy Chain an, dann sind die Daten die am Angang im ersten standen im zweiten usw.

kurzes Beispiel:
TLC1 --> TLC2 --> TLC3 --> ...
ABC --> DEF --> GHI --> ... (das ist irgendein Registerinhalt)

wenn Du jetzt den ersten neu beschreibst schiebst Du alles durch, also:
TLC1 --> TLC2 --> TLC3 --> ...
XYZ --> ABC --> DEF --> ...

Also Du hast schon recht, die anderen TLC's sind auch voll, aber halt mit den Daten die zuvor in dem jeweiligen vorgänger waren.

nighty2k · 21. Januar 2010

Das würde heisen das erste Bit das ich rausschiebe, landet dann im letzten TLC
Das letzte rausgeschobene Bit landet in dem ersten TLC also der direkt am Atmega.

Hätte ich eigentlich auch selber drauf kommen können xD, naja ist Spät

In dem Sinne Danke Grüße und GN8

Pesi · 21. Januar 2010

Ja, genau, wird einfach durchgeschoben - da das etwas verwirrend ist, und dann meist auch noch die LEDs durcheinander an den TLCs hängen (wie's grad' vom Layout her passt), habe ich mir ne Routine zum rausschieben gemacht, die erst in ner Tabelle nachschaut, welches Byte an der Reihe ist...

man kann dann also die Bytes "logisch" im Speicher ablegen (z.B. bei ner Matrix immer R-G-B von links oben nach rechts unten), die Routine kümmert sich darum, dass die Bits in der richtigen Reihenfolge im TLC landen:

Code

; ================================================================================================
; Datenausgabe aus RAM an TLC5947
;
; benutzte Register    : temp0-2, ZL, ZH, werden gesichert
; Statusregister       : wird *nicht* gesichert!
; reservierte Register : keine
; ------------------------------------------------------------------------------------------------


SUB_TLC_Out:


		push	temp2						; Register sichern
		push	temp1
		push	temp0
		push	ZL
		push	ZH


		clr		temp0						; temp0 = aktuell bearbeiteter Kanal 


TLC_Out_Loop:


		ldi		ZH, high(TLC_Patchtable*2)	; Position des Kanals im Ram aus Tabelle
		ldi		ZL, low(TLC_Patchtable*2)
		add		ZL, temp0
		adc		ZH, Null


		lpm		temp1, Z					; in temp1


		ldi		ZH, high(ARR_TLC_Out)		; Zeiger auf auszugebendes Byte legen
		ldi		ZL, low(ARR_TLC_Out)
		add		ZL, temp1					; 2x addieren, da Wörter im RAM
		adc		ZH, Null
		add		ZL, temp1
		adc		ZH, Null
		adiw	Z, 1						; High Byte ist eins weiter
		ld		temp1, Z					; auszugebendes HB in temp1 laden


		swap	temp1						; nur 4 LSB interessieren


		ldi		temp2, 4					; Ausgabe-Schleife für 4 höchste Bits


TLC_Out_H:


		cbi		TLC_Port, TLC_Clk			; Neg. Flanke Clock


		rol		temp1						; auszugebendes Bit in Carry schieben
		brcc	TLC_Out_H0					; carry 0?
		sbi		TLC_Port, TLC_Data			; Nein, Data auf 1
		rjmp	TLC_Out_H_Ende


TLC_Out_H0:


		cbi		TLC_Port, TLC_Data			; Carry Clear, Data auf 0

TLC_Out_H_Ende:


		nop									; kurz warten
		nop
		nop


		sbi		TLC_Port, TLC_Clk			; Pos. Flanke Clock = Bit übernehmen


		dec		temp2
		brne	TLC_Out_H					; Schleife weiter


		sbiw	Z, 1						; Low-Byte ist vorher
		ld		temp1, Z					; auszugebendes LB in temp1 laden


		ldi		temp2, 8					; Ausgabe-Schleife für 8 niedrigste Bits


TLC_Out_L:


		cbi		TLC_Port, TLC_Clk			; Neg. Flanke Clock


		rol		temp1						; auszugebendes Bit in Carry schieben
		brcc	TLC_Out_L0					; carry 0?
		sbi		TLC_Port, TLC_Data			; Nein, Data auf 1
		rjmp	TLC_Out_L_Ende


TLC_Out_L0:


		cbi		TLC_Port, TLC_Data			; Carry Clear, Data auf 0

TLC_Out_L_Ende:


		nop									; kurz warten
		nop
		nop


		sbi		TLC_Port, TLC_Clk			; Pos. Flanke Clock = Bit übernehmen


		dec		temp2
		brne	TLC_Out_L					; Schleife weiter


		inc		temp0						; Nächster Kanal
		cpi		temp0, TLC_Kanaele			; alle Kanäle durch?
		brlo	TLC_Out_Loop				; nein, nächster Kanal


 		sbi		TLC_Port, TLC_Blank			; Blank (LEDs aus)


		sbi		TLC_Port, TLC_Lat			; Daten in's Latch übernehmen
		nop									; kurz warten
		nop
		nop


		cbi		TLC_Port, TLC_Lat			; und anzeigen
		cbi		TLC_Port, TLC_Blank			; Blank off (LEDs an)


		pop		ZH							; Register wiederherstellen
		pop		ZL
		pop		temp0
		pop		temp1
		pop		temp2


		ret


; ------------------------------------------------------------------------------------------------
; Patchtabelle, Zuordnung RAM-Position zu TLC-Kanal
;
; Kanäle werden "rückwärts" vom letzten zum ersten ausgegeben,
; Zahl gibt an, an welcher Position im RAM der auszugebende Kanal liegt (1. Kanal ="0")
; ------------------------------------------------------------------------------------------------


TLC_Patchtable:


.db		8, 7, 6, 11, 10, 9, 23, 22
.db		21, 20, 19, 18, 17, 16, 15, 14
.db		13, 12, 2, 1, 0, 5, 4, 3


; ================================================================================================

Alles anzeigen

(ja, ich weiß, Du machst C, aber evtl. so als Anregung... ;)) - bei mehr als einem TLC muss man dann halt TLC_Kanaele (hier: 24) auf 48, 72, usw. stellen, und die Tabelle unten muss dann auch dementsprechend 24 oder 48 oder 72 usw. Einträge enthalten... und natürlich landen auch hier die zuletzt rausgeschobenen Daten in dem TLC, der als erster am µC hängt...

nighty2k · 21. Januar 2010

Warum so kompliziert Pesi?
Ich mach mir einfach nen Array mit Anzahl der Channels.
Ab sofort, bin ja jetzt schlauer, schiebe ich das Array dann Rückwärts raus. Somit ist Array[0] Pin 1 am TLC1 ... Array[1] Pin 2 am TLC1 usw...
Wie du dich sicher noch an den Sammelbestellungsthread erinnern kannst, hatte ich ja auch schon einen TLC am laufen.
Mit ner selbstgeschrieben Lib, allerdings was mir damals nicht aufgefallen ist das 23 = 0 und 0 = 23 war, aber jetzt zählt die while halt andersrum
Also wenn ich mir deine asm Lib anschaue bin ich doch froh ausm c Lager zu kommen. Array, While-Schliefe oder halt ne for und gut ist.

Dafür hast mein Respekt, sobald ich lustig bin werde ich mich auch noch über asm her machen. =)

Greetz

Pesi · 22. Januar 2010

Naja, soviel aufwändiger ist das in asm auch nicht - die Wörter im Ram und der Z-Pointer da drauf ist im Prinzip nix anderes als ein Array... also das selbe wie das hier:

Zitat von nighty2k

Ich mach mir einfach nen Array mit Anzahl der Channels.

das ist nix kompliziert, in asm sieht das halt so aus..

Zitat von nighty2k

Ab sofort, bin ja jetzt schlauer, schiebe ich das Array dann Rückwärts raus.

Ja - nur hast Du wohl nicht verstanden, worauf ich hinaus will, also was meine Routine macht... dass sie eben *nicht* einfach *der Reihe nach* die Bits rausschiebt, das ist ja "Standard", das hätte ich jetzt nicht reingestellt... (die Routine von mir ist auch nix "Besonderes", aber halt mal so als Idee...)

Zitat von nighty2k

Somit ist Array[0] Pin 1 am TLC1 ... Array[1] Pin 2 am TLC1 usw...

Ja, und wenn Du nun lieber Array[0] an Pin 4 des TLC hättest und Array[3] an Pin 1 und Array[1] an Pin 22 usw., weil sich das dann vom Layout her besser ausgeht...?

Genau *das* macht meine Routine eben, ich kann einen *beliebigen* Eintrag im Array einem beliebigen TLC-Ausgang zuweisen.

Klar, das geht in C natürlich auch mit einem weiteren Array, in dem Du dann diese Zuordnung abspeicherst - und nix anderes macht meine Routine mit dieser "Patchtabelle" ganz am Schluß...

nighty2k · 3. Februar 2010

So lange lange ist es her, nun hab ich endlich mal Zeit mein Board zu erstellen.
Würdet Ihr bitte mal drüber schauen, wenns soweit okay ist, gehen die Daten auf den weiten Weg nach China

Hab mich jetzt nach einigen versuchen gegen einen Puffer Treiber entschieden und werde es einfachheitshalber auf Pesis Methode, mit dem Aderndrehen machen =)
Vielen Dank nochma Pesi für den spitzen einfall

Die Grünen Preile sind ne DuKo mit Leiterbahn auf Top

[Blockierte Grafik: http://nighty2k.de/images/tlc_bot.png]
[Blockierte Grafik: http://nighty2k.de/images/tlc_3d1.png]
[Blockierte Grafik: http://nighty2k.de/images/tlc_3d2.png]

Greetz und vielen Dank

synvox · 3. Februar 2010

Was meinst du mit Aderndrehen? Paarverseilen? Naja, bin mal gespannt, ob das ohne Puffer störungsfrei laufen wird , vor allem die Cock-Leitung zu allen Chips ohne Pufferung . Es wird wohl auf die Gesamtlänge der Leitungen, der Anzahl Chips an der Leitung und den maximal gewünschten Clock-Takt ankommen.

Gruss
Neni

nighty2k · 3. Februar 2010

Also zu den Parametern, hier mal meine absoluten Max Ratings.

4 von den Boards

uc -> erstes Board 50cm
zwischen den Boards 15 cm

höchstens 4 MHz

wie gesagt das sind alles absolute Max Werte, und deine Einschätzung?

Greetz

synvox · 3. Februar 2010

Ok, vier Boards sind jetzt nicht soooo viel. Ich habe gedacht. du hättest öfter mal 12 TLC5947 bzw. 12 Boards erwähnt.

Die Längen machen mir aber triotzdem etwas Sorgen, vor allem die der Clock-Leitung. Fast ein ganzer Meter bei 4 MHz nicht-differentiellem Signal und das bei nur max. 5V Spannungshub, also mir würde es da schon etwas mulmig werden.
Andererseits möchte ich dich auch nicht in unnötige Unkosten stürzen, deshalb weiss ich echt nicht so genau, was ich dir raten soll.

Du könntest ja zumindest auf der µC-Platine dann für die Clock-Leitung einen entsprechenden Leitungstreiber verwenden, welcher dann eben auch höhere Impedanzen und Kapazitäten verkraftet.

Gruss
Neni

nighty2k · 3. Februar 2010

Ja 12 Boards ist shcon richtig, aber irgendwo hatte ich dann auch erwähnt, das ich 3 Busse a 4 Platinen mache =)
Gerade aus dem Grund der Leitungslänge und weil ich sonst für ein Refresh ca 2,8KBit benötige.

Jetzt hast mit wieder sorgen gemacht
Umkosten ist ja relativ, 74er Chips kosten ja nichts, und das Board wird sowieso zweiseitig, das einzige was halt mehr würde sind Stecker und Buchsen.
Und das Layout wird komplizierter zu routen.

Jetzt weis ich wiede rnicht was ich machen soll

synvox · 3. Februar 2010

Wenn du ein Oszi zur Verfügung hast, könntest du ja mal einfach einen äquivalenten Testaufbau machen und dir das Clock-Signal an versch. Punkten anschauen. Dabei kannst du mit einem AVR einen 4 MHz Clock ausgeben und dann in den jeweiligen Abständen mit den entsprechenden Kabeln Chips mit CMOS-Eingängen (es müssen nicht die TLCs sein, einfach Chips mit CMOS-Eingängen, also auch Chips aus der 74HC... oder 74HCT... Reihe) dran hängen. Damit würdest du zumindest einigermassen abschätzen können, ob's am Ende doch reicht oder eher nicht (je nach der gemessenen Signalform).

Gruss
Neni

Pesi · 3. Februar 2010

Meine Einschätzung (ohne Gewährleistung):

ich würde es erst mal so probieren, ggfs. dann noch die stärkeren Treiber am Sender...

Du hast 24 Kanäle á 12 Bit pro TLC, mal 4 macht 288 Bit, mal 4 TLCs macht 1.152 Bit für ein "Bild" - eine Refresh-Rate von 40 Hz sollte wohl dicke reichen (ist mehr als Glotze oder Kino), das wären dann 46.080 Bit/Sekunde - das sollte hier über insg. 1 Meter echt nicht das Problem sein...

muss man dann natürlich von der SW her so machen, dass die das immer schön gleichmäßig im Hintergrund rausschickt - Bei erst alles rechnen und dann immer das neue Bild rausschicken muss das rausschicken natürlich schneller gehen - bei 4 MHz (also 4 Mbit/Sek) hätte ich hier auch Bedenken...

evtl. nen Kompromiß, wenn der Steuer-µC die Hälfte der Zeit nur für's rausschicken vertun darf, und 25 Hz Refresh auch reicht (wie eben bei der Glotze), dann wären's immer Blöcke mit 57 kBit/s, das sollte auch noch problemlos gehen... bei mir geht DMX (250 kBit/s) mit TTL-Pegel über ca. nen Meter ohne Probleme, aber da hängt auch nur ein Empfänger dran... (direkt der Rx von nem Tiny2313)

nighty2k · 17. Februar 2010

So, da es bei mir beruflich gerade viel Stress gibt, habe ich leider nicht so viel Zeit im Moment.
Hatte heute wieder mal Zeit mir Gedanken zu meinem Matrix Projekt zu machen.

Größte aktuelle Änderung ist, dass pro Pixel nun eine Sensorik in Form eines ADC hinzu kommt.
Meine Überlegung war nun jeder 8er Spalte eine eigene Intelligenz in Form eines Atmegas zu verpassen.

Vorteile:
- 8 A/D Channels zur Verfügung
- keine Probleme mehr mit Leitung zu TLC, da ja auf dem selben Board
- es entsteht ein Board, das auch im Single-Betrieb für andere Projekte funktionieren kann.

Weitere Überlegungen:
Da ich ja 12*8 Pixel habe, benötige ich also 12 dieser Boards,
Wie auch bei der bisherigen Variante möchte ich dabei bleiben, das ein Großer uC (XMega) die Master funktion übernimmt.
Was nun trotzdem bleibt ist, dass die Daten zu den Slaves müssen, was mir hier bleibt ist wohl TWI bzw. I²C

Die Slaves sollen als nun folgende Funktionen haben.
-Regelmäßig ADC auslesen und in 8Bit Variable ablegen.
-Regelmäßig TLC refreshen.
-Interrupt wartet auf TWI.
->Über TWI LED Channels empfangen
->Über TWI Sensor Channel an Master geben

Da ich nun noch nie was mit TWI realisiert habe, hätte ich dazu folgende Fragen:
- Wenn ich Daten zu einem Salve(1) sende, was machen dann die anderen Slaves?
Die Daten kommen ja trotzdem an, da diese auch Interrupt basiert sind springen ja alle in Interrupt, was machen nun die Slaves die nicht Empfänger sind?
Wieder aus der Interrupt raus? Dann kommt ja aber sofort das nächste Bit und er springt wieder in Interrupt, dass ist mir alles noch etwas unklar.

- TWI könnte ich ja mit 400.000 Hz realisieren.
Bei Slave Nutzdaten von 288Bit macht das mit Overhead 324Bit + 27Bit für Start, Adresse, Stop.
Somit bin ich also bei 351Bit pro Slave, mal 12 macht das 4212Bit für alle Slaves.

400.000 / 4212 = 94,96

Somit könnte ich die gesamten Daten also 94,96 mal über den Bus jagen, wobei mir 25-35 mal reichen würden, sehe ich das richtig?
(Die Rechnung beinhaltet natürlich noch nicht das auslesen der Sensorik, wobei das vom Datenaufkommen dagegen ja "Kinderkram" ist)

Vielen Dank wiedermal an euch =)
Und sorry für das viele Hü und Hot, aber in das Projekt fliest ne Menge Geld, und wenn ich was mache, dann richtig, soll am Ende ja auch funktionieren.

Greetz

Kanwas · 18. Februar 2010

TWI ist ja I²C also Adressbasiert.
Wenn ein Master etwas sendet, sendet er zuerst die Adresse des Slave. Dann verhalten sich die nicht angesprochenen Slaves passiv. Sie müssen aber weiterhin den Bus abhören um nix zu verpassen. Es reicht allerdings aus auf ein Start Signal zu triggern.
Das ist bei mir auch schon länger her, dass ich I²C mal programmiert habe. Und da war es noch komplett von Hand Auf nem AVR habe ich es noch nicht versucht (Nen LM75 liegt hier rum und langweilt sich )
TWI ist in den Atmegas doch soweit in Hardware integriert oder? Das sollte die Sache doch dann einfacher machen

(TLC5947 Board erstellen.) FRAGEN zu TWI

Teilen

Benutzer online in diesem Thema