Arduino Uno lässt sich nicht mehr mit Bascom programmieren

[herrgerd]

Hallo Ag,

Danke für den Tipp, hat aber leider nicht geholfen.
Was ich nicht so ganz verstehe ist, dass hier für den Programmer eine Baudrate von 115200 am COM Anschluss im Gerätemanager eingestellt werden soll,
die Kommunikation für den Serial Monitor aber über 9600 läuft? Geht doch über den gleichen Anschluss, oder laufen die Pfade hier anders?
Anders herum kann ich für den Arduino ja auch mit 115200 am COM arbeiten?

Gruss, Gerd

[ag]

Hallo Gerd,

bei eine serielle Schnittstelle müssen die gegenüberstehende Ansprechpartner sich auf eine Übertragungsprotokoll einigen. Deshalb "müssen" die COM Einstellungen mit dem angeschlossenen Gerät übereinstimmen. Aber je nach Betriebsystem, Treiber, Anwendung, Kabel, Gerät, usw., können diese Einstellungsarbeiten automatisch ablaufen. Wenn man eine Anleitung schreibt, die allgemeingültig sein sollte (unabhängig von Betriebsystem usw.) ist es nicht verkehrt, explizite Vorgaben zur COM Einstellungen zu machen. Ich verwende momentan ein Toschiba Laptop mit Win7 64Bit und USB-2 Schnittstelle für meine BASCOM-AVR Verbindung mit dem Arduino. In BASCOM-AVR ist 57600 Baud eingestellt, und wenn ich mit dem USB Kabel ein Arduino anschließe, erscheint im Windows Gerätemanager ein neues USB Serial Port (COM8) mit 19200 Baud eingestellt. Ohne dieses zu ändern, funktioniert trotzdem die Übertragung, sowohl mit BASCOM-AVR als auch mit dem Arduino ISP. Wenn aber Probleme auftreten, solltest man aber doch versuchen die Probleme zu umgehen, indem alle Einstellungen explizit auf einander abgestimmt werden.

Die USB Anschluss vom Arduino wird auf die Platine zu eine serielle Schnittstelle umgesetzt und zu pins TX und RX geführt. Nach meine Erfahrung, bleibt diese Schittstelle durch BASCOM-AVR belegt, damit eine Datenübertragung von Arduino zurück zum BASCOM-AVR interne "Terminal emulator" stattfinden kann. Dieser Schnittstelle spricht du im Programm an mit "Baud = 9600" und "Print ...", und hier muss nach meine Erfahrung die COM Einstellungen im BASCOM-AVR Kommunications Option tatsächlich übereinstimmen mit dem im Programm definierten Baudrate, sonst klappt es mit der Kommunikation nicht. Mit dem Arduino ISP gibt es analog dazu der "Serielle Monitor".

Man kann aber auch im Programm weitere serielle Schnittstellen definieren die per Software auf andere Pins geführt werden (siehe BASCOM-AVR Kommando "OPEN"). Hier gelten die gleiche Regeln wie bei der standard "Hardware" Schnittstelle.

Es ist denkbar, dass die gerade im Arduino befindliche Programm die TX und/oder RX Leitungen belegt, was die Übertragung eines neues Programm via BASCOM-AVR verhindern könnte, obwohl es mit der Arduino ISP klappt. Denn, ich glaube dass der Arduino ISP eine ggf. vorhandene Programm löscht, oder zumindest mit interne Reset deaktiviert, bevor es mit der Upload ein neues Programm beginnt. Beim BASCOM-AVR bin ich mir nicht sicher. Da findet auch eine Reset statt, ober ob alle Register wirklich dadurch freigemacht werden weiß ich nicht. Du könntest versuchen, mit Arduino ISP ein simples Sketch zu Uploaden, die keine serielle Schnittstelle benutzt, und dann mit BASCOM-AVR das gleiche versuchst (Programm ohne serielle Schnittstelle Verwendung). Wenn das Problem dann nur bei ein bestimmtes Programm auftaucht, enthält das Programm vermutlich ein Fehler. Wenn das aber nicht der Fall ist (Problem besteht weiterhin auch mit Programme ohne Verwendung der serielle Schnittstelle), dann würde ich vorschlagen, alle COM Einstellungen explizit im Gerätemanager und im BASCOM-AVR auf eine langsame Baudrate, z.B. 19200, einzustellen. Wenn auch das nichts nutzt, würde ich mal nach Hardware oder Treiber Fehler in Windows Ereignisanzeige zu suchen. Falls das nichts bringt, dann würde ich BASCOM-AVR einfach neu installieren und es danach wieder versuchen.

Viele Grüße,
Ag

[burkhard]

Inzwischen konnte ich den Fehler nachvollziehen: Immer wenn eine Print-Ausgabe im Programm enthalten ist klemmt der Arduino-Programmer in Bascom. Es handelt sich wohl um ein Problem in der Bascom-IDE. (Das hatte ich leider bisher übersehen, weil ich lieber mit dem MCS-Bootloader arbeite, wo es dieses Problem nicht gibt.) Nach einigem Rumprobieren kam folgende Lösung heraus:

1. Die Timeout-Einstellung wird auf 3000 hochgesetzt.
2. Beim Upload wird dreimal (!!) kurz die Reset-Taste des Uno gedrückt. Vor dem ersten Reset stehen im Chip-Fenster erstmal drei Fragezeichen ???. Nach dem ersten Reset erhält man hier den Eintrag ATmega328P. Der Programmer liest also erstmal diese Info. Nach dem zweiten Reset geht es immer noch nicht weiter. Vielleicht wird da noch etwas anderes gelesen oder aber der Speicher wird gelöscht. Aber nach dem dritten Reset geht es dann wie gewohnt weiter.

Das war's. Dreimal Reset löst das Problem. Oder der MCS-Bootloader, den man allerdings mit einem externen Brenner reinladen muss.

Die ganze Sache mit Sreenshots zur Verdeutlichung steht hier:
http://www.elektronik-labor.de/AVR/ElektorBas.html#boot2

[herrgerd]

Hallo Burkhard,

ich hatte zwischenzeitlich auch festgestellt, dass das Problem nur dann auftritt, wenn während des flashens aktuell gerade Daten vom Uno zum Rechner laufen.
Deshalb hatte ich mal ein Poti an den Messeingang angeschlossen und das Programm so geschrieben, dass nur bei Erreichen eines Schwellwertes eine Ausgabe im Terminal Emulator erscheinen soll.
Es ist dann auch nur in dem Fall die TX LED auf dem Board an und genau dann tritt der Fehler reproduzierbar auf.


Ich glaube man kann ein Programm auf dem Uno nicht "löschen" sondern nur überschreiben-wäre vielleicht auch ein Workaround gewesen, also die Kommunikation seitens des Unos vorher abzubrechen bevor man dann ein neues Programm laden will.

Dein Workaround mit der Resettaste funktioniert einwandfrei.

Vielen Dank für den Tipp, auch an Dich Ag, Danke für die Hinweise!

Gruss, Gerd

[burkhard]

Hallo Gerd,
grad noch mal getestet: Wenn ich mit der Arduino-IDE ein Programm lade, das printf verwendet tritt in Bascom das gleiche Problem auf. Wie zu erwarten.
Dann ein Oszi an die Reset-Leitung und beide Systeme verglichen. Arduino sendet dreimal Reset (mit DTR klappern), Bascom auch, aber langsamer. Es dürfte ein Timing-Problem sein. Der Mega328 hat dann genug Zeit um sein altes Programm wieder zu starten. Deshalb muss man offensichtlich mit der Reset-Taste nachhelfen.
Ich könnte mur auch vorstellen, dass das eigentliche Problem im USB-Chip auf dem Uno steckt, der irgendwie klemmt, wenn noch Daten unterwegs waren. Die Arduino-Leute haben dann einen Trick gefunden wie man ihn zurücksetzt oder sowas.

[burkhard]

Nachtrag 2 von Jürgen Conrad: Froher Hoffnung habe ich sofort die Änderung auf Timeout 3000 vorgenommen. Auch den Link genau studiert. Die Programmierung von UNO_Print.BAS mit Waitms 200 geht problemlos. Ausgabe auf Terminalfenster ok. Während des Laufes von UNO_Print.BAS mit 200 ms kann das Programm LEDblink.bas wieder nicht geflasht werden. Bascom hängt sich auf (mit: Keine Rückmeldung), wird mit Arduino wieder „entsperrt“. Erhöhe ich Waitms jedoch auf 300 ms funktioniert alles wieder. Timeout 3000, $crystal = 16000000, $baud = 9600, sofern sich das Programm Bascom nicht aufhängt, stets kontrolliert. Ich habe BASCOM-AVR IDE free (2.0.7.5), neu installiert. USB-Teiber für Arduino (Ver. 1.5.6-r2) neu eingespielt.

Bestätigung von B. Kainka: Auch das konnte ich nachvollziehen. Mit einer Pause von 300 ms kommt man ohne die Reset-Taste aus. Wenn das Programm aber schneller sendet muss man wie beschrieben dreimal Reset-drücken.

Ist das bei allen so? Kann jemand das Reset-Verfahren bestätigen?

[jeanpierre]

Hello,
I have the pleasure to give you an important information :
A new forum for ARDUNO are living since yesterday under Bascom forum : http://www.mcselec.com/index2.php?option=com_forum&Itemid=59

All Bascom and Arduino users are ready to help you and.... we need your Help too !

Jean-Pierre