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?
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.
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. ;-)
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.
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.
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?
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.
"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.
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.
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.
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.
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.
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 im Beitrag #7987143:
"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.
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.
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.
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...
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.
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.
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.
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.
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. ☺
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.
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
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.
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.
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.
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.
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? ☺
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.
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.
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.
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.
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.
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.
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.
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...
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.
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...
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.
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...
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.
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.
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.
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.
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.
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.
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).
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)?
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.
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.
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.
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.
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.
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".
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?
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.
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.
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.
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.
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
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"
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.
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;-)
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.
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.
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.
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.
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...
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.
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.
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.
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 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.
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.
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.
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.
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.
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... :-)
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...
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.
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.
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!
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
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!
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.
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.
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.
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.
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.
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.
Auch der Feuchtigkeits-/Temperatursensor "TIMMERFLOTTE" arbeitet mit AAA-Zellen, allerdings zwei davon, was aber wohl auch am verbauten Display liegen dürfte.
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.
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.
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.
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).
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.
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.
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":
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.
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.
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.
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.
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.
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.
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.
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?
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
Hi,
ich hab jetzt nicht alle posts durchgelesen aber für mich sind PIC's noch aktuell.
Hier findet ihr meine letzen NMRA-DCC Projekte unter Eisenbahnmodellbau mit PIC10F322 und PIC16F18313:
https://g-zi.de
Mit Dateien für JLCPCB zum Automatischen Bestücken.
Bei den Projekten mit PIC10F322 können auch die HEX-Codes heruntergeladen werden (Manufacturer ID = selfmade).
Die PIC16 Dekoder sind bei der NMRA zum Testen, da warte ich noch auf die Ergebnisse.
Ich bin auch dabei ein mechanisches Hebelstellwerk zu Bauen wo die Stellung der Hebel und Servos für die Weichen und Verriegelungen mit PIC16 über I2C kommunizieren.
PIC microcontrollers may not be as popular as they once were, but they remain a reliable option for many industrial and embedded systems. At Fonhua, we always find it interesting how well-established technologies continue to deliver value alongside newer platforms. Reliability and long-term support often matter more than following the latest trends.
PICs sind für bit-orientierte Real-Time-Steuerungsaufgaben, die nicht viel Rechenleistung erfordern immer noch meine Präferenz. Besonders die kleinen 8-Beiner (12F bzw. früher 12C) ;)
Hätte ich nicht mit PICs angefangen, dann würde ich vermutlich AVR oder 8051 dafür einsetzen.
Ein kleines Programm ist in Assembler sehr schnell geschrieben ("KISS"-Prinzip) und die Entwicklungswerkzeuge fast kostenlos (PICkit2/3-Clones oder K150-Programmer)
Gerade arbeite ich mich in 8051er ein mit der STC-Serie - nachdem die UART-programmierbaren NXP-8051er weg sind, jene von Atmel bzw. Microchip zwar noch da aber schweineteuer und teils nicht mehr als PDIP erhältlich sind.
Selbst die kleinsten 8-Beiner von STC sind mit UART-Bootloader ausgestattet, haben grosszügigen Flash (teils bis zu 64K), alle Chips sind mit internen Oszillatoren ausgestattet und die meisten auch in PDIP erhältlich.
Einen 32-Bitter würde ich erst dort einsetzen, wo es um Farbdisplays, Mathematik/DSP, WiFi, USB, SD-Karten/Filesysteme, UART-basierte Protokolle mit Text-Parsing, etc... geht.
Ich mag deren PPS (quasi alle Funktionen auf allen Pins) und CLC (ersetzt Gluelogik). Das erlaubt kleine und flexible Designs. Zudem gibt es viele HW-Funktionen. Verzweifelt bin ich an den Uart-Bugs in Voll-Duplex.
Seit 25 Jahren werden die bei uns ausschließlich in C programmiert (16er und 18er), inclusive Funktionspointer bei den 18ern. Der Compiler kompensiert den fehlenden Stack perfekt.
Wenn ein PIC passt, ist gut, wenn man Spezialfunktionen braucht, umso besser und wenn nicht, nimmt man halt was anderes. Für eine Wald- und Wiesenaufgabe mit einfachen Portwacklern oder Timern ist es eh egal, was man nimmt.
