Hallo, ich hab überlegt an verschiedene SPI Signalleitungen Status LEDS anzuschliessen. Können die SPI Signale dadurch gestört werden? SS ist denk ich unkritischer als beispielsweise MOSI, MISO oder SCK... ich würde die LED mit einem Transistor auf die signalleitung schalten. signal low...transistor schaltet...LED an da manche signale schnell takten, müsste der vorwiderstand entsprechend kleiner gewählt werden um helleren blitz zu erzeugen... aber geht das alles ohne zu stören?
Kannst ja den Transistor in Kollektorschaltung betreiben. Aber gehen tut das, wenn du möglichst wenig Strom von den SPI-Leitungen ziehst. Aber das wird wirklich nur kurz blitzen an den LEDs. Halts eher für unsinnig...
Wenn du auf nem STK500 an PortB die LEDs anschließt geht das auch ohne die SPI zu stören. Auf dem Board sind die LEDs auch mit Transistoren angesteuert. Halt ich aber auch für unsinnig. Die blitzen echt nur kurz auf und gehen dann wieder aus. Was mehr sinn machen würde am Programmer ne LED die wärend dem gesammten Programmiervorgang leuchtet. (Also nur an der Reset Leitung ?!)
Hallo, ja, das geht, habe ich auch gemacht, man sieht es immer heller leuchten,m je mehr auf dem Bus los ist. Mit Low Power LED gehts ganz gut oder mit den Blauen, die leuchten schon ab 200 uA. Im Übrigen schliesst man einen schnelen SPI Bus ja auch ab (ich nehme 100 Ohm) und lässt etwas Strom fliessen, bzw fügt 20 Ohm Widerstände in die Leitungen am Prozessor ein, um ein RC Filter zu bilden.
@ Patrick Ka (kaplan) >ich hab überlegt an verschiedene SPI Signalleitungen Status LEDS >anzuschliessen. Können die SPI Signale dadurch gestört werden? Jain. >ich würde die LED mit einem Transistor auf die signalleitung schalten. >signal low...transistor schaltet...LED an >da manche signale schnell takten, müsste der vorwiderstand entsprechend >kleiner gewählt werden um helleren blitz zu erzeugen... Dann must sie ntweder relativ langsam takten oder Augen wie Superman haben. Solche kuzen Pulse im Nanosekundenbereich sieht kein Mensch. Da brauchst du eher sowas. http://www.geocities.com/jacquesmartini/digital/logiktester/logiktester.html Wobei es für deine Zwecke einfacher geht. Ein Monoflop mit 74HC123. Wozu soll das denn gut sein? MfG Falk
ich vermute Patrick möchte einfach nur den SPI + externe LEDs im laufenden Betrieb haben. Um eine "Kontrolle" des Programmiervorgangs gehts wahrscheinlich nur sekundär. Auch ich hänge LEDs bevorzugt an den SPI Port, beim Flashen stören sie nicht, und ihre Aktion -> Leuchten -> ist weniger gefährlich als wenn da ein Starkstrommotor mit seinem Treiber parallel hängt. Gruß Hagen
@ Christian Julius (Gast) >oder mit den Blauen, die leuchten schon ab 200 uA. Im Übrigen schliesst >man einen schnelen SPI Bus ja auch ab (ich nehme 100 Ohm) und lässt Die Ausgänge vom AVR werden sich freuen, vor allem bei 5V (was schlappe 50mA braucht). >etwas Strom fliessen, bzw fügt 20 Ohm Widerstände in die Leitungen am >Prozessor ein, um ein RC Filter zu bilden. So einen RC-Filter mögen vor allem Takteingänge . . . Terminierung funktioniert ein wenig anders. MfG Falk
ich möchte nicht unbedingt die programmierung begutachten sondern schauen, welcher meiner SLAVES gerade daten üverträgt (Slave Board im anderen thread unter Platinen). und da ich keinen Port mehr frei hab um das separat zu steuern wäre eine andere lösung geschickt.ansonsten wird das debuggen verdammt mühselig...
>oder mit den Blauen, die leuchten schon ab 200 uA. Im Übrigen schliesst >man einen schnelen SPI Bus ja auch ab (ich nehme 100 Ohm) und lässt Die Ausgänge vom AVR werden sich freuen, vor allem bei 5V (was schlappe 50mA braucht). ## ;-) Man nehme eine Null mehr an der 100, dann passt das. Geht auch über einen Kondensator + R. Ich hatte mal eine Page wo alle Möglichkeiten draufstanden aber ich finde die nicht wieder. >etwas Strom fliessen, bzw fügt 20 Ohm Widerstände in die Leitungen am >Prozessor ein, um ein RC Filter zu bilden. So einen RC-Filter mögen vor allem Takteingänge . . . ## Fast alle Busdesigns die auf meinem Schreibtisch landen haben diese Widerstände eingefügt. Die 20 Ohm bilden mit der Kapaität des Pins einen Tiefpassfilter von einigen zig Mhz. Ausserdem glättet er die Flanken.
@ Patrick Ka (kaplan) >schauen, welcher meiner SLAVES gerade daten üverträgt (Slave Board im >und da ich keinen Port mehr frei hab um das separat zu steuern wäre eine >andere lösung geschickt.ansonsten wird das debuggen verdammt mühselig... ??? Du STEUEST doch mit SS, welcher Slave gerade angesprochen wird. Und dein Master gibt auch den Takt vor. Da ist die von dir vorgeschlagene Debuggschaltung vollkommen nutzlos. Mal ganz abgesehen davon, dass du da bestenfalls was flimmern siehst, wenn dein Programm mit voller GEschwindigkeit läuft. Da wäre dann schon ein Logicanalyser notwendig. MfG Falk
@ Christian Julius (Gast) >>Die Ausgänge vom AVR werden sich freuen, vor allem bei 5V (was schlappe >>50mA braucht). >## ;-) Man nehme eine Null mehr an der 100, dann passt das. Geht auch 1000 Ohm sind als Terminierung vollkommen sinnlos, die kann man auch weglassen. >über einen Kondensator + R. Ich hatte mal eine Page wo alle DAS ist schon was GANZ anderes. Nämlich AC-Terminierung. >Fast alle Busdesigns die auf meinem Schreibtisch landen haben diese >Widerstände eingefügt. Was noch lange nicht heisst, dass es sinnvoll ist. > Die 20 Ohm bilden mit der Kapaität des Pins einen > Tiefpassfilter von einigen zig Mhz. Ausserdem glättet er die Flanken. Ach ja? Und das ist gut? Wieviel "zig" Mhz sind es denn? Bei angenommenen 10pF Eingangskapazität und 20 Ohm + 30 Ohm Innenwiderstand sind das bei mir ~318 MHz. So schnell sind die gängigen Schaltkreise (HC-Familie etc.) gar nicht, somit ist der Frequenzbereich eher uninteressant. "Flanken glätten" ist oft eine schlechte Idee. Nicht ganz umsonst haben viele ICs ein maximal zulässige Ansiegszeit definiert. Aber am Ende wirken die 20 Ohm extern + Innenwiderstand in Reihe wie ~50 Ohm, und bilden eine gute Serienterminierung für 50 Ohm Leitungen. Das sollte man aber nur bei Punkt-zu-Punkt Verbindungen oder Datensignalen machen, jedoch nicht bei Takten mit Multi-Drop-Struktur. Gleiche Hardware, aber entschieden andere Funktion! MfG Falk
Falk wrote: > Du STEUEST doch mit SS, welcher Slave gerade angesprochen wird. Und dein > Master gibt auch den Takt vor. Da ist die von dir vorgeschlagene > Debuggschaltung vollkommen nutzlos. Mal ganz abgesehen davon, dass du da > bestenfalls was flimmern siehst, wenn dein Programm mit voller > GEschwindigkeit läuft. Da wäre dann schon ein Logicanalyser notwendig. wenn ich an jeder SS leitung eine LED hänge und die mir anzeigt welcher SLAVE gerade angesteuert wird bringt mir das doch einiges... bei meinem Master-MultiSLave Test (alles AVR ATMega644) gabs einige probleme bis die übertragung geklappt hat. da mein protokoll im endstadium etwas umfangreicher wird als schlichte datenpakete zu versenden, kann mir eine LED schon helfen. Z.b. dann wenn ein Slave hängen bleibt und seine übertragung nicht beenden will. dann bleibt die led an... und wenn ich jetzt da diese SS leitung ein NPN Tranistor hänge und in Emitter Schaltung eine LED betreibe dürfte es doch keine probleme geben...
@ Patrick Ka (kaplan) >wenn ich an jeder SS leitung eine LED hänge und die mir anzeigt welcher >SLAVE gerade angesteuert wird bringt mir das doch einiges... bei meinem Kaum. >LED schon helfen. Z.b. dann wenn ein Slave hängen bleibt und seine >übertragung nicht beenden will. dann bleibt die led an... Das denke ich nicht. Wie komplex ist denn deine Datenübertragung. Im Normalfall gehts doch eher so. Master setzt SS des Slaves Master überträgt N Bytes Master deaktiviert SS Wo siehst du da ein Hängenbleiben? >und wenn ich jetzt da diese SS leitung ein NPN Tranistor hänge und in >Emitter Schaltung eine LED betreibe dürfte es doch keine probleme >geben... Nimm einfach ne Low Current LED und nen grossen Vorwiderstand (>1k), dann ist alles im Lot. Mfg Falk
ich benutze bei SPI noch ne zusätzliche Handshake Leitung. denn die Slaves sind nicht immer sofort bereit. somit muss der master manchmal auch kurz warten...
...benutze bei SPI noch ne zusätzliche Handshake Leitung. denn die Slaves sind nicht immer sofort bereit. somit muss der... Das klingt aber dann nicht nach echtem-SPI ??? Wieso kann ein Schieberegister nicht bereit sein?? **kopfkratz**
@ Matthias (Gast) >>...benutze bei SPI noch ne zusätzliche Handshake Leitung. denn die >>Slaves sind nicht immer sofort bereit. somit muss der... >Das klingt aber dann nicht nach echtem-SPI ??? Ist es auch nicht ganz. >Wieso kann ein Schieberegister nicht bereit sein?? >**kopfkratz** Wenn das Schieberegister ein AVR ist, der muss erst auf den Interrupt vom SS reagieren und Daten ins Schieberegister tun. Das dauert ein paar Takte (us). MfG Falk
??? Also bei mir steckt ein 74138 drin als Slave Decode und als Schieberegister ein 74HCT595, die schalte sofort. Und wenn die Slaves PICs sind, wie in meinem derzeitigen Projekt, dann kriegen die vom Master solange ein "Are you there?" vor den Latz geballert, bis sie sich mit "I am here" zurückmelden. Die SPI seöbnst wird bei SS=0 initialisiert und bitsynchron gemacht. Und wenn ein Slave fertig ist schreibt er ein ID-Byte in das SPI Register, das der Master sofort bekommt, wenn er die Leitung triggert, damit er weisse, dass der Slave seine Aufgabe erfüllt hat. Ganz trivial ist es trotzdem nicht und man sollte nicht spotten. Bei Langzeitläufen mit 5 Slaves an einem Master habe ich schon sporadische Abstürze gehabt und Datenfehler, wenn das Timing nicht 100% hinhaute. Darum immer mit Checksumme und Datenecho bei der Übertragung. Gruss, Christian
also mein MASTER ist ein ATMEGA644 und ALLE SLAVES sind auch ATMEGA644. >dann kriegen die vom >Master solange ein "Are you there?" vor den Latz geballert, bis sie sich >mit "I am here" zurückmelden. Meine Handshake Leitung bezweckt genau dies... nur eben mehr Hardware anstatt software. Die Shiftregister des SPI und die Shiftregister auf meiner Platine bitte nicht in Zusammenhang bringen. AM SPI Bus hängen bei mir ausschließlich ATMEGAs. Die zwei 8Bit Shiftregister (vormals ein 16 Bit) lesen nur eine jumper sache aus :) >wenn das Timing nicht 100% hinhaute. >Darum immer mit Checksumme und Datenecho bei der Übertragung. Wegen den timing problemen hab ich zu Handshake gegriffen. Zumal ein Slave nur mit 1/4 des Taktes arbeiten kann. Siehe AVR Dattenblatt Ausserdem machen meine "Slave"Boards ne menge mehr als nur auf den MAster zu warten... aber das nur am Rande. wer das ganze mal in Aktion sehen will muss dann meinen Endbericht lesen :)
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.