Hallo zusammen, für die Steuerungen die ich mir bisher zusammengebaut habe kam ich durch ausreichend Platz immer ohne Mikrocontroller aus und weil es mir auch aus Faulheit immer lieber war Schaltungen komplett selbst zu entwickeln (mir fällt es leichter eigene Schaltungen zu erstellen als fremde nachzuvollziehen) ist das jetzt für mich größtenteils Neuland. Für ein aktuelles Projekt komm ich aber kaum drum herum weil die ganzen Gattern für eine Komponente alleine schon eine ganze Platine füllen würden. Einfache Logikgatter denke ich kann ein Mikrocontroller sowieso deutlich effizienter. Auch wenn ich es erstmal nicht vorhabe (es kann sich ja immer was verändern, oder ich etwas nicht bedacht habe) könnte ich die Programmierung nachträglich ändern. Jetzt meine Fragen, was muss ich alles wissen, welche Architekturen, also welche Unterschiede gibt es bei den einzelnen? Sind sie spezialisiert oder sind sie so umfänglich, das Timer, Speicher und ähnliches bei allen integriert sind? Morgen müsste ich sowieso was bestellen, deswegen wollte ich die Mikrocontroller idealerweise gleich mitbestellen. Ich könnte mich da schon selbst einlesen, werde ich natürlich auch im Verlauf, aber das dauert einige Tage und meine begrenzten Englischkenntnisse beschleunigen das auch nicht gerade. Was muss ich jetzt aber für den Moment beachten? Unterscheiden sich die Funktionen soweit wie ich mir vorstelle, oder kann ich die Mikrocontroller nach ein paar Parametern doch schon auswählen und mitbestellen?
Florian schrieb: > Für ein aktuelles Projekt Was ist denn das für ein "Projekt"? Wie viele Ein- und Ausgänge braut es? Wie schnell müssen die Ausgänge auf Änderungen an den Eingängen reagieren? > Ich könnte mich da schon selbst einlesen Musst du sowiso. > Morgen müsste ich sowieso was bestellen, deswegen wollte ich die > Mikrocontroller idealerweise gleich mitbestellen. Mein Tipp: kauf einen Arduino-Uno und fang damit an. Und behalte immmer im Hinterkopf, dass der darauf verbaute Mikrocontroller auch ohne das Arduino-Entwicklungssystem programmiert werden kann. Und wenn du den einen µC dann gut kennst, ist es tatsächlich so: kennst du einen, dann kennst du alle. Weil alle "im Grunde" gleich sind. Nur eben mal mehr oder weniger schnell und groß und leistungsfähig und mit mehr "Hardware on Chip"...
Florian schrieb: > Sind sie > spezialisiert Ja, es gibt eine Unzahl verschiedene Controller. Viele für "allgemeine" Anwendungszwecke, aber viele auch für ganz bestimmte Anwendungen. Florian schrieb: > oder sind sie so umfänglich, das Timer, Speicher und > ähnliches bei allen integriert sind? Diese Dinge gehören allerdings zur Standardausstattung die fast alle haben. Florian schrieb: > oder kann ich die Mikrocontroller nach ein > paar Parametern doch schon auswählen und mitbestellen? Du musst als erstes mal überlegen was du genau machen willst, dann kann man überlegen welcher Controller geeignet ist. Mit welcher Programmiersprache willst/kannst du ihn programmieren? Was für Programmieradapter und Software braucht es? Wie gut ist Software & Dokumentation? Mikrocontroller nach der parametrischen Suche von Digikey auszusuchen macht wenig Sinn. Bei anspruchslosen Anwendungen ist es eine gute Idee, den zu nehmen der am Einfachsten zu programmieren ist, z.B. einen Arduino-kompatiblen. Denke auch daran dass da Zubehör wie Spannungswandler für Ein&Ausgänge nötig sein können und ggf. ein Quarz, Spannungsregler etc.
Lothar M. schrieb: >> Mikrocontroller idealerweise gleich mitbestellen. > Mein Tipp: kauf einen Arduino-Uno und fang damit an. Florian bastelt offenbar hardwarenah, da ist der Nano die bessere Wahl. Der passt wie ein großes DIL in die Lochrasterplatine und alles für den Uno läuft auch auf diesem.
Florian schrieb: > was muss ich alles wissen Vermutlich nichts, ausser das uC Digitalsignale mit 0V/3.3-5V verarbeiten, Analogsignale oft von 0 bis 1.1/2.5 genauer messen können, selten Analogsignale ausgeben können dafur Impulsfolgen. Passt das nicht zu deiner Umgebung brauchst du Eingangsschaltungen, Spannungsregelung und Ausgangsschaltungen, genannt Treiber. Die übliche Plattform für Einsteiger ist derzeit der Arduino, meist als Nanp oder Uno, weil der über USB vom PC aus programmiert wird. Programme schreibt man dann in C++, wobei andere Plattformen manchmal LUA oder proprietär bevorzugen, auch SPS (AWL) ist möglich. Wenn deine Gatterschaltungen nicht zeitkritisch sind, geht das problemlos per uC, brauchst du aber Reaktionszeiten schneller als 1 Millisekunde musst du mehr Fehirnschmalz investieren.
Florian schrieb: > Schaltungen komplett selbst zu entwickeln > (mir fällt es leichter eigene Schaltungen zu erstellen als fremde > nachzuvollziehen) ist das jetzt für mich größtenteils Neuland. Dann bist du der richtige Kandidat fuer "verdrahtete Logik auf einem Chip", auch als FPGA bekannt. > Für ein aktuelles Projekt komm ich aber kaum drum herum weil die ganzen > Gattern für eine Komponente alleine schon eine ganze Platine füllen > würden. Ja so manche 215x170 Karte wurde damit gefuellt. Aber keine Angst, in besseren (:= teureren) FPGAs, warten genug Logikeinheiten auf ihre Verwendung. Ungefaehre Faustregel: Je $1000 ca. 1 Million davon. So viele wirst du anfangs kaum brauchen. > Jetzt meine Fragen, was muss ich alles wissen, welche Architekturen, > also welche Unterschiede gibt es bei den einzelnen? Sind sie > spezialisiert oder sind sie so umfänglich, das Timer, Speicher und > ähnliches bei allen integriert sind? > Morgen müsste ich sowieso was bestellen, deswegen wollte ich die > Mikrocontroller idealerweise gleich mitbestellen. Bis morgen wirst du kaum fertig sein. > Ich könnte mich da schon selbst einlesen, werde ich natürlich auch im > Verlauf, aber das dauert einige Tage und meine begrenzten > Englischkenntnisse beschleunigen das auch nicht gerade. Was muss ich > jetzt aber für den Moment beachten? Unterscheiden sich die Funktionen > soweit wie ich mir vorstelle, oder kann ich die Mikrocontroller nach ein > paar Parametern doch schon auswählen und mitbestellen? Bis morgen wirst du kaum fertig sein. Lothar M. schrieb: > Mein Tipp: kauf einen Arduino-Uno und fang damit an. Das ist jetzt aber die Bankrotterklaerung. :) > Und wenn du den einen µC dann gut kennst, ist es tatsächlich so: kennst > du einen, dann kennst du alle. Weil alle "im Grunde" gleich sind. Nur > eben mal mehr oder weniger schnell und groß und leistungsfähig und mit > mehr "Hardware on Chip"... Ja wenn es nur die feinen subtilen Unterschiede nicht gaebe... Frohen Advent!
Motopick schrieb: > Dann bist du der richtige Kandidat fuer "verdrahtete Logik auf einem > Chip", auch als FPGA bekannt. Auch wenn das konzeptionell vielleicht logischer wäre, sind Mikrocontroller doch oft einfacher vom Handling, Software/Tooling und auch schlicht billiger und besser verfügbar. FPGAs sind erst dann wirklich sinnvoll wenn es um hohe Geschwindigkeiten geht...
Niklas G. schrieb: > Motopick schrieb: >> Dann bist du der richtige Kandidat fuer "verdrahtete Logik auf einem >> Chip", auch als FPGA bekannt. > > Auch wenn das konzeptionell vielleicht logischer wäre, sind > Mikrocontroller doch oft einfacher vom Handling, Software/Tooling und > auch schlicht billiger und besser verfügbar. FPGAs sind erst dann > wirklich sinnvoll wenn es um hohe Geschwindigkeiten geht... Was nun "einfacher" ist? Man kann Kenntnisse, Faehigkeiten und Fertigkeiten nicht mitbestellen. Leiterplatten voller Gatter gibt es auch nicht umsonst. :)
Motopick schrieb: > Man kann Kenntnisse, Faehigkeiten und Fertigkeiten nicht mitbestellen. Logische Ausdrücke sind in VHDL bzw. C nahezu identisch darzustellen. Speicher und Zeitverhalten aber nicht mehr. Das sequentielle Nutzen von Variablen und delays ist aber ziemlich intuitiv verständlich, während die Transferleistung zwischen HDL zu Hardware schon ziemliche Hirnknoten bewirkt, selbst wenn man Digitalschaltungen grundsätzlich beherrscht. Verrückterweise versucht man ja sogar mit SystemC das Logikdesign zu vereinfachen... Dazu kommt dass die IDEs und sonstiges Tooling für FPGAs größtenteils ziemlich umständlich sind, während z.B. Arduino sehr einsteigerfreundlich daher kommt. Außerdem gibt es einfach viel mehr praktische Mikrocontrollerboards als FPGA-Boards.
Lothar M. schrieb: > Was ist denn das für ein "Projekt"? Wie viele Ein- und Ausgänge braut > es? Wie schnell müssen die Ausgänge auf Änderungen an den Eingängen > reagieren? Genau wollte ich das Projekt nicht unbedingt benennen, weil sicher einige ein paar aus meiner Sicht blöde aber durchaus berechtigte Kommentare schreiben werden. Meine Prioritäten liegen eben "individuell". Ich wollte mir erstmal etwas Wissen aneignen und mir über die Umsetzbarkeit Gedanken machen, aber Eingänge hab ich zum Beispiel an einem LED-Modul 7 bzw. 10 sollte ich Kennwerte übersehen haben. Ausgänge deren Ansteuerung und Anzahl ich mir bereits im klaren bin sind 16. Dazu kommen je nach dem was für LEDs ich finde zwischen 40 und 70 Stück für ein Lauflicht (wenn ich sowieso schon mit uC arbeite dachte ich, ich steuer sie darüber an). So schnell nicht, bis man es selbst optisch registriert.... Lothar M. schrieb: > Musst du sowiso Werde ich auch, das denke ich ist selbstverständlich. Mir geht es im Prinzip wirklich nur darum ob ich mir ohne mich länger einzulesen schon welche bestellen kann ohne das es völliger Quatsch ist. Ein Arduino wollte ich aus Budget-Gründen nicht unbedingt kaufen, die Möglichkeit an einem ein bisschen zu üben hätte ich allerdings. Niklas G. schrieb: > Diese Dinge gehören allerdings zur Standardausstattung die fast alle > haben. Viel mehr brauch ich allerdings auch nicht, die ersten 16 LEDs wollte ich über 5 PWM Signale steuern. Also eigentlich was relativ einfaches. Viel programmiert hab ich noch nicht und das was ich programmiert habe ist schon einige Jahre her, aber viel kann das kaum benötigen. Programmiersprache hab ich mir C++ gedacht, wobei ich mir erstmal wieder die "Vokabeln" aneignen muss. Z.B. Spannungswandler für die Steuerung brauch ich sowieso. Mit den Ausgängen steuer ich über regelbare KSQs die LEDs an.
Florian schrieb: > Dazu > kommen je nach dem was für LEDs ich finde zwischen 40 und 70 Stück für > ein Lauflicht (wenn ich sowieso schon mit uC arbeite dachte ich, ich > steuer sie darüber an). Da brauchst du schon einen relativ großen Controller für diese Anzahl an IOs. Wobei die interne Leistung wurscht ist, wie du schon sagst ist die optische Wahrnehmung langsam. Florian schrieb: > Viel mehr brauch ich allerdings auch nicht, die ersten 16 LEDs wollte > ich über 5 PWM Signale steuern. Sollte mit den meisten Arduinos gehen, hier eine Übersicht über die PWM-Kanäle: https://support.arduino.cc/hc/en-us/articles/9350537961500-Use-PWM-output-with-Arduino Florian schrieb: > Ein Arduino wollte ich aus Budget-Gründen nicht unbedingt kaufen Billiger als Arduino wird's kaum, gerade wenn man auch die billigen Klone betrachtet. Allerdings hat selbst der größte Arduino "nur" 54 Pins. Da könnte man sich schon in Richtung der "STM32 Nucleo-144"-Boards umschauen, die haben mehr Pins und auch mehr PWM-Kanäle. Sind aber auch deutlich komplexer als die Arduinos; es gibt wohl eine Möglichkeit sie per Arduino zu programmieren, das habe ich nicht ausprobiert. Kostet ca 30€ bei Reichelt. Der nackte Chip ist natürlich billiger, aber wenn man dann die Kosten für das ganze Drumherum und auch den Debugger dazurechnet wird man sicherlich bei mehr herauskommen. Florian schrieb: > Programmiersprache hab ich mir C++ gedacht Trifft sich gut, Arduino ist C++ -basiert.
Ok, ich hätte nach den Unterbrechungen wohl neu lesen und wieder neu schreiben sollen, das waren viele flotte Antworten😅 danke. Aber... irgendwie bin ich gerade wirklich demotiviert, viele Begriffe wie FPGA sind mir so spontan komplett fremd. Ich dachte Mikrocontroller als Bauteile, deren Ansteuerung und C++ zum programmieren würden mir ausreichen. Bevor ich was kaufen kann werde ich um das einarbeiten so wohl nicht herumkommen. Ist wohl doch etwas mehr Neuland wie ich dachte 🙈
Florian schrieb: > Ich dachte Mikrocontroller > als Bauteile, deren Ansteuerung und C++ zum programmieren würden mir > ausreichen. Rein technisch ja, praktisch muss man sich mit der Programmierung schon beschäftigen. Bei den Arduinos ist das am Einfachsten, aber dort reichen die Pins nicht. Florian schrieb: > Bevor ich was kaufen kann werde ich um das einarbeiten so wohl nicht > herumkommen. Arduinos oder STM32-Nucleo kann man recht bedenkenlos kaufen, die können grundsätzlich was du brauchst, wenn die Pins reichen. Da wird dann auch kein externer Debugger/Programmieradapter gebraucht, da integriert. Aber für die Programmierung musst du Zeit für die Einarbeitung einplanen.
Ok, ich glaube ich mach das mal anders, einiges überfordert mich gerade wirklich. Die Begriffe mit den blauen Links kenn ich nicht und nur schnell überfliegen reicht mir nicht aus. Arduino kenn ich nur vom Namen und mal kurz sehen, gemacht hab ich damit noch gar nichts. Deswegen, meintet ihr zum testen/ einarbeiten, oder zum verbauen? Weil für die "Endversion" hatte ich schon im Sinn eine eigene individuelle Schaltung zu verwenden. Wo liege ich falsch? Ein Mikrocontroller braucht in der Schaltung doch nur eine Versorgungsspannung, Steuerspannungen und die Programmierung um entsprechende Ausgangssignale zu erzeugen (im entsprechenden Spannungsbereich ist selbsterklärend)🤔
Florian schrieb: > Deswegen, meintet ihr zum testen/ einarbeiten, oder zum verbauen? Beides. Florian schrieb: > Weil für die "Endversion" hatte ich schon im Sinn eine eigene > individuelle Schaltung zu verwenden. Schon möglich, aber alles auf einmal zu machen ist eine knackige Lernkurve. Wenn man bei der Schaltung was falsch macht startet der Controller nicht, und ohne Erfahrung damit zu haben steht man dann blöd da. Florian schrieb: > Versorgungsspannung Muss auch sauber und stabil sein, große Controller brauchen viele Kondensatoren und gutes Layout. Ein Takt per Quarz kann sinnvoll sein. Treiber für LEDs braucht man bei hohen Strömen. Sauber einlöten muss man einen Controller mit vielen kleinen Pins auch erstmal. Florian schrieb: > und die Programmierung Muss auch irgendwie auf den Controller kommen. Dazu brauchst du einen Programmieradapter/Debugger. Manche Controller kann man direkt per USB programmieren aber auch da braucht man eine entsprechende Verschaltung die nicht ganz trivial ist. Das sind einfach sehr viele Baustellen auf einmal. Mit einem fertigen Board erspart man sich viel Ärger. Selber machen kann man später immer noch...
Niklas G. schrieb: > Beides Testen und lernen ok, letzteres wollte ich insbesondere aber wegen den Gestaltungsmöglichkeiten vermeiden, kostentechnisch wäre eine eigene Schaltung auch besser wenn ich mir die Preise anschaue. Und weil ich doch ein paar uCs mehr brauche summiert sich das ganze nicht unerheblich. Das Wissen kann ich immerwieder brauchen, deswegen wäre mir das ganz recht, ich lerne auch relativ schnell. Die Arbeit mach ich mir gerne. Niklas G. schrieb: > Muss auch sauber und stabil sein, große Controller brauchen viele > Kondensatoren und gutes Layout. Ein Takt per Quarz kann sinnvoll sein. > Treiber für LEDs braucht man bei hohen Strömen. Sauber einlöten muss man > einen Controller mit vielen kleinen Pins auch erstmal. Eine saubere und stabile Versorgungsspannung bekomme ich auf jeden Fall hin, daran gedacht hab ich mir weil ich ja noch am "Informationen sammeln" bin aber zu dem Zeitpunkt noch nicht. Bei hohen Strömen? Ein uC kann doch keine ausreichende Ströme für LEDs liefern. Für die Ströme die ich habe brauche ich aber definitiv Treiber. Das Löten ist am Ganzen die leichteste Übung für mich. Ausgetauscht hab ich mittlerweile schon einige, nur um die Programmierung und das umliegende Layout musste ich mich noch nicht kümmern Niklas G. schrieb: > Muss auch irgendwie auf den Controller kommen. Dazu brauchst du einen > Programmieradapter/Debugger. Manche Controller kann man direkt per USB > programmieren aber auch da braucht man eine entsprechende Verschaltung > die nicht ganz trivial ist. > Das sind einfach sehr viele Baustellen auf einmal. Mit einem fertigen > Board erspart man sich viel Ärger. Selber machen kann man später immer > noch... Die Programmierung hatte ich geplant vor dem Einbau auf einer "Programmierplatine" zu setzen (entweder selber noch eine bauen oder wenn es fertige dafür gibt eine solche zu nehmen). Genau so lange wollte ich warten, bis ich genug gelernt und auch getestet hab das ich das selbst kann. Ja, es dauert länger und ist aufwändiger, aber ich kann es einbauen ohne irgendwann die Gehäuse wechseln zu müssen, falls Grundform von einem Arduino überhaupt passt. Damit aber ersteinmal zu lernen und Testschaltungen zu bauen, dagegen spricht aber nichts. Allgemein an der Bereitschaft was zu tun/ zu lernen scheitert es nicht. Aktuell ist es wirklich das Wissen was mir fehlt und das ich mir aneignen möchte.
Niklas G. schrieb: > Logische Ausdrücke sind in VHDL bzw. C nahezu identisch darzustellen. ... und die for-Schleife macht in VHDL bzw. C nahezu das selbe! VHDL
1 | Y <= (A and not B) xor C; |
C
1 | Y = (A && !B)^C; |
Sehen sich tatsächlich zum Verwechseln ähnlich. [/ironie] Florian schrieb: > Genau wollte ich das Projekt nicht unbedingt benennen Eh klar. Aber es geht eben darum, wie schnell etwas passieren soll. Ob das in 100ns oder in 100ms erledigt sein muss. Für ersteres brsuchst du ein FPGA, für letzteres reicht der lahmste uC. Florian schrieb: > Aktuell ist es wirklich das Wissen was mir fehlt und das ich mir > aneignen möchte. Wie gesagt: ksuf dir einrn Arduino und fang mal damit an. Dann hast du schnelle Erfolge. Du ksnnst, wenn es dir sperrig wird, das Arduino-Framework weglassen, oder du kannst einfach einen "Rechenboliden-Arduino" kaufrn.
> kam ich durch ausreichend Platz immer ohne Mikrocontroller aus und > weil es mir auch aus Faulheit immer lieber war Schaltungen komplett > selbst zu entwickeln Das ist bei mir eher andersrum... ich bin zu faul sowas wie keine Ahnung einen NE555 und 2..3 TTL/CMOS-ICs aneinander zu löten, wenn ich die Aufgabe auch mit einem kleinen µC lösen kann, der die Logik oder was ich möchte in Software macht.
Florian schrieb: > Ok, ich hätte nach den Unterbrechungen wohl neu lesen und wieder neu > schreiben sollen, das waren viele flotte Antworten😅 danke. > > Aber... irgendwie bin ich gerade wirklich demotiviert, viele Begriffe > wie FPGA sind mir so spontan komplett fremd. Ich dachte Mikrocontroller > als Bauteile, deren Ansteuerung und C++ zum programmieren würden mir > ausreichen. Na das ging ja schnell. Es ist heute einigermassen trivial einen Controller auf eine Leiterplatte zu setzen. Kennst du eigentlich den Unterschied zwischen C++, C, (hier weitere Hochsprachen einsetzen) und Assembler? Was laesst dich also glauben, dass C++ das Seligmachende ist? Gerade die einfachen Bit- (aka Gatteroperationen) werden von manchen Controllern sehr gut auf Assemblerebene unterstuetzt. In C(++) bleibt von diesen einfachen Eleganz genau nichts uebrig. > Bevor ich was kaufen kann werde ich um das einarbeiten so wohl nicht > herumkommen. > > Ist wohl doch etwas mehr Neuland wie ich dachte 🙈 Das ist wohl eher ein "Land in Sicht". Wenn es um "individuelle" Loesungen geht, liegt ein FPGA vorn. Nur mit dem kann man statt 5 PWM auch 50 oder 500 realisieren. Und niemand wird ernsthaft etwarten koennen, dass das aenlich "billig" wie ein Controller ist. Sowohl vom Preis, als auch vom dafuer zu treibenden geistigen Aufwand. Aber es ist eben im allerhoechsten Mass "individuell". :) Und vom Gedanken, "etwas" mit Arduino auszuprobieren, und dann auf einer anderen Hardware zu realisieren, solltest du dich auch schnell freimachen. Entweder bist du dann bei der Wahl der Zielhardware eingeschraenkt, oder es wird aufwendiger als es gleich auf der gewuenschten Zielhardware zu tun. Frohen Advent!
Florian schrieb: > Und weil ich doch ein paar uCs mehr brauche summiert sich das ganze > nicht unerheblich. Was ist dein Budget pro Platine für den Mikrocontroller? Florian schrieb: > Die Programmierung hatte ich geplant vor dem Einbau auf einer > "Programmierplatine" zu setzen Du wirst mit Sicherheit die Software nachträglich noch ändern wollen. Alleine schon weil auf der "echten" Platine immer Dinge anders sind, und immer Fehler drin sind. Du brauchst also auf jeden Fall eine Möglichkeit zum Programmieren. Lothar M. schrieb: > VHDL > > Y <= (A and not B) xor C; > > C > > Y = (A && !B)^C; > > Sehrn sich tatsächlich zum Verwechseln ähnlich VHDL:
1 | Y <= (A and not B) xor C; |
C++:
1 | Y = (A and not B) xor C; |
Ein Zeichen Unterschied. Motopick schrieb: > Gerade die einfachen Bit- (aka Gatteroperationen) werden von manchen > Controllern sehr gut auf Assemblerebene unterstuetzt. Das ganze drumherum aber nicht. Insbesondere was Libraries und sonstiges Tooling angeht. Das alles in Assembler zu machen ist zumindest für den Anfang viel zu umständlich. Wenn es unbedingt sein muss kann man die Bitoperationen auch in Inline-Assembler machen. Aber alleine schon obiges Beispiel ist in Assembler länger, ob das so elegant ist? Einen großen Controller (wegen der vielen Pins) auf eine eigene Platine setzen und dann erst diesen programmieren zu lernen ist möglich, aber sehr sportlich. Gerade wenn man schnell demotiviert ist. Florian schrieb: > irgendwie bin ich gerade wirklich demotiviert, Die Motivation ist schnell futsch wenn der Weg zur ersten blinkenden LED lang ist, und dann fängt die Arbeit erst richtig an. Und du wirst noch viele viele Begriffe und Aspekte lernen müssen bevor der Controller zum ersten Mal überhaupt irgendwas macht. Hier im Forum sind Unmengen an Threads von Leuten, deren Controller auf ihrer eigenen Platine nicht starten. Das passiert auch erfahrenen Profis. Wenn man sich dann nicht mit dem Controller auskennt, viel Spaß... Selbst im Industrieumfeld wird sehr oft erst ein Prototyp mit Evalboards oder sogar Arduino gebaut, und dann erst eine eigene Platine. Und das von Leuten die sich mit den Controllern auskennen.
Hm, der Trend geht bei sowas zum überdimensionierten Mikrocontroller. Die sind heute so billig, daß man selbst für einfachste Aufgaben gleich einen ARM32 Controller verwendet, obwohl das ein "alter 8-Bitter" auch locker schaffen würde. Jedenfalls solange es nicht um besonders hohe Stückzahlen geht. Ich würde daher aus heutiger Sicht dazu raten, gleich mit einem leistungsfähigeren Controller wie z.B. dem ARM Cortex M0 oder M3 anzufangen, besonders wenn man sowieso auf eine Hochsprache wie C möchte. Dann hat man etwas Spielraum nach oben wenn man die Leistung wirklich einmal braucht und beim Bastler spielt der Preis keine so große Rolle wie in der Serienproduktion. Wobei die Chinesen auch schon lange ARM32-Controller für irgendwelche Dimmer o.Ä. einsetzen, die ganzen Bestandteile eines Elektro-Scooters (Dashboard, Motor-Controller und BMS) sind voll mit ARM32-Varianten. Beim Kern des 8 Bit AVR, der bei sehr vielen Arduino-Varianten verwendet wird, macht es noch sehr viel Spaß, ihn in Assembler zu programmieren. Beim ARM Cortex M0 oder M3 leider nicht mehr ganz so, diese Kerne finde ich deutlich komplexer.
Niklas G. schrieb: > C++ > > Ein Zeichen Unterschied. Ja, wo kommt denn da auf einmal das Doppelplus her?
Ich empfehle für den Anfang ein Nucleo64 Board mit dem STM32L072 mit Arduino zu programmieren. Später eventuell ohne Arduino mit der kostenlosen Cube IDE von ST. Diesen 32 Bit ARM Cortex M0 Controller gibt es in unterschiedlichen Größen. Er hat einen USB Bootloader, der nur stabile 3,3V und ein paar Kondensatoren benötigt. Geht wahlweise mit und ohne Quarz. http://stefanfrings.de/stm32/stm32l0.html
Wenn du es wirklich in dieser Reihenfolge machen willst: Bestell einen STM32G473VB, damit wird es sehr wahrscheinlich funktionieren, und er hat die nötigen IOs. Wenn die Software fertig ist kannst du schauen ob auch ein kleineres Modell reicht. Ja, es gibt viele weitere geeignete Controller, dieser ist eine "Standardmöglichkeit" mit gut nutzbaren Tools. Außerdem kann man ihn direkt per USB in der Zielhardware programmieren. Zur Entwicklung ist aber die Verwendung eines Debuggers dringend zu empfehlen, auf den Nucleo-Boards ist einer integriert. Ben B. schrieb: > Beim ARM Cortex M0 oder M3 leider nicht mehr ganz so, diese Kerne finde > ich deutlich komplexer. Na, gerade die vielen Optimierungsmöglichkeiten machen das doch viel spannender! Aber so etwas mit Assembler zu machen wenn man schon C++ kann halte ich für wenig sinnvoll. Lothar M. schrieb: > Ja, wo kommt denn da auf einmal das Doppelplus her? Auch in C, ob da jetzt && oder "and" steht, ist doch minimalste Transferleistung. Sherlock 🕵🏽♂️ schrieb: > Nucleo64 Zu wenig Pins. Sherlock 🕵🏽♂️ schrieb: > Cortex M0 Reicht zwar im Prinzip, aber ich würde mit einem M3 oder gleich M4 anfangen, da hat man einfach viel mehr "Puffer" um erstmal was zum laufen zu bringen, gerade bei Bitschubsereien (Instruktionen UBFX, BFI & Co). Von der höheren Komplexität merkt man in C/C++ absolut nichts.
M3 und M4 finde ich für den Einstieg auch OK. Nur von der STM32F7xxx Serie würde ich Anfängern abraten, wegen ihrer Komplexität.
Niklas G. schrieb: > ist doch minimalste Transferleistung. Ja, für einen absoluten Anfänger sicher. Hast du da die Ironietags oder den Zwinker-Smiley vergessen?
Florian schrieb: > Eingänge hab ich zum Beispiel an einem LED-Modul 7 bzw. 10 sollte ich > Kennwerte übersehen haben. Ausgänge deren Ansteuerung und Anzahl ich mir > bereits im klaren bin sind 16. Dazu kommen je nach dem was für LEDs ich > finde zwischen 40 und 70 Stück für ein Lauflicht (wenn ich sowieso schon > mit uC arbeite dachte ich, ich steuer sie darüber an). 70 helligkeitsregelbare Lauflicht-LED baut man heute gerne mit WS2812, kostet 1 Pin fur alle. 7 Eingänge und 16 Ausgänge hat schon ein ATmega328 vom Arduino Nano fur 1.69€. Na gut, nicht ganz, sondern 7+15. Aber die Grage ist eher, was an diesen Ein und Ausgängen hängt, oft braucht man Treiber und oft will man Knöpfe und Displays. Florian schrieb: > Ein Arduino wollte ich aus Budget-Gründen nicht unbedingt kaufen, Uff, wenn dir das billigste development Ding für 1.69€ schon das Budget sprengt, vergiss es.
Hallo, Wenn jemand von Gattern kommt und gleich ein Necleo-Board o.ä. einsetzen soll, ist das ein Riiiiesenschritt. Vielleicht schreibt der TO doch mal, was er bauen möchte. Bei Gattern braucht man für 50 LED auch 50 Ausgänge. Bei MC ist das anders. Michael B. schrieb: > 70 helligkeitsregelbare Lauflicht-LED baut man heute gerne mit WS2812, Helligkeit und auch Farben kann man steuern. Wenn man die Strasse beleuchten will, braucht man natürlich Treiber. Eine kleine Platine mit I/O- und Programmiermüglichkeiten ist schon schön. Arduino, ESP32 oder Raspberry Pico finde ich zum Anfang erstmal toll. Arduino-IDE, Bootloader, Bibliotheken und es gibt Lesestoff noch und nöcher. Sicher gibt es für die anderen MC ähnliche Tools und Unterstützung. Weiss ich aber nicht. Gruß Clemens
Manfred P. schrieb: > Florian bastelt offenbar hardwarenah, da ist der Nano die bessere Wahl. > Der passt wie ein großes DIL in die Lochrasterplatine und alles für den > Uno läuft auch auf diesem. Vor allem kann man da mal "einen Kilo" von kaufen, ohne gleich arm zu werden. Wenn man die billigen Chinakracher nimmt. Manchmal muss man diese CH... updaten, aber meistens laufen die sofort an USB. Braucht kein Programmiergerät und kann aus dem auch, wenn er mehrere hat, ein Programmiergerät bauen, wenn mal doch noch kein Bootloader drauf ist oder das Programm ein bisschen zu groß ist und ohne Bootloader noch passt.
Wastl schrieb: > Troll-Alarm ..... und keiner hört es. Ach Leute, der Witz hat soooo einen langen Bart. Ist echt nicht mehr lustig.
Frank O. schrieb: > Manchmal muss man diese CH... updaten, aber meistens laufen die sofort > an USB. Ja, in Linux laufen sie sofort. Windows User sind gearscht, wenn sie einen Fake Chip bekommen haben, was bei der genannten Preisklasse (unter 2 €) recht wahrscheinlich ist. Das ist alles nicht mehr so einfach wie früher, aber billiger.
Sherlock 🕵🏽♂️ schrieb: > Frank O. schrieb: >> Manchmal muss man diese CH... updaten, aber meistens laufen die sofort >> an USB. > > Ja, in Linux laufen sie sofort. Windows User sind gearscht, wenn sie > einen Fake Chip bekommen haben, Du brauchst ein Update!
Sherlock 🕵🏽♂️ schrieb: > Das ist alles nicht mehr so > einfach wie früher, aber billiger. Stefan, mal ehrlich, wie oft musstest du Treiber nachträglich installieren? Und gerade für die Nanos. Ohne dass ich es genau weiß, weil ich den schon irgendwann mal auf einem Rechner installiert habe, denke ich, dass du einen CH340 oder CH341 auch ohne Treiberinstallation auf einem aktuellen Win11 zum laufen bekommst. Selbst wenn nicht, wer sich mit µC beschäftigen will, der hat doch die Computer schon längst durch.
Frank O. schrieb: > Ohne dass ich es genau weiß, weil ich den schon irgendwann mal auf einem > Rechner installiert habe, denke ich, dass du einen CH340 oder CH341 auch > ohne Treiberinstallation auf einem aktuellen Win11 zum laufen bekommst Ähm, nein. BTDT.
Hi Florian Ich habe auch mit dem Aufbau von diskreten Schaltungen begonnen, irgendwelche Steuerungen umzusetzen. Das war in den 70-ern und zu der Zeit war das Wort µC ferne Zukunft. Ca. 40 Jahre später bin ich dann auf die Alleskönner in Form der Atmegas gestoßen und habe ein paar private Spielereien damit umgesetzt. Irgendwann einmal habe ich ein "kleines" Buch geschrieben, welches einen möglichst einfachen Einstieg mit zwei Themen in diese Welt aufzeigt. Das dabei die Programmierung in Assembler vorgenommen wird, sollte kein Hindernis sein. M. e. ist Assembler gar nicht so schwer. Das ist im zweiten Teil mit ein paar aufbauenden Beispielen erklärt. Der erste Teil befasst sich mit der Programmierung in VB auf dem PC und dient der Erfassung von Daten, die ein µC verfügbar macht. Dieses Buch steht zum Download kostenlos unter dem https://www.makerconnect.de/media/u...ocontroller Teil 1 und 2 Stand 26.07.2019.pdf zur Verfügung. Vielleicht hilft es dir. Über eine Rückmeldung würde ich mich freuen. Gruß oldmax PS.: Ja, ich weiß, die "richtige" Sprache ist C. Assembler nutzen nur noch verstaubte Oldies....
Michael B. schrieb: > Ähm, nein. BTDT. Na gut, dann muss man halt den Treiber installieren. Ist das eine unüberwindbare Hürde? Wenn selbst so alte Säcke das hin bekommen.
Martin V. schrieb: > Dieses Buch steht zum Download kostenlos unter dem > https://www.makerconnect.de/media/u...ocontroller Teil 1 und 2 Stand > 26.07.2019.pdf zur Verfügung. Link sagt: "Oops!"
Frank O. schrieb: > Link sagt: "Oops!" Wegen der Leerzeichen (kann die Foren-Software nicht richtig). Du musst die ganze URL aufrufen.
Martin V. schrieb: > PS.: Ja, ich weiß, die "richtige" Sprache ist C. Assembler nutzen nur > noch verstaubte Oldies.... Das kann man nicht so sagen, wie ich finde. Für mich ist die "richtige Sprache" die, mit der man persönlich am einfachsten und schnellsten ans Ziel kommt.
Martin V. schrieb: > PS.: Ja, ich weiß, die "richtige" Sprache ist C. Assembler nutzen nur > noch verstaubte Oldies.... C stammt aus den 70ern, C++ aus den 80ern, AVR und der dazugehörige Assembler aus den 90ern, Rust aus den 2000ern. Also eigentlich hätte man AVRs direkt in C und C++ programmieren können, und jetzt sogar auch in Rust. ARM hat in den 80ern angefangen, und lässt sich natürlich auch super in C, C++ und Rust programmieren. Frank O. schrieb: > Ist das eine unüberwindbare Hürde? Tja, die STM32's mit integriertem USB-Bootloader (die F1 gehören leider nicht dazu) kann man so direkt programmieren ohne Adapter, und der Treiber ist unproblematisch zu installieren (geht automatisch bei Installation des Programmiertools, STM32CubeProg).
Hi Frank O. schrieb: > Link sagt: "Oops!" Mein Fehler, Versuch es mal damit https://www.makerconnect.de/media/user/oldmax/PC%20und%20Mikrocontroller%20Teil%201%20und%202%20Stand%2026.07.2019.pdf Gruß oldmax
Hi Frank O. schrieb: > Für mich ist die "richtige Sprache" die, mit der man persönlich am > einfachsten und schnellsten ans Ziel kommt. Ja, so ist es. Wenn mathematische Aufgaben bewältigt werden müssten, würde ich auch kein Assembler einsetzen. Da käme sogar in Betracht, C zu lernen... oder den Controller in die Ecke zu legen und einen PC mit einer entsprechenden Hochsprache zu nutzen. Aber das ist nicht das Thema. Ich finde, das Assembler für den Umstieg von Logikgattern zum Controller relativ einfach erlernbar ist. Und wenn man modular programmiert, ist auch der Überblick in großen und umfangreichen Programmen gegeben. Gruß oldmax
Praktischerweise kann der C Compiler auch Assembler sowohl innerhalb des C Quelltextes, als auch in separaten Dateien einbinden.
Beitrag #7793313 wurde von einem Moderator gelöscht.
Martin V. schrieb: > Das war in den 70-ern und zu der Zeit war das Wort µC ferne Zukunft. Na ja, zumindest Mikroprozessoren wie den 6502 oder den Z80 gibt es seit 1975/76. Da war die Zukunft, wo alles als µC auf einem Chip sitzt, nicht mehr so fern.
Rainer W. schrieb: > Na ja, zumindest Mikroprozessoren wie den 6502 oder den Z80 gibt es seit > 1975/76. Da war die Zukunft, wo alles als µC auf einem Chip sitzt, nicht > mehr so fern. Beitrag "R6500/1EC von Rockwell"
Ich würde am liebsten direkter auf die Antworten eingehen, aber das wäre jetzt zu umfangreich. Mein Grundgedanke beim stellen meiner Eingangsfrage war es uCs anhand von Grundfunktionen wie Anzahl der Ein- Ausgänge, der Timer usw auszuwählen. Es hätte mir geholfen, erklären kann ich es nicht, aber ich fühl mich besser und mir fällt es leichter damit zu arbeiten etwas physisch zu haben anstatt nur theoretisch damit zu arbeiten. Einen Fehler vom Anfang muss ich aber korrigieren wenn ihr euch das selbst vorstellen wollt. Für die 16 "Haupt-LEDs" hab ich keine PWM sondern werde die mit einem Smartphone über USB ansteuern. 2 Eingänge werden von dem Smartphone gesteuert, zwei erhalten jeweils ein analoges Signal und beim 5. bin ich mir spontan nicht mehr sicher ob digital oder analog. Das Lauflicht in dem Modul wird über zwei digitale Eingänge angesteuert, einmal eben als Lauflicht und einmal konstant leuchtend. (Sollte es helfen könnte ich es grob skizzieren). Solche Steuerungen brauche ich mehrere, nicht alles LEDs, aber über vergleichbare Eingänge die über uCs entweder eine Spannung oder einen Strom regeln sollen. Die Funktionen die die uCs können müssen ähneln sich also, lediglich die Anzahl der Ein- und Ausgänge variieren sowie entsprechend die Programmierung. Wie viele Platinen es genau werden weiß ich noch nicht sicher, aber >10 auf jeden Fall, deswegen war mein Ziel pro Platine unter 10€ zu bleiben was bei den Preisen der einzelnen Bauteilen die ich gesehen habe auch realistisch sein sollte. Arduino kenn ich nur das Uno oberflächlich, das würde mein Budget mit seinen 25€ aber sprengen und durch seine Bauform auch leider nicht passen. Darauf bezieht sich auch das "individuell" beim Arduino ist die Form der Platine fix, von Aussparungen die ich für das Gehäuse bräuchte ganz zu schweigen.
Dann nimm halt die bewährten Arduino Nano Boards für weniger als 2€ pro Stück. Eine eigene Platine mit den selben (wenigen) Bauteilen ist leicht nachbar, allerdings teurer. Erste Versuche macht man sinnvollerweise mit fertigen Boards, sonst hast du zu viele Baustellen gleichzeitig offen (vor allem, wenn es nicht auf Anhieb klappt, jnd das wird es nicht). Smartphone und USB ist schwierig. Denn das Smartphone muss ein USB Host sein. Das ist unter den teuren Modellen noch weit verbreitet, doch die verfügbaren Treiber (z.B. für den USB-UART Chip) sind sehr unterschiedlich. Koppele das Smartphone lieber per WLAN an. Das kann jedes Smartphone gleich. ESP32 oder ESP8266 sind da im Low-Cost Bereich das Mittel der Wahl.
Sherlock 🕵🏽♂️ schrieb: > Praktischerweise kann der C Compiler auch Assembler sowohl innerhalb des > C Quelltextes, als auch in separaten Dateien einbinden. Ja, aber sich gleich mit zwei Sprachen rumplagen weil
1 | digitalWrite (13, (digitalRead (9) and digitalRead (7)) xor digitalRead (14)); |
so viel schlimmer lesbar als
1 | in r24,PINB |
2 | in r25,PIND |
3 | in r18,PINC |
4 | lsr r24 |
5 | bst r25,7 |
6 | clr r25 |
7 | bld r25,0 |
8 | and r24,r25 |
9 | eor r24,r18 |
10 | sbrs r24,0 |
11 | rjmp 1f |
12 | sbi PORTB,5 |
13 | ret |
14 | 1:cbi PORTB,5 |
15 | ret |
ist? Ich weiß ja nicht. Also wenn schon dann mal ARM-Assembler beim STM32G4 (Cortex-M4):
1 | mov r3, #0x48000000 |
2 | ldr r0, [r3, #0x410] |
3 | ldr r1, [r3, #0x810] |
4 | ldr r2, [r3, #0xC10] |
5 | and r0, r0, r2, lsr #6 |
6 | eor r0, r1, r0, lsr #1 |
7 | |
8 | movs r2, #0 |
9 | bfi r2, r0, #5, #1 |
10 | eor r1, r2, #(1<<5) |
11 | orr r2, r2, r1, lsl #16 |
12 | |
13 | str r2, [r3, #0x418] |
14 | |
15 | bx lr |
Ist sogar kürzer, und das obwohl die IO-Register-Zugriffe bei den ARMs komplexer sind, weil der einfach viel mehr davon hat (größerer Adressraum). Die eigentliche Datenverarbeitung ist beim M4 kürzer&schneller (3-4 Takte vs ca. 8 beim AVR, je nachdem wie man zählt und natürlich sind die ARM-Takte viel schneller), dafür muss der STM32 noch den Tanz mit zusätzlichem EOR+ORR machen um das BSRR-Register korrekt zu bedienen für den atomischen Zugriff, weil die ARMs anders als AVR keine direkten atomischen IO-Zugriffe können. Immerhin muss das nur 1x pro Port-Register erfolgen, auch wenn man mehrere (bis 16) Pins auf einmal atomisch setzt - nur ein zusätzlicher Takt für jeden weiteren Pin den man setzt, das ist bei AVR mit SBI/CBI weniger skalierbar. Dieser Code benötigt 44 bytes im Flash. Für den STM32G0 (Cortex-M0+) ist das schon deutlich umständlicher:
1 | ldr r3, =0x50000C10 |
2 | movs r0, #1 |
3 | lsls r0, #10 |
4 | |
5 | ldr r2, [r3] |
6 | subs r3, r0 |
7 | ldr r1, [r3] |
8 | subs r3, r0 |
9 | ldr r0, [r3] |
10 | |
11 | lsrs r2, #7 |
12 | lsrs r0, #1 |
13 | ands r0, r2 |
14 | eors r0, r1 |
15 | |
16 | movs r2, #(1 << 5) |
17 | lsls r0, #5 |
18 | ands r0, r2 |
19 | |
20 | movs r1, r0 |
21 | eors r1, r2 |
22 | |
23 | lsls r1, #16 |
24 | orrs r0, r0, r1 |
25 | |
26 | str r0, [r3, #0x8] |
Die eigentliche Datenverarbeitung ist zwar mit ca. 5 Takten fast genau so schnell wie beim M4, aber der viel simplere Instruction Set des M0+ macht den Umgang mit den langen Registeradressen und mit dem BSRR deutlich schwieriger und daher langsamer. Die Registeradressen berechne ich explizit um das Laden von 32bit-Literals zu vermeiden, was zwar gleich groß aber langsamer wäre. Interessanterweise ist der Code mit 46-48 Bytes kaum größer als der für den M4 (je nach Alignment), aber eben langsamer. Der Instruction Set ist deutlich näher an dem von 8-Bittern dran, auch wenn die Register eben 32bit groß sind. Lediglich bei der Codegröße gewinnt der AVR-Code mit 30 Bytes eindeutig. Dadurch dass typische Cortex-M0+ -Mikrocontroller aber auch höhere Taktraten und größeren Flash-Speicher als 8bitter haben (und M4 natürlich noch mehr), wird der längere und umständlichere Code wieder ausgeglichen. Durch die komplexere Adressierung erkauft man sich die Möglichkeit, viel und komplexe Peripherie problemlos ansteuern zu können. Der gezeigte Code ist auch ein ziemlicher Worst-Case für 32bitter - viele Zugriffe auf weit auseinander liegende Register mit wenig Datenverarbeitung dazwischen. Wenn sich das Verhältnis zu "mehr Verarbeitung" verschiebt (insbesondere viel mit Pointern wie in vielen Datenstrukturen und Mischung von Flash&RAM-Pointern), gewinnen beide ARMs mehr Vorsprung gegenüber 8-Bittern. Immerhin ist hier deutlich gezeigt, dass der M4 doch viel angenehmer in Assembler zu programmieren ist als der M0+ und IMO auch als der AVR, dank Barrel-Shifter und Multifunktions-Instruktionen. Der AVR nutzt das T-Flag um einzelne Bits zwischen Registern zu transferieren, während der M4 mit den Instruktionen UBFX+BFI beliebig große Bitfelder zwischen Registern austauschen kann. Die Möglichkeiten zur Offset-Adressierung und das Shiften der Operanden von vielen Instruktionen nehmen viel Arbeit (und Rechenleistung) ab. Weiterhin können M0 und M4 mehrere Register auf einen Rutsch laden/sichern, und beide Prozessoren sichern automatisch den Kontext bei Interrupt-Eintritt - somit kann man ISRs wie normale Funktionen schreiben und direkt "loslegen" statt erst noch das SREG und sonstige Register manuell sichern zu müssen.
Florian schrieb: > Für die 16 "Haupt-LEDs" hab ich keine PWM > sondern werde die mit einem Smartphone über USB ansteuern Also über den Mikrocontroller? Der wird mit dem Smartphone per USB verbunden? Florian schrieb: > Wie viele Platinen es genau werden weiß ich noch nicht sicher, aber >10 > auf jeden Fall, deswegen war mein Ziel pro Platine unter 10€ zu bleiben Ich denke das wird sehr knapp bei der Stückzahl wenn du einen Controller mit vielen Pins brauchst. Wenn der Arduino Nano von den Pins doch reicht - billiger wirst du es in der Stückzahl nicht schaffen. Es gibt diverse sehr billige Mikrocontroller, mit denen das zwar schon gehen könnte, damit ist dann aber auch die Arbeit komplizierter weil du näher an die Grenze des Möglichen kommst und die Tools weniger hilfreich sind. Nicht optimal für Anfänger. Man wird sich dann im Bereich 1-2€ für den Controller bewegen. Der für USB meistens (nicht immer) erforderliche Quarz kostet extra, dazu Stecker zum Programmieren, Hühnerfutter, USB-Buchse und ESD-Schutz, Spannungsregler... Sherlock 🕵🏽♂️ schrieb: > Das ist unter den teuren Modellen noch weit verbreitet, doch die > verfügbaren Treiber (z.B. für den USB-UART Chip) sind sehr > unterschiedlich. Das ist tatsächlich gar kein Problem unter Android. Man kann aus einer App heraus direkt auf USB-Geräte zugreifen, ähnlich zu libusb, und dann beliebige USB-Transfer machen. Das läuft über die UsbManager-Klasse. Der User muss dies nur 1x erlauben (kein rooten o.ä. erforderlich). Ein USB-UART-Chip wird sowieso nicht im Budget sein, man muss auf dem Mikrocontroller das USB-Protokoll umsetzen. Theoretisch könnte man hier zwar einen USB-Serial-Adapter simulieren, das ist aber nur zusätzlicher Aufwand ohne Nutzen. Sollte man doch mal einen USB-Serial-Adapter unter Android ansteuern wollen, dafür gibt es diese tolle Library: https://github.com/mik3y/usb-serial-for-android Die implementiert die Protokoll der diversen gängigen USB-Serial-Adapter direkt im Userspace (via UsbManager), somit funktioniert dies auf allen Android-Geräten völlig unabhängig von vorinstallierten Treibern. Das Gerät muss nur einen USB-Host haben. Sherlock 🕵🏽♂️ schrieb: > ESP32 oder ESP8266 sind da im Low-Cost Bereich das Mittel der > Wahl. Die haben aber auch sehr wenige Pins.
Pins kann man mit Schieberegistern für wenige Cent erweitern oder mit Port-Expandern. Ist also kein Killer-Kriterium. Die Arduino Nano und Uno Boarfs enthalten USB-UART Chips. Ich glaube nicht, dass man sie ohne Treiber verwenden kann. Was mich wieder zum STM32L072 bringt.
Pins kann man mit Schieberegistern für wenige Cent erweitern oder mit Port-Expandern. Ist also kein Killer-Kriterium. Die Arduino Nano und Uno Boarfs enthalten USB-UART Chips. Ich glaube nicht, dass man sie ohne Treiber verwenden kann. Was mich wieder zum STM32L072 (oder einen stärkeren) bringt.
Sherlock 🕵🏽♂️ schrieb: > Die Arduino Nano und Uno Boarfs enthalten USB-UART Chips. Ich glaube > nicht, dass man sie ohne Treiber verwenden kann. Unter Android kann man den Treiber eben einfach direkt in der App implementieren/mitliefern, in Form der genannten Library. Dann braucht es keinen traditionellen Kernel-Treiber.
Niklas G. schrieb: > Unter Android kann man den Treiber eben einfach direkt in der App > implementieren/mitliefern, in Form der genannten Library. Dann braucht > es keinen traditionellen Kernel-Treiber. Danke für den Tipp. Ich hatte nicht erwartet, dass die tatsächlich den Treiber nachbilden. Meine Antwort war voreilig, ich hätte vorher dem Link folgen sollen.
Sherlock 🕵🏽♂️ schrieb: > Dann nimm halt die bewährten Arduino Nano Boards für weniger als 2€ pro > Stück. Eine eigene Platine mit den selben (wenigen) Bauteilen ist leicht > nachbar, allerdings teurer. Hab jetzt doch endlich gegoogelt, wenn das kein multilayer ist ist das ja ganz schnell mit ätzen auf eine eigene Platine gebastelt, ist ja nichts drauf bis auf ein den Controller und ein paar Kleinigkeiten noch. Bei 32 Pins würde es allerdings nur reichen um damit erstmal zu lernen. Sherlock 🕵🏽♂️ schrieb: > Erste Versuche macht man sinnvollerweise mit fertigen Boards, sonst hast > du zu viele Baustellen gleichzeitig offen (vor allem, wenn es nicht auf > Anhieb klappt, jnd das wird es nicht). Einarbeiten und testen wollte ich es natürlich schon bevor ich die endgültige (eigene) Platine entwerfe. Wenn es nicht funktioniert wie es soll und ich noch Fehler drin hab macht das noch keinen Sinn. Sobald ich eine Schaltung mit Programmierung habe kann ich das Layout ja an die Form die ich brauche anpassen. Sherlock 🕵🏽♂️ schrieb: > Smartphone und USB ist schwierig. Denn das Smartphone muss ein USB Host > sein. Das ist unter den teuren Modellen noch weit verbreitet, doch die > verfügbaren Treiber (z.B. für den USB-UART Chip) sind sehr > unterschiedlich. Ich hatte befürchtet das mir das mit USB noch Probleme bereiten wird. WLAN oder Bluetooth hatte ich mir überlegt, aber wie ich es mir vorstelle ist das keine brauchbare Lösung. Bluetooth und WLAN sind für andere Funktionen gedacht. Wie die Kommunikation über USB genau funktioniert also Adressierung, Rückmeldung ect. (die richtige Benennung weiß ich jetzt nicht) dazu hab ich mich noch nicht informiert. Ich versuche mir wirklich erst Gedanken zu machen wie ich umsetzen kann was ich will. Vorgesehen hab ich ein Samsung s20 ultra, wenn ich es richtig gesehen habe, ist das eines auch wenn es schon älter ist.
Sherlock 🕵🏽♂️ schrieb: > Ich hatte nicht erwartet, dass die tatsächlich den > Treiber nachbilden. Jau. IMO eine ziemlich coole Lösung. Ich glaube diese Terminal-App integriert die Library: https://play.google.com/store/apps/details?id=de.kai_morich.serial_usb_terminal Man kann ausprobieren ob die App mit dem gewünschten Adapter funktioniert, und wenn ja dürfte die Bibliothek in eigenen Apps dann auch gehen. Hab es schon mit einem uralten Original-Arduino (FT232RL) und Custom CDC-ACM-Implementation getestet.
Florian schrieb: > Bei 32 Pins würde es allerdings nur reichen um damit erstmal zu lernen. Du kannst ja auf deiner eigenen Platine AVR mit mehr Pins verwenden, zum Beispiel den ATmega644 oder ATmega2560 (bekannt als Arduino Mega).
Florian schrieb: > Wie die Kommunikation über USB genau > funktioniert dazu hab ich mich noch nicht informiert Niklas G. schrieb: > dafür gibt es diese tolle Library: > https://github.com/mik3y/usb-serial-for-android Kannte ich noch nicht.
Florian schrieb: > ist ja > nichts drauf bis auf ein den Controller und ein paar Kleinigkeiten noch. Allerdings wirst du den nackten Controller kaum so billig bekommen wie die komplette fertigen Arduino Nanos aus Fernost. Die beliebten STM32-Bluepill-Boards wären auch eine Option, aber die kann man nicht direkt per USB programmieren und sie haben auch nicht allzu viele Pins. Aber sie haben natives USB und sind billig. Man muss aber wegen Fälschungen aufpassen und die Widerstände für die USB-Erkennung sind teilweise nicht/falsch (?) bestückt. Florian schrieb: > Bluetooth und WLAN sind für > andere Funktionen gedacht Da kannst du grundsätzlich auch alles mit übertragen. Die Latenz wird etwas höher sein als bei USB. Florian schrieb: > Wie die Kommunikation über USB genau > funktioniert also Adressierung, Rückmeldung ect. (die richtige Benennung > weiß ich jetzt nicht) dazu hab ich mich noch nicht informiert. Ich > versuche mir wirklich erst Gedanken zu machen wie ich umsetzen kann was > ich will. Das ist ein ziemlich komplexes Thema für sich. Da empfehle ich immer gern mein USB-Tutorial mit STM32. Einen virtuellen Serial-Port auf dem Controller selbst zu implementieren bringt hier nichts, da kann man auch einfach direkt per UsbManager ein eigenes Protokoll implementieren. Florian schrieb: > Vorgesehen hab ich ein Samsung s20 ultra Das sollte funktionieren, es unterstützt OTG. Ich habe die 5G-Version davon, mit der klappt so etwas problemlos.
Hallo Florian, ich arbeite mit der Arduino - IDE und ESP32, ESP8266 (D1Mini), ... Die können so einiges. Einen guten Überblick findest Du hier: https://randomnerdtutorials.com/ Diese Tutorials sind gut aufgebaut. Ich hatte mit denen noch nie Probleme gehabt. Es wird nichts übersprungen, sondern alles gut erklärt. Wenn Du viele IO-Ports brauchst können Dir I2C IO-Expander-Module helfen. Module mit dem PCF8575 bieten Dir 16 Ports. https://www.ebay.de/itm/276674707330 Du kannst natürlich mehrere Module zugleich betreiben. Platinen lasse ich seit über 6 Jahren hier https://jlcpcb.com/ anfertigen. Bezahlen tut man über PayPal. 2 Layer 100mm x 100mm kosten 2$ für 5 Stück. Weniger liefern die nicht. Als Versand wählst Du das EuroPaket. Da sammenln die alle Aufträge und fliegen die in einer Kiste nach Leipzig. In Deutschland werden die per DHL verteilt. Für meine letzte Lieferung von 5 Platinen habe ich 6,32$ bezahlt. Vor jlcpcb habe ich Platinen in Deutschlang fertigen lassen. Da zahlte ich für 2 100mm x 160mm über 50 €. mfg Klaus
Klaus R. schrieb: > https://jlcpcb.com/ > > anfertigen. Bezahlen tut man über PayPal. 2 Layer 100mm x 100mm kosten > 2$ für 5 Stück. Weniger liefern die nicht. Als Versand wählst Du das > EuroPaket. Da sammenln die alle Aufträge und fliegen die in einer Kiste > nach Leipzig. In Deutschland werden die per DHL verteilt. Für meine > letzte Lieferung von 5 Platinen habe ich 6,32$ bezahlt. Vor jlcpcb habe > ich Platinen in Deutschlang fertigen lassen. Da zahlte ich für 2 100mm x > 160mm über 50 €. > > mfg Klaus Lohnt Lochraster nicht mehr. Selbst wenn man einen Fehler gemacht hat. Muss ich beim nächsten Mal auch machen.
Niklas G. schrieb: > Also über den Mikrocontroller? Der wird mit dem Smartphone per USB > verbunden? Das ist eine gute Frage. Gedacht war das so ursprünglich, ja. Allerdings hab ich nicht bedacht das ich ja mehrere Platinen habe und die alle per USB gesteuert werden. Im Grundverständnis von USB fehlt mir dazu die Adressierung. Ich weiß nicht ob es vielleicht besser wäre die Signale von einem "Verteiler" an die einzelnen Platinen zu leiten. Niklas G. schrieb: > Es gibt diverse sehr billige Mikrocontroller, mit denen das zwar schon > gehen könnte, damit ist dann aber auch die Arbeit komplizierter weil du > näher an die Grenze des Möglichen kommst und die Tools weniger hilfreich > sind. Nicht optimal für Anfänger. Man wird sich dann im Bereich 1-2€ für > den Controller bewegen. Der für USB meistens (nicht immer) erforderliche > Quarz kostet extra, dazu Stecker zum Programmieren, Hühnerfutter, > USB-Buchse und ESD-Schutz, Spannungsregler... Sobald ich die Basics verstanden hab kann ich damit eigentlich auch gut komplexer arbeiten. Bis zum jetzigen Zeitpunkt hab ich mich aber noch nicht damit auseinander gesetzt. Ich wollte mir erstmal eine Übersicht über den grundsätzlichen Aufbau verschaffen und überlegen wie ich das realisieren kann. Niklas G. schrieb: > Allerdings wirst du den nackten Controller kaum so billig bekommen wie > die komplette fertigen Arduino Nanos aus Fernost. Die beliebten > STM32-Bluepill-Boards wären auch eine Option, aber die kann man nicht > direkt per USB programmieren und sie haben auch nicht allzu viele Pins. > Aber sie haben natives USB und sind billig. Man muss aber wegen > Fälschungen aufpassen und die Widerstände für die USB-Erkennung sind > teilweise nicht/falsch (?) bestückt. Ja, die klassische Logik, 2+2=1🤐😅 Per USB programmieren wäre denke ich nicht so tragisch, on Board soll die Programmierung ja sowieso fix bleiben. Fälschungen wären aber ein wirkliches Problem, weil ich das Original schon nicht kenne kann ich Fälschungen wohl kaum erkennen.
Frank O. schrieb: > Lohnt Lochraster nicht mehr. Selbst wenn man einen Fehler gemacht hat. > Muss ich beim nächsten Mal auch machen. Das kann ich nur bestätigen. Lieferzeit 10 - 14 Tage. mfg Klaus
Florian schrieb: > Im Grundverständnis von USB fehlt mir dazu die > Adressierung. Naja, es gibt ja USB-Hubs. Damit kannst du grundsätzlich bis zu 127 Geräte anschließen. Es könnte halt unhandlich werden. Um die Adressierung musst du dich nicht kümmern, für die USB-Endgeräte sind Hubs und andere Endgeräte "unsichtbar", die "sehen" nur den Host. In der Anwendung hast du dann mehrere UsbDeviceConnection-Instanzen, da steckt auch eine Adresse drin, aber da bekommst du nicht viel von mit. Um die Geräte zu unterscheiden kannst du z.B. die Seriennummer abfragen - in der Firmware kannst du da was beliebiges zurücksenden. Achja, ich gehe davon aus du kannst Android-Apps programmieren (in Java/Kotlin)...? Florian schrieb: > Ich weiß nicht ob es vielleicht besser wäre die Signale > von einem "Verteiler" an die einzelnen Platinen zu leiten. Auch möglich, aber nur sinnvoll wenn die Leitungen zu den einzelnen Platinen z.B. besonders lang oder störgefährdet sind, dann könnte man einen Feldbus à la CAN oder RS485 dazwischen schalten. Das bedeutet aber zusätzlichen Aufwand, einen USB-Hub zu verwenden ist da einfacher und flexibler. Florian schrieb: > Sobald ich die Basics verstanden hab kann ich damit eigentlich auch gut > komplexer arbeiten. Naja, wenn du noch nie mit Mikrocontrollern gearbeitet hast... Weißt du wie man ein Programm so optimiert dass es möglichst wenig Programmcode braucht (so wie ich das bei o.g. Assembler-Beispielen gemacht hab) und in den kleinen Flash eines billigen Controllers passt, und dass es mit wenig RAM auskommt? Weißt du wie man eine Software-PWM implementiert für Controller mit zu wenigen PWM-Kanälen? Florian schrieb: > Per USB programmieren wäre denke ich nicht so tragisch, on Board soll > die Programmierung ja sowieso fix bleiben. Das denkt man am Anfang, aber man hat immer später neue Wünsche oder findet Fehler. Nicht ohne Grund haben selbst massenproduzierte Verbrauchergeräte oft irgendwo eine versteckte Programmier-Schnittstelle. Wenn du einen STM32F103 benutzt, solltest du also die SWD-Schnittstelle irgendwie rausführen (z.B. auf Pads für Tag-Connect-Kabel) zum Umprogrammieren. Bei moderneren Controllern reicht USB. Florian schrieb: > älschungen wären aber ein > wirkliches Problem Viele von den Fälschungen funktionieren sogar grundsätzlich, haben aber ein paar subtile Tücken. Da gibt's hier irgendwo ne lange Diskussion... Es hilft originale Eval-Boards vom Mikrocontroller-Hersteller oder Olimex o.ä. zu kaufen, das sind dann ziemlich sicher keine Fälschungen. Florian schrieb: > Wie viele Platinen es genau werden weiß ich noch nicht sicher, aber >10 > auf jeden Fall, deswegen war mein Ziel pro Platine unter 10€ zu bleiben Du möchtest also unter 100€ bleiben? 150€ wären zu viel? Rechne damit dass du noch diverses an Zubehör brauchst, wie Debugger, USB-Serial-Adapter, eventuell Logic Analyzer oder Oszilloskop, Eval-Boards zum ausprobieren, diversen Kleinkram für Tests. Eine USB-Lizenz kostet eigentlich 6000$ aber für Hobby-Projekte kann man das mal "übersehen".
Niklas G. schrieb: >> > > Naja, es gibt ja USB-Hubs. Damit kannst du grundsätzlich bis zu 127 > Geräte anschließen. Es könnte halt unhandlich werden. Um die > Adressierung musst du dich nicht kümmern, für die USB-Endgeräte sind > Hubs und andere Endgeräte "unsichtbar", die "sehen" nur den Host. In der > Anwendung hast du dann mehrere UsbDeviceConnection-Instanzen, da steckt > auch eine Adresse drin, aber da bekommst du nicht viel von mit. Um die > Geräte zu unterscheiden kannst du z.B. die Seriennummer abfragen - in > der Firmware kannst du da was beliebiges zurücksenden. Achja, ich gehe > davon aus du kannst Android-Apps programmieren (in Java/Kotlin)...? Ich denke alles was detaillierter ist werde ich zumindest per schreiben nicht mehr bereden können das muss ich mir selbst erarbeiten, mir fehlen dafür einfach die sprachlichen Fähigkeiten. Apps hab ich noch nicht programmiert, nein. Meine letzte Programmierung liegt ca 10 Jahre zurück. Deswegen muss ich die Vokabeln die ich mir noch nie richtig merken konnte neu lernen. Etwas eingerostet bin ich durch die lange Pause definitiv auch. C++ war aber bisher meine einzige Programmiersprache. Niklas G. schrieb: > Das denkt man am Anfang, aber man hat immer später neue Wünsche oder > findet Fehler. Nicht ohne Grund haben selbst massenproduzierte > Verbrauchergeräte oft irgendwo eine versteckte > Programmier-Schnittstelle. Wenn du einen STM32F103 benutzt, solltest du > also die SWD-Schnittstelle irgendwie rausführen (z.B. auf Pads für > Tag-Connect-Kabel) zum Umprogrammieren. Bei moderneren Controllern > reicht USB. Sobald ich die Programmierung fix hab das ich sie ins fertige Modul bauen kann hatte ich tatsächlich vor das sie nicht mehr ändere. Mein ursprünglicher Gedanke war es ja eine rein hardwarebasierte Steuerung zu bauen, die ist auf die beabsichtigten Funktionen beschränkt und das ist auch gut so. Niklas G. schrieb: > Du möchtest also unter 100€ bleiben? 150€ wären zu viel? Rechne damit > dass du noch diverses an Zubehör brauchst, wie Debugger, > USB-Serial-Adapter, eventuell Logic Analyzer oder Oszilloskop, > Eval-Boards zum ausprobieren, diversen Kleinkram für Tests. Eine > USB-Lizenz kostet eigentlich 6000$ aber für Hobby-Projekte kann man das > mal "übersehen". Sagen wir es ist der "Rahmen" mein Projekt besteht aus vielen Komponenten, Elektronik ist nur eines davon. Deswegen, fix ist das nicht, aber ich kalkuliere lieber etwas pessimistisch und ich dehne für einen Teil das Budget sollte es wirklich nicht anders gehen als das ich alles genau festlege und es durch eine nicht bedachte Stelle nicht reicht.
Florian schrieb: > Apps hab ich noch nicht programmiert, nein. Meine letzte Programmierung > liegt ca 10 Jahre zurück Dann rechne mit einer ordentlichen Lernkurve und Einarbeitungszeit. Florian schrieb: > Sobald ich die Programmierung fix hab das ich sie ins fertige Modul > bauen kann hatte ich tatsächlich vor das sie nicht mehr ändere. Das haben alle vor, aber die Erfahrung lehrt, dass es immer anders kommt als erwartet. Man muss sich Möglichkeiten offen halten. Und der Controller muss ja überhaupt auch mal initial programmiert werden, da brauchst du sowieso eine entsprechende Schnittstelle. Einen einzelnen SMD-Chip so zu kontaktieren dass man ihn programmieren kann ist schwierig und ziemlich unüblich. Florian schrieb: > aber ich kalkuliere lieber etwas pessimistisch Die 10€ pro Platine sind ganz schön optimistisch. Abseits der massenproduzierten, mit nachgemachten billigst-Komponenten (die du gar nicht kaufen kannst) hergestellten Fernost-Platinen sind die meisten Eval-Boards schon deutlich teurer, und das obwohl die Stückzahl deutlich über 10 liegt. Wenn der Original-Arduino oder ein STM32-Nucleo (diese werden praktisch zum Selbstkostenpreis verkauft) dir schon zu teuer ist - da ist kaum was drauf, wie kann deine Platine dann mit diesen Komponenten und deinen LED-Treibern noch billiger werden?
Florian schrieb: > Ein Arduino wollte ich aus Budget-Gründen nicht unbedingt kaufen, die > Möglichkeit an einem ein bisschen zu üben hätte ich allerdings. Arduino ist open-source, da darf man Clone kaufen. Frank O. schrieb: > Vor allem kann man da mal "einen Kilo" von kaufen, ohne gleich arm zu > werden. > Wenn man die billigen Chinakracher nimmt. Ich kenne keine aktuellen Preise. Meine letzten habe ich 2020 gekauft, um 2..3 €uro und genug im Vorrat, auch 8 MHz ohne USB. > ein Programmiergerät bauen, wenn mal doch noch kein Bootloader > drauf ist oder das Programm ein bisschen zu groß ist und ohne Bootloader > noch passt. Zeige mal, wie man mit der Arduino-IDE Software baut, die den Speicher des Bootloaders nutzen kann. Sherlock schrieb: > Ja, in Linux laufen sie sofort. Windows User sind gearscht, wenn sie > einen Fake Chip bekommen haben, Spinner. Es gibt mehr als einen Thread, wo Linuxer Arduino-Clone nicht zum Laufen bekamen. Unter Windows ist das einfacher, einen Treiber nachzurüsten oder auszutauschen. Wie viele Fake-CH340 hast Du schon gehabt - vermutlich keinen, aber um Deine rege Phantasie kann man Dich schon beneiden. Niklas G. schrieb: >> Ist das eine unüberwindbare Hürde? > > Tja, die STM32's mit integriertem USB-Bootloader (die F1 gehören leider > nicht dazu) kann man so direkt programmieren ohne Adapter, und der > Treiber ist unproblematisch zu installieren (geht automatisch bei > Installation des Programmiertools, STM32CubeProg). Wehe, Du bringst den STM in den Uploadmodus, bevor der USB-Treiber auf dem PC ist. Das hatte ich mit einer komerziellen Fremdentwicklung, das Gerät war danach tot und musste per ICP wiederbelebt werden. Rainer W. schrieb: > Na ja, zumindest Mikroprozessoren wie den 6502 oder den Z80 gibt es seit > 1975/76. Da war die Zukunft, wo alles als µC auf einem Chip sitzt, nicht > mehr so fern. 6502 habe ich in den 80ern per Assembler bespielt, ein eigenes CPU-Board als Eurokarte layoutet und fertigen lassen. Frage lieber nicht, was die Leiterplatten gekostet haben, in Hannover gefertigt. Eine Weile später hatte ich MC68HC05 mit EEPROM als PLCC in den Fingern, da waren dann Ports mit drin. Die natürlich auch in Assembler betan. Florian schrieb: > Wie viele Platinen es genau werden weiß ich noch nicht sicher, aber >10 > auf jeden Fall, deswegen war mein Ziel pro Platine unter 10€ zu bleiben > was bei den Preisen der einzelnen Bauteilen die ich gesehen habe auch > realistisch sein sollte. Arduino kenn ich nur das Uno oberflächlich, das > würde mein Budget mit seinen 25€ aber sprengen und durch seine Bauform > auch leider nicht passen. Lesen kannst Du, warum wohl nannte ich den Nano? Wenn es eine eigene Leiterplatte wird, darfst Du den µC auch gerne als einzelnes IC auflöten und das Drumherum selbst machen. Du wirst aber kaum dran vorbei kommen, für Deine hohe Anzahl Ports zusätliche Peripherie anzubauen. Wenn Du wirklich auf 10 €uro fixiert bist, lass' es sein. Frank O. schrieb: >> Für meine >> letzte Lieferung von 5 Platinen habe ich 6,32$ bezahlt. >> > Lohnt Lochraster nicht mehr. Selbst wenn man einen Fehler gemacht hat. Für ein Einzelstück ist das Unfug, erst bei mehreren Stück macht die Platine Sinn. Klaus R. schrieb: >> Lohnt Lochraster nicht mehr. Selbst wenn man einen Fehler gemacht hat. >> Muss ich beim nächsten Mal auch machen. > Das kann ich nur bestätigen. Lieferzeit 10 - 14 Tage. Während Du Deine Platine malst und auf die Lieferung wartet, ist meine Lochraster schon in Betrieb, Einzelstück Florian schrieb: > Das ist eine gute Frage. Gedacht war das so ursprünglich, ja. Allerdings > hab ich nicht bedacht das ich ja mehrere Platinen habe und die alle per > USB gesteuert werden. Im Grundverständnis von USB fehlt mir dazu die > Adressierung. Ich weiß nicht ob es vielleicht besser wäre die Signale > von einem "Verteiler" an die einzelnen Platinen zu leiten. Du willst Dinge, die Dein Wissen erheblich übersteigen. Anstatt hier tausend Ideen zu zeigen, Füsse auf den Boden und erstmal Grundlagen erarbeiten.
Manfred P. schrieb: > Ich kenne keine aktuellen Preise. Meine letzten habe ich 2020 gekauft, > um 2..3 €uro und genug im Vorrat, auch 8 MHz ohne USB. Ja, die gab es ohne USB sogar zwischenzeitlich für 1,50 Euro. Man muss immer die passenden Momente abwarten. Dann gibt es die mit 16 MHz und USB für ca. 3 Euro. Aber das letzte Mal musste ich schon eine Weile suchen. Ich bestelle dann aber meistens 10-20 Stück. Das macht dann den Preis aus.
Manfred P. schrieb: > Wehe, Du bringst den STM in den Uploadmodus, bevor der USB-Treiber auf > dem PC ist. Das hatte ich mit einer komerziellen Fremdentwicklung, das > Gerät war danach tot und musste per ICP wiederbelebt werden. Das ist mir noch nie passiert und kann mir auch nicht vorstellen was da passiert sein soll. Der Bootloader ist im ROM und kann nicht modifiziert werden. Kein OS sendet an unbekannte Geräte komische Befehle (an USB-Serial-Ports teilweise schon, aber die STM32-Bootloader melden sich nicht als solche an). Durch einen extrem seltenen Power-Glitch könnten vielleicht die Option Bytes kaputt gegangen sein? Sicher dass das überhaupt der ROM-Bootloader war und nicht ein eigener im Flash? Aber eine SWD/JTAG-Schnittstelle sollte man so oder so vorsehen. Frank O. schrieb: > Dann gibt es die mit 16 > MHz und USB für ca. 3 Euro. Die mit USB haben dann einen CH340 drauf? Also das USB geht nicht direkt an den Controller?
Niklas G. schrieb: > Die mit USB haben dann einen CH340 drauf? Also das USB geht nicht direkt > an den Controller? Ja und nein. Natürlich nicht. Habe ich aber auch noch nie beim Nano gesehen, dass da USB auf den Controller geht. Dann müsste der ATmega328 direkt USB können.
Manfred P. schrieb: > Zeige mal, wie man mit der Arduino-IDE Software baut, die den Speicher > des Bootloaders nutzen kann. https://github.com/MCUdude/MegaCore#bootloader-option
Stück für ~97cent, mit Versand. Sogar aus Deutschland. Muss man nur 4 x diese 3 Stück nehmem. https://www.ebay.de/itm/255283140515?mkcid=16&mkevt=1&mkrid=707-127634-2357-0&ssspo=kSLcqpXwSAK&sssrc=2047675&ssuid=2LzyVcAhTDy&widget_ver=artemis&media=COPY
Frank O. schrieb: > Na gut, dann muss man halt den Treiber installieren. > Ist das eine unüberwindbare Hürde? > Wenn selbst so alte Säcke das hin bekommen. Ich habe vorhin für Spaß nach dem Treiber gesucht und (nochmal) installiert. Hat keine 5 Minuten gedauert.
Niklas G. schrieb: > Die 10€ pro Platine sind ganz schön optimistisch. Abseits der > massenproduzierten, mit nachgemachten billigst-Komponenten (die du gar > nicht kaufen kannst) hergestellten Fernost-Platinen sind die meisten > Eval-Boards schon deutlich teurer, und das obwohl die Stückzahl deutlich > über 10 liegt. Wenn der Original-Arduino oder ein STM32-Nucleo (diese > werden praktisch zum Selbstkostenpreis verkauft) dir schon zu teuer ist > - da ist kaum was drauf, wie kann deine Platine dann mit diesen > Komponenten und deinen LED-Treibern noch billiger werden? Wie gesagt, die 10€ sind die Grenze die ich nur sehr UNGERN überschreiten möchte, ausgeschlossen habe ich es jedoch nicht. "Leistungsteil" und Steuerung hab unabhängig von einander geplant, also fallen LED-Treiber und deren Komponenten nicht in die 10€ Rechnung. Manfred P. schrieb: > Du willst Dinge, die Dein Wissen erheblich übersteigen. Anstatt hier > tausend Ideen zu zeigen, Füsse auf den Boden und erstmal Grundlagen > erarbeiten. Du schreibst es doch schon selber, ich will Dinge die mein WISSEN übersteigen. Was hält mich denn davon ab mir das Wissen anzueignen? Ich sagte nicht es soll morgen fertig sein. Ich bezweifle das du mit deinem Wissen geboren wurdest, das hast du dir schön mühselig angeeignet. Andere streamen am Abend mal ein zwei Stunden um zu entspannen, entspannen kann ich nicht unbedingt sagen, aber es ist ein gutes Gefühl ein Teil des Puzzles gelöst zu haben das mich beschäftigt. Bei mir fließt eben meine ganze Freizeit in sowas, da kommen schnell ein paar hundert Stunden zusammen in denen ich nur lerne. Jeder hat eben seine eigenen Prioritäten.
Florian schrieb: > also fallen LED-Treiber und deren Komponenten nicht in die 10€ Rechnung. Na immerhin. Was fällt alles da rein? Das PCB selbst auch? Florian schrieb: > Ich bezweifle das du mit deinem Wissen geboren wurdest, das hast du dir > schön mühselig angeeignet Andere brauchen Jahre um sich das alles anzueignen; so lange an einem einzelnen Projekt zu tüfteln wenn man schon ganz am Anfang was von Motivationsmangel sagt klingt nicht so vielversprechend.
Niklas G. schrieb: > Na immerhin. Was fällt alles da rein? Das PCB selbst auch? Musste ich gerade tatsächlich überlegen ob ich die wo anders drin hab, gut ich geb zu meine Gedanken sind da ab und zu etwas unsortiert, aber ja, die PCBs hab ich wirklich auf einem anderen Posten. Die 10€ beinhalten tatsächlich nur die Bestückung. Niklas G. schrieb: > Andere brauchen Jahre um sich das alles anzueignen; so lange an einem > einzelnen Projekt zu tüfteln wenn man schon ganz am Anfang was von > Motivationsmangel sagt klingt nicht so vielversprechend. Ich weiß nicht ob ich mit meinen Gedanken so aus der Reihe tanze, aber wenn ich Begriffe lese die ich genauer betrachten muss nur um daraus eines zu wählen und der Rest ist zumindest vorerst egal, ja mich demotiviert das. Eine Sache zu lernen und damit zu arbeiten für die ich auch eine praktische Verwendung hab finde ich hingegen sehr motivierend.
Florian schrieb: > Die 10€ beinhalten tatsächlich nur die Bestückung. Dann kann es schon eher hinkommen mit einem gewöhnlichen Mikrocontroller und dessen Zubehör. Florian schrieb: > aber wenn ich Begriffe lese die ich genauer betrachten muss nur um > daraus eines zu wählen und der Rest ist zumindest vorerst egal, ja mich > demotiviert das. Aber genau das wirst du bei deinem Ansatz in sehr großem Maße haben. Du musst ein riesige Menge Begriffe lernen und Entscheidungen treffen, und erst in ferner Zukunft wird überhaupt erstmal irgendwas anfangen zu funktionieren. Zu Anfang mal alle Begriffe aus diesem Thread. Genau das ist der Grund warum das niemand sonst so macht und schafft. Florian schrieb: > . > Eine Sache zu lernen und damit zu arbeiten für die ich auch eine > praktische Verwendung hab finde ich hingegen sehr motivierend. Daher ist es viel sinnvoller in kleinen Schritten anzufangen. Erst mit ein paar fertigen Mikrocontroller Boards (z.B. Arduino) rumspielen, C++ Kenntnisse auffrischen, allgemein in die Embedded Welt einarbeiten, LEDs blinken lassen. Dann damit in USB einarbeiten, die Gegenseite auf dem PC implementieren. Dann in Android App Entwicklung einarbeiten, eine rudimentäre App für die USB Ansteuerung implementieren. Wenn das alles klappt kannst du anfangen darüber nachzudenken eine eigene Hardware zu entwickeln. So hast du immer nur eine Baustelle auf einmal und kannst praktisch lernen. So wie es im Endeffekt alle machen. Bei Vollzeit-Arbeit wird das ein paar Monate dauern.
Niklas G. schrieb: > Daher ist es viel sinnvoller in kleinen Schritten anzufangen. Erst mit > ein paar fertigen Mikrocontroller Boards (z.B. Arduino) rumspielen, C++ > Kenntnisse auffrischen Ja, eine Variante! Eine Andere: Ein ESP32, z.B. ESP32-C3 Ist für ca. 2 bis 5 Euronen zu haben I2C/SPI Portexpander sind auch in der Preislage. Die Anbindung ans Händi kann über USB, WLAN oder BT erfolgen. Programmierung über OTA oder USB Tuts u.A. auch mit der Arduino IDE.
Niklas G. schrieb: > Aber genau das wirst du bei deinem Ansatz in sehr großem Maße haben. Du > musst ein riesige Menge Begriffe lernen und Entscheidungen treffen, und > erst in ferner Zukunft wird überhaupt erstmal irgendwas anfangen zu > funktionieren. Zu Anfang mal alle Begriffe aus diesem Thread. Genau das > ist der Grund warum das niemand sonst so macht und schafft. Da geb ich dir Recht, nach dem Ansatz arbeite ich dummerweise ja schon immer. Viele Ideen sind deswegen auch schon gescheitert die meisten und oft auch die größten sind aber fertig geworden und haben bis auf ein paar Wunschvorstellungen auch so funktioniert wie sie sollten. Bei größeren Herausforderungen wächst dann auch die Motivation es durchziehen zu wollen. Das einprasseln von fremden Begriffen nimmt mit dem Fortschritt aber auch ab. Niklas G. schrieb: > Daher ist es viel sinnvoller in kleinen Schritten anzufangen. Erst mit > ein paar fertigen Mikrocontroller Boards (z.B. Arduino) rumspielen, C++ > Kenntnisse auffrischen, allgemein in die Embedded Welt einarbeiten, LEDs > blinken lassen. Dann damit in USB einarbeiten, die Gegenseite auf dem PC > implementieren. Dann in Android App Entwicklung einarbeiten, eine > rudimentäre App für die USB Ansteuerung implementieren. Wenn das alles > klappt kannst du anfangen darüber nachzudenken eine eigene Hardware zu > entwickeln. So hast du immer nur eine Baustelle auf einmal und kannst > praktisch lernen. So wie es im Endeffekt alle machen. Bei > Vollzeit-Arbeit wird das ein paar Monate dauern. Dieser Ablauf ist glaube ich fast universell. Das Ziel ist zumindest aus meiner Sicht doch schon größer, deswegen wollte ich mir erstmal einen Überblick verschaffen was ich alles brauche, was ich lernen muss und ob es überhaupt für mich umsetzbar ist. Paar Monate.... ja das kommt hin es werden schon ein paar... Erst war es ein Monat, dann kam hier eine Steuerung hinzu, dann da usw. und jetzt der Umstieg auf uCs wodurch ich es freier gestalten kann aber auch umfangreicher wurde.
Florian schrieb: > Bei größeren Herausforderungen wächst dann auch die Motivation es > durchziehen zu wollen Man muss es ja nicht unbedingt auf die härtest-mögliche Art umsetzen, sondern kann sich schrittweise annähern (außer vielleicht man heißt Terry A. Davis). So kommt man auch ans Ziel. Manche würden behaupten, nur so.
Niklas G. schrieb: >> Wehe, Du bringst den STM in den Uploadmodus, bevor der USB-Treiber auf >> dem PC ist. Das hatte ich mit einer komerziellen Fremdentwicklung, das >> Gerät war danach tot und musste per ICP wiederbelebt werden. > Das ist mir noch nie passiert und kann mir auch nicht vorstellen was da > passiert sein soll. Der Bootloader ist im ROM und kann nicht modifiziert > werden. Kein OS sendet an unbekannte Geräte komische Befehle (an > USB-Serial-Ports teilweise schon, aber die STM32-Bootloader melden sich > nicht als solche an). Ich kann Dir nicht sagen, was die Softwerker da getrieben haben. Ich habe das Gerät über mehrere Monate als Tester begleitet, es wurde leider kurz vor Ende eingestellt, weil die Kaufleute keine kurzfristige Amortisation weiterer Kosten wie Gehäuse und externe Zertifizierung rechnen konnten. Es wurde per USB parametriert und auf diesem Wege auch das Softwareupdate angestoßen. Kern war ein STM32L072C8. Niklas G. schrieb: > Frank O. schrieb: >> Dann gibt es die mit 16 >> MHz und USB für ca. 3 Euro. > Die mit USB haben dann einen CH340 drauf? Also das USB geht nicht direkt > an den Controller? Die klassischen Arduinos verwenden ATMega328, der kein USB kann. Auf dem originalen UNO sitzt dafür ein ATMega8U2, auf dem Nano ein FT232. Die Chinesen setzen für beide auf den CH340. Macht in der Funktion keinen Unterschied, da hier nur USB nach Seriell übersetzt wird. Der ProMini kommt ohne USB, führt Rx / Tx des AT328 heraus und braucht dann einen externen USB nach seriell. Es gibt noch den ProMicro mit ATMega32U4, nur der kann direkt mit USB. Florian schrieb: > Du schreibst es doch schon selber, ich will Dinge die mein WISSEN > übersteigen. Was hält mich denn davon ab mir das Wissen anzueignen? Ich > sagte nicht es soll morgen fertig sein. Ich bezweifle das du mit deinem > Wissen geboren wurdest, das hast du dir schön mühselig angeeignet. Vollkommen richtig. Ich wollte Dich nur erinnern, langsam zu starten. Ich zerlege meine Aufgaben in kleine Bröckchen und füge diese dann später zum Gesamtgebilde zusammen. Du hast mir den Eindruck vermittelt, dass Du zuviel auf einmal reißen willst. Kam das wirklich böse rüber?
Niklas G. schrieb: > Man muss es ja nicht unbedingt auf die härtest-mögliche Art umsetzen, > sondern kann sich schrittweise annähern Schrittweise wird es zwangsläufig sowieso, aber kleinere Projekte an denen ich lernen kann hab ich nicht und irgendwas zu basteln nur das ich davon lerne ohne es danach wenigstens zu Testzwecken verwenden zu können... Mir würde nicht mal eine Idee für ein kleines Projekt einfallen. Etwas wie ein Arduino macht für den Anfang tatsächlich am meisten Sinn, das kann man auch für anderes gebrauchen.
Florian schrieb: > Mir würde nicht mal eine Idee für ein kleines Projekt einfallen LED-Blinker, Lauflicht, PWM-Dimmer, "Knightrider"-Lauflicht, analoge Spannungen messen und auf ein LCD ausgeben, Grafik-LCDs ansteuern, Sensoren einlesen (Temperatur, Accelerometer, Luftfeuchtigkeit,...), Kommunikation mit dem PC via UART, Soundausgabe, präzise getimte Signale per Timer ausgeben, mit Buttons und Drehencodern arbeiten, Motoren/Servos steuern, Kommunikation via TCP via WiFi (ESP32), mit den verschachtelten Interrupts der Cortex-M spielen, eigenes RTOS implementieren, Funkmodule z.B. für LoRa ansteuern, eine Uhr mit RTC implementieren, digitale Signalverarbeitung auf Audiodaten, NFC-Tags auslesen, GPS-Tracker, Solar-MPP-Tracker, usw. usf. Der Appetit kommt beim Essen.
Manfred P. schrieb: > Kam das wirklich böse rüber? Böse? NEIN! Ich wollte auch nicht das sich meine Aussage so liest als wäre es das. Manfred P. schrieb: > Ich wollte Dich nur erinnern, langsam zu starten. Ich zerlege meine > Aufgaben in kleine Bröckchen und füge diese dann später zum > Gesamtgebilde zusammen. Du hast mir den Eindruck vermittelt, dass Du > zuviel auf einmal reißen willst. Viel anderes werde ich auch nicht ran gehen. Meine Bröckchen sind meist sogar recht klein, einfach weil ich mich öfter festfahre und keine richtige Lösung mehr finde. Da hilft es dann wirklich nur zu stoppen und wann anders damit weiter zu machen. Ich nehme dann meistens einfach ein fernes anderes Bröckchen was ich brauche und lenke mich damit vom vorherigen ab. Wenn ich dann wieder zurückkehre ist der Kopf dann auch wieder frei (zumindest meistens, ab und zu braucht es auch ein paar Anläufe). Wie gesagt, ich stehe jetzt noch ganz am Anfang, jetzt hab ich noch mehr im Fokus was für ein Gesamtbild es am Schluss ergeben soll. Tut mir leid wenn ich in der Erklärung nicht richtig zu den Einzelschritten differenzieren kann.
Niklas, ich hoffe die ein oder andere Idee der Liste missverstehe ich, aber wenn du zb schreibst Grafik LCD ansteuern... das stell ich mir gerade komplizierter vor als meine ganze Elektronik von dem Projekt zusammen
Florian schrieb: > aber wenn du zb schreibst Grafik LCD ansteuern... das stell ich mir > gerade komplizierter vor als meine ganze Elektronik von dem Projekt > zusammen Manche von den Vorschlägen sind komplex, ja. Bei fertiger Hardware (z.B. 32F429IDISCOVERY) ist die Software aber durchaus machbar und weniger Aufwand als dein Gesamprojekt. Ein Anfängerprojekt ist das aber sicherlich auch nicht. Wenn man die Software fertig hat und ein Gefühl für die Funktionalität hat und auch ein Eval-Board als Vorlage, kann man auch mit einem eigenen Board anfangen. Wenn man Erfahrung mit PCB-Design hat ist das wohl immer noch einfacher als mal eben schnell Kotlin für Android-App-Entwicklung zu lernen...
@Florian: es gibt nur einen Rat, dem man jemand geben kann, der ganz bei Null anfängt. FANG AN! Der bereits mehrfach zitierte "Arduino für 2€" reicht dafür aus, und bevor du nicht verstanden hast, weshalb die LED blinkt, musst du über alles Weitere gar nicht nachdenken. Wenn dich das überfordert, such dir ein anderes Hobby!
Hallo, als ich angefangen hatte mit Mikrocontrollern war einmal diese Seite für mich bedeutungsvoll http://s-huehn.de/elektronik/ und andererseits diese ebenso https://holger-klabunde.de/ . Heute sind das aber alte Hüte, damals war gerade die Ablösung der D-Mark durch unseren geliebten Euro. Für mich fiel damals die Wahl auf den AVR, weil man den so schön über den Parallelport programmieren konnte, auch sehr altmodisch. Also viel Erfolg mit dem neuen Zeug. mfg
Florian schrieb: > Programmiersprache hab ich mir C++ gedacht, wobei ich mir erstmal wieder > die "Vokabeln" aneignen muss. Puh, der Sprung von Gattern und FFs zu C++ erscheint mir doch recht steil. Oder hast Du schon fundierte Vorkenntnisse in Objektorientierung? Florian schrieb: > sondern werde die mit einem Smartphone über USB ansteuern. Für mich besteht der Charme von µCs ja gerade darin, daß die kein riesen Geraffel mit Host usw. brauchen, um ihre Funktion auszuführen. Einfach nur einschalten und schon rennen sie los. Auch ist USB nicht mit I2C, SPI oder UART zu vergleichen. Das USB-Gerät muß erstmal angemeldet werden und dann die passende Applikation gestartet werden. Und bricht die Verbindung ein, stürzt alles ab. Ich habe schon mehrfach Gattergräber durch µCs ersetzt. Einfach um bei den logischen Verknüpfungen flexibel zu sein. Viele Kunden haben ständig Änderungswünsche, da geht keine fest verdrahtete Logik.
Florian schrieb: > Meine Bröckchen sind meist sogar recht klein, einfach weil ich mich > öfter festfahre und keine richtige Lösung mehr finde. > > Wie gesagt, ich stehe jetzt noch ganz am Anfang Nimm wie zigtausende andere Anfänger einen der kleinen Arduinos und beginne mit dem Blinklicht. Der Rest kommt dann von alleine. Und wenn du dann die Grenzen dieses Systems/µC erkennst, dann weißt du auch, anhand welcher Kriterien du einen besser zu den Anforderungen passenden µC auswählen kannst. Florian schrieb: > (Sollte es helfen könnte ich es grob skizzieren). Schaltpläne sind die länderübergreifende Sprache der Elektronik. Da sagt ein Bild mit brauchbarer Beschriftung (Bauteilnamen und Bestellbezeichungen) mehr als tausend Worte. Und hinterher brauchst du den Schaltplan eh', damit du in 2 Jahren noch weißt, was du da wie verschaltet hast. Wenn es nicht zum kompletten Schaltplan reicht, dann reicht auch eine schmatische Skizze. Harry L. schrieb: > FANG AN! Genauso geht das und auch der Rest dieses Posts trifft vollumfänglich zu.
Peter D. schrieb: > Für mich besteht der Charme von µCs ja gerade darin, daß die kein riesen > Geraffel mit Host usw. brauchen, um ihre Funktion auszuführen. Naja, wenn man eine Benutzeroberfläche braucht und ggf. Daten-Import/Export bietet sich die Smartphone-Anbindung schon an, dort kann man unproblematisch komplexe (und auch schöne) GUIs erstellen, das ist auf dem Mikrocontroller mit angebundenem Display schon deutlich mehr Aufwand (und teurer). Ob das dann allerdings USB sein muss und nicht Bluetooth oder WiFi... Peter D. schrieb: > Und bricht die Verbindung ein, stürzt alles ab. Nur während der Enumeration - wenn das Gerät erstmal korrekt angemeldet ist, ist es OK wenn es langsam antwortet. Die Mikrocontroller-Firmware stürzt aber nicht per se davon ab, die kann schon normal weitermachen. Peter D. schrieb: > Viele Kunden haben ständig > Änderungswünsche, da geht keine fest verdrahtete Logik. Ganz genau, auch wenn sein eigener Kunde ist! Lothar M. schrieb: > Da sagt > ein Bild mit brauchbarer Beschriftung (Bauteilnamen und > Bestellbezeichungen) mehr als tausend Worte. Jau, wenn Florian mal einen groben Schaltplan zeigen würde könte man schauen was der Mikrocontroller davon übernehmen kann...
Florian schrieb: > Ich weiß nicht ob ich mit meinen Gedanken so aus der Reihe tanze, aber > wenn ich Begriffe lese die ich genauer betrachten muss nur um daraus > eines zu wählen und der Rest ist zumindest vorerst egal, ja mich > demotiviert das. > Eine Sache zu lernen und damit zu arbeiten für die ich auch eine > praktische Verwendung hab finde ich hingegen sehr motivierend. Meine Motivation war auch eine Idee in die Tat umzusetzen und da musste ein Mikrocontroller her. Erst bei dem Projekt stellte ich fest, dass der Mikrocontroller und onewire die kleinsten Probleme waren. Die Ansteuerung von den Lüftern kannte ich aus meinem Job, auch wenn ich im Job so was nicht bauen muss. Das eigentliche Problem war, ich musste erstmal zum Schimmelexperten werden. Ebenso musste ich das alles berechnen, da es 3 Monate aus einer Batterie funktionieren musste. Kam letztlich nie zum Einsatz, aber da ich das hier diskutiert hatte, so vermute ich zumindest, kamen die Geräte auch teilweise so raus, wie ich das vorgeschlagen hatte. Also es gibt viele verschiedene Hürden. Da muss man dann auch Programme lernen, mit denen man seine Sachen auch fertigen lassen kann. Klar, das kann mit unter Jahren dauern. Und in meinem Fall, ich war jetzt 12 Jahre raus, aus persönlichen Schicksalsschläge, ich lerne immer noch und teilweise sogar Sachen wieder neu, die ich schon wusste. Also ja, es kann ein langer Weg sein.
PS: Das Projekt ist grundsätzlich schon machbar. Viele erfahrene Entwickler könnten das wohl in ein paar Wochen (Vollzeit) hinbekommen, auch mit eigenem PCB, eigener App etc. Aber das sind dann die Leute die seit vielen Jahren genau solche Dinge machen und die ganzen Technologien, Knackpunkte und Baustellen kennen und dort eine gewisse Routine haben. Deswegen sind solche Leute auch teuer - man bezahlt nicht nur für 2 Wochen Arbeit, sondern für 20 Jahre Erfahrung und (Selbst)Studium.
Manfred P. schrieb: > Während Du Deine Platine malst und auf die Lieferung wartet, ist meine > Lochraster schon in Betrieb, Einzelstück Meine Platinen sehen aber schöner aus.😎 mfg Klaus
> Arduino
Mit Arduino lernt man Arduino, aber nicht den Mikrocontroller. Das war
auch die Grundidee des Arduino-Konzeptes: man muss das Datenblatt gar
nicht lesen.
Georg M. schrieb: > Mit Arduino lernt man Arduino, aber nicht den Mikrocontroller. Erstmal Arduino lernen ist trotzdem sinnvoll um ein Gefühl dafür zu bekommen. Man kann auch im Arduino-Code direkt auf Hardware-Register zugreifen um es "richtig" zu lernen. Und man kann auch anderweitig kompilierte Programme, ohne Arduino-Framework, auf den Arduino-Boards nutzen. Ein Schritt nach dem anderen.
Georg M. schrieb: > Das war > auch die Grundidee des Arduino-Konzeptes: man muss das Datenblatt gar > nicht lesen. Falsch, du Arduino Basher. Ziel ist ein leichter/einfacher Einstig, niederschwellig, von ca. 10 bis 100 Jahren. Für Bäcker, Schüler, Bauer und viele weitere. Wie tief man sich dann da rein buddelt, bleibt jedem selber überlassen. Übrigens, ohne Datenblatt kommt man auch ohne Arduino nicht weit. Niklas G. schrieb: > Arduino-Code C, C++ und Assembler Hauptsächlich C++
Florian schrieb: > Ich könnte mich da schon selbst einlesen, werde ich natürlich auch im > Verlauf, aber das dauert einige Tage und meine begrenzten > Englischkenntnisse beschleunigen das auch nicht gerade. Man kann sich ja auch mit der Artikelsammlung hier beschäftigen, oder mit den Projekt-Vorstellungen oder auch mit den Physik-Projekten von stoppi.
Arduino F. schrieb: > Übrigens, ohne Datenblatt kommt man auch ohne Arduino nicht weit. Words of wisdom.
Georg M. schrieb: > Mit Arduino lernt man Arduino, aber nicht den Mikrocontroller. Man lernt in der Fahrschule auch ein wenig über die Technik im Auto. Klar, die wenigsten werden eine Kopfdichtung tauschen können, aber es gibt doch schon viele, die solche einfachen Arbeiten, wie Bremsbeläge ersetzen, sich dann aneignen. Ohne Arduino würde ich heute hier nicht schreiben. Und da ich quasi 12 Jahre raus war, sehe ich doch sehr deutlich den Unterschied zu damals. Arduino ist mittlerweile von den meisten akzeptiert und stark verbreitet. Die ewige gestrigen Leute, sind nur in ihrem Fachgebiet so und klammern sich mit aller Macht an dieses vermeintliche Alleinstellungsmerkmal und merken durch ihre Scheuklappen gar nicht, dass sie längst überholt wurden. Und zu Hause schalten sie bequem den Fernseher per Fernbedienung um, wo man doch alles zu Fuß machen sollte. Der Mensch ist grundsätzlich pragmatisch veranlagt und sucht daher immer nach der naheliegenden Lösung. Außerdem ist dieser Weg zwar von Arduino beschritten worden, aber mit Cube und was es da sonst gibt, geht es weiter. Durch die KI wird sicher in absehbarer Zeit nur noch dem Computer erzählt, was das Programm machen soll und wahrscheinlich "versteht" der Mikrocontroller bald selbst, was er für dich tun soll. Am Ende ist eines jedoch sicher. Wenn dein Gerät wunderbar funktioniert, kannst du es von außen nicht sehen, ob so ein Arduino-Depp, wie ich oder so ein hoch intelligenter Assembler Spezi das programmiert hat. Ist das nicht wirklich schade?
Florian schrieb: > begrenzten Englischkenntnisse Da ist irgendwie noch keiner drauf eingegangen - für sehr viele Themen gibt es ausschließlich englische Texte. Deutsche Texte sind meist eher Zusammenfassungen/Tutorials. Ohne Englisch wird das also ziemlich sicher nichts. Am Besten versucht man direkt die englischen Originaltexte zu lesen, und wenn man was nicht versteht bemüht man eine der mittlerweile vielen guten (KI-)Übersetzungsapps. So lernt man die Texte selbst zu verstehen. Sich nur auf deutsche Literatur zu verlassen funktioniert nur sehr begrenzt. Vieles ist sowieso nicht von Muttersprachlern geschrieben und daher eher einfach strukturiert. Frank O. schrieb: > ob so ein Arduino-Depp, wie ich oder > so ein hoch intelligenter Assembler Spezi Tja, eine Menge sehr clevere Leute die nicht nur das bisschen Assembler können sondern sich auch mit den wirklich knackigen Details der Hardware auskennen (Pipeline-Verhalten, Cache-Konfiguration, SIMD-Erweiterungen, branch prediction, out-of-order execution, speculative execution, microcode, Silicon-Bugs, Multicore-Systeme und deren Cache-Kohärenz und inter-processor-communication, memory barriers, Scheduler&Threadsynchronisation für SMP, Atomics, Portable Speichermodelle, Energieverbrauch der Software, massiv parallele Architekturen wie GPUs, Side-Channel-Attacks, Optimierung der Software um diese Dinge so effizient wie möglich auszunutzen) nutzen trotzdem auch ganz entspannt High-Level-Frameworks wie Arduino und Hochsprachen. Weil das für viele Zwecke einfach am Schnellsten geht. Der eigentliche Depp ist der, der alles in Assembler schreibt!
H. H. schrieb: > Woz? Hat vor einem halben Jahrhundert (!) BASIC für den Apple I implementiert. Aber nicht in Assembler, sondern manuell im Maschinencode. Wahrscheinlich hatter er zu dem Zeitpunkt schlicht keine andere Wahl. C gab es erst nur für die PDPs und UNIX. Gab es für den dann brandneuen 6502 überhaupt Hochsprachen außer dem dann so implementierten BASIC (Henne-Ei-Problem), und hätte die frisch gegründete Firma Apple da überhaupt das Kleingeld für gehabt? Man implementiert auch sicherlich keine neuen Programmiersprachen wenn man der Meinung ist man solle alles in Assembler/Maschinencode schreiben... Die Kryptowährung seiner aktuellen Firma und deren Website ist bestimmt auch nicht ausschließlich in Assembler implementiert. Heute, Äonen später, gibt es exzellente Compiler für leistungsfähige Hochsprachen, die man einfach so gratis herunterladen und auf einem Supercomputer im Hosentaschenformat, den man fast nachgeworfen bekommt, ausführen kann, statt dafür einen kühlschrankgroßen Computer und das dazugehörige Betriebssystem zum Gesamtpreis eines Einfamilienhauses erwerben zu müssen. Da muss man nicht mehr nach den gleichen Mustern arbeiten.
Hi Niklas G. schrieb: > Man implementiert auch sicherlich keine neuen Programmiersprachen wenn > man der Meinung ist man solle alles in Assembler/Maschinencode > schreiben... Bitte, nicht Maschinencode und Assembler gleichsetzen. Assembler ist gegenüber Maschinencode schon eine Hochsprache. Damit Maschinencode einigermaßen lesbar war, wurde er in Hex-Code geschrieben. Also Byteweise so wie C9h. Binär ist das "11001001" und das ist Maschinencode. Ich glaub, das war beim Z80 ein Return. Ist schon lange her.. In Assembler steht da aber RET. So, nu aber Klugscheißermodi aus. Gruß oldmax
Martin V. schrieb: > Bitte, nicht Maschinencode und Assembler gleichsetzen. Assembler ist > gegenüber Maschinencode schon eine Hochsprache. Die übliche Definition von Hochsprache schließt Assembler ziemlich eindeutig aus. Assembler und Maschinensprache kann man schon in eine Kategorie stecken, weil man in beiden Fällen Ausdrücke ausrollen, Registerzuweisung, Stack-Verwaltung selber machen muss, in Hochsprachen aber nicht. Maschinencode und Assemblercode lassen sich eindeutig 1:1 in beide Richtungen abbilden, Maschinencode mit Hochsprachen wie C jedoch keineswegs.
Niklas G. schrieb: > Maschinencode und Assemblercode lassen sich eindeutig 1:1 in > beide Richtungen abbilden, Falsch. Es gibt Assembleranweisungen, die überhaupt keinen Code generieren, sondern z.B. ein Symbol definieren, eine andere Datei inkludieren, o.ä.. Viele Prozessorarchitekturen beinhalten keine expliziten NOP-Instruktion. In solch einem Fall wird ein "ungefährlicher" Befehl, der weder Register noch Flags ändert, als NOP-Ersatz genutzt. Bei klassischem ARM wäre das z.B. "ANDEQ R0, R0, R0". Ein Disassembler wird aber niemals daraus NOP generieren. Dann gibt es Pseudo-Instruktionen, die der Assembler ggf. in mehrere Einzelinstruktionen auflöst, z.B. ADR, und das auch noch abhängig von dem jeweiligen Adresswert. Ein Disassembler würde diese Anweisungen natürlich auch niemals wieder zu einem ADR zusammenfassen, weil er gar nicht weiß, dass es sich um die Kurzform für eine Adressierung handelt. Weiterhin gibt es bei vielen Prozessoren ungültige Instruktionen, für die es dementsprechend keine Assembler-Äquivalente gibt. Diese werden teilweise auch explizit genutzt, um Exceptions auszulösen.
Niklas G. schrieb: > Martin V. schrieb: >> Bitte, nicht Maschinencode und Assembler gleichsetzen. Assembler ist >> gegenüber Maschinencode schon eine Hochsprache. > > Die übliche Definition von Hochsprache schließt Assembler ziemlich > eindeutig aus. Assembler und Maschinensprache kann man schon in eine > Kategorie stecken, weil man in beiden Fällen Ausdrücke ausrollen, > Registerzuweisung, Stack-Verwaltung selber machen muss, in Hochsprachen > aber nicht. Maschinencode und Assemblercode lassen sich eindeutig 1:1 in > beide Richtungen abbilden, Maschinencode mit Hochsprachen wie C jedoch > keineswegs. Als ich vor vielen, vielen Monden angefangen hatte, gab es für meinen zweiten 'puter — KIM-1 — zunächst einmal nur Maschinensprache. Das heißt, ein detailliertes Handbuch von MOS Technology und ein Quick Reference Kärtchen mit 57 Befehlen/Mnemonics in der Y-Achse und 13 Adressierungsarten in der X-Achse. Gefüllt war die Tabelle mit entsprechenden Hex-Codes. Selbst Jumps und Branches durfte man selbst ausrechnen. Von Hand wurde auf auf Papier kodiert und Cut'n'Paste wurde tatsächlich mittels Schere wörtlich genommen. Da lernt man es richtig und versteht jedes, aber auch wirklich jedes einzelne Bit im System. Der erste Assembler war wie der Eintritt in eine neue, bequeme, komfortable Welt. Es fühlte sich damals zumindest fast wie eine Hochsprache an.
Andreas S. schrieb: > Falsch. Ich habe in meinen obigen Beispielen sogar Pseudo-Instruktionen und Labels genutzt. Es stimmt zwar dass das Mapping nicht 100% exakt ist, aber es ist dennoch konzeptuell sehr nah aneinander. Wenn der Unterschied zwischen Assembler und C so wie der zwischen einer grauen Katze und einem Krokodil ist, dann ist Maschinensprache die schwarze Katze. Rein technisch nicht das Gleiche wie eine graue Katze, aber in der Gesamtperspektive doch schon sehr nah dran. Außerdem gelten die Argumente für Maschinencode und Assembler sowieso gleichermaßen, bei beiden macht es keinen Sinn sie für ganze große Projekte zu nutzen: Wenn man einen BASIC-Interpreter in Maschinensprache schreibt, macht man das nicht weil man der Auffassung ist man solle alles in Assembler schreiben.
Andreas S. schrieb: > Falsch. Nein. > Es gibt Assembleranweisungen, die überhaupt keinen Code generieren, > sondern z.B. ein Symbol definieren, eine andere Datei inkludieren, o.ä.. Das sind dann keine echten Assembler-Anweisungen, das andere Sachen. Z.B. Labels und Direktiven. Beides gibt es in ähnlicher Form und Funktion auch in vielen "Hochsprachen". > Viele Prozessorarchitekturen beinhalten keine expliziten > NOP-Instruktion. In solch einem Fall wird ein "ungefährlicher" Befehl, > der weder Register noch Flags ändert, als NOP-Ersatz genutzt. Bei > klassischem ARM wäre das z.B. "ANDEQ R0, R0, R0". Ein Disassembler wird > aber niemals daraus NOP generieren. Das sind dann Macros. Die funktionieren natürlich nur Vorwärts. Das ist der Punkt. Auch diese Sache findet man genauso bei vielen "Hochsprachen". Ja mehr noch: viele Hochsprachen sind im Kern sogar nix anderes als eine riesige Ansammlung äußerst komplexer Macros. > Dann gibt es Pseudo-Instruktionen, die der Assembler ggf. in mehrere > Einzelinstruktionen auflöst Auch nur Macros. > Weiterhin gibt es bei vielen Prozessoren ungültige Instruktionen, für > die es dementsprechend keine Assembler-Äquivalente gibt. .DB/.DW/.DD <ungültiger Opcode> ist das Assembler-Äquivalent. Das kann man natürlich auch in mehr oder weniger sinnfällig benannten Macros verstecken. Zusammenfassend hast du eigentlich dargestellt, was ein "purer" Assembler alles nicht tun sollte. Aber natürlich tun die meisten (guten) Assembler solche Sachen. Weil es halt den "Vorwärtsweg" (also die Programmierung) vereinfacht. Der Extremfall eines solchen Macro-Assemblers ist übrigens ein C-Compiler...
Niklas G. schrieb: > H. H. schrieb: >> Woz? > > Hat vor einem halben Jahrhundert (!) BASIC für den Apple I > implementiert. Aber nicht in Assembler, sondern manuell im > Maschinencode. Mit einem Cross Assembler auf einer PDP-8. Und der wurde schnell auf 6502 portiert...
H. H. schrieb: > Mit einem Cross Assembler auf einer PDP-8. Und der wurde schnell auf > 6502 portiert... https://www.apple2history.org/museum-a-l/articles/ca8610/#:~:text=I%20had%20no%20assembler%2C%20that,was%20available%20in%20time%2Dshare. > I had no assembler, that was another thing. To use an assembler, they figured that somebody was going to buy this processor to use for a company, and their company can pay a few thousand dollars in time-sharing charges to use an assembler that was available in time-share. I didn’t have any money like that, so a friend taught me that you just sort of look at each instruction, you write your instructions on the right side of the page, you write the addresses over on the left side, and you then look up the hex data for each instruction – you could assemble it yourself. Wer sich keinen Assembler leisten konnte, konnte wohl auch keine PDP-8 kaufen.
Niklas G. schrieb: > PDP-8 kaufen. Musste man nicht. Konnte man stundenweise nutzen, gegen recht kleines Geld.
Hi Martin V. schrieb: > Bitte, nicht Maschinencode und Assembler gleichsetzen. Assembler ist > gegenüber Maschinencode schon eine Hochsprache. Nun muss ich mich doch mal selbst zitieren.. Also, wer lesen kann, der sollte auch erkennen, das ich nicht davon sprach, Assembler sei eine Hochsprache, sondern gegenüber Maschinenode. C ist auch kein Basic oder Pascal oder Java oder wie sie alle heißen. Einzig das Verständnis, wie man ein Programm schreibt ist allen Sprachen gemeinsam. Man nimmt die Sprache, die der Maschine gerecht wird und die zu einem mehr oder weniger schnellen Ergebnis führt. Weitere Kriterien sind Lesbarkeit, Portierbarkeit und Programmpflege Es macht überhaupt keinen Sinn irgendeine Sprache zum "Non plus Ultra" zu erklären. Wenn in einer Softwareschmiede mit C gearbeitet wird, macht es keinen Sinn, Pascal zu favorisieren, nur weil man das kann, C aber nicht. Will man da arbeiten, muss man C lernen oder gehen. So einfach ist das. Und wird Assembler verlangt trifft das genauso zu wie die Vorgabe einer x-beliebigen anderen Sprache. Ich kann ja auch nicht nach Timbuktu reisen und erwarten, das dort meine Sprache gesprochen wird. Aber wenn ich noch ein paar Jährchen lebe, habe ich vielleicht ein Smartphone, was simultan übersetzen kann.... Programmieren könnte dann evtl. auch so gehen: "mach, das das geht" Gruß oldmax
Hallo Mit deinen Hintergrund wird der Hardwareanteil bzw. das Verständniss der Erklärungen dazu kein Problem sein, - war es bei mir auch nicht. Aber: Gerade weil du in Logikschaltungen wohl sehr fit bist und das denken dahinter verstehst ist die Gefahr groß das du zu "zu" Hardwarenah programmieren willst. Das funktioniert mit den meisten im µC Bereich "heute" eingesetzten Programmiersprachen nicht, da sie "zu" Universell (Hochsprache...) sind und im Hintergrund dafür gesorgt wird das der jeweilige genaue µC alles richtig "Übersetzt" bekommt - natürlich nur insoweit wie es die Hardware hergibt. Viele Funktionalitäten (eigentlich alle) sind schon von irgendjemanden fertig Programmiert und liegen dann als vorgefertigte "Blöcke" (in Bibliotheken - Librarys- vor). Du brauchst sie dann "nur" noch aufzurufen und Parameter zu setzen - die Anführungsstrich kommen aber nicht von Ungefähr denn so einfach ist das im Einzellfall nun leider auch nicht. Das ist einerseits Praktisch, andererseits aber -zumindest meiner Erfahrung nach - zu Anfang verwirrend und enttäuschen für Leute die aus der reinen Hardware kommen und eigentlich alle Details verstehen und nachvollziehen wollen. Eben das "verstecken" des eigentlichen Kern und was da Bit für Bit geschieht ist für jemanden der aus der reinen Hardware kommt unbefriedigend - besonders wenn es nicht funktioniert wie gedacht und man eigentlich anhand des Datenblatts eines Hardwaremoduls (eines Treiber ICs, eines Displays,...) man gezielt "nachmessen" oder ein bestimmtes Bit setzen möchte... Erst später wenn es um das eigentliche "Produkt" geht erkennt man die Vorteile solcher fertigen Softwaremodule, den verstecken von Details usw. Falls die jetzt schon verwirrt bist mit den komischen Begriffen die du im Alltag aus ganz anderen Zusammenhängen kennst: Willkommen in der ganz eigenen "Programmierwelt". Das Denken und die Logik dahinter muß man erst mal (generell) verstehen Lernen. Bibliotheken, Klassen Funktionen usw. haben wenig bis gar nichts mit dem zu tun woher man als "Normalo" und den Alltag diese Begriffe kennt, des weiteren werden sie mal dafür und mal dafür verwendet - was man aber erst mit der Zeit erkennt und sauber unterscheiden kann. Auch gibt es (auch auf englisch) keine wirklich guten und eingängigen Erklärungen und Anleitungen wie man Programmiert. Da wird dann automatisch davon ausgegangen das du weist was Ganzzahlen sind, was "jetzt in diesen Augenblick, an dieser einen Stelle" eine Funktion ist, was mit Modular gemeint ist, was ein Parameter ist, was ein Array ist und vieles andere - wesentlich verzwickteres mehr... Und wenn du (man) es einmal verstanden hast -irgendwann macht es einfach "Klick und alles hat seinen Sinn- erkennt man warum es keine guten und eingängigen Erklärungen geben kann: Das ganze Denken, die ganze Logik, die Sprache hinter den Programmieren (generell, das hat überhaupt nichts mit µC speziell zu tun) ist einfach zu anders, zu abstrakt um diese klar und einfach zu vermitteln. Es ist ein klein wenig wie Mathematik die so ab der 8 Klasse gelehrt wird: Ohne die Grundlagen und (leider in der Schulmathematik) ohne Praktische Anwendungen versteht man Null, ist es zu Allgemein, zu abstrakt. Leider gibt es aber bei Programmieren, so wie es gelehrt wird, nicht die Klassen 1-7 oder ein Allgemeinwissen und die Abstraktion (alles Universell halten - aber "ich" möchte doch nur diesen einen µC Programmieren, oder wenigstens das Arduinoskript 100% verstehen...) ist tendenziell noch höher als in der Schulmathematik der hohen Jahrgänge... Das waren zumindest meine Probleme und Fallstricke beim programmieren lernen. Hardware: Einfach, Interessant, nachvollziehbar, hat ihre nachvollziehbare Logik, wird "überall" gut auch für absolute Noobs erklärt. Software, "Programmierdenke": Häähh, wat will "der"? Was hat da eine Bibliothek (da leiht man doch Bücher und Filme aus), eine Klasse (da war ich zum letzten mal vor 40 Jahren drin) usw. zu suchen? Was meint "der" nun mit Funktion? - Einmal ist das dies, einmal jenes und bei Vollmond noch was ganz anderes... Objekt...? Hähh geht es jetzt ums Häuslebauen. Literal? Was stotterst du rum, Linguistikprofessor rede mal deutsch!? usw. usw. Da muß man leider(!) durch und eigenes unverständnis oft erst mal einfach ignorieren bzw. viele Quellen (und auch Videos - ja die hier oft ach so negativ dargestellte Youtubevideos, Text ist eben nicht alles und wir haben nicht mehr 1984) nutzen. Wie schon gesagt: Irgendwann macht es von einen zum anderen Augenblick Klick und "alles" hat seinen Sinn und innere Logik - und ist eigentlich doch "Ganz einfach", aber einen anderen Programmieranfänger das dann alles gut verständlich in klarer Alltagssprache erklären: Es geht nicht, man wird den gleichen (scheinbaren) Mist von sich geben an dem man selbst erstmal verzweifelt war.
Darius schrieb: > zu Anfang verwirrend und enttäuschen für Leute die aus der reinen > Hardware kommen Zum Glück kann er schon programmieren, sogar C++, also alles kein Problem. Darius schrieb: > Auch gibt es (auch auf englisch) keine wirklich guten und eingängigen > Erklärungen und Anleitungen wie man Programmiert. Es gibt Unmengen an guten Büchern, Tutorials, Kursen, und natürlich auch das gute alte Studium, sogar Schulunterricht. Allerdings muss man hier im Bereich der klassischen (PC-) Programmierung schauen. Die Embedded Welt hat's nicht so mit "gut programmieren (lernen)". So konnten schon Generationen an Programmierern es Schritt für Schritt lernen. Das auf einen Mikrocontroller zu übertragen ist dann kein großes Ding mehr. Darius schrieb: > Da wird dann automatisch davon ausgegangen das du weist was Ganzzahlen > sind Das lernen die meisten ja auch schon früh in der Schule. Die Denkweise beim Programmieren/Informatik ist stark von der Mathematik geprägt. Wenn man sehr schlecht in Mathematik ist wird es mit Programmieren auch schwierig. Aber wer Schulmathematik geschafft hat, schafft das dann auch. Darius schrieb: > Objekt...? Hähh geht es jetzt ums Häuslebauen. Viele Leute, die vorher Null mit Hardware oder Informatik zu tun hatten, haben keine Probleme damit, solche Abstraktionen wie objektorientierte Programmierung zu lernen. Es ergibt sich intuitiv. Man darf es halt nicht sofort mit Hardwaredetails in Verbindung bringen. Wenn man das abstrakte Modell beherrscht kann man sich anschauen was der Compiler draus macht, und dann macht es alles Sinn. Totalen Anfängern würde ich sowieso eher Python nahe legen. Da kann man sehr einfach die grundlegende Denkweise begreifen, und wenn man dann später C++, Arduino, Embedded lernen will hat man es viel einfacher. Es ist wie beim Fahrrad fahren lernen: Früher hat man Kindern Fahrräder mit Stützrädern gegeben. Da haben sie zwar gelernt in die Pedale zu treten, aber das ist sowieso der einfache Teil. Aber sie lernen nicht ein Zweirad zu balancieren, sondern ein Zwei(drei?)spuriges Fahrzeug zu steuern, was ganz anders funktioniert. Wenn sie dann auf ein Fahrrad umsteigen, müsssen sie das wieder ent-lernen und das wichtigste, das Balancieren, neu lernen. Viel besser ist es, mit einem Laufrad zu lernen, also ein Zweirad ohne Pedale/Antrieb. Dort lernt man ganz intuitiv, ohne explizit nachzudenken, das Rad aufrecht zu halten. Also die richtige Denkweise, ohne sich mit den technischen Details von Pedal, Kette, Gangschaltung auseinander zu setzen. Geht man zu logisch dran, ist Zweirad fahren widersinnig: Man muss nach links lenken, um nach rechts zu fahren ("Countersteering"). Kein Kind denkt darüber nach, sondern macht es sofort intuitiv richtig. Danach setzt man das Kind auf ein richtiges Fahrrad, erklärt die Pedale und es kann ohne Ängste schnell richtig fahren. Für reine Motorradfahrer scheint gerade das Countersteering ein großes Mysterium zu sein, man sieht gelegentlich wie sie Probleme damit haben, oder sie zu sehr darüber nachdenken - wären sie mal vorher Laufrad gefahren, dann könnten sie es intuitiv. Genau so muss man es mit dem Programmieren machen: Alles über Hardware, Flipflops, Logikgatter, CPUs, Speicher vergessen. Die mathematischen Grundlagen in Erinnerung rufen. Abstrakt und intuitiv Grundrechenarten umsetzen, Abläufe und Kontrollfluss verstehen, später OOP dazu. Vollkommen ignorieren was im Hintergrund passiert. Das geht super in Python oder Java. Wenn man das beherrscht und auf C++ umsteigt kommt vieles bekannt vor und dann kann man sich ansehen was da im Detail passiert. Das dann auf Mikrocontroller zu übertragen ist dann nur noch ein kleiner Schritt. Aber glücklicherweise kann der TO ja schon programmieren.
Seit ich das letzte mal geschrieben hab wurde hier recht viel geschrieben, hatte die letzten Tage leider nicht die Möglichkeit hier wirklich was zu schreiben. @Niklas das mit dem Englisch ist zb wirklich, naja... Es ist zwar nicht so das ich gar nichts verstehen würde, aber zb ein Datenblatt zu lesen und alle paar Zeilen wieder Wörter zu kopieren um sie zu übersetzen ist schon sehr mühselig. Niklas G. schrieb: > Zum Glück kann er schon programmieren, sogar C++, also alles kein > Problem. Doch, etwas schon. Ja, programmiert hab ich schon, die Logik dahinter ist auch kein Problem die Sprache (Vokabeln) hingegen schon. Seh ich einen einen fertigen Quellcode versteh ich den mit Leichtigkeit, wenn ich einzelne Begriffe nicht kenne ergibt sich das ja aus dem Kontext. Ein kleines einfaches Teilstück von meiner Steuerung versuche ich gerne auf einem Nano zu programmieren, das ist schon mühsam. Hardwarenäher zu arbeiten wäre schon leichter, da wäre ich mit dem kleinen Baustein in ein paar Minuten fertig. Vielleicht bietet mir das Programmieren aber auch die Chance allgemein mit Sprachen fitter zu werden. Programmiersprache ist ja doch weniger komplex. Niklas G. schrieb: > Es ist wie beim Fahrrad fahren lernen: Früher hat man Kindern Fahrräder > mit Stützrädern gegeben. Da haben sie zwar gelernt in die Pedale zu > treten, aber das ist sowieso der einfache Teil. Aber sie lernen nicht > ein Zweirad zu balancieren, sondern ein Zwei(drei?)spuriges Fahrzeug zu > steuern, was ganz anders funktioniert. Das ist aber ein grundsätzliches Problem, hat man ein Prinzip gelernt versucht man möglichst immer nur damit zu arbeiten. Man kennt es, man weiß wie es funktioniert und man fährt sich schnell darauf fest. Der Mensch versucht immer das zu nutzen was er bereits kennt. Andere Herangehensweisen anzunehmen ist immer eine Überwindung und Herausforderung. Niklas G. schrieb: > Aber glücklicherweise kann der TO ja schon programmieren. Ansich wie gesagt ja, es ist aber schon lange her. Jetzt muss ich erstmal (wieder) in Übung kommen, es zur Routine werden lassen damit ich nicht bei jedem zweiten Befehl nachschauen muss wie das Wort dafür heißt. Niklas G. schrieb: > Das geht super in Python oder Java. Beide hab ich mir noch nie angeschaut, Java kenn ich auch nur vom Namen. War deren, ich nenn es mal Wortschatz, nicht noch umfangreicher? Das wäre dann aber nur für die was, die komplett neu in die Materie einsteigen und sich weniger mit der Hardware befasst haben, also noch nicht in das "Hardware-Denken" drin sind, oder?
Florian schrieb: > aber zb ein Datenblatt zu lesen > und alle paar Zeilen wieder Wörter zu kopieren um sie zu übersetzen ist > schon sehr mühselig. Das schleift sich mit der Zeit schon ein, schnell lernt man die Dinge. Und die meisten Begriffe sind sowieso Fachbegriffe die kein deutsches Äquivalent haben, die muss man sowieso lernen. Ohne Datenblätter und Spezifikationen im Original lesen zu können wird das Vorhaben definitv nichts. z.B.: - STM32G4 Reference Manual: > 2000 Seiten - USB Basis-Spezifikation: > 600 Seiten - USB Type-C Spezifikation: > 400 Seiten - ARMv7M Architecture Reference Manual: > 800 Seiten Natürlich liest man das nicht vollständig, sondern immer nur punktuell. Aber man muss sich definitiv zurecht finden können. Und niemand hat all das in hinreichender Qualität übersetzt. Florian schrieb: > Hardwarenäher zu > arbeiten wäre schon leichter, da wäre ich mit dem kleinen Baustein in > ein paar Minuten fertig. Mit was für einem Baustein? Wenn du den nennst kann man die Komplexität besser einschätzen... Florian schrieb: > Der > Mensch versucht immer das zu nutzen was er bereits kennt. So ist es, daher auch die ausführlichen Diskussionen hier... Florian schrieb: > War deren, ich nenn es mal Wortschatz, nicht noch umfangreicher? Von den hier genannten Sprachen an sich ist C++ (mit Abstand) die komplexeste. Java ist vielleicht etwas komplexer als Python. Aber: Java kommt mit einer riesigen Standardbibliothek mit vorgefertigten Funktionalitäten die man sehr einfach nutzen kann, aber natürlich schaut man sich dabei immer nur die an die man braucht, den Rest kann man ignorieren. Die Standardbibliothek von Python ist kleiner, aber es gibt eine Unzahl an zusätzlichen Bibliotheken die man sehr leicht integrieren kann. Für viele Anwendungen kommt man mit Python am Einfachsten ans Ziel, weil es einem sehr viele Dinge abnimmt und man sich nicht um jedes Detail selber kümmern muss. Florian schrieb: > Das > wäre dann aber nur für die was, die komplett neu in die Materie > einsteigen und sich weniger mit der Hardware befasst haben, also noch > nicht in das "Hardware-Denken" drin sind, oder? Naja, wenn du "richtig" programmieren lernen willst anstatt nur einmal was zusammen zu tüdeln wäre Python schon empfehlenswert. Da du aber schon C++ kannst und nicht über Grundbegriffe stolperst, kannst du abkürzen und direkt die C++ Kenntnisse vertiefen. Das machst du am Besten am PC, ganz ohne Mikrocontroller. Wenn du da sattelfest bist kannst du das auf Mikrocontroller übertragen.
Niklas G. schrieb: > Das schleift sich mit der Zeit schon ein, schnell lernt man die Dinge. > Und die meisten Begriffe sind sowieso Fachbegriffe die kein deutsches > Äquivalent haben, die muss man sowieso lernen. Bei manchen Dingen könnte ich meinen ich sei lernresistent. Niklas G. schrieb: > STM32G4 Reference Manual: > 2000 Seiten > USB Basis-Spezifikation: > 600 Seiten > USB Type-C Spezifikation: > 400 Seiten > ARMv7M Architecture Reference Manual: > 800 Seiten > > Natürlich liest man das nicht vollständig, sondern immer nur punktuell Was für Wälzer das sind hab ich beim Stöbern mittlerweile gesehen. Glücklicherweise sind die Inhaltsverzeichnisse mittlerweile soweit alle verlinkt das man gleich auf die entsprechenden Seiten springt und man nicht selbst danach suchen muss. Niklas G. schrieb: > Java kommt mit einer riesigen Standardbibliothek mit vorgefertigten > Funktionalitäten die man sehr einfach nutzen kann, aber natürlich schaut > man sich dabei immer nur die an die man braucht, den Rest kann man > ignorieren. Die Standardbibliothek von Python ist kleiner, aber es gibt > eine Unzahl an zusätzlichen Bibliotheken die man sehr leicht integrieren > kann. Für viele Anwendungen kommt man mit Python am Einfachsten ans > Ziel, weil es einem sehr viele Dinge abnimmt und man sich nicht um jedes > Detail selber kümmern muss. Das ist es aber eher was ich meine. Bibliotheken vereinfachen zwar die Handhabung, die Schreibarbeit wird geringer, aber ich schreibe lieber etwas länger als das ich mich durch Bibliotheken und deren Aufruf quälen muss Niklas G. schrieb: > Da du aber schon C++ kannst Ich weiß was du damit meinst und dabei geb ich dir auch Recht. Das "Prinzip" kenn ich, können würde ich es aber nicht nennen. Ein Programm kann ich nicht schreiben wenn ich zwar weiß welchen Befehl ich brauche ihn aber nicht aufrufen kann, weil ich seinen "Namen" nicht kenne. Niklas G. schrieb: > Das machst du am Besten am PC, ganz ohne Mikrocontroller. Wenn du da > sattelfest bist kannst du das auf Mikrocontroller übertragen. Das mach ich auch, ein bisschen herumspielen kann ich so, damit ich ein bisschen Übung sammel, aber bevor ich einen uC programmieren kann muss ich erstmal meine Vokabeln festigen. Niklas G. schrieb: > Mit was für einem Baustein? Wenn du den nennst kann man die Komplexität > besser einschätzen... Hätte ich fast vergessen zu schreiben. Ich wollte da ein einfaches Lauflicht aus 3-4 LEDs programmieren. Erste LED an, nach beispielsweise 0.5 Sekunden die zweite usw. und nach einer kurzen Verzögerung nachdem alle an sind sollen sie abschalten, danach startet es wieder neu. Viel ist es also wirklich nicht.
Florian schrieb: > Hätte ich fast vergessen zu schreiben. Ich wollte da ein einfaches > Lauflicht aus 3-4 LEDs programmieren. Erste LED an, nach beispielsweise > 0.5 Sekunden die zweite usw. und nach einer kurzen Verzögerung nachdem > alle an sind sollen sie abschalten, danach startet es wieder neu. Viel > ist es also wirklich nicht. Warum machst Du es denn nicht? 15 Euro opfern, einfach mal Arduino-Uno kaufen und loslegen – der Rest oder das Gefühl für weitere Vorgesehensweise ergibt sich dann schon im Laufe der Zeit, wichtig ist nur, dass man den Anfang macht. Man kann auch einen nackten ATMEGA in PDIP nehmen und ihn mit ein paar Teilen selbst zum Leben erwecken – also komplett ohne Arduino, man braucht dann aber noch ein Programmiergerät für den Chip. Die IDE (z.B. Atmel/Microchip Studio) in ihrer finalen Version ist kostenlos und beinhaltet/unterstützt quasi alle gängigen AVRs. Der Thread ist mittlerweile ziemlich lang – nur vom Labern oder Labern lassen (wie so oft teilweise sinnbefreit oder völlig absurd in diesem Forum) wird nichts kommen bzw. am Ende etwas Brauchbares auf dem Arbeitstisch entstehen, denn man muss schon tätig werden, es real und nicht nur als Gedankenspiel machen.
Gregor J. schrieb: > Der Thread ist mittlerweile ziemlich lang – nur vom Labern oder Labern > lassen (wie so oft teilweise sinnbefreit oder völlig absurd in diesem > Forum) wird nichts kommen Genau das gleiche denke ich auch die ganze Zeit. Mehr als 120 Posts für sowas 😂 Gregor J. schrieb: > Warum machst Du es denn nicht? 15 Euro opfern Und wenn ihm das noch zu viel ist soll er für die Hälfte 2 Pi Pico kaufen und kann gleich noch einen als Debugger flashen. Mit VS Code / PlatformIO geht das mittlerweile echt gut. Aber für seine Aufgabe mit dem Lauflicht tut es erstmal jeder uC der genug Pins hat.
Florian schrieb: > aber ich schreibe lieber > etwas länger als das ich mich durch Bibliotheken und deren Aufruf quälen > muss Etwas gefährliche Ansicht, die Autoren von Bibliotheken (insbesondere der Standard-Bibliotheken) haben oft sehr viel Arbeit hinein gesteckt diese stabil und umfassend umzusetzen. Das selbst in ähnlicher Qualität nachzubilden wäre ein absurder Aufwand. Eine Bibliothek für ein Datenformat (z.B. PDF oder ZIP oder XML...) kann locker Zigtausend Zeilen enthalten, das baust du nicht mal eben nach. Die Aufrufe sind (gerade bei Standardbibliotheken) gut dokumentiert und damit hast du es ruckzuck erledigt. Im Embedded-Umfeld sind (große) Bibliotheken weniger verbreitet, aber z.B. für Protokollstacks (TCP/IP) durchaus relevant. Das macht man auch nicht mal so schnell selbst. Dinge wie USB oder das SD-Karten-Protokoll kann man so gerade noch selber machen, aber mit Bibliothek geht es viel schneller. Insbesondere wenn man mit den Details des jeweiligen Systems nicht absolut vertraut ist, in der Dokumentation/Spezifikation muss man da teilweise zwischen den Zeilen lesen. Die Bibliotheksautoren haben diese Dinge schon erledigt. Florian schrieb: > Ein Programm > kann ich nicht schreiben wenn ich zwar weiß welchen Befehl ich brauche > ihn aber nicht aufrufen kann, weil ich seinen "Namen" nicht kenne. Dann hilft nur: Üben, üben, üben. Am Besten auf dem PC. Du kannst dir jetzt sofort eine Entwicklungsumgebung (z.B. Visual Studio Community Edition) herunterladen und anfangen. Es gibt viele Tutorials, gute sind allerdings (gerade für C++) etwas rar. Gute Bücher gibt es aber. Gregor J. schrieb: > Warum machst Du es denn nicht? 15 Euro opfern, einfach mal Arduino-Uno > kaufen und loslegen Ganz genau so. Arduino ist perfekt für Lauflichter.
Arduino F. schrieb: > Nöö... > Du: Verrechnet! Jau! Aber trotzdem günstig. Kannst du nicht mehr selbst dafür bauen.
Florian schrieb: > Glücklicherweise sind die Inhaltsverzeichnisse mittlerweile soweit alle > verlinkt das man gleich auf die entsprechenden Seiten springt und man > nicht selbst danach suchen muss. Ja, allerdings schreibt ST nichts doppelt hin. Zum Beispiel steht nur im RCC Kapitel, welche Komponenten man vor der Benutzung einschalten muss. Nur das Kapitel der Komponente zu lesen reicht nicht. Die Doku von AVR ist kürzer und hat mehr Querverweise, sind daher für den Anfang deutlich angenehmer. Aber wenn man es ernst meint kann man sich auch an den Dokumentations-Stil von ST gewöhnen.
Sherlock 🕵🏽♂️ schrieb: > Aber wenn man es ernst meint kann man > sich auch an den Dokumentations-Stil von ST gewöhnen. Immerhin steht nahezu alles drin. Es gibt genug Controller die kaum dokumentiert sind, wo man kaum mehr als eine Register-Liste bekommt (auch mit NDA).
Niklas G. schrieb: > Immerhin steht nahezu alles drin Ja. Und wenn man sich die PDFs nicht ausdruckt, sondern auf dem PC liest und dabei auch rege von der Suchfunktion (Strg-F) gebraucht macht, kommt man zurecht - finde ich.
Niklas G. schrieb: > Etwas gefährliche Ansicht, die Autoren von Bibliotheken (insbesondere > der Standard-Bibliotheken) haben oft sehr viel Arbeit hinein gesteckt > diese stabil und umfassend umzusetzen. Das selbst in ähnlicher Qualität > nachzubilden wäre ein absurder Aufwand. Eine Bibliothek für ein > Datenformat (z.B. PDF oder ZIP oder XML...) kann locker Zigtausend > Zeilen enthalten, das baust du nicht mal eben nach. Ich denke hier sind wir uns alle einig das ich für Programme für die ich solche umfangreiche Bibliotheken brauch deutlich mehr Übung brauche. Deswegen hatte ich auch nicht solche im Sinn, sondern relativ kurze die man durchaus selber noch schreiben kann. Für Größen die du nennst greift man unweigerlich auf Bibliotheken zurück. Niklas G. schrieb: > Dann hilft nur: Üben, üben, üben. Am Besten auf dem PC. Du kannst dir > jetzt sofort eine Entwicklungsumgebung (z.B. Visual Studio Community > Edition) herunterladen und anfangen. Da hab ich mir mittlerweile schon was überlegt wie ich am besten lerne. Vor zwei oder drei Tagen hab ich mir die Arduino IDE geholt, einfach auch um was an der Hardware zu sehen. Über die Feiertage ist gewöhnlich viel los, die freie Zeit die ich aber habe werde ich dafür nutzen. Niklas G. schrieb: > Ganz genau so. Arduino ist perfekt für Lauflichter. Hab ich mir ebenfalls geholt. Ohne Bradboard schaut es zwar nicht schön aus, aber es sieht ja keiner🤐😂 Sherlock 🕵🏽♂️ schrieb: > Ja, allerdings schreibt ST nichts doppelt hin. Zum Beispiel steht nur im > RCC Kapitel, welche Komponenten man vor der Benutzung einschalten muss. > Nur das Kapitel der Komponente zu lesen reicht nicht. Mir ging es bei denen dicken Dingern nur um die Navigation, man muss dann eben nochmal genauer schauen, aber mit der Zeit lernt man ja die Eigenheiten der einzelnen Hersteller.
Florian schrieb: > Deswegen hatte ich auch nicht solche im Sinn, sondern relativ kurze die > man durchaus selber noch schreiben kann Also bei Verwendung von USB wird das schon recht schwierig. Bei WiFi unmöglich. Und für die Android App muss man das umfangreiche Android SDK Framework nutzen. Theoretisch kann man direkt die Android System APIs nutzen aber da gibt es kaum Unterstützung in der Entwicklungsumgebung für, es ist total umständlich und man muss auf viele Möglichkeiten gerade bei der GUI verzichten. Keiner macht das so. Für komplexere Mikrocontroller wie STM32 gibt es umfangreiche Bibliotheken, die vieles deutlich vereinfachen. Florian schrieb: > Hab ich mir ebenfalls geholt Na das ist ein Fortschritt 👍
Niklas G. schrieb: > Also bei Verwendung von USB wird das schon recht schwierig. Bei WiFi > unmöglich Ich wollte ja nicht mit dem schwierigen Teil als erstes beginnen sondern mich doch erst wieder langsam einarbeiten. Bibliotheken wollte ich nicht grundsätzlich auslassen, aber für den Anfang wollte wollte ich nicht zusätzliche Bausteine mit einbauen wenn ich selbst bei den einfachsten noch mit der Groß- und Kleinschreibung ringe. Bibliotheken kommen schon noch, es war ja von Anfang an klar dass es Zeit braucht und ich nicht innerhalb ein paar Wochen das Programm schreibe.
Florian schrieb: > Bibliotheken kommen schon noch, es war ja von Anfang an klar dass es Zeit > braucht und ich nicht innerhalb [von] ein paar Wochen das Programm > schreibe. Das erste Programm – z.B. LED-Blinkprogramm – kann man mit einem Arduino-Uno und mit der Arduino-IDE innerhalb von 15 Minuten „schreiben” und das schafft sogar ein Zwölfjähriger problemlos. Dafür braucht man sich außerdem nicht noch zusätzlich mit der Hardware herumplagen, was am Anfang enorm wichtig ist. Man braucht auch kein Programmiergerät, sondern nur ein USB-Kabel für den Arduino kaufen. So ein LED-Blinkprogramm ist in der Regel sehr einfach aufgebaut – LED einschalten, Delay-Pause, LED ausschalten und wieder Delay-Pause; das ganze als Endlosschleife, vorher wird noch der Port für die LED definiert und als Ausgang eingestellt. Es sind nur ein paar Zeilen Code und im Netz gibt es für Arduino genügend Beispiele, die man erstmal direkt so übernehmen/kopieren, kompilieren und sofort auf den µC aufspielen kann. Diese Programmgrundlage kann man dann sehr leicht und auch relativ schnell ausbauen und daraus ein Lauflicht mit z.B. 4 oder 8 Leuchtdioden machen – diese zusätzlichen LEDs kann man dann z.B. auf einem Steckbrett unterbringen und alles einfach mit Dupontleitungen verbinden. Dauert maximal ein paar Stunden – Tage oder Wochen muss man nicht davor sitzen und grübeln, es sei denn man hat wirklich große Defizite oder generell gravierende Wissenslücken bzw. Einschränkungen, aber auch Menschen mit einer Behinderung können solche Dinge relativ zügig schaffen. Wer aber weiterhin nur darüber reden will, der darf das gerne tun, denn verboten ist es nicht, sich in der Phantasie vorzustellen, wie es sein könnte und wie bzw. womit man es eventuell schreiben könnte. Hoffentlich bleibt es am Ende nicht nur bei dieser Träumerei.
Das schöne an den klassischen Arduino Boards (Uno und Nano gehöre dazu) ist, dass - da nur minimal Schnickschnack drauf ist - Bauteile verwendet wurden, die man Problemlos in eigenen Schaltungen nutzen kann - die Schaltpläne veröffentlicht wurden - die Platine keine verborgenen Layer hat So kann man sich erst mal darüber freuen, dass das Programm funktioniert, und dann in Ruhe anschauen/abgucken, wie sie das gebaut haben. Für den Einstieg finde ich auch den Funduino Cube (mit Arbeitsbuch) sehr attraktiv. Denn da sind jede Menge Komponenten zum Ausprobieren drauf, die in der Maker Szene beliebt sind. Man kann sie billig bei Aliexpress kaufen. https://funduino-aio.de/uebersicht/ Mein Sohn nutzt das in der Berufsausbildung. Der Preis mag etwas hoch erscheinen, wenn man nur auf das Foto schaut, aber das Arbeitsbuch rechtfertigt den Preis. Nach den ersten Anfängen kann ich den NiboBee Roboter empfehlen. Damit lässt sich die Programmierung der Regelung von Motoren gut üben. https://www.reichelt.de/ch/de/shop/produkt/nibobee_-_programmierbarer_roboter-bausatz-91023?q=%2Fnibobee-programmierbarer-roboter-bausatz-nibo-bee-p91023.html http://stefanfrings.de/nibobee/index.html
Angehängte Dateien:
-
erster_Test.jpg
130 KB -
Tach_Manfred.jpg
110 KB -
Testaufbau_DCF77.jpg
93 KB
Gregor J. schrieb: > Das erste Programm – z.B. LED-Blinkprogramm – kann man mit einem > Arduino-Uno und mit der Arduino-IDE innerhalb von 15 Minuten „schreiben” > und das schafft sogar ein Zwölfjähriger problemlos. Dafür braucht man > sich außerdem nicht noch zusätzlich mit der Hardware herumplagen, was am > Anfang enorm wichtig ist. Man braucht auch kein Programmiergerät, > sondern nur ein USB-Kabel für den Arduino kaufen. So ein > LED-Blinkprogramm ist in der Regel sehr einfach aufgebaut – LED > einschalten, Delay-Pause, Dein Niveau ist offenbar unter dem Zwölfjährigen! Das LED-Blinkprogramm bringt Arduino ab Werk mit und wer etwas verstanden hat, wird eine Schleife mit "delay" vermeiden. Delay blockiert, man sollte sofort das Beispiel "Blink ohne delay" durcharbeiten. Ich habe dann mal direkt drei LEDs angebaut, mit aufgesteckter Buchsenleiste und natürlich Vorwiderständen, Lauflicht bespielt, ohne zusätzliche Hardware ist das Ding wertlos. Im nächsten Schritt habe ich gelötet, drei LEDs, drei Taster, ein Drehpoti und ein Display. Damit kann ich so ziemlich alles austesten. Liegt derzeit mit einem DCF-Empfänger dran herum, ich wollte die Machbarkeit eigener Software austesten. Alle meine realisierten Geräte haben einen Nano oder ProMini, die dank des gleichen µC kompatibel sind.
Manfred P. schrieb: > Dein Niveau ist offenbar unter dem Zwölfjährigen! Das LED-Blinkprogramm > bringt Arduino ab Werk mit und wer etwas verstanden hat, wird eine > Schleife mit "delay" vermeiden. Delay blockiert, man sollte sofort das > Beispiel "Blink ohne delay" durcharbeiten. Delay blockiert nichts, wenn das ganze Programm des µControllers nur aus dieser Schleife besteht und sonst nichts – es ist gar nicht so einfach es zu begreifen. Ist so ähnlich, wenn man krampfhaft an SRAM sparen will, obwohl der µC z.B. 2kB hat und man am Ende eh nur 100 Bytes verbrauchen wird und der Rest davon einfach so ungenutzt im µController liegt. Das beste Beispiel dafür ist: man betreibt irgendwelche Bitakrobatik und Schiebeoperationen, um alles in ein Byte hineinzuquetschen, statt einfach jeweils ein Byte als Platzhalter für ein Bit zu nehmen. Wie man bei Aufgaben auch ohne Delay auskommen kann, sollte man sich später natürlich auch mal anschauen und aneignen, weil man es brauchen wird, aber gerade am Anfang ist so etwas kontraproduktiv, wenn man sich z.B. mit Timern und Interrupts beschäftigen muss – das hat durchaus Potenzial, einen Einsteiger gleich am Anfang so zu überfordern, dass er die Flinte ins Korn wirf, was natürlich schade wäre. Zu wissen, was wann angebracht und sinnvoll ist, ist das A und O.
Manfred P. (pruckelfred) 21.12.2024 21:40 >Alle meine realisierten Geräte haben einen Nano oder ProMini, die dank >des gleichen µC kompatibel sind. Auf den Bildern ist aber ein Uno über Kopf. Der braucht ja extrem viel Platz.
Manfred P. schrieb: > Tach_Manfred.jpg Komisch, das Display ist schief aber das Arduino Board (mit seinen versetzten Steckern) sitzt gerade. Wie hast du dieses Kunststück fabriziert?
Hallo N. M. schrieb: > Genau das gleiche denke ich auch die ganze Zeit. Mehr als 120 Posts für > sowas 😂 Ein aktiver Thread ist was sehr schönes, vor allem wenn er recht nah am Thema bleibt und das Niveau zum größten Teil hoch ist und einfach spaß macht. (Für das Forum - noch -fast- keine Beleidigungen, keine politischen Diskussionen, keine Weltanschaulichen Streitereien - was leider selbst bei solchen Themen nicht selbstverständlich ist). Und nie vergessen: Man Antwortet nicht in erster Linie für den TO (generell) sondern für die vielen stillen Mitleser und mittlerweile auch ein klein wenig für die KI. Was Suchmaschinen und KI hier findet bzw, "lernt" braucht nicht (obwohl es immer besser und persönlicher ist) hier nochmal erklärt werden. Des-weiteren sind gerade bei diesen speziellen Thema (wenn vernünftig formuliert und ohne persönliche Angriffe und Generalisierung) verschiedene Anschauungen, Vorgehensweisen und simple die "Geschichte" der einzelnen wie sie programmieren gelernt (oder auch aufgegeben) haben sehr interessant und unterhaltsam. Nein dieser Thread sollte im Gegensatz zu "Energiewende", Elektromobilität, "Faule Schüler", Energiekosten, "Made in Germany" Uni vs. FH, Lernkomptez, Arduino ja oder nein,.. Threads auch die 1000er Marke überschreiten.
Hi Darius schrieb: > Nein dieser Thread sollte im Gegensatz zu "Energiewende", > Elektromobilität, "Faule Schüler", Energiekosten, "Made in Germany" Uni > vs. FH, Lernkomptez, Arduino ja oder nein,.. Threads auch die 1000er > Marke überschreiten. Na, dann will ich noch einmal dazu beitragen, dieses Ziel zu erreichen. Aber meine Antwort gilt Florian und denjenigen, die diesem Thread aus fachlicher Sicht folgen und nicht darauf warten, wer grad den Glaubenskrieg zwischen Sprachen und Hardware gewinnt. Es spielt keine Rolle. welche Controller zum Einsatz kommen, aber es spielt eine Rolle, welche Unterstützung ein Anfänger erfährt. Florian schreibt, das er Probleme hat, sich die Befehle zu merken und manchmal nicht weiß, wie sie heißen. In Assembler ist das relativ einfach, denn prinzipiell gibt es nur wenige Befehle, die, wenn auch englisch, relativ einfach zu merken sind. Wer aus der Hardware kommt, arbeitet mit Verbindungen. Ob mit Logikgattern oder Relaiskontakten, das Ergebnis kann mit Messungen an den Kontaktstellen immer kontrolliert werden. Anders eine Schaltung mit Controller. Da muss man sich im klaren sein, das er sich einen Befehl aus dem Speicher holt, mit dem Befehlsdecoder die binäre Struktur erkennt und einen Befehl ausführt. Das kann sein, das er an eine Speicheradresse springen und dort den nächsten Befehl lesen, eine logische Verknüpfung mit einem zweiten Byte durchführen oder ein Ergebnis abspeichern soll. Signale lesen und Ausgänge setzen sind mit lesen oder speichern von oder in Speicherzellen vergleichbar. Immer spielt die Adresse eine Rolle. In meinem Buch habe ich versucht, das etwas näher zu erläutern ohne gleich eine hochwissenschaftliche Abhandlung zu Controllern zu geben. Das ich im ersten Teil Schritt für Schritt den Aufbau eines durchaus nützlichen Programmes für die spätere Arbeit mit Controllern beschrieben habe ist dem Umstand geschuldet, das VB kostenlos im Netz verfügbar ist und angefangen mit simplen Beispielen in die OOP und Ereignis gesteuerte Programmierung führt. Schließlich hat man ein Programm, welches die Inhalte der Variablen innerhalb des Controllers zur Laufzeit visualisiert. Macht ein Controller nicht das, was erwartet wird, kann man Triggerbits in den relevanten Programmcode setzen und wenn der Abschnitt bearbeitet wird empfängt der PC über die serielle Schnittstelle den Inhalt der Variablen. Da man es selber schreibt und aufbaut, bekommt man einen guten Einblick in die Struktur eines Programmes und kann dies auch in eigene Programme übertragen. Anschließend wird mit der Programmierung einiger Experimente mit Controllern der Programmaufbau in Assembler erklärt und warum Assembler bei weitem nicht so schwer und unlesbar sein muss, wie manchmal behauptet wird. In dem Sinne euch allen ein frohes Fest und einen guten Start ins neue Jahr Gruß oldmax
Martin V. schrieb: > mit simplen Beispielen in die OOP und Ereignis gesteuerte Programmierung > führt Warum nicht in Assembler? Warum nicht C++ auf beiden Plattformen? Wär doch viel einfacher nur eine Sprache lernen zu müssen... Martin V. schrieb: > In Assembler ist das relativ einfach, denn prinzipiell gibt es nur > wenige Befehle, die, wenn auch englisch, relativ einfach zu merken sind Es ist aber derart umständlich und langwierig damit zu arbeiten, dass man in der verlorenen Zeit viel besser eine Hochsprache lernen kann. Übrigens hat C++ und C erst recht weniger Keywords als selbst der AVR-Assembler. Folglich ist es besser C zu lernen wenn man sich Begriffe schlecht merken kann. Ich finde Begriffe wie "if" und "else" übrigens deutlich besser zu merken als sowas wie "brcs". Martin V. schrieb: > des Controllers zur Laufzeit visualisiert. Macht ein Controller nicht > das, was erwartet wird, kann man Triggerbits in den relevanten > Programmcode setzen und wenn der Abschnitt bearbeitet wird empfängt der > PC über die serielle Schnittstelle den Inhalt der Variablen. Und was wenn der Controller das "Triggerbit" nicht mehr empfängt weil er vorher abstürzt? Moderne Controller kann man Step-By-Step debuggen per JTAG/SWD, was die Fehlersuche dramatisch vereinfacht und beschleunigt. Außerdem kann man so super den Programmablauf visualisieren und begreifen. Entsprechende Debug-Adapter sind spottbillig bzw in die Evalboards integriert.
Christoph M. schrieb: >>Alle meine realisierten Geräte haben einen Nano oder ProMini, die dank >>des gleichen µC kompatibel sind. > Auf den Bildern ist aber ein Uno über Kopf. Der braucht ja extrem viel > Platz. Lesen und Verstehen sind bei manchen Leuten Gegensätze. Der Uno ist ein TESTAUFBAU. "Realisierte Geräte" sind eine andere Sache, mit Gehäuse drum und Bedienelementen. Sherlock schrieb: > Komisch, das Display ist schief aber das Arduino Board (mit seinen > versetzten Steckern) sitzt gerade. Wie hast du dieses Kunststück > fabriziert? Das sieht auf dem Foto schlimmer aus als in echt. Die zwei gelben LEDs durch die Befestigungslöcher hindern das Display am Abfallen, aber die Löcher passen nicht ins Raster. Das UNO-Board habe ich auf verbogene 0,6er-Stifte setzen müssen, ganz sauber parallel sitzt es auch nicht. Das tut wenig zur Sache, es ist ein Testbrett zur Erprobung von Grundfunktionen und erfüllt seinen Zweck, wird niemals zu einem fertigen Gerät werden - damit habe ich 2015 meine Arduino-Gehversuche gemacht.
>Lesen und Verstehen sind bei manchen Leuten Gegensätze. Der Uno ist ein >TESTAUFBAU. "Realisierte Geräte" sind eine andere Sache, mit Gehäuse >drum und Bedienelementen. Ja. Aber auch auf einem Testaufbau lässt sich ein Nano verwenden, da Softwarekompatibel.
Hi Niklas G. schrieb: > Warum nicht in Assembler? Warum nicht C++ auf beiden Plattformen? Wär > doch viel einfacher nur eine Sprache lernen zu müssen... Wenn du mein veröffentlichtes Buch mal angeschaut und vielleicht einmal flüchtig reingeschaut hättest, wäre deine Kritik anders ausgefallen. Ich habe mir das Recht herausgenommen, VB und Assembler zu verwenden. Punkt und fertig. Jeder Autor hat das Recht, Thema und Inhalt für seine Zielgruppe selbst festzulegen. Ja, JTag gibt es, aber nicht für alle Controller. Das VB Programm zielt daraufhin, mit der seriellen Schnittstelle von einem Controller Daten zu empfangen und da auch Datenbank benutzt wird, die Grundlage zu liefern, diese zu verarbeiten und zu speichern. Außerdem, das Buch entstand vor über 10 Jahren. Hardware war schon bei Fertigstellung überholt, aber deswegen ist es nicht völlig wertlos. Anfänger werden kaum mit einem komplexen Controller beginnen. Und der im Buch angegebene Atmega8 liegt durchaus im Bereich der preiswerte Controller für viele Anwendungen. Und noch ein Schlusswort: Ja, lernt die Programmiersprache, die euch gefällt, die ihr nutzt, mit der ihr Erfolg habt. Für zwei Sprachen hab ich etwas Hilfe geleistet wie andere Autoren mit Tutorials für C, Pascal, Java usw. Gruß oldmax
Martin V. schrieb: > Ich habe mir das Recht herausgenommen, VB und Assembler zu verwenden. > Punkt und fertig Na dann nehme ich mir das Recht zu sagen, dass es sinnvoller ist auf beiden Seiten C++ zu nutzen. Oder C++ auf dem Controller, Python oder Java auf dem PC. Martin V. schrieb: > Ja, JTag gibt es, aber nicht für alle Controller Aber für sehr, sehr viele. Warum ausgerechnet mit einem anfangen der dieses extrem hilfreiche Feature nicht hat? Martin V. schrieb: > Anfänger werden kaum mit einem komplexen Controller beginnen Wenn das allgemeine Handling und die Tools gut sind, ist auch ein komplexer Controller kein Problem. Zigtausend Anfänger arbeiten problemlos mit den ARM- oder ESP32- Arduinos. In C++ oder Python. Martin V. schrieb: > Und der im Buch angegebene Atmega8 liegt durchaus im Bereich der > preiswerte Controller für viele Anwendungen. Mittlerweile sind viele ARMs billiger. Besonders in Einzelstückzahlen. Komplette Boards inklusive Debugger, Quarz, USB, USB-Serial-Adapter, LEDs, Buttons und teilweise noch mehr diverser Peripherie für unter 20€ - besser geht's kaum. Die ESP32 haben wohl das beste Preis-Leistungs-Verhältnis und exzellente Software-Unterstützung, aber ausgerechnet das JTAG-Debugging geht (noch) nicht ganz so glatt, daher würde ich die nicht unbedingt als erste Wahl zum Einstieg sehen, aber mindestens auf Platz 2. Martin V. schrieb: > Wenn du mein veröffentlichtes Buch mal angeschaut Naja, glaub nicht dass es da viel für mich zu lernen gibt...
Martin V. schrieb: > Und der im Buch angegebene Atmega8 liegt durchaus im Bereich der > preiswerte Controller für viele Anwendungen. Der ATMEGA8 ist auch schon ziemlich obsolet. Es wundert mich immer wieder, dass Leute sogar heute noch geizen und zu solchen alten Ziegelsteinen greifen und sich selbst diverse Problme und Einschränkungen damit schaffen (für C-Programme ist der Speicher relativ klein, es gibt keine PCINTs usw.), obwohl es den 328P gibt, mittlerweile wieder für ca. 2 Euro.
Hi Niklas G. schrieb: > Naja, glaub nicht dass es da viel für mich zu lernen gibt... Stimmt. Dazu müßtest du lesen können, bzw. verstehen, was geschrieben ist. Gregor J. schrieb: > obwohl es den 328P gibt, mittlerweile > wieder für ca. 2 Euro. Ach ja, Asche auf mein Haupt.... den Atmega8 auch nur zu erwähnen. Der 328P lässt sich u. a. auch mit dem im Buch beschriebenen Assembler programmieren. Aber was sag ich euch das, ihr wisst es ja auch. Es geht ja nur darum, das man hier mit einem Beitrag zeigt, wie schlau man ist. Und wie fortgeschritten. Also Freunde, hört auf die Experten. Ihr seid sonst wie ich "von gestern" Gruß oldmax
Martin V. schrieb: > Wenn du mein veröffentlichtes Buch mal angeschaut und vielleicht einmal > flüchtig reingeschaut hättest, wäre deine Kritik anders ausgefallen. Na, möchtest du eine detaillierte Kritik? Könnte im gleichen Tonfall ausfallen wie: Martin V. schrieb: > Stimmt. Dazu müßtest du lesen können, bzw. verstehen, was geschrieben > ist.
Niklas G. schrieb: > Na, möchtest du eine detaillierte Kritik? Könnte im gleichen Tonfall > ausfallen wie: Oh man, jetzt hab ich aber Angst. Hat dich das so hart getroffen? Sorry, aber das hier zu diskutieren macht doch keinen Sinn außer, man holt sich ne Tüte Chips und ne Cola und amüsiert sich darüber. Für den TO aber ist das nicht hilfreich. Ich hab versucht, dem gerecht zu werden, ohne andere Meinungen schlecht zu reden oder meine Tipps als das "Non plus ultra" zu predigen. Gruß oldmax
Niklas G. schrieb: > Totalen Anfängern würde ich sowieso eher Python nahe legen. und warum nicht ICON? https://forum-raspberrypi.de/forum/thread/8465-icon-teil-1-tutorial-zum-erlernen-der-programmiersprache-icon-installation/ Jeder empfiehlt ohne Not was NEUES nur weil es neu ist? (obwohl es auch fast alles mit den etablierten Programmiersprachen geht!) Auch am PC1500 von Sharp programmierte ich in Assembler, kam der Z80 und MOS6502 CPU nahe, dummerweise gab es für relokatiblen Code keine direkte Auslesemöglichkeit für den Programmcounter, aber es gab Tricks um dann relative Branch zu erzeugen und den Stack für Jump SUB und RTS return from Subroutine zu korrigieren um halt relokatibel zu bleiben. Damals war ich fit und heute verstehe ich kaum wie ich es vor 40 Jahren schaffte.
Martin V. schrieb: > Hat dich das so hart getroffen? Ah, erst jemandem sagen er könne nicht lesen und sich dann wundern? Joachim B. schrieb: > Jeder empfiehlt ohne Not was NEUES nur weil es neu ist? Python gibt es seit 1991. Joachim B. schrieb: > obwohl es auch fast alles mit den etablierten Programmiersprachen geht!) Und weil Python eine sehr etablierte Sprache ist, momentan auf Platz 1 des Tiobe-Index, ist es absolut sinnvoll, damit zu lernen. Gerade auch weil es eine Unmenge an Literatur, Software, Tools dazu gibt. Gibt es für C auch, aber Python ist halt viel einfacher zum Erlernen. Und dabei bleiben, weil man damit sehr viel machen kann, eben bis auf manche Embedded-Sachen.
Martin V. schrieb: > Ach ja, Asche auf mein Haupt.... den Atmega8 auch nur zu erwähnen. Der > 328P lässt sich u. a. auch mit dem im Buch beschriebenen Assembler > programmieren. Aber was sag ich euch das, ihr wisst es ja auch. Es geht > ja nur darum, das man hier mit einem Beitrag zeigt, wie schlau man ist. > Und wie fortgeschritten. Also Freunde, hört auf die Experten. Ihr seid > sonst wie ich "von gestern" Es ging nicht um Deinen ATMEGA8, auch nicht um Dein Buch von damals, was womöglich zeitlich und mental einigermaßen zusammenpassen könnte, sondern darum, wie Leute sich mit dieser Wahl des µControllers heutzutage immer noch das Leben selbst schwer machen, aber bei dieser Selbstmitleidtour, die Du an Tag legst, wird eine Konversation sehr schwierig bis unmöglich. Manche versuchen es auch mit dem ATMEGA88, aber das ist fast das gleiche, nur in einer anderen Farbe – mit C ist man schnell am Ende des Flashs angekommen, wenn man Programme über mehrere Seiten schreibt und womöglich auch noch etwas einbindet. Übrigens, der ATMEGA328P ist auch schon ziemlich veraltet oder anders ausgedrückt – obsolet. Dieser Chip wird sich aber noch sehr lange halten – dank der Popularität von Arduino. Und um hier den Flash mit normalen Kritzeleien in C vollzuschreiben, muss man sich schon ziemlich anstrengen – gemeint ist nicht das Unterbringen von Daten im Flash, denn damit kann man den Flash mit einer einzigen Variable (Feld) sofort vollbekommen, sondern das übliche Texten in C.
Ja, man kann heutzutage gut Assembler programmieren: Perplexity: "Write a blink program in assembler for an Atmega8"
1 | ; ATmega8 Blink Program |
2 | |
3 | .include "m8def.inc" |
4 | |
5 | .org 0x0000 |
6 | rjmp RESET |
7 | |
8 | RESET: |
9 | ; Set up stack pointer |
10 | ldi r16, high(RAMEND) |
11 | out SPH, r16 |
12 | ldi r16, low(RAMEND) |
13 | out SPL, r16 |
14 | |
15 | ; Configure PB0 as output |
16 | sbi DDRB, PB0 |
17 | |
18 | LOOP: |
19 | ; Turn LED on |
20 | sbi PORTB, PB0 |
21 | rcall DELAY |
22 | |
23 | ; Turn LED off |
24 | cbi PORTB, PB0 |
25 | rcall DELAY |
26 | |
27 | rjmp LOOP |
28 | |
29 | DELAY: |
30 | ldi r16, 0xFF |
31 | ldi r17, 0xFF |
32 | DELAY_LOOP: |
33 | dec r17 |
34 | brne DELAY_LOOP |
35 | dec r16 |
36 | brne DELAY_LOOP |
37 | ret |
Christoph M. schrieb: > DELAY_LOOP: > > dec r17 > > brne DELAY_LOOP > > dec r16 > > brne DELAY_LOOP > > ret Tja, und wie viele Schleifendurchläufe sind das jetzt, und wie viele Takte sind es?
Gute Frage:
Perplexity: How many clock cycles are needed by the following function:
To determine the number of clock cycles needed by the given delay loop
function, we need to analyze each instruction and consider their cycle
counts. Let's break down the function and calculate the cycles:
Cycle Count Analysis
Inner Loop:
dec r17: 1 cycle
brne DELAY_LOOP: 1 cycle if branch not taken, 2 cycles if branch
taken
Outer Loop:
dec r16: 1 cycle
brne DELAY_LOOP: 1 cycle if branch not taken, 2 cycles if branch
taken
Return:
ret: 4 cycles (this may vary depending on the specific
microcontroller)
Total Cycle Count Calculation
The total number of cycles will depend on the initial values of r16 and
r17. Let's call the initial value of r17 as N and the initial value of
r16 as M.
The inner loop (dec r17, brne) will execute N times for each
iteration of the outer loop.
The outer loop (dec r16, brne) will execute M times.
For each complete inner loop (except the last iteration):
(N-1) * (1 + 2) cycles = 3N - 3 cycles
For the last iteration of the inner loop:
1 + 1 = 2 cycles
For each complete outer loop (except the last iteration):
(M-1) * (3N - 1) cycles
For the last iteration of the outer loop:
3N + 1 cycles
Finally, we add the return instruction:
4 cycles
Therefore, the total number of cycles can be calculated as: Total cycles
= (M-1) * (3N - 1) + (3N + 1) + 4 This simplifies to: Total cycles = 3MN
- M + 4 It's important to note that this calculation assumes that the
branch prediction is perfect and that there are no additional cycles due
to pipeline stalls or other architectural factors
Christoph M. schrieb: > The inner loop (dec r17, brne) will execute N times for each iteration > of the outer loop. Tja, stimmt hier leider nicht. Toll dass Assembler so einfach ist dass selbst die KI ihren eigenen Code nicht versteht 😄
Assembler den Leuten als einfach zu verkaufen oder zu bezeichnen, ist ein Trugschluss, Selbstbetrug, Halbwissen oder einfach eine Überheblichkeit, die einen schnell einholen wird – das kann ich aus meiner Perspektive, in der ich mit diversen Assemblern in Verbindung mit 8085, Z80, 6502, 68000, C51, AVR und STM32 jahrelang real zu tun hatte, einfach so sagen. Was beim Blink-LED-Programm oder auch größeren Byte-Schaufel-Programmen usw. mit Assembler noch recht gut als etwas selbstgeschriebenes klappt, wird bei komplexeren Programmstrukturen, Berechnungen und Umgang mit Nicht-Integer-Zahlen, Feldern, Tabellen etc. sehr schnell zu einem Problem werden – die Zeit, die man für das Schreiben eines solchen komplexen Programms dann benötigt, kann man wirklich für nützlichere Dinge verwenden – z.B. für einen guten Aufbau und Ablauf des Programms oder um sich einfach neue Programmiertechniken anzueignen. Um den üblen Rest auf der untersten Ebene kümmert sich dann der Compiler, aber wenn man Assembler kann, kann man immer auch seine Arbeit überprüfen, überwachen und ggfs. entsprechend in die gewünschte Richtung mit entsprechenden C-Befehlen lenken – man kann einfach mal in der generierten Assemblerdatei immer nachschauen, wie es generiert worden ist. Wer Assembler nicht kann, der steht solchen speziellen C-Optimierungen gegenüber dann oft rat- und machtlos da, auch bei Fehlern, die ein Compiler machen kann, wird man leider nicht wissen können, woran es liegt, dass etwas nicht richtig funktioniert. Den Fehler hat in Wirklichkeit natürlich nicht der Compiler gemacht, denn es ist ja auch nur ein Programm, das seine Befehl ausführt, sondern es war ein Mensch oder ein Team, welches das Compilerprogramm geschrieben, mit entsprechenden Daten gefüttert und entsprechenden Verhaltensmustern ausgestattet hat. Und wer nur bei einem bestimmten µController (z.B. F103) mit Assembler oder auch in C-Sprache mental hängengeblieben ist, der ist selber schuld – die Realität wird einen irgendwann schon einholen, denn die Welt dreht sich immer weiter.
Gregor J. schrieb: > klappt, wird bei komplexeren Programmstrukturen, Berechnungen und Umgang > mit Nicht-Integer-Zahlen, Feldern, Tabellen etc. sehr schnell zu einem > Problem werden Ganz genau. Insbesondere auch wenn man nachträglich noch Änderungen machen möchte, und das möchte man sehr oft. In einen Assemblercode manuell noch etwas dazwischen zu schieben erfordert oft kompliziertes Hin-und-Her-Schieben der Registerzuordnungen und Sprungmarken. Dieser Aufwand ist schnell nicht mehr zu handlen. Der Compiler hingegen macht das blitzschnell automatisch. Man kann es sich in Assembler einfacher machen und viele kleine Blöcke anlegen mit jeweils ihrer eigenen Registerzuordnung und push-pop-Litanei, aber dann ist der Compiler-generierte Code mit Sicherheit schneller. Beim Assemblercode muss man immer jeden letzten Takt rausholen damit es überhaupt einen Effekt haben könnte. In C++ wird vieles vom Compiler einfach "per default" schon optimal umgesetzt, ohne dass man viele Gehirnzellen abnutzen müsste. Gregor J. schrieb: > Fehlern, die ein Compiler machen kann, Fehler im Compiler sind tatsächlich extrem selten. Über die stolpert man eigentlich nur wenn man sehr spezielle Dinge mit brandneuen Sprachfeatures macht, und das ist fast immer nur ein Absturz des Compilers, sehr selten falsch generierter Code. Gregor J. schrieb: > die Zeit, die man für das Schreiben eines solchen komplexen Programms > dann benötigt, kann man wirklich für nützlichere Dinge verwenden – z.B. > für einen guten Aufbau und Ablauf des Programms oder um sich einfach > neue Programmiertechniken anzueignen Genau, oder auch einfach bessere (komplexere) Algorithmen implementieren, die dann letztendlich schneller sind als handoptimierte simplere Algorithmen. Meistens (aber tatsächlich nicht immer) ist ein O(log n) Algorithmus in C++ besser als ein O(n) Algorithmus in handoptimiertem Assembler. Rbx schrieb: > Ja, immer fettere Internetseiten.. Ich finde Seiten wie Google Docs oder die Webversion von MS Office und solche extrem praktisch.
Gregor J. schrieb: > aber bei dieser > Selbstmitleidtour, die Du an Tag legst, wird eine Konversation sehr > schwierig bis unmöglich. Häää ? Selbstmitleidtour? Aber von mir aus. Gregor J. schrieb: > Was beim Blink-LED-Programm oder auch größeren > Byte-Schaufel-Programmen usw. mit Assembler noch recht gut als etwas > selbstgeschriebenes klappt, wird bei komplexeren Programmstrukturen, > Berechnungen und Umgang mit Nicht-Integer-Zahlen, Feldern, Tabellen etc. > sehr schnell zu einem Problem werden Martin V. schrieb: > Ja, so ist es. Wenn mathematische Aufgaben bewältigt werden müssten, > würde ich auch kein Assembler einsetzen. Da käme sogar in Betracht, C zu > lernen... Warum hackst du so auf Assembler ? Wer aus der Hardware kommt, der möchte vielleicht auch wissen, wie so ein Controller funktioniert. Da unterstützt Assembler etwas mehr wie eine Hochsprache. Ich sage nicht "ihr müßt .. " sondern Martin V. schrieb: > lernt die Programmiersprache, die euch > gefällt, die ihr nutzt, mit der ihr Erfolg habt. Und nun noch etwas: Ich habe auch andere Beiträge von euch gelesen und ich weiß durchaus eure Fachkenntnis zu schätzen aber erwarte auch, wenn man meine Fachkenntnis anzweifelt die Antworten zu verstehen, die ich gebe. Die paar Kommentare sind nur ein Beispiel für "lesen können" und "verstehen". Gruß oldmax
Martin V. schrieb: > Warum hackst du so auf Assembler ? Wir hacken nicht auf Assembler rum. Sondern darauf, dieses für Anfänger zu empfehlen oder nahe zu legen, ganze (große) Projekte damit umzusetzen. Martin V. schrieb: > Da unterstützt Assembler etwas mehr wie eine Hochsprache Ja, aber zum Programmieren lernen ist das nicht die erste Priorität. Ich finde auch es ist kontraproduktiv damit anzufangen, weil man sich so eine Denkweise zulegt, welche nicht skaliert, und die man so später wieder ent-lernen muss. Erst mit einer abstrakten Sprache anzufangen und dann den Assembler dazu zu nehmen halte ich didaktisch für viel sinnvoller.
Hi Anfangs ging es noch darum, Florian bei seinem Problem zu helfen, den Umstieg von Logikgattern zu Schaltungen mit µC und dem damit verbundenem Problem der Programmierung. Nach seiner Aussage kann er etwas C++, also was streiten wir hier ob Assembler lernen zweitrangig oder überhaupt nicht erforderlich ist. Ich habe ihm vorgeschlagen, mal einen Blick in mein öffentliches Buch zu werfen und zu schauen, ob es ihm vielleicht hilft. Nicht mehr und nicht weniger. Alles andere ist im Laufe dieser Beiträge hineininterpretiert worden. Und das basiert auch zum Teil darauf, das man vielleicht lesen kann, aber nix versteht oder einfach nur sein eigenes Ego verwirklichen will. Mir ist das ja egal, ob es euch nicht gefällt, ich brauch eure Hilfe nicht und eure ach so tollen Meinungen. Florian aber, nur mal zur Erinnerung. Niklas G. schrieb: > Ja, aber zum Programmieren lernen ist das nicht die erste Priorität. Ich > finde auch es ist kontraproduktiv damit anzufangen, weil man sich so > eine Denkweise zulegt, welche nicht skaliert, und die man so später > wieder ent-lernen muss. Erst mit einer abstrakten Sprache anzufangen und > dann den Assembler dazu zu nehmen halte ich didaktisch für viel > sinnvoller. Ja, aber... genau. Florian ist genau an dieser Stelle. Ich komme auch aus der IC-Grab Ecke. Ich kann außer Assembler auch ein paar Hochsprachen und nein, C ist leider nicht dabei. Aber ich hab es noch nicht gebraucht, da meine Projekte mit µC eben keine mathematischen Klimmzüge brauchen und in der Regel mit den "einfachen" Befehlen auskommen. Sollte sich das ändern, werde ich mich mit C befassen. Ich werde den Syntax von C lernen, aber programmieren kann ich schon. Ich habe gelernt, Programme aufzubauen, zu strukturieren und meine Ziele zu erreichen. Beruflich wie privat. Also denke ich, auch meine Einstellung zu Sprachen hat einen Erfahrungswert. Etwas anders als deiner, aber genau so wertvoll. Er hilft nicht jedem, das weiß ich auch und ob es Florian hilft weiß ich nicht. Er hat sich dazu noch nicht geäußert. Gruß oldmax
Martin V. schrieb: > Ja, aber... genau. Florian ist genau an dieser Stelle Eben nicht, er kann schon C++, das sollte er nutzen und ausbauen, anstatt sich mit was völlig Neuem wie Assembler zu plagen. Gerade auch weil er komplexe Dinge wie USB umsetzen möchte, das komplett in Assembler zu machen ist... unschön. Und auch wenn man aus der Digital-Hardware-Ecke kommt und gar nicht programmieren kann finde ich es sinnvoller programmieren erstmal abstrakt zu lernen. Martin V. schrieb: > Alles andere ist im Laufe dieser Beiträge hineininterpretiert worden Er soll also das Buch anschauen aber nicht die dortige Methodik befolgen, sondern nur dein Werk bewundern? Meinetwegen, aber IMO Zeitverschwendung. Das Buch zu lesen und es so zu machen wie dort gezeigt, mit Assembler? Das ist IMO kontraproduktiv.
Niklas G. schrieb: > Er soll also das Buch anschauen aber nicht die dortige Methodik > befolgen, sondern nur dein Werk bewundern? Meinetwegen, aber IMO > Zeitverschwendung. Das Buch zu lesen und es so zu machen wie dort > gezeigt, mit Assembler? Das ist IMO kontraproduktiv. "IMO", eben deiner Meinung nach. Es gibt auch andere Meinungen. Aber du verstehst es nicht... macht aber nix. Ich denke, Florian selbst ist alt und klug genug zu wissen, was er mit dem Hinweis anfängt. Gruß oldmax
Kaufe billige Arduinos. In keinem Ökosystem findest du mehr Hilfe für Einsteiger. Wenn dir die IOs nicht reichen: Es gibt Schieberegister. Dabei lernst du auch, wie die UARTs im Controller funktionieren. Wenn dir die IOs nicht reichen: Es gibt IO-Expander, die seriell, per SPI oder I2C angebunden werden. Dabei kannst du lernen, wie I2C und SPI funktionieren. Lass (zumindest vorerst) die Finger von Assembler und von FPGAs. Beides bringt erstmal eine deutlich höhere Komplexität mit sich, ohne dass du entsprechende Vorteile hast. Beides macht man heute nur noch aus Liebhaberei oder wenn man Anforderungen hat, die sich anders schlecht erfüllen lassen.
Aus der Diskussion über Assembler halte ich mich mal raus weil ich mich mit denen eigentlich noch gar nicht befasst habe. Martin V. schrieb: > Ja, aber... genau. Florian ist genau an dieser Stelle. Tut mir leid, aber da muss ich Niklas beipflichten. Mit Assemblern kenn ich mich kaum aus, mit C++ hab ich mich aber schon intensiver befasst (auch wenn es Jahre her ist und ich erst wieder reinfinden muss) nehm es mir also bitte nicht übel wenn ich mich nicht tiefer mit deinem Buch befasse. Mich an dieser Stelle mit Assemblern zu befassen halte ich für kontraproduktiv wenn ich mir hier die Beiträge dazu durchlese. Martin V. schrieb: > Hi > Anfangs ging es noch darum, Florian bei seinem Problem zu helfen, den > Umstieg von Logikgattern zu Schaltungen mit µC und dem damit verbundenem > Problem der Programmierung. Anfangs... Anfangs ging es mir darum zu lernen was ich was ich zu Mikrocontroller wissen muss weil ich zuvor noch nicht damit gearbeitet hab. Mein Hauptproblem mit der Programmierung ist die Linguistik, die ist allgemein für mich schwierig, ich denke das ist beim lesen meiner Beiträge sicher einigen aufgefallen, das denke ich wird mit der Übung aber automatisch zumindest deutlich besser. Das Programm für das LED-Modul hab ich gerade begonnen, wenn auch zb. mit Analogeingängen als Platzhalter für USB (ein Schritt nach dem anderen). Ich muss nur eben immerwieder die Begriffe suchen, ja das passiert mir auch noch teilweise bei sowas einfaches wie If, else oder ähnliches. Mit der Übung wird das definitiv einfacher. Und um auf den Ursprung kurz zurück zu kommen, was ich gerade wirklich alles andere als berauschend finde sind die Compiler. Zb bei PIC hab verstanden das die freien nur mit Einschränkungen zu gebrauchen sind und der vom Hersteller kosten ja gleich um die 2k was für meinem Fall völliger Schwachsinn wäre. Zu den Nanos am Anfang würde ich gerne noch eine Frage stellen. Ich weiß es ist Offtopic aber ich hoffe ich darf trotzdem fragen. Für ein paar Steuerungen die ich brauche wären die ideal. Billig und in ein paar Minuten aufgebaut und programmiert, meine Frage dazu ist wie es bei den Billiganbietern damit aussieht? Das es kein "original" Arduino ist ist mir bewusst, laufen muss es letztendlich aber doch. Auf AliExpress hab ich welche wirklich günstig gesehen, gekauft hab ich von da aber noch nie was. Kann man bei denen kaufen ohne gleich auf die Nase zu fallen? Wäre natürlich auch für andere Komponenten ganz praktisch.
Florian schrieb: > Billiganbietern damit aussieht? Das es kein "original" Arduino ist ist > mir bewusst, laufen muss es letztendlich aber doch. Auf AliExpress hab > ich welche wirklich günstig gesehen, gekauft hab ich von da aber noch > nie was. Kann man bei denen kaufen ohne gleich auf die Nase zu fallen? > Wäre natürlich auch für andere Komponenten ganz praktisch. Kaufe mindestens einen "richtigen" Arduino als Referenz, zum Vergleichen. Bei den billigen aus China: Mit großer Wahrscheinlich hast du Glück. Du kannst aber auch Pech haben. Du riskierst allerdings nur wenig Geld und 2 Wochen Wartezeit.
Florian schrieb: > was ich gerade wirklich alles andere als berauschend finde sind die > Compiler. Zb bei PIC hab verstanden das die freien nur mit > Einschränkungen zu gebrauchen sind Für 8bit-Controller ist es schwieriger, gute Compiler zu entwickeln, und der Markt ist kleiner. Daher muss man da Geld einwerfen. Für die ARM-Architektur gibt es mit dem GCC einen exzellenten OpenSource-Compiler ohne Beschränkungen, auch weil die Architektur 32bit ist und explizit dafür konzipiert ist, mit Hochsprachen programmiert zu werden. Dank Arduino und anderen Umgebungen sind ARM-Controller aber trotz der Komplexität einfach zu programmieren. ARM-Controller sind mittlerweile auch sehr günstig, aber noch nicht ganz auf dem Niveau der China-Arduino-Nanos. Die STM32 Bluepills sind nahe dran, aber es gibt Probleme mit Fakes und man sollte sich einen Programmieradapter dazu kaufen (ST-Link), die aber ebenfalls sehr billig zu haben sind. Da kann man dann den sehr guten GCC nutzen und auch debuggen.
Tilo R. schrieb: > Lass (zumindest vorerst) die Finger von Assembler und von FPGAs. An dem Punkt sowieso, FPGAs sehen zwar für mich "Freundlicher" aus, aber ich hab mich damit nicht näher befasst und dann möglicherweise wieder die Hälfte umstellen... ne, dafür bin ich zu faul. Tilo R. schrieb: > Du riskierst allerdings nur wenig Geld und 2 Wochen Wartezeit. Das Geld wären 5 Euro mit Versand für ein paar... die zwei Wochen wären in dem Hinblick schlimmer. Tilo R. schrieb: > Kaufe mindestens einen "richtigen" Arduino als Referenz, zum > Vergleichen. Was verstehst du unter richtig? Einen originalen? Ich hab jetzt einen von AZ... Mit der Funktion hab ich bei dem keine Probleme. Außer das ich mir die externen Verbindungen hinpfusche weil ich keine Steckverbinder hab🙊😅 funktioniert alles einwandfrei.
Niklas G. schrieb: > Für 8bit-Controller ist es schwieriger, gute Compiler zu entwickeln, und > der Markt ist kleiner. Daher muss man da Geld einwerfen. Beschränkt sich das auf die 8-bit? Gerade wenn ich eher auf größere, das heißt höhere Anzahl an IOs baue hab ich vermehrt 16-bit gefunden. In manchen Steuerungen zwar Overkill aber das bisschen mehr kostet kaum was. Für genaueres hab ich offensichtlich noch nicht ausreichend gesucht, wie stark sind denn die Einschränkungen? Ich weiß nicht ob ich nur einfach zu wenig gesucht hab, aber PIC zu ARM macht schon einen Unterschied. Wenn die Einschränkungen nicht gravierend sind würde ich doch eher fast zu PIC tendieren. Ich brauch mehrere Steuerungen der gleichen Art, erstellen muss ich es also nur einmal, die anderen sind dann einfach nur noch eine Kopie.
Florian schrieb: > Beschränkt sich das auf die 8-bit? Gerade wenn ich eher auf größere, das > heißt höhere Anzahl an IOs baue hab ich vermehrt 16-bit gefunden 16bitter sind im Hobby-Bereich eigentlich seltener, weshalb entsprechende Compiler/Tools hier noch teurer/exotischer sind. Da 32bitter mittlerweile extrem leistungsfähig und günstig sind, macht der Zwischenschritt über 16bit kaum noch Sinn. Florian schrieb: > Ich weiß nicht ob ich nur einfach zu wenig gesucht hab, aber PIC zu ARM > macht schon einen Unterschied. Wenn die Einschränkungen nicht gravierend > sind würde ich doch eher fast zu PIC tendieren. Warum genau? Wenn schon dann die PIC32, sich mit den Limitierungen der 8/16bit Varianten zu quälen macht heutzutage keinen Sinn, außer du hast gigantische Stückzahlen und musst den letzten Cent rausquetschen. Allerdings sind unter den 32bit-Architekturen die ARMs einfach viel verbreiteter, es gibt exzellente gratis-Tools und Compiler, Dokumentation, billige Evalboards und Debugger, Unmengen an Literatur auch im Hobby-Bereich...
Niklas G. schrieb: > Warum genau? Wenn schon dann die PIC32, sich mit den Limitierungen der > 8/16bit Varianten zu quälen macht heutzutage keinen Sinn Ganz einfach, auf 32-bit hab ich nicht geschaut und die Suche spuckt nur immer das aus wonach man auch sucht. An dem "überholt Status" hab ich ganz einfach nicht gedacht. Intensiv hab ich noch nicht gesucht, aber weil PIC auf dem ersten Blick besser ausgesehen hat hab ich da erstmal geschaut und die Compiler haben mich doch sehr erschrocken.
Florian schrieb: > Zu den Nanos am Anfang würde ich gerne noch eine Frage stellen. > meine Frage dazu ist wie es bei den Billiganbietern damit aussieht? > Das es kein "original" Arduino ist ist mir bewusst, > laufen muss es letztendlich aber doch. Auf AliExpress hab > ich welche wirklich günstig gesehen, gekauft hab ich von da aber noch > nie was. Kann man bei denen kaufen ohne gleich auf die Nase zu fallen? Ja, ich hatte mit nachgemachten Arduino Boards (mit ATmega328) noch nie Probleme, bis auf eine Ausnahme: Bei einer Lieferung fehlten die Booloader. Die konnte ich aber selbst installieren, weil ich schon einen ISP Programmieradapter hatte. Wäre das nicht so gewesen, hätte der Händler Ersatz geliefert, er bot es mir so an. Die Nachbauten verwenden in der Regel einen anderen USB-UART Chip, nämlich den CH340. Das ist kein Hindernis.
Florian schrieb: > Ganz einfach, auf 32-bit hab ich nicht geschaut und die Suche spuckt nur > immer das aus wonach man auch sucht Wo hast du denn da wie gesucht... Man braucht schon starke Argumente jetzt noch neue Projekte mit 8/16bit zu machen. Und einfach das erstbeste Suchergebnis zu nehmen ist, naja. Wenn man nur einfache Dinge mit Arduino programmiert merkt man wenig Unterschied, aber wenn die Programme größer und komplexer werden eben schon. Daher sind 8bit Arduinos für den Einstieg okay, aber ich würde da nicht bleiben - es gibt ja ARM-Arduinos.
Niklas G. schrieb: > Wo hast du denn da wie gesucht... Das kann ich dir genauso schnell beantworten wie ich gesucht habe. Eine kurze schnelle Suche bei Mouser um mir eine grobe Orientierung zu verschaffen. Keine Sorge, davon mir was auszuwählen ist da weit entfernt, da schau ich dann schon was ich brauche. Niklas G. schrieb: > Wenn man nur einfache Dinge mit Arduino programmiert merkt man wenig > Unterschied, aber wenn die Programme größer und komplexer werden eben > schon. Mir fehlt da die Orientierung. Für alles wofür geschätzt keine Tage zum programmieren brauche ist es nicht besonders groß und komplex. Niklas G. schrieb: > Daher sind 8bit Arduinos für den Einstieg okay, aber ich würde da nicht > bleiben - es gibt ja ARM-Arduinos. Im Bezug auf die billigen Arduinos. Die sollen nur ganz einfaches bewältigen. Dafür würde ich normalerweise nie auf uCs gehen, weil das dann aber Steuerungen sind für die ich mir keine Arbeit machen will sind die Dinger in dem Fall die einfachste und billigste Variante. Normalerweise mag ich es ja mir ein paar Gedanken zu machen, aber das ist dann einfach nur Mittel zum Zweck.
Florian schrieb: > Im Bezug auf die billigen Arduinos. Die sollen nur ganz einfaches > bewältigen. Dafür würde ich normalerweise nie auf uCs gehen, weil das > dann aber Steuerungen sind für die ich mir keine Arbeit machen will sind > die Dinger in dem Fall die einfachste und billigste Variante. > Normalerweise mag ich es ja mir ein paar Gedanken zu machen, aber das > ist dann einfach nur Mittel zum Zweck. Mach dir keine Sorgen, dass die billigen Arduinos zu wenig könnten. Auch die billigsten können eine ganze Kiste diskreter Logik ersetzen. Wichtig ist, das du lernst wie man Mikrokontroller programmiert: Eine nicht endende Hauptschleife, alle größeren Aufgaben nicht blockierend, nach Möglichkeit ohne aktives Warten. Und um das alles zu verwalten: Zustandsmaschinen. Imho das wichtigste Programmierkonstrukt überhaupt. Wenn du das kannst, glaube ich nicht, dass du jemals wieder zu diskreter Logik zurück willst. Es ist im Code so viel komfortabler, nachträglich noch was zu ändern. IOs mit konfigurierbarem Pull-Up oder Pull-Down oder auch ein AD-Wandler ersparen viel Zusatzbeschaltung. Und auch mit "nur" 16 MHz ist der Arduino Nano noch relativ schnell, da kann man auch mal was berechnen.
Zweckmässig programmiert, sind auch die 328er Arduinos, im IDE entwickelt, ziemlich leistungsfähig. Das Teil verarbeitet immerhin bis zu 16m Instruktionen pro s. Ich baute in der Arbeit mal einen Produktionstester als Teil eines größeren Testsystems mit dem 1284er und die Erfolge waren sehr befriedigend. CPU Performanz und Zuverlässigkeit war absolut kein Thema. Wenn man keine komplizierten Stacks braucht, dann sind 8-bitter zumindest aus eigener Erfahrung für viele Steueraufgaben mehr als geeignet. Und sollte ein Comm-Stack notwendig sein, dann sind ja noch die diversen ESPs da, die dann seriell als Brücke dienen können und die wünschenswerte Netzwerk-Performanz haben. 5V Logik ist für viele Peripherieverbindungen doch angenehm. Aber das soll jeder sehen, wie er mag. Nicht alles Ältere muß übersehen werden. Das Resultat zählt. Duck und weg...
Gerhard O. schrieb: > Zweckmässig programmiert, sind auch die 328er Arduinos, im IDE > entwickelt, ziemlich leistungsfähig. Ein Nano regelt meinen Lötkolben, mein erstes Projekt 2015, was ich in reiner Hardware nicht konnte. In meinem Akkutester regelt ein Nano zwei Kanäle, zeigt Werte auf dem 2004-LCD an und schreibt diese auf eine SD-Karte, allerdings mit Peripherie INA219, MCP4725 plus ein paar FETs. Das endete leider im Kampf mit 99% Speicher. Ein Nano steuert einen Mikrowellenofen mit kaputtem Schaltwerk, Laufzeit und Leistung (PWM) mit zwei Drehpotis einstellbar. Zur Protokollierung einer Spannung läuft ein ProMini plus ADS1115, alle 10s den Wert auf die SD-Karte schreiben schafft der aus einer 18650 LiIon knapp 500 Stunden. Natürlich nur so lange, wie das OLED-Display aus ist, dessen Speicherbadarf mir heftig Ärger bereitet hat. Gerhard O. schrieb: > Ich baute in der Arbeit mal einen > Produktionstester als Teil eines größeren Testsystems mit dem 1284er und > die Erfolge waren sehr befriedigend. CPU Performanz und Zuverlässigkeit > war absolut kein Thema. Ich hatte in der Prüftechnik eine 6502-CPU plus zwei Portbausteine auf Eurokarte, später noch MC68HC805. Arduino war zu der Zeit unvorstellbar, der könnte alles, was ich damals gebaut habe, erheblich einfacher. Aber so oder so, der Florian muß sich bewegen, Arduino kaufen, Testaufbau machen und den bespielen.
Wenn man nicht gerade kompliizierte Communication Stacks braucht, dann bewegt sich die Welt der uC für Steueraufgaben oft im ms Bereich. Naja, und in einer ms, schafft ein 16MHz nahe an immerhin 16000 Instruktionen wenn man von den wenigen Doppeltaktinstruktionen absieht. Da lässt sich in einer ms allerhand erledigen. Das größte Handicap ist, wenn man z.B. gefrässige Peripherien wie Graphic Displays ansteuern möchte, daß zu wenig Speicher da ist. Da tut man sich mit dem 1284er oder 16/32-bit Maschine doch ein wenig leichter. Es muß aber auch erwähnt werden, daß die größeren Brüder, w.z.B. bestimmte Typen der STM32 Familie angenehme Datenautobahnen in der Form von DMA zur Verfügung stellen, teils Graphikunterstützung u.v. A. Performante Features haben. Wer anspruchsvolle Anwendungen dieser Art auf die Beine stellen will, ist mit solchen dafür bestimmten uC besser dran, als mit unterbemittelter HW. Den uC sadistisch zu quälen, um Aufgaben abzuarbeiten für die er nicht wirklich vorgesehen wurde, hat wenig Sinn. Die 8-bitter sind dann in ihren Element, wenn die Aufgaben den Ressourcen gegenüber besser angepasst sind und man nicht Bohnen, ich meine Zyklen zählen will. Manchmal bekomme ich den Eindruck, daß manche Entwickler aus sportlichen Ehrgeiz und technischer Herausforderung das letzte aus der HW herausholen wollen. Sicher kann man das machen, aber man verbaut sich auch viele Wege für zukünftige Erweiterungen, wenn man an der Grenze des Möglichen operieren will. Ich ziehe vor, vernünftige Ressource Reserven übrig zu haben. In der Firma war das schon einige Mal nützlich. Bei High-Volume Produkten die nachher nicht mehr gewartet werden müssen und wo es auf fraktionale Pennyersparniss ankommt, sind natürlich andere Maßstäbe anzulegen. Im Hobbybereich und niedrigen Stückzahlen in Industriebereichen, ist eine gewisse Großzügigkeit durchaus von zukünftigen Nutzen, wenn der Kunde Erweiterungen wünscht oder die Anwendung einen gewissen "Creep Factor" aufweist... Es ist auch zweckmässig, die uC so zu wählen, daß man bestimmte Familiencharakteristiken frei auswählen kann. Im Prototyp Stadium nimmt man z.B zuerst eine größere Speichervariante, entwickelt die Anwendung, und erst danach, legt man für den folgenden ersten Produktionszyklus eine Variante fest die dann weniger kostet und ausreichend ist. Man weiß aber dann, daß man oben noch Ellbogenplatz hat. Es kommt in der realen Welt vor, daß man vertrieblich zu knapp rechnet und später feststellen muß, daß signifikante Nachentwicklung notwendig ist, wenn sich die Ansprüche erweitern. Ich pflege meine Design nach Möglichkeit von Groß auf klein anzupassen, mit Erweiterungspfaden schon vorgesehen. Das hat sich bei uns schon ab und zu ausgezahlt, weil die HW für zukünftige Erweiterungen schon geplant war. Unbestückte Komponenten Pads sind in der LP Fertigung oft keine reale extra Ausgabe, solange der Platz da ist. Duck und weg...
"Zur Protokollierung einer Spannung läuft ein ProMini plus ADS1115, alle 10s den Wert auf die SD-Karte schreiben schafft der aus einer 18650 LiIon knapp 500 Stunden. Natürlich nur so lange, wie das OLED-Display aus ist, dessen Speicherbadarf mir heftig Ärger bereitet hat." Ich bin überrascht, daß Du dann nicht lieber LCDs auf HD44780 o.ä. Ebene verwendest. Die sind viel sparsamer im Konsum von Daten. Alternativ hat es auch Sinn einen Optiboot Bootloader auf einen 1284er aufzuspielen und dann mit dem Arduino IDE zu arbeiten. So eine Erweiterung beglückt immerhin mit acht Mal soviel Speicher. Der 1284er spürt dann das OLED Display fast nicht. Allerdings wäre DMA schon wünschenswert. Was mich betrifft, vermeide ich Graphikdisplays lieber bei 8-bittern. Da haben gewisse STM32s schon den Vorteil, das Display vollkommen entkoppelt zu füttern und man schreibt nur auf den internen Frame-Buffer.
Gerhard O. schrieb: > Naja, und in einer ms, schafft ein 16MHz nahe an immerhin 16000 > Instruktionen wenn man von den wenigen Doppeltaktinstruktionen absieht Leider kann so eine einzelne 8-Bit-Instruktion nicht so viel. Die ARMs können in einem einzelnen Takt mehr machen. Gerhard O. schrieb: > daß die größeren Brüder, w.z.B. bestimmte Typen der STM32 Familie > angenehme Datenautobahnen in der Form von DMA zur Verfügung stellen, > teils Graphikunterstützung u.v. A. Performante Features haben. Wer > anspruchsvolle Anwendungen dieser Art auf die Beine stellen will, ist > mit solchen dafür bestimmten uC besser dran, als mit unterbemittelter > HW. Das hat noch ganz andere Vorteile: Bei Verwendung von DMA kann man den Prozessor in den Idle-Mode schicken und den Stromverbrauch reduzieren; das können die meisten 8bitter so nicht. Gerhard O. schrieb: > Manchmal bekomme ich den Eindruck, daß manche Entwickler aus sportlichen > Ehrgeiz und technischer Herausforderung das letzte aus der HW > herausholen wollen Das kommt mir auch oft so vor. Das kann ja durchaus Spaß machen, aber das als Mittel der Wahl für "richtige" Projekte, oder eben auch als Einstieg darzustellen macht keinen Sinn. Gerhard O. schrieb: > Und sollte ein Comm-Stack notwendig sein, dann sind ja noch die diversen > ESPs da, die dann seriell als Brücke dienen können Naja, dann kann man auch einfach alles auf dem ESP32 laufen lassen. Relativ sinnlos da noch einen AVR dran zu schnallen außer man hat ganz spezifische IO-Anforderungen. Die allermeiste Peripherie ist heute auf 3,3V (und weniger) ausgelegt.
Hi Florian schrieb: > nehm es > mir also bitte nicht übel wenn ich mich nicht tiefer mit deinem Buch > befasse. Kein Problem, warum sollte ich. Danke auch für deine Antwort und die klärenden Worte. Ich denke, jetzt werden auch die C++ Programmierer dir bessere Hilfestellung geben können. Viel Erfolg. Gruß oldmax
Angehängte Dateien:
-
1_mini.jpg
330 KB -
5_min.JPG
460 KB -
6_min.JPG
460 KB -
F1_min.JPG
770 KB
Tilo R. schrieb: > (...) Arduino als Referenz, zum Vergleichen (...) So eine Arduinoreferenz ist immer ganz gut – eine habe ich auch, um zu schauen ggfs. zu überprüfen, was die Arduinojünger wieder für einen Unfug damit treiben – manche sind sogar davon überzeugt, damit alles machen/steuern zu können, egal ob es sich um eine Kamera, einen MP3-Dekoder oder gar ein Raumschiff handelt – nun ja, manche Leute sollte man mit sachlichen Argumenten lieber nicht aufklären oder überzeugen, denn der blinde Fanatismus ist auch in diesem Milieu weitverbreitet. Ich hatte mir anfangs auch mal 10-20 Pro-Minis gekauft, um damit wegen der geringen Größe mit ATMEGAs arbeiten zu können, als ich aber meine eigenen Platinen entworfen hatte, habe ich diese Pro-Minis dann quasi zum gleichen Preis verkauft und davon auch nur 2-3 Stück als Referenz oder Erinnerung behalten. Das gleiche gilt auch für ATMEGAs in PDIP40. Mit den STM32 und Nucleos ist das so ähnlich passiert – ich habe hierfür eigene Leiterplatten, optional auch gleich als fertig bestückte. Da sich die Welt weiterdreht, kommen im Laufe der Zeit immer neue Sachen hinzu, den MKII benutze ich mittlerweile auch sehr selten, weil der SNAP-PG164100 es einfach besser kann.
von Gregor J. (Firma: Jasinski) (gregor_jasinski) 27.12.2024 09:41 >So eine Arduinoreferenz ist immer ganz gut – eine habe ich auch, um zu >schauen ggfs. zu überprüfen, was die Arduinojünger Bist du dir sicher, dass es der richtige ist? Vielleicht ist der hier besser: https://store.arduino.cc/en-de/products/portenta-h7
Christoph M. schrieb: > Bist du dir sicher, dass es der richtige ist? Ja, ziemlich, denn mit Arduinos oder Arduino-IDE arbeite ich nicht und solche geschminke Clowns oder etwas Vorgegaukeltes brauche ich nicht, da ich mit meinen STM32 direkt arbeite – egal, ob F030, F4 oder H7.
Gregor J. schrieb: > Ich hatte mir anfangs auch Im Grunde meine Worte, zumindest dieser Teil. Einstieg mit Arduino, dann eigene Entwicklung, egal welche Richtung. Vielleicht nicht für alle, aber für viele gangbar. Merke: Dein Weg funktioniert für dich! Das heißt aber nicht, dass es für die anderen 8 Milliarden Menschen auch der ideale Weg ist. ---------- Gregor J. schrieb: > was die Arduinojünger wieder für einen Unfug > ... > blinde Fanatismus Fanatismus geht meist/immer damit einher, andere Menschen (oder was sie tun/denken) abzuwerten und die eigene Einstellung für die einzig richtige zu halten. Ist dieses, dein Verhalten, wirklich so von dir beabsichtigt Gregor J. schrieb: > Vorgegaukeltes brauche ich nicht, da > ich mit meinen STM32 direkt arbeite – egal, ob F030, F4 oder H7. Meinst du wirklich, dass die Entwicklung eines H7 Boards ein guter Einstig in die µC Welt ist? Ich denke eher, dass es ein paar Jahre Beschäftigung braucht, bis das Vorhaben relativ frustfrei durch geht.
Arduino F. schrieb: > Meinst du wirklich, dass die Entwicklung eines H7 Boards ein guter > Einstig in die µC Welt ist? Aus dem Kontext geht hervor, dass es bei dieser Textpassage nicht um einen Einstieg in die µC-Welt ging – mein expliziter Vorschlag dazu liegt etwas weiter oben, muss man etwas scrollen und vielleicht nochmal nachlesen.
:
Bearbeitet durch User
Arduino F. schrieb: > Fanatismus geht meist/immer damit einher, andere Menschen (oder was sie > tun/denken) abzuwerten und die eigene Einstellung für die einzig > richtige zu halten. Wow - so prägnant, klar und kurz (im besten Sinne) habe ich das noch nicht formuliert gesehen. So ist es - es sind tatsächlich schon einzelne Worte welche die Einstellung der wirklichen Fanatiker (oft erkennen sie selbst ihren Fanatismus und vor allem ihre verletzende, abwertende Art gar nicht mehr, so sehr leben sie in ihrer Kopfwelt) zeigen. Solche einzelnen Worte sind nicht witzig oder gar feine Ironie sondern zutiefst arogant und abwertend.
Gerhard O. schrieb: > Die rote AVR Bord von Gregor gefällt mir eigentlich. Der Atmega328 ist in diesem Format alerdings schon deprecated (not recommended for new design).
Gerhard O. schrieb: > Die rote AVR Bord von Gregor gefällt mir eigentlich. Ich habe solche Platinen auch für den ATMEGA328P in TQFP32 und auch welche für den neueren ATMEGA328PB – unbestückt und mit grüner Lötstoppmaske. Bei Bedarf einfach über private Nachricht mich kontaktieren. Für manche Bastler sind die Platinen für PDIP attraktiver, weil man den Chip hier sehr einfach einlöten oder auch eine Präzisionsfassung verwenden kann – manche Leute möchten dann die mit Arduino-IDE programmierten ICs umstecken. Ist alles eigentlich auch abwärtskompatibel – also auch für ATMEGA168PA, ATMEGA88PA usw, sofern das Pinout gleich ist, ich persönlich verwende aber nur noch die 328P oder 328PB, d.h. mit 32KB Flash.
:
Bearbeitet durch User
Hi >> Fanatismus geht meist/immer damit einher, andere Menschen (oder was sie >> tun/denken) abzuwerten und die eigene Einstellung für die einzig >> richtige zu halten. >Wow - so prägnant, klar und kurz (im besten Sinne) habe ich das noch >nicht formuliert gesehen. Ich finde es als Frechheit wenn solche Sprüche vom ehemaligen "AduinFanboy" (jetzt "arduinof") kommen. Fanatismus ist ihm wahrlich aus eigenem agieren nicht fremd. Wer im Glashaus sitzt ... . MfG Spess
Spess53 .. schrieb: > ... Stimmt, ich glaube, ich erinnere mich, dir habe ich doch auch schon mal ordentlich den Kopf gewaschen. Oder?
Gerhard O. schrieb: > "Zur Protokollierung einer Spannung läuft ein ProMini plus ADS1115, alle > 10s den Wert auf die SD-Karte schreiben schafft der aus einer 18650 > LiIon knapp 500 Stunden. Natürlich nur so lange, wie das OLED-Display > aus ist, dessen Speicherbadarf mir heftig Ärger bereitet hat." > > Ich bin überrascht, daß Du dann nicht lieber LCDs auf HD44780 o.ä. Ebene > verwendest. Die sind viel sparsamer im Konsum von Daten. Es soll mit 3,3V laufen und einigermaßen klein sein, geeignete LCD kenne ich nicht. Was mir nicht klar war, dass das OLED sehr viel RAM braucht. Es war schwierig, aber ist zur Funktion gekommen und tut, was es soll. Beitrag "Re: Arduino China-ProMini stürzt ab" > Alternativ hat es auch Sinn einen Optiboot Bootloader auf einen 1284er > aufzuspielen und dann mit dem Arduino IDE zu arbeiten. Man kann den Optiboot auch auf Nano und Pro-Mini spielen, um etwas mehr Programmspeicher zu bekommen. Rettet nichts daran, dass RAM knapp ist. Gregor J. schrieb: > So eine Arduinoreferenz ist immer ganz gut – eine habe ich auch, um zu > schauen ggfs. zu überprüfen, Weiter vorne zeigte ich mein Testboard, eben, um mal zu gucken. > was die Arduinojünger wieder für einen Unfug damit treiben > – manche sind sogar davon überzeugt, damit alles > machen/steuern zu können, egal ob es sich um eine Kamera, einen > MP3-Dekoder oder gar ein Raumschiff handelt – nun ja, manche Leute > sollte man mit sachlichen Argumenten lieber nicht aufklären Kannst Du auch Kommentare ohne überflüssige Angriffe? Bist Du ein Zweitnick von Heinr...? Gerhard O. schrieb: > Die rote AVR Bord von Gregor gefällt mir eigentlich. Mir garnicht, das ist ein hundsgewöhnlicher Arduino-Nano-Clone, der mit einem "Markennamen" überteuert verkauft wird.
Hi
>Stimmt, ich glaube, ich erinnere mich, dir habe ich doch auch schon mal
ordentlich den Kopf gewaschen.
Oder?
Wovon träumst du eigentlich nachts?
Aber Danke für das Beispiel deiner maßlosen Arroganz und
Überheblichkeit. Damit relativierst du deine Aussagen. Du kannst ja
weiterhin herum heulen und dich über die ruchlosigkeit der Arduinogegner
beklagen. Viel Spass weiterhin.
MfG Spess
Arduino F. schrieb: > Stimmt, ich glaube, ich erinnere mich, dir habe ich doch auch schon mal > ordentlich den Kopf gewaschen. > Oder? Damals, als ich mit Arduino angefangen hatte, was sind sie über mich hergefallen. Da warst du so ziemlich der einzige, der sich an meine Seite stellte. Aber auch damals hatte ich schon gesagt, dass Arduino schon bald weite Verbreitung erfährt. Spess jetzt mal ausgenommen, denn er hatte mir auch schon persönlich sehr geholfen, waren diese Unkenrufer recht laut. Das erinnert mich immer an einen Schallplattenladen in Essen. Der Betreiber "CD wird sich niemals durchsetzen!", meinte er. Nach nicht einmal 2 Jahren gab es diesen Laden nicht mehr. Aber woher kommt diese Art? Das ist eigentlich ganz einfach. Zugegebenermaßen haben sich diese Leute die Mikrocontroller sehr hart erarbeitet und hatten damit ein Alleinstellungsmerkmal und sie gehörten zu einer (vermeintlichen) Elite. Mit Arduino konnte auf einmal jeder Depp eine LED blinken lassen und es war nicht mehr besonders Mikrocontroller zu programmieren. Ich habe schon einige dieser, zwar intelligenten Menschen, kennen gelernt. Heute nennt man diese Leute wohl Nerds. Ich habe sie immer Kellerkinder genannt. Weil sie in ihren Kellnern hocken und dort basteln oder funken. (Nichts gegen die Funker) Oft haben diese Leute wenige, echte soziale Kontakte und das einzige was sie haben, ist ihr Alleinstellungsmerkmal. Da fühlen sie sich dann drum beraubt und auf einmal gleichwertig mit den "normalen Menschen ". Vorher mussten sie nicht ihre Kellner verlassen, denn die da draußen waren ihrer Gesellschaft nicht würdig (das haben sie sich zumindest wohl selbst eingeredet). Doch plötzlich sind sie ganz normale Menschen. Dabei waren sie nie, auch nur annähernd eine Art Elite, für die Welt da draußen. Das haben sie bis heute nicht begriffen.
Frank O. schrieb: > Da warst du so ziemlich der einzige, der sich an meine Seite stellte. Ich danke dir für die Blumen. Frank O. schrieb: > Damals, als ich mit Arduino angefangen hatte, was sind sie über mich > hergefallen. Nicht nur über dich! Mein Schlüsselerlebnis hier war, als ein 11 jähriger Arduino Anfänger, von mindestens 5 Erwachsenen mit Verachtung überschüttet wurde, weil er/sie/es irgendwas noch nicht wusste. Erst dann habe ich mich ArduinoFanBoy genannt. Daraufhin haben sich dann so ziemlich alle Arduino Basher bei mir "gemeldet". Einen nach dem anderen konnte ich sie mir dann vornehmen. Das ist auch wohl das, was unser Spess53 als "meinen Fanatismus" diagnostiziert. Mittlerweile ist es, in der Hinsicht, hier deutlich ruhiger geworden.
Arduino F. schrieb: > Mein Schlüsselerlebnis hier war, als ein 11 jähriger Arduino Anfänger, > von mindestens 5 Erwachsenen mit Verachtung überschüttet wurde, weil > er/sie/es irgendwas noch nicht wusste. > Erst dann habe ich mich ArduinoFanBoy genannt. > Daraufhin haben sich dann so ziemlich alle Arduino Basher bei mir > "gemeldet". Ich weiß, ich war oft genug dabei. Nur war ich durch Scheidung, Tod meines Sohnes, mehrmals Krebs, lange Zeit raus.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.