Hallo.
Ich wollte mal fragen ob es stimmt, dass es relativ egal ist mit welchem
Mikrocontroller man anfängt, solange es kein Arduino ist, da wenn man
einen uC wirklich verstanden hat, es relativ einfach ist sich in andere
einzuarbeiten.
Würdet ihr das so unterschreiben?
Wie lange braucht ihr um euch in einen neuen uC einzuarbeiten?
Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger
heutzutage raten anzufangen?
Habe Elektrotechnik und Softwaretechnik Kenntnisse, könnte also sofort
damit anfangen.
bloody_beginner schrieb:> solange es kein Arduino ist
Seltsame Einschränkung!
Denn es gibt keinen Arduino µC!
bloody_beginner schrieb:> Wie lange braucht ihr um euch in einen neuen uC einzuarbeiten?
1/2 Jahr, bis 1 Jahr.
So ca. und ohne Gewähr, da stak abhängig von Type und Vorwissen.
bloody_beginner schrieb:> Ich wollte mal fragen ob es stimmt, dass es relativ egal ist mit welchem> Mikrocontroller man anfängt, solange es kein Arduino ist
Der Arduino ist aber kein µC.
Auf einer Platine namens Arduino können verschiedene µC sitzen.
Bevor ich meine Frage gestellt habe, habe ich natürlich schon hier im
Forum recherchiert und bin oftmals auf die Aussage gestoßen, dass man
eine Abschlussarbeit bei der ein Arduino verwendet wurde, nicht ernst
nehmen kann oder dass man sofort mit einem "uC" anfangen sollte.
Ok, Arduinos sind keine uC's, könnte man sie dann Launchpads nennen?
Ich dachte bis jetzt immer: uC = uP + Peripherie, also dass sie quasi
wie ein Entwicklungsboard sind.
Joachim B. schrieb:> bloody_beginner schrieb:>> könnte also sofort>> damit anfangen.>> wer hindert dich?
Niemand, ich möchte nur nicht "blind" damit anfangen. Beim
Programmierenlernen war ich z.B. so dumm und wollte mit C++ und
Assembler anfangen, hat nicht so recht geklappt. Hätte ich damals im
Forum nachgefragt bevor ich damit gestartet hätte, dann wäre mir dieser
Fehler wahrscheinlich erspart geblieben.
Arduino Fanboy D. schrieb:> 1/2 Jahr, bis 1 Jahr.> So ca. und ohne Gewähr, da stak abhängig von Type und Vorwissen.
Wenn ich fragen darf, wie kann man sich die Einarbeitung vorstellen?
Du bist ja während der Einarbeitung schon produktiv, nehme ich an.
Muss man dann übertrieben oft im Datenblatt nachschauen, während man
sein Projekt realisiert und kämpft mit Bugs, die daher rühren dass man
die Architektur noch nicht versteht?
Eine Masterarbeit dauert z.B. 6 Monate, wäre es realistisch in dieser
Zeit ein mikrocontrollerbasiertes Projekt zu erstellen, zu einem uC den
man noch nicht kennt, wenn man Vorwissen mitbringt?
spess53 schrieb:> Hi>>>war ich z.B. so dumm und wollte mit C++ und>>Assembler anfangen, hat nicht so recht geklappt.>> Welcher Teil hat nicht geklappt?>> MfG Spess
Assembler für Desktopanwendungen zu lernen war ziemlich hirnrissen :/
C++ beherrsche ich mittlerweile, aber so richtig bin ich ins
Programmieren dann erst mit Java eingestiegen. Die Fehlermeldungen
aufgrund von Templates und co. sind in C++ einfach nicht
anfängerfreundlich.
spess53 schrieb:> Hi>>>war ich z.B. so dumm und wollte mit C++ und>>Assembler anfangen, hat nicht so recht geklappt.>> Welcher Teil hat nicht geklappt?>> MfG Spess
Und vorallem welche Sprache wäre weniger dumm gewesen?
Willst du nur auf den "Mittelweg zwischen Asm und C++" hinaus: C?
Wenn die Aufgabe einfach ist, sieht C++ praktisch aus wie C, daher würde
die Aussage eher wenig Sinn machen.
EDIT:
bloody_beginner schrieb:> Assembler für Desktopanwendungen zu lernen war ziemlich hirnrissen :/>> C++ beherrsche ich mittlerweile, aber so richtig bin ich ins> Programmieren dann erst mit Java eingestiegen. Die Fehlermeldungen> aufgrund von Templates und co. sind in C++ einfach nicht> anfängerfreundlich.
Jetzt sind wir aber weg von Mikrocontrolern, oder?
Ja, java ist schlicht anders als C und C++ und erst recht als Asembler.
Ist auch eine meiner Lieblingssprachen. Aber für uC verfügbar ist sie
halt leider nicht.
Wenn man uCs programmieren will, muss man bereit sein zu leiden ;)
Hardwarenahes Zeug ist harter Tobak. Dafür hat dieser Bereich einfach
Vorteile die man mit PCs wo Java und Co. läuft, prinzipiell nicht
bewerkstelligen kann.
Studierst du irgendein allgemeineres Feld der Softwareentwicklung?
Also Software für Desktops und Server?
Wenn ja, würde ich nicht empfehlen als Abschlussarbeit, jetzt in den
Mikrocontroelrbereich einzusteigen, auchw enn du hobbymäßig Erfahrung
mit Elektronik haben solltest.
Es gibt schlicht andere Studiengänge für die so eine Arbeit viel eher
angebracht wäre.
bloody_beginner (Gast)
>Bevor ich meine Frage gestellt habe, habe ich natürlich schon hier im>Forum recherchiert und bin oftmals auf die Aussage gestoßen, dass man>eine Abschlussarbeit bei der ein Arduino verwendet wurde, nicht ernst>nehmen kann oder dass man sofort mit einem "uC" anfangen sollte.
Geht so. Wenn Du so was hier als Abschlussarbeit machst, kommst Du auch
mit dem Arduino durch:
https://en.wikipedia.org/wiki/ArduSat
Alex G. schrieb:> Jetzt sind wir aber weg von Mikrocontrolern, oder?> Ja, java ist schlicht anders als C und C++ und erst recht als Asembler.> Ist auch eine meiner Lieblingssprachen. Aber für uC verfügbar ist sie> halt leider nicht.>> Wenn man uCs programmieren will, muss man leider bereit sein zu leiden> ;)> Hardwarenahes Zeug ist harter Tobak. Dafür hat dieser Bereich einfach> Vorteile die man mit PCs wo Java und Co. läuft, prinzipiell nicht> bewerkstelligen kann.
Ja, das bezog sich nur auf die Frage "welcher Teil an meinem damaligen
Vorhaben dumm gewesen ist". Also hätte ich im Forum nachgefragt, hätte
mir wohl niemand ernsthaft empfohlen Assembler zu lernen, wenn ich
Desktopanwendungen schreiben will. Bin auf die Idee gekommen wegen einem
Artikel in dem Assembler hoch gelobt wurde, als die schnellst Sprache
die nur echte Freaks beherrschen.. Aber lassen wir das :)
Bin davon ausgegangen die uC's in C zu programmieren.
bloody_beginner schrieb:> Ich wollte mal fragen ob es stimmt, dass es relativ egal ist mit welchem> Mikrocontroller man anfängt, solange es kein Arduino ist, da wenn man> einen uC wirklich verstanden hat, es relativ einfach ist sich in andere> einzuarbeiten.
Die verwendeten Prinzipien und Konzepte sind schon ähnlich, vor allem
bei den µCs aus einer Ära. Aber zwischen einem alten PIC10 und einem
aktuellen Cortex-H7 gibt es schon deutliche Unterschiede...
> Wie lange braucht ihr um euch in einen neuen uC einzuarbeiten?
Das hängt auch sehr davon ab wie tief Du da einsteigen willst.
Geht es nur darum, ein Programm sequentiell ablaufen zu lassen und ein
bischen die Peripherie zu bedienen?
Oder willst Du Dein eigenes RTOS für den µC implementieren? Dann kämen
zu der Peripherie noch die ganzen Details der Architektur hinzu, mit
Interrupt-Prioritäten, verschiedenen Speicherbereichen,
Speicherschutz,... - aktuelle ARM-Cortexe haben da schon ne ganze Menge
Features wenn man mal etwas tiefer graben geht.
Für die meisten Projekte muss man aber nicht jede "dunkle Ecke" des µCs
detailliert kennen.
bloody_beginner schrieb:> Muss man dann übertrieben oft im Datenblatt nachschauen,
2 Monitore
Links das Datenblatt und sonstige Dokumentationen.
Rechts die IDE.
Ob das Übertreiben ist, überlasse ich deinem fachkundigen Urteil.
bloody_beginner schrieb:> Du bist ja während der Einarbeitung schon produktiv, nehme ich an.
Wenn ich produktiv sein will/muss, nehme ich bekanntes.
bloody_beginner schrieb:> Wenn ich fragen darf, wie kann man sich die Einarbeitung vorstellen?
Ich nehme mir ein Teilgebiet, z.B. ADC, DMA, Timer, und arbeite es aus,
bis ich es hinreichend weit durchdrungen habe.
bloody_beginner schrieb:> Sprache die nur echte Freaks beherrschen..
Und das hat dich nicht abgeschreckt? ;)
Naja, fürchte Arduino Fanboy da oben hat Recht. grade durch die
Hardwarenähe, muss man einiges auf dem Chip gemacht haben um ihn zu
durchschauen und das Beste raus zu holen.
Im Berufsleben wirst du zwangsläufig schon in dieser Phase Produktiv
sein müssen weil Projekte da kurzlebiger sind, als bei PC Software.
Dafür ist der Umfang oft auch nicht vergleichbar.
Für eine Abschlussarbeit würde ich ehrlich gesagt etwas empfehlen was du
am PC (auch in C) simulieren kannst. Also nichts was von
Hardwarefeatures zwingend abhängig ist (wie Kommunikationsprotokolle),
denn die EInarbeitung dahin ist zu langwierig.
Alex G. schrieb:> bloody_beginner schrieb:>> Sprache die nur echte Freaks beherrschen..> Und das hat dich nicht abgeschreckt? ;)
Naja, ich verweise mal auf den
https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt
Mittlerweile wäre ich natürlich abgeschreckt, aber damals habe ich mich
komischweise angesprochen gefühlt :)
Gerd E. schrieb:> Das hängt auch sehr davon ab wie tief Du da einsteigen willst.>> Geht es nur darum, ein Programm sequentiell ablaufen zu lassen und ein> bischen die Peripherie zu bedienen?>> Oder willst Du Dein eigenes RTOS für den µC implementieren?
bloody_beginner schrieb:> Alex G. schrieb:>> bloody_beginner schrieb:>>> Sprache die nur echte Freaks beherrschen..>> Und das hat dich nicht abgeschreckt? ;)>> Naja, ich verweise mal auf den> https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt> Mittlerweile wäre ich natürlich abgeschreckt, aber damals habe ich mich> komischweise angesprochen gefühlt :)>> Gerd E. schrieb:>> Das hängt auch sehr davon ab wie tief Du da einsteigen willst.>>>> Geht es nur darum, ein Programm sequentiell ablaufen zu lassen und ein>> bischen die Peripherie zu bedienen?>>>> Oder willst Du Dein eigenes RTOS für den µC implementieren?
Also eher ersteres :)
Aber irgendwann muss man ja mal anfangen. Wenn nicht bei der
Abschlussarbeit, dann ja im Beruf. Aber ich denke dann wäre es doch
sicherlich besser schon in der Abschlussarbeit damit anzufangen. Wenns
dann halt keine 1,0 wird, sondern eine 2,0, könnte ich auch noch damit
leben.
bloody_beginner schrieb:> Wie lange braucht ihr um euch in einen neuen uC einzuarbeiten?
Kommt drauf am: Wie gut ist der Herstellersupport, gibt es Beispiele
oder wurde absichtlich alles vercryptet dokumentiert damit man es auf
die mühsame Art meistern muss, von Fehler zu Fehler.
> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger> heutzutage raten anzufangen?
Arduino.
Nein, nicht wirklich, dessen Doku ist auch unter aller Sau, die
Imkompatibilitäten (unterschiedlicher "Arduinos") schrecklich und ebenso
undokumentiert, ausserdem macht ihn die Software schnarchlangsam und die
IDE ist rudimentär.
8051 ?
Hat man wenigstens am meisten von, jeden besonders ausgestatteten uC
gibt es zunächstmal immer mit 8051 Kern. Braucht man LCD mit
Niedrigstrom 8051, braucht man Hochstrom SH79F3212, braucht man 12V
Versorgungsspannung HVC22xyA, 24 bit A/D ADUC824, 200MHz TSCR8051L,
braucht man Hochtemperatur bis 300 GradC HT83C51, das alles gibt es bei
anderen uC-Familien nicht, billig für 5ct PMS150C, ausser man braucht
einen uC der ab 0.25V läuft: EtaCore M3, der stammt nicht aus der
8051-Familie sondern ARM-Familie, ein 8051 braucht 0.9V C8051F90.
Allerdings ist 8051 nicht wirklich gut in C zu programmieren und auch
nicht in Assembler.
ARM ?
Gerade ST mit seinen Cortex hat viele ARM Prozessoren, und die lassen
sich ordentlich in C programmieren: Aber: Die Peripherie ist aufwändig
und komplizierter, für Anfänger nicht so doll. Selbst wenn man sie
Arduino-Style programmiert, sind die Inkompatibilitäten schwere
Stolpersteine.
6805 ?
Solider von Neumann Prozessor, gut dokumentiert
http://www.nxp.com/assets/documents/data/en/reference-manuals/M68HC05TB.pdf
, leider alt.
Letzlich empfehle ich die AVR Famile über Atrmel Studio zu
programmieren.
Ja, wohl wahr. Wundert mich dass das noch nirgends im Studium gefordert
war...
Da lob ich mir die Hochschule im vergleich zur Uni.
Aber das bringt uns zurück zu Joachim's Frage: Was hindert dich daran
anzufangen?
Oder was spielt den Deine Frage bezüglich vergleichbarkeit für eine
Rolle?
Du musst dich schließlich mit uCs befassen. So oder so.
Nur wenn du richtung Consulting gehst, kannst du vieleicht den
Programmierteil umgehen...
Früher hätte ich Dir einen C64/Amiga empfohlen - da habe ich Basic und
Assembler mit "gelernt". Aber diese Zeiten sind lange vorbei.
Ansich bietet die Arduinoplattform einen schönen Einstieg (nur die kenne
ich). Die Atmel-AVRs kann man auch mit Assembler füttern. Letztendlich
fällte nach dem Compilieren eh eine Binärdatei an die auf den uC geladen
wird.
Zu Deinen Fragen: "uC Egal?" ja, sind ähnlich.
"Einarbeitung?": Atmel-AVR (Arduino) für kleine Projekte: ein
Wochenende.
Ich würde was kleines nehmen. Bei größere uC würde ich die eher in eine
Hochsprache programmieren (MicroPython hatte ich mir auch mal
angesehen).
"Anfangen mit?": Arduino-Plattform ;-)
Das wichtigste ist ein Ziel zu haben, der Rest geht wie von selbst. Ich
hatte damals am C64 Relays ansteuern wollen und Grafik gemacht
(Rasterbars, 3D-Strichgrafik).
bloody_beginner schrieb:> Aber irgendwann muss man ja mal anfangen. Wenn nicht bei der> Abschlussarbeit, dann ja im Beruf.
Oder eben einfach mal privat, als kleine Bastelei.
Arduinos kann man übrigens auch ohne die Arduino-IDE und deren Framework
benutzen. Dann ist das, was übrig bleibt, ein gut handhabbares
Controller-Experimentierboard mit bisschen drumrum
(Programmierschnittstelle bspw.).
Vorteil der kleineren AVRs, wie sie auf vielen Arduinos zu finden sind
ist, dass die Hardware immer noch einigermaßen überschaubar ist. Von da
auf einen größeren umzusteigen, dürfte leichter fallen, als gleich mit
einem Cortex-M7 anzufangen, dessen Referenzhandbuch 2000+ Seiten
umfasst.
Michael B. schrieb:> Arduino.>> Nein, nicht wirklich, dessen Doku ist auch unter aller Sau, die> Imkompatibilitäten (unterschiedlicher "Arduinos") schrecklich und ebenso> undokumentiert, ausserdem macht ihn die Software schnarchlangsam und die> IDE ist rudimentär.
Das ist jetzt aber sehr hart ausgedrückt.
Den Grad an Kompatibilität, den Arduino erlaubt, als zu niedrig zu
bewerten ist blödsinnig.
Dort hat man wenigstens die Chance, seinen Code mit wenig Anpassungen,
auf einen anderen uC zu protieren.
Bei all deinen genannten Beispielen ist das nicht der Fall.
Was bleibt ist, dass man mit Arduino nicht so in die "Tiefe" gehen kann.
Deswegen ist er was für Hobbyprojekte und selten in der Industrie
anzutreffen wobei selbst die Industrie ihn zum Prototyping einsetzt.
Seine Brötchen damit zu verdienen ist nicht ausgeschlossen.
Alex G. schrieb:> Für eine Abschlussarbeit würde ich ehrlich gesagt etwas empfehlen was du> am PC (auch in C) simulieren kannst. Also nichts was von> Hardwarefeatures zwingend abhängig ist (wie Kommunikationsprotokolle),> denn die EInarbeitung dahin ist zu langwierig.
Meinst du mit Kommunikationsprotokollen sowas:
https://de.wikipedia.org/wiki/Serial_Peripheral_Interface
?
bloody_beginner schrieb:> Alex G. schrieb:>> Für eine Abschlussarbeit würde ich ehrlich gesagt etwas empfehlen was du>> am PC (auch in C) simulieren kannst. Also nichts was von>> Hardwarefeatures zwingend abhängig ist (wie Kommunikationsprotokolle),>> denn die EInarbeitung dahin ist zu langwierig.>> Meinst du mit Kommunikationsprotokollen sowas:> https://de.wikipedia.org/wiki/Serial_Peripheral_Interface> ?
Ja, SPI, I2C, 1-Wire und Canbus sind so die bekanntesten.
Darüber werden auch gern Abschlussarbeiten geschrieben auch wenn es
eigentlich Redundant ist weil die schon so oft implementiert wurden (oft
auch schon in Hardware).
Alex G. schrieb:> Das ist jetzt aber sehr hart ausgedrückt.
Die Realität kann manchmal hart sein, vor allem für Leute die die
Realität nicht sehen wollen.
Alex G. schrieb:> Michael B. schrieb:>> Arduino.>>>> Nein, nicht wirklich, dessen Doku ist auch unter aller Sau, die>> Imkompatibilitäten (unterschiedlicher "Arduinos") schrecklich und ebenso>> undokumentiert, ausserdem macht ihn die Software schnarchlangsam und die>> IDE ist rudimentär.> Das ist jetzt aber sehr hart ausgedrückt.
Es ist die Wahrheit. Die mag manchem bitter schmecken.
> Den Grad an Kompatibilität, den Arduino erlaubt, als zu niedrig zu> bewerten ist blödsinnig.
Arduino mit µC zu vergleichen ist blödsinnig. "Arduino lernen" ist
ungefähr wie "den Taxischein machen". "µC lernen" ist dann eher "ein
Auto einmal komplett in Einzelteile zerlegen und wieder zusammenbauen
können und es fährt immer noch". Hat zwar beides irgendwie mit Autos zu
tun, aber das eine Mal bleibt man halt ganz an der Oberfläche.
> Dort hat man wenigstens die Chance, seinen Code mit wenig Anpassungen,> auf einen anderen uC zu protieren.
Auf einen anderen Arduino. Was nur heißt, daß die eigentliche Portierung
von jemand anderem gemacht wurde.
> Was bleibt ist, dass man mit Arduino nicht so in die "Tiefe" gehen kann.> Deswegen ist er was für Hobbyprojekte und selten in der Industrie> anzutreffen wobei selbst die Industrie ihn zum Prototyping einsetzt.> Seine Brötchen damit zu verdienen ist nicht ausgeschlossen.
Klar. Nur sind das halt ganz verschiedene Berufe. So wie Taxifahrer und
Kfz-Mechaniker.
Alex G. schrieb:> Was bleibt ist, dass man mit Arduino nicht so in die "Tiefe" gehen kann.
Das bezweifle ich.
Man muss nicht unbedingt in die Tiefe gehen, um zu Ergebnissen zu
kommen.
Ja.
Aber eine Grenze/Beschränkung legt es einem nicht auf.
Bedenke:
Manchmal sind Behauptungen so dermaßen falsch, dass noch nicht mal das
Gegenteil richtig ist.
@bloody_beginner
bist du denn "algorithmisch" fit?
wie tief du in uC einsteigen möchtest ist dir selbst überlassen. Ob du
in "Hochsprache" oder eher in Assembler programmieren möchtest, hängt
sicherlich von deinen Zielen und Vorstellungen ab.
Überlege dir folgende Übungs-Aufgabe (und "baue" sie nach)
Mach eine "reverse Engineering" eines Fahrrad-Tachos. Kauf dir einen für
5 EUR (vielleicht hast du einen) und baue ihn nach. Da sind ein paar
Anzeigen-Segmente, ein paar Tasten, ein Impulsgebr ... das wars schon.
Die Funktion eines solchen Tachos ist vollständig beschrieben, es gibt
also eigentlich nichts "unbekanntes" an solch einem Teil .
Nun versuche, die Software nachzubauen, d.h. zu beschreiben.
Menueführung mit irgendwelchen Tastendrücken, Uhrzeit, Geschwindigkeit,
zurückgelegte Strecke, Kalorienverbrauch, ...)
Du wirst auf dieser Reise mit Interupt-Routinen, Statemaschinen,
zweckmäßigen (=kompakten) Arithmetik-Operationen und ähnlichen
konfrontiert.
Wenn du das ganze in einer Metasprache formulieren kannst, prima. Setze
es dann um in einer "Hochsprache" (z.B. C), und wenn du dir richtig die
Kante geben möchtest, dann beschreibe das ganze in Assembler deines uC.
Wenn du damit durch bist, dann bist du schon ziemlich weit gekommen.
Dann kannst du dich mit deiner Master-Arbeit beschäftigen, und das
Methodenwissen auf "unbekannten" Gebiet (z.B. die Lageregelung einer
Kugel, welche im Magnetfeld schwebt) anwenden.
Nim irgend etwas, was da ist und mindestens 1 LED hat. Das Demoboard von
der Messe, das Standardprodukt Deiner Uni, oder das, was dein Nachbar
hat.
Es ist egal, ob Du auf einem Hollandrad oder Mountainbike fahren lernst.
Jeder ADC, jeder GPIO ist so verschieden, dass Du besser bis zur
Abschlussarbeit schon Mal 3 Demoboard verschiedener Architekten (auch
gern arduino) zum blinken gebracht hast, um Argumente anderer überhaupt
verstehen zu können.
Und nein, auch nach 10 Jahren mit einem uC gibt es ganze Universen, die
noch brach liegen, wenn es bisher keine Anwendung dafür gabt. Bei den
einen ists capture compare, beim anderen adc-filter-modi, beim dritten
DMA. Von speziellen Motorsteuergeräte-features wie Zündfunk Überwachung
ganz zu schweigen. Und das geht bei der SW genauso weiter, von
Linkerfragen über C++17-features zu Eclipse-einstellungen.
Wegstaben V. schrieb:> Mach eine "reverse Engineering" eines Fahrrad-Tachos.
Wobei man den Nachbau nun nicht gerade mit einem segmentweise
anzusteuernden LCD machen sollte. Die sind schwer zu bekommen und werden
eigentlich nur betrieben, indem man sie an speziell dafür vorbereitete
Controller anschließt.
Für den Nachbau wäre es einfacher (und sinnvoller), ein
Industriestandard-HD44780-LC-Display zu benutzen. Oder aber, man schafft
sich, und steuert zeitmultiplex klassische LED-7-Segment-Anzeigen an.
Das hat auch einen guten Lerneffekt.
Arduino Fanboy D. schrieb:>> Was bleibt ist, dass man mit Arduino nicht so in die "Tiefe" gehen kann.> Das bezweifle ich.
Du bist ja auch ein Arduino-Fanboy. Nennt man wohl betriebsblind.
Ja, das Gute ist: Man kann im Arduino-C-Sourcecode auch einfach den AVR
(oder sonstigen Prozessor) direkt ansprechen, z.B. mit PORTB = 0xFF oder
TIMSK = (1<<TOIE0).
Damit kommt man in die Tiefe. Es hat Ähnlichkeit, als ob man im
C-Programm gewisse Routinen in Assembler schreibt, für mehr Tiefe, um
eben Dinge erreichen zu können die in C nicht mehr gehen.
ABER: Das ist dann nicht mehr die Arduino-Schale, die ihn so berühmt
gemacht hat, die Schale die einen abkapselt vor dem wirklichen
Prozessor. Die will alles in Shields verpacken und nur über speziell
(von anderen, wissenden Programmierern, die in die Tiefe gehen)
geschriebene C++ Objekte ansprechbar haben.
Nur reine Arduino-Programme kann man portieren auf andere Arduinos
anderer Prozessorfamilien. Leider geht in der Praxis nicht mal das.
Michael B. schrieb:>> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger>> heutzutage raten anzufangen?>> Arduino.>> Nein, nicht wirklich, dessen Doku ist auch unter aller Sau, die> Imkompatibilitäten (unterschiedlicher "Arduinos") schrecklich> und ebenso undokumentiert, ausserdem macht ihn die Software schnarchlangsam und
die IDE ist rudimentär.
Na ja ... es ist eine C++ Umgebung und damit eine Sprache, die in der
Industrie umfassend eingesetzt wird.
Schnarchlangsam ist einfach Quatsch.
Die "rudimentäre IDE" bringt schon einmal alles mit, ein Kompilat zu
erzeugen und in den Prof. zu spielen. Übel ist auf jeden Fall der
Editor, aber da kann man problemlos einen ordentlichen Editor anbinden.
Falls es an Dir vorbei gegangen sein sollte: Auch in der Arduino-IDE
kann man 'richtiges C++' einbinden und übersetzen.
> 6805 ?> Solider von Neumann Prozessor, gut dokumentiert> http://www.nxp.com/assets/documents/data/en/reference-manuals/M68HC05TB.pdf,
leider alt.
Ein simpler Kern, wenn man Assembler programmieren möchte, mir noch gut
bekannt.
> Letzlich empfehle ich die AVR Famile über Atrmel Studio zu> programmieren.
Wo ist nun der große Unterschied, ob ich per Arduino-IDE den GCC
übersetzen lasse oder er unter dem Atmel-Studio werkelt?
Jörg W. schrieb:> Für den Nachbau wäre es einfacher (und sinnvoller), ein> Industriestandard-HD44780-LC-Display zu benutzen.
Da wäre jetzt zu entscheiden, ob man eine fertige Library greift, das
ist auch in kommerzieller Programmierung durchaus üblich, oder es von
der Pike auf selbst erzeugt.
> Oder aber, man schafft sich, und steuert zeitmultiplex klassische LED-7-Segment-Anzeigen an.
> Das hat auch einen guten Lerneffekt.
Wie - in C++ oder auf Assemblerebene?
Michael B. schrieb:> Damit kommt man in die Tiefe.
Also ist mein "betriebsblind" doch nicht so blind.
Oder anders:
Der Betreibsblinde sagt: Man kommt in die Tiefe!
Und der Kritiker bestätigt das.
Tipp, an dich:
Beschränkungen entstehen/existieren im Kopf.
Jörg W. schrieb:> Wobei man den Nachbau nun nicht gerade mit einem segmentweise> anzusteuernden LCD machen sollte.
Ich denke bei solchen Sachen eher "TopDown".
wenns ein Pixel-Display ist, dann ist es natürlich "ganz tief unten"
anderes anzusteuern als eine 7-Segment Anzeige.
Die eigentliche "technische" Ansteuerung des Anzeige-Elements (einzelne
Segmente, oder 7-Segment-Anzeigen, oder irgendwelche Pixel in einem
Raster-Display) ist aber "ein wenig höher" im Programmablauf halt
"einfach" irgend eine spezielle Ausgabe-Funktion welche man aufruft.
Wichtiger (und Vorarbeit) ist z.B. zu verstehen, dass man die Anzeige
der ermittelten Größe "Geschwindigkeit" und "Uhrzeit" im
1-Sekunden_Wechsel auf der Anzeige darstellen soll, und die
Geschwindigkeit (und Uhrzeit) im 1/10 Sekunden-Rythmus intern
aktualisiert wird.
Arduino Fanboy D. schrieb:> Alex G. schrieb:>> Was bleibt ist, dass man mit Arduino nicht so in die "Tiefe" gehen kann.> Das bezweifle ich.
Da hast du durchaus recht. Zum einen ist das Abstraktionslayer von
Arduino ziemlich dünn und zum anderen auch sehr durchlässig. So kann man
bspw. problemlos Direktzugriffe auf die Ports in den Code schreiben oder
sogar eine Funktion main() in ein Sketch packen und damit die
Arduino-main() überschreiben. Man könnte also in die Tiefe abtauchen.
Die Frage ist halt nur: wozu? Entweder stellt man sich auf den "Rainer
Anwender" Standpunkt und will alles gemütlich und komfortabel haben.
Dann will man gar nichts über main() oder Ports wissen. Ein Arduino
hat "verdammt nochmal" Pins und die sind einfach durchnumeriert. Und
mehr gibt es nicht zu wissen.
Oder du bist eher von der neugierigen Sorte. Nur warum solltest du dich
dann überhaupt mit der rudimentären Arduino-IDE abgeben wollen, wenn du
doch genauso Code::Blocks oder das AVR-Studio haben könntest. Mit einem
Debugger und Syntax-Highlighting und kontextsensitiver Hilfe.
> Man muss nicht unbedingt in die Tiefe gehen, um zu Ergebnissen zu> kommen.
Natürlich nicht. Wenn man nur Fahrgäste von A nach B bringen will, muß
man nicht wissen, wie ein ABS funktioniert. Oder eine Lambdasonde.
Andererseits gibt es jede Menge Leute, die gerade das deutlich
spannender finden als die Frage, ob man vom Bahnhof zum Opernhaus besser
durch Straße X oder durch Straße Y fährt.
Arduino Fanboy D. schrieb:> Michael B. schrieb:>> Damit kommt man in die Tiefe.> Also ist mein "betriebsblind" doch nicht so blind.> Oder anders:> Der Betreibsblinde sagt: Man kommt in die Tiefe!> Und der Kritiker bestätigt das.
Man kommt nur in die Tiefe, in dem man 'Arduino' um-geht.
> Tipp, an dich:> Beschränkungen entstehen/existieren im Kopf.
Tip an dich:
Der Kopf ist auch für die Intelligenz da.
Wer sich Arduino-Fanboy nennt, aber keine Ahnung hat was Arduino
kennzeichnet, ist einfach nur dumm.
Manfred schrieb:> > ausserdem macht ihn die Software schnarchlangsam und die IDE ist rudimentär.> Schnarchlangsam ist einfach Quatsch.
Schnarchlangsam beginnt damit, 8 bit eines value auszugeben:
for(bit=0;bit<8;bit++)
digitalWrite(OUTPUTPIN0+bit,value&(1<<bit)?HIGH:LOW);
Das ist schnarchlangsam gegenüber einem PORTD=value;
Ja, das ist nicht so flexibel und portierbar, aber genau deswegen ist
dieser Weg beim Arduino-Konzapt blockiert.
Michael B. schrieb:> Schnarchlangsam beginnt damit, 8 bit eines value auszugeben:>> for(bit=0;bit<8;bit++)> digitalWrite(OUTPUTPIN0+bit,value&(1<<bit)?HIGH:LOW);>> Das ist schnarchlangsam gegenüber einem PORTD=value;
Bin mir ziemnlich sicher dass man dann eben so programmiert dass man
nicht erstmal 8 verschiedene Outputs in eine einzelne variable rein
pfercht...
Klar, es gibt sicher Fälle wo man solche Output Masken vorbelegen kann,
um daraus wirklich nen Greschwindigkeitsvorteil zu ziehen.
Das ist aber seltener der Fall, als man vom Komfort profitiert, den
digitalWrite ermöglicht.
Wir kommen langsam vom Thema ab...
bloody_beginner schrieb:> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger> heutzutage raten anzufangen?
Mit gar keinem! Sonst bist du der Nächste, der zwar mit nem Controller
zum Mond fliegen will, aber unglaublich dumme Fragen zur dennoch fast
immer nötigen Analogtechnik stellt.
Hier im Forum finden sich vielleicht 5 threads, bei denen man jemandem
zu einem µC raten sollte. Umgekehrt gibt es sicher 5.000.
Michael B. schrieb:> Wer sich Arduino-Fanboy nennt, aber keine Ahnung hat was Arduino> kennzeichnet, ist einfach nur dumm.
Nunja, du nennst dich "laberkopp"
Hat das keine Berechtigung?
Ja, du darfst mir "keine Ahnung" unterstellen.
Aber ob du damit richtig liegst, das Urteil, überlasse ich lieber
anderen.
Agathe Bauer!!! schrieb:> bloody_beginner schrieb:>> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger>> heutzutage raten anzufangen?>> Mit gar keinem! Sonst bist du der Nächste, der zwar mit nem Controller> zum Mond fliegen will, aber unglaublich dumme Fragen zur dennoch fast> immer nötigen Analogtechnik stellt.>> Hier im Forum finden sich vielleicht 5 threads, bei denen man jemandem> zu einem µC raten sollte. Umgekehrt gibt es sicher 5.000.
Kann es sein das hier manche nur "auf Stress" aus sind?
Naja, an alle anderen: Danke für die Ratschläge.
Ich gehe dann mal schlafen :)
bloody_beginner schrieb:> Kann es sein das hier manche nur "auf Stress" aus sind?
Keine Ahnung wen du meinst, ich habe nur gesagt, wie es tatsächlich
aussieht. Wenn du solche Wahrheiten schon als stressig ansiehst, na dann
wirklich gute Nacht...
bloody_beginner schrieb:> Agathe Bauer!!! schrieb:>> bloody_beginner schrieb:>>> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger>>> heutzutage raten anzufangen?>>>> Mit gar keinem! Sonst bist du der Nächste, der zwar mit nem Controller>> zum Mond fliegen will, aber unglaublich dumme Fragen zur dennoch fast>> immer nötigen Analogtechnik stellt.>>>> Hier im Forum finden sich vielleicht 5 threads, bei denen man jemandem>> zu einem µC raten sollte. Umgekehrt gibt es sicher 5.000.>> Kann es sein das hier manche nur "auf Stress" aus sind?>> Naja, an alle anderen: Danke für die Ratschläge.>> Ich gehe dann mal schlafen :)
Mal sehen ob Du wirklich schlafen gehst:-)
Auch wenn ich jetzt einen mißbilligendem Hurricane an Kritik auslöse,
werde ich allen Unkenrufen zum Trotz für die ersten Schritte doch zum
Arduino raten. Auch wenn es sich teilweise wie mit Windmühlenflügel zu
kämpfen anfühlt:-)
Pro: Extrem billig Elektronik und narrensichere Installation. Man kann
sofort loslegen. Installieren, einstecken und es ist "Ready for Action".
Da Arduino auf GCC als Toolchain aufgebaut ist, besteht der wesentliche
Unterschied, daß beim Arduino die main() in einer eigenen Datei
existiert und der Anwender im einfachsten Fall nur die Sketch Datei mit
der "ino" Dateikennung. Für den Anwender existiert die traditionelle
main Funktion lediglich in den zwei Funktionen setup und loop. Un diese
wiederum befinden sich in einer versteckten main.cpp Datei. Neben ein
paar Vereinfachungen (keine Funktion Prototypen im "ino" notwendig) kann
man jetzt in stinknormalen C oder C++ loslegen.
Im einfachsten Fall belegt Arduino immer:
Timer0 als Zeitbasis für die millis() Funktion, PWM und den UART. Sonst
kann man alles in normaler Weise durch direkten SFR Zugriff in gewohnter
Weise beeinflussen und man ist nicht gezwungen Arduino Bibliotheken zu
verwenden, wenn man nicht will. Bei den Serial Routinen fügt man sich am
besten und verwendet die Serial.print Bibliothek. Ab diesen Zeitpunkt
programmiert es sich im Arduino Umfeld auch nicht viel anders wie in
nicht-Arduino Situationen.
Auch wenn die Arduino IDE von fast allen leuten von links bis rechts
kritisiert wird(ob zu recht oder nicht, mag dahin gestellt sein), kann
man durchaus zügig und effektiv damit arbeiten. Wie schon erwähnt
funktioniert es auch mit externen Editor falls man so will. Ich habe das
auch schon gemacht. Für kleinere Projekte mit nur einer ino Datei geht
es auch in der Arduino IDE ganz zügig und bequem. Syntax Highlighting
funktioniert ja und was will man Anfang wirklich mehr? Auch bei Arduino
lohnt es sich zusammen mit dem Datenblatt/User Manual und App Notes zu
arbeiten um nicht blind im Arduino Bibliotheken Kokon operieren zu
müssen. Man hat ja mittels der SFR Register kompletten Zugang zur AVR
Hardware und auch Inline-Assembler läßt sich einfügen. In der Hinsicht
besteht wenig Unterschied zu anderen Entwicklungs Paradigmen.
Mein Rat: Probiers aus und bilde Dir Deine eigene Meinung. An
garantierter Zuverläßigkeit und Billigkeit für den Anfang ist Arduino
nicht überbietbar. Und man kann es sich so einfach oder kompliziert
machen wie man will. 99% aller Real World Projekte lassen sich auch im
Arduino Program Universum realisieren. Verfall nicht so wie viele in der
berüchtigten "Analysen Paralyse". Go for it! Man muß nicht immer alles
zu Tode diskutieren.
Für HW ausprobieren gibt es unzählige Bördchen in der Bucht mit denen
mal viele Periphere Beschaltungen ohne großen Aufwand testen kann.
Später mit mehr Erfahrung kann man immer noch auf normale
Entwicklungsumgebungen umsteigen.
Da gibt es ha noch viele andere Möglichkeiten, wie z.B. MSP430, STM32,
um nur zwei zu nenen. Die Cortexen sind aber wesentlich anspruchsvoller
in der Peripheriebenutzung.
Guck auch hier für Nützliches zum Thema:
https://www.mikrocontroller.net/articles/Mikrocontroller_Vergleich
Nur My two Cents worth...
bloody_beginner schrieb:> Also hätte ich im Forum nachgefragt, hätte> mir wohl niemand ernsthaft empfohlen Assembler zu lernen, wenn ich> Desktopanwendungen schreiben will.
Nicht einmal ich hätte das getan. Für kleine µC hingegen: auf jeden
Fall.
> Bin auf die Idee gekommen wegen einem> Artikel in dem Assembler hoch gelobt wurde, als die schnellst Sprache
Das ist so, zumindest potentiell. Allerdings: ein Anfänger wird es
i.d.R. nicht schaffen, damit nennenswert schnelleren Code zu schreiben
als ein guter C oder C++ Compiler liefert.
> die nur echte Freaks beherrschen..
So what? Es gibt auch nur vergleichweise wenige Leute, die wirklich C
oder gar C++ umfassend beherrschen.
Diese Sprachen werden nur deswegen häufiger benutzt, weil man auch mit
einer recht kleinen Teilmenge des Sprachumfangs noch Programme schreiben
kann. Es sind dann beschissene, ineffiziente und häßliche Programme,
aber, so lange sie das tun, was sie sollen...
bloody_beginner schrieb:> Hallo.> Ich wollte mal fragen ob es stimmt, dass es relativ egal ist mit welchem> Mikrocontroller man anfängt, solange es kein Arduino ist, da wenn man> einen uC wirklich verstanden hat, es relativ einfach ist sich in andere> einzuarbeiten.> Würdet ihr das so unterschreiben?
Ja. Ich habe 1981 mit dem Z80 angefangen und ein halbes Jahr gebraucht,
bis ich einigermaßen fit war. Für den nächsten, den 6502, habe ich dann
nur noch 6 Wochen gebraucht, bis ich im Kopf assemblieren und Hexcode
eintippen konnte.
Im Prinzip ist es egal, womit man anfängt.
fchk
bloody_beginner schrieb:> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger> heutzutage raten anzufangen?
Mit einem 8-Bit PIC, zb. PIC16F18855
Begründung:
Arduino: Zu Abstrakt. Du weißt nicht was die eingebundenen Bibliotheken
wildfremder Menschen machen und so richtig weißt du auch nicht was sonst
noch so abgeht im Code. Arduino ist cool, aber nur für die ganz
schnellen Frickelsachen.
AVR: Register direkt ansprechen und setzen, Datenblatt durchforsten,
100x falsch konfiguriert bis es und du dann nach x-Stunden endlich
deinen eigentlichen Code anfangen kannst zu schreiben.
PIC: Da gibt es in der MPLAB X IDE ein Add-on namens MCC (Microchip Code
Configurator) und das funktioniert wirklich gut. Du kannst direkt alle
Pins konfigurieren, alle Peripherals. Wie im AVR direkt als Register,
kannst du dort deine Funktionen in Klartext konfigurieren. Beim USART
zeigt er direkt die Fehlerrate an, beim ADC direkt die Conversion-Time.
Und für jeden Ausgang gibts Abstraktere Funktionen wie RB3_toggle().
Timer, Interrupt Prioritäten, ADC, USART, SPI -> Alles schnell
konfiguriert.
Der Code macht aber trotzdem genau nur das was du willst.
Fazit:
Der PIC bietet eine schöne Mitte zwischen AVR und Arduino und durch die
angenehme Konfiguration einen frustfreien Start.
Protokolle, z.b. das Auslesen welchen Registers vom SPI eines Sensors,
darfst du trotzdem selbst schreiben. Der MCC macht dir nur die
allererste Konfiguration des Controllers.
Für eine Abschlussarbeit finde ich daher den PIC genau richtig.
VG Niine
bloody_beginner schrieb:> Würdet ihr das so unterschreiben?
Überwiegend ja, mit Ausnahmen. Die Arbeitsweise vom Parallax Propeller
und den XMOS Typen ist recht anders.
utor: Niine (Gast)
>Arduino: Zu Abstrakt. Du weißt nicht was die eingebundenen Bibliotheken>wildfremder Menschen machen und so richtig weißt du auch nicht was sonst>noch so abgeht im Code. Arduino ist cool, aber nur für die ganz>schnellen Frickelsachen.
Du weißt es nicht? Was genau hindert Dich daran in den Code der
Bibliotheken zu schauen?
bloody_beginner schrieb:> Ich studiere Elektrotechnik aber habe bis jetzt noch nie einen uC> angefasst.
tja und?
kaufe einen ATmega 328p stecke den aufs Breadboard und du hast ihn
angefasst.
Vor dem Studium E-Technik hatte ich das zwar schon gemacht (6502 / Z80)
auch etwas programmiert, ASM und Basic (upps, böses Wort)
Im Studium mit µC LH5803 & C angefangen, war ein klacks (jedenfalls die
Anfängerversion)
Jeder Weg beginnt mit dem ersten Schritt.
bloody_beginner schrieb:> Ich wollte mal fragen ob es stimmt, dass es relativ egal ist mit welchem> Mikrocontroller man anfängt, solange es kein Arduino ist, da wenn man> einen uC wirklich verstanden hat, es relativ einfach ist sich in andere> einzuarbeiten.> Würdet ihr das so unterschreiben?
Nein.
Am Arduino-Konzept ist prinzipiell nichts auszusetzen. Es zwingt einen
nicht, schlechte Programme zu schreiben. Es erleichtert dem Anfänger
aber den Einstieg.
Jeder ist für seinen Programmierstil selber verantwortlich, die IDE kann
überhaupt nichts dafür.
Die ARM sind einen erheblichen Zacken komplexer als die AVRs, daher ist
der Einstieg damit mit Hürden gepflastert. Die Einarbeitungszeit ist
deutlich höher.
Auch sind die Erratasheets oft sehr lang und enthalten wirklich
kritische Bugs, z.B. beim LPC435X:
"Specifically, writes to I2C0, MCPWM, and I2S can affect C_CAN1. Writes
to I2C1, DAC, ADC0, and ADC1 can affect C_CAN0."
Und man erlebt auch Überraschungen, die man von einfacheren MCs nicht
gewohnt ist. Ein Kollege wollte das SPI mit Bitbanging benutzen, statt
erst den Haufen SPI-Doku durcharbeiten zu müssen. Leider ist aber der
SCK-Pin nicht als Output verfügbar, also geht nur HW-SPI.
Man kann sich auch nicht die Arbeit erleichtern und ungeprüft fremde
Codebeispiele übernehmen. Z.B. hatte der Kollege Probleme mit dem CAN.
Nach langer Suche stellte sich heraus, daß der Takt des CAN-Controllers
zu hoch konfiguriert war.
Alles in allem halte ich daher die ARM nicht für Anfänger tauglich.
bloody_beginner schrieb:> wenn man einen uC wirklich verstanden hat, es relativ einfach ist sich> in andere einzuarbeiten.
Jeder Hersteller verbaut andere Peripherie-Module. Die grundlegenden
Konzepte sind die selben, die Details nicht.
Peter D. schrieb:> Die ARM sind einen erheblichen Zacken komplexer als die AVRs
Was eigentlich nichts mit der CPU selbst zu tun hat. Der MSP432
kombiniert eine ARM-CPU mit der 'guten alten' MSP430-Peripherie; gibt es
so etwas auch von anderen Herstellern?
Niine schrieb:> PIC: Da gibt es in der MPLAB X IDE ein Add-on namens MCC (Microchip Code> Configurator) und das funktioniert wirklich gut. Du kannst direkt alle> Pins konfigurieren, alle Peripherals.
Oh Gott, bloß nicht noch sowas ins Spiel bringen. :-o
Solche Codegeneratoren gibt es mittlerweile wohl so ziemlich für jeden
Controller, das ist also erstmal gar kein Argument "pro PIC". Aber:
damit lernt man nicht, einen Controller zu verstehen und zu
programmieren, und beim nächsten Controller mit Codegenerator Y des
Herstellers Z ist gleich mal wieder alles ganz anders.
Mithin so ziemlich der schlechteste Ratschlag für einen Einstieg, sowas
zu benutzen. Dann ist ja das Arduino-Framework noch eher zu empfehlen,
da hat man wenigstens eine riesige Community, die man fragen kann.
(Allerdings würde ich dem TE dennoch eher "bare metal" empfehlen statt
Arduino-Framework. Da lernt man mehr.)
"Kennst du einen - kennst du alle" trifft auf jeden Fall nicht zu.
Aber: Wenn man einen kennengelernt hat, fällt es meisten nicht sehr
schwer, einen weiteren dazu zu lernen, weil es viele Gemeinsamkeiten
gibt.
Wenn man in einer Hochsprache programmiert, sind viele Details gut
abstrahiert so dass man sich mit dem CPU Kern eher selten bis gar nicht
auseinander setzen muss. Dann kann man sich direkt auf die I/O
Schnittstellen konzentrieren.
> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger> heutzutage raten anzufangen?
Wenn du schnelle Erfolge brauchst, dann die AVR Serie (z.B. ATmega328P
auf Arduino-Nano Board), ansonsten etwas mit ARM Cortex M3 oder M4 drin
(z.B. STM32F103C8T6 auf Blue-Pill Board oder STM32F103RBT6 auf Nucleo-64
Board).
Wir reden hier von rund 350 Seiten Lesestoff versus 2500 Seiten. Klingt
krass, aber man muss ja nicht alles auf einmal Lesen und kann erstmal
mit Tutorials anfangen. Ich halte beide genannten µC sowohl für
anfängertauglich als auch Industrie-Typisch. Zweifellos gibt es noch
viele weitere geeignete (einige wurden ja schon genannt).
Marc schrieb:> utor: Niine (Gast)>>Arduino: Zu Abstrakt. Du weißt nicht was die eingebundenen Bibliotheken>>wildfremder Menschen machen und so richtig weißt du auch nicht was sonst>>noch so abgeht im Code. Arduino ist cool, aber nur für die ganz>>schnellen Frickelsachen.>> Du weißt es nicht? Was genau hindert Dich daran in den Code der> Bibliotheken zu schauen?
Das ist nicht der Punkt. Natürlich könnte ich in den Code schauen.
Aber ich würde es vorziehen, wenn es dokumentiert wäre. Also eine
offizielle und vollständige Variante von dem hier:
Gerhard O. schrieb:> Im einfachsten Fall belegt Arduino immer:> Timer0 als Zeitbasis für die millis() Funktion, PWM und den UART. Sonst> kann man alles in normaler Weise durch direkten SFR Zugriff in gewohnter> Weise beeinflussen
Denn natürlich ist das weder offiziell noch komplett. Es gilt auch nur
für Arduino auf AVR.
Aber ich bin mir recht sicher, daß so etwas nicht kommen wird. Weil das
gar nicht die Zielrichtung von Arduino ist. Die Zielgruppe von Arduino
soll ausschließlich über das Framework auf die Hardware zugreifen. Ein
Mix aus dem Framework hier und direkten Hardwarezugriffen dort wird
weder als sinnvoll angesehen noch unterstützt.
Und weißt du was: da bin ich ganz bei den Arduino-Leuten. Das ist
tatsächlich nicht sinnvoll. Wer direkten Hardwarezugriff will (vulgo:
wer seinen µC verstehen will) der soll Arduino links liegen lassen und
gleich direkt mit der Hardware sprechen.
Bei kleinen µC wie dem AVR halte ich Assembler für eine mögliche
Einstiegs-Programmiersprache. Sonst halt C. Oder C++. Im Idealfall kann
man schon eine Programmiersprache. Wenn es die für den µC gibt, dann
halt die. Dann muß man nicht an mehreren Fronten kämpfen.
Axel S. schrieb:> Die Zielgruppe von Arduino> soll ausschließlich über das Framework auf die Hardware zugreifen. Ein> Mix aus dem Framework hier und direkten Hardwarezugriffen dort wird> weder als sinnvoll angesehen noch unterstützt.
Das hast du dir doch nur ausgedacht!
Oder?
Wo steht das geschrieben?
Irgendwo in der Arduino Doku?
Dann zeige mir bitte die Stelle.
Denn bisher ist mir das noch nicht unter gekommen.
Ich befürchte, das beruht alleinig auf deiner Einbildungskraft.
Nenne bitte die Quelle, auf denen deine Schlussfolgerung beruht.
Wenn es eine solche Quelle nicht gibt, dann kann deine Ansicht nicht
mehr als eine Meinung sein. Und als solche ist sie dann recht
willkürlich, da nicht auf belegbaren Fakten beruhend.
Das direkte Hardwarezugriffe nicht unterstützt werden ist übrigens eine
Unwahrheit. Und bei Wiederholung eine Lüge.
Nöö...
Das halte ich für eins dieser Pseudoargumente, um einen Grund zu haben,
das Arduino Gedönse ablehnen zu können.
Wühle dich bitte mal durch http://playground.arduino.cc/ .
Und wenn du dann immer noch deine Meinung vertrittst, dann kann ich dir
auch nicht helfen. Dann muss das wohl weiter von dir in die Welt
trompetet werden.
Michael B. (laberkopp) schrieb:
>braucht man Hochtemperatur bis 300 GradC HT83C51, das alles gibt es bei
Vor allem sein Preis ist voll anfängertauglich ...
@TO:
Ansonsten halte ich es wie die meisten anderen:
Wenn es Dir darum geht, generell das µC-Gebiet bzw. einen konkreten µC
zu erforschen, dann meide Arduino u.ä. (oder besser, dessen Art des
Programmierkonzepts), oder irgendwelche Codegeneratoren, denn deren Sinn
ist es nun gerade nicht, das Innere eines µC kennenzulernen, sondern
möglichst schnell und einfach irgendeine µC-Anwendung zum Laufen zu
bekommen, indem man einfach irgendwelche Codekomponenten
zusammenstöpselt. Da lernste aber eigentlich nix, was die µC-Welt im
Inneren zusammenhält.
AVR und PICs wurden ja schon genannt, und sind vergleichsweise noch
schnell zu überblicken. Damit hatte ich vor zehn, fuffzehn Jahren mal
angefangen. Aber nicht einfach nur, um es bloß kennenzulernen, sondern
ich hatte damals eins, zwei konkrete Projekte im Plan, die ich umsetzen
wollte. Ich denke, da lernt man am besten und ambitionierter, wenn man
ein Ziel hat, als nur sturr paar Beispiele durchzuarbeiten. Bis auf ein
LED-Blinki-Blinki-Programm (was für den allerersten Test noch geklaut
war ;-), welches ich dann noch zu einem LED-Lauflicht aufbohrte (ohne zu
klauen ;-) - damit waren schonmal IO, Timer, Interrupts kennengelernt),
bin ich dann direkt zu meinem ersten Projekt übergegangen, DB von vorn
bis hinten durchgelesen (naja, nicht ganz ;-), und dabei überlegt, was
man wie damit umsetzt, und parallel dazu Schaltplan entworfen, nachdem
man geschnallt hat, welche Ports/Pins man wozu nutzen kann (ja, war
damals noch klassisch mit Programmiergerät, und eigener Schaltung, kein
Discoveryboard oder so).
Also kurz: denke Dir was konkretes aus, was Du umsetzen willst, und was
später von Nutzen sein soll, und mache dann Learning by doing bei diesem
konkreten Projekt (was zumindest für den Anfangs vielleicht nicht zu
sehr aufgebläht sein sollte). Ob jetzt PIC, oder Atmel oder sonstwas,
ist eigentlich eher egal (irgendso ein ARM/Cortex-Kram ist vielleicht
nicht ganz so ideal für den Anfang).
Axel S. schrieb:> Ein> Mix aus dem Framework hier und direkten Hardwarezugriffen dort wird> weder als sinnvoll angesehen noch unterstützt.https://www.arduino.cc/en/Reference/PortManipulation
es wird unterstützt und da werden die Pros und Cons aufgelistet. Nur
wird der Arduino Anfänger das nicht als erstes lesen, aber sowas gehört
auch nicht in die erste Lektion.
Wenn es darum geht z.B. ein Display mit Parallel Port anzusteuern bleibt
gar nichts anders mehr übrig das über direkte Zugriffe zu machen. In den
bekannten Libs findet man das auch so und per defines ist es auch oft
portabel gemacht weil Arduino nicht mehr nur AVR targets hat.
Also sind beide Wege absolut legitim, der Einsteiger bekommt schnell
seine LED zum blinken und wenn er mehr Geschwindigkeit braucht muss er
sich mit der Registerprogrammierung auseinandersetzen. So einfach ist
das.
Arduino Fanboy D. schrieb:> Axel S. schrieb:>> Die Zielgruppe von Arduino>> soll ausschließlich über das Framework auf die Hardware zugreifen. Ein>> Mix aus dem Framework hier und direkten Hardwarezugriffen dort wird>> weder als sinnvoll angesehen noch unterstützt.>> Das hast du dir doch nur ausgedacht!> Wo teht das geschrieben?
Ich bin der gleichen Meinung. Es steht indirekt in der Doku, weil diese
Möglichkeit dort konsequent verschwiegen wird.
Arduino Fanboy D. schrieb:> Stefanus F. schrieb:>> Ich bin der gleichen Meinung. Es steht indirekt in der Doku, weil diese>> Möglichkeit dort konsequent verschwiegen wird.>> Das ist eine Unwahrheit!> Eine Lüge.>> Und wird in der Referenz widerlegt:> https://www.arduino.cc/en/Reference/PortManipulation
Ich habe die Seite anders in Erinnerung und kann sie gerade nicht
aufrufen (timeout). Aber wenn sich das inzwischen geändert hat, freue
ich mich darüber.
Die ursprüngliche Idee des Baukasten-Systems für Künstler ging ja nicht
so ganz auf, stattdessen beschäftigen sich mehr Leute mit dem System,
die etwas hardwarenäher programmieren wollen.
Arduino Fanboy D. schrieb:> Eine Lüge.
Nö. Sinn des Frameworks ist es doch, möglichst losgelöst von der
tatsächlichen Hardware arbeiten zu können. Wie auf einem Betriebssystem
gewissermaßen, wo die Treiber auch die Hardware für dich abstrahieren.
Das ist ja kein Argument gegen Arduinos, sondern eins dafür. Nur
halt nicht gerade etwas, was der TE so bräuchte.
Wenn man auf die Hardware zugreifen muss, braucht man natürlich direkte
Zugriffe, das ist dann wie der OS-Treiber. Unterschied ist halt, dass es
keine erzwungene Barriere zwischen beiden gibt.
Arduino Fanboy D. (ufuf) schrieb:
>Stefanus F. schrieb:>> Ich bin der gleichen Meinung. Es steht indirekt in der Doku, weil diese>> Möglichkeit dort konsequent verschwiegen wird.>Das ist eine Unwahrheit!>Eine Lüge.>Und wird in der Referenz widerlegt:>https://www.arduino.cc/en/Reference/PortManipulation
Nicht wirklich, eher das Gegenteil, denn dort steht:
"Why use port manipulation?
From The Bitmath Tutorial
Generally speaking, doing this sort of thing is not a good idea. Why
not? Here are a few reasons:
...
..
.
"
Bei den Arduino Fanboys ist das also verpönt.
Jörg W. schrieb:> Nö. Sinn des Frameworks ist es doch, möglichst losgelöst von der> tatsächlichen Hardware arbeiten zu können. Wie auf einem Betriebssystem> gewissermaßen, wo die Treiber auch die Hardware für dich abstrahieren.
Unser Stefanus hat gesagt, dass diese Möglichkeit auf die Hardware
durchzugreifen in der Doku verschwiegen wird.
Das ist nicht wahr!
Ob man es Lüge, Unwahrheit, oder Irrtum nennt, ist zweitrangig.
Es ist eine Falschaussage.
Und es bleibt eine Falschaussage.
Und dein "Nö" ist in dem Zusammenhang deplatziert.
Ein Irrtum, eine Unwahrheit oder Lüge deinerseits.
Bedenke:
Diese Unwahrheit wurde hier identifiziert und widerlegt.
-----------
> Sinn des Frameworks ist es doch, möglichst losgelöst von der> tatsächlichen Hardware arbeiten zu können. Wie auf einem Betriebssystem> gewissermaßen, wo die Treiber auch die Hardware für dich abstrahieren.
Ist ja ok...
Und wenn einem das nicht reicht, dann muss man eben tiefer in die Kiste
greifen.
Aber die Behauptung, das das nicht erwünscht ist, oder gar überhaupt
nicht möglich sein soll, ist einfach nur absurd und falsch.
Irreführend.
Jedenfalls kann (und konnte man schon immer) am Arduino Framework vorbei
programmieren, wenn man es denn will. Im Prinzip finde ich das gut, denn
so hat man immer die Möglichkeit offen, Sachen zu implementieren, die
von den Arduino Machern gerade nicht vorgesehen waren. Ist doch gut so.
Jens G. schrieb:> Generally speaking, doing this sort of thing is not a good idea. Why> not? Here are a few reasons:
Und dann hast du aufgehört weiterzulesen? Es folgen 3 Argumente Con und
3 Pro.
Und wenn man die verstanden kann man selbst entscheiden.
Jens G. schrieb:> Nicht wirklich, eher das Gegenteil, denn dort steht:>> "Why use port manipulation?>> From The Bitmath Tutorial>> Generally speaking, doing this sort of thing is not a good idea. Why> not? Here are a few reasons:>> ...> ..> .> ">> Bei den Arduino Fanboys ist das also verpönt.
Auch du liest scheinbar nur halb, und pickst dir dann das raus, was dir
gefällt, deine Ablehnung bestätigt.
Du hast unterschlagen:
> Here are some of the positive aspects of direct port access:
Welche man durchaus als Empfehlung auffassen darf, wenn man auf die dort
benannten Probleme trifft.
Dieser Teil der Arduino Doku beleuchtet also die Vor- und Nachteile des
direkten Portzugriffs.
> Bei den Arduino Fanboys ist das also verpönt.
Falsche Schlussfolgerung, da nicht vollständig gelesen/verstanden.
Stefanus F. schrieb:> Jedenfalls kann (und konnte man schon immer) am Arduino Framework> vorbei> programmieren, wenn man es denn will. Im Prinzip finde ich das gut, denn> so hat man immer die Möglichkeit offen, Sachen zu implementieren, die> von den Arduino Machern gerade nicht vorgesehen waren. Ist doch gut so.
Dem kann ich vollumfänglich zustimmen.
Ich würde dir zu einem Atmega, z. B. 328P raten. Der ist natürlich nicht
State of the Art aber noch einfach genug um sich Grundlagen auch ohne
viel Vorwissen selbst zu erarbeiten. Kennst du einen kennst du alle
würde ich so nicht sagen, aber das Grundverständnis hilft definitiv bei
der Einarbeitung in neue Controller.
Arduino wäre dann quasi die passende Entwicklungsumgebung mitsamt
Platine, wenn du eigentlich mit der µC-Technik möglichst wenig Kontakt
haben, sondern schnell ein irgendwie funktionierendes Programm haben
willst.
Ohne Arduino brauchst du erstmal ein Eval-Board. Ich habe das Atmel
Evaluation Board von Pollin. Da hast du schonmal funktionierende
Hardware. Zum Programmieren nimmst du z. B. einen AVRISP MKII. Der hat
USB für deinen PC und ISP für den µC auf deinem Eval-Board. Als
Entwicklungsumgebung benutzt du das aktuelle Atmel Studio. Hier kannst
du dann zu Beginn deinen µC auswählen um einige wichtige Libraries
automatisch einzubinden.
Jetzt hast du alles um anzufangen. Alles zum Aufbau des µC und der
Umsetzung deiner Ideen findest du dann im Datasheet zu deinem µC und
entsprechenden Application Notes des Herstellers.
@Johannes S. (jojos) + Arduino Fanboy D. (ufuf)
> Generally speaking, doing this sort of thing is not a good idea. Why> not? Here are a few reasons:
Ich habe weder halb gelesen, noch lehne ich Arduino ab. Ich habe nur den
einen Satz ins Spiel gebracht, der uns zu verstehen geben will, daß
direkte Zugriffe nicht empfohlen (erwünscht) sind, egal ob da noch drei
Pros aufgeführt sind.
Und das dies nicht wirklich erwünscht ist, sieht man mehr oder weniger
daran, das der genannte Link ziemlich losgelöst ohne weitere Referenzen
da steht. Von https://www.arduino.cc/reference/en/ (Language Reference)
jedenfalls scheint es keinen Link auf
www.arduino.cc/en/Reference/PortManipulation zu geben. Zumal die beiden
oberen Verzeichnisebenen reference/en sich auf magische Art und Weise in
/en/Reference verwandeln, wenn es um PortManipulation geht, damit man es
ja nicht findet.
das Inhaltsverzeichnis vom Internet ist einfach schlecht...
https://playground.arduino.cc/Main/TutorialList#AVR
da wird es verlinkt und sowas sollte man einfach überflogen haben wenn
man die ersten Schritte hinter sich hat.
Arduino Fanboy D. schrieb:>> Nö. Sinn des Frameworks ist es doch, möglichst losgelöst von der>> tatsächlichen Hardware arbeiten zu können. Wie auf einem Betriebssystem>> gewissermaßen, wo die Treiber auch die Hardware für dich abstrahieren.>> Unser Stefanus hat gesagt, dass diese Möglichkeit auf die Hardware> durchzugreifen in der Doku verschwiegen wird.
OK, das hatte ich dann falsch aufgefasst.
Arduino Fanboy D. schrieb:> Dem kann ich vollumfänglich zustimmen.
Dann sind wir uns ja alle völlig einig. :-)
Arduino Fanboy D. schrieb:> Axel S. schrieb:>> Die Zielgruppe von Arduino>> soll ausschließlich über das Framework auf die Hardware zugreifen. Ein>> Mix aus dem Framework hier und direkten Hardwarezugriffen dort wird>> weder als sinnvoll angesehen noch unterstützt.>> Wo steht das geschrieben?> Irgendwo in der Arduino Doku?
Das steht nirgendwo geschrieben. Insofern ist das meine Beschreibung für
den vorgefundenen Zustand. Der Beginn und die Motivation des
Arduino-Projekts sind ja gut dokumentiert. Der Rest ergibt sich mehr
oder weniger direkt daraus.
> Nenne bitte die Quelle, auf denen deine Schlussfolgerung beruht.
Das nennt man die Realität.
Johannes S. schrieb:> Axel S. schrieb:>> Ein>> Mix aus dem Framework hier und direkten Hardwarezugriffen dort wird>> weder als sinnvoll angesehen noch unterstützt.>> https://www.arduino.cc/en/Reference/PortManipulation>> es wird unterstützt und da werden die Pros und Cons aufgelistet.
Das ist nicht das, was ich gemeint habe. Es wird selbstverständlich
unterstützt in dem Sinne das es geht. Nur ist ist das keine Eigenschaft
der Arduino-Umgebung, sondern nur eine durchscheinende Eigenschaft der
Technologie, auf der Arduino aufgebaut ist. Hier: avr-gcc und avr-libc.
Wenn Arduino direkte Hardwarezugriffe an der Lib vorbei wirklich
unterstützen würde (und das ist jetzt die Art Unterstützung, die ich
weiter oben gemeint habe) dann würden sie dafür sorgen, daß
Direktzugriffe nicht in Konflikt mit der Lib kommen können. Bspw.
könnten sie den Direktzugriff auf Timer0 unterbinden und damit
verhindern, daß der geneigte Arduino-Nutzer sich seine Infrastruktur
unter dem Hintern wegballert. Als Minimum müßten sie klar dokumentieren,
welche Teile der Hardware Tabu sind.
So wie es jetzt ist, haben sie da einen hüfthohen Zaun eingezogen. Die
von dir gezeigte Seite ist das Schild "Hinter dem Zaun ist das Gras
sogar noch grüner und in der einen Ecke wachsen sogar Blumen. Aber es
gibt auch wilde Tiere. Betreten auf eigene Gefahr!"
> Wenn es darum geht z.B. ein Display mit Parallel Port anzusteuern bleibt> gar nichts anders mehr übrig das über direkte Zugriffe zu machen.
Der Arduino-Nutzer im Sinne der (meinetwegen auch nur ursprünglichen)
Zielgruppe verwendet dafür eine Lib. Abgesehen davon kann man natürlich
auch mit digitalWrite() ein paralleles LCD ansteuern. Langsam wie Hulle,
klar. Aber am Ende wahrscheinlich schnell genug <tm>
Axel S. schrieb:> So wie es jetzt ist, haben sie da einen hüfthohen Zaun eingezogen. Die> von dir gezeigte Seite ist das Schild "Hinter dem Zaun ist das Gras> sogar noch grüner und in der einen Ecke wachsen sogar Blumen. Aber es> gibt auch wilde Tiere. Betreten auf eigene Gefahr!"
:-))
Axel S. schrieb:> Wenn Arduino direkte Hardwarezugriffe an der Lib vorbei wirklich> unterstützen würde (und das ist jetzt die Art Unterstützung, die ich> weiter oben gemeint habe) dann würden sie dafür sorgen, daß> Direktzugriffe nicht in Konflikt mit der Lib kommen können. Bspw.> könnten sie den Direktzugriff auf Timer0 unterbinden und damit> verhindern, daß der geneigte Arduino-Nutzer sich seine Infrastruktur> unter dem Hintern wegballert. Als Minimum müßten sie klar dokumentieren,> welche Teile der Hardware Tabu sind.
Wie jetzt, du willst die Sicherheit die dir Android bietet und
gleichzeitig völlige Freiheit zum Zugriff auf den uC?
Tja, beides kann man schlicht nicht haben.
Mittels ein paar Suchanfragen im Sourcecode der Core Libraries oder
durch Durchlesen der realen main Funktion kannst du recht schnell
rauslesen ob das was du grade maximal-maschinennah vor hast, mit Android
kolidiert, oder nicht.
Gut, vieleicht scheint hier die Philosophie der "Maker" durch. Wir lesen
lieber sourcecode statt Datenblätter.
Jörg W. schrieb:> :-))
Genau! Das hat der Axel doch schön gesagt, gelle?
Das Problem bei allem, was irgend jemand in bester Absicht vorgekaut und
zum Benutzen vorbereitet hat, besteht eben darin, daß es recht vielen
Benutzern den Weg in ein Technik-Gebiet öffnet, OHNE daß daran der
eigentlich notwendige Lernprozeß gekoppelt ist.
Wer jedoch Arduino benutzt UND sich in die verwendete Technik einliest
und selbst darin weiterbildet, dem ist das alles eine gute Hilfe - ABER
es gibt offenbar sehr viele, die eben letzteres nicht tun und dennoch
meinen, sie wüßten durch's schiere Benutzen schon genug. Siehe der
Beitrag mit den offengelassenen ADC-Eingängen.
W.S.
Axel S. (a-za-z0-9) schrieb:
>Das ist nicht das, was ich gemeint habe. Es wird selbstverständlich>unterstützt in dem Sinne das es geht. Nur ist ist das keine Eigenschaft>der Arduino-Umgebung, sondern nur eine durchscheinende Eigenschaft der>Technologie, auf der Arduino aufgebaut ist. Hier: avr-gcc und avr-libc.
Aja, dann wird es auch für mich klar, warum es nicht in der Arduino-Ref
erwähnt ist. Ist eben kein Feature von Arduino, sondern beruht nur auf
der Umgehung deselben. So gesehen unterstützt es ja alles ...
Alex G. schrieb:> Axel S. schrieb:>> Wenn Arduino direkte Hardwarezugriffe an der Lib vorbei wirklich>> unterstützen würde (und das ist jetzt die Art Unterstützung, die ich>> weiter oben gemeint habe) dann würden sie dafür sorgen, daß>> Direktzugriffe nicht in Konflikt mit der Lib kommen können. Bspw.>> könnten sie den Direktzugriff auf Timer0 unterbinden und damit>> verhindern, daß der geneigte Arduino-Nutzer sich seine Infrastruktur>> unter dem Hintern wegballert. Als Minimum müßten sie klar dokumentieren,>> welche Teile der Hardware Tabu sind.> Wie jetzt, du willst die Sicherheit die dir Android bietet und> gleichzeitig völlige Freiheit zum Zugriff auf den uC?
Gott, nein. Ich verwende Arduino nicht. Und zwar nicht, weil ich es
schlecht oder häßlich finden würde, sondern weil es schlicht kein
Problem löst, das ich hätte. Und in diesem Thread rede ich darüber auch
nur deswegen, weil das gleiche für den TE gilt. Für das, was er vorhat,
ist (das) Arduino(framework) keine Hilfe. Die Hardware könnte er
natürlich trotzdem verwenden. Ich nehme auch gerne Arduino-nano Klone
aus China. Die sind kaum größer als ein mega328 in DIP und haben den
USB-UART schon an Bord. Sehr praktisch.
> Tja, beides kann man schlicht nicht haben.
Man könnte schon. Aber es würde Arbeit machen. Man könnte nicht einfach
nur Compiler und libc von jemand anderem nehmen und eine handvoll
C-Funktionen als Abstraktionsschicht drüber stülpen. Man müßte die
Hardwareresourcen so wegkapseln, daß man den Zugriff einschränken kann.
Lustigerweise würde C++ als Sprache dafür ja sogar Mittel und Wege
bereitstellen.
> Mittels ein paar Suchanfragen im Sourcecode der Core Libraries oder> durch Durchlesen der realen main Funktion kannst du recht schnell> rauslesen
Klar könnte ich. Aber es ist nichts, was mich weiterbringt. Im Zweifel
bin ich ohne Arduino schneller am Ziel.
Man muss halt auch sehen, viele von uns blicken schon auf eine längere
"Elektroniklaufbahn" zurück. Meiner Erfahrung nach gab es schon immer
eine Art Dreiteilung.
Den größten Teil der Menschheit interessiert Elektronik nur soweit, dass
sie mit fertigen Sachen mehr oder weniger umgehen können. Dann gibt es
die, für die es nur "Mittel zum Zweck" ist. Die haben halt früher
Schaltungen nur aus Büchern/Zeitschriften nachgebaut oder Bausätze
gekauft, um das Ganze dann halt in einem anderen Zusammenhang (z.B.
Modellbahn) einzusetzen. Das Äquivalent dazu ist meiner Meinung nach
heute der Arduino und die ganze Szene drumherum.
Und dann gibt es die, für die der Weg das Ziel ist, die in die Materie
eintauchen wollen. Früher wurden alle möglichen Schaltungen konstruiert,
berechnet und ausprobiert, heute sind es die Register und Bits in den
Controllern. Dafür können sie auf so "unnötigen Schnickschnack" wie
Gehäuse gerne verzichten, denn das erschwert nur den Zugang zur
Debug-Schittstelle und Aufbauten bleiben oft nur so lange bestehen, bis
man die nächste Idee hat...
Doch anstelle sich zu ergänzen, wird lieber aufeinander eingehackt.
Manche Dinge ändern sich halt nie...
Hi,
ich verstehe nichts mehr.
Also, erst einmal ein "schlaues" Buch lesen, um sich mit den Grundlagen
vertraut zu machen, dann geht es ans Evaluation Board,
und dann kann man ein bisschen was in ASM eingeben oder so dann
Debuggen, im Simulator Käsekästchen hin- und herschieben lassen, etc.
Achtung joke/Und dann fährt mir diese verflixte Arduino in die Parade,
und nichts geht mehr./ joke end
Beitrag "Re: ArduinoISP - Wieso wird das Programm nicht."
Also aus Erfahrung auch mit 8051-ern-> Atmel Studio und ein EVA Board,
also meins war damals STK500, da gibt es jetzt auch modernere. Und
ATtiny4313 oder eben ein MEGA und mit Adaptersockel sogar 32-er Megas.
(Wenn die ersten LEDs blinken, sprechen wir uns wieder.) ;-)
ciao
gustav
Hallo,
bloody_beginner schrieb:> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger> heutzutage raten anzufangen?>> Habe Elektrotechnik und Softwaretechnik Kenntnisse, könnte also sofort> damit anfangen.bloody_beginner schrieb:> C++ beherrsche ich mittlerweile, aber so richtig bin ich ins> Programmieren dann erst mit Java eingestiegen.
Also wenn Du C++ beherrschst und Kenntnisse in Elektrotechnik hast, dann
bist Du kein blutiger Anfänger.
Nachdem ich letzte Woche auch das erste mal einen Arduino in der Hand
hatte kann ich die sagen, dass es ca. 15 min dauert bis Du dein erstes
lauffähiges Arduino-"Hello World"-Programm geschrieben hast. Als
Einführung würde ich folgendes Video empfehlen:
https://www.youtube.com/watch?v=nL34zDTPkcs
Wirst sehen, es ist ganz einfach...
Der einzige Knackpunkt bei der Sache ist, wie hier schon im Thread
angemerkt wurde, die ganze Analogtechnik die Du um den Arduino herum
brauchst...
Das ist auch mein Problem, dass ich in der Analogtechnik nicht sehr
bewandert bin und praktisch nur über (ein bisschen) Grundwissen verfüge,
mit dem ich keine praxistauglichen Ananlogschaltungen entwickeln kann.
Gruß
Gerhard
Joerg W. schrieb:> Und dann gibt es die, für die der Weg das Ziel ist, die in die Materie> eintauchen wollen.
..und dann gibt es noch die, die damit Geräte entwickeln und bauen. Zum
Teil beruflich für die Brötchen, die man zu essen gedenkt, zum Teil
hobbymäßig, um sich das Equipment zu schaffen, das man für's Hobby
braucht.
Es ist dann wohl eine Vierteilung.
W.S.
Wenn man "kommerzielle" Tätigkeiten mit einrechnet, reicht dann eine
Vierteilung nicht mehr. Die Leute bei den Chipherstellern oder ATE
sitzen meist noch ein Stück näher am Silizium. Und am anderen Ende wird
mit dSPACE oder Vector Tools gearbeitet, gegen die ich Arduino noch als
"hardwarenah" bezeichnen würde. Und dazwischen tausende von
Schattierungen.
Selbst meine "Dreiteilung" bei den Hobbybastlern ist schon grenzwertig,
weil es natürlich auch da fließende Übergänge gibt.
Michael B. schrieb:> Schnarchlangsam beginnt damit, 8 bit eines value auszugeben:>> for(bit=0;bit<8;bit++)> digitalWrite(OUTPUTPIN0+bit,value&(1<<bit)?HIGH:LOW);>> Das ist schnarchlangsam gegenüber einem PORTD=value;
Das ist in der Masse aller Anwendungen ein theoretisches Problem. Du
hast durchaus recht, dass man mit dem direkten Zugriff etliche Zyklen
sparen kann, zu je 63 Nanosekunden @ 16MHz. Ich bin fast geneigt, sowas
mal zu schreiben und ein Scope dran zu hängen.
Hannes J. schrieb:> Ohne Arduino brauchst du erstmal ein Eval-Board. Ich habe das Atmel Evaluation
Board von Pollin.
Selbst schuld :-)
> Da hast du schonmal funktionierende Hardware.
Aus diesem Grunde kaufen etliche Leute Arduino-Boards aus Fernost. Alle
haben den ISP-Anschluß drauf und lassen sich so auch ohne das
A*-Framework verwenden.
W.S. schrieb:> ..und dann gibt es noch die, die damit Geräte entwickeln und bauen.> Zum Teil beruflich für die Brötchen, die man zu essen gedenkt,
Und auch diese klempnern nur noch selten auf der Assemblerebene, sondern
schreiben in C.
Hallo,
die Art der Hardwarezugriffe sind Anfangs erstmal egal ob nah oder fern.
Ein Programm besteht nicht nur aus Hardwarezugriffen. Sie müssen auch
verarbeitet werden. Genau hier liegt in meinen Augen die Kunst des
Programmieren lernen. Wie formuliert man ein Problem und wandelt es in
den Code um der dann am Ende hoffentlich fehlerfrei funktioniert und
nicht nur paar Minuten. Das ist offensichtlich völlig unabhängig der IDE
oder des Controllers.
Und wegen dem Arduio Framework. Nüchtern betrachtet sind das alles
Komfortfunktionen. Ich meine wir schreiben uns doch selber auch
Funktionen oder ganze Librarys um uns selbst die Arbeit zu erleichtern.
Damit sind wir beim digitalWrite u.ä. Komfortfunktionen. Es gibt bis
heute keine Alternative die 1:1 benutzbar schneller funktioniert. Man
kann sich ein Array für irgendwelche Pins anlegen und mittels
Indexdurchlauf und digitalWrite drübergehen. Geht in der einfachen Form
sonst nicht. Weil Komfort immer Zeit kostet, der muss anderes schreiben
wenn ihm das zu langsam ist. Das ist aber schon immer so gewesen und
nichts neues.
Und was schon oft geschrieben wurde und gern wiederholt werden muss ist.
Man muss die Arduino IDE und/oder dessen Komfortfunktionen nicht nutzen.
Man kann die Boards auch als reine praktische Entwicklerboards
verwenden.
Manfred schrieb
>Das ist in der Masse aller Anwendungen ein theoretisches Problem. Du>hast durchaus recht, dass man mit dem direkten Zugriff etliche Zyklen>sparen kann, zu je 63 Nanosekunden @ 16MHz. Ich bin fast geneigt, sowas>mal zu schreiben und ein Scope dran zu hängen.
Es gibt ja kein Problem, das man nicht mit einer Library lösen könnte.
Hier eine unter vielen:
https://github.com/mmarchetti/DirectIO
Das Pollin Board ist eine billige Alternative für das STK500. Beide
wollen ganz viele Stecksockel für viele unterschiedliche AVR Modelle
bereit stellen.
Das halte ich aber für wenig sinnvoll. Denn innerhalb der AVR Serie kann
man tatsächlich sagen "Kennst einen, kennst du alle". Die sind sich
wirklich sehr ähnlich.
Das Argument "Ich kann das Eval Board auch als Programmieradapter
verwenden" zählt für mich kaum, denn normalerweise programmiert man
diese Chips eben nicht in einem Programmier-Sockel sondern direkt in der
Zielschaltung.
Nur die kleinen 8-Pinner programmiere ich häufig außerhalb der
Zielschaltung. Dafür braucht man aber kein komplettes "Board". Als
Bastler wird man es wohl noch schaffen, einen 8 poligen IC Sockel mit 6
Drähten ab einen Pfostenstecker oder ein paar Dupont Kabel zu löten.
Stefanus F. schrieb:> normalerweise programmiert man> diese Chips eben nicht in einem Programmier-Sockel sondern direkt in der> Zielschaltung.
Die neueren ATmega4808 brauchen nur eine Leitung zum Programmieren und
debuggen (UPDI).
Arduino Fanboy D. schrieb:> bloody_beginner schrieb:>> Wie lange braucht ihr um euch in einen neuen uC einzuarbeiten?>> 1/2 Jahr, bis 1 Jahr.> So ca. und ohne Gewähr, da stak abhängig von Type und Vorwissen.
Ganz unrecht hat der OP nicht ... Ich hab lange Zeit mit AVRs
gearbeitet und bin dann auf STM32 quasi umgestiegen.
Es hat 2 Wochen gedauert sich da einzuarbeiten und das angestrebte
Projekt zur Funktion zu bringen.
Aber selbst mehr als 1 Jahr später tauchen immer noch Sachen auf, mit
denen man bisher keine Berührpunkte hat (z.B. DMA Transfer mit
Ringpuffer und den Half-Full/Half-Empty Interrupts). Mit anderen Sachen
hatte ich nie was zu tun - wie z.B. CAN.
Wäre daher der Meinung, dass man mit µC Vorwissen schneller voran kommt,
aber länger mit neuen µCs arbeiten muss, bis man sie wirklich kennt.
Marc schrieb:
> Es gibt ja kein Problem, das man nicht mit einer Library lösen könnte.> Hier eine unter vielen:>> https://github.com/mmarchetti/DirectIO
Hallo,
alle diese Libs sind zwar schnell, ersetzen aber nicht die
Funktionalität 1:1 von digitalWrite mit
Parameterübergabe/Parameteränderung zur Laufzeit. Die Pins werden mit
Objektnamen vorher festgenagelt und steif geschalten. Eigentlich fast
nichts anderes als wenn man das mit den sbi/cbi markro machen würde.
Veit D. schrieb:> Hallo,>> alle diese Libs sind zwar schnell, ersetzen aber nicht die> Funktionalität 1:1 von digitalWrite mit> Parameterübergabe/Parameteränderung zur Laufzeit. Die Pins werden mit> Objektnamen vorher festgenagelt und steif geschalten. Eigentlich fast> nichts anderes als wenn man das mit den sbi/cbi markro machen würde.
Nein, die Library ermöglicht auch dynamische Pin variablen. Wie hoch da
die Beschleunigung zu Digitalwrite ist, steht leider nicht, aber null
wird sie nicht sein, sonst wäre das ja sinnlos.
Alex G. schrieb:> Wie hoch da die Beschleunigung zu Digitalwrite ist, steht leider nicht,> aber null wird sie nicht sein, sonst wäre das ja sinnlos.
wird nicht auch manchmal sinnloses gemacht?
Wer will sich davon freisprechen, oft glaubt man ja sein eigener Weg ist
der bessere.
Hallo,
okay, ist zwar nicht 100% 1:1, aber geht in die richtige Richtung. Ist
eben etwas anders in der Benutzung, man muss 2 Schritte machen. Ist ja
nicht schlimm. Man muss sich nur umgewöhnen. :-)
Danke für den Hinweis. Ich hatte es leider nur überflogen.
Dann wird https://github.com/NicksonYap/digitalWriteFast es ähnlich
machen.
Wenn ich mal viel Zeit & Lust habe werde ich das gegeneinander testen.
Stefanus F. schrieb:> Das Argument "Ich kann das Eval Board auch als Programmieradapter> verwenden" zählt für mich kaum
Ich nutze das regelmässig, so lange der uC in DIP und nicht SMD ist.
War neulich angenehm überascht dass das Pollin-Board mit avrdude ponyser
auch ATtiny13a programmieren konnte obwohl der nicht in der Doku stand.
Und wenn ein SMD in der Schaltung programmiert wird, steckt das andere
Kabelende im Pollinboard.
Ich achte aber drauf, dass mein PC noch richtige seriell und parallel
Ports hat.
MaWin schrieb:> Ich achte aber drauf, dass mein PC noch richtige seriell und parallel> Ports hat.
Hi @MaWin,
fullest ack.
Irgendwie bin ich von den USB-seriell-Adaptern nicht so überzeugt.
ciao
gustav
MaWin schrieb:> Ich achte aber drauf, dass mein PC noch richtige seriell und parallel> Ports hat.
Das funktioniert aber nur, wenn du höchstens XP drauf fährst.
Abgesehen davon sieht es mit nachträglich eingebauten Parallelports
ausgesprochen mau aus. Die Dinger, die es auf Einsteck-Karten gibt
(NetMos usw.), haben unübliche I/O-Adressen ($4000 oder $4800 und so)
und damit kommen viele Programme, die nur die drei alteingesessenen
Adressen kennen, nicht mehr zurecht.
W.S.
Jens G. schrieb:> Funktioniert aber einwandfrei (steht dort ;-)
Hi,
bekomme es nicht gebacken, ein STK500 (Rs232) mit USB-Adapter über
USB-Port zum Laufen zu bringen. Irgendein USB-Treiber oder so etwas
fehlt da. FLIP verstehe ich nicht.
Vielleicht hilft mir jemand auf die Sprünge.
W.S. schrieb:> Das funktioniert aber nur, wenn du höchstens XP drauf fährst.
geht auch mit mehr als WinXP und sogar 64-Bitter.
Kommt wohl auf die Karte an.
Zitat:
MCS9835 -- PCI to Dual Serial and Single Parallel Controller
The MCS9835CV-BA is a PCI based single function I/O Adapter. /Zitat
ciao
gustav
>bekomme es nicht gebacken, ein STK500 (Rs232) mit USB-Adapter über>USB-Port zum Laufen zu bringen. Irgendein USB-Treiber oder so etwas>fehlt da. FLIP verstehe ich nicht.>Vielleicht hilft mir jemand auf die Sprünge.
Zuallererst gucken, ob es neuere Treiber für den Adapter gibt. Hat
zumindest bei mir damals bei irgend so einem Prolific-Adapter mal
weitergeholfen
Manfred schrieb:> W.S. schrieb:>> ..und dann gibt es noch die, die damit Geräte entwickeln und bauen.>> Zum Teil beruflich für die Brötchen, die man zu essen gedenkt,>> Und auch diese klempnern nur noch selten auf der Assemblerebene, sondern> schreiben in C.
Das ist NICHT das Thema. Es geht hier nicht um Assembler oder
C/Pascal/forth/sonstwas, sondern um das Thema der geistigen Stellung zum
Thema Mikrocontroller, also darum, welche Menschen-Gruppe welche
Position dazu einnimmt:
- reine Benutzer (Telefon, Radio, Computer)
- Bausatz-Bastler (für die Modelleisenbahn, Quadcopter usw)
- Steckbrett-Bastler (Steckbrett: was aufbauen und gucken, ob man's
hinbekommt)
- Geräteentwickler (Ziel: verkaufsfähiges Gerät)
Wer da wofür welche Programmiersprache benutzt, ist wirklich egal.
Kleines Beispiel: der frühere Antennen-Analysator in Funkamateur:
programmiert mit BASCOM, und war ein Verkaufsschlager.
W.S.
Karl B. schrieb:> Kommt wohl auf die Karte an.> Zitat:> MCS9835 -- PCI to Dual Serial and Single Parallel Controller> The MCS9835CV-BA is a PCI based single function I/O Adapter. /Zitat
Eben NICHT.
Man kann solche Karten durchaus einbauen und sie werden auch bei
Vorhandensein passender Treiber vom Betriebssystem akzeptiert - aber der
Zugriff von einem Anwendungs-Programm aus ist so ab Win7 nicht mehr
frei. Selbstverständlich könnte man dort einen echten Drucker
anschließen und auch drüber drucken, aber hier geht's um das Anschließen
von Programmier-Geschirre anstelle des Druckers.
W.S.
W.S. schrieb:> Karl B. schrieb:>> Kommt wohl auf die Karte an.>> Zitat:>> MCS9835 -- PCI to Dual Serial and Single Parallel Controller>> The MCS9835CV-BA is a PCI based single function I/O Adapter. /Zitat>> Man kann solche Karten durchaus einbauen und sie werden auch bei> Vorhandensein passender Treiber vom Betriebssystem akzeptiert - aber der> Zugriff von einem Anwendungs-Programm aus ist so ab Win7 nicht mehr> frei. Selbstverständlich könnte man dort einen echten Drucker> anschließen und auch drüber drucken, aber hier geht's um das Anschließen> von Programmier-Geschirre anstelle des Druckers.
Hmm. Dann habe ich mit meinem Setup wohl ein glückliches Händchen
bewiesen. Der Parallelport ist auch so eine PCIe Karte. Da hängt ab und
zu ein Galep3 dran. Die Software läuft allerdings nicht direkt auf dem
Eisen, sondern in VMWare. Und das emuliert den Parallelport auf der
Standard-Adresse, obwohl er auf dem Host ganz woanders liegt. Läuft
alles ganz normal.
Jens G. schrieb:> Zuallererst gucken, ob es neuere Treiber für den Adapter gibt. Hat> zumindest bei mir damals bei irgend so einem Prolific-Adapter mal> weitergeholfen
Hi @all,
erst mal danke für Antworten.
Irgendwie habe ich heute eine riesen Dachlatte vorm Kopf.
OK. Im Bildchen links ist Bord noch nicht eingeschaltet. Aber die Frage
ging dahin,
bei USB sieht das STK auch irgendeinen von den COM-Anschlüssen, die im
Menü aufgelistet sind? Oder auf Auto gehen?
Bei "richtigem" COM-Port läuft es super.
ciao
gustav
Hi
>Aber die Frage ging dahin,
bei USB sieht das STK auch irgendeinen von den COM-Anschlüssen, die im
Menü aufgelistet sind?
Das ist eigentlich die Liste der COM-Ports die das AVR-Studio abfragt.
>Oder auf Auto gehen?
Ja.
MfG Spess
spess53 schrieb:>>Oder auf Auto gehen?>> Ja.>> MfG Spess
Hi,
der andere USB-Konverter wird alsbald ausprobiert.
Melde mich dann, wenn es geklappt hat.
Schon mal vielen Dank für den Tip an @Spess.
ciao
gustav
Stefanus F. schrieb:> Denn innerhalb der AVR Serie kann> man tatsächlich sagen "Kennst einen, kennst du alle". Die sind sich> wirklich sehr ähnlich.
Ähemm. Jain. Einerseits neige ich dazu, dir zuzustimmen, denn es gibt
tatsächlich sehr, sehr viele Gemeinsamkeiten zwischen den vielen
AVR8-Inkarnationen. Leider gibt es aber eben auch Unmassen Unterschiede
und viele davon haben halt durchaus das Potential, auf dem einen Device
eine beabsichtigte Nutzungsart unmöglich zu machen, die auf anderen
problemlos funktioniert.
> Das Argument "Ich kann das Eval Board auch als Programmieradapter> verwenden" zählt für mich kaum, denn normalerweise programmiert man> diese Chips eben nicht in einem Programmier-Sockel sondern direkt in der> Zielschaltung.
So isses. Evalboards braucht man eigentlich nur für "erste Schritte" in
der jeweiligen Zielarchitektur, um die jeweilige Toolchain an's Laufen
zu bringen und die ersten Erfahrungen mit ihrer Benutzung und der der
Zielarchitektur zu sammeln. Danach kann man ein Evalboard höchstens noch
nutzen, um Teil-Lösungen zu testen, aber selten für wirklich optimierte
vollständige Anwendungen. Entweder sind sie zu groß oder zu klein für
das Evalboard oder die vorhandene Schaltung des selbigen stört bezüglich
der beabsichtigten Ziel-Anwendung.
Karl B. schrieb:> der andere USB-Konverter wird alsbald ausprobiert.> Melde mich dann, wenn es geklappt hat.> Schon mal vielen Dank für den Tip an @Spess.
OK,
der Delock 62589 wird im Windows unter Anschlüsse (COM&LPT) als COM3
geführt. Und im STK500 sowohl unter Auto als auch (natürlich) unter COM3
erkannt.
Das Einzige, was unschön ist, dass erst ein Male-Male und Female-Female
Gender Changer hintereinander gesteckt werden müssen, weil die Muttern
sonst blockieren.
Danke nochmals für den Tip @Spess !
ciao
gustav
Karl B. schrieb:> weil die Muttern sonst blockieren
Einfach welche rausschrauben (die aus dem STK500 lassen sich auf jeden
Fall lösen). Die sind doch nicht wichtig.
Hi
>Das Einzige, was unschön ist, dass erst ein Male-Male und Female-Female>Gender Changer hintereinander gesteckt werden müssen, weil die Muttern>sonst blockieren.
Entschuldige bitte, da ist mir ein kleiner Irrtum unterlaufen: Ich
meinte eigentlich diesen
https://www.reichelt.de/usb-2-0-konverter-a-stecker-auf-rs-232-delock-61425-p121151.html?&trstct=pos_19
hier. Der Inhalt vom Delock 62589 dürfte identisch mit den des Delock
61425 sein. Beide mit FTDI-Chips.
MfG Spess
spess53 schrieb:> Ich> meinte eigentlich diesen
Hi,
überhaupt kein Problem. Hatte noch zwei Gender-Changer auf die Schnelle,
sonst die Muttern rausschrauben, geht auch.
Hauptsache das Ding funktioniert neben der so wie so installierten
I/O-Karte.
Deswegen der COM3 dann als Zuordnung.
Was mich wunderte war, dass im Gerätemanager nichts im Bereich der
USB-Hubs zu sehen ist, aber bei Anschlüsse (COM&LPT) da ist er zusehen.
Und Zum Test ein "Read" vom Flash klappt auch.:-)
Jetzt kann es ja weitergehen, nachdem diese Hürde genommen wurde.
Nochmals Danke an @Spess
ciao
gustav
Hi
Nun ja, die Discussion scheint dem ursprünglichen Thema doch
wegzulaufen. Wenn ein blutiger Anfänger nach einem Einstiegscontroller
fragt, dann sind Beiträge über ARM nicht hilfreich. Gut, im Detail hab
ich nicht alles gelesen, aber wenn man anfängt zu laufen, dann ist es
sehr selten, das es Tanzschritte sind. Meist ist es Stolpern und richtig
Fällen. Ich hab mit dem Polinboard, einem AtMega8, AVR Studio und
PoniProg angefangen. C könnte ich nicht und die Pascalcomputer verstand
das Studio nicht. Also Assembler.Das ist einfacher als man denkt. Aber
eben nur auf Controllerebene. In einem PC gelten andere Regeln. Zum
Thema. Elektrotechnik hat nicht unbedingt etwas mit yc zu tun.Klar sind
die überall drin, aber repariert wird da nicht mehr. Also bleibt es beim
eigenen Interesse, diese Bauteile zu verstehen und da ist es hilfreich,
eine Anwendung zu haben, ein Projekt. Etwas, was es zu kaufen so nicht
gibt oder zu teuer ist. Und Zeit. Zeit und Geduld, denn ein Controller
hat eine eigene Art, Befehle die man sich ausdenkt, zu befolgen.Such dir
ein Projekt, einen geeigneten Controller mit entsprechender
Programmierschnittstelle und Fang an. Vernünftig Gehen lernt man beim
Laufen und irgendwann kann Mann dann auch tanzen.
Gruß oldmax
Stefanus F. schrieb:> Und unter Linux macht AltGr-Shift-Q ein Ω
So allgemein stimmt das nicht. Das hängt stark von der
Linux-Distribution, Terminal oder GUI, Konfiguration von X, keymap, etc.
ab.
Alexander S. schrieb:> Stefanus F. schrieb:>> Und unter Linux macht AltGr-Shift-Q ein Ω>> So allgemein stimmt das nicht. Das hängt stark von der> Linux-Distribution, Terminal oder GUI, Konfiguration von X, keymap, etc.> ab.
Jein, das ist seit einiger Zeit im deutschen Keyboard-Layout von X.org
so drin, und damit ziemlich unabhängig von der Linux-Distribution.
Funktioniert auf meinem FreeBSD bspw. genauso.
Aber das ist natürlich nur unter X11 mit einem deutschen Layout
erstmal so der Fall, das ist richtig.
Karl B. schrieb:> Hier gibt es Infos:
Nach einer knappen Woche an Diskussion brauchst du glaub' ich nicht
wieder völlig von vorn anfangen, ohne auf die restlichen Beiträge
einzugehen.
Jörg W. schrieb:> Aber das ist natürlich nur unter X11 mit einem deutschen Layout> erstmal so der Fall, das ist richtig.
Dann muss ich irgendwas falsch machen, denn auf meinem Laptop
funktioniert die Tastenkombination sowohl unter X11 als auch unter
Wayland - einfach so ohne spezielle Konfiguration.
Oldmax schrieb:> Ich hab meinen Beitrag mit einem Tablet geschrieben,daher das "y".
Auch auf Tablets und Smartphones kann man üblicherweise durchaus ein "µ"
eingeben. Man muss eben nur LERNEN, wie das jeweils geht...
Ja, dazu ist Eigeninitiative und Eigenintelligenz erforderlich, sorry...
Stefanus F. schrieb:> sowohl unter X11 als auch unter Wayland
OK, Wayland kenne ich nicht. Weiß nur, dass es das gibt.
Vermutlich haben sie da einfach mal viele Defaults von X11 übernommen.
Das wollte ich damit nicht ausschließen, sondern eher sowas wie die
normale Textconsole.
c-hater schrieb:> Oldmax schrieb:>>> Ich hab meinen Beitrag mit einem Tablet geschrieben,daher das "y".>> Auch auf Tablets und Smartphones kann man üblicherweise durchaus ein "µ"> eingeben. Man muss eben nur LERNEN, wie das jeweils geht...>> Ja, dazu ist Eigeninitiative und Eigenintelligenz erforderlich, sorry...
Ja. Du bist wirklich sorry:-)
Das Sprichwort sagt aber, dass Bilder mehr als 1000 Worte sprechen... So
waere es nett von Dir gewesen, vielleicht einen Link zu posten, wie.z.B.
hier um die restliche Welt zu erleuchten:
https://www.imore.com/how-type-special-characters-and-symbols-your-iphone-or-ipad
mfg
