Hallo Alle zusammen, ich suche im Moment für ein Projekt einen Mikrocontroller. Dieser soll möglichst klein sein, wenig Strom verbrauchen, eine RTC eingebaut haben und mindestens 7 frei definierbare Schnitstellenmodule haben (UART, SPI, I²C). Bisher habe ich einen ATMega 2560 verwendet, will jetzt aber gerne auf einen Controller mit DMA umsteigen und dachte mir dabei könnte ich auch gleich mal den Einstieg in die ARM's wagen. Da ich den Programmer/Debugger von Atmel schon habe (Atmel ICE) und die IDE ganz übersichtlich finde habe ich bei Atmel nach einem Controller gesucht und den ATSAM G55 gefunden. (http://www.microchip.com/wwwproducts/en/ATSAMG55) Es ist ein Cortex-M4. Nach allem, was ich gelesen habe sollte der für den Anfang ganz gut geeignet sein. Außerdem gibt es ein offizielles Development-Board mit dem ich zunächst die Entwicklung beginnen könnte. Der Preis spielt eine untergeordnete Rolle. Das Board soll nicht öfter als 5 mal hergestellt werden. Ich lese überall ganz viel über die STM-32 Chips. Was sind da die Vorteile? Zum G55 finde ich leider außer dem Datenblatt (~1100 Seiten) nur wenig Dokumentation. Gibt es Dokumentation/Hilfestellungen/Tutorials, die für alle ATSAM's gelten, an denen ich mich entlang hangeln könnte? LG Joscha
Joscha schrieb: > einen Controller mit DMA Ist nur meine Meinung aber ich finde einen uC mit Dual-Core einfacher zu programmieren als DMA: Jeder Core kümmert sich asynchron um was z.B. einer um den ADC auslesen und ein anderer um den FIR Filter. https://www.nxp.com/products/microcontrollers-and-processors/arm-based-processors-and-mcus/lpc-cortex-m-mcus/lpc54000-series-cortex-m4-mcus:MC_1414576688124 https://www.nxp.com/products/microcontrollers-and-processors/arm-based-processors-and-mcus/lpc-cortex-m-mcus/lpc4300-cortex-m4-m0:MC_1403790133078 > Atmel ICE Der Debugger wird Dir von NXP, STM, Silabs für < 20 EUR nachgeworfen. > Ich lese überall ganz viel über die STM-32 Chips Stimmt hat sich im Hobby-Bereich etabliert. In der Industrie ist aber mehr NXP und Silabs (die vor allem bei Wireless) und in Automotive TI Zudem hat STM noch eine 8-bit Linie STM-8 für Automotive.
Joscha schrieb: > Ich lese überall ganz viel über die STM-32 Chips. Was sind da die > Vorteile? Wenn man sich nur die Specs anschaut: - Grösser (Speicher) - Schneller - Flexibler (Innerhalb der Familie kann fast ohne Probleme und Up- Downgrade gemacht werden, was mir bei einer laufenden Serie schon den Arsch gerettet hat) Vom Handling her: - Tool und Programmierung für Cortex-M0 bis M4 identisch (einfach unterschiedlicher HAL, -> siehe Flexibilität) - Fertige Bibliotheken (HAL, USB-Stack...) - Breite Community (gibt massenhaft Foren und Tutorials) Preise: - Gratis IDE (Coocox, Atollic) - Günstige Demo-Boards (<30 Euro mit Touch-Screen) Aber ich denke, mittlerweile spielt die Marke wohl nicht mehr eine Grosse Rolle, da alle ähnliches können.
Einen bereits vorhandenen Debugger würde ich nicht unbedingt als Kriterium nehmen. Für die meisten Cortex-Derivate gibt es sehr günstige Debug-Hardware, auf fast allen Demoboards ist sie bereits integriert. Wir benutzen den STM32F mit dem ST-Link, der kostet unter 20,-€. Gruß, Stefan
Joscha schrieb: > wenig Strom verbrauchen Dann wäre auch ein Blick auf Cortex-M0[+] interessant. Gibt's von Atmel (SAMD21 und Co.), aber auch von anderen. Ist halt auch eine Frage, ob du viel CPU-Leistung (und schnellen Takt) brauchst oder Strom sparen wichtiger ist.
Jörg W. schrieb: > Ist halt auch eine Frage, ob du viel CPU-Leistung (und schnellen Takt) > brauchst oder Strom sparen wichtiger ist Da muss ich dann natürlich wieder mal anmerken, dass sich wie getestet ein 32-bit Cortex M0+ mit 50 MHz wie z.B. LPC800 und ein 8-bit 8051 mit 50 MHz wie z.B. EFM8 in der Leistung nicht viel geben und der 8051 auch noch stromsparender ist. Das liegt einfach daran, dass beide Waitstates haben beim Flash-Zugriff, beide kein Programm aus dem RAM ausführen können, und beim Cortex M0+ die wichtigsten ARM-Vorteile wie bedingte Ausführung und Barrel-Shift eingespart wurden. Division hat er auch nicht. DMA haben auch beide.
Danke erst mal für die ganzen Antworten! Ich habe leider mehr als zwei "Prozesse", die nebeneinander laufen müssen. DMA bietet sich da bei mir wirklich gut an. Würde ein Mehrkernprozessor denn mehr Strom verbrauchen? Wer produziert denn im Moment Mehrkern-Arm´s, die zu meinem Projekt passen könnten. Bis auf die Community und die vielen Hilfestellungen und Tutorials gab es für mich noch kein K.O.-Argument. Gibt es sonst noch irgendwelche Nachteile an der Ateml SAM-Reihe? Laut dieser Grafik ist die G-Reihe für Stromsparende Anwendungen genau das richtige, obwohl es ein M4 ist. Oder versethe ich da etwas falsch? Im Prinzip scheue ich mich nicht vor einem Wechsel. Gibt es von STM auch so einen "Konfigurator"? (http://www.atmel.com/selector.html#%28actives:%21%28%29,data:%28area:%27%27,category:%2734864%27,pm:%21%28%29,view:list%29,sc:1%29) Was für einen Microprozessor würdet ihr mir denn empfehlen? LG Joscha
Hups, da habe ich denk Link zur Grafik vergessen: http://www.atmel.com/Images/ARM_Roadmap_Web_Lg_870x560.png
Joscha schrieb: > Danke erst mal für die ganzen Antworten! > > Ich habe leider mehr als zwei "Prozesse", die nebeneinander laufen > müssen. DMA bietet sich da bei mir wirklich gut an. > Würde ein Mehrkernprozessor denn mehr Strom verbrauchen? Wer produziert > denn im Moment Mehrkern-Arm´s, die zu meinem Projekt passen könnten. > Ich arbeite schon seit Beginn mit den EnergyMirco/Silabs EFM32 Serien. Bin also etwas voreingenommen. Aber die Struktur ist einfach sauber und die Libraries sind gut. Die AppNotes und Beschreibungen super. Das Pheripheral Reflex System mit DMA eignet sich gerade für solche quasi parallel laufenden Aufgaben. Also z.B. regelmäßig ADC Scan laufen lassen und Ergbnisse automatisch mit DMA ins RAM schieben lassen. Oder parallel dazu die serielle Kommunikation per DMA in den RAM Buffer schieben und die CPU schläft dabei. Die DMA sind auch besser und mächtiger als z.B. die der PICs. Da reicht dann ein CPU Clock von 5-14 MHz (--> Flash ohne wait states) bei meinen Anwendungen locker. Die Pheripherie ist meist sehr mächtig, stromsparend und sauber implementiert. Nicht so dazugeschustert wie bei so manch anderem Hersteller. Der Segger J-Link (onboard bei den Dev Boards) mit einer IDE welche kaum Wünsche offen lässt (Rowley Crossworks) und es macht wieder Spass uCs zu programmieren. M0, M3, M4 - M0 hat einiges an Befehlen weniger als M3. Das heißt, für die gleiche Aufgabe muss der Core länger laufen. Auch wenn der Stromverbrauch / MHz geringer ist, bringt es real dann oft nichts da man entweder höher takten muss, oder eben der Core weniger im Sleep Mode ist. Wer die floating point Befehle des M4 braucht, ist mit diesem gut bedient. Oft braucht man diese aber nicht. Nur weil der M4 kaum mehr Siliziumfläche braucht als ein M3, setzten neuere Chips oft nur mehr auf M4.
Joscha schrieb: > Gibt es von STM auch > so einen "Konfigurator"? Nennt sich stmcufinder. Schau Dir den STM32L476 auch an! Und das L4 Disco Board zum Spielen.
STM32F103 http://stefanfrings.de/stm32/index.html Die Stromaufnahme im Standby ist allerdings deutlich höher, als du von AVR Controllern gewöhnt bist. Wenn es da wirklich auf wenige µA ankommt, dann schau Dir die STM32L Serie an. > Ich habe leider mehr als zwei "Prozesse", die nebeneinander laufen müssen Das löst man zum Beispiel mit Zustandsautomaten. Selbst Windows beruhte lange Zeit darauf (als ich noch klein war).
Lothar schrieb: > Das liegt einfach daran, dass beide Waitstates > haben beim Flash-Zugriff, beide kein Programm aus dem RAM ausführen > können, [...] Zumindest Atmels CM0+ können Code aus dem RAM ausführen. Es gibt dafür sogar eine eigene Appnote, und schneller, wait-state-freier Zugriff ist als eins der Argumente dafür genannt. http://www.atmel.com/Images/Atmel-42249-Executing-code-from-RAM_Application-Note_AT07347.pdf Eine generelle Aussage, welche CM0[+] das können und welche nicht, konnte ich auf die Schnelle nicht finden. Es handelt sich aber ganz offensichtlich nicht um eine architekturelle Einschränkung des Prozessors, sondern bestenfalls um ein Feature einer konkreten Implementierung.
Jörg W. schrieb: > Zumindest Atmels CM0+ können Code aus dem RAM ausführen War mir neu: Dachte dass das erst ab M3 geht. Zudem hat der kleinste D20 nur 2K RAM. Ausserdem steht da: "If it is desirable to place all code in RAM, a linker script is available for this purpose. This can be found in ASF, however currently not trough the ASF bundled with Atmel Studio"
Lothar schrieb: > Jörg W. schrieb: >> Zumindest Atmels CM0+ können Code aus dem RAM ausführen > > War mir neu: Dachte dass das erst ab M3 geht. Es gibt eigentlich keinen Grund bei ARM, warum es nicht gehen sollte. Im Gegenteil, CM0 ist eine von-Neumann-Architektur (sagt Wikipedia), da sollte es ohnehin kein Problem sein. > Zudem hat der kleinste D20 > nur 2K RAM. Ausserdem steht da: Man muss sich ja auch nicht am kleinsten orientieren. SAMD20 würde ich ohnehin nicht mehr in Betracht ziehen, das war eigentlich nur ein Zwischenschritt zum D21. Wimre hat der D20 auch noch keine DMA. > "If it is desirable to place all code in RAM, a linker script is > available for this purpose. This can be found in ASF, however currently > not trough the ASF bundled with Atmel Studio" Naja, das bisschen Linkerscript kann man sich auch mit der Hand fummeln. Wer aber bei einem ARM allen Code in den RAM packt, geht da irgendwie irgendwas falsch an, würde ich mal sagen. Schließlich ist RAM deutlich teurer als Flash, und bei vielen Dingen stören die Wait-States nicht weiter, weil es nicht zeitkritisch ist.
Joscha schrieb: > Ich habe leider mehr als zwei "Prozesse", die nebeneinander laufen > müssen. DMA bietet sich da bei mir wirklich gut an. Huch? Was hat DMA mit mehr als zwei Prozessen zu tun? Also DMA ist ein Core, der Daten von einer Adresse zu einer anderen Adresse umschaufeln kann. Mehr nicht. Normalerweise hat er zwei Adreßregister (Quelle und Ziel) und einen Datenzähler und das war's (bis auf die Triggerlogik). Zumeist kann ein DMA nicht mal einen Ringpuffer richtig bedienen, ohne daß die CPU damit genauso viel Arbeit hat als ohne DMA. Also, wieso kommst du darauf, einen DMA als derart wichtiges Kriterium zu betrachten und obendrein mit Ideen von mehreren Prozessen zu verbinden? Wenn du von der AVR-Seite kommst, dann lies dich zunächst mal in die derzeitigen Arm/Cortexe ein. Das ist wichtiger als DMA. W.S.
W.S. schrieb: > Joscha schrieb: >> Ich habe leider mehr als zwei "Prozesse", die nebeneinander laufen >> müssen. DMA bietet sich da bei mir wirklich gut an. > > Huch? > > Was hat DMA mit mehr als zwei Prozessen zu tun? > > Also DMA ist ein Core, der Daten von einer Adresse zu einer anderen > Adresse umschaufeln kann. Mehr nicht. Normalerweise hat er zwei > Adreßregister (Quelle und Ziel) und einen Datenzähler und das war's (bis > auf die Triggerlogik). > > Zumeist kann ein DMA nicht mal einen Ringpuffer richtig bedienen, ohne > daß die CPU damit genauso viel Arbeit hat als ohne DMA. > > Also, wieso kommst du darauf, einen DMA als derart wichtiges Kriterium > zu betrachten und obendrein mit Ideen von mehreren Prozessen zu > verbinden? > > Wenn du von der AVR-Seite kommst, dann lies dich zunächst mal in die > derzeitigen Arm/Cortexe ein. Das ist wichtiger als DMA. > > W.S. Hups, da habe ich mich wohl falsch ausgedrückt. Ich muss sehr viele Serielle Schnittstellen bedienen und trotzdem auf den Stromverbrauch achten. Ich hatte vor per DMA einen Puffer schreiben zu lassen und die CPU nur regelmäßig aufwachen zu lassen um die Verarbeitung zu machen. Zwei Kerne bringen mir da noch nichts, weil ich mehr als zwei Serielle Schnittstellen bedienen muss.
Joscha schrieb: > Ich habe leider mehr als zwei "Prozesse", die nebeneinander laufen müssen. Wie schnell? Denn der Trick am Multitasking ist, die Arbeit in kurze Häppchen zu verteilen, so dass jeder Task oft genug drankommt, um seine Aufgabe "(r)echtzeitig" zu erledigen. Das geht bei den in der mechanischen Automatisierung üblichen Aufgaben auch mit einem Kern.
Joscha schrieb: > Zwei Kerne bringen mir da noch nichts, weil ich mehr als zwei Serielle > Schnittstellen bedienen muss. ??? Dann würde ich mir zuerst über das Design Gedanken machen. Bei den STM32 DMAs weiss ich, dass dir die je nach Auslastung nicht den erhofften Speed bringen, da jeder DMA-Kanal und auch die CPU sich Adress- und Datenbus teilen. Da Gibt's dann auch Mechanismen, die garantieren, dass die CPU sowie jeder Kanal mal an die Reihe kommt (-> Buffer-Handling der DMA mit Block-Kopieren ist oft effizienter als jeweils nur 1 Register schreiben). Ausserdem Empfehle ich dir dringen die ERRATA-Sheets durchzulesen. Konnte einmal ein Design nach 6 Monaten Arbeit in die Tonne stampfen, nur weil der DMA beim STM32F4 einen Groben Fehler für das USB hatte (-> spontane Überlastung des Datenbus mit Kollisionen was zu einem Hardfault geführt hat, und natürlich konnten selbst die von STM nicht wirklich weiterhelfen). Wie viele Schnittstellen von welchem Typ hast du dann und wie Schnell werden welche Datenmengen übertragen?
Hey, einen Mehrkernprozessor brauche ich glaube ich wirklich nicht. Bisher hatte ich alles Interrupt-gesteuert und das Reicht geschwindigkeitsmäßig schon. Die meisten Schnittstellen laufen auf 9600 Baud. Zwei laufen etwas schneller. Wie schnell weiß ich jetzt noch nicht. Damit sollte es aber glaube ich kein Problem geben. Ich hatte mir nur mal DMA angeschaut und dachte ich könnte so den Prozessor oft schlafen lassen. Sowohl zum Senden, als auch zum Empfangen würde ich dann DMA benutzen. Die CPU könnte dann ein paar mal pro Sekunde anspringen und sich anschauen, was passiert ist. Ohne DMA werden es leider ziemlich viele Interrupts. Die wollte ich so verhindern. Klingt das sinnvoll, oder übersehe ich etwas? So, ich habe mir mal den stmcufinder herunter geladen. Da muss ich Atmel wirklich loben. Der stmcufinder ist unübersichtlicher, schlechter konfigurierbar und erfordert einen Download (+Installation). Immerhin auch mit Linux-Version. Trotzdem habe ich es geschafft einen Prozessor heraus zu suchen. Der STM32F423xH scheint alle meine Anforderungen zu erfüllen. http://www.st.com/en/microcontrollers/stm32f413-423.html?querycriteria=productId=LN2004 Was sagt ihr dazu? Wo liegt der Unterschied zwischen dem 413 und dem 423 am Ende? Development-boards finde ich zwar, aber da steht immer nur STM32F4. Was ist mit den letzten beiden Ziffern?
Joscha schrieb: > einen Mehrkernprozessor brauche ich glaube ich wirklich nicht. > Bisher hatte ich alles Interrupt-gesteuert und das Reicht > geschwindigkeitsmäßig schon. Alternativ könntest du dir überlegen ein RTOS einzusetzen. Das RTOS hilft dir beim Timing deiner Applikation und du kannst mehrere Teile deiner Applikation unabhängig und quasi parallel laufen lassen. Ich weiß ja nicht, ob das bei dir privat oder kommerziell ist. Du könntest dir FreeRTOS oder SEGGER embOS anschauen: https://www.segger.com/products/rtos/embos/ Und weil Rowley schon erwähnt wurde wäre Embedded Studio auch für dich passend: https://www.segger.com/products/development-tools/embedded-studio/
Til S. schrieb: > Alternativ könntest du dir überlegen ein RTOS einzusetzen. Was genau hilft das für das Problem, die CPU nach Möglichkeit maximal schlafen zu legen? Ich denke schon, dass dafür die DMA eine sinnvolle Wahl ist.
Das sind schon komische Anforderungen. Bei 9600 BPS brauchen z.B. 100 Zeichen 100 ms, was bringt es da Interrupts zu sparen oder was soll der DMA anders machen als zu warten? Zwischen den Zeichen schlafen? Dürfte auch nicht viel bringen bei mehreren Schnittstellen die den µC dann doch ständig wecken. Und zum schnell aufwachen wird man auch einen Modus nehmen müssen der nur wenig Strom sparen kann. Aber dafür mit einem STM32F4 Boliden mit vielen MHz drangehen? Der braucht dann wieder viel Strom wenn er läuft... Vorsichtig geschätzt reicht da ein Cortex-M0, selbst so ein Leichtgewicht aus der LPC8xx Serie. Und den Takt dann eher auf 1 MHz runterdrehen zum Stromsparen.
Jörg W. schrieb: > Was genau hilft das für das Problem, die CPU nach Möglichkeit maximal > schlafen zu legen? > > Ich denke schon, dass dafür die DMA eine sinnvolle Wahl ist. Klar, auf jeden Fall. Ich wollte nur eine Alternative aufzeigen. Auch mit einem RTOS kann man die CPU für eine maximale Zeit schlafen legen. Zum einem weiß man recht einfach wann sich die CPU im Idle befindet und kann dort einen Stromsparmodus einschalten und zum anderen gibt es noch zusätzliche Hilfsmittel wie z.B. Tickless Support. Es muss sich ja auch nicht beides widersprechen. Ich würde die DMA benutzen, um die Daten zu versenden und wenn die DMA fertig ist könnte ein Interrupt die Task aufwecken, die dann die nächsten Daten zum versenden vorbereitet und die DMA erneut startet. D.h. die Task verbraucht nur CPU Zeit, wenn es etwas zu tun gibt und man muss nicht jede Sekunde pollen, um zu schauen was passiert.
Til S. schrieb: > Auch mit einem RTOS kann man die CPU für eine maximale Zeit schlafen > legen. Zum einem weiß man recht einfach wann sich die CPU im Idle > befindet und kann dort einen Stromsparmodus einschalten und zum anderen > gibt es noch zusätzliche Hilfsmittel wie z.B. Tickless Support. Dürfte sich schätzungsweise gegenüber seinem bisherigen, rein interruptgesteurten Vorgehen aber nicht viel ändern. Ist nur etwas generischer.
Joscha schrieb: > Ohne DMA werden es leider ziemlich viele Interrupts. Die wollte ich so > verhindern. Klingt das sinnvoll, oder übersehe ich etwas? Und mit DMA werden es noch viel mehr Interrupts. Wozu du UART's mit DMA betreiben willst, ist mir immer noch völlig unverständlich. Ich schätze, das liegt einzig daran, daß du weder intimere Kenntnisse über die diversen UART-Cores noch Kenntnisse über die verbauten DMA-Cores hast. Wenn du diir nen Gefallen tun willst, dann vergiß die gesamte DMA-Idee und lies die Dokumentationen zu den verschiedenen Chips. Bei den LPCxxx hat man nämlich zumeist passable FIFO's in den seriellen Schnittstellen und die entlasten das Geschehen sehr gut - da kommt kein Konstrukt mit DMA hinterher. Also nochmal: Verenge dein Blickfeld nicht auf eine Marke, sondern lies die Unterlagen verschiedener Hersteller. W.S.
Joscha schrieb: > Hey, > Die meisten Schnittstellen laufen auf 9600 Baud. Zwei laufen etwas > schneller. Wie schnell weiß ich jetzt noch nicht. > Damit sollte es aber glaube ich kein Problem geben. > > Ich hatte mir nur mal DMA angeschaut und dachte ich könnte so den > Prozessor oft schlafen lassen. Sowohl zum Senden, als auch zum Empfangen > würde ich dann DMA benutzen. Die CPU könnte dann ein paar mal pro > Sekunde anspringen und sich anschauen, was passiert ist. Die EFM32 wurden ja schon genannt. Diese haben sog. Low Energy Uarts welche im Deep Sleep incl. DMA arbeiten können. Der Transfer z.b. via dma des frames kann über ein definierbares Startsymbol erfolgen, ende wird über ebenso definierbares Symbol signalisiert. Eventuell einschränkend, mir sind jetzt nur Typen mit zwei dieser implementierten LEUart Module bekannt aber da kann einem schnell mal was entgehen. Wer dies in der Form noch anbietet weiß ich jetzt nicht könnte mir aber vorstellen das man dies auch bei anderen Hersteller findet. > Ohne DMA werden es leider ziemlich viele Interrupts. Die wollte ich so > verhindern. Klingt das sinnvoll, oder übersehe ich etwas? > Soviel Interrupts sind es jetzt auch nicht, aber es geht auch effizienter wenn es darauf ankommt.
Lothar schrieb: > Jörg W. schrieb: > Ist halt auch eine Frage, ob du viel CPU-Leistung (und schnellen Takt) > brauchst oder Strom sparen wichtiger ist > > Da muss ich dann natürlich wieder mal anmerken, dass sich wie getestet > ein 32-bit Cortex M0+ mit 50 MHz wie z.B. LPC800 und ein 8-bit 8051 mit > 50 MHz wie z.B. EFM8 in der Leistung nicht viel geben und der 8051 auch > noch stromsparender ist. Naja zumindest der LB12 und BB3 Typ mit denen ich bisher arbeitete brauchen im Run Mode (auch nicht alle Peripherie aktiviert/genutzt) etwa 170uA/MHz(+-10 @3v3 mit 24 - 72MHz) das ist zwar ein gutes Stück besser als z.b der ältere f120 typ aber nicht unbedingt eine Benchmark für z.b. die erwähnten Cortex M0+ derivate. > Das liegt einfach daran, dass beide Waitstates > haben beim Flash-Zugriff, beide kein Programm aus dem RAM ausführen > können, Stimmt aber für linear ablaufenden Code prefetchen beide ausreichend um Full speed zu erreichen, bei sprüngen müssen sie dann alle warten. Der silab 8051 fetcht 4 Byte, hat aber auch bis zu 3Byte befehle passt gerade das allignment nicht vergeht dann noch mehr warte Zeit > und beim Cortex M0+ die wichtigsten ARM-Vorteile wie bedingte > Ausführung und Barrel-Shift eingespart wurden. Division hat er auch > nicht. Mehr Einsatz von 16Bit und 32Bit Datentypen Verarbeitung und..... >DMA haben auch beide. Naja du möchtest doch jetzt nicht den sehr speziellen und begrenzten light DMA nur für den Adc des efm8 mit der üblichen flexiblen mehrkanäligen DMA Implementierung bei den cortexen vergleichen...oder doch?
W.S. schrieb: ... > Und mit DMA werden es noch viel mehr Interrupts. ? Da soll mir mal jemand erklären wie blöd man einen DMA Kanal aufsetzen muss, um diese Aussage zu bestätigen. > Wozu du UART's mit DMA betreiben willst, ist mir immer noch völlig > unverständlich. .... Okay, das deutet in die Richtung, dass der Schreiber dieser Zeilen entweder noch nicht verstanden hat was man mit einem DMA machen kann, oder er hatte bis jetzt nur extrem verkorkste µCs wo DMA nur als Marketinggag im Flyer drinnen stand. Gerade beim schon erwähnten EFM32 mit z.B. 2 x LEUART, welche für die hier angesprochenen 9600 Baud ausreichen, ist das Betreiben dieser über DMAs eine wahre Freude aus Sicht SW-Konzept. Die laufen nämlich inklusive DMA im EM2 und somit mit minimalstem Stromverbrauch. Mit "Wake up only on specified start and signal frames" einfach genial solange man nicht über 9600 Baud muß. Aber für höhere Geschwindigkeiten gibt's ja eh noch die UARTs und USARTs.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.