Hallo, bei einem ca. 10 Jahre alten Produkt habe ich den PIC32MX verwendet. Ein aktuelles neues Produkt verwendet den PIC32MZ. Ich habe den Eindruck, dass von Microchip in Zukunft die ATSAM Baureihe mehr forciert wird. Da ja hier überwiegend ATMEL Fans und nur wenige PIC Liebhaber im Forum sind, frage ich einfach mal nach eurer Meinung, welche 32 Bit MCU Ihr für ein neues Projekt einsetzen würdet ? Eine Alternative wäre sicher die STM32 Reihe, aber dann muss man sich in eine neue IDE einarbeiten...
Dirk F. schrieb: > frage ich einfach mal nach eurer Meinung, Da es offenkundig keinerlei Anforderungen gibt, würde ich irgend eine beliebige nehmen. Denn die erfüllt automatisch alle.
Dirk F. schrieb: > welche 32 Bit MCU Ihr > für ein neues Projekt einsetzen würdet ? Einen mit dem ich schon Erfahrungen gesammelt habe. Dirk F. schrieb: > Ich habe den Eindruck, dass von Microchip in Zukunft die ATSAM Baureihe > mehr forciert wird. Naiv gefragt: Wie kommst du darauf?
Dirk F. schrieb: > Da ja hier überwiegend ATMEL Fans und nur wenige PIC Liebhaber im Forum > sind, Ach?
Ganz klar PIC32MX oder PIC32MZ; MK gibt es auch noch. Praktische Erfahrung ist durch nichts zu ersetzen. Dirk F. schrieb: > Ich habe den Eindruck, dass von Microchip in Zukunft die ATSAM > Baureihe mehr forciert wird. Na und? Die STM32 werden noch viel mehr forciert, aber: https://www.microchip.com/en-us/support/quality/product-longevity > Eine Alternative wäre sicher die STM32 Reihe, aber dann muss man sich in > eine neue IDE einarbeiten... Wobei die IDE das kleinste Übel wäre, gerade die STM32 funktionieren ganz einfach auch ohne IDE. Aber ein paar nicht so offensichtliche Feinheiten muss man erstmal lernen, z.B. vertragen 5 Volt tolerante Eingänge keine 5 Volt. Und gerade wenn man denkt "das sieht ja genauso aus wie beim PIC", tut's das nicht.
Dirk F. schrieb: > aber dann muss man sich in > eine neue IDE einarbeiten... Dann verwende Visual Studio Code, damit kann du fast jede MCU programmieren.
Obelix X. schrieb: > Dann verwende Visual Studio Code, damit kann du fast jede MCU > programmieren. Damit kannst Du zunächst gar keinen µC programmieren. Das geht erst, wenn man entsprechende Erweiterungen installiert. Und die haben's in sich, weil jede eine komplett andere Philosophie verfolgt - PlatformIO ist so ein Ansatz, bei dem man sehr viele (versteckte) Abhängigkeiten hat, und letztlich wieder eine komplett eigene IDE erhält, die sich von anderen Ansätzen unterscheidet. Genauso könnte man zu Eclipse raten. Dirk sollte einfach das verwenden, was er kennt. Wenn er mit Entwicklungssystemen für 32-Bit-PIC klargekommen ist, ist die Lernkurve am flachsten, wenn er einfach bei 32-Bit-PIC bleibt. Microchip wird die nicht einstellen. Klar, universeller aufgestellt ist man, wenn man irgendeinen ARM verwendet, der via SWD o.ä. programmierbar ist, und man dafür nicht eine vom Hersteller angebotene IDE, sondern etwas unabhängiges verwendet. Dann hat man halt auch nicht die Codegeneratoren à la CubeMX oder MCUXpresso, sondern muss/darf sich die Grundlagen und die nichttriviale Konfiguration selbst erarbeiten. Da Dirk nicht erwähnt hat, was er vorhat, oder welche Anforderungen er hat, kann man ihm letztlich auch nicht zu irgendwas passendem raten.
Dirk F. schrieb: > welche 32 Bit MCU Ihr für ein neues Projekt einsetzen würdet ? STM32G4 > Eine Alternative wäre sicher die STM32 Reihe, aber dann muss man sich in > eine neue IDE einarbeiten... Ich finde die CubeIDE eigentlich selbsterklärend. Ich habe damit sofort loslegen können - ganz im Gegensatz zu Eclipse. Ach ja, die ATMegas programmiere ich inzwischen Notepad++, AVRGCC und Avrdude.
Bauform B. schrieb: > z.B. vertragen 5 Volt tolerante Eingänge keine 5 Volt. Doch tun sie, wenn man es richtig macht.
Auch die Programmierfähigkeit in circuit an deinen Anforderungen ausrichten (SWD, UART) wer will schon mit JTAG arbeiten.
:
Bearbeitet durch User
Johnny B. schrieb: > Bauform B. schrieb: >> z.B. vertragen 5 Volt tolerante Eingänge keine 5 Volt. > > Doch tun sie, wenn man es richtig macht. Glaubt man, wenn man das Problem noch nicht verstanden hat.
Michael B. schrieb: > Johnny B. schrieb: >> Bauform B. schrieb: >>> z.B. vertragen 5 Volt tolerante Eingänge keine 5 Volt. >> >> Doch tun sie, wenn man es richtig macht. > > Glaubt man, wenn man das Problem noch nicht verstanden hat. Spannend. Nenn mal ein paar Details. Wir hatten bisher noch keine Probleme damit aber ich wäre gern vorbereitet. Die MIPS PICs haben halt den Nachteil dass das Ökosystem außen rum relativ gesehen recht klein ist. Cortex-M und langsam auch RISCV sind da besser aufgestellt. Für Hobby bei dem bleiben was man kennt. Für Industrieeinsatz kommen da ein paar mehr Parameter dazu die eine pauschale Aussage schwierig machen.
Dirk F. schrieb: > Eine Alternative wäre sicher die STM32 Reihe, aber dann muss man sich in > eine neue IDE einarbeiten... Das muss man sowieso. MPLAB 8, MPLAB X, jetzt kommt Visual Studio Code. Bestimmt wird da alles paar Jahre etwas neues ausgedacht. Wie ich Microchip kenne, wird alles immer grösser und langsamer. Debuggen immer instabiler.
Moin, Andras H. schrieb: > Das muss man sowieso. MPLAB 8, MPLAB X, jetzt kommt Visual Studio Code. > Bestimmt wird da alles paar Jahre etwas neues ausgedacht. Bisher (letzten 30 Jahre) bin ich auf ziemlich vielen verschiedenen CPU/µC von attiny13a bis aarm64/x86_64 und momentan auch stm32 mit vim, make und x-y-z-gcc und Konsorten nicht zu schlecht gefahren. Ich hab' eigentlich nicht vor, das nochmal zu aendern. Da greift dann schon mein Altersstarrsinn ;-) Will sagen: Ich finde die IDE ein ganz schlechtes Argument zur Auswahl von CPU/µC. Gruss WK
Μαtthias W. schrieb: > Michael B. schrieb: >> Johnny B. schrieb: >>> Bauform B. schrieb: >>>> z.B. vertragen 5 Volt tolerante Eingänge keine 5 Volt. >>> >>> Doch tun sie, wenn man es richtig macht. >> >> Glaubt man, wenn man das Problem noch nicht verstanden hat. > > Spannend. Nenn mal ein paar Details. Halt Stopp, falsche Abteilung, da geht's lang: Beitrag "STM32: 5 Volt tolerante Eingänge sind es nicht"
Obwohl ich mich seit 10 Jahren nicht mehr mit MCs beschäftigt habe, hat mich jetzt ein, zugegeben einfaches, privates Projekt dazu gezwungen. Als erstes habe ich geschaut, wo ich einen möglichst billigen Debug- und Programmieraddapter erhalte. Ohne richtiges Debuggen möchte ich keinen MC anfassen. Da mich auch noch 32 Bit und RISC-V reizten, bin ich beim CH32V006 und der IDE des Herstellers gelandet. Mit Adapterplatine. Die IDE ist simpel und funktioniert ohne Nachdenken. Viel besser als Platformio. Bei der Umstellung auf C++ muss man zusätzlich die include Pfade von C nach C++ übertragen.
Dirk F. schrieb: > Da ja hier überwiegend ATMEL Fans und nur wenige PIC Liebhaber im Forum > sind, frage ich einfach mal nach eurer Meinung, welche 32 Bit MCU Ihr > für ein neues Projekt einsetzen würdet ? STM32H723
Meine persönliche Meinung: STM32 und ESP32. Beides unter VSCode. VSCode kann per Project konfiguriert werden, da ist also auch eine Bunte Mischung möglich, so kann man ESP32 mit PlatformIO, ein anderes ESP32 Project aber auch mit ESP-IDF lösen, ein drittes vielleicht Bare-Metal oder FreeRTOS. Ach verschiedene Linux-Projekte habe ich auch in VSCode. Inzwischen manage ich ESP32, STM32, IMX6, RockChip und ZynqMP Projekte komplett in VSCode. Es hilft sich die Projekte etwas zu sortieren und Start-Icons zu bauen, die dann die Project Init verlinken als Parameter oder eben manuell zwischen Workspaces zu wechseln. Ich bin nach ca 15 Jahren von Eclipse umgestiegen auf VSCode, da ich durch die Arbeit dazu gezwungen wurde. Auch Eclipse ist nur durch entsprechende Addons gut brauchbar, ebenso wie VSCode. Aber inzwischen bin ich auch privat auf VSCode.
Falk B. schrieb: > Ich empfehle die 20 Bit Prozessoren von Bitburger ;-) Erinnert ein wenig an den alten Spruch aus der Harald Schmitt Show:
1 | · Das neue Windows95 kann alles besser Dank 32 Bit. |
2 | · Also wenn ich 32 Bit hatte, glaube ich auch alles besser zu können! |
Maxim B. schrieb: > STM32H723 Ja, genau! Die muss es sein. Egal wofür, egal für was. Die isses!!!111elf Wenn man bei den PIC32 beleiben will, weil man damit gute Erfahrungen hat, mit der IDE zufrieden ist, möglicherweise sogar Harmony verwendet ... dann stellt sich für mich die Frage etwas anders. Nicht ob MX/MZ 1er, 2er ,,, sondern ob der µC bestmöglich zu dem passt was ich machen will. Wer braucht Ethernet, wenn er keines braucht. :-) Wenn man 6 * USART braucht, dann braucht man die halt und dann ist die Frage: ... Such dir genau den passenden aus: https://www.microchip.com/maps/microcontroller.aspx (OK, das ist immer wieder schnarchlangsam) Wenn man innerhalb der PIC32 bleibt und Harmony verwendet, kann man einfach den Controller wechseln, ohne irgendwas umzuprogrammieren.
Dirk F. schrieb: > welche 32 Bit MCU Ihr für ein neues Projekt einsetzen würdet? Ich bin auf STM32 gekommen, weil - wurde hier empfohlen - es gab Boards ab 1,50 € - Debugger kosten nur 2 € - Software kostet gar nichts Inzwischen gibt es einige STM32 Anleitungen auf deutsch.
:
Bearbeitet durch User
Hans W. schrieb: > Ich bin auf STM32 gekommen Danke für die vielen Hinweise. Hatte den Eindruck, dass viele Berichte und neue Dokumente von Microchip auf den ATSAM kommen, dass die PIC Reihe fallen gelassen wird. Bei STM32 sehe ich den Vorteil, dass es hier einen Software Stack für Profinet gibt. Aktuell setzen wir einen separaten Profinet Chip ein. Gruß
Dirk F. schrieb: > Hatte den Eindruck, dass viele Berichte und neue Dokumente von Microchip > auf den ATSAM kommen, dass die PIC Reihe fallen gelassen wird. Ziemlich sicher nicht, denn damit würde Microchip eine Eigenentwicklung zugunsten einer Fremdentwicklung fallenlassen. (PICs sind Microchip-Urgestein, Atsam sind von Atmel).
Harald K. schrieb: > Ziemlich sicher nicht, denn damit würde Microchip eine Eigenentwicklung > zugunsten einer Fremdentwicklung fallenlassen. Vielleicht haben sie es endlich gemerkt dass Atmels ARM besser sind als PICs.
Wastl schrieb: > Vielleicht haben sie es endlich gemerkt Sie werden gemerkt haben, daß beide unterschiedliche Zielgruppen bedienen.
Bauform B. schrieb: > z.B. vertragen 5 Volt tolerante Eingänge keine 5 Volt. Wenn die Versorgungsspannung aus ist, meinst du wohl. Dann vertragen sie nur 4V. Jetzt musst du ganz ganz tapfer sein: Fast alle CMOS IC für 5V vertragen ebenfalls keine 5 Volt, wenn die Versorgungsspannung aus ist. Sie vertragen dann sogar noch weniger als die STM32, nämlich höchstens 0,5 Volt. Insofern ist das kein Argument gegen STM32, sondern eher ein Vorteil!
Wastl schrieb: > Vielleicht haben sie es endlich gemerkt dass Atmels ARM besser > sind als PICs. 4 kleine PICs haben auch 32 bit, können aber z.B. 4 Additionen gleichzeitig ausführen! Es wird auch bei den PICs Neuentwicklungen geben. Z.B. den PICMega64A, und den 12 V toleranten PIC555. Ansonsten kann man sich 32 bittig, auch mit japanischem Flair sehr gut die Zeit vertreiben. Vom V850 über die RX6x und die Super-Hs. Bei TI gibt es auch einiges, was nicht nur ARM dran ist, und auf TMS320 hört. Die letzteren haebn oft recht spochtliche Spezialdisziplinen, in denen sie locker auch dicke ARMe abhängen können.
:
Bearbeitet durch User
> Ziemlich sicher nicht, denn damit würde Microchip eine Eigenentwicklung > zugunsten einer Fremdentwicklung fallenlassen. (PICs sind > Microchip-Urgestein, Atsam sind von Atmel). Ich glaub zwar auch nicht das PICs gleich naechstes Woche aussterben, aber die Begruendung ist doch eigenartig. Eine Firma interessiert nur eins: Wie gut verkaufen sich die Teile. Langfristig geht es da nur um Stueckzahlen und Preise und da wuerde ich vermuten, wird alles durch RiscV ersetzt werden. Wobei mich persoenlich solche Diskussionen immer wundern. Es ist mir doch schiet egal was das letztlich fuer ein Controller ist solange es einen C-Compiler gibt. Vanye
Dirk F. schrieb: > Hans W. schrieb: >> Ich bin auf STM32 gekommen > > Danke für die vielen Hinweise. > Hatte den Eindruck, dass viele Berichte und neue Dokumente von Microchip > auf den ATSAM kommen, dass die PIC Reihe fallen gelassen wird. Nicht ganz. PIC32M: MIPS basiert PIC32C: ARM basiert PIC64: RISCv basiert Da wird nichts fallen gelassen. fchk
Moin, Vanye R. schrieb: > Es ist mir > doch schiet egal was das letztlich fuer ein Controller ist solange es > einen C-Compiler gibt. Und der ein halbwegs aktueller gcc ist. Ich hab' nicht wirklich Bock auf irgendwelche Spezialtoolchains, am besten dann noch, dass man ein Windows oder irgendwelche Kruecken braucht, damit die laufen... Gerade TI hab' ich da in schlechter Erinnerung. Vielleicht isses heute anders, hab' schon lange nichts mehr mit Prozessoren von denen gemacht. Letztesmal Vogel abgeschossen war bei TI: In BMS-Chips nehmen die wohl gerne mal eine bizarre 22bit-CPU her. Tut das Not? Gruss WK
Vanye R. schrieb: > solange es > einen C-Compiler gibt. C++ Ich möchte nicht mehr auf meine Objekte, Templates usw. verzichten.
Dergute W. schrieb: > Moin, > > Vanye R. schrieb: >> Es ist mir >> doch schiet egal was das letztlich fuer ein Controller ist solange es >> einen C-Compiler gibt. > > Und der ein halbwegs aktueller gcc ist. Ich hab' nicht wirklich Bock auf > irgendwelche Spezialtoolchains, am besten dann noch, dass man ein > Windows oder irgendwelche Kruecken braucht, damit die laufen... Du müsstest noch TI von der Wichtigkeit der Meinung deiner Person überzeugen. Hat man einen der richtigen JTAG-Adpater für die TI-Controller, öffnet sich ein wahres Paradies. Für den $REST tut es ein FTDI-Bitwackler ja prnzipiell auch. Gerade TI unterstützt auch den Hobbyisten mit freien Lizenzen. Ob die vom System ausgeführten Systemcalls dann blau oder grün gefärbt sind, ist mir relativ egal. "Entscheidend ist, was hinten rauskommt." ☺ > Gerade TI hab' ich da in schlechter Erinnerung. Vielleicht isses heute > anders, hab' schon lange nichts mehr mit Prozessoren von denen gemacht. > Letztesmal Vogel abgeschossen war bei TI: In BMS-Chips nehmen die wohl > gerne mal eine bizarre 22bit-CPU her. Tut das Not? Wenn die gesparten Bits den Energiebedarf senken, warum nicht?
Moin, Cartman E. schrieb: > Du müsstest noch TI von der Wichtigkeit der Meinung deiner Person > überzeugen. Na, zum Glueck musste ich das noch nicht tun. Da gibts sicher lustigere Windmuehlenkaempfe. Wenn ich keinen Brokoli mag, dann muss ich auch nicht alle anderen davon ueberzeugen, wie kagge der schmeckt. Es reicht mir voellig, den selbst nicht zu mir zu nehmen. Gruss WK
Dergute W. schrieb: > Moin, > > Cartman E. schrieb: >> Du müsstest noch TI von der Wichtigkeit der Meinung deiner Person >> überzeugen. > > Na, zum Glueck musste ich das noch nicht tun. Da gibts sicher > lustigere Windmuehlenkaempfe. > Wenn ich keinen Brokoli mag, dann muss ich auch nicht alle anderen davon > ueberzeugen, wie kagge der schmeckt. Es reicht mir voellig, den selbst > nicht zu mir zu nehmen. Dann solltest du einen weiten Bogen um Hannover machen. In der Mensa der MHH Hannover, wo auch die c't-Redakteure speisen, gibt es mindestens(!) vier mal die Woche diese schrecklichen Broekolli. Widerlich! So sind schlimm ist keins der TI-Produkte. Manches von TI mag dir ja speziell vorkommen. Ich kann dir aber versichern, dass es dann auch speziell nützlich ist. Kwasi "alternativlos". ☺ Schönes Wochenende!
Dergute W. schrieb: > Und der ein halbwegs aktueller gcc ist. llvm/clang kann man auch sehr gut verwenden.
Dergute W. schrieb: > In BMS-Chips nehmen die wohl gerne mal eine bizarre 22bit-CPU her. Tut > das Not? Cartman E. schrieb: > Wenn die gesparten Bits den Energiebedarf senken, warum nicht? Ich mag die Piccolos. Da haben sie aber z.B kein wirkliches uint8. Also gerade anders rum. Großer als es sein müsste.
N. M. schrieb: > Ich mag die Piccolos. Da haben sie aber z.B kein wirkliches uint8. Was sind Piccolos? Rasp PiPico, Pipico2? Der RP2350 mit seinen M33 kann manches in 8Bit: https://developer.arm.com/documentation/dui0801/l/Advanced-SIMD-Instructions--32-bit-/Summary-of-Advanced-SIMD-instructions?lang=en https://developer.arm.com/documentation/dui0801/l/Advanced-SIMD-Instructions--32-bit-/VADD--A32-?lang=en
Christoph M. schrieb: > N. M. schrieb: >> Ich mag die Piccolos. Da haben sie aber z.B kein wirkliches uint8. > > Was sind Piccolos? Rasp PiPico, Pipico2? https://www.ti.com/product/de-de/TMS320F280220 fchk
Harald K. schrieb: > Dirk F. schrieb: >> Hatte den Eindruck, dass viele Berichte und neue Dokumente von Microchip >> auf den ATSAM kommen, dass die PIC Reihe fallen gelassen wird. > > Ziemlich sicher nicht, denn damit würde Microchip eine Eigenentwicklung > zugunsten einer Fremdentwicklung fallenlassen. (PICs sind > Microchip-Urgestein, Atsam sind von Atmel). Vor allem ist der ARM-PIC32C von 2021 jünger als der ATSAM, welcher mit dem Kauf von Atmel 2016 ins Portfolio wanderte. Man bekommt bei Microchip noch immer DIL. Man bekommt bei Microchip noch immer PIC16F84 bzw. kompatible Nachfolger. Ich würde mir da wirklich noch keine Gedanken über eine Abkündigung von irgendwelchen 'modernen' Chips machen. Christoph M. schrieb: > Was sind Piccolos? TI DSC (DSP-Controller) C2000 Vor allem für Motorsteuerungen gedacht. PWM-Monster. Nett! Cartman E. schrieb: > So sind schlimm ist keins der TI-Produkte. Dann werfe ich mal den MSP432 in den Ring. Ein von TI entwickelter, stromsparender ARM-Controller als Nachfolger mit mehr Wumms für den MSP430. Wenn Du Probleme brauchst, dann ist der die Lösung! Da fehlten so viele grundlegende Dinge ... Wurde kurz nach der Erscheinung auch wieder eingestellt. Was habe ich mit den Scheissdingern gekämpft ... Gruß Jobst
:
Bearbeitet durch User
Jobst M. schrieb: > Christoph M. schrieb: >> Was sind Piccolos? > > TI DSC (DSP-Controller) C2000 > Vor allem für Motorsteuerungen gedacht. PWM-Monster. > Nett! Ja, aber die ganze C2000-Sparte den Piccolos zuzurechnen, ist schon etwas unzutreffend. Die Piccolos sind da eher die Zwergerl. Die speziellen Gimmicks findet man da eher nicht, wenn man die Peripherie mal ausnimmt. > Cartman E. schrieb: >> So sind schlimm ist keins der TI-Produkte. > > Dann werfe ich mal den MSP432 in den Ring. Ein von TI entwickelter, > stromsparender ARM-Controller als Nachfolger mit mehr Wumms für den > MSP430. > Wenn Du Probleme brauchst, dann ist der die Lösung! > Da fehlten so viele grundlegende Dinge ... > Wurde kurz nach der Erscheinung auch wieder eingestellt. > Was habe ich mit den Scheissdingern gekämpft ... Mit den MSP430 bin ich ganz zufrieden. Besonders die Mixed-Mode-Typen MSF430FG461x oder der MSP430F5418. Ein paar Kleinere aber auch. ☺ Für MSP432 hatte/habe ich wohl keinen Bedarf. Auch mit den Stellaris und den TIVAs lässt sich einiges(!) anfangen. Und: Wo viel gearbeitet wird, werden auch viele Fehler gemacht. > Gruß > Jobst Schöne Woche!
Cartman E. schrieb: > Mit den MSP430 bin ich ganz zufrieden. Da passiert halt nicht mehr viel, und sie sind durch den durch die Bank doch arg spartanischen Speicherausbau (RAM) limitiert. Und im Vergleich zu anderen µCs sind sie halt auch recht teuer und "exotisch" (sprich: nur über Distributoren zu bekommen, nicht aber auf irgendwelchen günstigen Bastelplatinen). Immerhin, es gibt sogar einen MSP430 im bastelfreundlichen 40poligen DIP-Gehäuse (das ist der 'G2744). Allerdings gibt es genau eine Bezugsquelle dafür: https://www.olimex.com/Products/MSP430/Booster/MSP430-G2744BP/open-source-hardware und weder TIs Webseite noch das Datenblatt erwähnen, daß es diesen µC in dieser Bauform gibt ...
Harald K. schrieb: > Und im Vergleich zu anderen µCs sind sie halt auch recht teuer und > "exotisch" (sprich: nur über Distributoren zu bekommen, nicht aber auf > irgendwelchen günstigen Bastelplatinen). Es gab mal diese Launchpads für $5. Das waren billige Bastelplatinen, noch vor der Arduino-Zeit.
Ob es überhaupt immer etwas "neues" sein muss, hängt davon ab, ob es sich um ein Produkt oder ein Hobbyprojekt handelt. Nicht etwa, weil "alt = schlecht", sondern weil "alt = teuer". Sobald ein neues Teil herauskommt, schießen die Preise der alten Teile durch die Decke. Deshalb kostet ein etwas größerer AVR oder ein Cortex-M3 der ATSAM3X-Reihe heute mehr als ein Cortex-M7 mit 500MHz. Bei Produkten macht es daher eher Sinn, zu wechseln. Da spart man in der Serie einen Haufen Geld. Ich habe immer parallel mit mehreren verschiedenen µC-Reihen gearbeitet. Vor 10 Jahren waren das z.B. AVR für klein und billig, ATSAM3 für anspruchsvollere Sachen und den ATSAMS7 für highspeed. Heute würde ich den AVR nicht mehr anfassen. Nach 30 Jahren muss es mal gut sein. Für Kleinzeugs nehme ich seit Jahren den SAMD21. Der ist auch nicht mehr so taufrisch, aber er rennt jedem AVR davon und wird auch von Arduino unterstützt (Arduino Zero). Für den Preis bekommt man heute auch schnelleres, aber die Peripherie ist massiv für die kleinen 48 oder 64 Pin Gehäuse und kaum von anderen oder schnelleren Typen übertroffen. z.B. 3 oder 4 SPI-Schnittstellen in einem 48pin Gehäuse bietet eben auch nicht jeder an. Für großes nehme ich die STM32H7. Was mich da aber stört, sind die unvollständigen highspeed USB-Schnittstellen (wo man einen externen Phy benötigt). Da war ATMEL mit den SAMS7 besser. Die habe ich auch benutzt, aber ich sehe die als ausgestorben an. Da genügt ein Blick in die Preisliste. Aber selbst die STM32H7 sind ja auch schon gut 10 Jahre alt. Die scheinen aber noch aktuell, weil sie noch zu humanen Preisen angeboten werden. Möglicher Nachteil sind eben die mindestens 100 Pins. Wenn ich jetzt unbedingt einen Ersatz für DSPIC suchen würde, würde ich aktuell zum STM32H7 oder bei kleineren Baugrößen evtl. dem STM32F7 tendieren. DSP-Funktionen und FPU sind vorhanden. Das sollte für die nächsten Jahre reichen. Ich denke nicht dass die H7 oder F7 so schnell vom Markt verschwinden werden. Dass Microchip sein Angebot ausdünnt, war seit der Übernahme von ATMEL klar. Schaut man sich das Portfolio an, wird zwar offiziell noch ALLES angeboten, aber ich denke, viele sind nur noch aufgeführt, weil man sie eben hat! Die SAMS7 SAME7 oder SAMV7 sehe ich als tot an. Auch tummeln sich in dem Bereich "high performance" PIC32. Ob die langfristig eine Daseinsberechtigung haben bzw. gegen die STM32 anstinken können? Die SAM3 oder SAM4 werden im Mittelfeld noch gelistet, sind aber auch tot. Den unteren Bereich scheinen eher die DSPIC zu dominieren, auch wenn da noch ein SAMC oder SAMD erscheint. Die DSPIC scheinen also alles andere als vernachlässigt zu sein. Mir scheint dass der Markt hauptsächlich von 10 Jahre alten Typen dominiert wird. Im Bereich µC scheint da in den letzten Jahren wenig bahnbrechendes passiert zu sein. Verbessert mich, wenn ich falsch liege. Vor 10-15 Jahren kam alle paar Jahre eine neue Serie heraus. Aber in den letzten Jahren kam nix mehr(?). Braucht man nichts mehr neues oder stehen wir kurz vor einem neuen Innovationsschub? Bei irgendwelchen Exoten (wenn auch durchaus erfolgreich) bin ich immer vorsichtig. So ist z.B. ein RP2040 sehr verlockend angesichts der Leistung und dem lächerlichen Preis. Aber die erscheinen mir zeitlich wenig beständig und eigenen sich wohl eher für kurzlebige Produkte. Ob sich da eine Einarbeitung auszahlt? Wenn ich hier ab und an lese "den gibts auch im DIP" frage ich mich auch, in wieweit das heute noch ernsthaft ein Kriterium sein kann, selbst für Bastler. Ich glaube man hatte ja nun mehr als genug Zeit, Löten zu lernen :-) Gruß Joachim
Harald K. schrieb: > Cartman E. schrieb: >> Mit den MSP430 bin ich ganz zufrieden. > > Da passiert halt nicht mehr viel, und sie sind durch den durch die Bank > doch arg spartanischen Speicherausbau (RAM) limitiert. Bei den MSP430FG461x muss man mit 8 kByte, und beim MSP430F541x mit 16 kByte auskommen. Gegenüber dem DIL-Veteranen haben sie noch einiges mehr zu bieten. Manches ist vielleicht auch so gut, dass man keine Notwendigkeit verspürt, auf noch unausgegorenes Neues zu schielen. Wie z.B. die MSP432. > Und im Vergleich zu anderen µCs sind sie halt auch recht teuer und > "exotisch" (sprich: nur über Distributoren zu bekommen, nicht aber auf > irgendwelchen günstigen Bastelplatinen). Billigheimer sind es nicht. Bei den Mixed-Mode MSP430 kann man dafür ja einiges andere dann einsparen. > Immerhin, es gibt sogar einen MSP430 im bastelfreundlichen 40poligen > DIP-Gehäuse (das ist der 'G2744). Allerdings gibt es genau eine > Bezugsquelle dafür: > > https://www.olimex.com/Products/MSP430/Booster/MSP430-G2744BP/open-source-hardware > > und weder TIs Webseite noch das Datenblatt erwähnen, daß es diesen µC in > dieser Bauform gibt ... Er wird wohl nicht mehr "Active" sein. > Es gab mal diese Launchpads für $5. Das waren billige Bastelplatinen, > noch vor der Arduino-Zeit. Es waren $4,30!
Joachim M. schrieb: > Vor 10-15 Jahren kam alle paar Jahre eine neue Serie heraus. Aber in den > letzten Jahren kam nix mehr(?). Braucht man nichts mehr neues oder > stehen wir kurz vor einem neuen Innovationsschub? Naja, so kann man das nicht sehen. ST bringt ja immer mal wieder interessante neue Serien. Zuletzt z.B. STM32C5. 512kB Flash und 144MHz M33 für ~1€. Renesas hat in der RA Serie auch regelmäßig was neues bis rauf zum RA8 2MB/1GHz M85. Die iMXRT von NXP bekommen auch immer mal wieder Zuwachs.
Joachim M. schrieb: > Dass Microchip sein Angebot ausdünnt, war seit der Übernahme von ATMEL > klar. Oft werden nur Varianten gestrichen. Da gibt es den gleichen Controller mit 256, 512 und 1024 kB, und den 512er lässt man sterben. Das optimiert die Lagerhaltung, und technisch steckt ohnehin der gleiche Chip drin. > Schaut man sich das Portfolio an, wird zwar offiziell noch ALLES > angeboten, aber ich denke, viele sind nur noch aufgeführt, weil man sie > eben hat! Als Großkunde bekommst Du den o.g. (fiktiven) Stein auch mit 384 oder 911 kB Flash. Ist ja nur eine Sachnummer und ein angepasstes Prüfprogramm.
Joachim M. schrieb: > Aber die erscheinen mir zeitlich wenig beständig und eigenen sich wohl > eher für kurzlebige Produkte. Die RPi Foundation meint dazu im Produkt Brief des RP2040 Chips:
1 | We expact RP2040 to remain in production until at least 2041. |
Das finde ich schon lange genug um sich einarbeiten zu können. Wobei sie dem Board (Raspberry Pi Pico) deutlich weniger Zeit zugestehen:
1 | Appendix A: |
2 | Raspberry Pi guarantee availability of the Raspberry Pi Pico product until at least January 2028. |
Aber solange es den Chip gibt...
Soul E. schrieb: > Es gab mal diese Launchpads für $5. Das waren billige Bastelplatinen, > noch vor der Arduino-Zeit. Das war nicht wirklich vor der Arduino-Zeit, so lange ist das noch nicht her. Davor gab es als ersten Versuch, kostengünstiger auf Entwickler zuzugehen, das ez430-f2013 Kit - das kam vor 20 Jahren 'raus. Mit dem 'f2013 konnte man aber nicht sonderlich viel anstellen, der hat 2 kiB Flash und nur 128 Byte RAM (und dafür aber einen 16-Bit-ADC ...). Erst mit der Einführung der "G"-Reihe besserte sich das allmählich, mit dem Launchpad, das 2010 herauskam (anfänglich nur mit dem kaum besser verwendbaren 'G2211 und 'G2231. Die bessere Variante gab es dann erst ein Jahr später, die enthielt den 'G2553. Wirklich viel kann man mit dem aber nicht anstellen, denn auch der hat nur 16 kiB Flash und gerade mal 512 Byte RAM. Das ist aber der "größte" MSP430 im DIL-Gehäuse (wenn man mal vom Olimex-Exoten absieht). Die älteren MSP430-Modelle (wie z.B. 'F1612) kann man mit dem Launchpad nicht nutzen (die kennen nur 4-Draht-JTAG und nicht das mit dem 'F2013 eingeführte SBW), und die waren schon immer ziemlich teuer. Größere MSP430 gibt es natürlich, aber letztlich hat es in den letzten zehn, fünfzehn Jahren auf dem Gebiet kaum noch Weiterentwicklung gegeben. Übrigens sind MSP430 auch keine 32-Bit-Architektur, damit ist das hier alles ein bisschen "offtopic" ...
Joachim M. schrieb: > Bei irgendwelchen Exoten (wenn auch durchaus erfolgreich) bin ich immer > vorsichtig. > So ist z.B. ein RP2040 sehr verlockend ... Ob sich da eine > Einarbeitung auszahlt? Eine Einarbeitung ist nicht notwendig, einzig speziell ist die PIO. Wenn Du STM32 verwendest, ist der Rest eher simpel, vielleicht sogar zu simpel. Großer Nachteil ist, daß der Programmspeicher extern angebunden ist. Für kleine, feine Sachen würde ich einen STM32G0xx empfehlen. Norbert schrieb: > Da es offenkundig keinerlei Anforderungen gibt, würde ich irgend eine > beliebige nehmen. Denn die erfüllt automatisch alle. Wo Du Recht hast, hast Du Recht ;-)
Mi N. schrieb: > Großer Nachteil ist, daß der Programmspeicher extern angebunden > ist. Dafür gibt's ja nun die RP2354 in den Geschmacksnoten A oder B. ;-)
Die PiPicos haben eher noch den Nachteil des fehlenden Aufstiegspfades. 100 Pinner? Gibt's nicht. Externes RAM? Schwierig. Display mit Grafikbescheinigung? Vergiss es. Da haben die etablierten mit ihrem Bauchladen an Varianten schon noch ein paar Vorteile.
Μαtthias W. schrieb: > Die PiPicos haben eher noch den Nachteil des fehlenden > Aufstiegspfades. > 100 Pinner? Gibt's nicht. Externes RAM? Schwierig. Display mit > Grafikbescheinigung? Vergiss es. Da haben die etablierten mit ihrem > Bauchladen an Varianten schon noch ein paar Vorteile. Ich muss nur lange genug darüber nachdenken, dann fallen mir bestimmt noch weitere negative Aspekte ein. ;-) Hätte ich gerne … mehr als 520 KiB RAM? Klar! mehr als 32 MiB Flash? Klar! mehr als 48 GPIO? Klar! mehr als 12 SMs? Klar! mehr als… Aber um mal etwas Reelles zu benennen, das USB Interface dürfte tatsächlich gerne ein wenig mehr Fump haben. PS: Die PICOs sind die fertig bestückten boards. PPS: Was mich aber wirklich nervt ist die Tatsache, dass sie den beiden ARM Prozessoren zwei FPUs gespendet haben, den beiden RISC-V Prozessoren jedoch nicht. Ein Schelm wer Böses dabei denkt.
:
Bearbeitet durch User
Joachim M. schrieb: > Für großes nehme ich die STM32H7. Was mich da aber stört, sind die > unvollständigen highspeed USB-Schnittstellen (wo man einen externen Phy > benötigt). Die STM32H7R3/R7 und die S3/S7 laufen mit 600MHz und haben 1x USB OTG Full Speed plus 1x USB OTG High Speed. Beide mit internem PHY. Brauchen aber dafür externes QUAD/OCTA Flash. Ein fertiges STM32H7R3 Board mit 8MB Flash von WEACT gibt es bei ALI. https://de.aliexpress.com/item/1005010466566322.html
Joachim M. schrieb: > So ist z.B. ein RP2040 sehr verlockend angesichts der Leistung und dem > lächerlichen Preis. Definitiv ja. Noch attraktiver sind seine Nachfolger. Nochmal ordentlich mehr RAM, nochmal ordentlich mehr Rechenleistung, auf Wunsch mehr Pins und/oder Flash included. Und das alles für kaum mehr Geld (außer die mit Flash, aber den musste man ja zuvor auch extra kaufen). > Aber die erscheinen mir zeitlich wenig beständig Dazu wurde ja bereits was geschrieben. > Ob sich da eine > Einarbeitung auszahlt? Das Witzige ist: Im Vergleich zu anderen ARM-basierten Teilen mit M0+ bzw. M3-Kernen sind die sogar eher einfach gestrickt. Wenn man mal vom überaus mächtigen PIO-Feature absieht. Und das lohnt definitiv eine Einarbeitung, wenn man Probleme zu lösen hat, die sich selbst mit den H7-Dickschiffen nicht lösen lassen oder nur durch Einarbeitung in die unendliche Featurefülle der völlig überfrachteten Peripherien. Um dann gelegentlich festzustellen, das Silizium-Bugs diese selten genutzten und deshalb wohl auch kaum getesteten Features sogar komplett unbrauchbar machen können. SOWAS lohnt die Einarbeitung nicht.
Ob S. schrieb: >> So ist z.B. ein RP2040 sehr verlockend angesichts der Leistung und dem >> lächerlichen Preis. > > Definitiv ja. Noch attraktiver sind seine Nachfolger. Nochmal ordentlich > mehr RAM, nochmal ordentlich mehr Rechenleistung, auf Wunsch mehr Pins > und/oder Flash included. > > Und das alles für kaum mehr Geld Wohl war, habe neulich 10x RP2350 für 80ct/st gekauft. Rechenleistung ist überragend. Entwickeln & Debuggen geht mit Pico-SDK und Debug-Probe ganz ordentlich. Nur mit der DMA komme ich schlecht klar, die beißt sich irgendwie mit der Debug-Probe bzw meiner Umgebung.
Wulf D. schrieb: > Nur mit der DMA komme ich schlecht klar, die beißt sich irgendwie mit > der Debug-Probe bzw meiner Umgebung. Wie äußert sich das? Ich habe damit jedenfalls keine Probleme (egal ob mit dem originalen Debug-Probe oder mit meinem Pico-Probe Eigenbau aus den frühen Tagen des PiPico). Probleme habe ich allerdings mit dem Debuggen von Core1-Code im VSCode-GUI. Das geht praktisch garnicht mehr. Der hält an Breakpoints schlicht nicht an, wenn der Code auf Core1 läuft. Ärgerlich ist insbesondere, weil das definitiv mal problemlos funktioniert hat. Da ham'se irgendwas kaputt gefrickelt. Ich weiß bloß nicht, was genau Schuld ist. Ich hatte recht lange kein Projekt, bei dem Core1 benutzt wurde, erst kürzlich kam dann wieder eins. Zwischen den beiden Zeitpunkten gab es leider ziemlich viele Änderungen im SDK (inbesondere auch die Umstellung auf 2.x). Aber auch das Cortex-Debug-Plugin hatte etliche Updates und, last but not least, auch OpenOCD. Leider ein ziemlich großer Suchraum...
Ob S. schrieb: >> Nur mit der DMA komme ich schlecht klar, die beißt sich irgendwie mit >> der Debug-Probe bzw meiner Umgebung. > > Wie äußert sich das? Ich habe damit jedenfalls keine Probleme (egal ob > mit dem originalen Debug-Probe oder mit meinem Pico-Probe Eigenbau aus > den frühen Tagen des PiPico). Muss da präzisieren, nutze den RP2350 mit ADC via fifo und DMA. Solange der ADC nicht läuft, ist alles gut. Starte ich den ADC in oben genannten Konfiguration (adc_run(true);), stoppt der Debug-Probe zwar noch an den Breakpoints, aber die Daten der .bss section (globale und statische Variablen) zeigen oft nur noch zufällige Werte. Egal, ob in der Watch-List or Memory View. Beim Weiterlauf stürzt der Code dann auch ab. Stoppe ich nicht per Breakpoint, läuft die Code durch und zeigt auch korrekte Daten z.B. auf dem Display. Mit Core 1 hatte ich auch mal viel Spaß. Lag an der default Stack-Size von 2kByte. Der Code brauchte aber mehr und so haben sich die beiden Core gegenseitig den Stack überschrieben. Stürzte natürlich ab. Wenn man es weiß, läßt sich das schnell beheben.
> Um dann > gelegentlich festzustellen, das Silizium-Bugs diese selten genutzten und > deshalb wohl auch kaum getesteten Features sogar komplett unbrauchbar > machen können. Ja, das wundert mich auch immer. Es gibt hier soviele Leute denen man anmerkt die geistige Muehe zu scheuen ein Datenblatt zu lesen, ob die jemals ein Errata gelesen haben? :) Meine Einschaetzung zu dem RP2040: Er ist ein interessantes Teil, die PIO sogar sehr interessant, man merkt dem Dingen an das es aus der Hand von Leuten stammt die eher Software als Hardware machen. Die haben da ein paar interessante Sachen anders gemacht wie bei anderen Controllern. Man merkt aber auch das sie bestimmte Sachen nicht so konnten, wie z.B LowPower und ADCs. Also das analoge Leben halt.... Vanye
Vanye R. schrieb: > Man merkt aber auch das sie bestimmte Sachen nicht so konnten, wie z.B > LowPower und ADCs. Also das analoge Leben halt.... Tja, wenn man direkt mit 12 Bit einsteigt, dann fallen die Fehler deutlich mehr auf, als wenn man erst einmal 8/10 Bit Wandler gebaut und dabei sukzessive gelernt hätte. Der Neue ist ja tatsächlich schon deutlich linearer geworden. Was den Stromverbrauch angeht: Da Ding will einen externen Flash und diese Bausteine nehmen sich einen nicht unerheblichen Schluck aus der Energie-Pulle. Aber dafür ist im µC ja ein XIP, welcher nicht nur Zugriffszeiten dramatisch verbessert sondern auch die Energie-intensiven Zugriffe auf den Flash Baustein verringert. Dann stellt man aber fest, dass die XIP Komponente den größten Stromverbrauch aller Peripherie-Elemente hat. Dennoch ergibt sich netto ein deutlicher Vorteil. Die Dinger sind nie zum Strom sparen konzipiert worden, obwohl man massig Peripherie-Komponenten nach Bedarf ein/ausschalten kann. Wenn man das Ding auf zB. 16MHz und einen Kern herunter bremst, dann ist er plötzlich gar nicht mal sooo schlecht. Aber wer will das schon? ;-) Sollte man seinen Betriebsstrom jedoch in homöopathischen Dosen aus Knopfzellen beziehen wollen, da gibt es tatsächlich sehr viel besser geeignete Kandidaten.
> Wenn man das Ding auf zB. 16MHz und einen Kern herunter bremst, dann ist > er plötzlich gar nicht mal sooo schlecht. Aber wer will das schon? ;-) Ein STM32L4 kann mit 6uA im Deepsleep verharren, aufwachen und dann kurz was machen. Ich bin letzten auf 140Jahre Lebensdauer einer 16550Zelle gekommen und hab beschlossen jetzt was kleineres zu nehmen. :-D Vanye
Vanye R. schrieb: > in STM32L4 kann mit 6uA im Deepsleep verharren Nicht verwunderlich, trägt ja schon ein L im Namen. Ist also speziell für so etwas gebaut worden. Ein rp braucht dormant gut dreißig mal so viel, wäre also untauglich für eine Knopfzelle. Zumindest bei Knopfzellen kleiner als 'ne Kinderfaust. Die beiden haben einen wenn auch recht schmalen Überlappungsbereich. Der STM erweitert diesen nach unten, der rp nach oben.
Wulf D. schrieb: > Debug-Probe > ganz ordentlich. Das ist das schöne an den Picos mit der Debug-Probe FW, man hat sobald man 2+ von den Boards hat auch nen Debugger zur Hand. Ob S. schrieb: > Wenn man mal vom > überaus mächtigen PIO-Feature absieht. AFAIK Alleinstellungsmerkmal (zumindest in der Preisklasse). Deswegen hat der vermutlich auch weniger Spezialperipherie weil man vieles ja auf dem PIO abbilden kann was eher "nische" ist. Gibt ja sogar DVI/HDMI mit noch effektiv einem Kern frei: https://github.com/ikjordan/PicoDVI
Tom G. schrieb: > Gibt ja sogar DVI/HDMI mit > noch effektiv einem Kern frei ... und der 2350 hat für derartige Aufgaben sogar dedizierte Hardwareunterstützung, der kann dann also noch mehr anstellen.
Harald K. schrieb: > Tom G. schrieb: >> Gibt ja sogar DVI/HDMI mit >> noch effektiv einem Kern frei > > ... und der 2350 hat für derartige Aufgaben sogar dedizierte > Hardwareunterstützung, der kann dann also noch mehr anstellen. Andererseits kann man mit beiden ganz hervorragend VGA Signale erzeugen und braucht bei geschickter Programmierung dazu GAR KEINE CPU-Leistung. Also mit VGA Ausgabe immer noch 2×100% zur Verfügung. Getestet bis hoch zu 1680×1050.
Norbert schrieb: > Andererseits kann man mit beiden ganz hervorragend VGA Signale erzeugen Das ist kaum nützlicher, als FBAS. Die Zeit analoger Videosignale und passender Bildschirme ist vorbei.
Nemopuk schrieb: > Das ist kaum nützlicher, als FBAS. Die Zeit analoger Videosignale und > passender Bildschirme ist vorbei. Ja ja. Yada, Yada, Yada, … Ich schmeiß dann mal kurz meine sechs Monitore weg, welche allesamt noch VGA unterstützen. Du meine Güte…
Norbert schrieb: > Nemopuk schrieb: >> Das ist kaum nützlicher, als FBAS. Die Zeit analoger Videosignale und >> passender Bildschirme ist vorbei. > > Ja ja. Yada, Yada, Yada, … > > Ich schmeiß dann mal kurz meine sechs Monitore weg, welche allesamt noch > VGA unterstützen. > > Du meine Güte… Nunja, es gibt natürlich reichlich Monitore im Bestand, die noch einen VGA-Anschluss besitzen. Aber Nemopuk hat trotzdem nicht ganz Unrecht. "Die Zeit ist vorbei" ist zwar sicher übertrieben formuliert, aber das Angebot von Monitoren mit VGA dünnt sich doch schon deutlich sichtbar aus. Ich habe spaßenshalber mal die sehr gut organisierte Datenbank von Geizhals.at befragt. Die listen derzeit gut 3100 Monitormodelle, davon haben aber nur noch 650 einen VGA-Anschluss, das entspricht ca. 20%. Vor 5 Jahren waren es noch fast 100%. Man muss schon sehr ignorant sein, um diese Tendenz nicht wahrzunehmen.
Ob S. schrieb: > Die listen derzeit gut 3100 Monitormodelle, davon haben aber nur noch > 650 einen VGA-Anschluss, das entspricht ca. 20%. Und bei denen steckt stets ein Konverter auf Digital dahinter. Der analoge Eingang ist als Notlösung für alte Computer aus dem vorherigen Jahrtausend gedacht.
:
Bearbeitet durch User
Nemopuk schrieb: > Und bei denen steckt stets ein Konverter auf Digital dahinter. Natürlich. Das war aber selbst vor 10 oder sogar 15 Jahren nicht anders. Monitore mit CRT dürften auch damals bereits weitgehend ausgestorben gewesen sein. D.h.: ein Wandlung von Analog auf Digital war schon damals praktisch unvermeidlich.
Ob S. schrieb: > ein Wandlung von Analog auf Digital war schon damals praktisch > unvermeidlich. Bei digitalen Quellen (wie hier) ist die doppelte Wandlung nach analog VGA und wieder zurück durchaus fragwürdig.
:
Bearbeitet durch User
Nemopuk schrieb: > Der analoge Eingang ist als Notlösung für alte Computer aus dem > vorherigen Jahrtausend gedacht. Hmm, mein nächster PC (so gut wie bestellt) hat USB3, zwei 2.5G, einen COM und ... VGA. Fast alle aus den letzten 5 Jahren haben VGA. Und das sind alles Mini-PCs, wo kaum Platz für so große Stecker ist. Nur zwei sind dann doch zu klein ( so ca. 2 Päckchen Butter groß) dafür.
Bauform B. schrieb: > Fast alle aus den letzten 5 Jahren haben VGA Komisch. Meine haben entweder HDMI oder DisplayPort -- beides nimmt weniger Platz weg als der klobige VGA-Stecker. Der letzte Rechner, der tatäschlich noch VGA hat ... das war ein HP 260 G1, den es vor etwa elf Jahren mal sehr günstig bei Reichelt gab. (grad' die Bestellung rausgekramt - das Ding kostete 160 Euro, kam mit einem Pentium 3558u (2c/2t), 'ner 500-GB-Festplatte und 4 GB RAM) Oh, und das Ding hat natürlich auch einen DisplayPort-Anschluss; VGA hab' ich an dem noch nie genutzt.
:
Bearbeitet durch User
Mein HP Desktop PC ist 1,5 Jahre alt, hat neben HDMI auch VGA (was ich seltsam fand).
Ich finde ja VGA heuzutage auch ein seltsames Opa-Relikt, aber noch seltsamer finde ich die Frage was ich damit, oder von mir aus auch HDMI, an einem Mikrocontroller soll? Was sind fuer Anwendung wo man noch einen Monitor neben seine MCU stellt? Da muss man sich doch schon sehr anstrengen um bemueht wirkende Antworten zu finden. Vanye
Ich fänd's ja eher interessant, aus den größeren i.MX SoCs natives HDMI oder auch MIPI-DSI herauszukitzeln, Bare-Metal, ohne Linux. Dann könnte man schöne aktuelle Bildschirme anschließen.
> Hobby und die Sinnfrage. > Selten zur allgemeinen Zufriedenheit auflösbar. Ein nicht ganz unberechtigter Einwand. :-D Aber willst du jetzt Pong nach programmieren und dann extra einen olle VGA Kiste aus den Keller holen und in deine Bude stellen? Come on! Jeder normal denkende Mensch wuerde da irgendein LCD/Oled/epaper dran basteln. Niemand, und erst recht nicht die Frau von Niemand will sich eine weitere haessliche Monitorkiste in die Bude holen. .-) Kuck dir dagegen mal das hier an: https://hackaday.io/project/205771-stereoboy Ich koennte da im Detail einiges kritisieren, aber die Grundidee ist gut. Hab mich schon immer gewundert warum nicht mehr Leute verlgeichbares machen. Vanye
Vanye R. schrieb: > Aber willst du jetzt Pong > nach programmieren und dann extra einen olle VGA Kiste aus den Keller > holen und in deine Bude stellen? Nur zu oft ist das einfach die günstigste Lösung. > Jeder normal denkende Mensch > wuerde da irgendein LCD/Oled/epaper dran basteln. Die meisten dieser Dinger sind wegen langsamer Schnittstellen für Bewegtbilder wenig bis nicht geeignet. Ausnahme sind Displays mit parallelem RGB-Interface, die aber schwer zuverlässig beschaffbar sind (vor allem mit hinreichender Doku). Fast dasselbe gilt für Displays mit LVDS. Die sind zwar deutlich besser beschaffbar, aber auch hier hapert es oft an hinreichender Doku. Dann gibt's noch HDMI und MIPI-DSI. Für beides haben die meisten µC ihrerseits wieder kein passendes Interface. Dazu kommt bei MIPI-DSI die grundsätzlich unzureichende Doku, weil das Interface selber nicht mal teilweise öffentlich dokumentiert ist.
Harald K. schrieb: > Bauform B. schrieb: >> Fast alle aus den letzten 5 Jahren haben VGA > > Komisch. Meine haben entweder HDMI oder DisplayPort Ja, ist ähnlich wie bei den Monitoren (Kunststück, hier braucht man eine gewisse Kausalität wohl nicht herbeifantasieren). Aktuell bei geizhals in der Rubrik Komplettsysteme ist der Anteil mit VGA 250:2850, also schon unter 10%. Vor 5 Jahren sah das noch ganz anders aus, da hatten noch fast 80% VGA. Man kann das wohl so zusammenfassen: VGA ist eindeutig am Sterben, aber noch nicht ganz tot.
Vor 10 Jahren (!!) war ich an der Uni der einzige dessen Laptop einen VGA-Port hatte und somit die Beamer ansteuern konnte...
Niklas G. schrieb: > Vor 10 Jahren (!!) war ich an der Uni der einzige dessen Laptop einen > VGA-Port hatte und somit die Beamer ansteuern konnte... Das liegt sicher daran, dass Studenten eher nicht die Kohle für Business-Notebooks haben. Die waren vor 10 Jahren noch zu durchaus nennenswerten Anteilen mit VGA ausgestattet.
Ob S. schrieb: > Das liegt sicher daran, dass Studenten eher nicht die Kohle für > Business-Notebooks haben. Aber MacBooks und deren ultradünne Konkurrenzprodukte. Business Laptops â la klassische ThinkPads waren damals schon out.
Niklas G. schrieb: > Business Laptops > â la klassische ThinkPads waren damals schon out. Nicht im Business-Bereich...
Ob S. schrieb: > Nunja, es gibt natürlich reichlich Monitore im Bestand, die noch einen > VGA-Anschluss besitzen. > > Aber Nemopuk hat trotzdem nicht ganz Unrecht. "Die Zeit ist vorbei" ist > zwar sicher übertrieben formuliert, aber das Angebot von Monitoren mit > VGA dünnt sich doch schon deutlich sichtbar aus. > > Ich habe spaßenshalber mal die sehr gut organisierte Datenbank von > Geizhals.at befragt. Die listen derzeit gut 3100 Monitormodelle, davon > haben aber nur noch 650 einen VGA-Anschluss, das entspricht ca. 20%. > > Vor 5 Jahren waren es noch fast 100%. Man muss schon sehr ignorant sein, > um diese Tendenz nicht wahrzunehmen. Ach, das hat mit Ignoranz nichts zu tun. Natürlich weiß ich, dass VGA langsam zurück geht. Vor allem bei Auflösungen jenseits des Full-HD. Aber es gibt zig Millionen von Bestandsgeräten und es werden immer noch mehr als reichlich Neue gebaut. Des weiteren sollte man die DVI-A/D Anschlüsse nicht aus den Augen verlieren. Zudem ging es ja ursprünglich darum, dass DVI-D/HDMI usw. eine gesunde Portion Rechenleistung brauchen, mit zunehmender Auflösung immer heftiger und bis zu einem vollen core. Und dass im Gegenzug VGA Null Rechenleistung braucht, was bei Mikrocontrollern ja gelegentlich nicht ganz unerheblich ist.
Norbert schrieb: > Aber es gibt zig Millionen von Bestandsgeräten und es werden immer noch > mehr als reichlich Neue gebaut. Des weiteren sollte man die DVI-A/D > Anschlüsse nicht aus den Augen verlieren. Die "zig Millionen Bestandsgeräte" sind aber im wesentlich eines: Ziemlich alt, wenn sie noch mit VGA daherkommen. Und wann wurde das letzte mal ein DVI-Anschluss, gar noch mit dem analogen Zusatz, in einem PC verbaut? Dürfte auch schon lange her sein; DVI ist einfach unattraktiv, seitdem Monitore mit Auflösungen jenseits von WUXGA bzw. "Full-HD" üblich sind. Dual-Channel-DVI, das man dann bräuchte, war schon immer selten ... Jedenfalls: Wenn jemand zu Bastelzwecken mit einem µC einen Monitor ansteuern will, dann ist es doch ausgesprochen schön und reizvoll, daß man das mit heutigen µCs auch mit moderneren Videosignalen als Composite und VGA hinbekommt, weil halt nicht mehr in jedem Haushalt Monitore herumstehen, die damit etwas anfangen könnten. (Ich hab' extra einen alten 20"-Monitor von Dell aufgehoben, weil der auch mit Composite und S-Video zurechtkommt, allerdings hab' ich den auch schon seit gefühlt zehn Jahre nicht mehr aus dem Schrank geholt)
Niklas G. schrieb: > Ich fänd's ja eher interessant, aus den größeren i.MX SoCs natives HDMI > oder auch MIPI-DSI herauszukitzeln, Bare-Metal, ohne Linux. Tja, leider ist genau dieser Teil der SoCs meist nicht offen. Es gibt also auch keinen Linux-Treiber, in den man mal reinschmulen könnte. Alles, was geht, ist halt: den proprietären Blob genauso hochladen, wie es auch der Linux-"Treiber" tut und dann die Scheiße so (und nicht anders) zu benutzen, wie es auch der Linux-"Treiber" tut. Das ist sehr unbefriedigend. > Dann könnte > man schöne aktuelle Bildschirme anschließen. Komplette Bildschirme (also HDMI) ja. Aber bei Displays (mit MIPI-DSI) wird es doch eher eng. Man ist auf genau das beschränkt, was der Hersteller des Systems oder des SoCs unterstützt.
Harald K. schrieb: > Die "zig Millionen Bestandsgeräte" sind aber im wesentlich eines: > Ziemlich alt, wenn sie noch mit VGA daherkommen. Das ist doch kompletter Unsinn. Wie bereits zweifelsfrei festgestellt, sind sogar 20% der aktuell angebotenen Monitore noch damit ausgestattet.
Ob S. schrieb: > Tja, leider ist genau dieser Teil der SoCs meist nicht offen. Es gibt > also auch keinen Linux-Treiber, in den man mal reinschmulen könnte. Bei den i.MX ist es so semi dokumentiert. Einen binary blob in die Peripherie laden ist doch ok, ist ja sowieso die Standardlösung und keine Bastelei. Ob S. schrieb: > Aber bei Displays (mit MIPI-DSI) wird es doch eher eng. Man ist auf > genau das beschränkt, was der Hersteller des Systems oder des SoCs > unterstützt. Hmm, man kann die Peripherie und insbesondere das Timing doch recht genau einstellen und müsste damit viele Displays ansteuern können. Wird bei Linux doch genau so gemacht, konfiguriert über die DTB.
Niklas G. schrieb: > Hmm, man kann die Peripherie und insbesondere das Timing doch recht > genau einstellen und müsste damit viele Displays ansteuern können. Hast du das schonmal versucht? DSI-Displays kannst du in reicher Auswahl bei Ali kaufen. Versuch einfach mal, auch nur eins davon zum Laufen zu bekommen... Also eins, bei dem der Betrieb am konkreten SoC nicht gleich im Angebot zugesichert wird, was das Teil dann aber gegenüber sonst gleichwertigen Displays typisch preislich gleich mal eben mindestens vervierfacht. Das liegt dann halt daran, dass wer anders sich bereits der Mühe unterzogen hat, den Kram zum Laufen zu bekommen. Und der möchte auch bezahlt werden...
Ob S. schrieb: > Hast du das schonmal versucht? So halb, habe mal bei einem Rockchip SoC das Timing im U-Boot korrigiert weil es falsch war und komische Artefakte produziert hatte. Es war eine "White Label" Plattform mit vorkonfiguriertem Linux, aber eben inkorrekt. Weiß nicht mehr genau was da war. Ging aber eigentlich recht einfach. Die Transmitter in den SoCs sind eigentlich universell und müssten grundsätzlich alle Displays ansteuern können, man muss sie halt konfigurieren. Der Pixeltakt ist natürlich jeweils begrenzt, sodass man ggf. Limits bei der Auflösung oder Samplerate hat; prinzipiell wie bei VGA. Um das alles richtig umzusetzen bräuchte man natürlich Zugang zum MIPI Standard usw., deswegen schrieb ich ja dass es cool wäre das mal alles abzuhandeln.
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.