Beiträge anzeigen
Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.
Nachrichten - AKtronik
1
Ha, jetzt gehts endlich!
Habe meinen Rechner neu gestartet und jetzt gehts mit dem neuen WinAVR.
Merkwürdiger Weise geht es Trotz mehrerer Neustarts mit dem "alten" WinAVR auf meinem Rechner nicht.
Bei dem anderen Rechner ging es ohne Neustart mit dem "alten" WinAVR.
MfG
AKtronik
2
Erst mal vielen Dank für Eure Hilfe!!!
Leider geht´s noch immer nicht
Habe WinAVR auf einen "ähnlichen" Rechner Installiert (nicht meiner) und da läuft´s
(WinXP SP3, Intel Celeron 1,5 bzw. 1,7GHz)
cat.exe von telekatz genommen ->
cat.exe stürtzt ab.Dann habe ich auf meinem Rechner WinAVR de- und installiert ->
cat.exe stürtzt ab.Die aktuelle Version von WinAVR installiert ->
cat.exe stürtzt ab.Jetzt bin ich auf der Suche, was bei den Rechnern unterschiedlich ist.
Leider am Suchen, nicht am Finden.
MfG
AKtronik
3
Hab mich da wohl ungünstig ausgedrückt! Sorry!
Bin ja "so weit" dass der Compiliervorgang startet.
SDCC für Windows habe ich wie oben beschrieben installiert. Dort ist aber die cat.exe nicht enthalten.
Eine cat.exe steckt im WinAVR-Ordner und die wird, wie oben im Inhalt der cat.exe.stackdump zu lesen ist, aufgerufen.
Mit WinSDCC meine ich ein "Paket" mit allen tools die man zum Compilieren von betty_scart braucht.
Also auch die "passende" cat.exe.
@theborg
Danke für den Hinweis. Habe, obwohl auch ältere Versionen funktionieren müssen, die neuste Version installiert.
Das Problem bleibt unverändert bestehen.
Wenn ich jetzt frage, wie ihr das compiliert habt, bekomme ich wahrscheinlich zur Antwort, dass ihr es mit Linux gemacht habt, oder?
Es muss doch auch unter Windows gehen! Was mache ich falsch?
MfG
AKtronik
4
Hallo Leute,
hab da ein (Verständniss-)Problem beim kompilieren von betty_scart.
Ich habe zwar WinAVR und WinARM installiert, aber WinSDCC scheint es so nicht zu geben.
Installiert habe ich dann noch sdcc-20090519-5458-setup.exe und die Pfade in den Makefiles angepasst.
Mit Programmers Notepad v2.0.7.667-devel führe ich das Makefile aus. Im Output wird folgendes gemeldet:
> "make.exe" all
C:/Software/SDCC/bin/sdcc --iram-size 0x100 --model-small --code-size 8096 -IC:/Software/SDCC/include -c main.c
C:/Software/SDCC/bin/sdcc --iram-size 0x100 --model-small --code-size 8096 -IC:/Software/SDCC/include -c serial.c
C:/Software/SDCC/bin/sdcc --iram-size 0x100 --model-small --code-size 8096 -IC:/Software/SDCC/include -c cc1100.c
C:/Software/SDCC/bin/sdcc --iram-size 0x100 --model-small --code-size 8096 -IC:/Software/SDCC/include -c cmd.c
Linking main.rel serial.rel cc1100.rel cmd.rel
C:/Software/SDCC/bin/sdcc --iram-size 0x100 --model-small --code-size 8096 -IC:/Software/SDCC/include main.rel serial.rel cc1100.rel cmd.rel -o betty_scart.ihx
C:/Software/SDCC/bin/packihx betty_scart.ihx > betty_scart.hex
packihx: read 342 lines, wrote 174: OK.
cat betty_scart.hex | C:/Software/SDCC/bin/makebin -s 8096 > betty_scart.bin
0 [main] cat 2148 open_stackdumpfile: Dumping stack trace to cat.exe.stackdump
An dieser Stelle stürtzt cat.exe ab und es erscheint die Fehlerberichterstattung mit der Meldung : cat.exe hat ein Problem festgestellt....bla bla.
In der cat.exe.stackdump steht folgendes:
Exception: STATUS_ACCESS_VIOLATION at eip=300087C1
eax=710A5360 ebx=7159022C ecx=00020978 edx=00000770 esi=00000000 edi=715900D4
ebp=0022FD80 esp=0022FD5C program=c:\Software\WinAVR\utils\bin\cat.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
0022FD80 300087C1 (715900D4, 00000770, 00000003, 30003EE2)
0022FE70 30004074 (00000000, 00000000, 00000000, 00000000)
0022FF40 300047B1 (00401BB0, 00000000, 00000001, FFFFFFF7)
0022FF60 30004E2C (00000000, 00000000, 8054B92F, 00000000)
0022FF90 004057A4 (00401BB0, 00000001, 00000006, EC64DD04)
0022FFC0 0040103D (00000000, 0022DEF8, 7FFD9000, 8054B6B8)
0022FFF0 7C817077 (00401000, 00000000, 78746341, 00000020)
End of stack trace
Aufgerufen wird die cat.exe im Makefile mit den Zeilen:
$(TARGET).bin: $(TARGET).hex
cat $(TARGET).hex | $(IMGMAKER) -s 8096 > $(TARGET).bin
Sieht für mich nach falschem Toolchain aus. Aber WinSDCC habe ich nicht gefunden.
Hat da vielleicht jemand einen Tipp?
MfG
AKtronik
5
Ok, erledigt.
MfG
AKtronik
6
Danke für die schnellen Antworten!
Die Beschreibung im Wiki scheint falsch zu sein.
Ich habe ja vorher die "richtige" libgcc.a nach C:\WinARM\lib\gcc\arm-elf\4.1.1\interwork\ kopiert.
LIBPATH wieder reingenommen
LIBPATH = $(ARMBASE)/arm-elf/lib/interwork -> FEHLER
LIBPATH = $(ARMBASE)/lib/gcc/arm-elf/4.1.1/interwork -> FEHLER
Dann habe ich die "richtige" libgcc.a nach C:/Software/WinARM/arm-elf/lib/interwork kopiert und siehe da,
ES FUNKTIONIERT!!!
Vielen Dank für Eure tolle Hilfe.
Ohne Euch wäre ich nie darauf gekommen!
MfG
AKtronik
7
Hallo und Danke für die Hilfe!!!
Mit svn checkout svn://svn.mamalala.org/boop/trunk als URL hat das Runterladen der Dateien geklappt. Juhuu!
Anschießend wollte ich den Quellcode mit WinARM Kompilieren. Es sah erst gut aus.
Bis zur fehlermeldung:
> "make.exe" all
.
.
.
.
c:/Software/WinARM/bin/arm-elf-ld: ERROR: c:/Software/WinARM/lib/gcc/arm-elf/4.1.1/interwork\libgcc.a(_dvmd_tls.o) uses hardware FP, whereas boop_rom.elf uses software FP
c:/Software/WinARM/bin/arm-elf-ld: failed to merge target specific data of file c:/Software/WinARM/lib/gcc/arm-elf/4.1.1/interwork\libgcc.a(_dvmd_tls.o)
make.exe: *** [boop_rom.elf] Error 1
> Process Exit Code: 2
> Time Taken: 00:00
Ich habe nach Wiki folgendes gemacht:
WinARM nach C:\ entpacken
Systemeigenschaften -> Erweitert -> Umgebungsvariablen: PATH Variable setzen (siehe readme.htm)
Makefile.local.WinARM umbenennen in Makefile.local
In der Datei Makefile.local die Pfade anpassen. Kein abschließender Schrägstrich!
Die Zeile LIBPATH=$(ARMBASE)... löschen oder mit # versehen.
Die Datei C:\WinARM\lib\gcc\arm-elf\4.1.1\interwork\libgcc.a
ist durch die Datei ronetix-gnutools-arm-elf-4.1.1-linux.tar.bz2\ronetix-gnutools-arm-elf-4.1.1-linux.tar\usr\cross\arm-elf\lib\gcc\arm-elf\4.1.1\interwork\libgcc.a zu ersetzen.
Die libgcc.a kann hier als "7Z-Datei" bezogen werden.
Das Makefile.local sieht jetzt so aus:
ARMBASE = c:/Software/WinARM
INCLUDEPATH = $(ARMBASE)/include
# LIBPATH = $(ARMBASE)/arm-elf/lib/interwork
ARMPATH = $(ARMBASE)/bin
TOOLPREFIX = arm-elf-
LPCTOOL = lpctool.exe
Leider kann ich die Ursache für den Fehhler trotz Forumsuche nicht nachvollziehen.
Hat da vielleicht jemand einen Tip?
MfG
AKtronik
9
Hallo Leute,
hab da mal ne Frage.
Ich wollte den Boop-Quellcode (Rev 284) mit WinARM kompilieren, um zu versuchen Erweiterungen vorzunehmen, und unter folgendem Link downloaden.
http://svn.mamalala.org/listing.php?repname=boop&path=%2Ftrunk%2F&rev=0&sc=0Nun habe ich festgestellt, dass der Quellcode nicht als downloadbare *.zip oder Projektdateien vorliegt.
Wie kommt man denn an die Dateien ran?
MfG
AKtronik
10
Wenn Du die beiden Flash.bin´s einzeln zippst sollte dei erste kleiner 250KByte sein.
Die Zweite noch viel kleiner.
Dann kannst Du die Dateien unter [Erweiterte Optionen] Deinem nächsten posting anhängen.
Wenn das nicht geht, dann kannst Du meine eMail anklicken.
Nur bringt das dem Forum nichts.
Wäre vielleicht ein Denkanstoß für die Admins diese Optionen zu erweitern, damit das Board noch userfreundlicher wird und
"Forschergruppen" ihre Ergebnisse einfacher teilen können.
MfG
AKtronik
11
Hey, ist ja super!
So wie es aussieht, habe ich auch eine SwissCom-Betty.
Ich habe leider noch keine IDE am laufen.
Könntest Du dem Forum vielleicht die Flash.bin´s zur Verfügung stellen.
MfG
AKtronik
12
Ein 4,7k-Basiswiderstand für die Basistrombegrenzung wäre anzuraten.
Wenn 3,3V direkt an Q1-BE anliegen haben wir >300mA Basisstrom!
Mit 4,7k-Basiswiderstand nur 0,5mA.
Der Steuerstrom sollte nicht über dem Arbeitsstrom liegen.
Hinter dem Widerstand R3 ist UBE aufgrund der BE-Strecke <1V.
Somit ist D5 arbeitslos.
Bei dem NXPisp-s Interfase wird das Reset-Signal auch durch ein positives PC-Signal erzeugt.
Bei dem Interface von Alterego wird RTS über den MAX3232 zusätzlich invertiert.
MfG
AKtronik
13
OK, dann bevorzuge ich den Einstieg unter Windows.
Hmm, also bei mir wird Reset low, sobald ich "Restore" drücke und erst wieder high wenn der Vorgang beendet ist.
Also genau umgekehrt!?!
Ich verwende folgendes Interface: NXPisp-s.jpg
Das Interface von Alterego finde ich etwas gewagt: Betty-Serial-V2-EAGLE.jpg
Weil Q1 ohne Basiswiderstand betrieben wird und D5 arbeitslos ist.
da bei mir mit Boop nur das Logo und die Uhr läuft, habe ich die Befürchtung, dass ich eine SwissCom-Betty habe.
Der Funkchip CC1100 ist aber direkt auf dem Mainboard.
Soll wohl bei den SwissCom-Bettys nicht so sein.
Hat da vielleicht jemand einen Tip?
MfG
AKtronik
14
Hallo simschmid,
ich habe das gleiche mit der Betty vor, stehe aber auch noch am Anfang!
Bei Betty-Heaven habe ich festgestellt, dass DTR(PC)=Reset(Betty) permanent aktiv=low ist.
Es müste meiner Meinung nach aber nur ein Impuls sein, damit nach dem Reset die Betty antworten kann.
Die Pull-Up-Widerstandslösung an TX(Betty) hilft da nicht weiter.
(Du hast übrigens RX geschrieben (Schreibfehler?)).
Zur Zeit resette ich von Hand. Ich benutze die Freeware version 1.05 (09. Oktober 2007).
Möchte aber gar nicht glauben, dass es sich hierbei um ein Software-Bug handelt.
Bei Boop (boop_rom.bin) und der alternativen Software von den Machern (Flash1_UniFB.bin (und 2)) habe ich keine Einstellmöglichkeiten, bzw weiss nicht wie man das macht, um die Betty als Universal FB zu benutzen.
In Zukunft würde ich gerne Software/Firmware für die Betty erweitern/schreiben. Muss aber erst mal bei den IDE´s durchblicken und ans laufen kriegen.
Habe "nur" Erfahrung mit AVR-Studio und Visual C++, minimal mit WinAVR.
Unter welchem OS sollte man da einsteigen? Win oder Linux?
Mfg
AKtronik
