Dieses Projekt macht aus einem Arduino Nano Boards mit geringen Modifikationen den schnellsten In-System-Programmer (ISP) für klassische AVR-Bausteine wie ATtiny und ATmega.
Wer professionell mit klassischen AVR-Prozessoren arbeitet, kommt um den STK500 kaum herum; ich verwende ihn auch als Entwicklungsplatform. Allerdings sprechen zwei Dinge dagegen, ihn für die Programmierung fertiger Targets via ISP zu verwenden: Er benötigt eine externe Stromversorgung und braucht reichlich Platz auf dem Tisch. Hier kommt mein nanoSTK ins Spiel, klein, robust dank der Verwendung des nano-ISP-Anschlusses, transportabel und stand-alone, auch auf Reisen. Außerdem programmiert mein nanoSTK viel schneller als mein STK500.
Der Quellcode wurde ursprünglich mit der Arduino-Toolchain (Version 1.8.19) unter Linux Debian stable erstellt und getestet. Ab Version 1.50 ist der Build-Prozess nicht mehr von der Arduino-Toolchain abhängig - es wird nur noch die avr-gcc-Toolchain benötigt.
Oder halt die durchaus nennenswerte Anzahl anderer STK500(V2)-kompatibler Programmieradapter, die es (teils seit velen Jahren) am Markt gibt...
Darüber hinaus auch mehrere Bastelprojekte (ebenfalls von vor vielen Jahren), die ebenfalls genau diese Funktinalität bereit gestellt haen. Sowas wie "AVR-Doper" z.B.
Alle gut getestet und komplett ohne Arduino entstanden. Auch wenn du es kaum glauben kannst: Ja, es geht durchaus auch was ohne Arduino...
Ich bin kein AVRler, daher verzeihe mir meine Unwissenheit, aber was sind denn die Vorteile gegenüber zum Beispiel dem USBasp? Ist es einzig die Kompatibilität zum STK500 Protokoll?
Ich bin kein AVRler, daher verzeihe mir meine Unwissenheit, aber was
sind denn die Vorteile gegenüber zum Beispiel dem USBasp? Ist es einzig
die Kompatibilität zum STK500 Protokoll?
Das "allein" ist allerdings ist ein recht großer Vorteil. Denn es erlaubt die problemlose direkte Nutzung aus allen Atmel/Microchip-IDEs.
aber was sind denn die Vorteile gegenüber zum Beispiel dem USBasp?
Ein sauberes USB-Protokoll zum Beispiel. ;-) USBasp (und die anderen auf VUSB basierenden Projekte) ist cool, aber es ist als Software-USB halt grenzwertig. Ein USB-Logo könnte es nicht bekommen :-), und da es nur Lowspeed-USB ist, ist auch die Datenrate begrenzt.
Ist es einzig die Kompatibilität zum STK500 Protokoll?
Die natürlich auch mehr als hilfreich sein kann, wenn man das Teil beispielsweise direkt aus Atmel^H^H^H^H^HMicrochip Studio heraus bedienen möchte.
soweit war ich auch schon, ein Widerstannd für alle, oder für jede LED einen eigenen, das Suchspiel ist mir zu doof!
Soll man nun aus dem Code high und low für Anode, Kathode raussuchen?
Richtige Dokumentation geht anders.
Soll man nun aus dem Code high und low für Anode, Kathode raussuchen?
Such's Dir halt aus. Wenn die LEDs genau dann nicht leuchten, wenn Du es erwartetst, aber leuchten, wenn Du es nicht erwartest, hast Du es wohl falsch herum angestellt.
Auf dem Frickelboard ist das in drei Minuten abgegessen.
Es tut mir leid Dich zu traumatisieren, ich habe es daher noch einmal verdeutlicht. Ungeübte Anfänger hätten die optionalen LEDs auch erstmal weglassen können.
1
Heartbeat - Indicates that the programmer is running
2
D9 (PB1) ----|>|----/\/\---- GND
3
LED1 R1
4
5
Error - An Error has occured - clear with programmer reset
Auch wenn du es
kaum glauben kannst: Ja, es geht durchaus auch was ohne Arduino...
Bevor ich das alles zusammenfädele nehme ich lieber einen nano aus meiner Grabbelkiste - man sollte immer ein paar davon als Vorrat haben. Und wenn Du auf GitHub schaust, dann siehst Du, dass in meiner Software kein Arduino-Kram steckt; serielle Schnittstelle mit Interrupt sowie SPI, Timer und Analog-IO kommen aus eigenen Modulen - es braucht nur avr-gcc - nix *.ino.
Nur für die reinen Anwender, speziell die Windows-Nutzer, die sich mit Kommandozeile und "make" schwertun, gibt es im Branch "arduino_toolchain" das ganze auch "maker-gerecht" als „Sketch“ - wir haben halt alle mal klein angefangen.
glaub ich dir nicht, du wolltest nur angeben, sehe es doch ein!
Und du hast gar nichts geleistet, und meckerst an jemandem rum, der etwas geleistet hat. Sieh ein, das solch ein Charakterzug den Besitzer des Charakterzuges bei vielen Leuten unbeliebt macht.
Dass man auf dem Nano Board noch eine kleine Änderung vornehmen
soll sollte auch noch Erwähnung finden. Irgendwo in den
Sourcen steht's drin ... wer sich's aufmerksam durchschaut.
Der Kellner: "Wie fanden sie das Fleisch?"
Der Gast: "Ach, ganz zufällig als ich eine Kartoffel beiseite schob!"
glaub ich dir nicht, du wolltest nur angeben, sehe es doch ein!
Du weisst, wie man Leute motiviert, ihre Projekte zu veröffentlichen. Zum Glück bist Du kein Lehrer geworden.
Dass Martin kein Profi ist, ist offensichtlich, sonst hätte er gewusst, dass es auch von Atmel/Microchip ISP-Tools ohne die Nachteile des STK500 gibt.
Aber für Leute, die ohnehin überall Arduinos rumliegen haben, ist das ein schnell zu bauendes Werkzeug. Die Schwächen in der Dokumentation bekommt er nach sachlichen (!) Hinweisen bestimmt behoben.
Dass Martin kein Profi ist, ist offensichtlich, sonst hätte er gewusst,
dass es auch von Atmel/Microchip ISP-Tools ohne die Nachteile des STK500
gibt.
Du hast recht, ich werde nicht mehr fürs AVR-Programmieren bezahlt, meine Mitarbeiter sind auch schon lange auf 32 Bit umgestiegen. Allerdings ist Deine Annahme falsch, dass ich die Microchip-Tools nicht kennte - das Gegenteil ist der Fall. Ich hatte bisher jedoch keinen Bedarf zur Anschaffung und manchmal ist es auch eine nette Fingerübung, etwas selber aufzubauen.
Allerdings ist Deine Annahme falsch, dass ich die Microchip-Tools nicht
kennte - das Gegenteil ist der Fall.
OK, dann kam das in Deinem ersten Beitrag etwas missverständlich rüber. Das STK500 ist ja eher zum Kennenlernen der AVR-Plattform gedacht, auch wenn man es gut als (etwas unhandliche) eierlegende Wollmilchsau einsetzen kann.
Unterstützen die Microchip-Tools eigentlich noch das STK500v1-Protokoll? Ich meine mich zu erinnern, dass ab einer bestimmten AVR-Studio-Version direkt zum Update des STK500 oder AVRISP (damals noch ohne mkII) aufgefordert wurde.
Du hast recht, ich werde nicht mehr fürs AVR-Programmieren bezahlt,
meine Mitarbeiter sind auch schon lange auf 32 Bit umgestiegen.
Allerdings ist Deine Annahme falsch, dass ich die Microchip-Tools nicht
kennte - das Gegenteil ist der Fall. Ich hatte bisher jedoch keinen
Bedarf zur Anschaffung und manchmal ist es auch eine nette Fingerübung,
etwas selber aufzubauen.
Mir egal ob du Profi oder Hobbyist bist, ich find es super, dass du deine Mühe hier zur Verfügung stellst, auch wenn ich keinen Bedarf habe. Mir war mal so, als wäre genau so etwas Teil des Forumsgedankens.
Das STK500 ist ja eher zum Kennenlernen der AVR-Plattform gedacht, auch
wenn man es gut als (etwas unhandliche) eierlegende Wollmilchsau
einsetzen kann.
Dafür habe ich ihn mir vor ~20 Jahren auch privat angeschafft, für Prototypen hilfreich, auch als Programmer stabiler als Pony etc.
glaub ich dir nicht, du wolltest nur angeben, sehe es doch ein!
Und du willst eh bloß stänkern, macht es den Eindruck. Das sieht nicht danach aus, als wölltest du das Projekt selbst aufbauen.
Dann lass es einfach, du hast einmal (in eher unfreundlichem Ton) angemerkt, dass du dir mehr Dokumentation wünschst, damit ist es dann seine Sache, was er daraus macht.
Dann lass es einfach, du hast einmal (in eher unfreundlichem Ton)
angemerkt, dass du dir mehr Dokumentation wünschst, damit ist es dann
seine Sache, was er daraus macht.
stimmt der Ton war unfreundlich weil ich mich in Github und den source durchgewühlt hatte und die Lust verloren habe.
Es ehrt ihn das er sowas veröffentlicht, aber für mich ist es halt unvollständig, was hinderte ihn ein Schaltplan mitzuliefern?
Andere Projekte schaffen das auch.
Auch wenn meine "Kritik" unfreundlich war so finde ich sie berechtigt, er ist nun mal kein Neuling nach eigenen Aussagen.
Das sieht nicht
danach aus, als wölltest du das Projekt selbst aufbauen.
nun stänkerst du, natürlich wollte ich das aufbauen, sonst wäre ich nicht jedem Stöckchen hinterher gerannt, das schrieb ich doch, für dich wiederhole ich nochmal:
weil ich mich in Github und den source durchgewühlt hatte
Wer professionell mit klassischen AVR-Prozessoren arbeitet, kommt um den
STK500 kaum herum
Schönes Projekt Martin.
ISP Programmierer gibts aber wie Sand am Meer. Und ich gebe zu bedenken daß professionelles Arbeiten mit AVRs die inzwischen große Welt neuer, leistungsfähigerer Typen, die via 1+VCC/GND Pin UPDI nicht nur programmiert sondern auch debuggt werden können einschließen sollte.
stimmt der Ton war unfreundlich weil ich mich in Github und den source
durchgewühlt hatte und die Lust verloren habe.
Naja, Du hast aber auch betont wenig Elan an den Tag gelegt. Ich hatte mir aufgrund Deines Gegreines den Github-Source angesehen und dort die Information in deutlich unter 5 Minuten gefunden.
Besser wäre es gewesen, wäre der Schaltplan, der für das Projekt als Bezug verwendet wird, nicht nur im Eagle-Format veröffentlicht worden, sondern auch in einem ohne CAD-Software lesbaren Format (pdf oder png).
Ich finde das Projekt interessant, weil man auf die Schnelle einen Programmer zusammenhacken kann.
Ich würde aus Faulheitsgründen nur ein Widerstand für die LED verwenden. Bei Status-LEDs ist es Wurst, wenn sie etwas dunkler leuchten, wenn mehrere LEDs eingeschaltet werden, da die Lichtempfindlichkeit sowie so exponentiell ist. Wenn man ganz viel Muße hat, kann man noch ein LED-Multiplexing einbauen, dann bleibst gleich hell.
Ah, und vielleicht noch was:
Bei GitHUB Projekten ist es immer gut, wenn man nach dem Standardschema "What, Why, How" dokumentiert.
Also: Die Beschreibung "was macht das Projekt", "warum macht man das Projekt, was sind die Vorteile gegenüber anderen" und "Wie macht man das Projekt (Installation und Benutzung)".
Also: Die Beschreibung "was macht das Projekt", "warum macht man das
Projekt, was sind die Vorteile gegenüber anderen" und "Wie macht man das
Projekt (Installation und Benutzung)".
Sich auch noch rechtfertigen müssen dass man seine Arbeit der
Allgemeinheit zur Verfügung stellt? Neee danke.
Überzeugen dass man das Projekt annehmen soll (nimm mich, nimm
mich doch endlich)? Neee danke.
Wer das Projekt nicht zu schätzen und einzuschätzen vermag der
möge doch einfach drauf verzichten.
Es ehrt ihn das er sowas veröffentlicht, aber für mich ist es halt
unvollständig, was hinderte ihn ein Schaltplan mitzuliefern?
Andere Projekte schaffen das auch.
Ehrlich gesagt hatte ich dem Schaltplan keine große Relevanz beigemessen, da sich (mir) der Anschluss der - wie angemerkt - optionalen LEDs problemlos erschlossen hatte; das „Blinkenlight“ auf meiner HW war eh' ein Erbe der ScratchMonkey-FW, die vorher auf dem Programmer werkelte.
Hättest Du - so wie es auf GH üblich ist - ein Issue erstellt oder z.B. auch in Q'n'A der Diskussionen angemerkt, dass der Schaltplan fehlt, hätte ich ihn (wie auch auf Deinen unfreundlichen Rant hin) kurzfristig nachgeliefert, aber der Ton macht die Musik, und damit hast Du Dir ein schlechtes Karma erworben.
Ich finde das Projekt interessant, weil man auf die Schnelle einen
Programmer zusammenhacken kann.
Deshalb hab' ich es veröffentlicht. Es hat mich beim Fummeln am Transistor-Tester genervt, dass mein STK500 plus Peripherie zuviel Platz auf meinen Schreibtisch wegnahm - also hatte ich die Möglichkeit, einen neuen Programmer anzuschaffen, das hätte Tage der Lieferzeit gekostet oder schnell in ein paar Stunden was zu hacken - und als es dann lief fand ich es so interessant, dass ich mich vertiefte, ist das nicht Sinn eines Hobbys?
Ich würde aus Faulheitsgründen nur ein Widerstand für die LED verwenden.
Ich auch - was soll ich sagen, es funktioniert so gut (meist ist nur eine LED + Heartbeat aktiv), dass ich es dabei belassen habe. :)
ich bekam genau in meinem unfreundlichen Ton
Antworten wie braucht keiner
Tja, wie kommt das wohl...?
arbeite an deinem Leseverständnis, ich fragte im Git freundlich aber das vergeht einem bei unfreundlichen Antworten, du schriebst ja selbst das du kein Anfänger bist also warst du nachlässig, betriebsblind oder es ist dir egal wie andere das sehen, such dir was aus.
Deine Antwort liest sich auch wie "jaja" oder "LMAA" keinerlei Einsicht oder Selbstreflektion.
Hast Du bei diesem Projekt jedenfalls schon vor dem Anfangen aufgegeben.
Sonst müsste man da Spuren Deiner Nachfragen sehen können.
ja nach meinen github Erfahrungen, die ja nicht anders sind als heute.
Für mich sieht es halt so aus als wenn der Einsteller alles richtig gemacht haben will und seine Nachlässigkeiten nicht einsehen will.
er hätte ja auch sagen können er bringt den Schaltplan nach weil er dachte es wird nicht gebraucht, aber Einsicht sah ich nicht.
Sich auch noch rechtfertigen müssen dass man seine Arbeit der
Allgemeinheit zur Verfügung stellt?
Dafür nicht, aber wenn das in der Art „hier ist der absolut Weltbeste AVR-ISP-Dongle aller Zeiten“ passiert, dann gibts halt Häme, wenns letztendlich halt doch nur just another USB-Gadget ist.
ja nach meinen github Erfahrungen, die ja nicht anders sind als heute.
Für mich sieht es halt so aus als wenn der Einsteller alles richtig
gemacht haben will und seine Nachlässigkeiten nicht einsehen will.
Aha. Und es sind natürlich alle Menschen, die Dinge auf github veröffentlichen, gleich.
Wieso eigentlich muss ich an Geisterfahrer denken?
Und wieso nimmst Du an, daß ein Mensch, der seine Dinge auf github veröffentlicht, sich hier auf µc.net anders verhält, vor allem, wenn man ihm so überaus "freundlich" ans Bein pinkelt?
Ohne Deine spezifischen Interaktionen mit anderen github-Veröffentlichern gesehen zu haben, der /Verdacht/, daß Deine Erfahrungen unmittelbar und direkt mit der Art der von Dir verwendeten Formulierung Deiner Anliegen zu tun haben könnte, drängt sich mir deutlich auf.
aber wenn das in der Art „hier ist der absolut Weltbeste
AVR-ISP-Dongle aller Zeiten“ passiert
Bitte belege doch diese Behauptung, ich habe lediglich den Geschwindigkeitsvorteil herausgestellt. Als Evidenz kannst Du die Messwerte auf GitHub vergleichen.
Dieses Projekt macht aus einem Arduino Nano Boards mit geringen
Modifikationen den schnellsten In-System-Programmer (ISP) für klassische
AVR-Bausteine wie ATtiny und ATmega.
Hier kommt
mein nanoSTK ins Spiel, klein, robust dank der Verwendung des
nano-ISP-Anschlusses, transportabel und stand-alone, auch auf Reisen.
Außerdem programmiert mein nanoSTK viel schneller als mein STK500.
Ich zähle da deutlich mehr als nur ein positives Adjektiv. Zudem als glücklich machende Alternative ins Spiel gebracht.
09.12.2023 02:08 ---
Joachim B. schrieb im Beitrag #7554882:
kein Bock mehr auf das Suchspiel, LED sind ohne Schaltbild,
Widerstandsverdrahtung unklar!
Echt mal, Joachim, Du machst hier ein großes Fass auf und hängst Dich an dem fehlenden Schaltplan für fünf optionale LEDs auf. Nach Deiner - naja, etwas harschen - Nachfrage habe ich das Projekt auf GitHub aktualisiert und die fehlende Info auch hier nachgeliefert.
09.12.2023 18:10 ---
Martin H. schrieb im Beitrag #7555271:
ich habe es daher noch einmal verdeutlicht.
1
> Heartbeat - Indicates that the programmer is running
2
> D9 (PB1) ----|>|----/\/\---- GND
3
> LED1 R1
4
> Error - An Error has occured - clear with programmer reset
5
> D8 (PB0) ----|>|----/\/\---- GND
6
> LED2 R2
7
> Write - Writing to the target
8
> D7 (PD7) ----|>|----/\/\---- GND
9
> LED3 R3
10
> Read - Reading from the target
11
> D6 (PD6) ----|>|----/\/\---- GND
12
> LED4 R4
13
> PMode - Target in programming mode
14
> D5 (PD5) ----|>|----/\/\---- GND
15
> LED5 R5
16
>
... aber das war offenbar gar nicht Dein Kritikpunkt, denn Du tatest ja weiter Deine Abneigung gegen diese kleine Bastelei kund.
09.12.2023 18:20 ---
Joachim B. schrieb im Beitrag #7555286:
du wolltest nur angeben, sehe es doch ein!
Es ist dein Projekt und ohne vollständige Dokumentation, Schlamperei,
Betriebsblindheit oder Unvermögen musst du wissen!
Auch meine Erklärung, warum der Schaltplan der fünf LEDs fehlte, konnte Dich nicht milde stimmen
10.12.2023 16:29 ---
Martin H. schrieb im Beitrag #7555972:
Ehrlich gesagt hatte ich dem Schaltplan keine große Relevanz
beigemessen, da sich (mir) der Anschluss der - wie angemerkt -
optionalen LEDs problemlos erschlossen hatte
10.12.2023 23:00
Joachim B. schrieb im Beitrag #7556290:
Für mich sieht es halt so aus als wenn der Einsteller alles richtig
gemacht haben will und seine Nachlässigkeiten nicht einsehen will.
er hätte ja auch sagen können er bringt den Schaltplan nach weil er
dachte es wird nicht gebraucht, aber Einsicht sah ich nicht.
Häh?? Genau das hatte ich geschrieben: „hatte ich dem Schaltplan keine große Relevanz beigemessen“
Aber vielleicht kann ich ja Deine Blockade lösen, wenn ich ein paarmal schreibe:
„Ich werde meine Nachlässigkeiten einsehen.“
ich habe lediglich den Geschwindigkeitsvorteil herausgestellt
Dass ein STK500 kein Rennauto ist, ist nicht verwunderlich, der dürfte inzwischen schon 25 Jahre alt sein vom Design. ;-) Interessanter wäre der Geschwindigkeitsvergleich gegen AVRISP2, das war recht schnell und "werkbanktauglich". Allerdings war es auch nicht ganz billig und wird nicht mehr gefertigt.
Ich zähle da deutlich mehr als nur ein positives Adjektiv.
Du kennst den STK500, den ich zum Vergleich heranziehe, dort kommen alle genannten Eigenschaften zum Tragen (kleinere Abmessung [X], robuster [X], transportabler [X], kein Netzteil erforderlich [X], kein USB-Seriell-Wandler erforderlich[X]) sonst hätte ich das Ding ja auch nicht für mich als STK500-Ersatz gebaut - YMMV.
STK500 ...
Allerdings sprechen zwei Dinge dagegen, ihn für die Programmierung
fertiger Targets via ISP zu verwenden: Er benötigt eine externe
Stromversorgung und braucht reichlich Platz auf dem Tisch. Hier kommt
mein nanoSTK ins Spiel, klein, robust dank der Verwendung des
nano-ISP-Anschlusses, transportabel und stand-alone, auch auf Reisen.
Außerdem programmiert mein nanoSTK viel schneller als mein STK500.
Der STK500 hat doch eh nur ein einziges Killerfeature:
Naja, die diversen Fassungen und Buttons und LEDs waren für einfache Experimente schon auch ganz nett. Den integrierten Taktgenerator brauchte man vor allem in der Anfangszeit der AVRs, der ist heute nicht mehr so wichtig.
die
HV-Programmierung zur Rettung vollständig verfuster AVRs. Kann das dein
USB-Nano auch?
Sorry, ich weiß, es gibt keine dummen Fragen. Trotzdem kannst du dir angesichts der einfachen Hardware diese Frage wohl selbst beantworten. Woher sollten denn wohl die 12 V für den Reset kommen?
Er kann auch noch mehr Dinge nicht: Pegelwandlung zum Target. Geht mit so einer simplen Hardware auch nicht.
Sorry, ich weiß, es gibt keine dummen Fragen. Trotzdem kannst du dir
angesichts der einfachen Hardware diese Frage wohl selbst beantworten.
Woher sollten denn wohl die 12 V für den Reset kommen?
Man könnte einen einfachen StepUp Converter bestehend aus PWM-Ausgang, Transistor, Diode und Spule basteln.
Klar, aber die Hardware ist beschrieben, und es ist kein Step-up dabei. Damit erübrigt sich wohl die Frage, ob er HV-Programmierung kann.
HV-Programmierung kann man in den allermeisten Fällen aufgrund der benötigten Anzahl der Leitungen eh nicht in-circuit machen, damit ist ein externes Gerät wie der STK500 selbst (oder seinerzeit der Dragon) prädestiniert dafür.
Man könnte einen einfachen StepUp Converter bestehend aus PWM-Ausgang,
Transistor, Diode und Spule basteln.
Die Spannung ist das geringste Übel, das könnte man halbwegs einfach auch durch einen DC/DC-Wandler-Baustein erschlagen. Unhandlich wird die ganze Sache dann durch die komplett andere Verdrahtung, denn statt seriell per SPI werden die großen 20+ Pinnner parallel (HVPP) programmiert, nur die kleinen 8- und 14-Pinner laufen seriell (HVSP), aber auch mit anderer Kontaktierung.
Das HW-kompatible FW-Projekt ScratchMonkey unterstützt neben ISP auch HVSP und HVPP und zeigt auch diverse Schaltungsvorschläge, allerdings nur als *.fzz Dateien. Dieses Projekt wird leider seit Jahren nicht mehr aktiv gepflegt und es bräuchte eine Auffrischung. Durch die angestrebte Vielseitigkeit ist das Projekt aber so extrem modularisiert, dass es (mir) keine Freude bereitet, dort tiefer einzusteigen.
Und wie gesagt, für den Sonderfall eines „verfusten“ Chips ist mein STK500 das Mittel der Wahl.
Wer professionell mit klassischen AVR-Prozessoren arbeitet, kommt um den
STK500 kaum herum; ich verwende ihn auch als Entwicklungsplatform.
Die Aussage vor dem Semikolon benennt den STK500 und ordnet ihn in den professionellen Kontext ein.
Die Aussage nach dem Semikolon heißt nicht: „Ich verwende ihn daher auch als Entwicklungsplatform.“
Ich hatte den STK500 vor ca. 20 Jahren privat gekauft, weil ich zu dieser Zeit auch dafür bezahlt wurde (da kommt der professionelle Kontext ins Spiel), Code für AVR zu entwickeln und zu testen. Heute werde ich (leider) nur dafür bezahlt Teams und Prozesse zu managen, daher sind die klassischen AVR-Prozessoren für mich Liebhaberei, ich bin sozusagen ein „Dilettant“, soll heißen, jemand, der sich daran erfreut, mit einfachem Materialeinsatz ein Ergebnis zu erzielen, auch wenn es Zeit kostet - das ist sozusagen meine Variante des Bestrebens, den Eiffelturm im Maßstab 1:1000 aus Streichhölzern zu bauen.
Professionell und Arduino.... ist das nicht schon ein Wiederspruch...?
Ein Widerspruch ist es jedenfalls nicht. Wenn Arduino für eine Lösung ausreicht, reicht es aus. Wer Kunden nicht mit Lösungen, sondern mit eindrucksvollem Werkzeugkasten beeindrucken kann, sollte das unbedingt machen. Meine Kunden sind leider nur an den Lösungen interessiert.
Meine Kunden sind leider nur an den Lösungen interessiert.
Was sie in der Regel immer sollten.
Eindrucksvolle Werkzeugkästen beeindrucken den Kunden nur, wenn dadurch das Produkt besser und schneller fertig wird. Insofern beeindruckt auch Arduino!
wenn HV-Programmierung wichtig ist kann das auch ein AVR Dragon.
Ziemlich zur Zeit als AVR den AVRISP MKII abgekündigt hat, gabs den dann für 10€ bei Ali, davor lag er immer so bei 30-40€.
Habt ihr wirklich Geschwindigkeitsprobleme beim flashen? Ich habe meist mit 125k programmiert, so das selbst wenn mit internem Frequenzteiler von 8 (1 MHz) zuverlässig und schnell programmiert werden konnte.
Professionell und Arduino.... ist das nicht schon ein Wiederspruch...?
Nein.
Es ist eine ähnlich dümmliche Formulierung wie "Professionell und Schraubenzieher ... ist das nicht schon ein Widerspruch.... ".
Es kommt auf den Kontext an. Wenn ein Schraubenzieher passend für das Problem ist, sollte man einen verwenden.
Ich sehe bei vielen Programmier-Adaptern neben der Programmierschnittstelle (SPI, UPDI) auch die Möglichkeit der seriellen Kommunikation (wie bei Arduino).
Der m328p im Nano kommuniziert intern über die serielle Schnittstelle mit dem USB-Seriell-Wandler. Daher ist diese Schnittstelle extern nicht verfügbar. Wofür benötigst Du diese Kommunikationsvariante?
nanoSTK.jpg
(310 KB)
