ich brauche mal etwas mehr Hilfe...
Wie der Titel andeutet, denke und lese ich darüber nach, ob und wie mein Mini über meinen "Großen" programmiert werden kann,
ersterer bekanntlich ohne USB-"Infrastruktur", letzterer als Duemilanove komplett.
Entsprechend dieser Anleitung http://arduino.cc/en/Tutorial/ArduinoISP (Using an Arduino as an AVR ISP (In-System Programmer), wo aber NUR das Programmieren des Bootloaders beschrieben wird.
Was ich erfolgreich durchgeführt habe, ist der Anschluß des Mini an die Platine des 2009er OHNE dessen Atmega328, also nur die Verwendung der USB-Infrastruktur.
Aber ich möchte nicht, wenn es vermeidbar ist, jedesmal den Atmega328 heraushebeln...
Und während ich auf meine bestellten USB2TTL-Adapter warte, mit denen dann das Thema durch wäre, würde ich schon ganz gerne den Mini "befüllen"...
Die gedankliche Hürde ist, dass ich einerseits ein Sketch in den 2009er schaffe, dass diesen zum Programmer macht, und andererseits das eigentliche Sketch für den Mini bearbeiten, kompilieren und flashen...
Obwohl der Titel des obigen Links - Using an Arduino as an AVR ISP - das suggeriert, sehe ich nicht, wie.... außer dass der Bootblock, der in der IDE eh nicht (von mir) bearbeitet wird, in das Ziel geschafft wird...
Und während ich auf meine bestellten USB2TTL-Adapter warte, ...
Wieso verwendest du in der Zwischenzeit nicht einfach den Duemilanove für die Realisierung deiner Anwendung?
Wenn dann dein FTDI-Adapter kommt, kannst du den Mini anschliessen und den bereits getesteten Sketch hochladen.
Stimmt!
Ist wie so vieles im Hobby... der Weg ist das Ziel... die Aufgabe, eine Lösung zu finden.
BTW: habe mich gerade etwas durchgewühlt... das gleiche Ziel ist schon des öfteren angegangen worden...
EINE Lösung ist die "ArduinoISP-Firmware" auf dem 2009er, dann den legendären AVRDude mit/ohne GUI als aktiven Programmer...
muß noch etliches lesen...
Müßte funktionieren wenn Du das Reset-Pin des 2009 permanent auf Masse schaltest. Das müßte den Controller "abgeschalten". Dann kannst Du den Mini programmieren, brauchst aber einen manuellen Reset am Mini um die Übertragung zu starten.
(wird so in der Beschreibung zur Programmierung des XBee gemacht).
Grüße Uwe
nachdem ich mich gestern bereits darüber ausgelassen hatte, wie ich mit meinem vorhandenen "2009" meinen kleinen "Mini" programmieren könnte, weil der bestellte USB2TTL-Wandler noch nicht da ist, mit dem dann alles ganz einfach wird...
habe ich heute tatsächlich den erwarteten Wandler erhalten.
Aaaaber...
es klappt nicht!
Im Detail:
es ist eine kleine Platine mit USB-Buchse, einem CP2102, einer LED und einer 6fach Stiftleiste.
Auf der Stiftleiste liegen +3,3V, Reset, TxD, RxD, GND und +5V.
Ich habe lediglich TxD, RxD, Reset und GND am Mini aufgelegt: (alle Angaben gemäß Schema Mini Ver.04)
TxD an TX (Pin1)
RxD an RX (Pin2)
Reset an RESET (Pin3) (und auch versuchsweise gegenüber an Pin22 zwischen Ground und +5V)
GND an Ground (Pin4)
Feststellungen:
beim Anschluß des USB-Steckers an die Buchse leuchtet die kleine onboard-LED,
die Arduino-IDE "sieht" und bietet den korrekten Anschluss (dev/tty/USB0) an,
jeder Transfer endet mit der Fehlermeldung: (stk500_recv() ... programmer is not responding..)
Wenn ich in der kurzen Zeitspanne zwischen Kompilieren und Transfer den Reset-Pin kurz auf Low ziehe, dafür habe ich eine kleinen Taster auf dem Steckbrett, passiert .... nichts!
Es erscheint keine Fehlermeldung und es geht weder weiter noch endet die Geschichte ...
Auf dem Mini läuft ein kleines "Hallo Welt" Programm, dass ich auf die früher beschriebene Art und Weise transferiert habe ( "2009"er Board ohne AtmelMega328, Tx und Rx-Verbindung und eine Resetleitung), ein 16x4 Display ist angeschlossen,
diese Anwendung läuft während der Programmierversuche ungerührt weiter und wird nur durch meine Resets auf Null gesetzt.
bei Watterott (meiner ist auf direktem Wege aus HK zu mir gelangt...) wird neben dem wohlbekannten FTDI-Chip ebenfalls ein USB2TTL-Wandler auf CP210x Basis angeboten, dort wird von Treibern gesprochen, für Windows, Mac und auch Linux ...
nach meinen Recherchen WAR es für Kernel 2.4.x und < 2.6.12 ein Problem, den Chip CP2102 in Betrieb zu nehmen, nach den 2.6.12er Kernel ist der CP 2102 Support gleich mit an Bord und mein Ubuntu 10.10 ist bei 2.6.35 oder so angelangt...
und eigentlich hat die Arduino-IDE ja offensichtlich auch keine Probleme, die USB-Schnittstelle als solche zu erkennen.
also, der Chip, das Modul, der Baustein wird als USB-Schnittstelle erkannt...
unter Linux...
irgendwo hatte ich im Zusammenhang allgemein mit Programmierteilen gelesen, dass ein DTR-Signal in Richtung Atmel notwendig sei, als Reset(?), dass bei der einen oder anderen Bastellösung nicht gegeben war...
Eine andere Frage beschäftigt mich in dem Zusammenhang:
wie kann ich die Schnittstelle möglichst einfach testen?
Wie / wo wird ggf. die Übertragungsrate eingestellt?
In einem älteren Beitrag zum CP2102 war erwähnt, dass dieser im Gegensatz zum FTDI nur eingeschränkte Datenraten kann...
irgendwas mit 11500er Bereich...
den Mini über TX, RX und Resetleitung an das Duemilanove-Board ohne Atmel (also nur an das USB-Interface) angeschlossen, lässt er sich über die Arduino-IDE programmieren,
den Mini über TX, RX an das USB-to-TTL Interface angeschlossen, Resetschalter auf einen Taster gelegt, lässt er sich nicht programmieren, weder mit TX-TX noch mit TX-RX Verbindung, weder mit Reset beim Start des Übertragens, noch mit Reset in der kurzen Zeitspanne zwischen Kompilierung und Transferbeginn.
(die früher erwähnte RST-Leitung am Interface setzt übrigens das komplette USB-Interface zurück).
Wenn mir nicht irgendwann die Erleuchtung kommt, sind die 3,60€ für das USB2TTL Interface für den Kamin...
Schön wäre ein Schaltplan vom FTDI-Breakout, um mal nach wesentlichen Unterschieden zu forschen, obwohl ich selbst an meiner Aufstellung oben den einzigen Schluß ziehen kann, dass der Zeitpunkt des Resets wohl der Schlüssel ist.
Wenn Du ein Duemilanove-Board ohne Atmel verwendest dann mußt Du TX mit TX und RX mit RX verbinden.
Wenn Du ein USB2TTL Interface verwendest ( mit zb einem FT232 oder CP2102) dan TX mit RX und RX mit TX.
Der Resetzeitpunkt ist nicht sooo kritisch. Du hast einige Sekunden.
kurze Zusammenfassung, weil mein Thema schon 1 Woche zurückliegt:
neben meinem Duemilanove-Board experimentiere ich noch mit einem Mini - der dann später die Arbeit machen soll.
In der Zwischenzeit ist mein USB2TTL-Platinchen aus Fernost eingetroffen, der die USB-Infrastruktur für den Mini während des Programmierens stellen soll,
(kein FTDI sondern ein Aufbau rund um den CP2102).
Die Verbindung zwischen dem USB2TTL und dem Mini besteht in den Leitungen TX-RX, RX-TX, GND-Ground und desweiteren ein Resettaster gegen Masse an RESET des Mini.
Der Mini wird wahlweise autark über das Steckboard oder per USB via USB2TTL versorgt.
Problem bis gerade eben war, dass beim Übertrag des Programms in den Mini die IDE den Fehler meldet (sinngemäß): "Programmer antwortet nicht"
Bei ungezählten Versuchen gelang mir nur 1x (in Worten: einmal) der erfolgreiche Transfer von der IDE in den Mini.
Das Geheimnis liegt, nicht überraschend, im Timing der Resetleitung.
Aber es war völlig egal, wann ich den Resetschalter drückte, bzw. freigab, ob kurz oder lang, vor dem Start des Transfers oder wenn die Meldung über die fertige Kompilierung mit Anzahl Bytes erschien... "programmer is not responding"
Entsprechend der Seite http://www.arduino.cc/en/Guide/ArduinoMini habe ich heute angeschlossen (erstes Foto), aber die Resetleitung nicht dauerhaft an Plus gelegt, sondern mit Steckbrett-Kabel an Masse, also Reset dauerhaft ausgelöst - intern hat der Reset-Pin einen Widerstand "Pullup" an Plus - BIS die Meldung "Binary sketch size: 1020 bytes (of a 14xxx bytes maximum) angezeigt wird.
In diesem Moment zog ich die Resetleitung aus dem Massekontakt - Sekunden später: voila: Upload erfolgreich!
Zur Sicherheit 5x diese Prozedur mit zwei verschieden langen Sketchs durchgeführt - 5x erfolgreich ! 100% Quote
Hallo ManfredH
Du kannst Verify (kontrollieren- kompilieren) und Upload (übertragen) auch als getrennte Aktionen durchführen.Schau Dir mal die Ikons im IDE oben besser an und fahre mit der Maus darüber. Dann mußt Du nicht darauf warten daß das Kompilieren fertig ist.
Ich würde schon einen esternen Pullup Widerstand am Resetpin vorsehen (10kOhm).
Ein Taster müßte die gleichen Dieste leisten wie ein abgezogener Kabel.
Grüße Uwe
das mit dem Reset beim mini hab ich auch schon festgestellt & bin zum selben Ergebnis gekommen, sogar mit den gleichen Mitteln. Erst den Reset Taster wieder frei geben wenn die Meldung im Fenster erscheint. Alles andere ist zu früh.
Ich hab es heute übrigens nicht geschafft den Duemilanove als ISP Programmer für den mini zu nutzen, sondern musste es mit einem mySmartAVR machen...
das freut mich ja, dass Du auf gleiche Art und Weise erfolgreich warst/bist.
auf welche Art und Weise hast du den Duemilanove (als ISP-Brenner) mit dem Mini verbunden?
so wie hier?
Damit war ich ganz am Anfang auch gescheitert und habe es nicht weiter verfolgt.
Inzwischen bin ich beim "Studium" des Schaltbilds zum Mini, Vers.04, über einen Anschluß gestolpert...
es ist eine Verbindung von PD7(AIN1) am Chip zum Anschluß CON5 J7 Kontakt 1.
Im Schaltbild benannt als "BT_reset" und CON5 ist meiner Meinung nach der ISP-Anschluß und liegt an der Schmalseite des Minis.
Der gleiche Anschluß liegt auch als "10" an J1 und ich vermute ihn als "Boot Reset" im Zusammenhang mit dem ISP-Protokoll.
@Uwe,
jetzt hast Du mich aber etwas verunsichert...
in meiner IDE (hier die 0021, auf meinem alten Laptop 0022) finde ich von links nach rechts die Icons für:
Verify, Stop (runde Button), New, Open, Save, Upload, Serial Monitor
verify prüft und kompiliert,
upload prüft(?), kompiliert und überträgt
der PD7 ist meines Erachtens zum reseten eines angeschlossenen Bluetooth Moduls. Ich hab mich an dieses Tutorial gehalten.
verify prüft und kompiliert,
upload prüft(?), kompiliert und überträgt
So ist es. Ich vermute Uwe wollte damit sagen, dass Du dann nicht so lang auf die Meldung warten musst. Denn das kompilieren kann ja bei größeren Projekten schonmal dauern...
Wenn Du zuvor kompiliert hast, lädt "upload" nur hoch ohne zu kompilieren.
Wie Stundenblume sagt, brauchst Du dann nicht auf das Ende des Kompilierens zu warten.
Danke Uwe,
ich habe bereits beide Schemata... und mein China-Nachbau ist einer der Version 04... nachdem ich mühsam mit Lupe und Bleistift mein eigenes Schema zusammen hatte...
Wenn Du zuvor kompiliert hast, lädt "upload" nur hoch ohne zu kompilieren.
Wie Stundenblume sagt, brauchst Du dann nicht auf das Ende des Kompilierens zu warten.
Das ist es ja:
bei MIR läuft nach dem Klicken des UPLOAD-Button noch einmal die Kompilierung - genauso lang, wie bei Verify - mit der gleichen Meldung über die Größe an Bytes, und dann folgt ohne weitere Aktion der Upload mit einer Statusmeldung am Schluß.
Deshalb hatte ich euren Einwand - oder Hinweis - nicht recht verstanden.
