Noch kein tinyAVR Support in avrdude?

Um welchen Tiny geht es denn?

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.

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.

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.

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.

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.

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. ;-)

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.

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?

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.

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?

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.

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.)

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.)

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

Die Löschorgie finde ich jetzt allerdings unnötig.

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.

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.

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.