Hallo, nach einer längeren Abstinenz bin ich in der Mikrocontrollerwelt zurück und frage mich nun, ob die PICs von Microchip, mit denen ich damals gestartet bin, überhaupt noch angesagt sind, wo doch Arduino, AVR & Co den Markt offenbar dominieren - nicht ohne Gründe. Wie ist eure Meinung, werden PICs noch in der Berufswelt benutzt, wenn ja bei welcher Projektgröße, nur noch für Nischen, kleine Stückzahlen ...? Wer hat Erfahrung aus der Arbeitswelt damit und weiss, wie die Lage um die PICs ist? Danke euch und ein gutes Jahr 2026 Bernd
:
Bearbeitet durch User
Ist wohl verzerrte Wahrnehmung. Auf 100 verkaufte PICs kommt ein AVR, Arduino und andere. Nicht umsonst hat Micochip in den letzten Jahren viele andere Hersteller aufgekauft, unter anderem AVR, Micrel und viele andere. MfG Michael
Das lässt sich nicht ohne Weiteres beantworten, weil da viele Aspekte mitspielen. PICs are modern, aber so sind auch alle anderen. Wenn nicht gerade PIC spezifische Peripherie wichtig ist und es elektrisch keine wichtige Faktoren gibt und der Preis und Bezugszuverlässigkeit stimmt, dann steht dem PIC nicht viel im Wege. Ausserdem kommt Entwicklungserfahrung mit ins Spiel. Was mich betrifft, finde ich die Frage eigentlich nicht sehr zielführend.
Microchip bietet eine nahezu absure Anzahl von µC an. 2264 verschiedene. Da ist für fast jeden Unsinn was dabei das optimal passt (Ausnahmen bestätigen die Regel). Und tw. sogar noch im PDIP-Gehäuse für die komplett Zurückgebliebenen. ;-) Such dir was aus: https://www.microchip.com/maps/microcontroller.aspx
Ich sehe aus Berufssicht (Fertigung in D, Mengen im unteren 4-stelligen/a) eher 40% STM32, 35% PIC und 20% AVR, Kleckermengen auch LPC. Asiatische PCBs (Mengen- und Zukaufprodukte unserer Kunden) sind dagegen fast ausschließlich mit GD32, Rest RiscV. Das im Hobbybereich AVRs so weit verbreitet sind, liegt m.E. ausschließlich am Arduino und dessen Bootloader. PICs sind m.E. technisch fortschrittlicher, aber eben nur mit einem Programmiergerät zugänglich, auch wenn das "nix" kostet: bei Arduino reicht ein USB-Kabel, und die IDE ist wenn auch sinnlos aufgeblasen wesentlich umgänglicher als die von Microchip.
Bernd Laura schrieb: > ob die PICs von Microchip, mit denen ich damals > gestartet bin, Liegt ein wenig an der Definition von "Damals". Die alten hatten keinen Platz für einen ordentlichen Stack. So eigentlich nur ASM möglich. Ich erwarte von einem modernen µC, dass man ihn in C++, wenigstens mit C Programmieren kann. Bernd Laura schrieb: > werden PICs noch in der Berufswelt benutzt, Ein klares Ja!
Bernd Laura schrieb: > mit denen ich damals > gestartet bin Ea wäre sinnvoll das Modell / die Modelle zu nennen, so oder so. Auch wenn sich nun herausstellt dass PICs augenscheinlich mehr genutzt werden...
Jens M. schrieb: > Das im Hobbybereich AVRs so weit verbreitet sind, liegt m.E. > ausschließlich am Arduino und dessen Bootloader. Glaub ich nicht. In frühen Zeiten gab es mehr Leute die ASM geschrieben haben und da war der AVR deutlich freundlicher als der PIC mit seinen Segmentierungen.
Michael O. schrieb: > Ist wohl verzerrte Wahrnehmung. Auf 100 verkaufte PICs kommt ein AVR, > Arduino und andere Also Microchip alleine verkauft 100× so viele MCUs wie der gesamte Rest der Branche, inklusive der absurden Anzahl an Cortex-M's, RISC-V's, und chinesischen No-Name-Controllern die in jedem Spielzeug sind?
Niklas G. schrieb: > Michael O. schrieb: >> Ist wohl verzerrte Wahrnehmung. Auf 100 verkaufte PICs kommt ein AVR, >> Arduino und andere > > Also Microchip alleine verkauft 100× so viele MCUs wie der gesamte Rest > der Branche, inklusive der absurden Anzahl an Cortex-M's, RISC-V's, und > chinesischen No-Name-Controllern die in jedem Spielzeug sind? Hat er so nicht gesagt. Er sagt das Microchip für sich auf einen AVR 100 PICs verkauft. Es gibt keinen Bezug zum Rest der Welt. Wobei ich 100:1 dennoch nicht so recht glauben kann. Das würde die immer neuen AVR Modelle nicht erklären. Die Konkurrenz macht nur Cortex MCUs in Größenordnungen.
Wir verwendeten PICs in unserer Firma seit 1999 jahrelang in unseren früheren Produkten. Hauptsächlich 16F und 18F, später kamen auch DSPIC dazu. Wir arbeiteten durchwegs mit dem CCS Compiler in C. ASM wurde fast nie gebraucht. Auch der 16F877A war in C für kleinere Sachen recht brauchbar. Die DSPIC waren natürlich schon ein ganz anderes Kaliber und bewährten sich auch sehr gut. Aber später stiegen wir wegen der höheren Anforderungen und LAN/WIFI hauptsächlich auf STM32er um. In Analog Sachen verwenden wir übrigens immer noch DSPICs. Mein persönlicher Liebling fürs Hobby war für lange Zeit der 16F877A, 18F4620/40 und 18F(6)8720/2. Damit konnte ich so ziemlich alles abstrecken was mich interessierte. Heutzutage ist es nervig, wegen der großen Auswahl neue PICs auszuwählen. Das war damals noch nicht so schlimm. Vom Debug Standpunkt aus her, ist für mich der STM32 der klare Sieger.
Veit D. schrieb: > Hat er so nicht gesagt "Und andere" klingt für mich nach "alle anderen Controller"
Niklas G. schrieb: > Veit D. schrieb: >> Hat er so nicht gesagt > > "Und andere" klingt für mich nach "alle anderen Controller" Verstehe ich so, dass mit andere alle gemeint sind die AVR verbauen. Wie z.Bsp. Arduino. Die 100:1 Aussage bezieht sich klar nur auf PIC zu AVR. Betrifft allein Microchip. Ansonsten würde die 100:1 Aussage für mich überhaupt keinen Sinn machen, weil um Größenordnungen viel mehr Cortex statt PICs und AVR zusammen verkauft werden. Demzufolge kann es sich nur um eine interne Microchip Verteilung handeln. Nur wie gesagt, auch das kann ich nicht so recht glauben in dem Verhältnis.
Arduino F. schrieb: > Die alten hatten keinen Platz für einen ordentlichen Stack. > So eigentlich nur ASM möglich. > > Ich erwarte von einem modernen µC, dass man ihn in C++, wenigstens mit C > Programmieren kann. Die meisten haben keinen Stack. Aber Ram. Den Rest regelt der C-Compiler, der ein paar Restriktionen bei Funktionspointern hat und rekursive Funktionen nicht zulässt.
> seit 29.12.2025 13:55 > Beiträge 3 Alles klar!? Bernd Laura schrieb: > Hallo, > nach einer längeren Abstinenz bin ich in der Mikrocontrollerwelt zurück > und frage mich nun, ob die PICs von Microchip, mit denen ich damals > gestartet bin, überhaupt noch angesagt sind, wo doch Arduino, AVR & Co > den Markt offenbar dominieren - nicht ohne Gründe. Doch nur den Hobbybastelmurxermarkt. Wenn Angesagt überhaupt ein relevantes Thema für dich ist, dann bleib mal besser abstinent. Abseits davon gibt es immer einen Markt, für einen intelligenten 555-Ersatz. Michael O. schrieb: > ... Auf 100 verkaufte PICs kommt ein AVR Das werden wohl eher 1000 oder 10000 sein. Kein vernünftiger Entwickler würde z.B. einen ATTINY85 einsetzen. Gerhard O. schrieb: > Heutzutage ist es nervig, wegen der großen Auswahl neue PICs > auszuwählen. Einfach nur MPLAB 8.92 installieren. Wenn sich da dann kein passender findet, wäre ein PIC12/16 ohnehin ungeeignet. PIC18 und DSPIC sind heute sowieso raus. Für ersteren gibt es reichlich leistungsfähigeren Ersatz, und letzterer war und ist, ein übler Energieverheizer. Frohes Neues Jahr!
Veit D. schrieb: > weil um Größenordnungen viel mehr Cortex > statt PICs und AVR zusammen verkauft werden. Die PICs sind nicht nur MIPS-cores, sondern unter Anderem auch ARM-cores incl. CORTEX-cores. Irgendwie wird hier ständig einiges durcheinandergewürfelt. Und dabei kommt ein Obstsalat raus (Äpfel ; Birnen Vergleich) "Arduino programmiert man über USB und ist daher besser, denn bei den PICs braucht man ein Programmiergerät". Hääää???! Arduino ist kein µC, das ist ein DevBoard. Gibts auch einige von MCHP mit PICs drauf. Die zielen aber eher nicht auf den Hobby-Bereich wie der Arduino (das war das klare Ziel zu Anfang), sondern an den professionellen Entwickler. Wobei man die Discover-Boards von MCHP auch als Hobby-Segment bezeichnen mag (als Reaktion auf den Ardino-Hype). Wer PICs zum Rumspielen haben will, kann sich z.B. bei Olimex (https://www.olimex.com/) umsehen. 18 DevBoards, 10 ProtoBoards mit PICs drauf. Und 7 Programmer. Ist keine Werbung, hab noch nie was von denen verwendet. Aber die Boards werden direkt von MPLAB-X unterstützt. Kann also nicht so schlimm sein. Bei Olimex gibt es auch andere Hersteller/Cores. ARM, STM, MSP430, ... Dieses Jahr soll wohl der PIC64 auf den Markt kommen. Dann hat man auch einen RISC-V core. Falls man darauf besteht.
Nachtrag: Es gibt auch nicht DEN Arduino, das sind ganz unterschiedliche Plattformen. Angefangen hats mit einem AVR und einem ins Jämmerliche kastriertes C++. Arduino gibt/gab es auch mit RP2040. Also, das Thema "Arduino" ist auch ein ziemlicher Obstsalat.
Nick schrieb: > Die PICs sind nicht nur MIPS-cores, sondern unter Anderem auch ARM-cores > incl. CORTEX-cores. PICs sind sowas von weder MIPS noch ARM/Cortex. Du redest von den Zukäufen weil so verallgemeinernde Leute meinten das es an PICs im oberen Leistungssegment fehlte, und Mchip hat dann Architekturen zugekauft, die weder taugten, noch PICs waren, außer auf dem Aufdruck des Chips. Genauso wie mit dem angeblichen Risc-V PIC: da steht nur PIC drauf. Aber genau wie bei... Nick schrieb: > "Arduino programmiert man über USB und ist daher besser, denn bei den > PICs braucht man ein Programmiergerät". Hääää???! ... hast du den Kern der Aussage nicht verstanden. Ja, es gibt satt Boards auch mit PIC drauf. Genau so wie mit LPC, STM32, GD32 und und und. AVR sind seit mittlerweile Jahrzehnten so beliebt, weil es 2€-Platinen aus China gibt, die mit einem USB-Kabel und einer freien nicht allzu aufgeblasenen IDE plus Community von "bestellt" zu "da blinkt eine LED so wie ich das will" kommen. Das geht selbst bei vielen Demoboards nicht, weil es eben Demoboards sind, keine frei verwendbaren "Prozessoradapter", die man als Bastler auf seine Lochrasterkreation frickeln kann und die sich um die drei großen Probleme beim Verwenden eines Mikrocontrollers kümmern: Takt, Programmierschnittstelle und Löt/Steckbarkeit für einfachste Ansprüche. Die von dir genannten Boards von Olimex sind toll, aber es braucht eben immer den Programmer dazu. Und eine riesige aufgepustete IDE, die man selber erkunden muss weil es kaum Community dazu gibt gibt's kostenlos oben drauf. Der professionelle Entwickler nimmt das was er kennt (neue Programmer genehmigt zu bekommen ist ein Graus, und lange Einarbeitungszeit führt in Meetings zu Ärger warum der Milestone noch nicht fertig ist), und Bastler was billig ist. Arduino ist nicht billig, die Clones sinds bzw waren es. Jetzt kommen immer mehr Dinge auf den Markt, die ein Arduinoschild haben aber keine mehr sind, siehe aktuell den Q mit Linux und KI und einem Alibicontroller für Anfänger. Ein tolles Produkt, aber hat mit dem Grund nix mehr zu tun, ebenso wie die PICs ex 12/16/18er-Typen. Das sind BWLer-Projekte. Und ehrlich, die MIPS-PICs sind absoluter Müll. irgendwie in die IDE geflanscht, das Datenblatt völlig anders als von Mchp gewohnt (da wurde auch nur das Logo getauscht), die Hardware so PIC-untypisch, die ganzen PIC-Spezialitäten anders oder gar nicht gemacht, das ganze ist einfach Mist. Auch hier: die Projekte, die man aus Neugier mit 24er PICs gemacht hat, macht man weiter damit, denn wenn man sich an das Biest gewöhnt hat nutzt man es weiter (und die Tools und Lizenzen hab ich auch alle schon) aber "denk dir mal was gutes dazu aus" führt normalerweise nicht zu PIC24. Oder dsPIC.
Jens M. schrieb: > Nick schrieb: >> Die PICs sind nicht nur MIPS-cores, sondern unter Anderem auch ARM-cores >> incl. CORTEX-cores. > > PICs sind sowas von weder MIPS noch ARM/Cortex. Du hast das "unter Anderem" überlesen. > Du redest von den Zukäufen weil so verallgemeinernde Leute meinten das > es an PICs im oberen Leistungssegment fehlte, und Mchip hat dann > Architekturen zugekauft, die weder taugten, noch PICs waren, außer auf > dem Aufdruck des Chips. Nun, den ARM-core kann man nur kaufen. Das gilt für Alle die ihn verwenden. Das gilt dann auch für die STM32. Macht es die dann schlechter? Taugt der nichts, da der core zugekauft? Seltsame Argumentation. Microchip will nun mal ... tataaa! ... Microchips verkaufen. Und sie wollen, dass für jeden was dabei ist. Ja, MCHP kauft viel ein. Und ja, MCHP schleppt auch viele Altlasten (AVR) mit. MCHP sagt dazu: Solange die Chips gekauft werden, stellen wir sie her. Bei dem von mir verlinkten MCHP-Auswahlwerkzeug kann man auch nach cores eingrenzen. Da ist dann hoffentlich der "Richtige" für Dich dabei. Und verallgemeinern tu ich nicht. Ich weise auf die Verallgemeinerung hin! > Genauso wie mit dem angeblichen Risc-V PIC: da > steht nur PIC drauf. Wieso "angeblich"? Da ist nun mal ein RISC-V drinnen (wimre sogar 4). Ja, steht nur PIC drauf. Das ist genau das was ich als "Obstsalat" bezeichne. Vergleich von Äpfel, Birnen, Bananen, ... So hat auch der TO angefangen. PIC ist "schlechter" als Arduino oder AVR. Und genau auf dem Niveau gehts leider weiter. Um es nochmal klar zu machen: "PIC" ist eine Verallgemeinerung. So wie "Arduino" und "AVR". Mit den Begriffen kommt man nicht weiter.
Nachtrag, vergessen drauf einzugehen. Jens M. schrieb: > Das geht selbst bei vielen Demoboards nicht, weil es eben Demoboards > sind, keine frei verwendbaren "Prozessoradapter", die man als Bastler > auf seine Lochrasterkreation frickeln kann und die sich um die drei > großen Probleme beim Verwenden eines Mikrocontrollers kümmern: Takt, > Programmierschnittstelle und Löt/Steckbarkeit für einfachste Ansprüche. Ja, verdammt noch mal! Von MCHP gibts auch boards für das Steckbrett. Gibts auch von anderen Herstellern mit PIC (was auch immer für einer genau) drauf. Ja, schade (für die Bastler), Olimex bietet keine DevBoards an, die man in das Steckbrett stecken kann. Zumindest haben die dann Header. Damit dann auf ein Steckbrett zu gehen ist scheinbar für Einige zu viel verlangt. Ist halt eine Abwägung des Herstellers. Steckbrettkompatibel und beschränkt oder mit allem sinnvollen (Sicht des Herstellers), so dass man gleich loslegen kann. Ohne sich noch ein Steckbrett kaufen zu müssen und ein Modul mit SDcard und, oder, aber, nie, immer, habichschon, brauchichnicht, ... Kauf dir was Du willst. Es gibt nicht nur Olimex. Den hab ich nur aufgeführt, weil der mir bekannt ist. Sicherlich gibt es "den Chinesen" der was passendes hat. Mir persönlich sind boards die ins Steckbrett passen absolut schnurzegal. Auch DevBoards sind mir eher egal. Ich mach halt eine Platine dazu. Ist bestimmt nicht der richtige Weg zum Rumspielen. Ich persönlich hab halt keine Lust 100 MHz aufm Steckbrett versuchen zum laufen zu bringen. Wer ein Steckbrettboard haben will, soll sich eines kaufen. Wer ein DevBoard haben will, soll sich eines kaufen. Wer ein ProtoBoard haben will, soll sich eines kaufen. Wer Platinen selbst layouten will, soll das machen. Wer nichts davon haben will, kann heute die nicht explodierten Sylvesterartikel sammeln und in den Mixer kippen. Wenn er dann den Mixer dann noch einschaltet, war es seine Entscheidung.
Jens M. schrieb: > neue Programmer genehmigt zu bekommen ist ein Graus Die armen Leute die in Firmen arbeiten wo solche Zustände herrschen...
Niklas G. schrieb: > Jens M. schrieb: >> neue Programmer genehmigt zu bekommen ist ein Graus > > Die armen Leute die in Firmen arbeiten wo solche Zustände herrschen... Bei Jens M. ist scheinbar da nicht "Alles klar". ☺ Einen Laborschrank voller "Lauterbachs" wirst du aber wohl auch nicht haben. Für meinen Besten, wollte Digikey, zu seinen besten Zeiten auch $2500 haben. Das so ein USB-Bootlader bei Ex-Atmels AVRs praktisch ist, ergibt sich schon aus deren recht unpraktischen "Fuses-Konstruktion". Gleichzeitig verhindert er aber auch, dass man den Controller für einen bestimmten Einsatzzweck per Config noch feintunen kann. Da verkehrt sich der vermeintliche Nutzen dann in sein Gegenteil, und man ist dann doch auf einen Programmieradapter angewiesen. Besonders hervorgetan hat sich Atmel bei Debugadaptern ja auch nicht. Treiber die mit Demosoftware erstellt wurden, und ein Gesamtkonzept dass aus dem Adapter eine elektrische Mimose macht...
Kann es sein, daß hier im Thread Leute unterwegs sind, die jeden von Microchip hergestellten µC pauschal als "PIC" bezeichnen?
Harald K. schrieb: > Kann es sein, daß hier im Thread Leute unterwegs sind, die jeden > von > Microchip hergestellten µC pauschal als "PIC" bezeichnen? Den berühmten PICmega328P...
Nick schrieb: Das neue Jahr geht ja gut los. > So hat auch der TO angefangen. PIC ist "schlechter" als Arduino oder AVR. Auch das hat so niemand behauptet oder geschrieben. Auch der TO nicht. Du fängst mit dem Mist an. > Um es nochmal klar zu machen: "PIC" ist eine Verallgemeinerung. So wie > "Arduino" und "AVR". Mit den Begriffen kommt man nicht weiter. Das ist wohl eine Binsenweisheit und allen klar. Außerdem sind PIC und AVR Controllerserien. Arduino stellt keine Controller her, sie verbauen sie nur.
Cartman E. schrieb: > Einen Laborschrank voller "Lauterbachs" wirst du aber wohl auch > nicht haben. Nö, aber wenn ich das bräuchte... Wäre auch nur eine Geldfrage. Hatte Jens so verstanden dass ein neuer Programmer-*Typ* genehmigt werden muss, nicht die Kosten für ein weiteres Exemplar.
Veit D. schrieb: > Auch das hat so niemand behauptet oder geschrieben. Auch der TO nicht. Lies dir doch bitte nochmal den Ursprungsbeitrag durch. Danke. > Du fängst mit dem Mist an. Entspann dich! Lies dir die folgenden Antworten nochmal durch. Danke! Veit D. schrieb: > Das ist wohl eine Binsenweisheit und allen klar. Außerdem sind PIC und > AVR Controllerserien. Arduino stellt keine Controller her, sie verbauen > sie nur. Ja, ich weiß das. Der TO, und nicht nur der, würfelt aber alles lustig durcheinander. Das endet dann sinngemäss und übertrieben in "PICs kann man nicht in Steckbretter stecken". Naja, das Alles ist wohl eher ins Hobbysegment zu verorten. Und ich bin damit raus.
Nick schrieb: > Die zielen aber eher nicht auf den Hobby-Bereich wie der > Arduino (das war das klare Ziel zu Anfang), sondern an den > professionellen Entwickler. Genau das Gegenteil ist der Fall: Der Profi-Bereich war das klare Ziel. Das die Hobbyisten das übernommen haben, hat sich einfach so ergeben. Arduino (Wiring) wurde für (Licht-)-Künstler entwickelt, die damit Geld verdienen, aber nicht das Geld für die teure Bühnentechnik hatten und gleichzeitig auch kein grosses technisches KnowHow.
Niklas G. schrieb: > Cartman E. schrieb: >> Einen Laborschrank voller "Lauterbachs" wirst du aber wohl auch >> nicht haben. > > Nö, aber wenn ich das bräuchte... Wäre auch nur eine Geldfrage. Hatte > Jens so verstanden dass ein neuer Programmer-*Typ* genehmigt werden > muss, nicht die Kosten für ein weiteres Exemplar. Ja der scheinbare Plural ist da sehr mehrdeutig und auslegungsfähig. ☺ Aber es soll schon Firmen geben, die am Werkzeug sparen. Die sparen dann auch regelmässig am/beim Personal. Da wäre dann ein: "Schnell weg..." angezeigt. Mit den PIC12/16 kommt man aber recnt sparsam zurecht. Das MPLAB 8.92 hat einen vorzüglichen Simulator, der sogar die Errata, z.B. die vom Timer, korrekt simuliert. ☺
Cartman E. schrieb: > Aber es soll schon Firmen geben, die am Werkzeug sparen Jo. Es gibt definitiv Firmen die einen großen Aufriss um neue Tools/Programmiersprachen/Controller/Paradigmen machen, unabhängig von Geld. Cartman E. schrieb: > Mit den PIC12/16 kommt man aber recnt sparsam zurecht. Die STM32 sind da mittlerweile auch super, mit den diversen Evalboards unter 20€ die den Debugger gleich beinhalten.
Niklas G. schrieb: > Cartman E. schrieb: >> Mit den PIC12/16 kommt man aber recnt sparsam zurecht. > > Die STM32 sind da mittlerweile auch super, mit den diversen Evalboards > unter 20€ die den Debugger gleich beinhalten. Ein sicherer Weg, von der Ausbildung weg, eine loyale Kundenbasis zu schaffen. ☺ Sie verdienen sicher nichts damit, aber verlieren tun sie dabei sicher auch nicht viel. Immerhin ist man damit immer im Gespräch. Allerdings hätten sicher auch andere Controllerlinien bei ST, davon etwas mehr profitieren können. Da stand dann wohl der Kommerz im Weg. Für einen intelligenten 555-Ersatz werde ich bei den kleinen PIC12/16 bleiben. Können manche davon doch mit wenigen µA und einigen kHz Takt, immer noch mir ihrer Umgebung interagieren. Da ist der PICmega328P☺ in seinem Ard*o-Habitat schon lange (r)aus.
Cartman E. schrieb: > Für einen intelligenten 555-Ersatz werde ich bei den kleinen > PIC12/16 bleiben. Da tut es sogar ein PIC10F320/322, in der LF-Variante mit einem Strom im Sleep von 80 nA bei 3 Volt, der Watchdog will ggf. 800 nA bei 3 Volt, als Gehäuse gibt es DIP (!), DFN und SOT23
Cartman E. schrieb: > Ein sicherer Weg, von der Ausbildung weg, eine loyale Kundenbasis > zu schaffen Klar die machen das nicht aus Altruismus. Ganz allgemein ist das Ökosystem mittlerweile recht gut handelbar, trotz relativ komplexer Controller. Da gibt's noch ganz andere Kandidaten, unabhängig von Kosten... Mit so einem Nucleo Board kann man schon recht komfortabel und fix was zusammen basteln. Nicht so no-brainer-artig wie bei Arduino, aber wenn man schon die Erfahrung damit hat werden einem wenig unnötige Steine in den Weg gelegt. Cartman E. schrieb: > Können manche davon doch mit wenigen µA und > einigen kHz Takt, immer noch mir ihrer Umgebung interagieren Die STM32Uxx sind da mittlerweile auch recht gut drin, je nach Anforderungen. Preislich vermutlich kein Kopf-an-Kopf-Rennen, aber für kleine Stückzahlen/Basteleien... Dafür bekommt man günstige gute Debugger sowie leistungsfähige vollwertige C/C++ Compiler und IDEs als Open Source/Freeware, die dann auch für die großen Controller genutzt werden, somit kann man Workflow, Tools und Wissen über die ganze Bandbreite mitnehmen. Stephan S. schrieb: > Strom im Sleep von 80 nA bei 3 Volt Bei aktiviertem Oszillator für Timer/RTC?
:
Bearbeitet durch User
Stephan S. schrieb: > Da tut es sogar ein PIC10F320/322, in der LF-Variante mit einem Strom im > Sleep von 80 nA bei 3 Volt, der Watchdog will ggf. 800 nA bei 3 Volt, > als Gehäuse gibt es DIP (!), DFN und SOT23 Ein 555 hat 8 Beine. Die sollte das "Imitat" dann schon auch haben. Die Intelligenz kommt ja oft in Form der Auswertung externer Signale, für die es dann IOs/ADCs braucht. Und ich will daraus auch keine "Spezialwissenschaft" machen, was für mich eben mindestens 64 byte RAM heisst. Den Bedarf im Sleep habe ich bei denen bislang noch nie gemessen. Aber ich werde das bei Gelegenheit mal nachholen. DIP ist per se nichts schlechtes, wenn es die Option gibt. ☺ SO8 oder SO14 reicht mir, wenn es kleiner sein soll.
:
Bearbeitet durch User
Angehängte Dateien:
-
10f320.png
35 KB
Niklas G. schrieb: > Stephan S. schrieb: >> Strom im Sleep von 80 nA bei 3 Volt > > Bei aktiviertem Oszillator für Timer/RTC? Ich schrieb ja, dass der WD 800 nA haben will. Die 80 nA fallen z.B. an, wenn er auf ein Wakeup durch ein GPIO wartet. Cartman E. schrieb: > Ein 555 hat 8 Beine. Ein 555 hat aber keine 4 GPIOs, der PIC10F320/322 schon.
Stephan S. schrieb: > . Die 80 nA fallen z.B. an, wenn er auf ein Wakeup durch ein GPIO > wartet. Okay, das können die STM32U0 bei <60nA, mit RTC und Uhrenquartz fürs Timing bei <600nA.
Stephan S. schrieb: > Cartman E. schrieb: >> Ein 555 hat 8 Beine. > > Ein 555 hat aber keine 4 GPIOs, der PIC10F320/322 schon. Und haben erstaunlicherweise sogar 64 byte RAM. Kosten aber ca. 3x so viel, wie ein einfacher 8 Pinner mich gekostet hat. Das ist mur für einen 555-Imitator zu viel. ☺ Der muss auch im Preis einen 555 imitieren können.
Niklas G. schrieb: > Stephan S. schrieb: >> . Die 80 nA fallen z.B. an, wenn er auf ein Wakeup durch ein GPIO >> wartet. > > Okay, das können die STM32U0 bei <60nA, mit RTC und Uhrenquartz fürs > Timing bei <600nA. Immer wieder niedlich, wie die STM-Jünger ihre Stromfresser wie sauer Bier anpreisen. Wozu einen Mercedes, wenn ein Fahrrad reicht?
Roland E. schrieb: > Immer wieder niedlich, wie die STM-Jünger ihre Stromfresser wie sauer > Bier anpreisen. Frisst weniger als der PIC und der 555 sowieso 🤷♀️ Roland E. schrieb: > Wozu einen Mercedes, wenn ein Fahrrad reicht? Hab ich doch erläutert.
Niklas G. schrieb: > Roland E. schrieb: >> Wozu einen Mercedes, wenn ein Fahrrad reicht? > > Hab ich doch erläutert. Der kleine PIC wäre dann wohl der Baby-Benz, mit Saugerdiesel und Hängerkupplung.
Cartman E. schrieb: > Der kleine PIC wäre dann wohl der Baby-Benz Hätte Benz jetzt mit Komfort assoziiert, also das was man beim Cortex-M hat, aber beim 8bitter eher nicht so.
Niklas G. schrieb: > Cartman E. schrieb: >> Der kleine PIC wäre dann wohl der Baby-Benz > > Hätte Benz jetzt mit Komfort assoziiert, also das was man beim Cortex-M > hat, aber beim 8bitter eher nicht so. Das Fahrzeug mit dem Berta Benz die berühmte Fahrt machte war bestimmt nicht komfortabel.
:
Bearbeitet durch User
H. H. schrieb: > Das Fahrzeug mit dem Berta Benz die berühmte Fahrt machte war bestimmt > nicht komfortabel. Aber mit mehr Sinn für Ästhetik gestaltet als die heutigen Dicke-Hose-nix-dahinter-Karren für Hamdi & Marvin und andere Fahranfänger.
H. H. schrieb: > Das Fahrzeug mit dem Berta Benz die berühmte Fahrt machte war bestimmt > nicht komfortabel. Ob die Fahrräder zu der Zeit komfortabler waren? Die hießen nicht umsonst mal "boneshaker".
Der Komfort eines Baby-Benz liegt tiefer. Man könnte mit ihm, ohne einen Werkstattbesuch einplanen zu müssen, seinen Camper einmal bis zum Mond, und wieder zurück schleppen. Eventuell müsste man unterwegs, die Steuerkette nachspannen. Mit einem Ferrari wäre man selbst zwar schneller, müsste aber regelmässig auf das Begleitfahrzeug mit den Ersatz-Ferraris warten. Leider sind Raumtankstellen nur genau so selten wie Ladesäulen. Und, heisst es nicht: Besser gut gefahren, als schlecht gelaufen? ☺
Niklas G. schrieb: > ... > Hab ich doch erläutert. Ja, wie so oft wenn die STM-Leute ihre Ware anpreisen. Spektakulär aber unglaubwürdig. Aus zwei (wahllos aus den genannten Serien) herausgegriffenen Datenblättern kann ich die Behauptung, dass der STM weniger Strom brauche als der PIC nicht nachvollziehen. Deine beschriebvenen 60nA reichen nämlich nicht, wenn du auf eine I/O warten möchtest. Da kommen nämlich noch mal 50..80µA/MHz für das AHB des GPIO-Peripherals dazu. Und damit ist er über dem PIC und für (extreme) Low-Current nach wie vor raus. Preislich sowieso. Gerade die Bus-Matrix vom STM bricht ihm bei diesen Extremanforderungen oft das Genick. Zu komplex, zu stromhungrig. haben wir hier auch regelmäßig, wenn das batteriegepufferte Gerät die Batterie in einem Monat leernuckelt, obwohl sie lt Datenblatt ein Jahr halten solle. Man braucht halt die aktivierten Busse zu den Peripherals. Das läppert sich ganz schnell. Und regelmäßig spucken all die tollen Debug-Tools dazwischen, weil die Prozessormodule aktivieren, die man eigentlich nicht braucht. Oder in der falschen Reihenfolge aktivieren, zB externe LFXEs. Nein, für die oben genannte Spielerei ist ein PIC genau richtig. Und auch in den nächsten Jahrzehnten nicht überholt. Und falls STM das irgenwann wirklich schafft das Feld der kleinen PICs mit seinen STM32s zu beackern, setzt MC den PIC auf einer modernere Struktur um und reduziert den Strom um eine oder zwei Größenordnungen. Man darf nicht vergessen, die Designs und Prozesse der kleinen PICs sind alle samt mehrere Jahrzehnte alt. Niklas G. schrieb: > ... > Frisst weniger als der PIC und der 555 sowieso 🤷♀️ > Nagut, der LMC555 braucht wohl 20nA mehr. Wenigstens der Teil deiner Aussage stimmt.
Roland E. schrieb: > Da kommen nämlich noch mal 50..80µA/MHz für das AHB des GPIO-Peripherals > dazu Der AHB, Takt und Peripherie selbst sind aus. Der interne LDO welcher den Großteil der digitalen Logik versorgt ist abgeschaltet. Die Low-Power Wake-Up Pins haben eine dedizierte Input-Stufe welche ohne Takt auskommt und ohne Bus direkt den LDO wieder einschalten kann. Dafür wird nichtmal der 32kHz Takt benötigt. Roland E. schrieb: > Preislich sowieso Wie gesagt. Roland E. schrieb: > Man braucht halt die aktivierten Busse zu den Peripheral Aber eben nur wenn die Peripherals auch an sind. Man braucht ein Power-Management Framework in der Firmware welches nur das einschaltet was gerade gebraucht wird. Was die HAL mitliefert ist da eher rudimentär. Roland E. schrieb: > Und regelmäßig spucken all die tollen Debug-Tools dazwischen, weil die > Prozessormodule aktivieren, die man eigentlich nicht braucht. Das stimmt, darüber bin ich auch schon gestolpert. Kann man die PICs ohne Takt debuggen, ohne den Verbrauch im Standby zu erhöhen? Solange man bei den STM32 keine Verbindung per SWD/JTAG aufbaut spielt das aber alles keine Rolle, die Debug-Peripherie bleibt ausgeschaltet. Roland E. schrieb: > Nagut, der LMC555 braucht wohl 20nA mehr. Inklusive des Stroms durch die externen R und C?
Niklas G. schrieb: > Roland E. schrieb: >> Da kommen nämlich noch mal 50..80µA/MHz für das AHB des GPIO-Peripherals >> dazu > > Der AHB, Takt und Peripherie selbst sind aus. Der interne LDO welcher > den Großteil der digitalen Logik versorgt ist abgeschaltet. > Die Low-Power Wake-Up Pins haben eine dedizierte Input-Stufe welche ohne > Takt auskommt und ohne Bus direkt den LDO wieder einschalten kann. Dafür > wird nichtmal der 32kHz Takt benötigt. > > ... Gut, mit des STM32U habe ich noch nicht gearbeitet, aber bei den "normalen" STM32F muss der AHB für die (benutzte) GPIO an sein. Sonst gibts keinen IRQ, der irgend etwas aufweckt.
Roland E. schrieb: > aber bei den "normalen" STM32F muss der AHB für die (benutzte) GPIO an > sein. Von den alten STM32Fxx habe ich aber nicht geredet, die waren nie wirklich für low-power gemacht. Das ganze Power-Management ist bei den STM32Lxx, STM32UXX, STM32WLx5, STM32WB komplett neu. Der Wake-Up aus den Standby/Poweroff -Modi ist ein dediziertes System das mit den EXTI Interrupts und dem Bus nichts zu tun hat. Es wird nur initial über den Bus via Peripherieregister konfiguriert und läuft dann unabhängig. Die Register gehören nichtmal zum GPIO-Controller, sondern zum PWR-Block.
Cartman E. schrieb: > Kein vernünftiger Entwickler würde z.B. einen ATTINY85 einsetzen. Ist das nur Bashing oder gibt es auch eine plausible Begründung dafür?
[x] Bashing [ ] plausible Begründung Wir kennen doch unseren Cartman.
Was halten wir denn vom PML100B? Das scheint die Low-Power MCU zu sein, die in den ganzen Akkubetriebenen Lampen steckt. https://www.lcsc.com/product-detail/C49173943.html Außerhalb der low-power Diskussion macht ein PIC eigentlich keinen Sinn.
H. H. schrieb: > Tim . schrieb: >> Was halten wir denn vom PML100B? > > Ist halt OTP. Naja, das ist aber nur bei Kleinserien wirklich relevant. Oder wenn man wirklich In-field updates braucht.
Bernd Laura schrieb: > nach einer längeren Abstinenz bin ich in der Mikrocontrollerwelt zurück Tim . schrieb: >> Ist halt OTP. > > Naja, das ist aber nur bei Kleinserien wirklich relevant. Der Eingangspost klingt für mich nicht nach Großserie, sondern eher nach Hobby.
H. H. schrieb: > Tim . schrieb: >> Was halten wir denn vom PML100B? > > Ist halt OTP. Das ist für fehlerfrei arbeitende Entwickler ja dann kein Problem. ☺ Rick schrieb: > Cartman E. schrieb: >> Kein vernünftiger Entwickler würde z.B. einen ATTINY85 einsetzen. > Ist das nur Bashing oder gibt es auch eine plausible Begründung dafür? Das früher(TM) extrem ungünstige Preis-Leistungs-Verhältnis. Immerhin scheint der Markt diesen Preis nicht mehr herzugeben. Das sollte einem schon zu Denken geben. Bei Reichelt ist er auf ca. 1,50 gefallen, was mir für sein etwaiges Einsatzspektrum immer noch viel zu viel wäre. Vermutlich wird er bald den N.R.F.D.-Bempel bekommen. ☺ Der Pichler übt sich wieder in Unterstellungen. Ich kann alles programmieren was nicht bei Drei auf dem Baum ist.
Cartman E. schrieb: > ungünstige Preis-Leistungs-Verhältnis Na wenn es nur das ist. In die Gesamtkosten einer Entwicklung bzw. eines Produktes fließen noch ein paar weitere Faktoren mit ein. Zum Glück wurde BWL erfunden und Leute die sich damit auskennen...
> Der Eingangspost klingt für mich nicht nach Großserie, sondern eher nach > Hobby. Dann sollte PIC eigentlich keine Rolle mehr spielen.
Rick schrieb: > Cartman E. schrieb: >> ungünstige Preis-Leistungs-Verhältnis > Na wenn es nur das ist. > In die Gesamtkosten einer Entwicklung bzw. eines Produktes fließen noch > ein paar weitere Faktoren mit ein. Das kommt dann noch erschwerend hinzu. > Zum Glück wurde BWL erfunden und Leute die sich damit auskennen... Es geht hier um den Hobbybereich. Ich habe noch Preise von mehreren Euro per Controller in guter Erinnerung. Verwendung fand der ATTINY85 ja vor allem bei Bildungsprodukten des Franzis-Verlags. Da bin ich nicht in der Zielgruppe. >> N.R.F.D. > Not Recommended For Designs? [x]
Tim . schrieb: >> Der Eingangspost klingt für mich nicht nach Großserie, sondern eher nach >> Hobby. > > Dann sollte PIC eigentlich keine Rolle mehr spielen. Und das bestimmst du? ☺
Cartman E. schrieb: > Tim . schrieb: >>> Der Eingangspost klingt für mich nicht nach Großserie, sondern eher nach >>> Hobby. >> >> Dann sollte PIC eigentlich keine Rolle mehr spielen. > > Und das bestimmst du? ☺ Naja, wenn man sich spezifisch für 8-bit Mikrocontroller interessiert, dann kommt natürlich auch PIC in Frage. Aber Padauk, AVR und STM8 sind vielleicht sogar interessanter. Ansonsten gibt es viele 32 bit alternativen: RP2040, STM32, CH32V, PY32F etc...
Tim . schrieb: > Cartman E. schrieb: >> Tim . schrieb: >>>> Der Eingangspost klingt für mich nicht nach Großserie, sondern eher nach >>>> Hobby. >>> >>> Dann sollte PIC eigentlich keine Rolle mehr spielen. >> >> Und das bestimmst du? ☺ > > Naja, wenn man sich spezifisch für 8-bit Mikrocontroller interessiert, > dann kommt natürlich auch PIC in Frage. Aber Padauk, AVR und STM8 sind > vielleicht sogar interessanter. Die wohl interessantesten 8-bit Controller, sind die der TMS7000 Familie. Einem Chameleon gleich, darf man die sogar mit eigenen Mikroprogrammen erweitern. Oder die PLD/Controller-Hybriden der ST UPSD3200-Serie. Aber wie hier auch schon andere festgestellt haben, ist es sehr einfach, mit 8-bit PICs stromspared Ideen umzusetzen. Genauso setze ich aber auch 16-bitter, 32-bitter, DSPs und FPGAs in meinen Hobbyprojekten ein. Wenn ich eine Architektur kenne, und es mir zweckmässig erscheint, dann verwende ich sie. Gelegentlich ist es auch amüsant, z.B. von einem der kleinen PICs für ein FPGA-Projekt die Arithmetik "machen zu lassen". Die Berechnungen werden nur beim Start benötigt, und lassen sich damit einfacher flexibel anpassen. Wenn jemand anfängt, sich mit Controllern zu beschäftigen, sind PICs wegen ihrer überschaubaren Architektur durchaus auch keine schlechte Wahl. Er wird nur lernen müssen, auch Datenblätter zu lesen, und sich um manche Dinge selbst kümmern zu müssen. Z.B. Bibliotheken für die trivialen Dinge selbst zu schreiben. Er wird dabei vermutlich mehr lernen und verstehen, als es ein Arduino mit seiner Umgebung jemals für ihn tun könnte. Er wird dann auch nicht bei den kleinen PICs stehenbleiben, und sich selbst seinen weiteren Weg suchen, während die Arduinos für ewig, in ihrem Sandkasten sitzen bleiben werden. Sie haben ja nichts anderes gelernt und das wichtigste daber verlernt. Wenn nun jemand damit nur "basteln" will, dann soll er das tun. Er wird aber dabei auch nur ein "Bastler" bleiben. > Ansonsten gibt es viele 32 bit alternativen: RP2040, STM32, CH32V, PY32F > etc... Auch bei den Alternativen gibt es noch wesentlich mehr. ☺ Dort die richtige Auswahl zu treffen, ist dann schon schwieriger.
Cartman E. schrieb: > während die Arduinos > für ewig, in ihrem Sandkasten sitzen bleiben werden. Ich hab mit Arduino angefangen 🤷♂️ hat mir nicht geschadet.
Cartman E. schrieb: > Wenn jemand anfängt, sich mit Controllern zu beschäftigen, sind > PICs wegen ihrer überschaubaren Architektur durchaus auch keine > schlechte Wahl. Das Argument hört man immer wieder. Die PIC-Architektur mag simpel sein, aber sie ist weder representativ für aktuelle Prozessorarchitekturen noch einfach zu programmieren. Und warum man ausgerechnet als Anfänger eine MCU in Assembler programmieren soll, ist mir nicht klar. Für C sind andere Architekturen viel besser geeignet. Würde allerdings heutzutage jedem Anfänger erst einmal µPython vorschlagen...
Tim . schrieb: > ... > Und warum man ausgerechnet als Anfänger eine MCU in Assembler > programmieren soll, ist mir nicht klar. ... [ ] Du hast noch nie ernsthaft einen Debugger benutzt, richtig? Nur an/mit Assembler sieht man, was die CPU wirklich treibt. Daher ist es didaktisch mehr als sinnvoll genau damit anzufangen. Du hast in der 1.Klasse auch nicht gleich mit komplexer Grammatik angefangen, sondern mit den Buchstaben aus denen die Worte zusammengebaut werden.
Roland E. schrieb: > Daher ist > es didaktisch mehr als sinnvoll genau damit anzufangen. Und als Fahrschüler fängt man mit M6er Schrauben an... Nöö Deine Logik "riecht"!
Arduino F. schrieb: > Roland E. schrieb: >> Daher ist >> es didaktisch mehr als sinnvoll genau damit anzufangen. > Und als Fahrschüler fängt man mit M6er Schrauben an... > > Nöö > Deine Logik "riecht"! Man kann ja notfalls den ADPC anrufen...
Roland E. schrieb: > Nur an/mit Assembler sieht man, was die CPU wirklich treibt. Daher ist > es didaktisch mehr als sinnvoll genau damit anzufangen. Fast. Eigentlich ist Assembler ja schon fast eine Hochsprache. ;-) Also: [AD] 0200 [DA] A2 [+] 02 [+] CA [+] D0 [+] FD [+] 00 [+] [AD] 0200 Schalter auf Single step. [GO]
Roland E. schrieb: > Nur an/mit Assembler sieht man, was die CPU wirklich treibt. Daher ist > es didaktisch mehr als sinnvoll genau damit anzufangen. An wie vielen Hochschulen wird heutzutage noch mit Assembler begonnen, und wie viele erfolgreiche Software-Entwickler haben so angefangen?
Niklas G. schrieb: > Mit so einem Nucleo Board kann man schon recht komfortabel und > fix was zusammen basteln. Nicht so no-brainer-artig wie bei Arduino, > aber wenn man schon die Erfahrung damit hat werden einem wenig unnötige > Steine in den Weg gelegt. Doch doch, geht ziemlich gleich: https://github.com/stm32duino/Arduino_Core_STM32
Christoph M. schrieb: > Doch doch, geht ziemlich gleich: Stimmt geht auch. Wobei es auch Vorteile hat direkt die "vollwertige" Entwicklungsumgebung mit allen Möglichkeiten zu nutzen.
Du kannst aber nicht behaupten, das man das nicht auch merkt. Software wird immer aufgeblasener, und zwar gefühlt doppelt so viel Luft wie Funktion, weil das Programmieren Geld kostet und daher viel einfach so eingebunden wird, Hardwarepower ist ja genug da. Eben auch weil die gar nicht wissen was da passiert (oder passieren muss). Es erfolgt so langsam ein Umdenken, weil dieser Umstand mittlerweile schon von bösartigen Mächten ausgenutzt wird, aber es wurde 20 Jahre so gemacht, das machen wir auch weiterhin so.
:
Bearbeitet durch User
Norbert schrieb: > Fast. > Eigentlich ist Assembler ja schon fast eine Hochsprache. ;-) Auf jeden Fall ..
1 | >++++++++[<+++++++++>-]<.>++++[<+++++++>-]<+.+++++++..+++.>>++++++[<+++++++>-]<+ |
2 | +.------------.>++++++[<+++++++++>-]<+.<.+++.------.--------.>>>++++[<++++++++>- |
3 | ]<+. |
Norbert schrieb: > [AD] 0200 > [DA] > A2 [+] > 02 [+] > CA [+] > D0 [+] > FD [+] > 00 [+] > [AD] 0200 > Schalter auf Single step. > [GO] $02 ist doch viel zu wenig...
Niklas G. schrieb: > Stimmt geht auch. Wobei es auch Vorteile hat direkt die "vollwertige" > Entwicklungsumgebung mit allen Möglichkeiten zu nutzen. Da hast du Recht. In einem Serienprodukt mit entsprechender Stückzahl wird vermutlich nahezu niemand eine Arduino-Umgebung nutzen. In einem Testaufbau um mal schnell was zu messen schon.
Jens M. schrieb: > Eben auch weil die gar nicht wissen was da passiert Unterstellung. Genug Entwickler wissen das sehr wohl, aber die Vorgabe von oben lautet "bis gestern fertig". Da kann man noch so toll Assembler programmieren... Das geht ja so weit dass einige Unternehmen die Vorgabe machen, den Code mit LLMs schreiben zu müssen, damit es noch schneller geht - Effizienz, Sicherheit, Zuverlässigkeit spielt keine Rolle. Die wichtigste Fähigkeit ist schon längst nicht mehr "einzelne Takte wegoptimieren". Lange Zeit war es "große Komplexität im Griff behalten", jetzt ist es "das LLM dazu bringen etwas verkaufbares auszuspucken". Da ist der Einstieg per Assembler gar nicht mal so hilfreich. Vermutlich wird bald sowieso keiner mehr Programmiersprachen direkt benutzen, weder Assembler noch C oder JS.
Angehängte Dateien:
-
AVR_TCB_Mode.png
85 KB -
PIC18_TMR1.png
45 KB
Die Datenblätter von AVR sind für mich verständlicher: https://www.mikrocontroller.net/attachment/615726/AVR_TCB.png https://www.mikrocontroller.net/attachment/666147/AVR_TCB_Input_Capture_Pulse-Width_Measurement.png Und bei PIC muss ich zuerst von jemandem erklärt bekommen, welche Zähler welche Aufgaben ausführen können.
Niklas G. schrieb: > wie viele erfolgreiche Software-Entwickler haben so (mit Assembler) angefangen? Die sind schon im Ruhestand oder freuen sich darauf.
Jens M. schrieb: > Software wird immer aufgeblasener, und zwar gefühlt doppelt so viel Luft > wie Funktion Das war schon in den 90er Jahren zu sehen, als Frameworks aufkamen. Es hat keinen Sinn such darüber zu ärgern, denn du kannst diesen Fortschritt nicht stoppen.
Nemopuk schrieb: > Jens M. schrieb: >> Software wird immer aufgeblasener, und zwar gefühlt doppelt so viel Luft >> wie Funktion > > Das war schon in den 90er Jahren zu sehen, als Frameworks aufkamen. Es > hat keinen Sinn such darüber zu ärgern, denn du kannst diesen > Fortschritt nicht stoppen. Ich würde es eher als Tendenz denn als Fortschritt bezeichnen. In absehbarer Zeit wird sowieso nur noch der KI erzählt was das Produkt machen soll und die wird's dann schon (hin)richten.
Dieter W. schrieb: > In absehbarer Zeit wird sowieso nur noch der KI erzählt was das Produkt > machen soll und die wird's dann schon (hin)richten. Und wenns schief geht, dann hat man gleich den Sündenbock.
Bernd Laura schrieb: > Wie ist eure Meinung, werden PICs noch in der Berufswelt benutzt Sicher, sie sind billig. Das ist der Hauptentscheidungsgrund für die Industrie, daher auch gerne WCH und 8051. Aber das ist kein Grund, sie auch als Hobby zu nutzen. Da ist selbst der AVR überholt, man nutzt entweder STM32 oder ESP32. Moderne Arduinos nutzen ebenfalls keine AVR mehr. Interessant ist die Frage, ob es in die uC Familie auch Chips mit LCD Treibern und mit LED Treibern gibt, ob 5V tolerante Eingänge existieren und Chips mit USB und WLAN Support, und ob sie stromsparend arbeiten können in einem Spannungsbereich der zu Batterien oder Akkus passt. Viele Chips gehen NICHT direkt an LiIon sondern brauchen energiefressende Spannngsregler und können ihre eigene Betriebsspannung nicht per ADC messen. Manche Chips haben so schwache Ausgänge daß sie nicht mal LEDs ansteuern können ohne Transistor.
Ein guter Entwickler welcher gezwungen wird mit künstlichem Gelumpe zu arbeiten, sollte doch wohl in der Lage sein seine Prompts auf eine unschuldige Art und Weise so zu formulieren, dass ein gut versteckter, sehr teurer Fehler erst viel später in Erscheinung tritt. Den gesamten Prozess dokumentieren und dann viel später und bei Bedarf der Manglement Etage mit einer leichten Verbeugung überreichen. Grinsen dabei unterdrücken (vorher üben).
Norbert schrieb: > Nemopuk schrieb: >> schaden. > > Altes Sprichwort: Aus Schaden wird man klug. Trifft bei Dachschaden nicht zu.
Michael B. schrieb: > Viele Chips gehen NICHT direkt an LiIon sondern brauchen > energiefressende Spannngsregler Kennst du MCUs, die direkt bei 4.2V betrieben werden können, und deren Energieverbrauch dann auch niedriger ist als z.B. bei Betrieb bei 1.8V + Buck-Converter 4.2->1.8V (modernes effizientes Exemplar vorausgesetzt)? Norbert schrieb: > sollte doch wohl in der Lage sein seine Prompts auf eine > unschuldige Art und Weise so zu formulieren, dass ein gut versteckter, > sehr teurer Fehler erst viel später in Erscheinung tritt. Es gibt einfachere Wege gefeuert zu werden.
Niklas G. schrieb: > die Vorgabe > von oben lautet "bis gestern fertig". Da kann man noch so toll Assembler > programmieren Ich unterstelle, das viele Entwickler sowohl von Software, als auch von Firmware und ebenso von Hardware sowohl mit als auch ohne "Intelligenz" eben genau nicht mehr wissen wie es funktioniert, sondern nur wie es geht. Und das nicht nur auf Grundlage von Assemblersprache, sondern schon weiter oben nicht mehr. Ich habe in den letzten 35 Jahren meines Berufslebens so viele "boah echt jetzt?"-Momente gehabt, das ich bezweifle das der oder die Entwerfer und Bauer dieses Geräts es auch nur 3 Minuten selber benutzt haben. Besonders tun sich da Amerikaner hervor, Koreaner sind auch sehr gut in sinnlosen Verrenkungen, und die Deutschen werden auch in den letzten Jahren immer auffälliger. Niklas G. schrieb: > Effizienz, Sicherheit, Zuverlässigkeit spielt keine Rolle. Genau das mein ich. Niklas G. schrieb: > jetzt ist es "das LLM dazu bringen etwas verkaufbares auszuspucken". Da > ist der Einstieg per Assembler gar nicht mal so hilfreich. Wenn die Geundlagen des Programmier-LLMs Codebeispiele, Compiler und Datenblätter von LLMs sind, explodiert die Welt, wie im "Per Anhalter durch die Galaxis": plopp, weg. Meine Experimente mit "Erstelle mir einen Code, der auf einem Arduino nano 10kHz mit 50% Tastverhältnis an Pin 6 erzeugt" waren jedenfalls enttäuschend, ohne genaue Maschinenkenntnisse und Datenblatt war das Gestammel nicht verwertbar. Eine leere Vorlage in einer IDE plus Autocorrect wäre sinnvoller gewesen. Niklas G. schrieb: > Vermutlich > wird bald sowieso keiner mehr Programmiersprachen direkt benutzen, weder > Assembler noch C oder JS. Gnade uns Gott. Alles funktioniert nur noch mit KI-Blockchain in der Cloud. Nemopuk schrieb: > Es > hat keinen Sinn such darüber zu ärgern, denn du kannst diesen > Fortschritt nicht stoppen. Schöne neue Welt, wenn das "Fortschritt" ist. H. H. schrieb: > Und wenns schief geht, dann hat man gleich den Sündenbock. Wer ist Schuld? Der Prompter? Der KI-Anbieter? Der KI-Trainer? Michael B. schrieb: > Viele Chips gehen NICHT direkt an LiIon sondern brauchen > energiefressende Spannngsregler und können ihre eigene Betriebsspannung > nicht per ADC messen. Manche Chips haben so schwache Ausgänge daß sie > nicht mal LEDs ansteuern können ohne Transistor. Das sind aber doch gerade die von dir so gelobten STM32 und ESP? PICs und AVRs laufen hervorragend im Stromsparbetrieb an Standard-Alkali- oder Lipozellen und können leicht LEDs treiben, auch kleine Summer, Lautsprecher und Optorelais gehen. Ja, wenig Rechenleistung und kein WLAN, das ist heute ein KO-Argument, denn ohne Cloud, Webseite und Python geht nix mehr. Nemopuk schrieb: > würde nicht seinem eigenen Arbeitgeber schaden. Manchmal muss man nicht der Firma, aber der Führungsetage klar machen, das es so nicht weitergeht. "Lernen durch Schmerzen" oder "Zum eigenen Glück zwingen" nennt man das. Oder auch "Fakten schaffen". Das schadet nicht immer dem eigenen Arbeitgeber, sondern kann die Situation für alle verbessern. Inklusive Shareholder Value.
Jens M. schrieb: > Ich habe in den letzten 35 Jahren meines Berufslebens so viele "boah > echt jetzt?"-Momente gehabt Das beweist alles nicht, dass es am Unwissen der Entwickler liegt. Jens M. schrieb: > Niklas G. schrieb: >> Effizienz, Sicherheit, Zuverlässigkeit spielt keine Rolle. > > Genau das mein ich. Ich meine aber, dass diese Einstellung von oben kommt. Jens M. schrieb: > Meine Experimente mit "Erstelle mir einen Code, der auf einem Arduino > nano 10kHz mit 50% Tastverhältnis an Pin 6 erzeugt" waren jedenfalls > enttäuschend, ohne genaue Maschinenkenntnisse und Datenblatt war das > Gestammel nicht verwertbar. Weil die LLMs noch nicht eingehend auf so etwas trainiert sind. Das wird sich aber ändern. Wenn STM32CubeMX mal einen MCP-Server eingebaut bekommt, kann das LLM sich die Hardware-PWM einfach "zusammenklicken". Jens M. schrieb: > Gnade uns Gott. Alles funktioniert nur noch mit KI-Blockchain in der > Cloud. Genau das will doch praktisch die gesamte globale IT/Technologie-Branche, und sogar die Politik. Das ganze globale Finanzsystem wettet darauf dass es so kommt. Wettest du dagegen? Jens M. schrieb: > Das sind aber doch gerade die von dir so gelobten STM32 und ESP? Die STM32 können all das, außer Betrieb bei über 3.6V, aber m.W. würde das keinen Strom sparen, im Gegenteil. Jens M. schrieb: > Manchmal muss man nicht der Firma, aber der Führungsetage klar machen, > das es so nicht weitergeht. Da ja die großen Tech-Firmen signifikante Anteile ihres Codes nur noch per LLM erzeugen, scheint es ja durchaus weiter zu gehen.
Niklas G. schrieb: > Da ja die großen Tech-Firmen signifikante Anteile ihres Codes nur noch > per LLM erzeugen Tun sie das wirklich? Oder sagen sue nur "wir arbeiten mit KI". Ich denke, da wird momentan viel quatsch geschrieben, um die Blase nicht platzen zu lassen.
Nemopuk schrieb: > Tun sie das wirklich? Oder sagen sue nur "wir arbeiten mit KI" Wer weiß, aber was dort wirklich passiert spielt keine große Rolle. Mit der KI ist es wie damals bei "Nobody ever got fired for buying IBM" - selbst wenn es mit der KI nicht klappt, hat man doch sein Möglichstes getan. Während KI-Verweigerer gefeuert oder gar nicht erst eingestellt werden.
:
Bearbeitet durch User
Niklas G. schrieb: > Da ja die großen Tech-Firmen signifikante Anteile ihres Codes nur noch > per LLM erzeugen, scheint es ja durchaus weiter zu gehen. Vieles davon dürfte Blase sein um die Shareholder noch glücklicher zu machen, und nur weil es gemacht wird ist es nicht gut. Man kann Dinge auch 20 Jahre lang falsch machen. Oder eben falsch beginnen. Niklas G. schrieb: > Während KI-Verweigerer gefeuert oder gar nicht erst eingestellt > werden. Das ist das traurige. Wer versteht denn was KI da so macht, was es für Auswirkungen hat und wie man es korrigiert oder verhindert? KI selber ja leider nicht. Und wenn Mensch KI kontrollieren muss, kann Mensch auch gleich selber machen. KI ist so schnell gewachsen, das niemand absehen kann welche Folgen noch aufleuchten werden. Sicher gibt es sinnvolle Anwendungen, aber auf Teufel komm raus KI überall einzubauen nur um "Vegan, KI, 100% Ökostrom" draufzuschreiben ist gefährlich. Das ist ja das witzige gerade. Einerseits "Wir haben Fachkräftemangel", was zu "wir brauchen Ausländer" wird, aber gleichzeitig "wir hatten noch nie so viele Entlassungen wie jetzt". Nanü? Es können nicht alle Häuptlinge sein, es braucht auch ein paar Indianer.
Jens M. schrieb: > Man kann Dinge > auch 20 Jahre lang falsch machen. Oder eben falsch beginnen. Wenn man 20 Jahre dafür bezahlt wird es falsch zu machen, war es offenbar recht nachhaltig und bezahlt die Miete. Jens M. schrieb: > Wer versteht denn was KI da so macht Man kann sich den generierten Code ja auch von der KI erklären lassen. Jens M. schrieb: > Und wenn Mensch KI kontrollieren muss, kann Mensch auch > gleich selber machen. Die KI kontrolliert sich selbst, über Test-Cases. Wenn's nicht funktioniert, versucht der Agent es halt nochmal. Jens M. schrieb: > aber auf Teufel komm raus KI > überall einzubauen Man muss es ja nicht einbauen, aber man kann es zur Entwicklung des Produkts nutzen. Jens M. schrieb: > Wir haben Fachkräftemangel Sagt das noch wer? Jens M. schrieb: > Es können nicht alle Häuptlinge sein Dank KI halt schon! Der CEO lässt das LLM programmieren. Keine teuren Entwickler mehr nötig.
Niklas G. schrieb: > Der CEO lässt das LLM programmieren. Keine teuren > Entwickler mehr nötig. Ohne Indianer fühlt sich kein Häuptling als Häuptling. Die Folge: Die Hersteller von Therapeuten-Sofas erleben ein Allzeit-Hoch.
Niklas G. schrieb: > Kennst du MCUs, die direkt bei 4.2V betrieben werden können, und deren > Energieverbrauch dann auch niedriger ist als z.B. bei Betrieb bei 1.8V + > Buck-Converter 4.2->1.8V 5V AVR, PicoPower. Allgemein 5V uC.
Michael B. schrieb: > 5V AVR, PicoPower Laut Datasheet steigt deren Verbrauch bei höherer Spannung, somit wäre Betrieb bei niedrigster möglicher Spannung + Buck-Converter effizienter. Rolf schrieb: > Ohne Indianer fühlt sich kein Häuptling als Häuptling Die CEOs sind es doch die KI so lautstark befürworten, daher denke ich mal dass es für sie in Ordnung geht. Vielleicht wenn sie den KI-Agenten Namen geben. "Depp 7, kodiere mir eine smarte Taschenlampe!" "Sehr wohl, Euer Durchlaucht"
Niklas G. schrieb: > Michael B. schrieb: >> Viele Chips gehen NICHT direkt an LiIon sondern brauchen >> energiefressende Spannngsregler > > Kennst du MCUs, die direkt bei 4.2V betrieben werden können, und deren > Energieverbrauch dann auch niedriger ist als z.B. bei Betrieb bei 1.8V + > Buck-Converter 4.2->1.8V (modernes effizientes Exemplar vorausgesetzt)? > PICs. Die Laufen von 5..1,8V. Mit den benannten <1µA Stromverbrauch. Ich nutze die nach wie vor im Modellbau, weil es einen Spannungsregler einspart. Blaue und weiße LED leuchten üblicherweise nicht mit 3,3V...
Für manche schein es hier ein philosophisches Problem zu sein, welche Controller-Familie mit welcher Programmiersprache verwendet werden soll. Wer aber auf die Anforderungen seiner Applikation schaut, findet bei den PICs nicht selten (die Produktionszahlen belegen es) die beste Lösung. Meine letzten Projekte besaßen sehr kleine Formfaktoren der Schaltung, bei niedrigem Preis und nicht allzu stabiler Betriebsspannung (Akku/Batterie ohne Stabilisierung). Die damit realisierten Grafik-Anwendungen benötigten teilweise einen sehr effizienten Code, der nur mit Assembler realisiert werden konnte. Die Umwandlung von Bild-Dateien und ihrer Komprimierung in eine Tabelle, die direkt in den Assembler-Code implementiert werden konnte, erledigt hierbei eine KI. Für die Realisierung von Motorsteuerungen, Schnittstellen und diversen Sensorauswertungen sind viele moderne Hardware-Funktionsblöcke in den Controllern vorhanden, was bei diesen Projekten ebenfalls sehr hilfreich ist. Die verschiedenen Schaltungen werden als Kleinserie gefertigt und in unterschiedlichen Produkten verkauft. Hierbei spielt dann noch die gute Verfügbarkeit der Controller eine wichtige Rolle.
Martin schrieb: > Für manche schein es hier ein philosophisches Problem zu sein, welche > Controller-Familie mit welcher Programmiersprache verwendet werden soll. Gotthold Ephraim Turing: Nathan der Programmierer.
Aus meiner Sicht wähle ich meist den uC der für meine Anwendung am Zweckmässigsten ist. Ferner hängt es davon ab, inwieweit die Anwendung verfolgbar mit dem Debugger sein muss. Es gibt (einfachere) Projektarten wo man mit Serial Debugging auskommt und dann gibt es (kompliziertere) Projekte wo ein guter Debugger "lebensrettend" sein kann. Für mich kommen dann diesbezüglich hauptsächlich STM32 oder MSP430FR, Silabs 8051 von Betracht. Auch Zilog Encore! ist diesbezüglich nicht ganz uninteressant. Debugging bei PIC und AVR fand ich immer eine Krankheit und sind mit GDB nicht wirklich vergleichbar. Auch spielt "Erfahrungskapital" eine wichtige Rolle. Ein Entscheidungsfaktor ist z.B. auch, ob DMA für den speziellen Fall vorteilhaft oder notwendig sein könnte. Auch Anzeigeart spielt eine grosse Rolle. Da sind uC mit integriertem TFT Controller besonders vorteilhaft. Die Wahl eines uC ist also eine komplexe Angelegenheit und bedarf gründlicher Überlegung unter Berücksichtigung aller anwendungsspezifischen Details, Entwicklungswerkzeuge, Erfahrung, Vorhandensein von Ressourcen und Bibliotheken früherer Arbeiten, vorhandenes Programmiergerät Inventar. Im kommerziellem Bereich sind auch Verfügbarkeit und Langlebigkeit wichtige Faktoren. Was PICs betrifft, sind sie ein "Natural" in vielen Bereichen. Aber auch MSP430 sind wegen ihrer speziellen Eigenschaften im Vergleich zu PIC nicht uninteressant. Der grösste Killer kleinerer uC ist aber wahrscheinlich die Tendenz alles Kommerzielle mit dem Netz und der Cloud verbindbar bzw. abhängig machen zu wollen und die Notwendigkeit robuster Security. Wenn das nicht notwendig ist, erhöhen sich die uC Wahl-Möglichkeiten ungemein. Aus dieser Sicht ist dies wahrscheinlich der grösste "Threat Level" für kleine uC;-)
:
Bearbeitet durch User
Roland E. schrieb: > PICs. Die Laufen von 5..1,8V. Mit den benannten <1µA Stromverbrauch. Auch der Stromverbrauch der PICs steigt bei steigender Spannung. Er müsste antiproportional zur Spannung sinken, damit sich das Einsparen des Reglers energetisch lohnt.
Niklas G. schrieb: > Roland E. schrieb: >> PICs. Die Laufen von 5..1,8V. Mit den benannten <1µA Stromverbrauch. > > Auch der Stromverbrauch der PICs steigt bei steigender Spannung. Er > müsste antiproportional zur Spannung sinken, damit sich das Einsparen > des Reglers energetisch lohnt. Aber nicht in dem Maße, wie ein dedizierter Spannungsregler.
Angehängte Dateien:
Roland E. schrieb: > Aber nicht in dem Maße, wie ein dedizierter Spannungsregler. Doch. Faktor 9 dazwischen. Der Stromverbrauchs des PICs steigt mit der Spannung anscheinend so dramatisch, dass sich der Buck-Converter besonders lohnt - noch viel mehr als beim STM32U0, bei dem der Verbrauch nur leicht steigt.
:
Bearbeitet durch User
Roland E. schrieb: > Blaue und weiße LED leuchten üblicherweise nicht mit 3,3V... Ich hab' hier blaue und weiße LEDs, die mit einer CR2032 leuchten. Was machen die falsch?
Harald K. schrieb: > Roland E. schrieb: >> Blaue und weiße LED leuchten üblicherweise nicht mit 3,3V... > > Ich hab' hier blaue und weiße LEDs, die mit einer CR2032 leuchten. Was > machen die falsch? Die haben eine Ladungspumpe drin. Macht aber irgendwie keinen Sinn, wenn 12 oder 24V vorhanden sind. Niklas G. schrieb: > Roland E. schrieb: >> Aber nicht in dem Maße, wie ein dedizierter Spannungsregler. > > Doch. Faktor 9 dazwischen. Der Stromverbrauchs des PICs steigt mit der > Spannung anscheinend so dramatisch, dass sich der Buck-Converter > besonders lohnt - noch viel mehr als beim STM32U0, bei dem der > Verbrauch nur leicht steigt. Gut, Schaltregler für 5 auf 3,3 hatte ich jetzt noch nicht auf dem Schirm. Solange ich noch "Stangenweise" LDOs da habe, ist das auch kein Thema.
Roland E. schrieb: > Gut, Schaltregler für 5 auf 3,3 hatte ich jetzt noch nicht auf dem > Schirm. ... was denn sonst für Schaltregler?! Hatte auch eher an 1.8V gedacht. Roland E. schrieb: > Solange ich noch "Stangenweise" LDOs da habe, ist das auch kein Thema. Selbst damit wäre der Verbrauch bei den PICs dann niedriger, außer die LDOs haben einen hohen Eigenverbrauch...
Roland E. schrieb: > Die haben eine Ladungspumpe drin. Bitte was? Ich meine nackte LEDs, nicht irgendwelche Geräte, in denen LEDs eingebaut sind.
Harald K. schrieb: > Roland E. schrieb: >> Blaue und weiße LED leuchten üblicherweise nicht mit 3,3V... > > Ich hab' hier blaue und weiße LEDs, die mit einer CR2032 leuchten. Was > machen die falsch? Nix. Klar leuchten die bei frischen CR2032 ein wenig. Aber, nun halt dich fest: du hast in dem Aufbau optimale Voraussetzungen zur Messung der Flußspannung. Was mag da wohl herauskommen... Nachdem du das herausgefunden hast, darfst du dir die typische Kennlinie anschauen und extrapolieren, was wohl bei 3.3V für eine Helligkeit herauskommen mag...
Ob S. schrieb: > Harald K. schrieb: >> Roland E. schrieb: >>> Blaue und weiße LED leuchten üblicherweise nicht mit 3,3V... Sagt jemand, der es nie probiert hat. Hier funktionieren blaue 3mm mit 2k4 Vorwiderstand an einer LiIon bestens als Kontrollampe. >> Ich hab' hier blaue und weiße LEDs, die mit einer CR2032 leuchten. Was >> machen die falsch? > Nix. Klar leuchten die bei frischen CR2032 ein wenig. Die leuchten nur deshalb, weil der Innenwiderstand der CR2032 relativ hoch ist, an niederohmigen 3,3 Volt würde die LED direkt sterben. > Aber, nun halt dich fest: du hast in dem Aufbau optimale Voraussetzungen > zur Messung der Flußspannung. Was mag da wohl herauskommen... Was immer Du hier rumlallst, auch für Dich ist die LED das unbekannte Wesen.
Nick schrieb: > Dieses Jahr soll wohl der PIC64 auf den Markt kommen. Dann hat man auch > einen RISC-V core. Wobei dieser ein MPU und kein MCU ist. Zumindest für mich eine Liga, wo man mich nicht mal als Zuschauer reinlassen würde. https://www.microchip.com/en-us/products/microprocessors/64-bit-mpus/pic64gx
:
Bearbeitet durch User
Harald K. schrieb: > Kann es sein, daß hier im Thread Leute unterwegs sind, die jeden von > Microchip hergestellten µC pauschal als "PIC" bezeichnen? Das war ja aber jahrelang die Philosophie von Microchip, dass sie jede MCU "PIC" nennen (und am genannten "PIC64" sieht man, dass sie davon immer noch nicht völlig losgekommen sind). Insofern ist natürlich die Fragestellung des Threads völlig sinnlos, weil es eh nicht "den PIC" gibt. Niklas G. schrieb: > Der Stromverbrauchs des PICs steigt mit der Spannung anscheinend so > dramatisch, dass sich der Buck-Converter besonders lohnt Äpfel und Birnen. Wenn du etwas brauchst, was du mit minimalem Schlafstrom im Standby an einer einzelnen Lithium-Ionen-Zelle betreiben können möchtest, dann willst du keinen Spannungsregler in irgendeiner Form zwischen Zelle und MCU haben. Wenn du darauf schaust, mit welcher Leistungsaufnahme im aktiven Modus gerechnet werden muss, ist das 'ne völlig andere Nummer. Wenn du beides brauchst (und beides einen relevanten Anteil am Gesamt-Energieverbrauch des Systems hat), kann es sich gut und gern lohnen, zwei MCUs einzusetzen: eine möglichst kleine, die 5-V-tauglich ist, deren Sleep-Strom dann unterhalb der Selbstentladung der Zelle liegt, und eine zweite für die eigentliche Arbeit, die von der ersten eingeschaltet wird und mit einem Schaltregler versorgt wird. Es hat übrigens auch keinen Sinn, auf irgendwelche Nanoampere zu optimieren, wenn die Batterie eh das Äquivalent von 1 µA (oder mehr) als Selbstentladung hat. Wenn man wirklich Nanoampere braucht, dann hat man ganz schnell auch ganz andere Dinge als nur die MCU, auf die man achten muss, vor allem, wenn es nicht nur im warmen und trockenen Büro betrieben werden soll.
AVR® LA: https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ProductBrief/AVR-LA-Product-Brief-DS40002620.pdf Aber wozu?
Georg M. schrieb: > Aber wozu? Frag Microchip. Aber mit einem kannst du dir völlig sicher sein: dass sie keine Millionen-Investition in eine neue Produktreihe tätigen, ohne dass sie irgendwelche Kunden dahinter sehen.
Georg M. schrieb: > Aber wozu? Lies dir den Abschnitt "Security Concept" mal durch. Der erklärt wohl, warum man dafür extra eine eigene MCU-Familie vorgesehen hat.
Jörg W. schrieb: > Wenn du etwas brauchst, was du mit minimalem Schlafstrom im Standby an > einer einzelnen Lithium-Ionen-Zelle betreiben können möchtest, dann > willst du keinen Spannungsregler in irgendeiner Form zwischen Zelle und > MCU haben. Warum? Jörg W. schrieb: > Wenn du beides brauchst (und beides einen relevanten Anteil am > Gesamt-Energieverbrauch des Systems hat), kann es sich gut und gern > lohnen, zwei MCUs einzusetzen Und welche MCU hat einen geringeren Verbrauch bei 4.2V als eine moderne Low-Power-MCU bei 1.8V + Buck-Converter? Ich werde aus dem Datasheet der PICs nicht schlau, wie viel Strom die jetzt im Power-Down bei 5V verbrauchen. Bei aktiviertem WDT ist der Verbrauch sowieso höherer als bei z.B. einem STM32U0, gerade auch wenn der per Buck-Converter versorgt wird. Davon abgesehen dass beim ständigen Neustart RAM-Inhalte verloren gehen oder umständlich zwischen beiden MCUs übertragen werden müssen.
Niklas G. schrieb: > Und welche MCU hat einen geringeren Verbrauch bei 4.2V als eine moderne > Low-Power-MCU bei 1.8V + Buck-Converter? Wieviel verbraucht dein Buck-Converter denn für sich allein?
Jörg W. schrieb: > Wieviel verbraucht dein Buck-Converter denn für sich allein? Der TPS62840 aus meiner Beispielrechnung hat einen Quiescent-Current von 65nA.
Niklas G. schrieb: > Der TPS62840 aus meiner Beispielrechnung hat einen Quiescent-Current von > 65nA. Wenn sie auch bei geringer Last realistisch so weit runter kommen, ist das schon 'ne Nummer – aber eine Beispielrechnung sehe ich nicht von dir (habe den Thread jetzt mal durchsucht). Bei den neueren AVRs gibt es leider nicht bei allen die Diagramme für typische Werte. Bei denen, bei denen es sie gibt, ist der Stromverbrauch aber oberhalb von 2 V nahezu unabhängig von der Spannung. Da "PIC" nur ein Sammelbegriff für alles Mögliche ist, habe ich mir jetzt nicht die Mühe gemacht, dort nachzuschauen.
Jörg W. schrieb: > aber eine Beispielrechnung sehe ich nicht von dir Hier: Niklas G. schrieb: > Der Stromverbrauchs des PICs steigt mit der > Spannung anscheinend so dramatisch, dass sich der Buck-Converter > besonders lohnt - noch viel mehr als beim STM32U0, bei dem der > Verbrauch nur leicht steigt. Jörg W. schrieb: > Bei denen, bei denen es sie gibt, ist der Stromverbrauch > aber oberhalb von 2 V nahezu unabhängig von der Spannung. Bei welchem Exemplar kann man das konkret nachschauen?
Niklas G. schrieb: > Jörg W. schrieb: >> Bei denen, bei denen es sie gibt, ist der Stromverbrauch >> aber oberhalb von 2 V nahezu unabhängig von der Spannung. > > Bei welchem Exemplar kann man das konkret nachschauen? Hier beispielsweise: https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/AVR64DD32-28-Complete-DataSheet-DS40002315.pdf
Hab's auch bei ein oder zwei anderen gesehen, scheint für all diese neueren AVRs zu gelten, die bereits zu Microchip-Zeiten entworfen worden sind. Offenbar laufen die auf anderen Prozessen / in anderen Fabs als die, die aus Atmel-Zeiten stammen. Bei denen stieg der Verbrauch auch halbwegs linear mit der Spannung.
Jörg W. schrieb: > Hier beispielsweise: Interessant, vermutlich ist auch da einfach ein LDO drin sodass der Core immer mit der gleichen, niedrigen Spannung läuft. Aber dennoch ist der Verbrauch absolut gesehen nicht so niedrig, dass der AVR hier einen Vorteil gegenüber 32bitter + Buck hätte.
Niklas G. schrieb: > Da ja die großen Tech-Firmen signifikante Anteile ihres Codes nur noch > per LLM erzeugen hast Du da irgendwelche Quellen? Jeder HInterhoffrickler schreibt sich inzwischen KI/AI auf die Fahnen. Ist (immer noch) "cool", und ein Entwickler, der keine KI-Codegeneratoren nutzt, ist sowas von Steinzeit. Man ist also quasi gezwungen, die Firmenwebsite mit dem Thema KI vollzuballern. Inzwischen habe ich auch das Gefühl, dass ich die falschen KIs für's coden verwende. Jedenfalls kommt da selten etwas compilierbares oder funktionierendes raus. Da scheinen alle anderen ja in anderen KI-Welten zu leben, denn bei denen scheinen ja wenige Prompts zu reichen, um auch komplexe Systeme coden zu lassen. Nur gut, dass das die Kunden noch nicht geschnallt haben, sonst würden wohl die Auftragsvolumina drastisch reduziert. Wer will schon so viel zahlen wie in "Vor-KI-Zeiten"?! Wenn dann dadurch echter Kostendruck entsteht, wird sich zeigen, wie viel die Firmen tatsächlich von der KI erledigen lassen und wie gut das funktioniert. ;-) Oder die bisherigen Kunden lassen sich ihre Systeme gleich selbst von einer KI basteln... :-) ciao Marci
Marci W. schrieb: > hast Du da irgendwelche Quellen? https://www.cnbc.com/2025/04/29/satya-nadella-says-as-much-as-30percent-of-microsoft-code-is-written-by-ai.html Halbwegs relevant: https://www.golem.de/news/programmieren-fast-niemand-stellt-mehr-fragen-auf-stack-overflow-2601-203788.html Ein Bekannter von mir der in einem kleinen Startup arbeitet nutzt ebenfalls intensiv LLMs zum codieren. Marci W. schrieb: > Inzwischen habe ich auch das Gefühl, dass ich die falschen KIs für's > coden verwende. Claude Code ist da wohl recht beliebt. Ich kriege es auch noch nicht so recht hin dass es auch Zeit spart. Es ist wohl eine Lernkurve. Sehr wichtig ist glaube ich eine Datei mit allgemeinen Anweisungen zum Code-Style, zu den üblichen Mustern in denen man arbeitet, und wie der Agent den Code kompilieren kann damit er seine Fehler findet. Eigentlich braucht man auch bessere Simulatoren und HIL-Setups damit der Agent es auch "live" testen kann. Man muss auch umdenken - statt sich Schritt für Schritt an die Lösung heranzutasten, muss man diese erst vollständig skizzieren und in Anweisungen für den Prompt umwandeln, damit der Agent "alles in einem" erstellen kann. Eigentlich ist das ja sowieso das saubere Vorgehen aus dem Lehrbuch. Btw, ARM Assembler schreiben kann selbst ChatGPT schon lange recht gut...
Niklas G. schrieb: > Jörg W. schrieb: >> Wieviel verbraucht dein Buck-Converter denn für sich allein? > > Der TPS62840 aus meiner Beispielrechnung hat einen Quiescent-Current von > 65nA. Das ist nicht der Eigenverbrauch im Betrieb. No load operating input current sind 80nA. Wobei das wohl nur die halbe Wahrheit ist, denn in dem Modus gehen 36..100nA in Vin und 56..120nA in Vos. Dazu kommen dann noch die Schaltverluste. Die können bis 360nA hoch laufen. Für das Beispiel von 5 auf 3,3V bei etwa 1mA für den PIC liegt der Regler bei optimistischen 85%. Macht einen Eigenverbrauch von 150nA. Mache ich das um auf 1,8V zu kommen, verheizt er 500nA.
Niklas G. schrieb: > Eigentlich ist das ja sowieso das saubere Vorgehen aus dem Lehrbuch. Die Praxis ist allerdings häufig agil, im Sinne von: Fange schon mal an, die Details klären wir später während der Entwicklung oder Tests.
Roland E. schrieb: > Mache ich das um auf 1,8V zu kommen, verheizt er 500nA. Also sehr wenig im Vergleich zu den ca 300uA die man durch Verwendung des SMPS spart. Nemopuk schrieb: > Die Praxis ist allerdings häufig agil Ja, aber meistens auf höherer Ebene. Wenn der initiale Plan sagt, einen Temperatursensor per I2C anzusteuern, sollte man sich schon recht vollständig überlegen, wie der Treiber dazu funktionieren muss. Wenn man sich dann agil für einen analogen Sensor umentscheidet, muss man einen neuen Treiber schreiben (lassen), aber für die Gesamtarchitektur ist das nicht so relevant.
Niklas G. schrieb: > Btw, ARM Assembler schreiben kann selbst ChatGPT schon lange recht > gut... Da möchte ich mal lang, laut und herzhaft lachen. Genau so etwas hatten wir spaßeshalber mal mit einfachen, mehrfach geschachtelten Subroutine calls versucht. Das olle Ding war weder in der Lage etwas halbwegs Gescheites zu fabrizieren, noch konnte es cortex-M0 von M33 unterscheiden. Bei Thumb(2) gab's dann die endgültige Blutgrätsche. Also … ähm … Nein!
Norbert schrieb: > Da möchte ich mal lang, laut und herzhaft lachen Dann hab ich wohl Glück gehabt 🤷♂️ Norbert schrieb: > Thumb(2) gab's dann die endgültige Blutgrätsche Die Probleme, die der Assembler mit Fehlermeldung quittiert, kann es selbst automatisch beheben. Bei VS Code mit Copilot ist das schon so schick dass der Agent direkt Zugriff auf die Fehler hat, die die IDE selbst schon findet, bevor der Compiler überhaupt gestartet wird. Die behebt er dann direkt selbst. Bei Assembler geht's aber noch nicht
Niklas G. schrieb: > Roland E. schrieb: >> Mache ich das um auf 1,8V zu kommen, verheizt er 500nA. > > Also sehr wenig im Vergleich zu den ca 300uA die man durch Verwendung > des SMPS spart. Mich hätte jetzt trotzdem eher eine praktische Messung interessiert für ein reales Szenario als ein theoretischer, aus den Datenblattangaben "gezauberter" Wert. Aber: auf jeden Fall ein Argument, derartige Regler im Blick zu behalten. Danke dafür!
Jörg W. schrieb: > Mich hätte jetzt trotzdem eher eine praktische Messung interessiert Leider ist eine nachvollziehbare Messung nicht so ganz einfach zu bewerkstelligen, es gibt nicht viele gute Eval-Boards für Low-Power-Spielereien. Die Hersteller können der Versuchung nicht widerstehen, jedes Power-Rail mit LEDs (natürlich 0402) vollzupflastern. Zudem braucht es da ein gutes Multimeter. Jörg W. schrieb: > Aber: auf jeden Fall ein Argument, derartige Regler im Blick zu > behalten. Danke dafür! Gern 👌 Kann mir auch kaum vorstellen dass die hochmodernen BLE/Funk-Chipsets in AirTags, LoRaWAN-, ZigBee-, NB-IoT- o.ä. -Nodes und sonstigen IoT-Dingen die nur einen Hauch von Energie brauchen 5V-Logik verwenden. Selbst Desktop-CPUs werden ja "undervolted" (Dynamic voltage scaling), die STM32 machen das intern auch schon über die "V_CORE range" (aber per LDO). Der Spannungstrend geht nach unten... PS: Ganz vergessen, manche Mikrocontroller, auch STM32, haben ja sogar integrierte Buck-Converter. Damit kann man dann, mit nur einer externen Induktivität, die Versorgungsspannung runter schrauben. Der Use-Case ist aber etwas anders; da geht's wohl um den Betrieb unter höherer Rechenlast.
:
Bearbeitet durch User
Niklas G. schrieb: > Jörg W. schrieb: >> Mich hätte jetzt trotzdem eher eine praktische Messung interessiert > > Leider ist eine nachvollziehbare Messung nicht so ganz einfach zu > bewerkstelligen, es gibt nicht viele gute Eval-Boards für > Low-Power-Spielereien. Die Hersteller können der Versuchung nicht > widerstehen, jedes Power-Rail mit LEDs (natürlich 0402) vollzupflastern. > Zudem braucht es da ein gutes Multimeter. Heißluftpistole und ablöten. :-) Meine eigene Erfahrung: alles unter 1 µA wird dann immer anstrengender zu demonstrieren. Meine Funk-Temperatur-Sensoren halten jedenfalls viele Jahre mit einem Batteriesatz, sofern es nicht aus Versehen doch drauf regnet. :) > Gern 👌 Kann mir auch kaum vorstellen dass die hochmodernen > BLE/Funk-Chipsets in AirTags, LoRaWAN-, ZigBee-, NB-IoT- o.ä. -Nodes und > sonstigen IoT-Dingen die nur einen Hauch von Energie brauchen 5V-Logik > verwenden. Nö, aber die kommen oft einfach mit 3 V aus (wie mein ATmega128RFA1 auch). Da gibt's keinen Grund für LiPo. > PS: Ganz vergessen, manche Mikrocontroller, auch STM32, haben ja sogar > integrierte Buck-Converter. Zumindest die, die ich davon gesehen habe, kannst du aber nicht sinnvoll für low-power-Anwendungen benutzen, die überwiegend nur im Sleep sind.
Jörg W. schrieb: > Heißluftpistole und ablöten. :-) Versuch ich vielleicht mal bei Gelegenheit. Jörg W. schrieb: > Meine eigene Erfahrung: alles unter 1 µA wird dann immer anstrengender > zu demonstrieren. Ja, da machen sich sogar Reste vom Flussmittel bemerkbar. Jörg W. schrieb: > Nö, aber die kommen oft einfach mit 3 V aus (wie mein ATmega128RFA1 > auch). Da gibt's keinen Grund für LiPo. Und wenn es aufladbar sein soll? Jörg W. schrieb: > Zumindest die, die ich davon gesehen habe, kannst du aber nicht sinnvoll > für low-power-Anwendungen benutzen, die überwiegend nur im Sleep sind. Ja, dieser integrierte SMPS wird sowieso nur im aktiven Modus aktiviert um den CPU-Kern, der bei ca 1.2V läuft, effizient aus bis zu 3.6V zu versorgen. Es wird wohl davon ausgegangen dass bei Nutzung von LiPos noch ein externer SMPS das Gesamtsystem versorgt.
Niklas G. schrieb: > Jörg W. schrieb: >> Nö, aber die kommen oft einfach mit 3 V aus (wie mein ATmega128RFA1 >> auch). Da gibt's keinen Grund für LiPo. > > Und wenn es aufladbar sein soll? Wenn das Gesamtsystem sehr energiesparsam ist, lohnen sich Akkus irgendwann nicht mehr. So ein Apple Airtag hat halt eine CR2032 drin, und die vielen ZigBee-Teile sicher ähnlich. Bei meinen Sensoren sind es 2 x LR03, die viele Jahre halten.
Jörg W. schrieb: > Wenn das Gesamtsystem sehr energiesparsam ist, lohnen sich Akkus > irgendwann nicht mehr. So kann man es auch sehen... Dann müsste man aber sagen: - Extrem niedriger Verbrauch -> Versorgung aus Primärzelle, kann modernen Controller (z.B. STM32) direkt anschließen - Höherer Verbrauch -> Versorgung aus LiPo-Akku, kann modernen Controller + SMPS nehmen, Quiescent-Current auch nicht mehr so relevant - Oder sogar Lithiumtitanat-Akkus, deren Spannungsbereich von 1.8V-2.8V ist quasi perfekt für einen modernen Controller Dann ist das Argument für extrem sparsame 5V-Controller auch nicht mehr so stark...
:
Bearbeitet durch User
Jörg W. schrieb: > So ein Apple Airtag hat halt eine CR2032 drin, > und die vielen ZigBee-Teile sicher ähnlich. Tatsächlich hat Ikea, die viele Jahre lang Zigbee-Technik verkauft haben, zumindest deren Zigbee-Fernbedienungen auf AAA-Zellen umgestellt ("STYRBAR" mit zweien, "RODRET" mit nur einer), und das funktioniert auch mit den hauseigenen NiMh-Akkus. Die CR2032 ist damit weitestgehend/vollständig(?) aus deren Programm verschwunden. Derzeit wird das Zigbee-Programm (Tradfri etc.) ausgelistet und durch "Matter" ersetzt. Dazu gehört beispielsweise der Fensterkontakt "MYGGBETT" - und der arbeitet auch mit einer AAA-Zelle. https://www.ikea.com/de/de/p/myggbett-tuer-fenstersensor-smart-00603864/ Auch der Feuchtigkeits-/Temperatursensor "TIMMERFLOTTE" arbeitet mit AAA-Zellen, allerdings zwei davon, was aber wohl auch am verbauten Display liegen dürfte. https://www.ikea.com/de/de/p/timmerflotte-temperatur-feuchtigkeitssensor-smart-30597606/ Mit diesen neueren Dingen habe ich keine eigenen Erfahrungswerte, aber die "RODRET"-Fernbedienungen funktionieren bei mir problemlos; die Akkus darin hab' ich definitiv vor deutlich mehr als einem Jahr das letzte Mal geladen.
Harald K. schrieb: > aber > die "RODRET"-Fernbedienungen funktionieren bei mir problemlos; die Akkus > darin hab' ich definitiv vor deutlich mehr als einem Jahr das letzte Mal > geladen. Na ja, da hält bei mir jede TV-Fernbedienung deutlich länger durch. Was dann drauf hinweist, daß Fernbedienungen nicht das Thema dieses Threads sind. Oliver
Oliver S. schrieb: > Was dann drauf hinweist, daß Fernbedienungen nicht das Thema dieses > Threads sind. Zumindest, falls sie nicht gerade einen der vielen PICs drin haben sollten. :-)
Norbert schrieb: > Niklas G. schrieb: >> Btw, ARM Assembler schreiben kann selbst ChatGPT schon lange recht >> gut... > > Da möchte ich mal lang, laut und herzhaft lachen. > Genau so etwas hatten wir spaßeshalber mal mit einfachen, mehrfach > geschachtelten Subroutine calls versucht. Das olle Ding war weder in der > Lage etwas halbwegs Gescheites zu fabrizieren, noch konnte es cortex-M0 > von M33 unterscheiden. Bei Thumb(2) gab's dann die endgültige > Blutgrätsche. > Also … ähm … Nein! Habt Ihr ihn dann auf die Fehler aufmerksam gemacht? Ich kenne das insbesondere von Python, wo es ab und zu Befehle aus alten Libs benutzt. Dann gibt man ihm die Fehlermeldung und es weiß dann, was das Problem ist und korrigiert das entsprechend. Wichtig ist halt auch immer, dass es genug Beispiele dafür zum Lernen im Netz gab. Wenn man z.B. Farbraumkonvertierung für ARM Neon braucht, dann kommt da was sinnvolles raus, weil das eine Standardaufgabe ist und es Neon schon lange gibt. Möchte man das aber mit Arm Helium machen, dann kommt Unsinn raus, weil es Mikrocontroller mit Helium halt erst seit kurzem gibt.
Oliver S. schrieb: > Na ja, da hält bei mir jede TV-Fernbedienung deutlich länger durch. Und, machen die Zigbee? Sei's drum: Ikea traut sich, auch den nicht nur bei Handbedienung sendenden Kram mit Akkus zu betreiben, wie die beiden von mir verlinkten Sensoren (Fenster/Türkontakt und Temperatur/Luftfeuchte).
Jörg W. schrieb: > Zumindest, falls sie nicht gerade einen der vielen PICs drin haben > sollten. :-) Das wäre interessant zu wissen. Los, wer hat eine? Aufmachen und Chip posten! :D Markus K. schrieb: > Dann gibt man ihm die Fehlermeldung und es weiß dann, was > das Problem ist und korrigiert das entsprechend. Das widerspricht meiner Erfahrung. Wie gesagt, Beispiel Arduino/Nano, also "alt" und ausreichend bekannt. Register soundso, föllig valsch. Meine Antwort "ich glaube, das der Timer x mit Register x bedient wird" wird mit "oh ja du hast völlig recht, ich korrigiere den Code mal eben" beantwortet und raus kommt exakt identischer Text. Selbst wenn ich die Register und Bitnamen selber eintrage und frage was das macht kommt die falsche Antwort. Da wird halt nicht verstanden sondern irgendein Dreckfehler nachgeplappert, und wenn man dann den GPT drauf hinweist das der Pilz doch giftig war labert er einem nach dem Maul. Im Grunde kann man da nur ein "intelligentes" Copy&Paste rausziehen. Nachlesen und korrigieren muss man doch selber. Harald K. schrieb: > Ikea traut sich, auch den nicht nur bei Handbedienung > sendenden Kram mit Akkus zu betreiben Ikea will sich nicht mit langem Support aufhalten und liefert Apple-Qualität: es kann genau das was es soll, und das sehr gut. Nicht mehr, aber auch nicht weniger. Leider führt das auch wieder zu lustigen Verdingsern, weil die Jungs da keine Techniker sind. Dirigera z.B. (der Matter-Hub) "kann WLAN und wird mit Kabel an den Router angeschlossen", damit er als Zentrale alle neuen Matter-Geräte steuern kann. Wie viel Cloud und Account dagegen da drin ist sieht man erst wenn man's gekauft hat.
:
Bearbeitet durch User
Noch ein Beispiel für einen akkubetriebenen Sensor: https://www.ikea.com/de/de/p/myggspray-funk-bewegungsmelder-smart-70604186/ Zwei AAA-Zellen Jens M. schrieb: > Leider führt das auch wieder zu lustigen Verdingsern, weil die Jungs da > keine Techniker sind. Was magst Du meinen? Was ist an der von Dir zitierten Formulierung ein "Verdingser"? > Wie viel Cloud und Account dagegen da drin ist sieht man erst > wenn man's gekauft hat. Zu "Dirigera" schreibt Ikea: > Mit der IKEA Home smart App kannst du auch unterwegs ein Auge > auf dein Zuhause halten, zum Beispiel um zu überprüfen, ob du > die Kaffeemaschine ausgeschaltet hast oder ob das Licht noch an ist. Daß das mit sehr hoher Wahrscheinlichkeit über irgendeine Cloud läuft, ist naheliegend, auch wenn das da nicht explizit erwähnt wird. Liefe es nicht über eine Cloud, müsste der jeweilige heimische Internetzugang die Möglichkeit bieten, über etwas à la DynDNS angesprochen werden zu können - mit der Zunahme von CGNAT aber ist das immer seltener möglich. Das wiederum einem Publikum technischer Laien zu erläutern, geht über das hinaus, was ein Anbieter wie Ikea leisten kann. Ein paar Details bzw. Versprechungen finden sich dann bei der Beschreibung der zugehörigen "App": https://play.google.com/store/apps/details?id=com.ikea.inter.homesmart.system2&hl=de https://apps.apple.com/de/app/ikea-home-smart/id1633226273 So, zurück zum Thema. Ich hab' den Ikea-Kram ja nur erwähnt, um darauf hinzuweisen, daß es auch offenkundig ernstgemeinte Alternativen zur CR2032 gibt, nämlich simple NiMh-Akkus in AAA-Bauform.
Harald K. schrieb: > Alternativen zur CR2032 gibt, nämlich simple NiMh-Akkus in AAA-Bauform Sind halt deutlich größer. Dafür können sie Stromimpulse besser ab.
Markus K. schrieb: > Habt Ihr ihn dann auf die Fehler aufmerksam gemacht? Reichlich. Mit Engelszungen. Meistens wurde das mit: ›Ja das stimmt‹ oder ›Ja da hast du recht‹ beantwortet, nur um ein oder zwei Iterationen später die gleichen Fehler zu wiederholen. Oftmals hat man nach einem Dutzend Versuchen einen 360° Vollkreis hingelegt (180° Vollkreis für Politikerinnen*innen). > Ich kenne das insbesondere von Python, wo es ab und zu Befehle aus alten > Libs benutzt. Dann gibt man ihm die Fehlermeldung und es weiß dann, was > das Problem ist und korrigiert das entsprechend. Das Problem ist, dass die Dinger nicht intelligent sind. Es sind extrem belesene Labersäcke bei völliger Abwesenheit eines wirklich fundamentalen Verständnisses. Die lernen nicht, die verstehen nicht, die wissen nicht, die suchen was im Moment am besten passt. Klar, bei Python ist die Trefferquote doch einmal etwas richtiges widerzukäuen deutlich höher. Oder bei Arduino Blinkbeispielen. Als Suchknecht isses sicher ausreichend, teils sogar einigermaßen praktisch. Da findet man die passenden Stellen in der Dokumentation bequem und kann dann selbst zielorientiert denken. Das gestehe ich zu. (Beim finden von simpelsten Code-Snippets auch) Aber sobald spezielle Dinge ins Spiel kommen, ist schneller Ende mit ›Intelligenz‹ als man die Enter Taste drücken kann. Da ist dann bestenfalls noch herum stochern im Nebel angesagt.
Norbert schrieb: > Markus K. schrieb: >> Habt Ihr ihn dann auf die Fehler aufmerksam gemacht? > > Reichlich. Mit Engelszungen. Meistens wurde das mit: ›Ja das stimmt‹ > oder ›Ja da hast du recht‹ beantwortet, nur um ein oder zwei Iterationen > später die gleichen Fehler zu wiederholen. Oftmals hat man nach einem > Dutzend Versuchen einen 360° Vollkreis hingelegt (180° Vollkreis für > Politikerinnen*innen). Wenn sich die Diskussion nach einiger Zeit im Kreis dreht, dann kann es gut sein, dass man die Kontextlänge überschritten hat, d.h. es hat den Anfang der Diskussion vergessen. Da hilft es dann manchmal, das aktuelle Programm in einen neuen Chat zu kopieren und die Punkte, die man herausgearbeitet hat, nochmal direkt zu nennen. >> Ich kenne das insbesondere von Python, wo es ab und zu Befehle aus alten >> Libs benutzt. Dann gibt man ihm die Fehlermeldung und es weiß dann, was >> das Problem ist und korrigiert das entsprechend. > > Das Problem ist, dass die Dinger nicht intelligent sind. Es sind extrem > belesene Labersäcke bei völliger Abwesenheit eines wirklich > fundamentalen Verständnisses. Die lernen nicht, die verstehen nicht, die > wissen nicht, die suchen was im Moment am besten passt. Diese Beschreibung ist viel zu stark vereinfacht. Zum einen lernen die Netze sehr wohl, zum anderen ist auch beim Menschen sehr viel nur auswendig gelernt. Wer das Ohmsche Gesetz zwar anwenden, aber nicht herleiten kann, der hat es doch wohl auswendig gelernt? Anwenden kann die KI das auch. Mein Verdacht ist, dass das Training der KIs nicht gut genug ist. Kinder werden gerade am Anfang solange korrigiert, bis sie etwas richtig machen. Die LLMs werden erst hinterher (nachdem sie das Internet gelesen haben) korrigiert. Überhaupt hat das erst den Durchbruch gebracht. Es gab ja auch schon vor ChatGPT 3.5 LLMs, aber die waren sehr schlecht. Der Durchbruch kam, als man angefangen hat, Antworten von Menschen korrigieren zu lassen und das ins Training einfloss. > Klar, bei Python ist die Trefferquote doch einmal etwas richtiges > widerzukäuen deutlich höher. Oder bei Arduino Blinkbeispielen. Als > Suchknecht isses sicher ausreichend, teils sogar einigermaßen praktisch. > Da findet man die passenden Stellen in der Dokumentation bequem und kann > dann selbst zielorientiert denken. Das gestehe ich zu. (Beim finden von > simpelsten Code-Snippets auch) Ich habe es öfters mal, dass ich ein kleines Pythonprogramm brauche und da kommen dann aus der KI 300 Zeilen Python raus und die können durchaus beim ersten Versuch korrekt sein. Für 300 Zeilen Code bräuchte ich locker einen halben Tag und wahrscheinlich sind die auch nicht sofort korrekt. > Aber sobald spezielle Dinge ins Spiel kommen, ist schneller Ende mit > ›Intelligenz‹ als man die Enter Taste drücken kann. Da ist dann > bestenfalls noch herum stochern im Nebel angesagt. Es ist halt ein Werkzeug, mit seinen Stärken und Schwächen. Die Hauptkritik an den ganzen KIs ist doch eigentlich, dass sie nicht in der Lage sind, alle unsere Jobs bereits heute zu übernehmen.
Harald K. schrieb: > Was ist an der von Dir zitierten Formulierung ein > "Verdingser"? Das Dirigera mit WLAN tut aber an ein Kabel muss. Harald K. schrieb: > Daß das mit sehr hoher Wahrscheinlichkeit über irgendeine Cloud läuft, > ist naheliegend, auch wenn das da nicht explizit erwähnt wird. Tuya so wie alle anderen auch? Oder Ikea, mit Datenschutz nach EU oder gar Germany-Art? Harald K. schrieb: > Ich hab' den Ikea-Kram ja nur erwähnt, um darauf hinzuweisen, daß es > auch offenkundig ernstgemeinte Alternativen zur CR2032 gibt, nämlich > simple NiMh-Akkus in AAA-Bauform. Und dazu: die Geräte sind billig, langlebig (also von der Batterie her) und leistungsfähig. Erstaunlich was geht wenn da einer hinter steht der das auch will. Markus K. schrieb: > Für 300 Zeilen Code bräuchte ich > locker einen halben Tag und wahrscheinlich sind die auch nicht sofort > korrekt. Aktuelle c't hat diverse Aussagen zur KI-Malware-Diskussion geprüft. Grundsatz war: ja, da kommt irgendwas, aber selbst da läuft es nicht, aus verschiedensten Gründen. KI ist Chat, nette (?) Unterhaltung, mehr nicht. Im übrigen auch bei der Armee, selbst da viel großspuriges Bullshitbingo von den Zulieferern, aber nix was auch nur als Demo liefe. Zum Glück. Und: da liegt es nicht am Geld. Markus K. schrieb: > Die Hauptkritik an den ganzen KIs ist doch eigentlich, dass sie nicht in > der Lage sind, alle unsere Jobs bereits heute zu übernehmen. Das wäre eine Katastrophe, und damit meine ich nicht das Leute ihren Job verlieren.
Markus K. schrieb: > Ich habe es öfters mal, dass ich ein kleines Pythonprogramm brauche und > da kommen dann aus der KI 300 Zeilen Python raus und die können durchaus > beim ersten Versuch korrekt sein. Jup, auch gerade wieder genau so hinbekommen. Einen Absatz an Anweisungen, es generiert ein Programm, führt es aus, findet Fehler, korrigiert sie, wiederholt dies 3x, fertig. Ergebnis funktioniert perfekt, keine manuelle Intervention zwischendurch nötig, nur die testweise Ausführung des Scripts genehmigen.
Jens M. schrieb: > Markus K. schrieb: >> Für 300 Zeilen Code bräuchte ich >> locker einen halben Tag und wahrscheinlich sind die auch nicht sofort >> korrekt. > > Aktuelle c't hat diverse Aussagen zur KI-Malware-Diskussion geprüft. > Grundsatz war: ja, da kommt irgendwas, aber selbst da läuft es nicht, > aus verschiedensten Gründen. Ich behaupte mal, der durchschnittliche menschliche Entwickler kann auch keine Malware schreiben. Die Frage ist also, ob die KI besser als ein durchschnittlicher Entwickler ist. Nein, ist sie nicht. > KI ist Chat, nette (?) Unterhaltung, mehr nicht. Im übrigen auch bei der > Armee, selbst da viel großspuriges Bullshitbingo von den Zulieferern, > aber nix was auch nur als Demo liefe. Zum Glück. Und: da liegt es nicht > am Geld. Die KI kann noch nicht völlig selbständig große Projekte umsetzen. Kleine Sachen, insbesondere wenn man bei 0 anfängt, gehen oft schon ganz gut. Hängt eben vom Projekt und vom Thema ab.
Angehängte Dateien:
-
Intakt_Start_1.png
57 KB -
Intakt_Start_2.png
36 KB -
Intakt_Start_3.png
55 KB -
Intakt_Switching_1.png
38 KB -
Intakt_Switching_2.png
42 KB -
Kaputt_Start.png
36 KB -
Kaputt_Switching.png
47 KB
Jörg W. schrieb: > Heißluftpistole und ablöten. :-) Hab's jetzt mal versucht, es ist ein Fall von "interessant Scheitern": Ich habe 2x STM32U083C-DK Boards hier, ein altes etwas verbasteltes Exemplar und ein Neues. Da ist ein ST1PS03 Buck-Converter drauf, nicht so toll wie der TPS62840 aber für eine kleine Demo vielleicht ausreichend. Mit einer sparsamen Software auf der MCU sollte man dann auf der Eingangsseite vom Converter einen "schön niedrigen" Strom auf 5V messen können, sofern man sonstige unnötige Verbraucher abgeklemmt bekommt: Ich wollte daher das alte Board so tunen dass nur die MCU über den Buck-Converter versorgt wird, und ich den Converter einzeln speisen kann ohne dass noch Strom woanders hin geht. Daher habe ich - R42 ausgelötet sodass die LED LD6 inaktiv ist - SB2 ausgelötet sodass ich den Buck-Converter über das "5V_LP" Rail von JP3 einzeln versorgen kann ohne dass noch Strom ins "5V" Rail verloren geht - JP6 und JP7 gezogen - Den Trace von VDD zu U20+U21 aufgekratzt - R28 ausgelötet Dadurch sollte keinerlei Last mehr am Buck-Converter hängen (MCU per JP7 abgekoppelt) und sich dieser im Leerlauf befinden. Dennoch zieht er aber ca. 10mA aus seinem Input ("5V_LP"), aber erst ca. 3-11 Sekunden nach Anlegen der Spannung. Ich bin ziemlich sicher dass der Strom am Converter selbst "verschwindet"; ich habe mit einem µV-Meter den Spannungsabfall an den Traces des VDD-Rails gemessen und dieser ist praktisch 0. Bevor ich R28 ausgelötet hatte konnte ich auf diese Art über den Spannungsabfall eindeutig den dadurch fließenden kleinen Strom (300µA) nachweisen, aber ohne R28 ist nirgendwo mehr ein Spannungsabfall auffindbar, der ja bei 10mA noch deutlich höher sein müsste. Am SW-Pin des Converters ist zu sehen dass er plötzlich anfängt "wild" zu switchen, also klassischer PWM-Modus. Fragt sich jedoch, warum! Wo geht die Energie hin? Müsste die Spannung nicht mindestens bis auf 5V steigen wenn ein Buck-Converter ohne Last ständig schaltet? Zum Vergleich beim neuen Board: Dort fließen 7mA in das 5V/5V_LP-Rail, allerdings inklusive der LED LD6 und noch ein paar anderen Sachen auf "5V". Das Board kann ich aber derzeit nicht verbasteln, das soll "frisch" bleiben. Obwohl eine kleine Last am Regler ist (R28, U20+U21) schaltet dieser viel seltener (Powersave-Modus) - immer wenn die Spannung zu weit runter gesunken ist. Ist der Regler auf dem ersten Board einfach kaputt (ESD?) oder mach ich noch was anderes falsch? Defekte passive Komponenten (C26?) müssten sich ja eigentlich sofort bemerkbar machen, nicht erst nach ein paar Sekunden nach Start des Reglers?
Niklas G. schrieb: > Hab's jetzt mal versucht, es ist ein Fall von "interessant Scheitern": Danke trotzdem! Zeigt wie immer, dass der Teufel schnell im Detail steckt …
Jörg W. schrieb: > Zeigt wie immer, dass der Teufel schnell im Detail > steckt … https://www.detail.de/ ;-)
Mikrocontroller sind sehr unterschiedlich. Der eine hat dies, der andere hat das. Z.B. MSPM0G150 von Texas: • Core – Arm® 32-bit Cortex®-M0+ CPU with memory protection unit, frequency up to 80MHz • Wide supply voltage range: 1.62V to 3.6V • Up to 128KB of flash memory with error correction code (ECC), Up to 32KB of SRAM with hardware parity • Two simultaneous sampling 12-bit 4Msps analog-to-digital converters (ADCs) with up to 17 external channels • 14-bit effective resolution at 250ksps with hardware averaging • One 12-bit 1Msps digital-to-analog converter with integrated output buffer (DAC) • Two zero-drift zero-crossover chopper op-amps (OPA) – 0.5µV/°C drift with chopping – Integrated programmable gain stage, up to 32x • One general-purpose amplifier (GPAMP) • Three high-speed comparators (COMP) with 8 bit reference DACs – 32ns propagation delay in high-speed mode – Support low-power mode operation down to 1µA • Programmable analog connections between ADC, OPAs, GPAMP, COMP and DAC • Configurable 1.4V or 2.5V internal shared voltage reference (VREF) • Integrated temperature sensor • Optimized low-power modes – RUN: 101µA/MHz (CoreMark) – SLEEP: 40µA/MHz – STOP: 190µA at 4MHz – STANDBY: 1.5µA with 32KHz LFXT, RTC with SRAM, CPU state, and registers retained – SHUTDOWN: 80nA with IO retained and IO wake-up capability • 7-channel DMA controller • Math accelerator supports DIV, SQRT, MAC and TRIG computations • Seven timers supporting up to 22 PWM channels • One 16-bit general-purpose timer supports QEI • Two 16-bit general-purpose timers support low-power operation in STANDBY mode • One 32-bit general-purpose timer • Two 16-bit advanced timers with deadband support and complementary outputs up to 12 PWM channels • Two window-watchdog timers (WWDT) • RTC with alarm and calendar mode • Four UART interfaces – One supports LIN, IrDA, DALI, Smart Card, Manchester – Three support low-power operation in STANDBY mode • Two I²C interfaces supporting FM+ (1Mbit/s), SMBus/PMBus, and wakeup from STOP mode • Two SPIs, one SPI supports up to 32Mbits/s • Internal 4MHz to 32MHz oscillator (SYSOSC) with up to ±1.2% accuracy (SYSOSC) • Phase-locked loop (PLL) up to 80MHz • Internal 32kHz low-frequency oscillator (LFOSC) with ±3% accuracy • External 4MHz to 48MHz crystal oscillator (HFXT) • External 32kHz crystal oscillator(LFXT) • External clock input • Cyclic redundancy checker (CRC-16, CRC-32) • True random number generator (TRNG) • AES encryption with 128-bit or 256-bit key • Flexible I/O features • Two 5V-tolerant open drain IOs • Two high-drive IOs with 20mA drive strength • Up to 5 high speed IOs • 2-pin serial wire debug (SWD) • Package options – 64-pin LQFP – 48-pin LQFP – 24-pin VQFN – 48-pin VQFN – 32-pin VQFN – 32-pin VSSOP – 28-pin VSSOP – 28-pin DSBGA
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.