Hallo zusammen! Da die alten µCs alle schwer lieferbar sind, dachte ich, ich könnte ja mal für ein neues Projekt einen der "neuen" AVRs nehmen. So neu sind die ja nun auch nicht mehr. Ein paar Jahre vielleicht? Jedenfalls unterstützt der avrdude 6.3 auf meinem aktuellen FreeBSD laut "-p ?" scheinbar keinen einzigen der "neuen" tinyAVRs. Muss ich da irgendwas noch patchen, oder geht das einfach nicht? Gibt es Alternativen zu avrdude unter Unix?
:
Da fehlt's an einem neuen Release … habe ich schon seit 2 Jahren vor. :-/ Du solltest es dir aber problemlos aus dem SVN-Source bauen können.
Vorher noch libhidapi installieren.
Jörg W. schrieb: > Vorher noch libhidapi installieren. Ist das noch aktuell? Bei Github steht: HIDAPI library was originally developed by Alan Ott (signal11). It was moved to libusb/hidapi on June 4th, 2019, in order to merge important bugfixes and continue development of the library.
Jan schrieb: > Jörg W. schrieb: >> Vorher noch libhidapi installieren. > > Ist das noch aktuell? Für FreeBSD schon. Da kommt die libusb direkt vom Core-Betriebssystem, und hidapi (ohne "lib" davor, gerade nachgeschaut) braucht man, um das HID-API halt zuzugreifen.
Beitrag #6870740 wurde von einem Moderator gelöscht.
>Gibt es Alternativen zu avrdude unter Unix?
pyupdi
mplab_ipe
Beitrag #6871050 wurde von einem Moderator gelöscht.
Jan schrieb: > Hallo zusammen! > > Da die alten µCs alle schwer lieferbar sind, dachte ich, ich könnte ja > mal für ein neues Projekt einen der "neuen" AVRs nehmen. So neu sind die > ja nun auch nicht mehr. Ein paar Jahre vielleicht? > > Jedenfalls unterstützt der avrdude 6.3 auf meinem aktuellen FreeBSD laut > "-p ?" scheinbar keinen einzigen der "neuen" tinyAVRs. Muss ich da > irgendwas noch patchen, oder geht das einfach nicht? > > Gibt es Alternativen zu avrdude unter Unix? Hallo, du musst nichts patchen. Du benötigst lediglich eine erweiterte .conf für avrdude. Dort werden die zu unterstützenden µC eingetragen. Ich weiß nicht welchen ATtiny du genau programmieren möchtest, nehme aber mal an einen mit UPDI. Eine erweitere .conf bekommste z.Bsp. von hier. https://github.com/ElTangas/jtag2updi Guckste rein ob deiner drin steht und wie das Kürzel für die Befehlszeile lautet. UPDI Programmer vorrausgesetzt.
Man kann sich eines der Starterkits kaufen. Die kommen mit einem UPDI programmer und kosten auch nicht viel mehr als ein USBasp... Für die alten ATtiny nutze ich trotzem noch AVRDUDE/USBasp.
:
Bearbeitet durch User
Veit D. schrieb: > du musst nichts patchen Wenn sein AVRDUDE noch kein UPDI unterstützt, braucht es sehr wohl mehr als nur ein paar Schnipsel avrdude.conf. Ich werde mich mal wieder ransetzen und schauen, wie man einigermaßen schnell einen Release zusammen bekommen kann. Die Idee, vorher alle plausiblen Patches und Bugfixes auszurollen, werde ich zu den Akten legen, sonst gibt's nie einen neuen Release.
Beitrag #6871264 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > Veit D. schrieb: >> du musst nichts patchen > > Wenn sein AVRDUDE noch kein UPDI unterstützt, braucht es sehr wohl mehr > als nur ein paar Schnipsel avrdude.conf. Ich nutze den jtag2updi "Adapter/Programmer" und der arbeitet mit deinem avrdude zusammen und benötigt nur die µC Ergänzungen. Der jtag2updi übersetzt nach UPDI. Ich weiß aktuell nicht warum du UPDI in avrdude einbauen musst? Vielleicht kannst du kurz erklären was avrdude eigentlich macht? Ich habe das bisher so verstanden das avrdude nur die Schnittstelle zwischen mir und dem verwendeten Programmer ist. Also avrdude das File entgegen nimmt und dem Programmer zukommen lässt. Die letzte Verbindung ISP, UPDI oder was auch immer für den µC macht doch der Programmer und nicht avrdude. Ein avrdude mit aktueller .conf sollte mit einem Atmel ICE problemlos funktionieren. Oder liege ich völlig daneben? > Ich werde mich mal wieder ransetzen und schauen, wie man einigermaßen > schnell einen Release zusammen bekommen kann. Die Idee, vorher alle > plausiblen Patches und Bugfixes auszurollen, werde ich zu den Akten > legen, sonst gibt's nie einen neuen Release. Darfste natürlich machen. Wobei Updates für die avr-libc auch schön wären ... 64bit double ... :-) duck und weg.
:
Bearbeitet durch User
Veit D. schrieb: > Ich nutze den jtag2updi "Adapter/Programmer" und der arbeitet mit deinem > avrdude zusammen und benötigt nur die µC Ergänzungen. Der jtag2updi > übersetzt nach UPDI. Das ist aber 'ne andere Hausnummer. > Ich weiß aktuell nicht warum du UPDI in avrdude > einbauen musst? Ich muss gar nicht, aber ein Kollege von Microchip hat es getan. (Warum wohl? Weil sie halt genügend $KUNDEN haben, die ganz offensichtlich auch AVRDUDE benutzen, trotz des hier gerade wie Sauerbier angepriesenen Studios. Oder wegen? Ich weiß es nicht. ;-) > Vielleicht kannst du kurz erklären was avrdude eigentlich macht? Ich > habe das bisher so verstanden das avrdude nur die Schnittstelle zwischen > mir und dem verwendeten Programmer ist. Ja, aber es gibt halt verdammt viele Programmer, und insbesondere ist es natürlich mehr als wünschenswert, dass die offiziellen Atmel/MCHP-Tools (also das AtmelICE) in dieser Hinsicht unterstützt werden. Das hat Jan Egil Ruud damals getan. > Ein avrdude mit aktueller .conf sollte mit einem Atmel ICE > problemlos funktionieren. Oder liege ich völlig daneben? Der Patch zur Unterstützung von UPDI war ziemlich umfangreich. > Darfste natürlich machen. Wobei Updates für die avr-libc auch schön > wären ... 64bit double ... :-) duck und weg. Ich weiß, hatte ich begonnen. Leider hat mir Johann den Patch dafür mehr oder minder als eine Art "Coredump" geliefert, also so ein Diff seines aktuellen Baums gegen das SVN. Da sind dann alle möglichen Änderungen drin, nicht nur die für multilib/double64, und bei der Arbeit, das mal einigermaßen sauber auseinander zu klamüsern und Stück für Stück zu committen, bin ich dann irgendwie abgestorben. :-( Ist aber auf jeden Fall noch in der Queue, ich war eigentlich selbst immer jemand, der hätte double64 als Option haben wollen.
Hallo Jörg, ich muss nochmal nachfragen. Hat Jan das UPDI Protokoll in avrdude eingebaut oder nur die Unterstützung der Programmer die UPDI können? Also bspw. den Atmel ICE hinzugefügt. Laut meiner Vorstellung kann und muss nur der Programmer der letztlich am µC angeschlossen ist "UPDI" reden können. Der Programmer wiederum bekommt das File vom Rechner worauf avrdude läuft wobei hier doch sicherlich noch kein UPDI im Spiel sein kann. Deshalb meine Frage. Sind alle bekannten Protokolle wie JTAG, PDI, TPI und UPDI in avrdude integriert? Irgendwie kann ich mir das nicht so recht vorstellen, weil das laut meiner Vorstellung die Aufgabe des Programmers wäre darauf umzusetzen. Zudem wenn der Programmer kein UPDI kann, kann doch avrdude machen es will, es geht nicht. Sonst könnte ich mir ja wünschen, dass avrdude zusammen mit meinem AVRISP mkII morgen UPDI kann. :-) Oder ganz anders gefragt. Wenn Jan UPDI in avrdude schon eingebaut hat, was fehlt für dich jetzt noch? Ich bitte um Korrektur in allen Punkten wenn ich falsch liege.
Veit D. schrieb: > Hat Jan das UPDI Protokoll in avrdude > eingebaut oder nur die Unterstützung der Programmer die UPDI können? Letzteres. > Oder ganz anders gefragt. Wenn Jan UPDI in avrdude schon eingebaut hat, > was fehlt für dich jetzt noch? Ein Release, in dem das auch drin ist. ;-)
Jörg, wenn ich du wäre würde ich das avrdude Projekt abschließen. Das wird sonst eine never ending Story mit zunehmendem Risiko, es kaputt zu machen. Hast du wirklich Lust, alle 4 Wochen neue AVR Modelle auf zig Programmieradaptern durchzutesten, während die Hobbybastler nach und nach auf 32 Bit umsatteln? Für die "neuen" tinyAVR und Xmega gibt es längst erschwingliche Programmieradapter samt Software original von Microchip. Wer unbedingt will, dem steht es frei, einen Fork von deinem Projekt zu machen und das dann selbst zu pflegen.
Stefan ⛄ F. schrieb: > Hast du wirklich Lust, alle 4 Wochen neue AVR Modelle auf zig > Programmieradaptern durchzutesten, während die Hobbybastler nach und > nach auf 32 Bit umsatteln? So extrem häufig kommen ja nun auch keine neuen Modelle dazu. Außerdem sind neue Derivate in avrdude.conf relativ unproblematisch einzufügen. Schwieriger wird es schon, wenn auch protokollmäßig einiges dazu kommt. > Für die "neuen" tinyAVR und Xmega gibt es längst erschwingliche > Programmieradapter samt Software original von Microchip. Ein großer Teil der AVRDUDE-Nutzer (mich selbst inklusive) benutzt das Programm zusammen mit ebendiesen Programmieradaptern. Gerade sowas wie das hier genannte UPDI geht m.W. derzeit ohnehin nur mit einem solchen. Letztlich hat ganz offensichtlich auch Microchip (also Trondheim, ehemals Atmel) Interesse daran, weil sie wissen, dass ihre Kunden an einigen Stellen AVRDUDE benutzen. Zwar kommt auch das Studio mit Kommandozeilen-Programmen zur Bedienung der Tools daher, aber es sind N verschiedene Programme, meiner Erinnerung nach auch nicht in der Benutzung so vereinheitlicht. Außerdem laufen sie natürlich nur unter Windows, und wenn bspw. ein Kunde irgendeine Lösung auf Linux aufsetzen will (und sei es "nur" das mittlerweile ja recht beliebte CI/CD für eine automatisierte Qualitätskontrolle), steht er im Regen.
:
Bearbeitet durch Moderator
Stefan ⛄ F. schrieb: > Hast du wirklich Lust, alle 4 Wochen neue AVR Modelle auf zig > Programmieradaptern durchzutesten, während die Hobbybastler nach und > nach auf 32 Bit umsatteln? Auf 32bit umsteigen? Warum schreibst du solchen Unsinn? Ist das dein Wunschdenken?
Veit D. schrieb: > Auf 32bit umsteigen? Warum schreibst du solchen Unsinn? Ist das dein > Wunschdenken? Nein, ich beobachte, was hier diskutiert wird und auf welche meiner Webseiten wie oft zugegriffen wird. Der Trend zu 32 Bit Controllern ist deutlich zu sehen. Ich würde sagen, dass er derzeit um die 50% Marke herum liegt.
Beitrag #6872098 wurde von einem Moderator gelöscht.
Stefan ⛄ F. schrieb: > Veit D. schrieb: >> Auf 32bit umsteigen? Warum schreibst du solchen Unsinn? Ist das dein >> Wunschdenken? > > Nein, ich beobachte, was hier diskutiert wird und auf welche meiner > Webseiten wie oft zugegriffen wird. Der Trend zu 32 Bit Controllern ist > deutlich zu sehen. Ich würde sagen, dass er derzeit um die 50% Marke > herum liegt. Das mag sein, dennoch werden Hobbybastler noch sehr oft zum 8 Bitter greifen. Was ich aber als echt unfairen Zug empfunden habe, was mir jetzt noch sauer aufstößt ist, dass du versuchst allen 8 Bitter Nutzer die Tür vor der Nase zu zuschlagen indem du Jörg sagst er soll die Entwicklung komplett einstellen. Wenn du avrdude nicht benötigst, dann ist das okay, anderen ihr Werkzeug zu klauen, weil man es selbst nicht benötigt, ist absolut unter der Gürtellinie.
Veit D. schrieb: > Auf 32bit umsteigen? Naja, ist schon ein Trend, auch bei mir. Erklärt auch meine nachlassende Motivation, da zu viel Arbeit reinzustecken, zumal ich letzten Endes weitestgehend Einzelkämpfer geblieben bin.
Beitrag #6872130 wurde von einem Moderator gelöscht.
Hallo Jörg, also irgendwie kommt kein richtiges Gespräch zu Stande. Okay, Jan hat nicht das UPDI Protokoll eingebaut sondern die Atmel ICE Unterstützung. Allerdings bleiben auch hier Fragen offen. Ich verstehe immer noch nicht was in deinem avrdude fehlen soll? Wenn avrdude das UPDI Protokoll nicht unterstützen muss, haste ja indirekt bestätigt und ich aber mit dem jtag2updi Programmer und avrdude einen UPDI µC programmieren kann, wofür nur die .conf angepasst werden muss, was fehlt dann konkret in avrdude? Und wenn du den "Patch" von Jan noch nicht eingebaut hast, warum funktioniert dann ein Atmel ICE mit deinem aktuellen Release? Laut meinen Recherchen funktioniert das nämlich. Warum funktioniert der ElTangas jtag2updi Programmer? Also frage ich nochmal. Was fehlt in avrdude bezüglich UPDI?
Beitrag #6872135 wurde von einem Moderator gelöscht.
Stefan ⛄ F. schrieb: > Für die "neuen" tinyAVR und Xmega gibt es längst erschwingliche > Programmieradapter samt Software original von Microchip. Aber nicht für FreeBSD. Und hier ging es ja um Unix. by the way - grub kann auch ufs-Platten booten ;-) Ist schon schade dass man mehrere Betriebssysteme braucht, weil die (vom Hersteller) angebotene IDEs starke Platformabhängigkeiten haben.
Beitrag #6872143 wurde von einem Moderator gelöscht.
Beitrag #6872149 wurde von einem Moderator gelöscht.
Beitrag #6872151 wurde von einem Moderator gelöscht.
Beitrag #6872152 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > Veit D. schrieb: >> Auf 32bit umsteigen? > > Naja, ist schon ein Trend, auch bei mir. Erklärt auch meine nachlassende > Motivation, da zu viel Arbeit reinzustecken, zumal ich letzten Endes > weitestgehend Einzelkämpfer geblieben bin. Das konnte ich erst danach lesen. Ich hatte schon gelesen das alle anderen das Projekt verlassen haben. Genaues erfährt man nicht. Was würdest du denn alles noch in avrdude einbauen wollen? Wenn ich das verwende funktioniert ja alles. Deswegen die Fragen und was nicht funktioniert ... die Probleme anderer kenne ich ja nicht.
Veit D. schrieb: > Was würdest du denn alles noch in avrdude einbauen wollen? Schau dir doch einfach die Liste der Bugs und Patches an. ;-) Für deine andere Frage: es ist halt nicht nur Support für das AtmelICE als solches (ist schon lange drin), auch die einzelnen Protokolle müssen implementiert sein. Ist halt (teils schon sehr lange) im SVN, was wirklich fehlt ist endlich ein Release.
Veit D. schrieb: > Das mag sein, dennoch werden Hobbybastler noch sehr oft zum 8 Bitter > greifen. Zweifellos. Veit D. schrieb: > Was ich aber als echt unfairen Zug empfunden habe, was mir > jetzt noch sauer aufstößt ist, dass du versuchst allen 8 Bitter Nutzer > die Tür vor der Nase zu zuschlagen indem du Jörg sagst er soll die > Entwicklung komplett einstellen. Interessante Interpretation, aber leider völlig falsch. Zum einen geht es mir nicht darum irgend jemandem das bewährte Programm weg zu nehmen, sondern seine bestehende Qualität aufrecht zu erhalten - weil ich das Programm nämlich so wie es ist toll finde. Zum Anderen habe ich darauf hingewiesen, dass jeder der will einen Fork davon machen kann/soll um es weiter zu entwickeln. Drittens habe ich dem Jörg nicht gesagt was er tun soll, sondern was ich an seiner Stelle getan hätte. Andere Meinungen sind auch Ok. Ich schätze seine andere Meinung dazu ebenso wie sein Werk.
Beitrag #6872274 wurde von einem Moderator gelöscht.
Achso: Veit D. schrieb: > Ich hatte schon gelesen das alle anderen das Projekt verlassen haben. Naja, nicht wirklich "verlassen", aber sich von jedeweden Aktivitäten zurück gezogen halt. Wenn es ein paar Mitstreiter mehr gäbe, die da einigermaßen regelmäßig dran bleiben, eingereichte Bugs und Patches sichten, dann hätte ich auch kein Problem, jährlich aus dem status quo ein Release auszurollen. Da das nicht der Fall ist, hatte ich lange Zeit die Idee, man müsse erstmal erschöpfend durch alle Bugs und Patches durchgehen, bevor man ein Release baut. Diese Idee gebe ich jetzt auf, versuche mal einen "reasonable effort" in der Richtung zu machen, danach gibt es endlich ein Release. Da ich natürlich auch der Maintainer des entsprechenden FreeBSD-Ports bin, gibt's postwendend dann dort einen Upgrade. (Wenn es mehr Mitstreiter/innen gäbe, hätte ich auch nichts dagegen, das Teil auf Git rüber zu ziehen. Aber solange ich eh nur allein wurschtele, ist das nur zusätzliche Arbeit ohne irgendeinen Nutzen für meine Arbeit.)
:
Bearbeitet durch Moderator
Beitrag #6872288 wurde von einem Moderator gelöscht.
Beitrag #6872292 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > Veit D. schrieb: >> Auf 32bit umsteigen? > > Naja, ist schon ein Trend, auch bei mir. Erklärt auch meine nachlassende > Motivation, da zu viel Arbeit reinzustecken, zumal ich letzten Endes > weitestgehend Einzelkämpfer geblieben bin. Du machst das alleine? Hmmm ich wüsste gar nicht, wie ich ohne avrdude den Einstieg geschafft hätte. Windows kommt hier nicht zum Einsatz. Nachdem mich das Gefühl übermannt hat, direkt man nen Tausender als Spende springen zu lassen, kam mir der Gedanke, dass diverse Unternehmen, die von der Existenz von avrdude profitiert haben, dir durchaus schonmal die eine oder andere Spende hätten zukommen lassen müssen. Allen voran Atmel/Microchip. Kannst du dazu vielleicht was sagen? Stefan ⛄ F. schrieb: > Jörg, wenn ich du wäre würde ich das avrdude Projekt abschließen. Das > wird sonst eine never ending Story mit zunehmendem Risiko, es kaputt zu > machen. Hast du wirklich Lust, alle 4 Wochen neue AVR Modelle auf zig > Programmieradaptern durchzutesten, während die Hobbybastler nach und > nach auf 32 Bit umsatteln? Bei uns in der Schweiz laufen so Querdenker rum, die gegen Coronamassnahmen protestieren. Soweit sogut, Protestieren ist ein demokratisches Basisrecht. Allerdings gehen jetzt einige vermehrt dazu über, Leute mit "sanfter Gewalt" daran aktiv hindern zu wollen, sich impfen zu lassen. Man muss sich das mal wirklich vor Augen führen. Die stehen an den Impfzentren und Impfbussen und bedrohen die Leute aktiv, die sich selbst entschieden haben, sich impfen lassen zu wollen. Jetzt frage ich mich, ob du auch einer von denen bist. Wenn ich deine Sätze so lese, sehe ich da einige Parallelen.
Also laut https://www.freshports.org/search.php?query=avrdude&search=go&num=10&stype=name&method=match&deleted=excludedeleted&start=1&casesensitivity=caseinsensitive gibt es da auch "arduino-avrdude" mit der gleichen Version. D.h. wer unter FreeBSD einen externen Programmer mit Arduino-IDE benutzen will, kann auch nur diese Version benutzen. Oder nur Sketches mit Arduino-ISP flashen. Also FreeBSD braucht avrdude ;-)
Jan schrieb: > Querdenker ... bedrohen die Leute aktiv, > die sich selbst entschieden haben, sich impfen lassen zu wollen. > Jetzt frage ich mich, ob du auch einer von denen bist. > Wenn ich deine Sätze so lese, sehe ich da einige Parallelen. Gut erkannt, Sherlock. Wie einige andere hier wissen, fresse ich auch meine Kinder und misshandle kleine Kätzchen. Das kann man alles von meinen Meinungen zur Softwareentwicklung ableiten.
ja, aber nicht für unix schrieb: > gibt es da auch "arduino-avrdude" mit der gleichen Version Keine Ahnung, warum das so ist. Habe dessen Maintainer mal nachgefragt. Außer, dass er unter einem anderen Namen installiert wird und man die FTDI-Option nicht abschalten kann, sehe ich da keine Unterschiede.
Jan schrieb: > Du machst das alleine? Hmmm ich wüsste gar nicht, wie ich ohne avrdude > den Einstieg geschafft hätte. Windows kommt hier nicht zum Einsatz. Microchip hat MPLABX, das ursprünglich für die PICs entwickelt wurde, auch auf die dazu gekauften AVR und ARM Architekturen erweitert, inklusive der PICKIT und ICD Programmer, die jetzt in Version 4 nicht nur ICSP, sondern auch JTAG, (U)PDI etc können. Und MPLABX läuft hervorragend auch unter MacOS und Linux. fchk
Jan schrieb: > Allen voran Atmel/Microchip. Kannst du dazu vielleicht was sagen? In der Tat habe ich für Microchip schon mal was als eine Art Werkvertrag machen dürfen. Aber ich habe einen normalen Job, ich mag mir die Hobbyarbeit nicht bezahlen lassen. Wenn mal jemand hier ist und mit mir ein Bier trinken gehen will, ist das was anderes. (Geht halt nur aktuell gerade nicht so gut.)
Frank K. schrieb: > Und MPLABX läuft hervorragend auch unter MacOS und Linux. Es ging allerdings (dem TE) um FreeBSD. ;-) Außerdem ist es nicht jedermanns/fraus Ding, für alles eine extra IDE haben zu müssen, durch die man sich dann durch klickert. Auch Microchip hat ja Kommandozeilentools.
Jörg W. schrieb: > ja, aber nicht für unix schrieb: >> gibt es da auch "arduino-avrdude" mit der gleichen Version > > Keine Ahnung, warum das so ist. Habe dessen Maintainer mal nachgefragt. Ist wegen diverser Hacks von Arduino selbst, die sie (die Arduino-er) in den offiziellen Tree entweder nicht einbringen können oder wollen.
Hallo, @ Stefan: Ich mag es gar nicht mehr kommentieren wollen. Deine letzte Antwort hat es jedenfalls nicht besser gemacht. Warum die Qualität leiden soll kann ich auch nicht nachvollziehen. Die v6.3 bleibt ja erhalten. Zudem du sicherlich anders reden würdest wenn du avrdude verwenden würdest. Meine Interpretation hat sich nicht geändert. Ich glaube auch kaum das du einen Fork machen würdest. Zudem Forks im allgemeinen Kontraproduktiv sind. Am Ende gibts zu viele Forks und nichts passt mehr zusammen. Das lohnt nur für ganz spezielle Fälle. Es ist immer besser wenn alles im Hauptzweig bleibt und gepflegt wird. @ Jörg: Wenn das auf Github liegen würde könntest du sicherlich mehr Leute erreichen und damit auch bestimmt welche die sich auskennen und helfen könnten/würden. Ich selbst tue mich echt schwer. Zudem traue ich mich nicht ran, da ich befürchte eher eine Last zu sein statt Hilfe. Englisch ist auch nicht meine Stärke. Fremden Code lesen, vorallen in dem Umfang, ist sowieso immer so eine Sache für sich. Wenn ich den Rückstand der Bugreports lese wird das ein Kraftakt. Ich würde dich aktuell sogar verstehen, wenn man nicht mehr hinterherkommt und es selbst nicht benötigt es links liegen zulassen. Was natürlich Schade wäre im Gesamten gesehen um die ganze Arbeit. Aber vielleicht wäre ein Spendenaufruf eine Motivation? Ähnlich wie es für avr-gcc gemacht wurde. Oder einfach nur eine PayPal Sammlung. :-) Auch wenn es Hobby ist kostet es Zeit und Nerven wenn man es hauptsächlich für andere macht. Was wir aber sicherlich machen können, wenn sich die allgemeine Lage im Sommer entspannt hat, ein Bier trinken gehen. Vielleicht kommt noch jemand mit. Ich würde mich freuen. Erstens sieht man endlich mal die Nasen was die Kommunikation sicherlich auch zugänglicher macht. Vielleicht ergibt da auch was, vielleicht auch nicht. Wir werden sehen. :-)
Veit D. schrieb: > Wenn das auf Github liegen würde könntest du sicherlich mehr Leute > erreichen und damit auch bestimmt welche die sich auskennen und helfen > könnten/würden. Da bin ich mir nicht so sicher. Hilfe wird ja weniger gebraucht dafür, mal irgendwie einen Patch zu generieren, sondern "am Ball bleiben", Meldungen anderer Leute aufzunehmen, zu testen, einzupflegen. > Aber vielleicht wäre ein Spendenaufruf eine > Motivation? Für mich nicht. Falls es das für andere wäre: ich gebe auch was dazu. > Was wir aber sicherlich machen können, wenn sich die allgemeine Lage im > Sommer entspannt hat, ein Bier trinken gehen. Vielleicht kommt noch > jemand mit. Ich würde mich freuen. Sehr gern. Die soziale Komponente kommt bei all diesem Internet- und Forenkrams oft genug nicht so gut weg. (Wenn jemand kein Bier mag, gern auch ein anderes Getränk seiner Wahl, bei dem man einen Schwatz führen kann.)
Beitrag #6872535 wurde von einem Moderator gelöscht.
Veit D. schrieb: > Zudem Forks im allgemeinen Kontraproduktiv Veit D. schrieb: > Wenn das auf Github liegen würde könntest du sicherlich mehr Leute > erreichen Wenn das auf Github liegen würde, gäbe es zahlreiche Forks mit genau dem Problem das du beschriebst. Und es gäbe noch mehr Änderungswünsche (pull requests) und support Anfragen die sich auf Änderungen in den Forks anderer Leute beziehen. Ich habe das schon erlebt, war damit rasch überfordert, und habe mich deswegen aus Gitlab wieder zurück gezogen. Übrigens benutze und empfehle ich avrdude, das weiß sogar Google.
Jörg W. schrieb: > Die soziale Komponente kommt bei all diesem Internet- und > Forenkrams oft genug nicht so gut weg. Ja leider. Andererseits bin ich Kellerkind, das mit Computern besser klar kommt als mit Menschen. Insofern ist das Internet für mich eine tolle Sache.
Beitrag #6872717 wurde von einem Moderator gelöscht.
Beitrag #6872736 wurde von einem Moderator gelöscht.
Beitrag #6872752 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > Da bin ich mir nicht so sicher. > > Hilfe wird ja weniger gebraucht dafür, mal irgendwie einen Patch zu > generieren, sondern "am Ball bleiben", Meldungen anderer Leute > aufzunehmen, zu testen, einzupflegen. Ich nutze avrdude auch gerne, aber die Tatsache dass es schlecht gepflegt ist, bringt mich immer mehr davon ab. Für die neueren AVR128 nehme ich es schon gar nicht mehr her. Mit dem JTAGICE3 gibt es bei mir große Probleme (habe ich in einem anderen Thread schon beschrieben). Ich denke auch auf github hätte es die Chance mehr gepflegt zu werden. Ich habe auch schon neuere tinys manuell hinzugefügt. Konnte das aber nirgendwo publizieren.
:
Bearbeitet durch User
Cyblord -. schrieb: > Ich denke auch auf github hätte es die Chance mehr gepflegt zu werden. Aber wir wird das denn tun, wenn nicht Jörg? Dass Projekte alleine wegen Github automatisch zu einer Gemeinschaftsarbeit werden, halte ich für einen Irrtum.
Stefan ⛄ F. schrieb: > Cyblord -. schrieb: >> Ich denke auch auf github hätte es die Chance mehr gepflegt zu werden. > > Aber wir wird das denn tun, wenn nicht Jörg? Das sieht man ja dann. > Dass Projekte alleine wegen Github automatisch zu einer > Gemeinschaftsarbeit werden, halte ich für einen Irrtum. Richtig. Aber ohne Github werden sie es sicher nicht.
Stefan ⛄ F. fragte im Beitrag #6872828: > Aber wir wird das denn tun, wenn nicht Jörg? Cyblord -. gab eine Antwort im Beitrag #6872783: > Ich habe auch schon neuere tinys manuell hinzugefügt. Konnte das aber > nirgendwo publizieren.
Cyblord -. schrieb: > Konnte das aber nirgendwo publizieren. Ich sehe allerdings auch keinen Patch-Tracker-Eintrag von dir damit. Die neueren DA/DB sind jetzt auch drin (dank Microchip). Wenn alles gut geht, gibt's diese Woche ein Release 6.4.
Sicher werden uns die 8-Bitter noch lange Zeit begleiten, denn warum sollten wir oder irgendwelche Hersteller sich mit den 32-Bittern rumschlagen, wenn es um Lösungen geht, die ein 8-Bitter schon mit links erledigt. Und die alten DIP Gehäuse sind manchmal auch ein grosser Vorteil, wenn man mal schnell eine Lösung braucht. Ob man dazu allerdings einen der hyperneuesten Tinies braucht, oder einer der Klassiker reicht, das ist die Frage. Bisher habe ich da noch nichts gesehen, das ich unbedingt als Feature brauche. Da haben immer die alten ISP/PDI programmierbaren gereicht.
Jörg W. schrieb: > Ich sehe allerdings auch keinen Patch-Tracker-Eintrag von dir damit. Ohne Pull Request, ohne mich. Sorry ich finde das ganze nongnu.org system absolut grottig.
:
Bearbeitet durch User
Cyblord -. schrieb: > Ohne Pull Request, ohne mich. Dann isses halt so, und wenn nicht jemand anders die von dir gewünschten Tinys mal eingereicht hat, dann werden sie möglicherweise auch im nächsten Release nicht drin sein. Ob dann der JTAGICE3-Support besser ist, kann ich dir auch nicht sagen, denn ich habe keine Ahnung, was du damit für ein Problem hast. Für mich funktioniert er, aber meins läuft auch noch mit der nicht-CMSIS-DAP-Firmware, aber die AtmelICEs funktionieren für mich ebenfalls. Ja, deren Web-UI wirkt etwas altbacken, aber es funktioniert, und solange das eine One-man-show ist, sehe ich mit überall verstreuten Repos und von da gesendeten Pull Requests bestenfalls zusätzliche Arbeit, ohne dass auf meiner Seite was schneller oder einfacher gehen würde. So, wie es ist, habe ich zumindest eine Latte von Bug- und Patch-Reports, die ich bei vorhandener Zeit abarbeiten kann und für die ich Rückfragen stellen kann. Für einen Bugreport muss man sich ja nicht einmal anmelden (und kann auf Wunsch trotzdem einen Patch anhängen).
Jörg W. schrieb: > Dann isses halt so, und wenn nicht jemand anders die von dir gewünschten > Tinys mal eingereicht hat, dann werden sie möglicherweise auch im > nächsten Release nicht drin sein. Wie gesagt, ich bin für alle aktuelleren Sachen schon auf die originalen Tools umgestiegen. Ich nutze avrdude nur noch für ältere Projekte. Man bekommt ja nicht mal so einfach ne aktuelle Windows Binary her. > Ja, deren Web-UI wirkt etwas altbacken, aber es funktioniert, und > solange das eine One-man-show ist, sehe ich mit überall verstreuten > Repos und von da gesendeten Pull Requests bestenfalls zusätzliche > Arbeit, ohne dass auf meiner Seite was schneller oder einfacher gehen > würde. Ich denke das bleibt so auch eine One-Man-Show und scheinst das auch genau so zu wollen. Da kann man nichts machen. Deine Antwort wirkt auf mich sehr starrsinnig. Manchmal muss man eben mit der Zeit gehen, und für verteiltes entwickeln ist git im Moment das Maß der Dinge. Diesen angeblichen erhöhten Aufwand gibt es so nicht. So gesehen finde ich deine Aussage, dass sich niemand für die Mitarbeit findet, heuchlerisch. Du tust ja nun wirklich alles um Mitarbeit zu verhindern. > Für mich funktioniert er, aber meins läuft > auch noch mit der nicht-CMSIS-DAP-Firmware, aber die AtmelICEs > funktionieren für mich ebenfalls. Das passt zu deiner Mentalität: Hauptsache bei dir geht es. Niemand will gesagt bekommen, er müsse für eine aktuelle Version erst mal das Ding selbst kompilieren -> aus der Zeit gefallen. Auch hier könnten Menschen auf github packages für verschiedene OS erstellen. avrdude wird sich sehr bald erledigt haben, und ich weiß jetzt auch warum.
:
Bearbeitet durch User
Cyblord -. schrieb: > Man bekommt ja nicht mal so einfach ne aktuelle Windows Binary her. Rat mal warum? Weil es außer mir kaum jemanden gab, der welche bauen wollte. Sofern meine MinGW-Umgebung noch funktioniert, werde ich sicher auch vom nächsten Release einen Windows-Build hochladen. Alle anderen OSe außer Windows bauen sich das Zeug selbst über einen Package Manager. Wenn es Windowsianern so wichtig wäre, warum setzt sich nicht jemand hin und hostet eine Seite mit weekly builds oder sowas? Dafür braucht es nicht unbedingt Git, aber es braucht jemanden, der es tut. Genau das sind die Leute, an denen es aber dem Projekt mangelt. > Ich denke das bleibt so auch eine One-Man-Show und scheinst das auch > genau so zu wollen. Nö, aber ich brauche keine Leute, die mir noch mehr Pull Requests senden, davon habe ich schon genug (auch wenn sie nicht "Pull Request" sondern "Patch" heißen). Ich brauche Leute, die das, was andere gesendet haben ansehen, testen, ggf. Rückfragen stellen, Doku ergänzen. Und natürlich solche, die sich eingereichte Bugs ansehen. > Diesen angeblichen erhöhten Aufwand gibt es so nicht. Der erhöhte Aufwand liegt erstmal nur in der Migration von SVN nach Git. Es entsteht halt aber für mich auch kein reduzierter Aufwand dadurch. >> Für mich funktioniert er, aber meins läuft >> auch noch mit der nicht-CMSIS-DAP-Firmware, aber die AtmelICEs >> funktionieren für mich ebenfalls. > > Das passt zu deiner Mentalität: Hauptsache bei dir geht es. Nein, das ist nicht Mentalität, sonst würde ich mich um die anderen Bugs nicht kümmern. Aber was ich nicht kenne, kann ich nicht einmal ahnen, geschweige denn erinnere ich mich dann, wenn ich mal Zeit dafür habe, noch an irgendwelche Details in einem Forum.
Jörg W. schrieb: > Sofern meine MinGW-Umgebung noch funktioniert, werde ich sicher auch vom > nächsten Release einen Windows-Build hochladen. DAS klingt mal richtig nach Abgesang. Mit so einer Einstellung wundert mich nichts mehr. Stefan hat recht, lass das Ding sterben. Wenn man schon zu träge ist ne Windows Binary zu pflegen. > Wenn es Windowsianern so wichtig wäre, warum setzt sich > nicht jemand hin und hostet eine Seite mit weekly builds oder sowas? > Dafür braucht es nicht unbedingt Git, aber es braucht jemanden, der es > tut. Mit git bräuchte es eben keine eigene Seite. Eigentlich sollte heute sowas sowieso automatisch über CI bauen. github bietet hier sogar was in der Richtung an. Das jedes mal selbst lokal auf nem MinGW hinstoppeln ist halt auch einfach nicht mehr zeitgemäß. Ein CI hat auch den Vorteil dass du bei jedem Pullrequest gleich sehen kannst, ob der für alle Systeme ordentlich baut. BEVOR du mergt. Auch das würde dich wieder beim Thema "Testaufwand" entlasten. Aber selbst wenn man es erstmal beim manuellen Bauen belässt, könnte man die Binary direkt im repo anbieten statt irgendwo auf einer anderen Seite. Das würde die Motivation deutlich steigern. Wie schon gesagt, es ist unredlich von dir, ständig auf fehlende Hilfe abzustellen, aber jede Verbesserung in diese Richtung strikt abzulehnen.
:
Bearbeitet durch User
Cyblord -. schrieb: > Eigentlich sollte heute sowas sowieso automatisch über CI bauen. github > bietet hier sogar was in der Richtung an Der größte Teil des Codes ist OS-agnostisch, wenn das also unter System A baut, baut es auch unter B. An den systemabhängigen Teilen hat sich schon sehr lange nichts mehr geändert. Wichtiger als das Bauen wäre das Testen. Aber das als CI einzurichten, ist ziemlicher Aufwand. Wollte man es unter verschiedenen OSes testen, noch mehr davon. Ich mach dir einen Vorschlag: nimm das SVN-Repo, migriere es so zu Github, dass die History die gleiche ist, migriere alle Bug- und Patch-Reports. (Die geschlossenen müssen meinetwegen nicht migriert werden, wenngleich es gut wäre um zu sehen, was es schon mal gab.) Dann wäre das erstmal der Status Quo repliziert. Optional, bereite mir ein CI vor, zumindest für die Compilierung. Runner kann bei mir laufen, aber von mir aus auch dort (Linux würde mir genügen als Test). Auf diese Weise habe ich keine zusätzliche Arbeit damit (die reguläre ist ja schon genug). Die Mailingliste fehlt dann eigentlich noch, aber die ist vielleicht nicht ganz so wichtig. Wenn das fertig ist, wechsle ich mit dem Projekt problemlos dorthin, das sichere ich dir hiermit zu.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Ich mach dir einen Vorschlag: nimm das SVN-Repo, migriere es so zu > Github, dass die History die gleiche ist Das ist kein Problem. Von SVN nach GIT kann man quasi vollautomatisch migrieren. E > migriere alle Bug- und > Patch-Reports. (Die geschlossenen müssen meinetwegen nicht migriert > werden, wenngleich es gut wäre um zu sehen, was es schon mal gab.) Das wird nur manuell gehen. Allerdings kann man sowieso fragen wieso man "Patch Reports" braucht. Die werden wohl durch Pull Requests ersetzt. Für Bugs kann man den github Bugtracker für Projekte nehmen. > Die Mailingliste fehlt dann eigentlich noch, aber die ist vielleicht > nicht ganz so wichtig. Ja sorry Mailingliste? Diese Zeiten sind vorbei. > Wenn das fertig ist, wechsle ich mit dem Projekt problemlos dorthin, das > sichere ich dir hiermit zu. Ja sicher. WENN alle deine unrealistischen Forderungen erfüllt sind, dann. Das nennt man auch "Ablehnungsangebot". Wenn man das zu git migrieren würde, würdest du 1001 Gründe finden warum das quatsch ist, das git repo würde parallel zu deinem SVN repo stehen und wäre genau so tot. Du zeigst ja jetzt bereits nichts als Ablehnung. Du könntest Hilfe auch ernsthaft annehmen. Aber dafür scheinst du dann doch zu starrsinnig. Ich denke es ist für alle das beste du werkelst daran noch ein wenig alleine rum und lässt es dann friedlich einschlafen. Und wenn jemand fragt warum, erzählst du wieder deine Mär von der fehlenden Hilfe.
:
Bearbeitet durch User
Cyblord -. schrieb: > Du könntest Hilfe auch ernsthaft annehmen. "Hilfe annehmen" -> "Mach das, was ich Dir sage, damit ich Dir nachher sagen kann, dass Du es falsch gemacht hast." Auf diese Art von Hilfe kann jeder getrost verzichten.
Cyblord -. schrieb: > Das wird nur manuell gehen. Allerdings kann man sowieso fragen wieso man > "Patch Reports" braucht. Die werden wohl durch Pull Requests ersetzt. Dann müssten aber die bereits eingereichten Patches als Pull Requests umgeschrieben werden. > Für Bugs kann man den github Bugtracker für Projekte nehmen. Ja, klar, aber von allein kommen die bereits eingereichten Bugs nicht dahin. Die sollten jedoch nicht weggeworfen werden. >> Die Mailingliste fehlt dann eigentlich noch, aber die ist vielleicht >> nicht ganz so wichtig. > > Ja sorry Mailingliste? Diese Zeiten sind vorbei. Keineswegs. Wenn es mehr Leute gäbe, die mit diskutieren möchten, braucht man ein Medium dafür. > Ja sicher. WENN alle deine unrealistischen Forderungen erfüllt sind, > dann. > Das nennt man auch "Ablehnungsangebot". Was ist daran unrealistisch? Du hast mir zuvor erklärt, dass es gar keine Mehrarbeit gäbe. Soll ich alles, was im Projekt jenseits des Sourcecodes bereits existiert, wegschmeißen, nur um dann mit Github oder Gitlab anzufangen?
Jörg W. schrieb: > Dann müssten aber die bereits eingereichten Patches als Pull Requests > umgeschrieben werden. Alles was noch nicht gemergt ist, mergt doch noch auf der Alten Plattform. Alles Neue kommt nur noch als Pullrequest rein. Da muss man gar nichts umschreiben. > >> Für Bugs kann man den github Bugtracker für Projekte nehmen. > > Ja, klar, aber von allein kommen die bereits eingereichten Bugs nicht > dahin. Die sollten jedoch nicht weggeworfen werden. Die Bugs umzutragen ist kein großer Aufwand. > Keineswegs. Wenn es mehr Leute gäbe, die mit diskutieren möchten, > braucht man ein Medium dafür. Diskutieren ja. Aber doch nicht über Maillinglisten. > Was ist daran unrealistisch? Du hast mir zuvor erklärt, dass es gar > keine Mehrarbeit gäbe. Im Betrieb. Natürlich erfordert das Umziehen etwas Arbeit. > Soll ich alles, was im Projekt jenseits des Sourcecodes bereits > existiert, wegschmeißen, nur um dann mit Github oder Gitlab anzufangen? Du kannst nicht alles 1:1 übernehmen. Aber mit der Maximalforderung kannst du niemals auf eine moderne Plattform umsteigen.
Cyblord -. schrieb: > Alles was noch nicht gemergt ist, mergt doch noch auf der Alten > Plattform. Das funktioniert ja nun schon seit Jahren nicht. Ohne irgendeine Art von Migration wird das nichts, und es braucht Arbeit – die jemand machen muss. Gute Ratschläge allein helfen da nicht. > Aber mit der Maximalforderung Das war eher die Minimalforderung.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Cyblord -. schrieb: >> Alles was noch nicht gemergt ist, mergt doch noch auf der Alten >> Plattform. > > Das funktioniert ja nun schon seit Jahren nicht. Wie ist das zu verstehen? Ein Grund mehr, die aktuellen alten Patches wegzuwerfen. Wenn die sowieso nicht gemergt werden. Und ein Grund mehr etwas zu ÄNDERN! Auf github würdest du mehr Leute finden die reviewen und mergen könnten. > Ohne irgendeine Art von Migration wird das nichts, und es braucht Arbeit > – die jemand machen muss. Ja sicher. Und wenn du dir damit absolut keine Arbeit mehr machen willst, dann sage das doch klar und dann kannst du das Projekt begraben. Wenn du sogar die letzte Möglichkeit, die Migration auf git, aus Zeitgründen nicht mehr angehen kannst, dann ist das halt so. Dann hilft aber eben auch alles nicht mehr. > Gute Ratschläge allein helfen da nicht. Kopf in den Sand halt leider auch nicht.
:
Bearbeitet durch User
Beitrag #6873327 wurde von einem Moderator gelöscht.
Hallo Cyblord, ein ganz bescheidene Frage. Das liest sich bei dir alles so einfach. Könntest du das nicht einfach einmal machen, diesen migrieren auf Github. @ all: Ich würde folgenden Vorschlag unterbreiten. Jörg möchte ja den aktuellen Stand als v.6.4 rausbringen. Dann könnte man den Stand 6.4 als Basis nehmen für Github und dann müßten alle die Fehler finden sich neu auf 6.4 beziehen. Sodass man sich damit die alten Bugreports bis dahin entledigt. Man fängt also mit 6.4 auf Github frisch an. Dann muss man nicht alles umziehen. Wäre das denkbar oder zu naiv gedacht?
Beitrag #6873633 wurde von einem Moderator gelöscht.
Veit D. schrieb: > Könntest du das nicht einfach einmal machen, diesen migrieren auf > Github. Er hat begonnen, das zu tun. Mal sehen, wie sich das dann alles anfühlt, aber es bewegt sich in eine sinnvolle Richtung, denke ich. > Jörg möchte ja den aktuellen Stand als v.6.4 rausbringen. Ich tendiere jetzt auch dazu, 6.4 noch auf SVN/Savannah zu machen. Da die Übertragung sowieso komplett gescriptet ist, sowie der Import-Script für Bugs (und ggf. Patches) steht, dann kann man sich überlegen, ob man entweder die Bugs, die ich in Savannah noch bearbeitet habe, nachträglich auf Github noch schließt, oder ob man den Script einfach nochmal laufen lässt. Da mein Ziel für die 6.4 diese Woche ist, könnte das mit Cyblords Scripts ja einigermaßen zusammen passen. Leider ist der Account "avrdude" auf Github schon vergeben, wenngleich komplett leer. Wenn jemand eine Idee hat, wie man dessen Eigentümer kontaktieren kann, daran hätte ich Interesse.
:
Bearbeitet durch Moderator
Beitrag #6873653 wurde von einem Moderator gelöscht.
Beitrag #6873654 wurde von einem Moderator gelöscht.
Beitrag #6873655 wurde von einem Moderator gelöscht.
Beitrag #6873656 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > Ich tendiere jetzt auch dazu, 6.4 noch auf SVN/Savannah zu machen. Ja mach das. Dann gibt es einen aktuellen Stand noch auf SVN und der Umzug auf github kann in aller Ruhe erfolgen.
Beitrag #6874575 wurde von einem Moderator gelöscht.
Beitrag #6874576 wurde von einem Moderator gelöscht.
Beitrag #6874577 wurde von einem Moderator gelöscht.
Beitrag #6874578 wurde von einem Moderator gelöscht.
Beitrag #6874581 wurde von einem Moderator gelöscht.
Beitrag #6874582 wurde von einem Moderator gelöscht.
Beitrag #6874584 wurde von einem Moderator gelöscht.
Beitrag #6874585 wurde von einem Moderator gelöscht.
Beitrag #6874586 wurde von einem Moderator gelöscht.
Beitrag #6874587 wurde von einem Moderator gelöscht.
Beitrag #6874589 wurde von einem Moderator gelöscht.
Beitrag #6874590 wurde von einem Moderator gelöscht.
Beitrag #6874591 wurde von einem Moderator gelöscht.
Beitrag #6874593 wurde von einem Moderator gelöscht.
Beitrag #6874594 wurde von einem Moderator gelöscht.
Beitrag #6874595 wurde von einem Moderator gelöscht.
Beitrag #6874597 wurde von einem Moderator gelöscht.
Beitrag #6874598 wurde von einem Moderator gelöscht.
Beitrag #6874599 wurde von einem Moderator gelöscht.
Beitrag #6874600 wurde von einem Moderator gelöscht.
Beitrag #6874601 wurde von einem Moderator gelöscht.
Beitrag #6874602 wurde von einem Moderator gelöscht.
Beitrag #6874603 wurde von einem Moderator gelöscht.
Beitrag #6874604 wurde von einem Moderator gelöscht.
Beitrag #6874605 wurde von einem Moderator gelöscht.
Beitrag #6874606 wurde von einem Moderator gelöscht.
Beitrag #6874607 wurde von einem Moderator gelöscht.
Beitrag #6874608 wurde von einem Moderator gelöscht.
Beitrag #6874609 wurde von einem Moderator gelöscht.
Beitrag #6874610 wurde von einem Moderator gelöscht.
Beitrag #6874612 wurde von einem Moderator gelöscht.
Beitrag #6874613 wurde von einem Moderator gelöscht.
Beitrag #6874614 wurde von einem Moderator gelöscht.
Beitrag #6874615 wurde von einem Moderator gelöscht.
Beitrag #6874616 wurde von einem Moderator gelöscht.
Beitrag #6874618 wurde von einem Moderator gelöscht.
Beitrag #6874619 wurde von einem Moderator gelöscht.
Beitrag #6874620 wurde von einem Moderator gelöscht.
Beitrag #6874621 wurde von einem Moderator gelöscht.
Beitrag #6874622 wurde von einem Moderator gelöscht.
Beitrag #6874623 wurde von einem Moderator gelöscht.
Beitrag #6874625 wurde von einem Moderator gelöscht.
Beitrag #6874626 wurde von einem Moderator gelöscht.
Beitrag #6874628 wurde von einem Moderator gelöscht.
Beitrag #6874629 wurde von einem Moderator gelöscht.
Beitrag #6874630 wurde von einem Moderator gelöscht.
Beitrag #6874631 wurde von einem Moderator gelöscht.
Beitrag #6874632 wurde von einem Moderator gelöscht.
Beitrag #6874635 wurde von einem Moderator gelöscht.
Beitrag #6874636 wurde von einem Moderator gelöscht.
Beitrag #6874637 wurde von einem Moderator gelöscht.
Beitrag #6874638 wurde von einem Moderator gelöscht.
Beitrag #6874641 wurde von einem Moderator gelöscht.
Beitrag #6874642 wurde von einem Moderator gelöscht.
Beitrag #6874643 wurde von einem Moderator gelöscht.
Beitrag #6874644 wurde von einem Moderator gelöscht.
Beitrag #6874646 wurde von einem Moderator gelöscht.
Beitrag #6874647 wurde von einem Moderator gelöscht.
Beitrag #6874648 wurde von einem Moderator gelöscht.
Beitrag #6874650 wurde von einem Moderator gelöscht.
Beitrag #6874651 wurde von einem Moderator gelöscht.
Beitrag #6874652 wurde von einem Moderator gelöscht.
Beitrag #6874654 wurde von einem Moderator gelöscht.
Beitrag #6874655 wurde von einem Moderator gelöscht.
Beitrag #6874656 wurde von einem Moderator gelöscht.
Beitrag #6874658 wurde von einem Moderator gelöscht.
Beitrag #6874659 wurde von einem Moderator gelöscht.
Beitrag #6874660 wurde von einem Moderator gelöscht.
Stefan ⛄ F. schrieb: > Der Trend zu 32 Bit Controllern ist > deutlich zu sehen. Wenn ich jetzt anfangen würde, dann wäre das sicher auch ein 32 Bit, aber ich werde diese Leistung wohl kaum noch in meinem Leben brauchen und da ich noch wirklich viele Tiny10 hier habe, reichen die bis an mein Lebensende. Das meiste gibt es heute doch eh schon fertig zu kaufen und besser als ich das selbst bauen könnte. Die Anwendungen, wo die eigenen Maßnahmen erforderlich sind, brauchen selten mehr als einen Tiny10. Den ganzen 32 Bit Kram zu lernen, das ist schon ein ganz schön großer Aufwand.
F. F. schrieb: > Den ganzen 32 Bit Kram zu lernen, das ist schon ein ganz schön großer > Aufwand. Ja. Ich habe damit angefangen aber nicht in der Tiefe, wie ich mit mit AVR befasst habe. Irgendwie ist mir die Lust vergangen. Wenn mein Sohn ankommen würde und Mikrocontroller kennen lernen wollte, würde ich ihm wahrscheinlich direkt die STM32 Boards geben und die "alten" Arduino Nanos für mich behalten sofern er mit den STM32 klar kommt.
Stefan ⛄ F. schrieb: > würde ich ihm wahrscheinlich direkt die STM32 Boards geben Alleine das Datenblatt ist doch schon um die 1000 Seiten. Ich hatte schon einmal damit anfangen wollen, aber da habe ich gar nicht genug Zeit dazu.
Beitrag #6874910 wurde von einem Moderator gelöscht.
Beitrag #6874911 wurde von einem Moderator gelöscht.
Beitrag #6874914 wurde von einem Moderator gelöscht.
Beitrag #6874915 wurde von einem Moderator gelöscht.
Beitrag #6874917 wurde von einem Moderator gelöscht.
Beitrag #6874919 wurde von einem Moderator gelöscht.
Beitrag #6874920 wurde von einem Moderator gelöscht.
Beitrag #6874922 wurde von einem Moderator gelöscht.
Beitrag #6874925 wurde von einem Moderator gelöscht.
Beitrag #6874926 wurde von einem Moderator gelöscht.
Beitrag #6874927 wurde von einem Moderator gelöscht.
Beitrag #6874928 wurde von einem Moderator gelöscht.
Beitrag #6874931 wurde von einem Moderator gelöscht.
Beitrag #6874932 wurde von einem Moderator gelöscht.
Beitrag #6874933 wurde von einem Moderator gelöscht.
Beitrag #6874934 wurde von einem Moderator gelöscht.
Beitrag #6874936 wurde von einem Moderator gelöscht.
Beitrag #6874937 wurde von einem Moderator gelöscht.
Beitrag #6876141 wurde von einem Moderator gelöscht.
Beitrag #6876142 wurde von einem Moderator gelöscht.
Beitrag #6876143 wurde von einem Moderator gelöscht.
Beitrag #6876144 wurde von einem Moderator gelöscht.
Beitrag #6876145 wurde von einem Moderator gelöscht.
Beitrag #6876146 wurde von einem Moderator gelöscht.
Beitrag #6876148 wurde von einem Moderator gelöscht.
Beitrag #6876149 wurde von einem Moderator gelöscht.
Beitrag #6876150 wurde von einem Moderator gelöscht.
Beitrag #6876151 wurde von einem Moderator gelöscht.
Beitrag #6876152 wurde von einem Moderator gelöscht.
Beitrag #6876153 wurde von einem Moderator gelöscht.
Beitrag #6876154 wurde von einem Moderator gelöscht.
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.