Hallo zusammen, da ich nach laaanger Zeit mal wieder ein neues Projekt habe, stellt sich mal wieder die Frage nach dem geeigneten Mikrocontroller. Es hat sich ja einiges getan (Atmel von Microchip geschluckt, etc) und ich werde erschlagen von einer Flut an Controllern... Welcher Hersteller ist denn aktuell zu empfehlen, oder schenken die sich alle nix? Kurz zum Projekt: Benötigt wird Ethernet-Kommunikation und 8 analoge Eingänge die mit min. 2 MS/s abgetastet werden. Und einen Timer zur Laufzeitmessung zwischen zwei Pulsen. Kommt ein Puls, dann benötige ich die ADC-Daten von 20µS vor dem Puls und 20µS danach. Ich bin noch am überlegen ob ein µC mit allem an Bord oder einer mit externem ADC und z.Bsp. eine Wiznet W5500. Oder eine beliebige Kombination davon. Schick wäre natürlich auch wenn das Teil nicht schon in 2 Jahren abgekündigt wird... Sodele, bin gespannt auf eure Vorschläge :)
Die Wiznet Chips haben den Charme, das TCP/IP Protokoll bereits zu
enthalten.
Sehr billig und einigermaßen leicht zu programmieren sind die ESP8266
(nur WLAN) und ESP32 (WLAN und Ethernet, aber es gibt nur wenige fertige
Boards wo Ethernet bestückt ist). Die beiden ESP Chips haben integrierte
ADC mit mieser Präzision, deswegen würde ich einen externen ADC mit I²C
oder SPI Interface dran hängen.
Schwierig könnte das Timing werden. Deine 2 MS/s (oder sind es gar 8 mal
2MS/s?) hauen so einen ESP nicht vom Hocker, aber die
Netzwerk-Schnittstelle will auch bedient werden. Der ESP32 hat zwei CPU
Kerne von denen du einen für Ethernet und den anderen für den ADC
verwenden kannst.
Willst die Daten kontinuierlich mit 2MS/s übers Ethernet senden?
Hoffentlich nicht, denn Ethernt ist dazu kaum geeignet. Auf jeden Fall
bräuchtest du dazu eine Menge Pufferspeicher.
> Ein STM32F407 oder F7xx sollte das können
Ist sicher eine gute Wahl. Da kannst du vermutlich etwas mit SPI über
DMA machen. Du brauchst allerdings Software für's Netzwerk (TCP/IP
Stack).
8 x 2 MegaSamples/s x 12 Bit = 192 MBit/s * Faktor 2 für den Overhead =~ 400 Mb/s. Da sollte dann aber schon eine Gigabit-Schnittstelle her und ein Netzwerksegment, auf dem wenig los ist.
Hallo und Danke schonmal! ich muss das mal entschärfen... beim ADC reichen mir 8 bit Auflösung und es wird nicht kontinuierlich gesendet. Ich brauche min. 7 ADC Kanäle möglichst zeitgleich. Und das alle 5ms für ungefähr 40µs. Getriggert von einem Puls und dann brauche ich 20µs vor und 20µs nach dem Puls. Deswegen wollte ich den ADC andauernd rennen und in einen Ringpuffer schreiben lassen. Gesendet wir nur auf Anforderung vom Netzwerk. Da macht es dann auch nix wenn ein paar von den Pulsen verloren gehen. Wichtiger ist dass die 7 Kanäle möglichst zeitgleich abgetastet werden und zwischen den 7er Blöcken nicht zuviel Zeit vergeht.
:
Bearbeitet durch User
Hi, ich würde dir auch einen STM32 Cortex M4 oder M7 empfehlen. Zur analogen Messung würde auch ein aktueller ATMega gut passen. Mit der passenden Konfiguration des Eventhandlers brauchst du auch kaum Rechenzeit. ADC->DMA->SPI zum STM32 alles ohne wirklichen Code. Alles durch interne Events abgedeckt. So habe ich mal ein schnelles Messystem realisiert. Ich habe mehr Zeit gebraucht die Messdaten vernünftig zu analysieren als das Gesamtsystem aufzusetzen. Gruß
Hmmm, ST hatte ich noch nie im Einsatz, was brauch ich denn da alles an Tools? So ganz habe ich die Datenverarbeitungskette vom Georg auch nicht kapiert... Bezieht sich das auf den STM32 intern? Wieso dann SPI? Für den W5500, denn der STM32 hat ja Ethernet an Bord...
Bob A. schrieb: > Kurz zum Projekt: > Benötigt wird Ethernet-Kommunikation und 8 analoge Eingänge die mit min. > 2 MS/s abgetastet werden. Und einen Timer zur Laufzeitmessung zwischen > zwei Pulsen. Kommt ein Puls, dann benötige ich die ADC-Daten von 20µS > vor dem Puls und 20µS danach. > > Ich bin noch am überlegen ob ein µC mit allem an Bord oder einer mit > externem ADC und z.Bsp. eine Wiznet W5500. Oder eine beliebige > Kombination davon. Wenn du Lust auf ein fertiges Board hast, mit einem "alles an Bord" µC, für kleines Geld (ab 20 Euro excl. MwST) bekommt man heutzutage solche Boards: https://www.st.com/en/evaluation-tools/nucleo-f429zi.html https://www.st.com/en/evaluation-tools/nucleo-f767zi.html Die µCs haben 24 ADCs, Timer, Ethernet. Für diese, und ein paar weitere Boards von ST mit Ethernet ( https://os.mbed.com/platforms/?tvend=10&pvend=10&connectivity=2 ) gibt es bereits fertig mbed OS mit einem TCP/IP-Stack. https://os.mbed.com/platforms/ST-Nucleo-F429ZI/ https://os.mbed.com/platforms/ST-Nucleo-F767ZI/ Ob das SRAM für deine 20µS Puffer ausreicht darfst du dir selber ausrechnen. mbed OS braucht natürlich auch was von dem RAM. Wenn du ein eigenes Board fertigen möchtest, kannst du trotzdem mit einem fertigen Board anfangen um zuerst einmal deine SW in den Griff zu bekommen. Zu Anfang brauchst du neben dem Board nur noch Software (mbed Toolchain, on-line oder off-line). Einen Programmer haben die Nucleo-Boards schon eingebaut. > Schick wäre natürlich auch wenn das Teil nicht schon in 2 Jahren > abgekündigt wird... Wenn du jemanden findest, der dir das garantieren kann, kannst du den bitte nach den Lottozahlen fürs Wochenende fragen? :-)
:
Bearbeitet durch User
Hannes J. schrieb: >> Schick wäre natürlich auch wenn das Teil nicht schon in 2 Jahren >> abgekündigt wird... > > Wenn du jemanden findest, der dir das garantieren kann, kannst du den > bitte nach den Lottozahlen fürs Wochenende fragen? :-) Die STM32Fxxx werden mit 10 Jahren Verfügbarkeit (ab Januar 2019) beworben, ist das denn nur Augenwischerei?
Ein Discovery Kit mit STM32F407VG (STM32F4DISCOVERY) und das passende Expansion Board (STM32F4DIS-EXT, dann hast alles was Du brauchst.
Georg X. schrieb: > ich würde dir auch einen STM32 Cortex M4 oder M7 empfehlen. > Zur analogen Messung würde auch ein aktueller ATMega gut passen. Stefanus F. schrieb: > Sehr billig und einigermaßen leicht zu programmieren sind die ESP8266 > und ESP32 Die können alle nicht 7 Kanäle gleichzeitig abtasten. Bob A. schrieb: > ST hatte ich noch nie im Einsatz, was brauch ich denn da alles an Tools? http://stefanfrings.de/stm32/index.html#software http://stefanfrings.de/stm32/index.html#proginterfaces
Also die STM32 Fanboys sind mal wieder in Höchsform :-) Ich ersetze ab jetzt "STM32" = "Jubelhurratoll" Um konstruktiv zu werden: Ich könnte als Alternative zu Jubelhurratoll folgenden empfehlen: PIC32MZ2048EFH. Der hätte mehr Flash als Jubelhurratoll und mehr und schnellere ADC. Ethernet ist auch mit dabei, ausreichend RAM steht auch zur Vefügung. Lediglich einen PHY wirst du benötigen. Ich persönlich würde mir die Sache mit Ethernet noch einmal überlegen. Für ein Bastelprojekt empfehle ich: https://www.lantronix.com/products/xport/ Damit tust du dich deutlich leichter. Ich habe das Teil schon in Serienprodukte verbaut. Grund: Sicherheit. Von Lantronix bekommt man Firmwareupdates. Desweiteren solltest du dir gut überlegen und genau rechnen, ob sich die Sache selbst mit den schnellen ADCs des PIC32MZ ausgeht, denn 8 Eingänge quasi synchron samplen wird sehr schwierig werden - je nach deinen Anforderungen. Möglicherweseise solltest du einen externen ADC in Betracht ziehen. Zur Verfügbarkeit wäre zu sagen, dass Microchip noch nie einen µC abgekündigt hat.
Zu Deiner Aufgabe: Damit bekommst Du evtl. ein billiges Multitasking hin: http://dunkels.com/adam/pt/examples.html
Es muss ja nicht gleichzeitig sein! ab 2MS/s wird der Versatz erträglich... Vorausgesetzt er bleibt von Messung zu Messung identisch Schöner wäre es natürlich schon, kuck mir grad mal den THS1007 an: 6MSps, 4 kanalig. Mit einer ausgeklügelten Anordnung der Detektoren wäre das nahezu perfekt :)
Bob A. schrieb: > Es muss ja nicht gleichzeitig sein! > ab 2MS/s wird der Versatz erträglich... Vorausgesetzt er bleibt von > Messung zu Messung identisch Im dem Fall sehe ich kein Problem. Das sollte mit den internen ADC machbar sein. Ich debugge just in dem Moment ein Projekt mit 12,5MSPS auf dem PIC32MZ. Nachdem man die ADCs mit Timern triggern kann, ist die Genauigkeit so hoch wie der Systemtakt. Solltem mit dem Jubelhurratoll (SMT32) aber auch möglich sein. Also läuft es darauf hinaus, wie du Ethernet hinbekommst. Ich rate dir dringend: Schau dir die Toolchain und die HALs der Kandidaten genau an und entscheide danach, nicht nach Lobhudelei aus dem Forum. Schließlich willst du Ethernet angehen, da wirst du die HAL brauchen. Und Hand aufs Herz, die ist bei ST UND Microchip sch.... nicht toll. Oder du pfeifst auf die HAL, und nimmst den Lantronix ;-)
Der STM32F4xx hat keine 24 ADC's sondern nur 24 Kanäle die auf bis zu 3 ADC's verbunden werden können. Also können exakt zeitgleich nur 3 Analoge Messungen stattfinden. Um 8 Kanäle zu messen muss somit 1 ADC Kanal bis zu 3x gestartet werden. Damit man eine Synchronität hin bekommt konfiguriert man 9 ADC Kanäle auf 3 ADC's und lässt diese per automatischem Trigger oder Timer getriggert immer im Kreis laufen und per DMA sich die Daten in das RAM kopieren. Jede Messung dauert ca. 6..7µS und alle 9 Werte wären nach ca. 20µS im RAM. Wenn es exakt gleich sein muss, so wird man um 8 einzelne ADC Chips nicht drum herum kommen, die per SPI (6 Stück bis zu 20MHz schnell hat der STM32) abgefragt werden. Und nein, der PIC32 hat sicher auch nicht mehr ADC's als der STM32 drin. Der Timer vom STM32F4xx kann mit bis zu 90MHz betrieben werden, das sollte ausreichend sein um bei 20µS noch eine gute Auflösung zu erhalten.
jemand schrieb: > Also die STM32 Fanboys sind mal wieder in Höchsform :-) > > Ich ersetze ab jetzt > "STM32" = "Jubelhurratoll" Ach du kleine Pfeife bist auch wieder da. Willst ein bisschen Streit? > Um konstruktiv zu werden: > Ich könnte als Alternative zu Jubelhurratoll folgenden empfehlen: > PIC32MZ2048EFH. PIC? Das ist ja wirklich ein Fanboy-Ding. Viel Spaß mit der ranzigen Toolchain. > Der hätte mehr Flash als Jubelhurratoll Die von mir erwähnten F429ZI und F767ZI haben genauso viel (2M). So, wenn du vorgibst einen konstruktiven Vorschlag zu machen, dann solltest du wenigstens deine Fakten richtig haben. > Ich persönlich würde mir die Sache mit Ethernet noch einmal überlegen. > Für ein Bastelprojekt empfehle ich: > https://www.lantronix.com/products/xport/ > Damit tust du dich deutlich leichter. Schweine-Teuer (so ab 40 Euro), absolut unnötig. > Ich habe das Teil schon in > Serienprodukte verbaut. Grund: Sicherheit. Nicht eher Inkompetenz TCP/IP selber zum Laufen zu bekommen? jemand schrieb: > da wirst du die HAL brauchen. HAL? So ein ganz Harter Junge bist du. Was glaubst du wohl, warum ich ein Embedded-OS (mbed) vorgeschlagen habe? Damit man für die schwierigen Kunststücke nicht an einer ranzigen HAL hängt. > Oder du pfeifst auf die HAL, und nimmst den Lantronix ;-) Fanboy ...
Ich kenne nur die stm32f3, die zum Teil 4x5MSPS schaffen. Z.B. Stm32f303. Allerdings haben die kein Ethernet. Ich schätze für deine Anwendung wirst du nicht um eine 2 Chip Lösung herumkommen.
jemand schrieb: > Oder du pfeifst auf die HAL, und nimmst den Lantronix ;-) Hast du Mal die gewünschte Datenrate überschlagen? 3MB/s macht das Teil bei weitem nicht mit.
Markus M. schrieb: > Jede Messung dauert ca. 6..7µS und alle 9 Werte wären nach ca. 20µS im > RAM. Wie rechnest Du hier? Die ADCs sind doch einen Tick schneller, wollen aber auch saubere Signale mit niedriger Impedanz sehen. Gut, bei acht Bits kann man auch etwas schludern. Und wenn irgendwelche "Pulse" verloren gehen, ist das auch nicht weiter schlimm (lt. TO siehe oben). > Wenn es exakt gleich sein muss, so wird man um 8 einzelne ADC Chips > nicht drum herum kommen, die per SPI (6 Stück bis zu 20MHz schnell hat > der STM32) abgefragt werden. Für Gleichzeitigkeit reichen auch entsprechend viele Sample-Hold-Stufen. Was ich angesichts des heutigen Freitags allerdings glaube, daß die "Anforderungen" mehr vom Bauch als vom Kopf bestimmt werden. Wenn es ein Einzelstück werden soll, würde ich mich allein auf die Datenerfassung konzentrieren, und die (wieso überhaupt?) abschließende Datenübertragung mit möglichst einfacher Lösung umsetzen. Die Einarbeitung in einen passenden µC wird schon genug Zeit brauchen. Wieso überhaupt Langzeitverfügbarkeit? Bauchgefühl?
> Benötigt wird Ethernet-Kommunikation und 8 analoge Eingänge die mit min.
2 MS/s abgetastet werden. Und einen Timer zur Laufzeitmessung zwischen
zwei Pulsen. Kommt ein Puls, dann benötige ich die ADC-Daten von 20µS
vor dem Puls und 20µS danach.
Da man nicht weiß wann der Trigger kommt, und man trotzdem schon
Ereignisse vor dem Trigger haben will, müssen die 8 ADCs permanent mit
2Megasamples/s durchlaufen und die Daten in einem Dual-Port-RAM
fortlaufend speichern. Der Trigger dient nur dazu intern die momentane
RAM-Speicheradresse der ADCs zu speichern und einen Interrupt für die
LAN-Übertragung von n-Bytes anzustoßen.
avr schrieb: > Hast du Mal die gewünschte Datenrate überschlagen? 3MB/s macht das Teil > bei weitem nicht mit. Das stimmt, danke für die Korrektur. Da ist bei 900kBit Schluss. Man müsste sich also genau überlegen, ob man damit hinkommt oder nicht. Der Punkt ist: Es ist schwiriger eine zuverlässige Implementierung hinzubringen, die im Kundennetzwerk SICHER funktioniert, als mal schnell ein HAL-Beispiel zu kompilieren. Darum sollte man die Sache eben vorher durchdenken. m.n. schrieb: > Wenn es ein Einzelstück werden soll, würde ich mich allein auf die > Datenerfassung konzentrieren, und die (wieso überhaupt?) abschließende > Datenübertragung mit möglichst einfacher Lösung umsetzen. Exakt. Wenn man 100h am Ethernet-Stack herumfummelt, kann man dafür einige fertige Lösungen kaufen. Es kommt eben auf die Stückzahl an.
jemand schrieb: > Solltem mit dem Jubelhurratoll (SMT32) aber auch möglich sein. Ist das nicht ein bischen voreingenommen? Ich habe mit STM, NXP und SAM in der Firma gearbeitet und alle funktionierten ausreichend gut und die Projekte wurden alle in der projektierten Zeit fertig und verkauften sich und bezahlte unsere Gehälter:-). Soo schlecht sind die STM32 nun auch wieder nicht. Gut, die CubeX braucht man ja nicht unbedingt zu verwenden und ich vermeide sie auch. Ist ja jedem freigestellt an wie viel nacktem Metall man feilen möchte. Die Errata sind in den meisten Fällen auch keine Show Stopper. Soll halt jeder verwenden was ihm gefällt. Aus der Peripheral Library oder CubeX kann man sich auch vieles Nützliche abschauen oder zumindest als Startpunkt verwenden und straffer zu verwenden. Es ist doch z.B. angenehm, ein Beispiel zu sehen wie man gewisse Module richtig initialisiert. Für die meisten Anwender funktioniert der Standard Startup Code ohne Intervention. Ausschlaggebend ist für viele Anwender nicht unbedingt der uC selber sondern die Toolchain. Und für viele Leute ist es angenehm mit TrueStudio sofort eine gebrauchsfähige Installation zu haben ohne erst ein Experte in Toolchain Konfigurierung sein müssen. Und teure Tools wie Keil oder IAR sind auch nicht unbedingt Hobbyist Metier. Wer sich selber die Tool Chain, Editor und Debugger einrichten kann - More power to you! Jeder soll halt mit dem uC seiner Wahl auf seine Weise glücklich werden. Auch wenn es ein STM32 ist:-) Vielleicht könnte man sich im Forum hier mal einigen sich über die Wahl der uC und deren Tools objektiv zu verhalten. Diese ganzen Fan Kriege sind nämlich schon lange recht nervig.
Gerhard O. schrieb: > Vielleicht könnte man sich im Forum hier mal einigen sich über die Wahl > der uC Genau dieser Wunsch führt doch zu den Glaubenskriegen. Am Ende kommt eine Einigung auf eine bestimmte µC Serie heraus und auf die werden wir dann alle festgenagelt? Lieber nicht!
Stefanus F. schrieb: > Gerhard O. schrieb: >> Vielleicht könnte man sich im Forum hier mal einigen sich über die Wahl >> der uC > > Genau dieser Wunsch führt doch zu den Glaubenskriegen. Am Ende kommt > eine Einigung auf eine bestimmte µC Serie heraus und auf die werden wir > dann alle festgenagelt? Lieber nicht! Ich verstehe nur nicht warum man sich immer herausgefordert fühlt, missionieren zu wollen. Die meisten uC sind höchstwahrscheinlich fähiger wie deren Programmierer *) :-) *) Ausnahmen natürlich ausgenommen
jemand schrieb: > Ich könnte als Alternative zu Jubelhurratoll folgenden empfehlen: > PIC32MZ2048EFH Es geht noch besser und billiger. Im LPC Debugger für 25 EUR ist ein LPC4370 mit 80 MHz ADC verbaut und drei ARM Cores. Das Debugger Board kann dafür einfach als uC Board genutzt und programmiert werden. https://www.conrad.de/de/entwicklungsboard-embedded-artists-ea-xpr-200-om13054-1027653.html https://mcu-things.com/blog/how-to-use-lpc-link2/
Lothar schrieb: > Das Debugger Board > kann dafür einfach als uC Board genutzt und programmiert werden. Das ist ein toller Vorschlag. Bastelboards mit LPC sind nämlich nicht so leicht zu bekommen. Weisst du zufällig, wo man als Endverbraucher passende Stecker bekommt?
Watterott hat einige LPC Boards im Programm, Mouser auch. https://www.watterott.com/de/10-pin-to-20-pin-JTAG-Adapter https://www.watterott.com/de/10-posIDC-Ribbon-Cable-50-MIL https://www.watterott.com/de/20-pos-IDC-Ribbon-Cable-50-mil Bei den LPC ist die 51xxx Serie die neuere, wenn dann würde ich mich da umsehen. ST ist mit seinen Nucleo Evalboards aber unschlagbar günstig, die haben definitiv das bessere Marketing.
Johannes S. schrieb: > ST ist mit seinen Nucleo Evalboards aber unschlagbar günstig, > die haben definitiv das bessere Marketing. Tja, das ist wohl wahr. ST hat jahrelang ein sehr aggressives Marketing veranstaltet und man sieht, daß sie damit durchaus Erfolg haben: Die meisten Beiträge hier in diesem Forum setzen Arm-Cortex schlichtweg gleich mit STM32. Dennoch gibt's hier etwas anzumerken: gerade bei den STM32 ist noch immer ein großer Teil der Peripherie nur 16 bittig und das stört gelegentlich. Ein großer Vorteil für Leute, die Angst vor Hardware haben oder sowas schlichtweg nicht können, sind die diversen Discovery-Boards von ST - ungeachtet des Umstandes, daß diese Dinger für das Entwickeln eines echten Gerätes ziemlich ungeeignet sind. Aber dafür wurden sie ja auch nicht gemacht. Was mir allerdings seltsam vorkommt ist das: Bob A. schrieb: > Welcher Hersteller ist denn aktuell zu empfehlen, oder schenken die sich > alle nix? Was ist das für eine Herangehensweise? Wenn man ein Projekt sich vornimmt, dann sollte man auch über eine adäquate Fähigkeit verfügen, selbst bei den eventuellen Zulieferern nachzulesen, was die denn so im Programm haben, was deren Chips können und kosten und wo man sie beziehen kann. Und wenn man ADC's im MSPS-Bereich andenkt, dann sollte auch genug Hardware-Können dahinterstecken, was das Erstellen einer passenden LP beinhaltet und damit alle Evalboards für dieses Projekt obsolet macht. Aber davon habe ich hier nix gelesen. Meine Vorschläge wären, sich auch mal bei den LPC von NXP, sowie den Chips von Freescale, den Chips von Nuvoton und den PIC32 umzusehen. Da sind eben auch Chips mit rund 200 MHz Takt und/oder 2 CPU's und/oder Cache dabei, die dann auch eine 32 bittige Peripherie haben. Also: Selberlesen macht klug. Auf die hiesigen Fanboys zu hören eher nicht. W.S.
W.S. schrieb: > Aber davon habe ich hier nix gelesen. Die Vorgaben sind eben sehr wabbelig. Sie lassen sich durchaus so interpretieren, daß zu einem Triggerimpuls sämtliche ADC-Daten von -20 µs bis +20 µs im 0,5 µs Abstand ausgegeben werden sollen. Das sind insgesamt 81 Werte pro Kanal. Das kann man nur erreichen, wenn pro Kanal ein eigener µC mit hinreichend schnellem ADC werkelt, der die anfallenden Werte per DMA in einen internen Ringpuffer schreibt. Das Auslesen der 8 x µCs hat dann wieder etwas Zeit (5 ms) und ginge mit SPI wohl sehr einfach. Das hieße aber auch, nicht zu kleckern, sondern zu klotzen! Ich bezweifele allerdings, ob der TO sein "neues Projekt" so aufwendig umsetzen möchte. Daher sage ich auch nicht, daß ein Arduino hier keine Lösung ist und welche STM32 ich empfehlen würde ;-)
m.n. schrieb: > W.S. schrieb: >> Aber davon habe ich hier nix gelesen. > > Die Vorgaben sind eben sehr wabbelig. > Sie lassen sich durchaus so interpretieren, daß zu einem Triggerimpuls > sämtliche ADC-Daten von -20 µs bis +20 µs im 0,5 µs Abstand ausgegeben > werden sollen. Das sind insgesamt 81 Werte pro Kanal. > > Das kann man nur erreichen, wenn pro Kanal ein eigener µC mit > hinreichend schnellem ADC werkelt, der die anfallenden Werte per DMA in > einen internen Ringpuffer schreibt. Das Auslesen der 8 x µCs hat dann > wieder etwas Zeit (5 ms) und ginge mit SPI wohl sehr einfach. > Das hieße aber auch, nicht zu kleckern, sondern zu klotzen! > > Ich bezweifele allerdings, ob der TO sein "neues Projekt" so aufwendig > umsetzen möchte. > Daher sage ich auch nicht, daß ein Arduino hier keine Lösung ist und > welche STM32 ich empfehlen würde ;-) Klarer Fall für FPGA. Microcontroller sind wie ein Leatherman Universalwerkzeug. Kann Vieles, aber für genaue Ergebnisse kauft man sich doch besser das richtige Spezialwerkzeug. Genauso ist es mit uC. Viele anfallende Aufgaben lassen sich mehr oder weniger gut lösen. Aber wenn es wirklich gut funktionieren soll und anspruchsvoll ist, dann greift man besser doch zu gezielt entwickelten Lösungen mit hohen Aufwand und Kosten = HP oder R&S:-) . Seid froh, daß uC auch so viele Aufgaben bewältigen können. Möglicherweise ist es unrealistisch immer die Grenzen des Möglichen als Argumentation gegen eine bestimmte Wahl vorzubringen. Was mich betrifft, bin ich froh eine so große Auswahl an uC zu haben um meine meisten anfallenden Designprobleme zu bewältigen. ...
:
Bearbeitet durch User
Uiuiui da hab ich aber so nebenbei noch in einem schönen Wespennest rumgestochert... Äusserst interessant finde ich ja das der Wunsch von Gerhard O. doch etwas mehr Objektiviät in die Diskussion zur µC Wahl gleich mal um ein paar Worte gekappt wurde. Weitere Missverständnisse vorporgrammiert :) Ich gestehe aber auch dass ich die Anforderungen besser hätte definieren müssen! Und nicht so verstreut im Verlauf der Diskussion... Und um die Frage von W.S. zu beantworten: Gerade die Abtastrate der internen ADC's habe ich in den parametrischen Tabellen mancher Hersteller vermisst. Außerdem ging es mir auch um das "Drumherum" also Toolchain, Libraries (besonders bei Ethernet) und Support. Specs lese und vergleichen kann ich auch, da ich aber wenig verschiedene µC bisher gesehen habe hoffte ich ein paar Infos zu hören wie Ethernet ist bei XXX besonders einfach umzusetzen weil die gute Libs/Beispiele mitliefern. Oder das ADC-DMA-Handling bei YYY ist sehr gut gelöst und schnell integriert. Sehr gerne mit Argumenten unterlegt :) Und ich habe ja auch die Optionen mit externen ADC und einem per SPI ansteuerbaren Ethernet-Chip in die Diskussion gebracht. Aber nochmal zu den ADC-Anforderungen: 8 Kanäle mit nicht mehr als 0,5µs Versatz abtasten (gerne auch < 0,2µs; schneller ist kaum erforderlich). Ich brauche +-20µs Daten um eine Triggerevent, also muss der ADC permanent rennen und möglichst fix (also per DMA) einen oder abwechselnd zwei Ringpuffer beschreiben. Mit dem Triggerevent werden die Daten umgeschrieben / Ringpuffer geswitched. "irgendwann" kommt eine Anforderung per Ethernet (ob UDP, TCP/IP, Telnet oder was auch immer ist noch nicht festgelegt, prinzipiell alles denkbar). Die Daten werden übertragen, dabei ist es irrelevant ob ein oder mehrere Triggerevents "verschluckt" werden. Nach der Übertragung geht der µC wieder in den Abtastmodus bis zur nächsten Anfrage. Zwischen den Anfragen liegen immer sicher mehr wie 5ms - bis hin zu mehreren Sekunde. Eine LP für dieses Proejkt zu erstellen traue ich mir sicher zu, hab auch schon Gbit-Ethernet gemacht und Systeme mit 32 ADC-Kanälen in 16bit und 1MSps. Alles sicherlich verbesserungswürdig, man lernt ja mit jedem Projekt dazu! Allerdings finde ich es immer angenehm mit einem Eval-board zu starten, ist halt bequem... An Langzeitverfügbarkeit denke ich da es durchaus möglich ist dass das System in Kleinserie (<10 p.a.) zum Einsatz kommt. Hat es eigentlich einen Grund dass bisher keiner Atmel erwähnt hat? Lustigerweise der einzige Hersteller von dem ich in bei den letzten Projekten µC verwendet habe... Und dass ich hierfür 8µC brauche ist gelinde gesagt übertrieben. Wie m.n. erwähnt würde für Gleichzeitigkeit auch eine 8-fach S&H reichen. Das möchte ich mir aber sparen da es so zeitkritisch eben nicht ist! Ich hoffe ich konnte etwas Licht ins Dunkel bringen
Bob A. schrieb: > 8 Kanäle mit nicht mehr als 0,5µs Versatz abtasten (gerne auch < 0,2µs; > schneller ist kaum erforderlich). > Ich brauche +-20µs Daten um eine Triggerevent, Ich weiß jetzt immer noch nicht, was Du willst. Bob A. schrieb: > Die Daten werden übertragen, dabei ist es irrelevant ob ein oder mehrere > Triggerevents "verschluckt" werden. Was soll das denn? Wenn ab und zu etwas nicht funktioniert, ist es egal? Bob A. schrieb: > Und dass ich hierfür 8µC brauche ist gelinde gesagt übertrieben. Wie > m.n. erwähnt würde für Gleichzeitigkeit auch eine 8-fach S&H reichen. Wenn ich es richtig verstehe, brauchst Du sogar einen 9. µC, der die Daten einsammelt und weiterleitet. Bob A. schrieb: > Hat es eigentlich einen Grund dass bisher keiner Atmel erwähnt hat? > Lustigerweise der einzige Hersteller von dem ich in bei den letzten > Projekten µC verwendet habe... Atmel gibt es dafür nicht mehr. Wenn Du AVR meinst, die sind viel zu langsam. Bob A. schrieb: > Ich hoffe, ich konnte etwas Licht ins Dunkel bringen. Bei mir nicht. Wieviel AD-Werte fallen insgesamt für einen Triggerimpuls für alle Kanäle an?
LTC2324 als Frontend, der tastet 4 Kanäle gleichzeitig mit 2MHz ab. Davon soviel du brauchst. Das Auslesen müsste noch mal überdacht werden. Vielleicht läßt sich QSPI Interaface dafür nehmen. Der W5500 klappt gut, die Frage wäre wie schnell die Daten verschickt werden müssen.
Schorsch X. schrieb: > LTC2324 als Frontend, der tastet 4 Kanäle gleichzeitig mit 2MHz > ab. Der STM32 ist viel besser. Das ist der Standart, weil er von ARM ist.
m.n. schrieb: > Ich weiß jetzt immer noch nicht, was Du willst. Logo, er hat's ja auch niemandem verraten. Aber ich schätze, er will eine Art Kurzzeit-Signal-Logger machen, der für etwa 40 µs 8 Signale im 500 ns Takt aufzeichnet. Triggerpunkt mittendrin. Und Auswertung dann hinterher. Offenbar ein Test auf "Gleichzeitigkeit" von 8 Signalen. Könnte ein Richtungspeiler werden, oder ein Windmesser oder so was Ähnliches. m.n. schrieb: > Die Vorgaben sind eben sehr wabbelig. Eben! Ich krieg langsam Pickel, wenn ich sowas lese. Hier gibt es viel zu viele Leute, die so aussehen, als ob sie mal grad krabbeln können, aber sie wollen sich ne Rakete bauen und damit bis zum Mond (und vermutlich auch zurück) fliegen. Immerzu mehr abbeißen, als man schlucken kann. Wie gesagt: bin grad dabei, mich zu ärgern. Ansonsten riecht mir das Ansinnen eher nach einem CPLD, einem RAM und 8 separaten ADC's als nach einem µC. W.S.
W.S. schrieb: > m.n. schrieb: >> Ich weiß jetzt immer noch nicht, was Du willst. > > Logo, er hat's ja auch niemandem verraten. Aber ich schätze, er will > eine Art Kurzzeit-Signal-Logger machen, der für etwa 40 µs 8 Signale im > 500 ns Takt aufzeichnet. Triggerpunkt mittendrin. Und Auswertung dann > hinterher. Was hab ich den vergessen zu spezifizieren? Was du schreibst ist haargenau das was ich angegeben habe, nur umformuliert. Gut, eine kleine Fehlinterpretation gibt es : Auswertung kann man getrost durch Übertragung ersetzen. Ausgewertet wird in einem übergeordneten System. Und dass Triggerevents während der Übertragung ignoriert werden dürfen bedeutet doch nicht dass etwas "nicht funktioniert". Es gibt eben nur keine harte Forderung alle 5ms frische Daten zu haben! Dass so mancher für diese Aufgabe eine CPLD/ein FPGA nehmen würde ist ja auch schon ein guter Hinweis. Danke dafür! Allerdings bin ich mir nicht sicher ob der Vorschlag darauf beruht dass die Forderungen falsch verstanden und zu hart interpretiert wurden...
Eigentlich hätte ich fragen sollen: Wie sind die Erfahrungen mit den aktuellen Toolchains diverser µC-Hersteller... und dass Atmel nun unter Microchip firmiert wird ändert doch nix daran dass es die ATSAMXXX-Chips noch gibt? Erfahrungen und Meinungen dazu habe ich hier nicht gelesen, hat mich etwas gewundert und ich wollte nach dem Grund fragen.
Was auch noch nicht ganz unwichtig ist, wie viel Auflösung wird denn benötigt. Oder habe ich das überlesen? Ich könnte mir auch z.B. 8 SH-Schaltungen, Analog-Multiplexer und einen schnellen externen ADC vorstellen. Dazu ein CPLD als Sequenzer, welches z.B. mit 18MHz aus einem µC Timer versorgt wird. Also 1 Takt S/H und 8 Takte Auslesen je Zyklus, das kommt dann auf 2MHz Samplerate. Ein STM32F4... !ZUM BEISPIEL! hätte dann bei 144 MHz Taktfrequenz 8 Zyklen, um die Daten von den GPIO zu lesen und in einen Ringpuffer zu schreiben. Und während des S/H-Taktes könnte z.B. die Triggerbedingung anhand der letzten Werte berechnet werden. Jörg
Joerg W. schrieb: > Ich könnte mir auch z.B. 8 SH-Schaltungen, Analog-Multiplexer und einen > schnellen externen ADC vorstellen. Da finde ich die Methode von Cäsar doch viel hilfreicher: parte et divide. Je ein kleiner µC sammelt die Daten eines Kanals. Interner S&H, ADC und DMA-Transfer sammeln die Daten völlig ungestört, ohne daß das Timing kritisch wird. Ein neuerer STM32G070 kostet < 2 €. Als Entwicklungsumgebung reicht eine kostenlose IDE von Keil oder IAR, selbst, wenn damit nur 4 oder 8 KB Code erzeugbar sind.
m.n. schrieb: > Als Entwicklungsumgebung reicht eine kostenlose IDE von Keil oder IAR, > selbst, wenn damit nur 4 oder 8 KB Code erzeugbar sind. Die Zeiten sind vorbei. Mittlerweile gibts Atollic Truestudio kostenlos und ohne Beschränkungen der Codegrösse: https://atollic.com/
Bob A. schrieb: > und dass Atmel nun unter Microchip firmiert wird ändert doch nix daran > dass es die ATSAMXXX-Chips noch gibt? > Erfahrungen und Meinungen dazu habe ich hier nicht gelesen, hat mich > etwas gewundert und ich wollte nach dem Grund fragen. Die ATSAM sind weit verbreitet, die neueste Produktlinie sind die SAM4. Die sind mitnichten tot oder vergessen, nur halt nicht bei Bastlern verbreitet. Das Problem is die Verzerrte Wahrnehmung in diesem Forum. Es gibt halt nur STM32, AVR und PIC. Schon die Pic werden alle in die stinkende PIC16-Tonne gekloppt, weil die Leute keine Ahnung haben. Die Realität in der Industrie hat damit NICHTS zu tun. STM32 sind mitnichten "Standard", es gibt eine Vielzahl von gebräuchlichen Serien. Darum wäre mein Rat auch: Lass dich vom Forum hier nicht etwas aufdrücken, was du möglicherweise nicht haben willst. Schau dir die Toolchains und Datenbläter der µC an und entscheide selber. Womit DU die Probleme gelöst bekommst und was DIR Spass macht, ist relevant. Gelöst bekommst du dein Problem mit vielen verschiedenen Serien. Einige µC-Serien haben für Bastler sehr schöne Eigenschaften: Bei den LPCx (und PIC24) ist das zum Beispiel das Peripheral Remapping, welches das Platinendesign mit 2 Lagen stark vereinfacht. Cypress PSOCs sind sehr flexibel, was die Peripherie angeht. Und binde dich nicht auf die Community hier. Fast jeder Hersteller hat ein Forum zu seinen µC, schau erst mal da rein. Ich bin NUR dort unterwegs, was µC-Fragen angeht.
Matthias S. schrieb: > Die Zeiten sind vorbei. Mittlerweile gibts Atollic Truestudio kostenlos > und ohne Beschränkungen der Codegrösse: Ich werde es mir ansehen. Insbesondere da: Added support for STM32G070, STM32G071 and STM32G081 devices Die gibts nämlich auch bastelerfreundlich im LQFP32. Frühere Installationen hatte ich allerdings wieder gelöscht. ... Aktuell regt sich bei "Download Installer" garnichts :-( soso... schrieb: > Lass dich vom Forum hier nicht etwas aufdrücken, Hier wird nichts aufgedrückt, es sei denn, Du kannst Dir keine eigene Meinung bilden.
m.n. schrieb: > Matthias S. schrieb: >> Die Zeiten sind vorbei. Mittlerweile gibts Atollic Truestudio kostenlos >> und ohne Beschränkungen der Codegrösse: > > Ich werde es mir ansehen. Über Umwege (anderer Rechner) habe ich die Installationsdatei (750 MB) bekommen. Ein Projekt - für den H750 mit Cubex erzeugt - läuft unter EWARM8 wie erwartet. Für Atollic Truestudio erzeugter Code liefert beim Build: Internal error ... Dann werde ich auch diese Version wieder löschen ;-)
m.n. schrieb: > Für Atollic Truestudio erzeugter Code liefert beim Build: > Internal error ... Ich verwende derzeit normales Eclipse mit c++ plugins und den OpenSTM plugins (direkt in eclipse installiert, nicht mit dem SystemWorkbench4STM32). Funktioniert bei mir sehr zuverlässig und hat auch schon support für STM32G0. In eclipse muss dazu diese Seite: http://ac6-tools.com/Eclipse-updates/org.openstm32.system-workbench.update-site-v2 als repository in add new software hinzugefügt werden
:
Bearbeitet durch User
Stefanus F. schrieb: > Die System Workbench ist doch Eclipse mit ac6 Tools, oder nicht? Ja aber hatte bei mir einige Probleme, dann habe ich die tools direkt in meine normale eclipse installation hinzugefügt und es läuft problemlos
Alex D. schrieb: > Stefanus F. schrieb: >> Die System Workbench ist doch Eclipse mit ac6 Tools, oder nicht? > > Ja aber hatte bei mir einige Probleme, dann habe ich die tools direkt in > meine normale eclipse installation hinzugefügt und es läuft problemlos Ich habe gerade mal meine System Workbench upgedated, klappte ohne Probleme.
Bob A. schrieb: > Dass so mancher für diese Aufgabe eine CPLD/ein FPGA nehmen würde ist ja > auch schon ein guter Hinweis. Danke dafür! > Allerdings bin ich mir nicht sicher ob der Vorschlag darauf beruht dass > die Forderungen falsch verstanden und zu hart interpretiert wurden... Die Frage ist halt immer wie genau ist genau genug und wenn ein Kriterium ist, "möglichst zeitgleich" mehrere Dinge auf einmal zu erledigen, sprich mehrere AD-Kanäle zu sampeln, auszuwerten und zu verschicken, dann kommt schon automatisch ein FPGA in den Sinn. Wenn man jetzt keine großen Anforderungen bezüglich Jitter hat, mit 8bit Auflösung leben kann und bei den 40us/5ms Abtastintervall bleibt, dann sollte das auch ganz gut, wie schon vorgeschlagen mit je einem Mikrocontroller pro Kanal gehen. Einfach einen Controller mit schnellem ADC pro Kanal, z.B. STM32F303 und irgendeinen Mikrocontroller oder Mikroprozessor, der den ganzen Kram, z.B. per SPI ausliest und per Ethernet weitergibt. Wenn man einen einzelnen ADC multiplext hat man mitunter das Problem, das der Kondensator im ADC nicht schnell genug umgeladen werden kann, wenn sich die Pegel von aufeinander folgenden Kanälen stark unterscheiden. Da hat man dann definitiv höhere Ansprüche an das Frontend.
Bin gerade über den THS1007 (http://www.ti.com/lit/ds/symlink/ths1007.pdf) gestolpert. Sind zwar "nur" 4 Kanäle, dafür kriege ich die alle 667ns. Parallel-Interface, also problemlos schnell einzulesen. Damit sollte die Aufgabe doch zu lösen sein! Es gibt sogar eine Variante mit FIFO (THS1064; http://www.ti.com/lit/ds/symlink/ths10064.pdf) Das dürfte sogar der SAMD21 schaffen, den ich schon in 2 anderen Projekten benutzt habe :) Grüßle, Bob
Bob A. schrieb: > Sind zwar "nur" 4 Kanäle, dafür kriege ich die alle 667ns. > Parallel-Interface, also problemlos schnell einzulesen. Zuvor wurden 500 ns bzw. sogar 200 ns gefordert, und das für alle acht Kanäle gleichzeitig. Die werden mit diesen Teilen nicht erreicht. Wie auch immer: nimm sie und nimm den SAMD21. Dann sind Deine Probleme vorerst gelöst. Das Datenblatt stammt aus dem Jahr 2002. Für Langzeitverfügbarkeit solltest Du Dir einen tray in die Schublade legen.
m.n. schrieb: > Bob A. schrieb: >> Sind zwar "nur" 4 Kanäle, dafür kriege ich die alle 667ns. >> Parallel-Interface, also problemlos schnell einzulesen. > > Zuvor wurden 500 ns bzw. sogar 200 ns gefordert, und das für alle acht > Kanäle gleichzeitig. Die werden mit diesen Teilen nicht erreicht. > > Wie auch immer: nimm sie und nimm den SAMD21. Dann sind Deine Probleme > vorerst gelöst. Das Datenblatt stammt aus dem Jahr 2002. Für > Langzeitverfügbarkeit solltest Du Dir einen tray in die Schublade legen. Ohjee, mir dämmert wo die ganze Verwirrung um die Specs herkam: 500ns, bzw 200ns ist das delay von Kanal zu Kanal! Also bei 8 Kanälen 1,6µs bis 4µs für alle 8. Ich muss wohl doch noch etwas besser lernen mich eindeutig auszudrücken :/ Und vielen Dank für den Hinweis auf das Datenblatt-Datum! Ich verfolge besser auch den Ansatz "FPGA und 8 einzelne ADCs" weiter
Bob A. schrieb: > 500ns, bzw 200ns ist das delay von Kanal zu Kanal! > Also bei 8 Kanälen 1,6µs bis 4µs für alle 8. Das ist schon heftig: eine Luftnummer! Ich hatte ganz gezielt danach gefragt und W.S. und ... und ... hatten es auch so verstanden, daß 81 Werte binnen 40 µs pro Kanal geliefert werden sollen. So schafft das auch ein einzelner µC. Und wenn man ein bisschen geschickt programmiert, kann man den Versatz beim Wandeln auch herausrechnen.
Tut mir leid, das ist in den ganzen hitzigen Diskussionen die zum Teil, abseits von´m Thema geführt wurden wohl untergegangen :( als ich schrub "8 Kanäle mit nicht mehr als 500ns Versatz" war das auf den Versatz zwischen den Kanälen und nicht zwischen den 8er Blöcken gemünzt. Sind ja dann auch 81 Werte pro Kanal, aber mit zeitlichem Versatz zwischen den Kanälen. Verieinfacht mit 4 Werten pro Kanal wäre das dann sowas:
1 | |
2 | Kanal 1 x x x x |
3 | Kanal 2 x x x x |
4 | Kanal 3 x x x x |
5 | Kanal 4 x x x x |
6 | Kanal 5 x x x x |
7 | Kanal 6 x x x x |
8 | Kanal 7 x x x x |
9 | Kanal 8 x x x x |
Allerdings, je kleiner die Zeit zwischen den Kanälen desto gut. Ich werde den THS10064 auf jeden Fall antesten. Das würde dann ja so aussehen:
1 | |
2 | Kanal 1 x x x x |
3 | Kanal 2 x x x x |
4 | Kanal 3 x x x x |
5 | Kanal 4 x x x x |
6 | Kanal 5 x x x x |
7 | Kanal 6 x x x x |
8 | Kanal 7 x x x x |
9 | Kanal 8 x x x x |
Bob A. schrieb: > Ich verfolge besser auch den Ansatz "FPGA und 8 einzelne ADCs" weiter Das würde ich dir nicht empfehlen. Fpgas bringen die Komplexität nochmals auf ein höheres Level. Die nimmt man wenn man sie braucht, aber in der Regel nicht aus als Spaß. Bei deinem Vorwissen würde ich bei dem 4fach parallel ADC bleiben. Oder den vorgeschlagenen ltc ADC nehmen. Von Lösungen mit mehreren Mikrocontrollern würde ich auch abraten, da arbeitest du an mehreren Baustellen gleichzeitig.
avr schrieb: > Von Lösungen mit mehreren > Mikrocontrollern würde ich auch abraten, da arbeitest du an mehreren > Baustellen gleichzeitig. Dann machst Du etwas falsch oder hast es nicht verstanden. Du programmierst ja auch nicht eine Anwendung und schreibst danach die passende LIB dazu. Oder doch?
Bob A. schrieb: > Allerdings, je kleiner die Zeit zwischen den Kanälen desto gut. > Ich werde den THS10064 auf jeden Fall antesten. > > Das würde dann ja so aussehen: > Kanal 1 x x x x > Kanal 2 x x x x > Kanal 3 x x x x > Kanal 4 x x x x > Kanal 5 x x x x > Kanal 6 x x x x > Kanal 7 x x x x > Kanal 8 x x x x Eine solche Messung würde mit einem Mikrocontroller mit 4 ADCs auch ohne Probleme gehen. Der STM32F303 wäre so einer, ob es ATSAMs mit 4 ADCs gibt weiß ich leider nicht, kenn mich da nicht gut aus, das gleiche für PIC32. Ist allerdings etwas mehr Software Aufwand und vor allem: Umstellung auf einen anderen µC, das kann dann schon mal dauern.
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.