Hallo! Nach langer Zeit wage ich mich mal wieder an ein AVR-Projekt, also wer weiß, vielleicht ist die Lösung hier ganz offensichtlich? Bestimmte Details muss ich vorerst auslassen; ich kann aber wohl ein Minimalbeispiel vorbereiten, falls nötig. Ich habe einen ATmega644 mit 20MHz Quarz, der mit USART + Timer ein DMX512-Signal generiert. Timing läuft über Interrupts, also noch reichlich Reserven. Gleichzeitig möchte ich ein DMX-Signal einlesen; dazu habe ich das ausgehende Signal einfach wieder dekodiert und an einen PCINT angeschlossen, mit dem ich in Kombination mit einem weiteren Timer auch die DMX-Break (Startsignal) zuverlässig erkenne. Sobald ich aber das Signal an den RXD-Pin gebe, hängt sich der uC einfach auf, das Verhalten wird komplett erratisch. Mit dem Oszi kann ich sehen, dass die ersten paar DMX-Bytes noch gesendet werden, nach 1-2 Sekunden messe ich dann nur noch einen konstanten Pegel. Ziehe ich die Verbindung zum RXD heraus, geht die Übertragung manchmal wieder korrekt los. Nach Reset ist alles wieder in Ordnung … so lange RXD nicht verbunden wird. Ideen? Gruß Erich
Du solltest deine Empfangsroutine erstmal mit einem externen DMX Signal testen. Die kannst du dann auf Laufzeitverhalten abklopfen und Zeit freischaufeln für den Sender.
Jens M. schrieb: > Interrupt-Deadlock? Was ist das bzw. wie entsteht das? > Ohne Code ist das schwer zu sagen. Ist pastebin okay? main programm: https://pastebin.com/zsvKe545 dmx header: https://pastebin.com/yFLTTjNU dmx implementation: https://pastebin.com/bAgwxfqZ Gruß Erich
c-hater schrieb: > Poste den Code. erich schrieb: > Ist pastebin okay? > main programm: https://pastebin.com/zsvKe545 > dmx header: https://pastebin.com/yFLTTjNU > dmx implementation: https://pastebin.com/bAgwxfqZ
'pastebin'? Ohne mich. Aber: Da der ATmega644 nur einen einzigen UART hat, stellt sich die Frage: ist der zweite UART in Software realisiert oder handelt es sich beim Controller um einen ATmega644Px?
PS: Falls die Antwort "weder - noch" sein sollte, wäre die Sache klar: es wird beim zweiten UART-Interrupt in einen Bereich der Interrupttabelle gesprungen, der beim ATmega644 gar nicht vorhanden ist.
erich schrieb: > Was ist das bzw. wie entsteht das? Das ist wenn sich an einer Rechts-Vor-Links-Kreuzung 4 nette Fahrer treffen: Jeder wartet, das der rechts von ihm losfährt. Bei dir evtl. - Der Sender wartet das was passiert - Der Empfänger wird ausgelöst - E wartet bis S aufhört - S kann nicht aufhören, weil das Programm im E läuft - "nein, sie zuerst!"
S. Landolt schrieb: > 'pastebin'? Ohne mich. Ebenfalls ohne mich. > Aber: Da der ATmega644 nur einen einzigen UART hat, stellt sich die > Frage: ist der zweite UART in Software realisiert Welche zweite UART? DMX ist unidirektional, man kann also für eingehendes und ausgehendes DMX dieselbe UART verwenden. Nur der schöne Trick mit der Änderung der Baudrate zur einfachen Generierung des Frameheaders kann dann natürlich nicht angewandt werden, weil dadurch natürlich der Receiver gestört werden würde. Um dieses Problem hat er wohl mittels Timer und PCINT herumgearbeitet. Ist OK und kein Ding, wenn man weiss, was man tut.
S. Landolt schrieb: > der zweite UART Es gibt nur einen. An TXD0 wird das Signal generiert und an RXD0 soll es empfangen werden. Ist das das Problem? Kann die USART kein vollduplex? Diverse Hardware-Fehlerquellen da kann ich ausschließen; selbst wenn ich das Signal durch einen Repeater nach RXD füttere, ergibt sich dasselbe Problem. S. Landolt schrieb: > 'pastebin'? Ohne mich. Was auch immer jetzt an pastebin falsch ist … aber okay, ist ein freies Land. Gruß Erich
Beitrag #6714184 wurde von einem Moderator gelöscht.
> Welche zweite UART? Schade - war eine schöne Theorie. > Was auch immer jetzt an pastebin falsch ist Ich klicke nicht auf jeden angebotenen Link. Und das Hochladen der Dateien hier direkt ins Forum ist ja auch einfach genug. > … aber okay, ist ein freies Land. Richtig! (glauben&hoffen wir zumindest) Ein Blick nach unten zeigt: "Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang".
S. Landolt schrieb: > Ich klicke nicht auf jeden angebotenen Link. Und das Hochladen der > Dateien hier direkt ins Forum ist ja auch einfach genug. Gut, hab ich dann auch mal hinbekommen. Hat ja auch keine Nachteile. Also, außer, dass zumindest bei mir ab Zeile 100 die Codeansicht kaputt geht, weil die Spalte für Zeilennummer zu schmal ist. Und, dass die Codeansicht halt nicht für .hpp-Dateien verfügbar ist, obwohl das keine unübliche Endung ist. Ach, und man muss das dann eben auch 1:1 als Datei haben … wenn ich nicht unbedingt die Header-Kommentare mitposten will, weil ich mich nicht selbst doxxen will, muss ich halt nen Umweg nehmen. Aber sonst keine Nachteile, erst recht keine, die nach vor 10 Jahren gelösten Problemen aussehen. /s SCNR, Erich
erich schrieb:
default:
// ignore pin change
this->rx_state = DMX_BREAK;
break;
Das ist wohl Unsinn. Der Kommentar sagt "ignore", du aber cancelst den
Empfang? Und zwar obendrein ohne jede weitere Maßnahme an der Hardware?
Insgesamt scheint es mir da noch einige Unstimmigkeiten mehr in der
statemachine zu geben, insbesondere was die Steuerung der
Hardwarekomponenten und ihrer Interruptfreigaben angeht.
Außerdem ist die Umsetzung grundsätzlich recht ineffizient. Es ist nicht
sehr sinnvoll, Ereignisse, die schon fein getrennt über verschiedene
Vektoren hereinkommen, erst zusammenzuwerfen, um dann eine zentrale
Routine wieder aufdröseln zu lassen, wo sie eigentlich ist. Naja, ca.
500 Takte/Byte bei paralleler Vollast, könnte noch reichen, trotz der
Ineffizienz. Genaueres kann man nur sagen, wenn man sich den
Assemblercode ansieht.
c-hater schrieb: > erich schrieb: [...] Nochwas: Es fehlt für den Sender ein weiterer Status, ich würde ihn DMX_EOT nennen. Und nein, das ist noch nicht DMX_BREAK, im ungünstigsten Fall ist man 21 Bitlängen vor DMX_BREAK. TIPP: TXCIE/TXCIF benutzen!
Randbemerkungen eines DMX-Laien (also Irrtum vorbehalten): - mir ist unklar, wie je rx_state==DMX_START erreicht wird - RX läuft ständig mit - sollte das nicht erst mit DMX_MAB eingeschaltet werden? - fehlt da nicht ein '-1'?:
1 | OCR0A = PHYS_OCRVAL; |
2 | OCR2A = PHYS_OCRVAL; |
- hier wird beim BREAK der ganze PORTD geschrieben!?:
1 | PORTD = (0 << PD1); |
2 | PORTD = (1 << PD1); |
- rein gefühlsmäßig hätte ich 87 genommen:
1 | if (this->rx_elapsed_us < 88) {
|
Danke für die Hinweise, ich werde mal erst ein umfangreiches refactoring machen, melde mich alsbald wieder. Gruß Erich
Hallo! Mein refactoring ist größtenteils durch … und ich bin einen Schritt weiter, denn ich denke, es liegt nicht am Code. Siehe Versuchsbeschreibungen. Break detection habe ich nun via Timer1/InputCapture gelöst; zum Start jedes DMX-Frame toggle ich eine Break-LED. Habe auch für einen Mega88P kompiliert, mit dem ich nun ein Testsignal generiere. ## Versuchsaufbau 1/2 ## Beide uC, Mega644 und Mega88P sind als reine Sender programmiert (TXEN=1, RXEN=0). Mit Oszilloskop sehe ich wie erwartet bei beiden uCs ein valides DMX-Signal an TXD. ## Versuch 1 ## Verbinde ich Mega88P.TXD mit Mega644.ICP, blinkt die Break-LED wie erwartet. Verbinde ich Mega88P.TXD mit Mega644.RXD, stürzt der Mega644 ab: Erratischer Output an TXD, dann fällt die Break-LED aus. Der Mega644 springt erst wieder an, wenn das Signal an RXD weg ist und RESET gepulst wurde. ## Versuch 2 ## Verbinde ich Mega644.TXD mit Mega88P.ICP, blinkt die Break-LED wie erwartet. Verbinde ich Mega644.TXD mit Mega88P.RXD, läuft wie erwartet alles weiter, kein Absturz. ## Versuchsaufbau 3 ## Mega88P ist als reiner Sender programmiert (TXEN=1, RXEN=0), beim Mega644 ist nur ICP programmiert (TXEN=RXEN=0). Mit Oszilloskop sehe ich wie erwartet beim Mega88P ein valides DMX-Signal an TXD. ## Versuch 3 ## Verbinde ich Mega88P.TXD mit Mega644.ICP, blinkt die Break-LED wie erwartet. Verbinde ich Mega88P.TXD mit Mega644.RXD, läuft wie erwartet alles weiter, kein Absturz. Für mich stellt sich nun die Frage, ob a) das eine generelle Limitierung des Mega644 ist? b) ich eine veraltete Version des Chips habe? Meiner ist PDIP40, Markierung "ATMEGA644 20PU 1053" c) mein Mega644 schlicht defekt ist? Gruß Erich
erich schrieb: > Versuch Nr 3, der vorherige Post darf dann weg … War doch gar nicht schlimm ... erich schrieb: > Gut, hab ich dann auch mal hinbekommen. Hat ja auch keine Nachteile. Eigentlich nur Vorteile: Der Anhang ist genauso lange verfügbar, wie der Thread.
Programm bleibt geheim, Erich? Na gut, dann nächster Vorschlag: e) Hardware Schließlich haben die beiden Controller unterschiedliche Gehäuseformen, folglich können die Anschlüsse, selbst auf einem Steckbrett, nicht dieselben sein.
S. Landolt schrieb: > Programm bleibt geheim, Erich? Nö. Aber meiner Meinung nach irrelevant. Ich mache nachher mal ein einzelnes c-file für den mega644 fertig, bei dem das Problem auftritt.
Was glauben Sie, was ich in den letzten Jahrzehnten alles für irrelevant hielt. Wie wäre es mit einem einfachsten Echo-Programm für den ATmega644, also Zeichen auf RX lesen und gleich wieder auf TX ausgeben, kontrolliert vom PC oder notfalls vom ATmega88?
Hallo! Hier ein minimaler Code für dmx break detection via ICP an meinem mega644. ## Aufbau ## ... die Schaltung ist das wohl Banalste überhaupt, aber lieber zu viele Details als zu wenig. Der Teil mit dem Mega644 sieht so aus: - ATMEGA644 20PU 1053 - VCC an 3.3V, 100nF nach Masse - AVCC nach VCC - RESET über Taster nach Masse - 20MHz Quarz zwischen XTAL0/1, je 18pF nach Masse - je 10k pullup res an RESET und PD6(ICP) nach VCC - irgendwo an PORTC eine LED mit Vorwiderstand nach Masse - Programm siehe main_644.c (wohlgemerkt, den UART habe ich nicht einmal angefasst!) Außerdem braucht es irgendetwas, das ein 250kHz UART Signal ausspuckt, in meinem Fall ein m88p. Der Teil sieht so aus: - ATMEGA88PA-PU 1404 - VCC an 3.3V, 100nF nach Masse - AVCC nach VCC - RESET über Taster nach Masse - 20MHz Quarz zwischen XTAL0/1, je 18pF nach Masse - je 10k pullup res an RESET und PD1(TXD) nach VCC - Programm siehe main_88p.c ## Versuch ## Eine Brücke von Mega88P.TXD nach Mega644.ICP wird gesteckt. Wie erwartet, leuchtet die LED am 644 dabei augenscheinlich konstant; wird nun aber mit einem PWM-Signal (UART) betrieben. Oskar das Oszilloskop bestätigt dies. Eine weitere Brücke von Mega88P.TXD nach Mega644.RXD wird gesteckt. Wider jegliche Vernunft beginnt die LED am 644 wild zu flackern und auch Oskar wird recht unruhig. In der Ferne Sirenen. Also: Entweder mache ich mit dem 644 etwas grob falsch, oder der ist hin. Gruß Erich
erich schrieb: > Hier ein minimaler Code für dmx break detection via ICP an meinem > mega644 Falsch … einfach nur ein kleiner Code, um meinen mega644 zu crashen.
Angehängte Dateien:
-
speed_grades.png
62 KB
Also ich übertakte auch hin&wieder, aber 20 MHz bei 3.3 V könnte zu viel sein.
S. Landolt schrieb: > 20 MHz bei 3.3 V könnte zu viel sein Oh. Oha. Ich würde ja behaupten, das wäre eine von den Sachen, die ich in der Zwischenzeit vergessen habe, da ich nichts mit AVRs gemacht habe (siehe Eingangspost). Aber das ist schlicht und einfach neu für mich, dass es je nach Spannung verschiedene zulässige Taktraten gibt. Auf die Idee wäre ich allein auch nie gekommen, vielen Dank für den Hinweis! Schaltung umgestellt, 3V3-Teil vorerst entfernt und AVRs auf 5V gelegt. Mag sein, dass die jetzt zufriedener sind, aber mein mega644 verhält sich leider unverändert. Kann ich nun von einem Chip-Defekt ausgehen? Gruß Erich
Tja, an dem Programm kann ich nichts Auffälliges entdecken, also vermute ich die Hardware. Und wenn die Umgebung des Pins 14, ATmega644.RXD0 (beachten Sie die Nachbarschaft zu XTAL1), in Ordnung ist, dann muss es wohl der Controller selbst sein. Zwar habe ich in den über zwei Jahrzehnten AVR8 so etwas noch nicht gesehen, aber man lernt ja nie aus.
Angehängte Dateien:
-
IMG_20210607_191817.jpg
240 KB
Hier nochmal zur letzten Absicherung ein Bild vom breadboard. Der Quarz hängt zwar etwas schief da drin, aber der 644 hat Takt. Oberer gelber Draht ist txd, Unterer ist ICP. Gruß Erich
erich schrieb: > Hier nochmal zur letzten Absicherung ein Bild vom breadboard. Da fehlt mindestens ein Bypass-Kondensator (zwischen AGND und AVCC). > Der Quarz hängt zwar etwas schief da drin, aber der 644 hat Takt. Das allein bedeutet noch nicht sehr viel. Poste mal die Fuse-Settings.
Angehängte Dateien:
c-hater schrieb: > Da fehlt mindestens ein Bypass-Kondensator (zwischen AGND und AVCC). Der 644 hat zwar kein eigenes GND, aber ich kann ja auf der rechten Seite auch mal einen 100nF mit dazutun, schadet bestimmt nichts … Verhalten unverändert, Signal geht kaputt. c-hater schrieb: > Fuse-Settings. LF, HF, EF = 0xCF, 0xDF, 0xFF. Auch als Anhang. Gruß Erich
Vorab: Ferndiagnosen von Hardware liegen mir nicht, ich muss die Dinge vor mir haben. Ich sehe das gelbe Kabel auf PD1 - heißt das, dass dieses merkwürdige Verhalten auch hier, also nicht nur bei PD0 auftritt? Und es ist noch das 'Mitternachtsprogramm', das sowohl PD0 als auch PD1 auf dem Defaultwert 'Eingang' lässt?
c-hater schrieb: > Ändere mal LF auf 0xF7 das … funktioniert. Entschuldigung, aber … wat*? "Full Swing Oscillator" hatte ich noch nie als Fuse genutzt. Wieder was gelernt. Danke, Leute! Gruß Erich ~~~ *) "wat" ist unter https://www.destroyallsoftware.com/talks/wat herrlich erklärt. Wer lieber YouTube mag, nimmt https://www.youtube.com/watch?v=3se2-thqf-A
erich schrieb: > das … funktioniert. Entschuldigung, aber … wat*? > "Full Swing Oscillator" hatte ich noch nie als Fuse genutzt. Man könnte alternativ natürlich auch den Quarz korrekt anpassen. Dann funktioniert's sicherlich auch mit den ursprünglichen Fuses. Diese Fullswing-Sache ist eigentlich nur der Nachweis, dass der Quarz falsch angepasst ist. Nicht komplett falsch, aber eben weit genug weg vom Optimum, um bei geringem Energieeinsatz keine saubere Schwingung mehr zu produzieren.
c-hater schrieb: > Nachweis, dass der Quarz falsch angepasst ist Okay. Gemeint sind die Kondensatoren? Ich hab zwar eine Ahnung, wie man die ausrechnen kann, aber leider habe ich zu meinen Quarzen im Breadboard-Prototyp kein Datenblatt gespeichert, als ich ihn gekauft habe :/ Spaßeshalber mal ein paar andere Werte getestet, meistens gleiches Ergebnis, mit 33pF hatte ich erst gar keinen richtigen Takt mehr. Wahrscheinlich hat mein Steckbrett eh noch parasitäre Kapazitäten, die mir in die Suppe spucken. Wenn ich ein Platinendesign dafür mache, kann ich ja alles etwas genauer kontrollieren. Und bis da hin reicht es wohl auch aus, die "Full Swing" fuses drin zu lassen. Gruß Erich
Angehängte Dateien:
> Und bis da hin reicht es wohl auch aus, > die "Full Swing" fuses drin zu lassen. Wobei sich die Frage stellt, weshalb überhaupt der 'Low Power Crystal Oscillator' gewählt wurde; erstens ist der für 20 MHz nicht spezifiziert, und zweitens erscheint mir die Stromersparnis nicht gravierend:
1 | 'FF':low 'F7':full |
2 | loop 13.38 14.99 |
3 | idle 3.72 5.34 |
In mA, gemessen an einem ATmega644P-20PU (0741) mit 20 MHz bei 5.0 V.
S. Landolt schrieb: > erscheint mir die Stromersparnis nicht > gravierend: >
1 | > 'FF':low 'F7':full |
2 | > loop 13.38 14.99 |
3 | > idle 3.72 5.34 |
4 | > |
Im Idle mal eben 30% mehr Energie zu sparen und im Busy auch immerhin noch 10% erscheint dir nicht attraktiv zu sein? Ich finde das durchaus attraktiv. Natürlich für die passende Anwendung. Aber auch bei jeder Anwendung ohne besondere Anforderungen an die Energiesparsamkeit spricht eigentlich fast nichts dagegen, diese Energie zu sparen. Gegenindikation wäre eigentlich nur der Betrieb in einer bekanntermaßen stark störungsverseuchten Umgebung. Da wäre natürlich der Fullswing zu bevorzugen.
erich schrieb: > Spaßeshalber mal ein paar andere Werte getestet, meistens gleiches > Ergebnis, mit 33pF hatte ich erst gar keinen richtigen Takt mehr. Klar, bei einem Steckbrett braucht man nach oben eher nicht zu probieren, sondern nur nach unten. > Wenn ich ein Platinendesign dafür mache, kann ich ja alles etwas genauer > kontrollieren. Und bis da hin reicht es wohl auch aus, die "Full Swing" > fuses drin zu lassen. Jepp.
> 10% erscheint dir nicht attraktiv
Ich kenne mich mit DMX nicht aus, kann/soll das ein batteriebetriebenes
Gerät werden? Netzgespeist sind mir 8 mW völlig egal.
S. Landolt schrieb: > Netzgespeist sind mir 8 mW völlig egal. Mein Gott, noch die was von der Klimakrise gehört? Auch Kleinvieh macht Mist. Wenn es genug davon gibt. Wenn man praktisch für lau 8mW bei jedem Stück sparen kann, dann tut man das. Die korrekte Quarzanpassung muss (zumindest: sollte) man doch sowieso machen...
> 8 mW ... Klimakrise
Das ist jetzt aber nicht Ihr Ernst, c-hater, oder? Falls doch, kann ich
Sie, pardon, nicht mehr für voll nehmen. Allein die Diskussion hier
steht doch schon in keinem Verhältnis mehr dazu. Selbst wenn das Gerät
rund um die Uhr liefe, wären es im Jahr zusätzliche 70 Wh, keine 3 ct -
wie hoch ist Ihr persönlicher Strombedarf?
Mal ganz abgesehen davon, dass Erich offensichtlich keine
Serienproduktion starten will.
S. Landolt schrieb: >> 8 mW ... Klimakrise > > Das ist jetzt aber nicht Ihr Ernst, c-hater, oder? Doch, absolut. > Falls doch, kann ich > Sie, pardon, nicht mehr für voll nehmen. Das sei dir gegönnt. > Allein die Diskussion hier > steht doch schon in keinem Verhältnis mehr dazu. Selbst wenn das Gerät > rund um die Uhr liefe, wären es im Jahr zusätzliche 70 Wh, keine 3 ct - > wie hoch ist Ihr persönlicher Strombedarf? Das war überhaupt nicht das Thema. Das Thema war: wenn ich praktisch ohne zusätzliche Kosten (12pF kosten genausoviel wie 22pF) Energie sparen kann (und seinen es auch nur lächerliche Beträge), sollte ich diese Energie dann sparen oder nicht? Aus meiner Sicht würden nur Idioten da sagen: nein, mache ich nicht. > Mal ganz abgesehen davon, dass Erich offensichtlich keine > Serienproduktion starten will. Das hat er wo genau verlauten lassen? Wie auch immer, Erich hat das Thema aufgeschoben bis zum endgültigen Layout. Das halte ich für durchaus sinnvoll und dem Problem angemessen und ich habe mich auch entsprechend geäußert.
S. Landolt schrieb: > Das ist jetzt aber nicht Ihr Ernst, c-hater, oder? Falls doch, kann ich > Sie, pardon, nicht mehr für voll nehmen. 8mW mögen sicher nicht groß zur Klimakrise beitragen, aber ich sehe es auch so, dass jedes bisschen Energie, das ohne Einbußen eingespart werden kann, auch gespart werden sollte. Und das prinzipiell; nicht erst ab einem Schwellwert X. S. Landolt schrieb: > erstens ist der für 20 MHz nicht spezifiziert Das finde ich hier viel wichtiger; für einen Chip, der bei 20MHz kein low-power spezifiziert, ist also der full-swing grundsätzlich zu bevorzugen. S. Landolt schrieb: > offensichtlich keine Serienproduktion Vielleicht? Vielleicht nicht? Wo war das "offensichtlich"? :D Gruß Erich
c-hater schrieb: > Das Thema war: wenn ich praktisch > ohne zusätzliche Kosten (12pF kosten genausoviel wie 22pF) Energie > sparen kann (und seinen es auch nur lächerliche Beträge), sollte ich > diese Energie dann sparen oder nicht? d'accord
erich schrieb: > 8mW mögen sicher nicht groß zur Klimakrise beitragen, aber ich sehe es > auch so, dass jedes bisschen Energie, das ohne Einbußen eingespart > werden kann, auch gespart werden sollte. Und das prinzipiell; nicht erst > ab einem Schwellwert X. Ganz genau so sehe ich das auch.
an Erich:
> ... keine Serienproduktion ... Wo war das "offensichtlich"?
Das ergibt sich aus Ihrem Kenntnisstand, es bestehen doch ganz
erhebliche Lücken. Von WEEE, CE und was sonst noch alles mal abgesehen.
Was nun aber die "Klimakrise" betrifft: Rechnen Sie für sich (oder uns
vor), wie lange Ihr Gerät im Jahr laufen wird und was diese zusätzlichen
8 mW dann bedeuten. "Keine zusätzlichen Kosten ... ohne Einbußen": Sie
gehen sehr großzügig mit Ihrer Lebenszeit um, wenn ich alleine mal diese
Diskussion hier betrachte, die seit fast einer Woche läuft. Wer an
solchen Nebensächlichkeiten klebt, verliert den Überblick.
Im übrigen ist der 'zusätzliche Nutzen' der 8 mW die schon mehrfach
erwähnte Störsicherheit. Vielleicht werden Sie daran beim ersten harten
Einsatz Ihres DMX-Gerätes denken.
ich wünsche frohes Schaffen und verabschiede mich
PS:
> ... verliert den Überblick
Da fällt mir, tagesaktuell, der CEO eines großen Automobilkonzerns ein,
der höchstpersönlich Spaltmaße nachmisst.
aber damit bin ich endgültig weg ...
an Erich: Um noch etwas Konstruktives nachzutragen: wie wäre es mit dem Versuch, mit einem Systemtakt von 10 MHz auszukommen? Hätte auch den Vorteil, zu Ihren ursprünglichen 3.3 V zurückkehren zu können. Ich habe mal obige Tabelle ergänzt:
1 | 'FF':low 20MHz 'F7':full 20MHz 'F7':full 10MHz |
2 | 5.0V 5.0V 3.3V |
3 | loop 13.4mA: 67.0mW 15.0mA: 75.0mW 4.8mA: 15.8mW |
4 | idle 3.7mA: 18.5mW 5.3mA: 26.5mW 1.7mA: 5.6mW |
Wie Sie sehen, erscheinen die gestern diskutierten 8 mW noch vernachlässigbarer, als sie es ohnehin sind. (Und ja, auch ich habe hierfür schon zu viel meiner Lebenszeit investiert; aber ich buche es unter 'Erkenntnisgewinn')
Alter Laptop mit Serieller Schnittstelle, Serielles 9pol. T-Stück, DOS, Norton Commander, der hat ein Terminal Programm das man super als Schnüffelstück verwenden kann. Man sieht dann alles in Echtzeit, haben ich früher gern für Reverse Engineering Versuche verwendet.
> Da fällt mir, tagesaktuell, der CEO eines großen Automobilkonzerns ein, > der höchstpersönlich Spaltmaße nachmisst. > > aber damit bin ich endgültig weg ... Mehr konnte er eh nicht, Terror mit dem Messschieber, alles weitere war zu kompliziert! Wer solch einen Chef hat braucht viele Freunde die einen regelmäßig therapieren und vorm .... abhalten!
c-hater schrieb: > Mein Gott, noch die was von der Klimakrise gehört? Auch Kleinvieh macht > Mist. Leg ein weißes Blatt Papier vor die Tür. Das reflektiert mehr Sonnenenergie in den Weltraum, als du mit solchem Kleinkram einsparen kannst. Zur Reduzierung der Erderwärmung ist das deutlich effektiver ;-)
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.