Guten Tag allseits ich habe eine ganz einfache Aufgabenstellung zu lösen (für die im Grunde ein 2 MHz 6802 ausreichen würde) die aber im Ergebnis so billlich wie irgend möglich werden soll (seufz - ich weiss - kein Kommentar hierzu erforderlich - ist halt so) Die Hardwareentwickler sagen Multilayer ist gesetzt, sonst kommen wir eh nicht durch die EMV. Ich denke: Zweilagig würde von den schaltungstechnischen Anforderungen wirklich ganz locker ausreichen. Gute EMV ist dabei zwingend, weil der VDE hier eine tragende Rolle mitspielt (9kW) Hat jemand einen Vorschlag für einen einigermaßen aktuellen und sicher langzeit erhältlichen (jünstigen) Controller, der nicht gleich wieder losstrahlt wie Sau? .. und den man mit aktuellen Werkzeugen und Schnittstellen (zB SWD) programmieren und idealerweise auch debuggen kann? also zB einen Cortex M0, den man auch noch weiter effektiv heruntertakten kann? (es nutzt mir nix wenn da die Takt-PLL wild vor sich hin schwingt) Danke vorab für Tipps/Ideen!
Der Controller selber wird nicht für die schlechte EMV verantwortlich sein, sondern hauptsächlich das Konstrukt was du aus ihm baust. Daher ist es auch so gut wie völlig egal welchen du nimmst. Mir fallen Spontan die Cortex-M0's von STM32 und XMC ein...
So billig wie möglich und dann Flash-Controller mit Debugging, SWD und den Kram? Padauk OTP CPUs kosten nur ein paar Cent und mittlerweile gibts da ganz gute Werkzeuge (OpenPDK, SDCC usw.)
Da fallen mir spontan mehrere Dinge ein: Nimm einen Controller, der einen hinreichend genauen internen Taktgenerator hat. Gibt es einen solchen nicht, dann einen der zumindest aus einem 32768 Hz Quarz einen genauen Takj ableiten kann. Nimm einen Controller, bei dem die Slewrate der Ausgaenge konfiguriert werden kann. Wenn man nur max. 2 MHz ansteuern muss, braucht es keine 2 ns Flanken... Spendiere dem Controller wirklich ausreichende Abblockung. Im Zweifel vom (unbestueckten) Controller aus, mal den Impedanzverlauf in fie Schaltung hinein messen! Der Verlauf sollte flach wie eine norddeutsche Landstrasse sein. Filtere die Betriebsspannungen nochmals breitbandig ueber Pi-Filter Das gilt natuerlich auch fuer alles, was an Peripherie am Contoller haengt. Viel Erfolg!
Ulrich B. schrieb: > es nutzt mir nix wenn da die Takt-PLL wild vor > sich hin schwingt Niemand zwingt Dich, die PLL einschalten zu müssen. Du kannst einfach den Takt wählen, der für die Aufgabe ausreichend ist.
> zB einen Cortex M0
Ein STM32F030/F05x/... sollte wohl passen.
Aber denke auch an den Rest.
Der Controller kann dabei durchaus intern mit vollem Takt laufen.
Der strahlt naemlich am wenigsten.
Die Peripherie kann man dann mit einem skalierten Takt betreiben,
wenn es passt.
Ulrich B. schrieb: > Hat jemand einen Vorschlag für einen einigermaßen aktuellen und sicher > langzeit erhältlichen (jünstigen) Controller Freescale hatte für einige Kinetis nicht nur 15 Jahre versprochen, sondern auch ein Datum dazu geschrieben. STM hat auch eine ähnliche Liste für die STM32, aber die von Freescale fand ich überzeugender. Und jetzt hat NXP das Sagen :( > für die im Grunde ein 2 MHz 6802 ausreichen würde Noch ein Argument für die Kinetis ;) Und es gibt 5V-Modelle, das kann STM nicht. xyz schrieb: > Ein STM32F030/F05x/... sollte wohl passen. Das sind allerdings Dreckschleudern, verglichen mit den STM32L0 (soweit die Datenblätter vergleichbar sind). Die L0 sind auch von der Takterzeugung her flexibler, man kann z.B. einen internen Oszillator mit 1MHz haben. Die STM32G0 strahlen wieder etwas mehr und haben weniger VDD/GND-Pinpaare, aber dafür haben sie als einzige STM32x0xx einen internen Oszillator, der stabil genug für UART ist. Von den Gehäusen und der Pinbelegung her sind die F0, L0 und G0 erstaunlich kompatibel. Ich könnte mir vorstellen, dass man eine Platine layouten kann, die für alle drei passt, falls man die wirklich vergleichen wollte.
:
Bearbeitet durch User
µC ist egal. Du kannst an alle Digitalen Ausgänge Widerstände in Serie schalten (ganz dicht am µC) um die Schaltflanken zu verlangsamen und die harmonischen Frequenzanteile zu verringern. Ferner Drosseln in die Versorgungsleitungen und so weiter...
> Das sind allerdings Dreckschleudern
Durch Messergebnisse belegbar?
Naja, alle Hausaufgaben will ich dem TO ja nicht abnehmen.
Wenn bei ihm EMV so oberkritisch ist, wird er um die Evaluierung
der Baureihen STM32F/L/G ohnehin vornehmen muessen.
Ich hatte jedenfalls mit STM32F030 (den ganz kleinen im TSSOP-20)
bei internem Takt nichts zu beklagen.
Bernhard schrieb: > So billig wie möglich und dann Flash-Controller mit Debugging, SWD und > den Kram? > > Padauk OTP CPUs kosten nur ein paar Cent und mittlerweile gibts da ganz > gute Werkzeuge (OpenPDK, SDCC usw.) Bei den Padauk gibt es aber kein Debugging auf dem laufenden µC. Wenn das gewünscht ist, würde ich zum STM8 raten. Teurer als Padauk, aber immer noch deutlich billiger als 32-Bitter. Lange Verfügbarkeit (wird z.B. auch im Automobilbereich eingesetzt). Und SDCC unterstützt den STM8 sogar noch besser als die Padauk.
Ulrich B. schrieb: > der nicht gleich wieder losstrahlt wie Sau? Hattest du da mal Probleme mit? > Die Hardwareentwickler sagen Multilayer ist gesetzt War da nicht grade noch die Parole "so billig wie irgend möglich"? Da kamen mir "gestanztes einlagiges Pertinax" in den Sinn, und jetzt kommst du mit Multilayer an... > Danke vorab für Tipps/Ideen! Wenn du die Blockkondensatoren richtig anschließt (nicht umsonst sind Vcc und GND heute meist paarweise angeordnet), dann ist der Käse fast schon geschnitten. Alles, was sich im µC abspielt, kommt dann gar nicht erst auf die Leiterplatte. Und wenn du dir dann noch den internen Oszillator leisten kannst, dann ist Ruhe. Und wenn es wegen hoher Genauigkeitsanforderungen ein externer Taktgeber sein muss, dann nimm keinen Oszillazor mit ns-Flanken, sondern einen Quarz, der mit möglichst niedriger Frequenz und wenig Energie schwingt. Die PLL im µC ist dank der Blockkondensatoren aussen nicht zu sehen. > Gute EMV ist dabei zwingend, weil der VDE hier eine tragende Rolle > mitspielt (9kW) Diese logische Verknüpfung kann ich nicht nachvollziehen...
:
Bearbeitet durch Moderator
Also der Controller wird alleine sowieso nie "einfach so" los strahlen. Nimm den 1. besten und gut :) Es geht da wirklich nur um's Layout! Schöne Fläche unterm uC; sauber abblocken. Wenn du Angst hast, kannst du noch Angst-C' mit ein paar pF zu den Eingängen und so 10R and die Ausgänge machen. Damit sollten die 20V/m aus der FuSi und Emission Haushalt wirklich kein Problem darstellen. Alles andere ist bei Multi-Layer auch nicht anders. Es wird nur einfacher. Irgendwann hast du einfach so viele Leitungen, dass du dir deine Referenz-Lage zu weit zerschneidest => du baust dir Antennen. Da hast du einfach Vorteile mit 4 oder mehr Lagen. Viel Kritischer sind bei sowas Schaltregler usw... Ach ja, was meinst du mit 9kW? 73
So! allem Anschein nach ist es ja fast schon eine Unverschämtheit, erst einen Tag später nach seinem Post zu schauen. Bin einigermaßen geflasht ob der Fülle der nützlichen Posts hier! AUF JEDEN FALL VIELEN DANK. reichlich Inspiration ist auf jeden Fall da. mir war zB nicht bewusst, dass es Controller gibt mit einstellbarer Flankensteilheit. (Klar dass das den Dreck mindern kann) Ebenso dass die PLL nicht zwingend ist (Ich entwickle geraume Zeit nur noch um den LPC1778 herum in Vollgasmodus, da wird man wohl etwas betriebsblind) Ja in der Tat, die STM32L0 .. die könnte passen und nein. nicht Pertinax. so billich dann doch nicht. Nur soo billich, dass man um jedes noch so kleine Detail feilschen muss aaaaber der Layouter einem dann mit Multilayer reingrätscht. Wobei der Aufpreis heute nicht mehr gar so dramatisch ist. Der Hinweis auf den internen Takt ist genauso klasse (wusste auch nicht, dass damit UART möglich ist - aber doch wohl kaum über 19.2 oder?) wie der, die paarweisen Versorgungspins als Pärchen zu begreifen. Muss dem Layouter mal genauer zuschauen wie mir scheint. Die 9kW sollen planmäßig in Wärme übergehen ohne dass es Flammen werden ;)
> aber doch wohl kaum über 19.2
Der relative Fehler bleibt immer der selbe.
Egal ob 19.2 oder 230.0.
Wann merken sich die Leute das endlich mal.
Ulrich B. schrieb: > Ich denke: Zweilagig würde von den > schaltungstechnischen Anforderungen wirklich ganz locker ausreichen. Du denkst nicht, du hoffst naiverweise auf gnädig gestimmte Naturgewalten. Soviel Teurer ist Multilayer nicht. Falls dein Zweilagenaufbau nich passt, wirste am schluß einen Schirmkäfig drumherum bauen müssen - das wird dann teuer.
Praktiker schrieb: > Der relative Fehler bleibt immer der selbe. > Egal ob 19.2 oder 230.0. > > Wann merken sich die Leute das endlich mal. Da hast du wohl Recht. Allerdings ergibt sich ein zusätzlicher Fehler, wenn der Systemtakt nicht glatt durch die Baudrate teilbar ist. Der ist bei niedrigen Baudraten geringer. Beispiel für den STM32L073 mit seinem Standard Takt (nach Reset): 2097000 ÷ 115200 ÷ 8 = 2 und ein paar zerquetschte. 2097000 ÷ 8 ÷ 2 = 131062,5 Baud -> 13,7% Fehler 2097000 ÷ 2400 ÷ 8 = 109 und ein paar zerquetschte. 2097000 ÷ 8 ÷ 109 = 2404,8 Baud -> 0,2% Fehler
Ulrich B. schrieb: > Hat jemand einen Vorschlag für einen einigermaßen aktuellen und sicher > langzeit erhältlichen (jünstigen) Controller, der nicht gleich wieder > losstrahlt wie Sau? Die Abstrahlung des Controllers ist meist nur dann ein Problem, wenn er das schmalbandig macht und dadurch einen hohen Peak im Spektrum erzeugt. Außerdem müssen dafür im Layout ausreichend wirksame Antennen vorhanden sein.
Stefan ⛄ F. schrieb: > STM32L073 > 2097000 ÷ 115200 ÷ 8 = 2 und ein paar zerquetschte. > 2097000 ÷ 8 ÷ 2 = 131062,5 Baud -> 13,7% Fehler ganz so schlimm ist es bei der L-Familie nicht: 2097000 ÷ 115200 = 18 und ein paar zerquetschte. 2097000 ÷ 18 = 116500.0 -> 1.13% Das reicht sogar, naja, wenn du schnelle Treiber nimmst und die 2MHz aus dem MSI mit den 32kHz vom LSE trimmst. Aber natürlich bleibt bei 9600 etwas mehr Luft.
Beitrag #6624117 wurde von einem Moderator gelöscht.
Praktiker schrieb: > Der relative Fehler bleibt immer der selbe. > Egal ob 19.2 oder 230.0. > > Wann merken sich die Leute das endlich mal. Wann wirst du begreifen, dass es beim Festlegen vom Timing des Baudratengenerators zwei prinzipiell verschiedene Arten von Fehlerursachen gibt: Es gibt einen Taktfehler, durch Abweichung der Taktfrequenz vom Nennwert entsteht und zu einem gleichbleibenden relativen Fehler der Baudrate führt. Und es kann Fehler dadurch geben, dass man auch bei Nennfrequenz den Teiler wegen diskreter Teilerverhältnisse nicht so einstellen kann, dass die Baudrate der Nennbaudrate entspricht. Probleme durch die Granularität des Teilers verschärfen sich bei höheren Baudraten und hängen von der relativen Abweichung zwischen idealem und realisierbaren Teilerfaktor ab. Und genau dieser relative Fehler kann bei hohen Baudraten (=kleiner Teilerfaktor) kräftig ansteigen. Durch passende, sogenannte Baudratenquarze, die eben auf ganzzahlige Teilerverhältnisse abgestimmt sind, kann diesen Problem vermieden werden.
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.