Hallo Community! Ich bin im Zuge meines Studiums so einige Male in eurem Forum bzw. der Homepage gelandet und bin auch immer fündig geworden auf der Suche nach Antworten. Jetzt habe ich aber „leider“ ein etwas spezifischeres Problem, auf welches ich gerne eure Meinungen und Empfehlungen hören möchte. Konkret geht es um die Wahl eines geeigneten Mikrokontrollers für die Umsetzung eines mobilen Testgerätes für ein spezielles Datenprotokoll. Damit ihr euch einen schnellen Überblick verschaffen könnt, nachfolgend ein paar Infos als Stichpunkte. Zum Protokoll: - Dreipegliges strommoduliertes Signal: 7, 14 und 28 mA - Wird an einem Messwiderstand gemessen (zweiadrige Leitung mit Stromsenke am anderen Ende der Leitung) - Manchestercodiert - Pulsbreite: 50 us --> 20kHz Was der Tester können soll: - Datenprotokoll einlesen, interpretieren und auf einem Display (LCD) Infos zur Analyse ausgeben - Eine Abtastung mit ca. 50 Messpunkten je Puls, gerne auch mehr --> mind. 1MHz Abtastfrequenz - Speicherung der Abtastpunkte sowie ggf. weitere analysierte Ergebnisse auf einer SD-Karte --> soweit ich in Erfahrung bringen konnte, ist somit mind. ein 32 Bit Controller nötig wegen des Adressraums? Sowie ggf. ein passendes Shield zur Erweiterung des Boards - Vermessung von bis zu 4 der Protokolle zeitgleich - Erzeugung des gemessenen Signals (Tester fungiert in diesem Schritt als Simulator des Signals), im besten Fall von 4 unabhängigen Signalen (also mit unterschiedlichem Dateninhalt) - Unterm Strich werden hier für die Funktion (vor Allem für die Signalerzeugung) wohl noch Shields / Einzelkomponenten nötig, da ich mir nicht erhoffe, dass es einen uC gibt, der die nötigen Ströme bereits in integrierten DACs bereitstellen kann - USB-Schnittstelle - Mit Batterie zu betreiben (sollte denke ich keine große Einschränkung bei einem uC sein) Zu meinen Fähigkeiten: - Ich komme aus der Mechatronik, - Kann C programmieren - Und habe vor vielen Jahren mal ein kleineres Arduino-Projekt gemacht, vornehmlich aber mit vorgefertigtem Code Ich habe mir während meiner Recherche Artikel wie beispielsweise den Ratgeber zur uC-Wahl Entscheidung Mikrocontroller genauer angeschaut sowie weitere mögliche Boards ins Auge gefasst. Soweit hat meine Recherche ergeben, dass ich einen AVR, PIC oder Arduino (im Grunde ja auch ein AVR) nutzen möchte aufgrund der breiten Community für mögliche Hilfestellungen. Der Compiler muss nicht komplett kostenlos sein, darf aber gerne auch unterhalb der 50€-Grenze liegen, da ich zeitlich bedingt nicht sehr optimistisch bin nach dem Projekt in naher Zukunft erneut ans uC Programmieren zu kommen. Aufgrund der 32-Bit Beschränkung (von der ich ausgehe wegen der SD-Karte) habe ich bisher den Arduino Due ins Auge gefasst. Ich denke ein Raspi ist bei meiner Anwendung eher fehl am Platz? Ich denke, dass diese beiden Hersteller nur die Spitze des Eisbergs sind, tue mir aber leider sehr schwer hier etwas geeignetes zu finden. Leider habe ich keine Erfahrung in der Wahl des richtigen uC für meine doch sehr spezifischen Anforderungen, weshalb ich eure Meinungen und Empfehlungen sehr zu schätzen weiß. Ich hoffe, dass ich die meisten aufkommenden Fragen bereits in den Stichpunkten beantwortet habe 😊 Danke bereits vorab! Grüße, orPoG
Constantin B. schrieb: > Ich denke ein Raspi ist bei meiner Anwendung eher fehl am Platz? Das kommt drauf an, wie groß deine Batterie ist und wie lange sie halten soll. Wie wäre es mit einem Teensy 4.1?
Constantin B. schrieb: > Ergebnisse auf einer SD-Karte --> soweit ich in Erfahrung bringen > konnte, ist somit mind. ein 32 Bit Controller nötig wegen des > Adressraums? Sowie ggf. ein passendes Shield zur Erweiterung des Boards Dan bist du Falsch informiert, Gerade ein paar andere Parameter die du aufgeführt hast lassen doch eher auf ein MSP430FRxxx schliessen der interne analoge Komponente hat. Vergleiche dazu: https://www.mikrocontroller.net/articles/MSP430#Analog_Peripherie Und das LEA System in Verbindung dazu. Die kann dir viel Rechnerei abnehmen, und durch die XMPU und ihren 24BIT Registern, macht auch die Programmierung grösseren Adressbereiche trotz der 16Bit MPU keine Probleme. Was der Stromverbrauch angeht ist der MSP430FRxxx so ziemlich der Spitzenreiter. Sparsamer bei gleicher Rechenleistung geht fast nicht.
:
Bearbeitet durch User
Hallo Wolfgang, Danke für deine Antwort! Die Batterie muss nur eine gute Stunde halten, das wäre schon ausreichend. Wird also denke ich kein limitierender Faktor. Der Teensy sieht auf den ersten Blick ja sehr gut aus. Wie ich sehe kann man ihn mit der Arduino IDE programmieren, also sozusagen mit C in angepasster Weise? Und wie sieht es hier wohl mit der Taktrate aus, die 600 MHz sollten denke ich bei einem 32 Bit Controller ausreichen für meine Anforderungen, oder übersehe ich hier etwas?
Hast du dir schon die STM Nucleo angeschaut? Der Nucleo bringt direkt programmer und debugger mit und die STM32 haben 1meg sample ADC mit DMA. Stromquellen müssen noch separate drauf. Entweder in die feedback loop eines regulators eingreifen oder opamp Spannung zu Strom Schaltung. Ein AVR DB µC kann daher bereits als einstellbare Konstantstromquelle verwendet werden, jedoch brauchst du dann separate USB und ADC. Denk dran, dass Konstantstromquellen eine compliance voltage haben.
> passendes Shield Was soll den das fuer "Bastelkram" werden? Nimm einen nicht zu kleinen FPGA, dann kannst du dir die passende CPU noch spaeter aussuchen. In der Peripherie ist man damit ohnehin am flexibelsten.
Wieso nimmst du nicht ein Launchpad? Nur als Beispiel https://www.ti.com/lit/ug/slau330b/slau330b.pdf?HQS=dis-mous-null-mousermode-dsf-pf-null-wwe&ts=1644257631802&ref_url=https%253A%252F%252Fwww.mouser.de%252F Oder https://www.ti.com/lit/ug/slau263i/slau263i.pdf?HQS=dis-mous-null-mousermode-dsf-pf-null-wwe&ts=1644258154241&ref_url=https%253A%252F%252Fwww.mouser.de%252F von denen habe ich sicher 10 Stück im Einsatz und rumliegen. Da gibt’s auch welche die haben schon Batteriehaltung und alles mit drauf. Da brauchst du nicht noch extra Shield. Schau dich mal da um. Ich verwende für Prototypen meist ein Launchpad das dem Desigen am nächsten kommt, erspar mir da die ganze "Bastelarbeit" und damit viel Zeit.
:
Bearbeitet durch User
Hallo zusammen, bei den MSP430FRxxx ist mir direkt das Manchester Function Module aufgefallen, das schaue ich mir nochmal genauer an. Klingt ja sehr vielversprechend, ebenso wie die weiteren analogen OPs. Danke für den Tipp! Bezüglich der Nucleo Reihe schaue ich mir die verfügbaren Boards die tage auch nochmal genauer an - da kann man ja auch wieder Stunden bei der Auswahl verbringen. Soweit ich es auf die Schnelle verstehe handelt es sich dabei aber um potentere Arduinos?
Patrick hatte ja auch bereits auf die MSP430FRxxx von TI hingewiesen - das scheint tatsächlich in die nähere Auswahl zu kommen. Danke für deinen Hinweis!
Patrick L. schrieb: > as der Stromverbrauch angeht ist der MSP430FRxxx so ziemlich der > Spitzenreiter. > Sparsamer bei gleicher Rechenleistung geht fast nicht. Das trifft nur auf die Lea, insbesondere deren FFT zu, die nur bis 256 Punkte geht. Bei der Prozessoreffizienz ist die Familie den modernen Low Power Controllern unterlegen. TI lobt die Lea mit einem Performancegewinn von 20x. Im Vergleich zu einem M4 sind es aber bei gleicher Energie nur noch Faktor 2-3. Für Filter gibt es beim STM32U5 ebenfalls einen Coprozessor. Wenn die Applikation nur etwas mehr sonst rechnen muss, ist der MSP430 schon nicht mehr effizienter. Ich glaube aber, dass es bei der Anwendung gar nicht auf die beste Effizienz ankommt. Ich wollte den Satz mit nicht so stehen lassen. Das besondere an dem Controller ist der FRAM. Die Lea bietet nur wenig Mehrwert für noch weniger Nieschenanwendungen. Zum Thema: Für deine Anwendung passen viele Prozessoren. Fang mit was an, was du kennst und mit was du dich zurecht findest, sonst machst du dir zu viele Baustellen auf. Möglich wäre ein Arduino mit Cortex M4. Die haben auch in der Regel einen schnellen ADC, zum Teil auch DACs. Ob man wirklich einen Low Power Controller nehmen muss, hängt maßgeblich davon ab, wie lange dein System an der Batterie laufen muss. Erst wenn dann die Effizienz des Mikrocontrollers wirklich eine Rolle spielt, sollte man sich umschauen. Dafür muss man dann aber auch genau wissen, was das Programm eigentlich alles macht.
Constantin B. schrieb: > - Dreipegliges strommoduliertes Signal: 7, 14 und 28 mA > - Wird an einem Messwiderstand gemessen (zweiadrige Leitung mit > Stromsenke am anderen Ende der Leitung) > - Manchestercodiert > - Pulsbreite: 50 us --> 20kHz Nicht sooo wild. > Was der Tester können soll: > - Datenprotokoll einlesen, interpretieren und auf einem Display (LCD) > Infos zur Analyse ausgeben Nicht sonderlich schwer. Ich nehme an, daß das kein kontinuierlicher Datenstrom ist sondern eher Datenpakete. Was ist es denn genau? > - Eine Abtastung mit ca. 50 Messpunkten je Puls, gerne auch mehr --> > mind. 1MHz Abtastfrequenz Wieso? Willst du ein Mini-Oszi bauen? Oder doch nur die Daten dekodieren? Für letzteres braucht man mal sicher KEINE 50fach Überabtastung! > - Speicherung der Abtastpunkte sowie ggf. weitere analysierte > Ergebnisse auf einer SD-Karte --> soweit ich in Erfahrung bringen > konnte, ist somit mind. ein 32 Bit Controller nötig wegen des > Adressraums? Unsinn. Selbst ein "oller" 8 Bit AVR kann eine SD-Karte relativ flott ansprechen. > Sowie ggf. ein passendes Shield zur Erweiterung des Boards > - Vermessung von bis zu 4 der Protokolle zeitgleich Reine Software, braucht halt bisssel mehr FLASH-Speicher. > - Erzeugung des gemessenen Signals (Tester fungiert in diesem Schritt > als Simulator des Signals), im besten Fall von 4 unabhängigen Signalen > (also mit unterschiedlichem Dateninhalt) Nicht schwer. > - Unterm Strich werden hier für die Funktion (vor Allem für die > Signalerzeugung) wohl noch Shields / Einzelkomponenten nötig, Shields? Bestenfalls für einen schnellen Prototypen. Wenn's dann mal was werden soll, packt man das alles direkt in eine Schaltung. Wird kleiner und billiger. > da ich mir > nicht erhoffe, dass es einen uC gibt, der die nötigen Ströme bereits in > integrierten DACs bereitstellen kann > - USB-Schnittstelle Haben viele, kann man auch per FT232 und anderen ICs herstellen. > - Mit Batterie zu betreiben (sollte denke ich keine große Einschränkung > bei einem uC sein) Welche Batterie? Bleiakku aus dem Auto? ;-) > - Ich komme aus der Mechatronik, > - Kann C programmieren Das sagen sie alle ;-) > - Und habe vor vielen Jahren mal ein kleineres Arduino-Projekt gemacht, > vornehmlich aber mit vorgefertigtem Code Aha. > Ich habe mir während meiner Recherche Artikel wie beispielsweise den > Ratgeber zur uC-Wahl Entscheidung Mikrocontroller genauer angeschaut > sowie weitere mögliche Boards ins Auge gefasst. Soweit hat meine > Recherche ergeben, dass ich einen AVR, PIC oder Arduino (im Grunde ja > auch ein AVR) nutzen möchte aufgrund der breiten Community für mögliche > Hilfestellungen. Kann man machen. > Aufgrund der 32-Bit Beschränkung (von der ich ausgehe wegen der > SD-Karte) habe ich bisher den Arduino Due ins Auge gefasst. Nein, auch die kleinen AVR-Arduinos funktionieren. > Ich denke > ein Raspi ist bei meiner Anwendung eher fehl am Platz? Ja, denn da kriegt man keinen gescheiten Zugriff auf die Hardware. Da wird es schwer bis unmöglich, das Signal zu dekodieren. > Leider habe ich keine Erfahrung in der Wahl des richtigen uC für meine > doch sehr spezifischen Anforderungen, weshalb ich eure Meinungen und > Empfehlungen sehr zu schätzen weiß. Arduino ist schon OK. Andere gehen auch.
Hallo AVR, die Thematik mit dem Energieverbrauch ist hier leider von mir anfänglich schlecht aufgezeigt. Mir geht es um ein Testgerät, das maximal mal eine Stunde am Stück laufen soll - also nichts sonderlich anspruchsvolles was die Effizienz angeht. Zu dem Cortex Arduino: Kann es sein, dass du dich hier nicht direkt auf ein Arduino beziehst? Ich habe leider maximal das Arduino Due mit einem Cortex M3 gefunden. Grüße, Constantin
Hallo Falk, danke für deine sehr ausführliche Antwort! Zu deinen Kommentaren: Ja, ich will tatsächlich ein behilfsmäßiges Oszi bauen, damit man auch gewisse Abweichungen und Abnormalitäten besser einfangen kann. Dass das eigentliche Datenprotokoll nicht sonderlich fix ist, ist mir bewusst. Ich will den Tester der mit dem Board gebaut werden soll aber für eine etwas tiefgreifendere Analyse der Signale nutzen, um die Funktionalität der Sensoren analysieren zu können. Im ersten Schritt soll aber natürlich erstmal "nur" der Inhalt interpretiert werden. Aber mit einem deutlich zu langsamen uC zu starten macht ja keinen Sinn, wenn es später dann direkt an den Ressourcen scheitert. Bei den Signalen handelt es sich um einen Datenstrom a 10 Bits, die abhängig von der Geschwindigkeit des Drehzahlsensors mal mit mehr und mal mit weniger Abstand aufeinander folgen ;) Und nochmal zum Thema der 32-Bit "Theorie", die ich hier bzgl. der SD-Karte aufgestellt habe: Das hatte ich aus dem Artikel Entscheidung Mikrocontroller im Absatz "Bitbreite" entnommen. @all: Danke euch für den ausführlichen Input bisher!
Constantin B. schrieb: > Zu deinen Kommentaren: Ja, ich will tatsächlich ein behilfsmäßiges Oszi > bauen, damit man auch gewisse Abweichungen und Abnormalitäten besser > einfangen kann. Dass das eigentliche Datenprotokoll nicht sonderlich fix > ist, ist mir bewusst. Ich will den Tester der mit dem Board gebaut > werden soll aber für eine etwas tiefgreifendere Analyse der Signale > nutzen, um die Funktionalität der Sensoren analysieren zu können. OK. Aber für 1Msps braucht es schon einen 32 Bit Controller, alles andere wird nur ein Krampf bis unmöglich. Und auch bissel Speicher, da gibt es genügend, die haben Dutzende bis 100kB++ direkt im Chip. Man braucht keine 600MHz CPU, um das zu bauen. Ich kann den PICCOLO empfehlen, der kann sowas. Ist aber etwas exotischer und hat mit der Arduino-Welt nix zu tun. Der Controller sollte auch einen internen ADC haben, der die 1Msps und ggf. etwas mehr kann. Ein externer ADC geht auch, ist heute aber nicht mehr zwingend nötig. > Bei den Signalen handelt es sich um einen Datenstrom a 10 Bits, Ach herje, wie süüüß! Das sind bei 50us/Bit * 10 Bit = 500us, die bei 1Msps gerade mal 500 Meßwerte ergeben. Also wenn du das Problem als solches lösen willst und der Schwerpunkt nicht auf der Entwicklung des Testgeräts liegt, kauf dir eine einfaches Speicheroszi und gut. Das kann dein SIgnal problemlos aufzeichnen. 10 Bits kann man per Hand dekodieren ;-) Als Zwischenlösung könne man eines der Ultrabilligen Mini-Oszis aus China nehmen, wo nur ein 32 Bit ARM Controller und ein LCD drin steckt. Das kann man selber umprogrammieren. https://www.ebay.de/itm/264446416682?hash=item3d923c172a:g:LCoAAOSwC~ZdZ41u > Und nochmal zum Thema der 32-Bit "Theorie", die ich hier bzgl. der > SD-Karte aufgestellt habe: Das hatte ich aus dem Artikel > Entscheidung Mikrocontroller im Absatz "Bitbreite" entnommen. Naja, der Satz über die SD-Karte ist eher Käse, das beweisen diverse SD-Karten Libs für 8-Bit Controller, allen voran FAT fs von ELM Chan. http://elm-chan.org/fsw/ff/00index_e.html
Constantin B. schrieb: > die Thematik mit dem Energieverbrauch ist hier leider von mir anfänglich > schlecht aufgezeigt. Mir geht es um ein Testgerät, das maximal mal eine > Stunde am Stück laufen soll - also nichts sonderlich anspruchsvolles was > die Effizienz angeht. Dann ist das tatsächlich nebensächlich. > Zu dem Cortex Arduino: Kann es sein, dass du dich hier nicht direkt auf > ein Arduino beziehst? Ich habe leider maximal das Arduino Due mit einem > Cortex M3 gefunden. Das geht genauso. Der könnte sogar ganz gut für dich passen. Der ADC ist schnell genug und DACs hat er auch.
Hallo Falk und avr, danke nochmals für euren Input. @Falk: die Bits dekodiere ich auch meist selber, kann man auch gerne mal auf einem Oszi antriggern und dann bei Änderungen des Dateninhalts live beobachten. Mir geht es aber um die generelle Entwicklung des Testers sowie die Interpretationsmöglichkeit für Personen, die nicht alltäglich mit dem Protokoll bzw. der Elektrotechnik zu tun haben. Nachgeschaltet zur Aufzeichnung der Daten soll der Tester nämlich vor allem eines: Dem Anwender auf dem LCD eine Info zum Zustand des Sensors geben. Die Kollegen in der Werkstatt sind da aber nicht so nah dran wie ich es bin und können mit dem einfachen Datenprotokoll nichts anfangen. Daher die nachgelagerte Interpretation des ganzen. Zum eigentlichen Thema: Aufgrund der vielen Vorschläge habe ich mich jetzt mal genauer mit der Nucleo-Reihe beschäftigt. Ist vielleicht mit Kanonen auf Spatzen geschossen, aber ich denke mit dem STM32F401RE (https://www.exp-tech.de/plattformen/arm/stmicroelectronics/5645/stm32-nucleo-development-board-for-stm32-f4-series-with-stm32f401re-mcu-supports-arduino?c=1158) mit - 512kB Flash - 32 Bit Cortex M4 - 1-kanaligem ADC mit bis zu 2,4 Msps dürfte ich wohl meine Anforderungen deutlich überschreiten und habe gut Luft nach oben übrig Ebenso habe ich weiterhin den Arduino Due im Auge mit - 512 kB Flash - 32 Bit Cortex M3 - 1Msps ADC - (leider nur) 2x DAC ebenfalls vorhanden Gibt es bei der engeren Auswahl erfahrungsgemäß wohl noch etwas zu beachten bzw. Tipps, welches hier sinnvoller wäre?
Constantin B. schrieb: > - (leider nur) 2x DAC ebenfalls vorhanden DACs brauchst du nur, wenn du Signale mit falschen Pegeln erzeugen musst. Für ein "vorschriftsmässiges" Signal reichen zwei digitale Ausgänge und die passenden Widerstände vor der Stromquelle.
Constantin B. schrieb: > Ist vielleicht mit > Kanonen auf Spatzen geschossen, aber ich denke mit dem STM32F401RE > ... > Gibt es bei der engeren Auswahl erfahrungsgemäß wohl noch etwas zu > beachten bzw. Tipps, welches hier sinnvoller wäre? Wenn Dir Nucleo-Boards gefallen, dann nimm den schnellsten Typen, der zur Zeit verfügbar ist. Ein F401 mit 84 MHz ist einer der langsamsten Controller. F7xx oder H7xx sind erheblich leistungsfähiger und nur wenig teuerer. RAM, Flash, Cache und Geschwindigkeit lassen Dir beim Programmieren viel Luft nach oben. Fraglich bleibt aber, ob Du mit Arduino und "shields" weit kommen wirst.
Constantin B. schrieb: > Zum Protokoll: > - Dreipegliges strommoduliertes Signal: 7, 14 und 28 mA > - Wird an einem Messwiderstand gemessen (zweiadrige Leitung mit > Stromsenke am anderen Ende der Leitung) > - Manchestercodiert > - Pulsbreite: 50 us --> 20kHz Welche informationen hast du weiter noch vom Protokol ? Gibt es eine beschreibung davon ? Ist es ein standarisiertes Protocol ? Gibt es da sourcecode von (oder libraries) ? Oder ist es mehr ein "Hack" ? Ist die hardwareschaltung zum Auslesen von Protocol schon deutlich ? Patrick aus die Niederlaende
Hallo Patrick, es gibt eine genaue Definition des Protokolls, die darf ich aber leider nicht veröffentlichen. Tut mir leid. Wirklich weit verbreitet ist es aber nicht und daher wird es auch keine Libraries dazu geben. Als Hardwarebeschaltung sehe ich einen Messwiderstand vor, der dann über den ADC eingelesen werden soll. VG, Constantin
Constantin B. schrieb: > es gibt eine genaue Definition des Protokolls, die darf ich aber leider > nicht veröffentlichen. Tut mir leid. Die Frage war mehr gemeint welche definitionen vorgeschrieben sind fuer einen 'officiellen' empfanger. Ist zB da keine galvanische trennung benoetigt zwischen sender und Empfanger ?
m.n. schrieb: > F7xx oder H7xx sind erheblich leistungsfähiger und nur wenig teuerer. > RAM, Flash, Cache und Geschwindigkeit lassen Dir beim Programmieren viel > Luft nach oben. Zumindest die H7-Serie würde ich nicht empfehlen, wenn die Leistung nicht benötigt wird. Danach hört es sich hier zumindest an. Die Teile sind zwar schneller, aber die Komplexität ist auch deutlich höher. Ob es hier entsprechende Arduino Unterstützung gibt, weiß ich nicht. Ich mag die Teile auch, aber würde sie deswegen nicht für alles empfehlen.
avr schrieb: > Die Teile > sind zwar schneller, aber die Komplexität ist auch deutlich höher. Welche Komplexität? Zusätzlich Funktionen muß man ja nicht nutzen. So wie ich den TO verstanden habe, möchte er sich seinen Code zusammenklicken. Ob es dann Arduino oder CubeMX+HAL sind, ist doch egal. Nicht egal wäre es mir, ob der Code auch zügig ausgeführt wird, oder die angelegten Bremsen den Erfolg verhindern. Da hat der H7 mit 480/550 MHz und seinen Caches immer die Nase vorn. Bei fast gleich schneller Peripherie wäre der F7 mit 216 MHz und Caches noch eine gute Alternative. Für ein paar Euro Ersparnis würde ich nicht darauf verzichten wollen. Mit Teensy 4.1 wurde ja auch schon ein anderer, schneller M7 Controller genannt. Da müßte man prüfen, ob die "richtigen" Pins auf der Steckerleiste verfügbar sind.
@ Patrick: eine galvanische Trennung ist nicht nötig oder gewünscht. ohne das Zwischenschalten des Testers sind die Sensoren direkt mit dem Messwiderstand des Empfängers verkabelt. @ m.n. und avr: ich habe mir gerade erste Programmbeispiele vom Arduino sowie Nucleo angeschaut und muss sagen, dass mir die Arduino IDE da bedeutend mehr zusagt. Mit meinen Programmierkenntnissen (ich bin definitiv kein Informatiker ;) ) kommt mir der Quellcode vom Arduino deutlich einfacher vor, gerade hinsichtlich der Verständlichkeit. Aus diesem Grund werde ich mich wohl einfach im ersten Schritt mal mit dem Due beschäftigen und hoffen, dass ich damit meine Ziele erreiche. Danke an alle für die hilfreichen Ideen!
m.n. schrieb: > Welche Komplexität? Zusätzlich Funktionen muß man ja nicht nutzen. Doch muss man. Es sind nicht nur zusätzliche Funktionen, sondern das ganze Design ist viel komplexer. Stichworte Clocktree, Power Domains, 64bit Datenbus, Vielzahl an DMA Controllern, dual core. Eine Einarbeitung in einen stm32f4 ist einfacher, allein schon vom Datenblatt her. Mag sein, dass man viel mit Bibliotheken umschiffen kann, aber falls Mal doch etwas nicht funktioniert, dann ist die Komplexität doch wieder da. Ich habe einen H7 schon in einem kommerziellen Produkt eingesetzt, aber ihm einen Einsteiger zu empfehlen, ist - sorry - einfach naiv. Wieso schlägst du nicht gleich den STM32MP1 vor? Der ist doch auch nicht komplexer!?
Wenns billig sein soll und ein brauchbares Farb LCD mit Touch haben soll, fällt mir noch das STM32F429I Discovery Board ein mit 8MB SDRAM, mittlerweile gibts ein Update davon. Kostet etwa 30 Mäuse und ist sofort verfügbar: https://www.st.com/en/evaluation-tools/32f429idiscovery.html Gut dokumentiert ist es auch. Hat 2 USB Stöpsel und kann Massenspeicher darstellen oder ansprechen. Wie bei den Nucleo ist ein STLink Programmer gleich dabei.
:
Bearbeitet durch User
Constantin B. schrieb: > Aus diesem Grund werde ich mich wohl einfach im ersten Schritt mal mit > dem Due beschäftigen und hoffen, dass ich damit meine Ziele erreiche. Mache es.
Hallo Matthias, das STM32F429I hatte ich auch beim Durchschauen der Nucleo-Boards gesehen und gefiel mir auch ganz gut. Ich versuche jetzt mein Glück vorerst aber mal mit dem Arduino.
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.