https://github.com/Ho-Ro/nanoSTK_V1 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. Viel Spaß, Martin
Martin H. schrieb: > Hier kommt > mein nanoSTK ins Spiel 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?
Marc X. schrieb: > 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.
Marc X. schrieb: > 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.
Martin H. schrieb: > Viel Spaß, Martin kein Bock mehr auf das Suchspiel, LED sind ohne Schaltbild, Widerstandsverdrahtung unklar!
:
Bearbeitet durch User
Joachim B. schrieb: > LED sind ohne Schaltbild In nanoSTK.cpp steht das hier drin:
1 | // Optional nanoSTK HW changes:
|
2 | // Put an LED (with resistor) on the following pins:
|
3 | // 9: Heartbeat - Indicates that the programmer is running
|
4 | //
|
5 | // the next 4 LEDs are the same as used by ScratchMonkey
|
6 | // 8: Error - An Error has occured - clear with programmer reset
|
7 | // 7: Write - Writing to the target
|
8 | // 6: Read - Reading from the targer
|
9 | // 5: PMode - Target in programming mode
|
Und ein paar Zeilen drunter werden auch richtige Portbezeichner im Kommentar verwendet:
1 | #define HEARTBEAT
|
2 | #ifdef HEARTBEAT
|
3 | // Heartbeat LED
|
4 | const uint8_t LED_HB = 9; // PB1 |
5 | #endif
|
6 | |
7 | // Error LED
|
8 | const uint8_t LED_ERROR = 8; // PB0 |
9 | |
10 | // Writing activity LED
|
11 | const uint8_t LED_WRITE = 7; // PD7 |
12 | |
13 | // Reading activity LED
|
14 | const uint8_t LED_READ = 6; // PD6 |
15 | |
16 | // Programming mode LED
|
17 | const uint8_t LED_PMODE = 5; // PD5 |
Widerstandsverdrahtung? Meinst Du etwa die Vorwiderstände für die LEDs?
Harald K. schrieb: > In nanoSTK.cpp steht das hier drin: Prosa ist kein Schaltbild! 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.
Joachim B. schrieb: > soweit war ich auch schon, ein Widerstannd für alle, oder für jede LED > einen eigenen Oh, das macht mich jetzt ... etwas betroffen. Ich hatte Dich da anders eingeschätzt. Jede LED braucht ihren eigenen Widerstand. Was denn sonst?! Joachim B. schrieb: > 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. Joachim B. schrieb: > Richtige Dokumentation geht anders. Man kann das Anspruchsdenken auch übertreiben.
Joachim B. schrieb: > kein Bock mehr auf das Suchspiel, LED sind ohne Schaltbild, Joachim B. schrieb: > Richtige Dokumentation geht anders. 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 |
6 | D8 (PB0) ----|>|----/\/\---- GND |
7 | LED2 R2 |
8 | |
9 | Write - Writing to the target |
10 | D7 (PD7) ----|>|----/\/\---- GND |
11 | LED3 R3 |
12 | |
13 | Read - Reading from the target |
14 | D6 (PD6) ----|>|----/\/\---- GND |
15 | LED4 R4 |
16 | |
17 | PMode - Target in programming mode |
18 | D5 (PD5) ----|>|----/\/\---- GND |
19 | LED5 R5 |
Martin H. schrieb: > Es tut mir leid glaub ich dir nicht, 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!
:
Bearbeitet durch User
Ob S. schrieb: > 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.
Joachim B. schrieb: > 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!"
Joachim B. schrieb: > 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.
Hmmm schrieb: > Zum Glück bist Du kein Lehrer geworden. sehe ich auch so Hmmm schrieb: > Die Schwächen in der Dokumentation > bekommt er nach sachlichen (!) Hinweisen bestimmt behoben. nun ja wenn ich auch meckerig rüber kam, er kann ja noch fehlende Doku einpflegen!
:
Bearbeitet durch User
Wastl schrieb: > Irgendwo in den > Sourcen steht's drin ... wer sich's aufmerksam durchschaut. Steht direkt auf der Projektseite, ganz weit oben: https://github.com/Ho-Ro/nanoSTK_V1#required-hw-changes
Hmmm schrieb: > 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.
Martin H. schrieb: > 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.
Martin H. schrieb: > 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 wollt ich nur mal gesagt haben.
Hmmm schrieb: > 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.
J. T. schrieb: > Mir war mal so, als wäre genau so etwas Teil des Forumsgedankens. Mir auch, ich weiß aber auch, warum ich mich schon lange lieber bei GitHub rumtreibe. :)
Hmmm schrieb: > Unterstützen die Microchip-Tools eigentlich noch das STK500v1-Protokoll? Weiß ich nicht, wie gesagt - "avr-gcc", "make" und "avrdude" sind genug für mich. Manchmal auch "arduino", denn wie heißt es so schön: In most projects, the first system built is barely usable....Hence plan to throw one away; you will, anyhow. Fred Brooks, The Mythical Man-Month
Joachim B. schrieb: > 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.
Jörg W. schrieb: > 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. Jörg W. schrieb: > 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
:
Bearbeitet durch User
Martin H. schrieb: > 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.
:
Bearbeitet durch User
Joachim B. schrieb: > 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). Das ist dieses Ding hier https://github.com/microtherion/ScratchMonkey Übrigens ist die Github-Seite mittlerweile aktualisiert worden, da sind die LEDs jetzt beschrieben.
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)".
:
Bearbeitet durch User
Christoph M. schrieb: > 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.
Joachim B. schrieb: > 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.
Martin H. schrieb: > 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, Dazu hätte er sich bei Github anmelden müssen. Hältst Du es für wahrscheinlich, daß er einen github-Account hat?
Martin H. schrieb: > Hättest Du - so wie es auf GH üblich ist - ein Issue erstellt oder z.B. > auch in Q'n'A der Diskussionen angemerkt habe ich aufgegeben, ich bekam genau in meinem unfreundlichen Ton Antworten wie braucht keiner, mache ich nicht, nimm und friss. also sieht auch Github oft nach Selbstdarstellung aus und nicht nach Gemeinsinn. Martin H. schrieb: > Ehrlich gesagt hatte ich dem Schaltplan keine große Relevanz > beigemessen sieht also nach Betriebsblindheit aus, ja das kann passieren. Christoph M. schrieb: > Ich würde aus Faulheitsgründen nur ein Widerstand für die LED verwenden. dachte ich auch beim Suchen, aber dann nahmen die Fragezeichen überhand.
:
Bearbeitet durch User
Christoph M. schrieb: > 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. :)
Joachim B. schrieb: > ich bekam genau in meinem unfreundlichen Ton > Antworten wie braucht keiner Tja, wie kommt das wohl...?
Martin H. schrieb: > Joachim B. schrieb: >> 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.
:
Bearbeitet durch User
Joachim B. schrieb: > habe ich aufgegeben, ich bekam genau in meinem unfreundlichen Ton > Antworten wie braucht keiner, mache ich nicht, nimm und friss. Hast Du bei diesem Projekt jedenfalls schon vor dem Anfangen aufgegeben. Sonst müsste man da Spuren Deiner Nachfragen sehen können. Redest Du also vom Pferd, also irgendwelchen gefühlten Erfahrungen, die Du irgendwann mal vielleicht irgendwo gemacht hast oder haben willst?
Harald K. schrieb: > 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.
Wastl schrieb: > 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. Oliver
Joachim B. schrieb: > 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.
Oliver S. schrieb: > 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. Martin H. schrieb: > 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. Oliver S. schrieb: > dann gibts halt Häme, wenns > letztendlich halt doch nur just another USB-Gadget ist. Dann ist doch für jeden was dabei, wenn es Dir Befriedigung bringt.
Martin H. schrieb: > Oliver S. schrieb: >> 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. Martin H. schrieb: > 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. Oliver
09.12.2023 02:08 --- Joachim B. schrieb: > 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: > 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: > 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: > 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: > 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.“
Martin H. schrieb: > 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 mag immer noch den USBprog (mk2 clone) aus dem µC.net Beitrag "Re: Woher bekommt man ein leeres "USB Stick Gehäuse" ?" https://www.mikrocontroller.net/attachment/260765/usbprog.jpg
:
Bearbeitet durch User
Oliver S. schrieb: > 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. Martin H. schrieb: > 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: die HV-Programmierung zur Rettung vollständig verfuster AVRs. Kann das dein USB-Nano auch? Oliver
Oliver S. schrieb: > 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.
Oliver S. schrieb: > die HV-Programmierung zur Rettung vollständig verfuster AVRs. Kann das > dein USB-Nano auch? Was glaubst Du, wie die Antwort auf diese rethorische Frage wohl lautet? Ich beantworte sie trotzdem: Nein, natürlich nicht - aber dafür habe ich ja den STK500.
>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.
Christoph M. schrieb: > Man könnte 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.
Christoph M. schrieb: > 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. https://github.com/microtherion/ScratchMonkey
Martin H. schrieb: > https://github.com/Ho-Ro/nanoSTK_V1 > Wer professionell mit klassischen AVR-Prozessoren Professionell und Arduino.... ist das nicht schon ein Wiederspruch...?
Thomas H. schrieb: > Professionell und Arduino.... ist das nicht schon ein Wiederspruch...? Wiederspruch.... ist das nicht schon ein Widerspruch...? SCNR :-)
Thomas H. schrieb: >> Wer professionell mit klassischen AVR-Prozessoren > > Professionell und Arduino.... ist das nicht schon ein Wiederspruch...? Vielleicht hättest Du mich im ganzen Satz zitieren sollen: Martin H. schrieb: > 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.
Thomas H. schrieb: > 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. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > 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.
von Thomas H. (Firma: CIA) (apostel13) >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. https://shop.trenz-electronic.de/de/TE0723-03-41C64-A-ArduZynq-Arduino-kompatibles-AMD-Zynq-7010-SoC-Modul
Funktioniert die Serielle Kommunikation ohne TX RX?
Georg M. schrieb: > Funktioniert die Serielle Kommunikation ohne TX RX? Welche meinst Du? UART oder SPI, ersteres nutzt die (internen) RX/TX-Signale, letzteres nicht.
Ich sehe bei vielen Programmier-Adaptern neben der Programmierschnittstelle (SPI, UPDI) auch die Möglichkeit der seriellen Kommunikation (wie bei Arduino). https://www.arduino.cc/reference/en/language/functions/communication/serial/
Georg M. schrieb: > bei vielen Programmier-Adaptern 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?
Bitte 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.