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.
bitte nicht schon wieder. Suche hier nach 'Arduino Einsteiger' und du bekommst genug zu lesen für den kommenden Winter. Zuletzt noch hier: Beitrag "AVR oder STM32 für Entwicklungsprojekt"
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?
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
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.
:
Bearbeitet durch User
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.
Ich studiere Elektrotechnik aber habe bis jetzt noch nie einen uC angefasst.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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).
bloody_beginner schrieb: > 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? > Schau mal hier rein und entscheide, ob Du damit zurecht kommst: http://www.avr-asm-tutorial.net/ https://s-huehn.de/elektronik/ http://www.sprut.de/electronic/pic/index.htm https://www.microchip.com/wwwproducts/en/ATtiny2313#datasheet-toggle mfG
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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.
Johannes S. schrieb: > So einfach ist > das. Jawoll! Diese Beschränkungen existieren nur in den hohlen Köpfen der selbst ernannten Arduino Experten.
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.
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
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
> https://playground.arduino.cc/Main/TutorialList#AVR
Sowas gehört in die Reference, und nicht in eine Linksammlung ...
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
Beitrag #5622730 wurde vom Autor gelöscht.
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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
Com_LPT_karte.jpg
9,9 KB
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
>Irgendwie bin ich von den USB-seriell-Adaptern nicht so überzeugt.
Funktioniert aber einwandfrei (steht dort ;-)
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
:
Bearbeitet durch User
>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.
Hi >bekomme es nicht gebacken, ein STK500 (Rs232) mit USB-Adapter über >USB-Port zum Laufen zu bringen. Vielleicht hast du nur den/die falschen? Ich habe unter WIN7(64 Bit) diesen https://www.reichelt.de/usb-2-0-konverter-a-stecker-auf-rs-232-delock-61460-p78847.html?&trstct=pos_8 im Einsatz. Extra für das STK500 gekauft. MfG Spess
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.
Angehängte Dateien:
-
STK500_COM.jpg
50 KB -
STK500_connected.jpg
52 KB
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
:
Bearbeitet durch User
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
Beitrag #5623279 wurde von einem Moderator gelöscht.
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.
Angehängte Dateien:
-
USB_RS232_STK500_.jpg
77 KB
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: > 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. Hallo, zur Info, so einen Konverter gibt es auch mit Kabel: https://www.reichelt.de/delock-usb-2-0-konverter-a-stecker-auf-rs-232-delock-65840-p219960.html?&trstct=pos_0 Allerdings ganz schöner Aufpreis für das Kabel. Suche nach "DELOCK USB 2.0 Konverter A Stecker auf RS-232" https://www.reichelt.de/index.html?ACTION=446&LA=446&q=delock%20usb%202.0%20konverter%20a%20stecker%20auf%20rs-232
Angehängte Dateien:
-
USB_Read_STK500.jpg
78 KB
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
Angehängte Dateien:
-
Prolific_PL2303_.jpg
79 KB
Hi, hier noch Auszug aus der Spec. Interessant auch der Warnhinweis vor Fakes. 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
Oldmax schrieb: > Elektrotechnik hat nicht unbedingt etwas mit yc zu tun. Kleiner Tip: AltGt-M macht ein µ Und unter Linux macht AltGr-Shift-Q ein Ω
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.
bloody_beginner schrieb: > Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger > heutzutage raten anzufangen? Oldmax schrieb: > Such dir > ein Projekt, einen geeigneten Controller mit entsprechender > Programmierschnittstelle und Fang an. Hier gibt es Infos: https://www.mikrocontroller.net/articles/AVR-Tutorial:_Equipment Hier gibt's die verschiedenen Studio IDE-Versionen: https://www.microchip.com/mplab/avr-support/avr-and-sam-downloads-archive Dann eben den USB-zu Rs232 Konverter, der auch mit den "höheren" Windows zurechtkommt. Den Delock62589 habe ich getestet. Dann gibt es da schon kleine Programme in ASM. Auch hier: https://www.mikrocontroller.net/articles/Kategorie:AVR-Tutorial Viel Spaß! ciao gustav
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.
Hi Ich hab meinen Beitrag mit einem Tablet geschrieben,daher das "y". Sorry. Gruß oldmax
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
Hi Dank eurer hilfreichen Beiträge weiß ich jetzt auch, wie Umlaute auf dem Tablet gefunden werden und auch das μ. ? Gruß oldmax
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.