Schönen guten Tag, ich versuche gerade, 3 7 Segment Anzeigen per Multiplex über einen AtMega8 anzusteuern. Alles läuft auch gut, die 3 Anzeigen leuchten und zeigen das an, was sie sollen, jedoch nicht so, wie sie es sollen. Angenommen, es erscheint auf dem Display die Zahl „412“, dann leuchten nicht nur die Segmente, welche die 3 Zahlen darstellen, sondern auch noch ein paar andere Segmente schwächer. Dadurch lässt sich die Anzeige schlechter ablesen und irgendwie wirkt es auch unsauber. Je nach eingestellter Zahl leuchten eben andere Segmente noch schwächer mit, die es aber nicht sollen. Ich hab mal ein Bild davon angefügt. Die fehlerhaft schwach leuchtenden Segmente sind grün umrandet. Außerdem ein Bild vom groben Überblick über die LED-Beschaltung mit dem µC. Die Vorwiderstände für die Segmente sind jeweils 300 Ohm, die 3 Basiswiderstände für die Transistoren jeweils 1KOhm. Transistortyp: BC550B Ist das Problem nun schaltungsbedingt oder programmabhängig? Kurioserweise wird das Leuchten der „falschen“ Segmente immer schwächer, je niedriger die Multiplexgeschwindigkeit gewählt ist. Nur leider fängt die Anzeige dann an zu flackern, logischerweise. Hier mal die Routinen für das Multiplexing: k[1]= Displ1Out; //Multiplex Transistor 1 schalten k[2]= Displ2Out; //Multiplex Transistor 2 schalten k[3]= Displ3Out; //Multiplex Transistor 3 schalten //****Zahlen den Segmenten zuweisen**** j[1] = x[d1]; //Stelle 1 j[3] = x[d2]; //Stelle 2 j[2] = x[d3]; //Stelle 3 //************************************* //****7-Segment-Multiplex************** for (i=1;i<=3;i++) { Out3 = j[i]; //Zahl ausgeben _delay_us(100); //nach 100us weiterschalten Out2 = k[i]; //nächstes Segment ansteuern } } } //************************************* Ich hoffe, dass das bischen Quellcode genügt. Das Programm an sich ist ziemlich lang. So, dann bedank ich mich schon mal! Grüße Tom
Angehängte Dateien:
-
atme.JPG
140 KB
Das Problem könnte an den übersteuerten Transistoren liegen. 10kHz Mux-Frequenz sind ziemlich viel! Baue mal pnp als Kollektorschaltung (ohne Basiswiderstände!) ein.
Was mir beim kurzen Blick auf den Code auffällt: Mit wievielen Elementen sind denn deine Felder definiert? Was steht an Index 0 ? j[3] = x[d2]; //Stelle 2 j[2] = x[d3]; //Stelle 3 Hat der Dreher hier einen Grund? Insgesamt fehlt zur Beurteilung des Codes halt der Rest. Zumindest alle im Codeschnipsel verwendeten Definitionen.
Du solltest vor dem wechsel auf einen anderen multiplextransi alle segmente ausmachen und erst nach dem wechsel die zu dieser stelle gehörigen segmente einschalten. Im Bild sieht man wunderbar in der zweiten stelle die 4 der ersten schwach leuchten.
@ Tom (Gast) >Dateianhang: atme.JPG (144,7 KB, 30 Downloads) Bildformate Deine Bauteile in Schaltplan haben kein Werte. >Basiswiderstände für die Transistoren jeweils 1KOhm. Transistortyp: >BC550B Aha, so macht man das heute. >Ist das Problem nun schaltungsbedingt oder programmabhängig? Sowohl als auch. Das Nachleuchten ist das zu langsame Abschalten der Spaltentransistoren. icht weil die so langsam sind, sondern weil die Ansteuerung suboptimal ist. >//****7-Segment-Multiplex************** > for (i=1;i<=3;i++) > { > Out3 = j[i]; //Zahl ausgeben > _delay_us(100); //nach 100us weiterschalten > Out2 = k[i]; //nächstes Segment ansteuern > } > } >} >//************************************* Komisches Multiplexing. Schon mal was von einem Timer gehört`? Ausserdem muss zwischen den Umschaltungen ei Pause von 1.2us her, solange brauchen deine Tranistoren zum umschalten. Das kann man beschleunigen, indem man ca. 22ßpF parallel zu den Basiswiderständen lötet. MFG Falk
Oh, viele Antworten, Dankeschön! @ Matthias Lipinsky, wenn ich die Zeit statt 100µs auf 5ms setze, ist das Nachleuchten fast weg. Aber dann bild ich mir ein, dass es leicht flackert. Außerdem scheint da ja noch ein anderes Prob zu sein, wie alle schreiben. @ ARM-Fan, hier noch die defines zum besseren Verständnis: #define Out2 PORTB #define Out3 PORTD #define Displ1Out 1<<PORTB0 #define Displ2Out 1<<PORTB1 #define Displ3Out 1<<PORTB2 Über den Zahlendreher, der mir im Moment auch schleierhaft vorkommt, muss ich noch mal nachdenken. Hab den code vor nen halben Jahr programmiert, die Sache aus Zeitmangel auf Eis gelegt und will nun weiterarbeiten. @ capellone, gute Idee, bin dabei, es zu testen. @ Falk Brunner, die Timer sind alle in Verwendung und werden unbedingt gebraucht. Dieser AVR hat ja leider nur 2. Ein Timer dient als „Taktgeber“ für einen exakten 1s. Takt, der Andere zum Abtasten eines Präzisionsgebers. Wenn ich nun die Pause einfüge, ändert sich leider nichts. Du meintest das doch so, oder: >//****7-Segment-Multiplex************** > for (i=1;i<=3;i++) > { > Out3 = j[i]; //Zahl ausgeben > _delay_us(100); //nach 100us weiterschalten > Out2 = k[i]; //nächstes Segment ansteuern _delay_us(1.2); //nach 100us weiterschalten > } > } >} >//*************************************
>Takt, der Andere zum Abtasten eines Präzisionsgebers. Das ist doch ideal. Wie schnell läuft der? Pack die Mux-Ausgabe da mit rein. delay ist immer Mist. >5ms setze,..flackert Natürlich, dann sinkt die Effektive Frequenz auf (Größenordnung) von 50Hz.
Timer kann man mehrfach verwenden. Stell ihn z.B. so ein, dass er alle 1ms einen Interrupt erzeugt. Davon leitest du beliebige andere Zeiteinheiten ab.
Der Timer zur Abfrage läuft gerade mit 3,9 KHz (256µs). In dieser ISR steht aber schon allerhand drinn. Wird dann irgendwie unübersichtlich. Es muss doch aber auch ohne Einsatz eines Timers gehen.
Du musst, bevor du die nächste Ziffer auf dem nächsten Segment ausgibst, die Matrix-Transistoren alle abschalten, dann die neue Ziffer auf den Port legen und erst dann den entsprechenden Matrixtransistor wieder ansteuern. Ansonsten "verschleifst" du die Ziffer die du am folgenden Segment ausgeben willst auf das momentan angesteuerte Segment. Gruss Chris
Also das Problem hatte ich auch mal...nach einigem Grübeln bin ich dann auf das Problem gekommen: Mein Vorgehen (so wie auch deins) war: ... -> Zahl ausgeben -> warten -> nächstes Segment ansteuern -> .... Das Problem hierbei ist, dass während du schon zum nächsten Segment schaltest noch die "alten" Daten anliegen. Das erklärt auch, dass das Problem bei niedrig werdender Multiplexfrequenz kleiner wird, denn diese "Übergangszeit" wird dann im Vergleich zur "Verweilzeit" immer unbedeutender. Prinzipiell gibt es hierfür 2 Lösungsansätze: ... -> Zahl ausgeben -> nächstes Segment einschalten -> warten -> Segment ausschalten (über Transistor) -> ... oder: ... -> Zahl ausgeben -> warten -> 0b00000000 ausgeben (Segment aus) -> nächstes Segment ansteuern -> ... ---------------------------------------------- Beide Lösung machen davon Gebrauch, dass die Komplette Anzeige für eine kleine Zeit ausgeschaltet sind. Prblem mit sich überlappenden Zuständen (alte Daten, neues Segment) bzw. Schaltzeiten der Transistoren sollten damit behoben werden. Gruß Christian PS.: Siehe Chris D. über mir, der ein Bisschen schneller war ;-)
@ Tom (Gast) >@ Falk Brunner, die Timer sind alle in Verwendung und werden unbedingt >gebraucht. Dieser AVR hat ja leider nur 2. Ja und? Das reicht dicke. > Ein Timer dient als >„Taktgeber“ für einen exakten 1s. Dort kann man PROBLEMLOS eine MUX-Funktion unterbringen. Siehe [[AVR - Die genaue Sekunde / RTC]. Das Ganze könnte PROBLEMLOS mit einem einzigen Timer laufen. Das wäre sogar besser, weil deterministischer. > Takt, der Andere zum Abtasten eines Präzisionsgebers. Du meinst Drehgeber? Auch kein Problem. Dein Delays verballern sinnlos CPU-Power. >Wenn ich nun die Pause einfüge, ändert sich leider nichts. Du meintest >das doch so, oder: Ja, wobei ich eher 1 bis 2 Mikrosekunden meinte, nicht 1 KOMMA 2 ;-) Ist aber egal. Probier mal ein wenig mehr, so bis 10us. MFG Falk
...ich hatte (die Woche) auch so meine Probleme mit genau der selben MUX Ansteuerung und ähnlichen Fehlern - bin dann über die "Zählschleife" letztendlich auch bei ISR gelandet, alles andere ist Mist. Also lern draus, ohne ISR sind die Displays zu dunkel bzw werden nicht optimal angesteruert. Die beste Ansteuerung ist, wenn NUR die ISR zu definierten Zeitpunkten die Anzeige weiterschaltet, quasi ohne "Pause" oder "Auszeiten"... Gruß, Klaus.
Sooo,
es Läuft! Einwandfrei. Immer wieder äußerst hilfreich dieses Forum!
Vielen dank euch Allen! Also, hier meine Lösung:
for (i=1;i<=3;i++)
{
Out3 = j[i]; //Zahl ausgeben
_delay_us(100); //nach 5ms weiterschalten
Out3 &= ~(SegA | SegB | SegC | SegD | SegE | SegF | SegG);
_delay_us(100); //nach 5ms weiterschalten
Out2 = k[i]; //nächstes Segment ansteuern
}
Die 2 Zeilen zwischen den Lehrzeilen haben also gefehlt. So läuft es
erstmal. Ich werd in den kommenden Tagen das ganze Prog noch verfeinern
und mich euren Vorschlägen annehmen, auch bzgl. des Timers.
Kurze Frage, warum "verballert es CPU-Takt"? Ich mein, das Programm
läuft doch so einwandfrei. Wie wirkt sich dies nachteilig aus? Kann man
die CPU-Auslastung denn irgendwie berechnen? Sind diese delay-Fkt.
wirklich so unvorteilhaft? Warum?
Grüße Tom
>Sind diese delay-Fkt. wirklich so unvorteilhaft? Warum?
Warum wohl? Was wird denn während dieser Zeit gemacht??
Richtig. Der µC wird (sinnlos) damit beschäftigt, eine Variable
herunterzuzählen...
Man könnte während dieser Zeit auch was sinnvolles machen...
Es gibt eine einzige Anwendung, wo man das machen könnte: wenn die Displaysteuerung die einzige Funktion der main ist (d.h. der Rest irgendwie in Interrupt-Routinen abgearbeitet wird). Dann ist es im Prinzip egal, ob du deine Prozessorzeit direkt mit Warteschleifen vertüdelst oder wartest, bis ein Timer dir sagt, die Zeit ist vorbei. Besser ist es dennoch, einen Timer zu benutzen. Vorteile vor allem bei späteren Programmerweiterungen - dann kannst du die gesparte Zeit sicher sinnvoller verwenden. Wie gesagt - die Displaysteuerung benutzt nur wenige Takte in einer ISR.
Falk Brunner wrote: > Ausserdem muss zwischen den Umschaltungen ei Pause von 1.2us her, > solange brauchen deine Tranistoren zum umschalten. Das kann man > beschleunigen, indem man ca. 22ßpF parallel zu den Basiswiderständen > lötet. Oder man nimmt PNPs in Kollektorschaltung, dann braucht man das Delay beim Umschalten nicht. Den Basiswiderstand spart man auch ein. Und bei 5V hat man noch genügend Spannung für die LEDs. Peter
Diese Übersprechen ist normal bei 7-Segmentanzeigen. Die wahrgenommene Helligkeit ist eine log Funktion. Durch die minimale Zeitverzögerung beim Abschalten der Transistoren werden Segmente der Anzeige kurzeitig angesprochen und man hat deshalb diesen Effekt. Die einzige Abhilfe dagegen ist das Ausschalten aller Segmente währen des Umschaltens auf die nächste Anzeige. Dieses Ausschalten sollte ca 50us lang sein und in die entstprechende Statemaschine berücksicht werden. Das Umschalten sollte in dieser Reihenfolge passieren: Ausschalten alles Segmente. 25uS Warten. Andere Anzeige auswählen. 25us Warten Segmente Einschalten. Willi Warlord
@ Willi Warlord (Gast) >Diese Übersprechen ist normal bei 7-Segmentanzeigen. Die wahrgenommene >Helligkeit ist eine log Funktion. Ja, siehe LED-Fading. >>die nächste Anzeige. Dieses Ausschalten sollte ca 50us lang sein und in Naja, alles relativ. Der UDN2981 braucht so lange. Die Diskreten Transistoren wie hier im Beispiel so 1..2us. PNPs in Kollektorschaltung 100ns, eher weniger. Die Logik besser so sortieren. Ausschalten aller Segmente Neue Ziffer dekodieren 2..50us warten Neue Ziffer ausgeben Neues Segmant aktivieren hat den Vorteil, dass die "aufwändige" Zifferndekodierung der nächsten Stelle gleichzeitig als Wartezeit genutzt werden kann. MFG Falk
Falk Brunner wrote: > PNPs in Kollektorschaltung 100ns, eher weniger. Ja stimmt: eher weniger. Es reicht dann völlig aus: - alle Digits aus - neues Segmentmuster setzen - nächstes Digit ein ganz ohne jede zusätzliche Wartezeit (AVR@16MHz). > hat den Vorteil, dass die "aufwändige" Zifferndekodierung der nächsten > Stelle gleichzeitig als Wartezeit genutzt werden kann. Mach ich dann doch lieber in der Mainloop einmalig bei der Ausgabe einer neuen Zahl. Spart nochmals einige Promille an CPU-Last für andere Tasks. Auch hab ich die Interrupts gerne so kurz wie möglich. Peter
Mal eine Frage, warum hat man diesen Effekt nicht bei pnp's in Kollektorschaltung? Das müsste doch völlig egal sein, ob pnp oder npn, zeitmäßig gesehen. Warum spart man sich da den Basiswiderstand? Es ist in der Tat schon so, dass in der Main außer der Initialisierung nichts stattfindet. Okay, es wird ein Unterprogramm aufgerufen, was eben die Ansteuerung der 7-Seg. Anzeige übernimmt, aber der ganze Rest befindet sich in den ISR's.
weil in dieser Schaltung die Transisoren nicht in die Sättigung kommen/nicht übersteuert werden. Deshalb kann der Transistor schneller sperren (überschüssige Ladungen müssen nicht erst abfliessen)
>warum hat man diesen Effekt nicht bei pnp's in >Kollektorschaltung? Bei der Kollektorschaltung ist der Transistor nie in der Sättigung. PNP oder NPN ist da gleich, hier nur deshalb, weil es ein deinem Fall dann ein PNP sein müsste.
Tom wrote: > Es ist in der Tat schon so, dass in der Main außer der Initialisierung > nichts stattfindet. Okay, es wird ein Unterprogramm aufgerufen, was eben > die Ansteuerung der 7-Seg. Anzeige übernimmt, aber der ganze Rest > befindet sich in den ISR's. Mit diesem Konzept wirst Du nicht froh werden. Das heißt ja, wenn alles in den Interrupts gemacht werden muß, dauern die auch schön lange und erhöhen das Delay im Main. Damit wird Deine Anzeige immer flackern, sobald ein Interrupt ausgelöst wird. Außerdem können sich so lange Interrupts leicht gegenseitig blockieren (Uhr geht nach, UART verliert Daten usw.). Andersrum, wenn der Timer das Multiplexen macht, stört es überhaupt nicht, wenn im Main mal 100ms lang gerechnet werden muß. Daß ne neue Zahl erst nach 100ms angezeigt wird, merkt kein Mensch. Peter
Eine grundsätzliche Sache noch.... Man legt Multiplexer üblicherweise nie so aus das bei einem Prozessorreset alle Segmente sofort angesteuert werden. Reset bedeutet dass alle Ports als Eingangsports geschaltet werden. Nach Außen hin stellt sich ein Reset so dar, das die Potleitungen, „High-Level“ annehmen und in deinem Fall alle Segmente mit "888" angesteuert werden. Das mag bei drei Segmenten und den hier verbauten Vorwiderständen noch kein Problem darstellen. Aber beim Multiplexen von üppigeren Matrizen werden weitaus kleinere Vorwiderstände eingesetzt damit die Lichtausbeute der einzelnen Segmente unserem Auge eine schöne, helle und homogene Anzeige vorgaukeln kann. In der Zeit bis die Portleitungen dann initialisiert werden, könnten sich mit deiner Hardware bereits einige LED’s wegen Überbelastung in die ewigen Segmentgründe verabschiedet haben... Und wer hier denkt das Watchdog- oder Brown-out-Detection dem Segmentsterben Einhalt gebieten können, der irrt gewaltig. Genau das Gegenteil ist der Fall, denn beide Detektoren belaufen sich auf einen Prozessorreset hinaus – und der kann durchaus zyklisch sein. Darum sollte man eine Multiplexschaltung immer so auslegen das Segment- und Segmentmatrix immer unterschiedliche Potentiale zur Ansteuerung benötigen. (Also einen der beiden Signalbusse invertieren ;-) Gruss Chris
Chris D. wrote: > Man legt Multiplexer üblicherweise nie so aus das bei einem > Prozessorreset alle Segmente sofort angesteuert werden. Ein ganz kurzer Blick auf die Schaltung verrät, hatter nicht. > Reset bedeutet > dass alle Ports als Eingangsports geschaltet werden. Nach Außen hin > stellt sich ein Reset so dar, das die Potleitungen, „High-Level“ > annehmen und in deinem Fall alle Segmente mit "888" angesteuert werden. Das ist 2-mal Quatsch mit Soße: 1. Eingänge floaten beim AVR. 2. LEDs und Bipolartransistoren brauchen echten Strom, sonst sind sie aus. High könntest Du nur dann sehen, wenn Du noch echte TTL-ICs dazwischen schalten würdest. Peter
@Peter Dannegger (peda) >>Tom wrote: >> die Ansteuerung der 7-Seg. Anzeige übernimmt, aber der ganze Rest >> befindet sich in den ISR's. >Mit diesem Konzept wirst Du nicht froh werden. Genau, deshalb ist die Lektüre des Artikels Interrupt empfehlenswert. @ Chris D. (m8nix) >Man legt Multiplexer üblicherweise nie so aus das bei einem >Prozessorreset alle Segmente sofort angesteuert werden. Richtig, werden sie aber hier nicht. > Reset bedeutet >dass alle Ports als Eingangsports geschaltet werden. Nach Außen hin >stellt sich ein Reset so dar, das die Potleitungen, „High-Level“ >annehmen Nöö, das ist bestenfalls bei den 8051ern so. Und selbst dort sind es nur schwache Pull-Ups. >und in deinem Fall alle Segmente mit "888" angesteuert werden. Aber nur, wenn die gemeinsamen Kathoden durchsteuern, was sie nicht tun. >homogene Anzeige vorgaukeln kann. In der Zeit bis die Portleitungen dann >initialisiert werden, . . . halten richtig platzierte Pull-Ups oder Pull-Downs die Spaltentreiber im AUS-Zustand. >Darum sollte man eine Multiplexschaltung immer so auslegen das Segment- >und Segmentmatrix immer unterschiedliche Potentiale zur Ansteuerung >benötigen. Nöö, vollkommen unnötig. Siehe LED-Matrix. MfG Falk
@ Chris D. nach dem Reset sind die Ports üblicherweise als Eingang geschaltet - keine Gefahr. Selbst wenn die internen Pullups aktiv sein sollten (sofern für die betreffenden Ports welche existieren sollten) - keine Gefahr. Denn die liefern ja nur einen sehr geringen Strom in die Transistorbasen. Und selbst wenn die Transistoren damit einige mA als Ic liefern könnten, können Sie es nicht, weil die Segmentleitungen ja auch nur über die Pullups gezogen werden, was nur paar µA Segmentstrom verursacht - da brauchste einen Sekundärelektronenvervielfacher, um eine 888 zu sehen. Zusätzliche PullUps/Downs sind also eigentlich komplett überflüssig an dieser Stelle - die würden weder eine nicht vorhandene Gefahr eliminieren, noch der Anzeige irgendeine besondere "Ausstrahlung" verleihen. Noch was zur Matrixansteuerung in der main(). Du versuchst ja, den Takt mit dem Delay vorzugeben. Wie schon jeder sagte, ist das meistens schlecht, nicht weil CPU-Power sinnlos verbraten wird (ist wohl eher das kleiner Übel), aber wenn der µC nebenbei noch andere Dinge in der main() macht, die noch dazu unterschiedlich in jedem Schleifendurchgang brauchen, hast Du eben auch das Flackern in der Anzeige, oder die Digits leuchten unterschiedlich hell (das ist wohl das, was Falk mit Deterministic meinte). typisches Beispiel aus der Praxis: einfache oder älter Fernsehgeräte u.a. - wenn Du da auf irgendwelche Tasten drückst, geben die oft eine hübsche Lichtorgel her (bei manchen siehste das Flackern sogar rhytmisch auch ohne Tastendruck - offensichtlich beschäftigt sich der µC gerade dann mit dem I2C) Auch wenn Du später was zur main() hinzufügst, änderst Du damit auch das gesamte Timing.
Ich würde langsamer schalten 1kHz reicht eigentlich aus. Das sind immer ncoh 300 Hz je Anzeige. Ausserdem sollten die Transistroen etwas Totzeit bekommen, also nicht mit den Daten umschalten, sondern VOR dem Datenumschalten abschalten und erst NACH dem Datenumschalten wieder anschalten. Früher (als wir nur mit 10-20 Hz wechseln konnten) haben wir das so gemacht, daß wir über Dioden rausgegangen sind, an denen Kondensatoren hingen. Das ergabe ein schönes Nachleuchten und eine stabile Anzeige ganz ohne "Hetze"!
Angehängte Dateien:
-
Impulsgeber.JPG
18 KB
So, dann muss ich mich auch mal wieder zu Wort melden. Hat sich ja in der Zwischenzeit einiges getan. Und zum Weiterprogrammiern bin ich auch noch nicht gekommen. Werd ich mir für das Wochenende aufheben. Also, was gäbe es denn noch an meiner Schaltung grob zu änder? Ihr schreibt alle was von Kollektorschaltung mit pnp. Ich mein, ist das wirklich erforderlich? Das Blinken ist ja nun erstmal verschwunden durch den (provisorischen) Einbau dieser 2 Zeilen, die ich gestern hier genannt hatte. Aber okay, noch hab ich Spielraum in der Gestaltung der Schaltung. Den Quellcode werd ich dann auch noch verändern und evtl. umschreiben. Aber wie gesagt, momentan mit dieser kleinen Änderung ist alles perfekt. Kein flackern, alle Anzeigen gleich hell und keine Verwischungen. Noch eine kleine Frage nebenbei: Insgesammt sind dort 2 Taster angeschlossen. Durch die internen pullups kann ich mir doch die externen sparen, oder? Zweite Frage, wie schon richtig erkannt, ist dort ein Drehimpulsgeber angeschlossen. Laut dem angehangenen Schaltbild werden dort ja 3 pullups benötigt. Kann ich diese auch weglassen? Das ich die pullups softwareseitig erst aktivieren muss, versteht sich von selbst. Vielen Dank!
@Ingenieur, gar nicht mal so schlecht die Idee mit den Dioden und Kondensatoren. Die Muplexzeit hab ich auch noch ein wenig heruntergestellt. Ach übrigens, der AVR läuft mit 8 Mhz, zur Info.
Man sollte eben so spät Nachts nichts mehr Posten .... :-D Aber ich kann schon wieder nicht einschlafen.... Find ich aber schon bedenklich das die ATmega's beim Reset in Tri-State gehen. Ich ging davon aus das die Ports als Eingang und mit Pullups resetet werden. Freut mich das es jetzt geht @ Tom (Gast). Ich habe allerdings bedenken das du weisst weshalb ?!
Chris D. wrote: > Find ich aber schon bedenklich das die ATmega's beim Reset in Tri-State > gehen. Ich ging davon aus das die Ports als Eingang und mit Pullups > resetet werden. Die coolen 's bei den Plural's scheinen ja manchen Leuten's ganz schön zu gefallen. Leider gibts aber nicht mal bei den Angelsachen's ein 's bei den Plural's. > Freut mich das es jetzt geht @ Tom (Gast). Ich habe allerdings bedenken > das du weisst weshalb ?! Lass uns an deinen Weisheiten's doch weiterhin teilhaben (plenk) ! außerdem stimmts einfach nicht, dass die atmel pins in einen richtigen tristate gehen. schau einfach im datenblatt ins DDRX-register und vor allem an die Reset's-Werte's. Du wirst merken, es sind Eingänge's. Wann genau die Richtungen's für die jeweilige Programmierschnittstelle gesetzt werden, findet sich irgendwo, wo es ums Beschreiben vom Flash geht.
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.