Ein "Sorry" hier für die beiden handgezeichneten Schaltungen, aber das ging so einfach schneller und zum Darstellen, reicht das glaube ich ausreichend. Mein Problem / Anliegen (oder wie man das bezeichnen mag) hängt eigentlich mit einem anderen Thread den ich in Projekte und Code erstellt habe und bezieht sich auf einen Bootloader mit CH32V003. Da aber die Fragestellung grundsätzlicher Natur ist und das auch andere Mikrocontroller betreffen kann (mein Problem hatte ich auch schon mit einem ATtiny serie0), jetzt hier einmal die Frage grundsätzlich. Ich habe folgendes Szenario: Weil ein Reset über einen Reseteingang des Controllers nicht funktioniert, dieser startet nur die User-Software neu, springt aber hier bei nicht in den Bootsektor, kann ein Aktivieren des Bootsektors nur durch ab- und wieder anschalten der Betriebsspannung erfolgen. Hierbei stellt sich das Problem, dass bei abgeschalteter Betriebsspannung der Mikrocontroller an den Pins Rx und Tx an eine USB2UART-Bridge angeschlossen ist. Da das letzte gesendete Bit auf einer seriellen Schnittstelle ein Stopbit ist, bleibt der Logikpegel von seitens der Bridge auf 1. Schaltet man nun die Versorgungsspannung des Controllers ab, so können unterschiedlich USB2UART-Bridges (ich habe CH340, FTDI, PL2303 getestet) unterschiedliche Ströme liefern. Ein Strom in den Rx Anschluss des Controllers kann bei ungeschickten Bedingungen dazu führen, dass dieses dem Controller als Betriebsspannung reicht und er von daher nicht in den Boot-Sektor springt. Zu diesem Zweck habe ich meine "PowerOn" Schaltung in Schaltung 1 (Impuls auf RTS sorgt dafür, dass die Versorgungsspannung des Controllers kurzfristig abgeschaltet wird) dahingehend erweitert, dass der Rx Anschluss des Controllers über einen Widerstand R4 auf logisch 1 gesetzt wird, der aber an der Betriebsspannung des Controllers hängt. Somit wird bei einer seriellen Übertragung die logische 1 über diesen PullUp-Widerstand geliefert. Wird eine 0 gesendet, so ist dieser Pegel der Diode D1 wegen auf ca. 0,7V. Die Datenübertragung funktioniert fehlerlos, bei abgeschalteter Betriebsspannung liegen als Betriebsspannung dann eben diese ca. 0,7V an, was dem Controller nicht als Versorgungsspannung reicht. In Schaltung 2 habe ich einen kleinen Controller verwendet, der den Impuls von RTS aufnimmt und entsprechend die Transistoren T1 und T2 schaltet. Wird hier die Betriebsspannung abgeschaltet, sperrt nicht nur T1, sondern T2 schließt auch die Rückwärts über den Rx Anschluss entstehende Spannung kurz. Hier bleibt dann nur noch eine Versorgungspannung von ca. 0,2V am Controller stehen (als "Reset-Controller hatte ich zum Experimentieren PFS-154 und ATtiny13 verwendet). So, eigentlich (aber nur eigentlich) gefällt mir Schaltung 1 besser, weil sie deutlich weniger Bauteile verwendet und auch weniger Platz auf einer Platine, die ich jetzt doch routen mag benötigt. Allerdings hat sie einen großen Haken (der mir nicht schmeckt): Der Controller hat natürlich noch weitere GPIO Pins. Hier kann es dann durchaus sein, dass am Controller eine Schaltung hängt, die ebenfalls den Controller rückwärts speisen könnte und dann kann es hier wieder sein, dass der Controller von einem GPIO seine Betriebsspannung erhält. In Schaltung 2 besteht dieses Problem nicht, da dort der NPN-Transistor die Betriebsspannung grundsätzlich kurzschließt. Was schmeckt mir daran nicht: Zum einen der Platzbedarf, den ein zusätzlicher SOIC-8 Baustein benötigt (plus Hühnerfutter), sowie die Frage, welchen Controller ich dafür verwenden soll. Wäre das nur für mich alleine, würde ich in Schaltung 2 den PFS-154 wählen, weil er billig ist. Ein ATtiny13 kostet mittlerweile schon mehr als einen Euro, einen ATtiny der serie 0 werde ich morgen ausprobieren. Das es für eine derart kleine Aufgabe des An- und Ausschalten einer Spannung eines Controllers bedarf, der dann ca. 4 bis 5 mal soviel kostet wie der eigentliche Zielprozessor finde ich dann dämlich (s irgendwie habe ich mir in den Kopf gesetzt, dass das ganze auf einer Platine inkl. der Platine nicht mehr als 1,50€ kosten soll ... als Herausforderung eben. Das ganze wäre dann eine Art "Arduino 32nano für Arme") Da das ganze auch als Nachbauanleitung (irgendwann) herhalten soll werde ich hier mit dem PFS-154 nicht so recht warm, weil ich annehme, dass nicht wirklich viele eine Möglichkeit haben, einen PFS-154 zu flashen (gleiches nehme ich allerdings auch für einen ATtiny serie 0 an, der in diesen Bastler / Maker - Kreisen irgendwie scheinbar noch nicht in dem Umfang wie die klassischen AVR's angekommen ist). ------------------------------------------------------- So, und weil viele Augen mehr sehen als 2 hier dann (endlich) die Frage: Wie würdet ihr das lösen, gibt es eine kurze knackige Schaltung (mit Transistoren) die das löst? Vielleicht seh ich vor lauter Bäumen die Lösung nicht !
Angehängte Dateien:
74LVC1G34, 74LVC2G34 oder 74LVC3G34 an die Ein- und Ausgänge? (Ja, ich habe die Einschränkung "mit Transistoren" ignoriert, andererseits sind in den ICs welche drin.)
:
Bearbeitet durch User
Angehängte Dateien:
-
IMG_20250617_232331.png
59 KB -
IMG_20250617_232521.png
76 KB
schwarz auf Packpapierbraun? Ernsthaft? Dann wenigstens editieren ...
Thorsten S. schrieb: > schwarz auf Packpapierbraun? Ernsthaft? > Dann wenigstens editieren ... Das ist kein Packetpapier, es war hier dunkel... aber danke fürs Aufhellen. Das war ein 4H Bleistift und ich mußte da den Kontrast hochdrehen, damit man da sehen kann. Ich habe mir weiter Gedanken zur Schaltung gemacht und bin am Überlegen, ob folgende Simulation in der Realität funktioniert: https://www.falstad.com/circuit/circuitjs.html?ctz=CQAgjCAMB0l3BWcMBMcUHYMGZIA4UA2ATmIxAUgoqoQFMBaMMAKABcRCUAWcYlTgkJ8BVJiAYwheSGG7ccM7Nm4oIk6IUgY8ebmRIFi2QsLBwQAEzoAzAIYBXADZt2nHiGxpBwr1Srq3NDYeKaE3IQYKMR4OnhIUjgR3AQhXghoeMhU1vbOrgDuPiCZxShCUCxFhBXlwjW+kLyQVWUVGBklFS0ATiAdAtidAyDcXlDZcCwA5v2dYwIjyRMtsw2jFuvL-iwASsVgKFnr4Ssb1P5Q0Ait64fHFWAYwr2enX5vAtwWVChoLUURkNFp06pVAaCKngwMIwasQNDfCYETDRqcdgAHFGwqGo5RmM7meDwFgAZ0+IgpxBe4BAbB6DjoeypvnmWUu3wuK2urQyWTA-AoWkpr0RXWEYvuE2UJP2kqO2M4zQmnIS3JufSEAUFXF4AtEk1eus83i1JsuRKm2AwVHW+OK3wCK1awMpfJFLEsoxk5qFVA+AlyjhcMwpjrD6PBFI+rv1UdjgrBcfhYPtYO2lSxScTFXtEAtxJJRVdHxS-u8LSAA
F. P. schrieb: > 74LVC1G34, 74LVC2G34 oder 74LVC3G34 an die Ein- und Ausgänge? (Ja, ich > habe die Einschränkung "mit Transistoren" ignoriert, andererseits sind > in den ICs welche drin.) Du meinst an die Anschlüsse der USB2UART-Bridge? ... da ist dann eine "Fremdversorgung" immer noch möglich
Ralph S. schrieb: > F. P. schrieb: >> 74LVC1G34, 74LVC2G34 oder 74LVC3G34 an die Ein- und Ausgänge? (Ja, ich >> habe die Einschränkung "mit Transistoren" ignoriert, andererseits sind >> in den ICs welche drin.) > > Du meinst an die Anschlüsse der USB2UART-Bridge? ... da ist dann eine > "Fremdversorgung" immer noch möglich 74LVCxG34 an alle relevanten Eingänge, hier also 74LVC1G34 an RX. Gleiche Stromversorgung wie die geschaltete MCU. Fremdversorgung über RX ist dann nicht mehr möglich. Die 74LVC-Serie ist da speziell, die haben keine ESD-Schutzdioden zu VCC. Auch ein paar andere Serien wie z.B. (WIMRE) 74AHC haben solche anders geschützten Eingänge.
:
Bearbeitet durch User
Bastelprojekt oder Serienprodukt? Im ersten Fall pack einen 100k Widerstand in die RXD-Leitung und du bist fertig.
Da UART im Ruhezustand auf H liegt, würde ich vom CH32V003 GND mit einem FET schalten. Gruß Jobst
Ralph S. schrieb: > Das ist kein Packetpapier, es war hier dunkel An die Lichtverhältnisse passt sich eine Kamera über Belichtungszeit und Verstärkung an. Wie soll es sonst funktionieren, dass man damit sowohl draußen bei Sonnenschein als auch in Innenräumen mit erheblich geringeren Beleuchtungsstärken photographieren kann. Bei zu wenig Licht fängt eine Kamera erstmal kräftig an zu rauschen - tut sie bei dir aber nicht. Falls sie allerdings nicht erkennt, dass der Gegenstand ein weißes Blatt Papier ist, weil der Automatik die Orientierung fehlt, nimmt sie ein mittelhelles Objekt an (Standard: 18% Reflektivität) und man muss manuell eingreifen, damit ein weißes Blatt Papier auch in der Aufnahme als helles Objekt dargestellt wird .
Hermann K. schrieb: > Bastelprojekt oder Serienprodukt? > > Im ersten Fall pack einen 100k Widerstand in die RXD-Leitung und du bist > fertig. Mit Widerständen in der Leitung hatte ich schon versucht gehabt. Danach hatte ich Schaltung 1 gemacht. Bei 100k war die Datenübertragung nicht mehr sicher. Jobst M. schrieb: > Da UART im Ruhezustand auf H liegt, würde ich vom CH32V003 GND mit einem > FET schalten. Den GND Schalten ist nie eine gute Idee (mit N-Channel dann). Grundsätzlich wollte ich statt bipolarer Transistoren FET nehmen, aber ich konnte es schier nicht glauben: N-Channel habe ich massenhaft und P-Channel habe ich nur ein paar wenige Leistungstransistoren. Bei der nächsten Elektronikbestellung (die aktuelle ist noch nicht einmal geliefert) steht das schon auf dem Zettel.
Ich finde, das handgezeichnete Schaltpläne völlig OK sind. Isoliert betrachtet gefällt mir Schaltung 1. Deine Bedenken zur parasitären Speisung durch weitere externe Beschaltung dazu sind völlig korrekt. Das gleiche "Problem" haben alle gängigen Mikrocontroller Boards (außer ESP866, weil dessen ESD Schutz anders arbeitet). Die zweite löst das Problem nicht, und ich sehe auch keine praktikable generische Lösung am Horizont. Für beide Schaltung gilt, dass sie den uC außerhalb seiner Spezifikation betreiben, wenn seine Stromversorgung gekappt wird währen die externe Peripherie noch Spannung an I/O Pins anlegt. Irgenwann wird der uC deswegen kaputt gehen. Die internen ESD Schutzdioden können durchbrennen, kurz danach gehen I/O Pins bei kleinster Überspannung (z.B beim Anfassen) kaputt. Der parasitäre Strom kann einen Latch-Up Effekt auslösen (Kurzschluss innerhalb des IC). Also wenn du offen für nicht speziell angepasste Peripherie sein willst, dann lass es bleiben. Dann muss der Benutzer halt manuell das Netzteil aus schalten. Damit kann man leben. Wenn du alle Pins vor Rückspeisung schützen kannst, dann mache das. Aber wirklich mit allen Pins.
Nicht zu Ende gedacht, war abgelenkt.. Rx über einen NPN schalten?
:
Bearbeitet durch User
Ralph S. schrieb: > Weil ein Reset über einen Reseteingang des > Controllers nicht funktioniert, dieser startet nur die User-Software > neu, springt aber hier bei nicht in den Bootsektor Das ist aber ein seltsamer µC. Ich kenne nur solche, wo externer Reset und Power-on identisch reagieren. Es gibt dann noch solche, die per Fusebit den externen Reset disablen können, um einen zusätzlichen IO-Pin zu erhalten.
Normalerweise sterben die Schutzdioden nicht so, daß sie hochohmig werden, sondern sie werden zum glatten Durchgang. Ich habe bei einem AVR mal einen Portpin zerschossen und der Rest des µC hat das scheinbar klaglos überstanden (aber keine Ahnung wie zuverlässig der Rest des µC dann auf lange Sicht noch ist). Auf dem kaputten Pin konnte man dann prima eine interne 1W-Heizung aktivieren wenn man ihn auf HIGH schalten wollte. Sehr gut für Deep-Space-Missionen (wobei ich nicht denke, daß der µC die Strahlung lange übersteht wenn man ihn nicht dagegen härtet), im gemäßigten Klima auf der Erde eher unpraktisch.
Ralph S. schrieb: > bezieht sich auf einen Bootloader mit CH32V003. Nö, es bezieht sich allein auf Deinen ganz speziellen Bootloader. Warum verlinkst Du ihn dann nicht? Beitrag "CH32V003: serieller Bootloader" Das Problem allgemein ist ja schon gegessen. Entweder eine Diode mit Pullup oder ein Transmission Gate, was ohne VCC in tristate geht. Oder ein Logik-Gate, was Vin > VCC erlaubt. Solche Trenner-ICs bei VCC = 0V habe ich schon mal gesehen, aber die dummen KI-Suchmaschinen finden sowas zum Verrecken nicht mehr, sondern nur ein Patent und nen Haufen anderen unpassenden Schrunz.
:
Bearbeitet durch User
Ganz allgemein erstellt man einen Bootloader so, daß er unabhängig von der Resetquelle eine Bedingung abtestet, um im Bootmodus zu bleiben oder die Applikation zu starten. Das kann ein IO-Pin sein oder das Ablaufen einer Wartezeit, in der ein Kommando empfangen werden muß. Jede Resetquelle führt erstmal immer dahin oder auch ein API-Call aus der Applikation heraus.
Ich mache es oft so, dass ich den UART mit einem 74LVC2G241 isoliere (der unterstützt Partial Power Off und bringt 5V Toleranz mit). https://www.ti.com/product/de-de/SN74LVC2G241 Zum Schalten der Versorgungsspannung würde ich einen Load Switch wie TPS2041B/TPS2051B nehmen. Der bringt noch Überstromschutz mit, was nie eine schlechte Sache ist. Gibts auch im SOT23-5 Package. https://www.ti.com/product/de-de/TPS2041B fchk
Bei meinen AVR-Boards, mache ich es immer so, daß die Applikation einen Resetbefehl erhält und darauf den Watchdog auf 16ms setzt und in eine Endlosschleife läuft. Der Bootloader löscht vor dem ersten Page-Erase ein Byte im EEPROM, damit er weiß, die Applikation ist ungültig. Wird das Flashen vorzeitig abgebrochen, bleibt er also immer im Bootmodus. Die VCC zu schalten, habe ich noch nirgends implementiert.
Alexander schrieb: > Würde nicht ein Pull-down reichen? Absolut korrekte Antwort: JEIN. In manchen Fällen genügt der PullDown eben nicht! Peter D. schrieb: > Das ist aber ein seltsamer µC. > Ich kenne nur solche, wo externer Reset und Power-on identisch > reagieren. > Es gibt dann noch solche, die per Fusebit den externen Reset disablen > können, um einen zusätzlichen IO-Pin zu erhalten. Na ja, für mich war das auch "neu" (kannst du aber auch gerne im DaBla für CH32V003 nachlesen). Ich habe zwar den externen Reset gedisabled (hier heißt das dann nicht Fusebit sondern Optionbyte), aber das habe ich erst gemacht, als mir klar war, dass ich mit dem Resetpin nichts mehr anfangen konnte. Einen Reset über einen Reset-Pin wäre mir am liebsten gewesen.
Peter D. schrieb: > Ganz allgemein erstellt man einen Bootloader so... > Jede Resetquelle führt erstmal immer dahin Das hätte der Ralph ja auch gerne so, aber da der Reset Pin im Gegensatz zu deiner Idealvorstellung keinen richtigen Reset auslöst, hat er keine andere Wahl, als einen Workaround zu suchen.
:
Bearbeitet durch User
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.