Alternative zu Flashnnn.exe

[hai1991]

hallo osser


ich habe jetzt heraus gefunden, wo mein problem lag

in der schule verwenden wir auch die serielle schnittstelle. und auch dieses programm hat zuerst meine virtuelle nicht gefunden. dann hat mir der lehrer geraten, dass ich den com-port umstellen soll.
gesagt-getan. ich änderte ihn von COM15 auf COM2 und seit dem funktioniert alles einwandfrei.

danke für deine unterstützung

[ukuchel]

Hallo Osser,
Ich habe die Leerzeichen wegelassen, und ... es funktioniert
Wenn Du die Nutzung von Leerzeichen ermöglichen könntest, wäre das sicherlich (zumindest für mich) eine große Hilfe.
Bleibt noch das Problem mit Deinem Flash-Tool. Da bin ich noch am experimentieren, leider bislang ohne Erfolg.
Gruß Ulli

[ukuchel]

Hallo Osser,
ich habe eine neues (und altes) Problem.
Weiter oben in Thread wurde schon einmal die Fehlermeldung ExitCode 259 angesprochen.
Diese Fehlermeldung habe ich gelegentlich ebenfalls beim Compilieren erhalten. Meine Lösung bestand bislang darin, den Compiliervorgang ein zweites Mal durchzuführen, meist mit Erfolg.
Jetzt häufen sich diese Meldungen und ich habe das mal ein wenig näher unter die Lupe genommen.
AF meldet:
Remote process time out elapsed!
ExitCode 259
... und beendet scheinbar den Compiliervorgang.
Im Hintergrung arbeitet der Compiler aber fleißig weiter und erzeugt eine korrekte .hex-Datei. Diese lässt sich dann auch flashen. In einem Dateimanager kann man den laufenden Compiliervorgang beobachten obwohl AF schon längst eine Fehlermeldung ausgegeben hat.

Der ExitCode 259 steht für "No more data availible".
Meine Vermutung:
AF wartet auf Daten vom Compiler und verliert ziemlich schnell die Geduld, weil irgendeine TimeOut-Variable im Programm zu knapp bemessen ist.
Kann das sein???
Analoges passiert beim Löschen überflüssiger Dateien.

Gruß Ulli

P.S.
Hier ist noch einmal die vollständige Fehlermeldung:

Asuro Flash (Alias Eierlegendewollmilchsau)	 V1.7.10.99 (c) O.O. Müller 2009
User has admin rights.
Processor branding         Intel(R) Pentium(R) M processor 1300MHz,  OS WINXP
Hello Administrator on 2723-2FG, have fun :)

Selected flash driver is RS232 Programmer
>Session Environment Variables:
AF_AVRDIR=%AF_PRGDIR%\Compiler
AF_PROJECT=Project1
AF_SOURCE_FILES=
AF_ASM_SRC_FILES=
AF_PRGDIR=F:\Programme\Asuro\WinAVR
AF_PRJDIR=F:\Programme\Asuro\WinAVR
>Ready.
>Session Environment Variables:
AF_AVRDIR=F:\Programme\Asuro\WinAVR\Compiler
AF_PROJECT=Project1
AF_SOURCE_FILES=new.c wfl.c
AF_ASM_SRC_FILES=
AF_PRGDIR=F:\Programme\Asuro\WinAVR
AF_PRJDIR=C:\test
File new.c saved.
File wfl.c saved.
File wfl.h saved.
>Default make_all.cmd file created.
>Default makefile created.
Make
set -e; avr-gcc -MM -mmcu=attiny2313 -I. -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-ahlms=wfl.lst -IF:\Programme\Asuro\WinAVR\include wfl.c \
	| sed 's,\(.*\)\.o[ :]*,\1.o \1.d : ,g' > wfl.d; \
	[ -s wfl.d ] || rm -f wfl.d
set -e; avr-gcc -MM -mmcu=attiny2313 -I. -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-ahlms=new.lst -IF:\Programme\Asuro\WinAVR\include new.c \
	| sed 's,\(.*\)\.o[ :]*,\1.o \1.d : ,g' > new.d; \
	[ -s new.d ] || rm -f new.d
-------- begin --------
avr-gcc --version
avr-gcc (WinAVR 20081205) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
Project1.elf  :
section           size   addr
.text              424      0
.debug_aranges      64      0
.debug_pubnames    158      0
.debug_info       1157      0
.debug_abbrev      403      0
.debug_line        859      0
.debug_frame       224      0
.debug_str         237      0
.debug_loc         192      0
Total             3718


avr-gcc -c -mmcu=attiny2313 -I. -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-ahlms=new.lst -IF:\Programme\Asuro\WinAVR\include new.c -o new.o

Remote process time out elapsed!

C:\test>F:\Programme\Asuro\WinAVR\Compiler\utils\bin\make.exe all 

ExitCode 259
>Ready.
Starting extern flasher
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e910a
avrdude.exe: erasing chip
avrdude.exe: reading input file "F:\Eigene Dateien\Eigene Programme\C++\Würfel\Würfel 1\Project1.hex"
avrdude.exe: input file F:\Eigene Dateien\Eigene Programme\C++\Würfel\Würfel 1\Project1.hex auto detected as Intel Hex
avrdude.exe: writing flash (424 bytes):

Writing | ################################################## | 100% 1.03s

avrdude.exe: 424 bytes of flash written
avrdude.exe: verifying flash memory against F:\Eigene Dateien\Eigene Programme\C++\Würfel\Würfel 1\Project1.hex:
avrdude.exe: load data flash data from input file F:\Eigene Dateien\Eigene Programme\C++\Würfel\Würfel 1\Project1.hex:
avrdude.exe: input file F:\Eigene Dateien\Eigene Programme\C++\Würfel\Würfel 1\Project1.hex auto detected as Intel Hex
avrdude.exe: input file F:\Eigene Dateien\Eigene Programme\C++\Würfel\Würfel 1\Project1.hex contains 424 bytes
avrdude.exe: readin

	
	
g on-chip flash data:

Reading | ################################################## | 100% 0.98s

avrdude.exe: verifying ...
avrdude.exe: 424 bytes of flash verified

avrdude.exe done.  Thank you.
ExitCode 0

[Osser]

Hi ukuchel,

bzgl. deines letzten Posts: Bitte poste CpuSignatures.xml
Dann kann ich mal schaun ob die Datei i.O. ist.

bzgl. AF: Die Software benutzt einen Timeout von ca. 20sec, was eigentlich immer ausreichend sein sollte. Vielleicht ist da auch was anderes falsch gelaufen was zum Abbruch des Tasks führt.
Wie lange dauert denn der Kompiliervorgang ca.?


Gruss,

O.

[ukuchel]

Hallo Osser,
hier der Ausschnitt der CpuSignatures.xml

<Signature>
	  <CpuName>ATtiny2313</CpuName>
	  <CpuType>actATtiny2313</CpuType>
	  <Sig byte1="0x1E" byte2="0x91" byte3="0x0A" byte4="0x00"></Sig>
	  <FlashOpt EraseBeforeFlash="1"></FlashOpt>
	  <MemSize Flash="0x0800" EEPROM="128"></MemSize>
	  <PageSize Flash="32" EEPROM="4"></PageSize>
	  <PageNo Flash="64" EEPROM="32"></PageNo>
	  <LocksLow>
		<Lock Bit="7" Default="1" Name="NDEF"></Lock>
		<Lock Bit="6" Default="1" Name="NDEF"></Lock>
		<Lock Bit="5" Default="1" Name="NDEF"></Lock>
		<Lock Bit="4" Default="1" Name="NDEF"></Lock>
		<Lock Bit="3" Default="1" Name="NDEF"></Lock>
		<Lock Bit="2" Default="1" Name="NDEF"></Lock>
		<Lock Bit="1" Default="1" Name="LB2"></Lock>
		<Lock Bit="0" Default="1" Name="LB1"></Lock>
	  </LocksLow>
	  <FusesLow>
		<Fuse Bit="7" Default="0" Name="CKDIV8"></Fuse>
		<Fuse Bit="6" Default="1" Name="CKOUT"></Fuse>
		<Fuse Bit="5" Default="1" Name="SUT1"></Fuse>
		<Fuse Bit="4" Default="0" Name="SUT0"></Fuse>
		<Fuse Bit="3" Default="0" Name="CKSEL3"></Fuse>
		<Fuse Bit="2" Default="0" Name="CKSEL2"></Fuse>
		<Fuse Bit="1" Default="1" Name="CKSEL1"></Fuse>
		<Fuse Bit="0" Default="0" Name="CKSEL0"></Fuse>
	  </FusesLow>
	  <FusesHigh>
		<Fuse Bit="7" Default="1" Name="DWEN"></Fuse>
		<Fuse Bit="6" Default="1" Name="EESAVE"></Fuse>
		<Fuse Bit="5" Default="0" Name="SPIEN" HVProgOnly="1"></Fuse>
		<Fuse Bit="4" Default="1" Name="WDTON"></Fuse>
		<Fuse Bit="3" Default="1" Name="BODLEVEL2"></Fuse>
		<Fuse Bit="2" Default="1" Name="BODLEVEL1"></Fuse>
		<Fuse Bit="1" Default="1" Name="BODLEVEL0"></Fuse>
		<Fuse Bit="0" Default="1" Name="RSTDISBL"></Fuse>
	  </FusesHigh>
	</Signature>

Ich habe die Zeiten beim Compilieren gerade mal nachgemessen.
AF bricht nach 23 Sekunden ab, das Compilieren dauert je nach Programm mal etwas weniger oder etwas mehr. Damit ist auch klar, warum AF manchmal sein o.k. gibt und manchmal eine Fehlermeldung anzeigt. Das kann auch schon mal bei ein und demselben Programm passieren.
Die Ursache des Problems ist offensichtlich der langsame Speicherzugriff auf den USB-Stick.

Kannst Du die TimeOut-Zeit raufsetzen (z.B. 40s) oder besser noch verfügbar machen? Um zu signalisieren, dass etwas passiert und AF nicht abgestürzt ist, könnte doch während der Wartezeit wie beim Flashen des Asuro jede Sekunde ein Punkt ausgegeben werden.

Gruß
Ulli

[Ceos]

den effekt habe ich in letzter zeit auch auf meinen laptop (allerdings ohne USB stick) wenn ich im AVR studio rebuild aufrufe dauert es extrem lange ... vielleicht hast du dasselbe problem und irgendwer der das hier liest zufällig ne lösung

warum startest du den compiler eigentlich asynchron ? ich geb zu mein java ist in der beziehung eingerostet, aber müsste das nicht auch synchron aufrufbar sein ? der returncode des compiler ist doch dokumentiert

[Osser]

Hi Ulli, Ceos,

@ukuchel:
Danke für die Datei, schau mir das heut Abend mal an.

@Ceos:
Eine synchrone Ausführung ist nicht möglich, da der Compiler, WinAvr also, in einem eigenen Prozess läuft und somit nicht synchron im selben Thread/Prozess ausführbar ist.
Wie der Build Prozess in AvrStudio umgesetzt ist weiss ich leider nicht, lediglich für AF kann ich das beantworten, sorry.


Gruss,

O.

[Ceos]

ja gut ich rede hier aus C++(winavr) heraus aber wenn ich per execute ein programm starte, wartet die ausführung des programm selber auf das beenden des aufgebruefnen programm (sie arbeiten immernoch in getrennten threads, aber synchronisieren sich sozusagen beim beenden)

ich meinte das also nicht threadsynchron nur halt blocked oder so ... ich schau grad mal in die API vielleicht find cih was


oder moment ... was meinst du mit winarvr läuft parallel ?

ich dacht du führst nur den makebefehl mit den passenden parametern aus ?

trotzdem würde mich mal interessieren warum der scheinbar nicht nur bei mir manchmal ewig lange braucht zum compilen

EDIT: *Nachschieb*

                Process P = null;
		try {
			P = Runtime.getRuntime().exec("blablabla");
			P.waitFor();  // Veranlasst den aktuellen Thread bis zur Terminierung des Prozesses anzuhalten
		} catch (InterruptedException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}

Problem dabei ist ausschliesslich, dass deine GUI und alles solange einfriert bis das übersetzen beendet ist

[Osser]

Hi Ceos,

Problem dabei ist ausschliesslich, dass deine GUI und alles solange einfriert bis das übersetzen beendet ist

Richtig, Du hast Dir die Frage selbst beantwortet ... deshalb auch der Timeout.


Gruss,

O.

[Ceos]

naja lieber die GUI frieren lassen (so ists in WinAVR auch) als ungültige eingaben vom user haben oder in ein timeout rennen ... der GCC beendet IMMER .... egal ob ohne meldung, mit fehlern oder strg+c ^_^

ich seh das hier aus usability-gründen und fehlersicherheit als günstiger ... by the way man kann auch mit timeout warten, also 20ms timeout und dann ein kleines label ONTOP, damit der user keine eingaben machen kann, auf dem pro timeout so n kreis wie im mozilla browser läuft(also immerwieder ein bild weiter oder so)

EDIT: ich weis ja nicht wie du dein timeout realisiert hast aber man könnte es ja anpasssen, aber eben nie davon ausgehen dass der GCC hängen geblieben ist, das ist quasi unmöglich! eventuell aber einen abbruchbutton einbauen damit man den prozess abschiessen kann ... inwiefern das mit java geht muss ich passen