@ Bingo
Ja bei _InitMemory ist noch einiges umzustricken. Statt den beiden LED
Makros könnte man dort ja das ENABLE und die RX/TX Konfiguration fürs
GPS Modul machen. Mal sehen.
@ Black Friday
Die Unterscheidung System Flash/FLASH ist eine "willkürliche", die
speziell auf das EB40A Board zugeschnitten ist.
s. User Manual Kap. 3.3
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2717
Bei dem Board kann man in dem hohen Flashbereich den Angel Debug
Monitor bzw. einen Bootloader unterbringen und in dem niedrigen Bereich
seine Programme. Über einen Jumper wählbar kann man normal aus dem
niedrigen Bereich seine Anwendung booten oder - nach Jumperumstecken -
den in den niedrigen Bereich gemappten hohen Flashbereich
(Bootloader/Debugger).
Will man eine exakte Anpassung (Speicherlage, Speichergröße) auf unsere
Platine, kann man die EB40A Targetdateien anpassen. Ich muss aber gleich
weg in die Hexennacht. Mal sehen wie fit ich morgen bin ;-)
Sorry, es gibt nicht viel Neues zu berichten.
GNUARM übersetzte Programme ins RAM schreiben klappt. Die Programme
laufen auch. Sogar in GDB/Insight.
Ins ROM schreiben geht auch, aber die GNUARM Programme laufen dann
nicht. Irgendwo steckt noch ein dicker Fehler im selbstgestrickten
Startupcode.
Das mache ich gerne, sobald der Code im Ansatz lauffähig ist. Im Moment
rennt das Programm als ROM Programm fröhlich auf Nimmerwiedersehen ins
Datennirvana. Und es ist nicht ganz auszuschliessen, dass dabei etwas
beschädigt wird. Sobald ich eine "Pre-alpha-Version" habe, gibt es
hier einen Anhang, versprochen!
Da sind sie: Die ersten GNUARM-Programme für das NavMe Board!
Im Anhang ist das komplette Projekt eingepackt. Teilweise sind meine
lauffähigen Binärdateien (main*.*) dabei.
Die Programme schalten das GPS-Modul ein, pollen die serielle Ausgabe
des GPS-Moduls und geben die serielle Ausgabe an die DSUB-26 Buchse
weiter (4800-8N1-kein Handshake). Das spart das Anlöten von Drähten an
das GPS-Modul bzw. das Heraussägen, Runterhebeln usw.
Verwendete Tools:
* Windows 98 SE mit Cygwin 1.5.18
* GNUARM 4.1.0
* OCDRemote 2.16 / Wiggler
* JTAG-O-MAT 1.2.5 mit Windows98 Modif. / Wiggler
* Programmers Notepad (aus WinARM 4.1.0 Paket)
* Hyperterm
Ob Code für ROM oder RAM erstellt wird, steuert das makefile. An der
passenden Stelle muss man den gewünschten RUN_MODE auskommentieren...
Für das Flashen der ROM-Binärdatei sind angepasste JTAG-O-MAT .jom
Dateien erforderlich. Siehe folgende Nachricht mit entsprechendem
Anhang. Bei längeren Programmen nicht vergessen weitere Sektoren im
Flash freizugeben!
Im Startup-Code ist noch einiges auskommentiert, da ungetestet. Das
betrifft vor allem das Interrupt-Handling und Mode Umschaltungen.
Im Moment befinden sich alle Sourcen noch in einem grossen Topf. Bei
fremden Projekten wird meist eine schöne Trennung in Part-spezifische
Header ("Chips") und Target-spezifische Header ("Boards") usw.
verwendet.
Die nächsten Schritte sind wahrscheinlich die AT91 Library von Atmel so
anzupassen, dass sie mit GNUARM übersetzt werden kann.
Stefan
Hier die zweite Portion für die Entwicklung:
*.jom Dateien = Angepasste Dateien für das Speicherlayout der
NavMe-Platine
upload_flash.bat = Batchdatei
Die Datei MAIN.BIN wird mit Hilfe von FLASHER.BIN ins FLASH
geschrieben. ACHTUNG: Der alte Inhalt von FLASH ist dann futsch!
Nach dem Flashen muss ein RESET erfolgen. Auf meinem Board macht das
RESET in der *.jom Datei KEINEN Hardware-Reset. Das Aus- und Anschalten
der Stromversorgung auf dem NavMe Board ist wirksam.
Stefan
Abend zusammen,
so, da ja jetzt das programmieren des Boards funktioniert, bin ich,
bevor ich richtig in die Programmierung einsteige, gerade am überlegen,
worauf ich später die Navigationsdaten anzeigen will.
Da die unbenutzten Prozessorports leider nicht auf Stiftleisten geführt
sind, wollte ich es gerne vermeiden, Unmengen von Fädeldraht an die
Prozessorbeinchen anzulöten.
Deshalb will ich über SPI eine Porterweiterung anbinden.
Daran will ich dann ein grafisches Display anschließen.
Für die ersten Tests werde ich dafür ein Optrex DMF5008 verwenden, da
ich davon zwei Stück hier herumliegen habe.
Zuerst hatte ich mir überlegt, ein Display mit Hilfe eines zweiten
kleinen Prozessors über UART anzubinden, doch dann hätte ich Probleme,
diesen z.B. für Wegpunkteingaben über den PC zu benutzen.
Habt ihr euch schon Gedanken über eine Displayanbindung gemacht? Oder
habt ihr etwas ganz anderes mit dem Modul vor?
Ich überlege mir gerade eine kleine Anwendung als Positions-Datalogger,
um ein paar Motorradtouren mitzuloggen. In das 8MB SDRAM müsste selbst
bei kontinuierlichem Sampling alle 1s fast ein Tag Daten passen.
Im einfachsten Fall benötigt so ein Logger kein Display oder andere
Ports. Eine Stromversorgung (7.2V/32 Wh Li-Ion Ersatzakku vom Camcorder
?) versorgt den Logger bis zum späteren Auslesen und startet über
"Reset-on-Power" beim Anstecken das Samplingprogramm.
Schöner wäre es, wenn ich das Sampling starten/stoppen könnte und wenn
ich Daten aus dem flüchtigen SDRAM ins Flash-Rom schreiben könnte. Dazu
bräuchte ich aber 2 Portpins für eine LED und einen Taster. Klar noch
schöner wäre es, wenn alle unbenutzten Portpins plus die momentan
totgelegten IRQ-Pins... für ein optimales Experimentiersystem verfügbar
wären.
Mit einem Display könnte man z.B. die vermissten Funktionen in der GPS
Firmware nachprogrammieren wie Bearing oder Cross Track Distance und
anzeigen. Oder eine "Atomuhr" oder einen "Höhenmesser" basteln...
Ausser Anlöten von Fädeldraht ist mir aber auch noch keine
mopped-stabile Do-It-Yourself Methode eingefallen, um an die Portpins
dranzukommen. Vor dem Anlöten habe ich einigen Respekt, da ich so ein
Subminigefummel noch nie gemacht habe. D.h. auf jeden Fall vorher an
Schrottplatinen üben...
Wobei die Idee SPI schon verlockend klingt...
Vielleicht kann man auf der Basis von diesem Beitrag aus der
Codesammlung sowas mit 4 ARM-Portpins (nur viermal zittern ;-) und
Software-SPI bis 8 Tasten plus Display anschliessen:
http://www.mikrocontroller.net/forum/read-4-264943.html#new
Ich glaube einer Atmega48L/88L als interface chip , und dann I2C oder
SPI brauche als kommunikation , und dann kriegst du noch einer uart.
Brauchst du mehre pins dann einer Mega16
/Bingo
Morgen zusammen,
und, seid ihr am Wochenende weitergekommen?
Momentan bastle ich gerade an meiner NMEA - Einlesefunktion und suche
Informationen über Entfernungs- und Richtungsberechnungen.
Das Display werde ich über eine I2C - Porterweiterung anbinden, an den
Bus kann ich dann auch noch andere Sachen hängen (z.B. FRAM zur
Wegpunktspeicherung bei Stromausfall). Mal sehen, wie ich den soft-I2C
hinbekomme.
Als Logger werde ich das Gerät wahrscheinlich nicht benutzen, dafür
habe ich ein uBlox MS1E-DL Modul.
@ Bingo
Hmm, das wäre auch ein Weg.
Statt RXD0/TXD0 wird die DSUB26-Buchse mit den beiden PIO-Leitungen
P14/P15 belegt. Und die werden als softwaregesteuerte I2C-Leitungen
benutzt. Ob das signaltechnisch geht?
Das würde dann die Löterei am AT91 ersparen. Die dadurch fehlende
UART-Schnittstelle müsste dann der Interface-µC/IC mitbringen. BTW.
gibt es I2C-to-RS232 Bausteine?
>BTW. gibt es I2C-to-RS232 Bausteine?
Warum nicht einfach direkt nen uart in Software schreiben ?
Zumindest zum senden ist das bei niedrigen baudraten wie zb 19200
überhaupt kein Thema ;) (selbst ohne timer)
Bye, Simon
Wenn man unbedingt was mit I2C-Bus machen will und sich einen 2. µC
sparen will, wäre so ein Baustein interessant. Bisher braucht man für
den Anschluss an den PC ja auch noch einen MAX32xx und wenn man den
dadurch auch noch sparen könnte...
Aber mir jetzt auch was aufgefallen, als ich im Wiki rumgefutschelt
habe und den Beitrag von Bingo nochmal überdacht habe:
AT91 => vorhandenes(!) UART => 2. µC
Der "ideale" 2. µC müsste 2 UARTs haben plus die gewünschten Ports
fürs Display und die Tasten.
Jetzt wo ich es so schreibe, fällt mir ein, dass ich noch ein R8C mit
5V-Applikationsboard und LCD habe, auf dem nur eine LED blinkt ;-) Ein
paar Tasterchen werden sich bestimmt noch finden. Mal recherchieren,
wie weit ich bei diesem 5V System mit den 3.3V Signalpegeln komme oder
ob ich Levelshifter brauche. Und ein bisher unbenutztes
3.3V-ATmega128-Board mit Handy-Grafikdisplay und vier Tastern hätte ich
auch noch ;-)
Abend zusammen,
ihr habe mich überzeugt. Die Lösung mit dem zweiten uC ist viel
eleganter und weniger "gefuddel".
Die ursprüngliche Anordnung (mit Handy zur Ansteuerung und Anzeige) hat
ja ähnlich funktioniert.
Als zweiten uC werde ich dann einen MSP430 nehmen, an den kommt dann
ein Drehgeber und noch ein zusätzlicher Taster. Das Display muss ich
dann halt über einen Pegelwandler anschließen.
Ob ich das FRAM direkt an den ARM oder den MSP430 hänge weiß ich noch
nicht.
> Und ein bisher unbenutztes> 3.3V-ATmega128-Board mit Handy-Grafikdisplay und vier Tastern hätte
ich
> auch noch ;-)
Wäre doch genau das Richtige, da der ATMEGA128 zwei UARTS besitzt.
Yes so sieht es aus. Weil beim R8C (hat auch 2 UARTs) ist für HIGH min.
0.8*Vcc erforderlich und das sind 4V bei Vcc=5V. Den Level erreicht das
3.3V NavMe-System nicht.
Ich habe nochmal alles umgeschmissen, weil ich nicht einsehe, mein 70
ATmega128 System an eine 3 Recyclingplatine anzuklemmen und dann mit
dem Mopped spazieren zu fahren ;-)
Für meine Datenlogger-Idee kann ich auch mit einer minimalen IO-Lösung
weiterkommen.
Minimal heisst eine LED zur Anzeige ala "GPS fix ist (nicht) da",
"ich schaffe gerade was ins Flash, nicht stören", "1,2,3x blinken
für eine Menüauswahl"... Und eine Taste für das Treffen der
Menüauswahl.
Da ich auf der NavMe-Platine nicht löten will, nutze ich eine Leitung
die bereits über DSUB26 rausgeführt wird. IO-Leitungen im klassischen
Sinn sind zwar nicht herausgeführt, aber die RXD0 und die TXD0 Leitung
von UART0. Und diese sind auf dem µC gemultiplext entweder IO Leitungen
oder UART Leitungen. Und weil ich auf die Übertragung der seriellen
Daten vom Tyco-Modul über den µC über TXD0 über DSUB26 in einen PC
nicht verzichten will, wird die LED und der Taster an die nun-ex-RXD0
Leitung angeschlossen.
Hardwaretechnisch bin ich ein ziemlicher Laie, daher habe ich meine
Anschlussidee mit der Studentenversion von Electronic Workbench 5.12
(war in einem Franzis Buch vom Grabbeltisch drin) simuliert. Die
Simulation ist im Dateianhang als *.EWB Datei und als *.GIF Datei
dabei. Ziel war in allen denkbaren Konfigurationen den µC strommäßig
nicht zu überlasten und die Low Current LED zu betreiben aber nicht zu
braten. Ich brauche als externe Bauteile einen Taster, drei
Widerstände, eine Low-Current-LED und einen Transistor.
Zur Ansteuerung habe ich ein Demoprogramm mit GNUARM 4.1.0 geschrieben,
welches als komplettes Projekt auch im Anhang enthalten ist. Es ist ein
minimales Proof-of-Concept Demo auf der Basis des UART-Polling
Beispiels.
Im Bereich Display finde ich die DOG LCD Displays z.B. von Reichelt
technisch (3,3V + SPI) und preislich (11 Euro) interessant. Hat hier
schon jemand Erfahrung mit diesen Displays?
====
3,3V DOG Modul Serie
z.B. blauer Hintergrund
Diese neue Displayserie wurde speziell für low-power Handheld
Applikationen entwickelt. Erstmals ist der Betrieb eines
Standard-Displays direkt an 3,3V möglich ! Ein 5V Betrieb ist
selbstverständlich ebenso möglich. Auch die optional erhältlichen
LED-Beleuchtungen laufen je nach Beschaltung mit 3,3V oder auch mit
5V.
kompakt mit 55x 31mm bei Standardschriftgröße 5,57mm (2x 16)
flach mit 2,0mm unbeleuchtet und 5,8mm mit Beleuchtung
direktes Einlöten in Platine ohne zus. Montageaufwand
4-Bit, 8-Bit und *SPI*-Interface
3,3V oder 5V - auch LED Beleuchtung
viele verschiedene Designs ab 1 Stück realisierbar
Top. -20..+70°C integr. Temperaturkompensation
2x 16 Zeichen, Schrifthöhe 5,57mm
====
Hallo zusammen,
sehr interessantes Display. Werde mir mal eins bestellen und dann
gucken ob ich das in meinen GPS-Tracker
(http://thomaspfeifer.net/gps_tracker.htm) noch reingequetscht kriege.
2mm Höhe könnte so gerade eben noch passen :-)
Hallo Thomas, ein schönes Projekt hast du da auf die Beine gestellt!
Zu dem Li-Ion-Akku speziell habe ich eine Frage, weil ich auch mit dem
Gedanken spiele einen zu verwenden. Und Li-Akkus sollen ja bei
Unterspannung bzw. Tiefentladen problematisch sein.
Hast du eine Überwachung / Schutzschaltung für diesen Fall vorgesehen?
Hallo Stefan,
habe auf der Platine einen hochohmigen Spannungsteiler vorgesehen, der
auf einen ADC-Eingang geht. So kann ich die Akku-Spannung zusammen mit
der internen Referenzspannung messen.
Sollte diese zu niedrig werden, wird die MMC-Karte und das GPS-Modul
auf Standby geschaltet und der Atmel mit dem Powerdown-Modus schlafen
gelegt.
Die Stromaufnahme sollte dann theoretisch bei einigen zig uA liegen.
Habe ich aber noch nicht ausprobiert.
Beste Grüße
Thomas
Moin
@Hartmut
Ebay-Artikel-Nr: 8807653888
Ist schön klein und kann man dank Magnet überall dran pappen.
Stromaufnahme (gemessen) ca. 8mA
@Stefan
Wenn es ein Atmel ist, hast du vielleicht noch den Komparator frei ?
Dann könnte man auf den einen Eingang mit einer Z-Diode z.B. 3V
erzeugen und die Batteriespannung auf den anderen Eingang legen.
Guten Morgen...
"mit einer Z-Diode z.B. 3V erzeugen und die Batteriespannung auf den
anderen Eingang legen". Hier fragt sich natürlich der aufmerksame
Leser, wie man aus einer Akkuspannung von kleiner 3V, mit einer Z-Diode
die 3V erzeugen soll... klappt nich :-)
Man könnte aber mit einer normalen Diode 0,7V für den einen Eingang
erzeugen und die Akkuspannung mit einem Spannungsteiler am anderen
Eingang so herunterteilen, das man bei der gewünschten Spannung unter
die 0,7V kommt.
Beste Grüße
Thomas
@ Thomas
neenee, ich will den ARM und das SDRAM (und ggf. restliches FLASH) auf
der Platine selbst als Teile des Loggers nutzen und keinen weiteren µC
anschliessen. Und bei dem AT91R40008 ist leider kein ADC vorhanden. Ich
werde es wahrscheinlich zuerst mit einer weniger kritischen Akkuart
versuchen.
@ All
Gestern abend bin ich mit dem Menü für die I/O-Modifikation (=> Wiki)
fertiggeworden. Die LED hat quasi drei Anzeigezustände - dunkel
(P15=Output LOW, schwach leuchtend (P15=Input), hell leuchtend
(P15=Output HIGH). Zusammen mit einem einfachen Blinkcode klappt eine
Auswahl von 1 bis z.B. 3 Möglichkeiten über Polling ganz gut.
Als nächstes werde ich mal den Stomverbrauch bei verschiedenen
Versorgungsspannungen und Betriebsarten messen. Vielleicht hilft das
auch bei der Lithium-Akku-Problematik.
Für meinen Plan eines akkubetriebenen GPS-Loggers war es wichtig zu
wissen, welcher Strom bei welcher Versorgungsspannung fliesst. Dieser
Zusammenhang wurde im Bereich 6V bis 13V Versorgungsspannung gemessen.
Bei der Messung war meine einfache I/O Erweiterung aus LED und Taster
angeschlossen. Desweiteren wurden der RS232-Levelkonverter und der
Wiggler von der NavMe-Platine versorgt. Das GPS-Modul inkl. externe
Antenne war in Betrieb und im AT91 lief ein RS232-Pollingprogramm,
welches im externen Flash untergebracht war.
Die Messkurve ist im Dateianhang zu sehen.
Ausgehend von 13V Spannung wird mit fallender Versorgungsspannung mehr
und mehr Strom aufgenommen. Das Produkt aus Spannung * Strom, d.h. die
Leistung ist fast konstant bei knapp 800 mW. Die Schwankungen bei
höheren Spannungen rechne ich der Ablesung der Messwerte zu. Bei
niedrigen Spannungen könnte ein leichter Anstieg der Leistungsaufnahme
möglich sein.
Bis inkl. 6.3V arbeitet das System noch korrekt. Bei 6V wurde eine
deutlich niedrigere Stromaufnahme gemessen. Gleichzeitig wurde ein
Funktionsverlust bei der I/O-Anwendung beobachtet. Der AT91 hat
anscheinend die Funktion eingestellt.
Hi,
gibt es eigendlich eine Hardware/Software Kombination fuer den JTAG,
mit der man die Platine sowohl programmieren und debugen kann, die
ueber eine RS232 oder USB Schnittstelle verfuegt?
Der JTAG-O-MAT unterstuezt zwar den Turtelizer zum pgrogrammiren,
diesen kann man aber nciht zum debuggen einsetzen und einen
Parallelport Wiggler kann ich an meinen Laptop nicht anschliessen.
Zwei verschiedene Adapter zum Programmieren und Debuggen finde ich
nciht sonderlich elegant.
Gruss Tobias
Interessant finde ich den Jtagkey von Amontec (leider keine Windows 98
Treiber) bzw. auch das USB to JTAG Interface vom Volksmikro
http://www.amontec.com/jtagkey.shtmlhttp://www.fh-augsburg.de/~hhoegl/proj/usbjtag/usbjtag.html
Beide nutzen OpenOCD als Bindeglied zwischen Debugger z.B. GDB und der
Hardware.
Weiter ist ein USB to JTAG Device von Olimex für Juli 2006
angekündigt:
http://www.olimex.com/dev/arm-usb-ocd.html
Hier wird ebenfalls OpenOCD verwendet.
Daher wäre es meiner Ansicht nach am vielversprechendsten für OpenOCD
einen auf unser System passenden Flash-Programmer-Treiber zu schreiben,
wenn man über USB arbeiten will. Der Flasher vom Jtag-O-Mat ist eine
sehr gute Basis dafür.
Hallo
Ich weis es ist schon eine Zeit lang her, aber hat vielleicht jemand
von eich noch so eine Platine übrig?
LG
Michael
rubitschka at hotmail punkt com
Ja eigentlich ich ;-)
Datenlogging für Moppedtouren. Stand ist im Moment eine rudimentäre
Menübedienung (s. Wiki) und die Stromversorgung über Li-Akku eines
Camcorders inkl. externe Warnungschaltung mit Buzzer bei Unterspannung
beim Li-Akku. Offen ist die Transferroutine, um Daten aus dem SDRAM ins
FLASH-ROM zu schreiben.
Nur ist mir der Sommer dazwischen gekommen und ich habe mehr Zeit in
andere saisonabhängige Hobbies gesteckt. Die µC-Pfriemelei habe ich auf
den kalten Herbst/Winter verlegt.
Aber die Wartezeit hat auch was gutes. Mit Interesse verfolge ich die
"Olimex USB-JTAG for ARM" Entwicklung. Möglicherweise ist das ein
schöner Ersatz für meinen Selbstbau-Wiggler. Wenn da jemand Erfahrungen
hat, bitte posten!
@Stefan
Hallo Stefan
Ich habe probiert die gcc-uartpolling code , mit WinArm 20060606
Ich kriege einer linker fehler ....
Linking: main.elf
arm-elf-gcc -mcpu=arm7tdmi -I. -gstabs -DROM_RUN -O0 -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=startup.o -std=gnu99 -MD -MP -MF
.dep/main.elf.d startup.o main.o --output main.elf -nostartfiles
-Wl,-Map=main.map,--cref -lc -lm -lc -lgcc -TAT91R40008-NavMe-ROM.ld
e:/arm-tools/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin
/ld.exe: address 0x1000900 of main.elf section .stack is not within
region SRAM
Aber keiner linker fehler wann ich compilere iomod-gcc , ich habe
möchligerveise einer fehler im WinArm gefunden oder ????
Ob ich mache "nur einer entry" im .data mit zbsp. int i=7 , dann kriege
ich keiner linkerfehler mit gcc-uartpolling.
Und die program lauft feine
Hast jeman diser fehler gesehen ???
mfg
Bingo (aus Dänemark)
Heh, da ist ja noch einer ;-)
Bei GnuARM ist das Problem nicht aufgetreten. Aber das Problem ist bei
WinARM bekannt. Ich selbst bin auch schon darüber gestolpert, als ich
WinARM ausprobiert habe, siehe
http://en.mikrocontroller.net/topic/67766#85448 und die folgende
Diskussion. Da ist aber nicht mehr rausgekommen, als dass es ein
ungelöstes Rätsel bei WinARM ist.
Halte dich an das Readme von WinARM
http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/WinARM_20060117_readme.html
------------------------------------------------------------------------
It seems that the linker does not provide a correct "." if the section
before is empty and the current section is aligned in the section
"header". I'm not sure why - maybe a new feature or a bug in the
binutils. In the "blinkswitch" examples for LPC2106 und LPC2129 I've
somehow fixed this and verified the correct result by the values given
in the map-file.
In the linker-script for ROM
.stack ALIGN(256) :
{
...
has been replaced with:
.stack :
{
. = ALIGN(256);
------------------------------------------------------------------------
Wenn das nicht hilft, opfere ein Byte im SRAM und lege eine
Dummyvariable an, so wie du es mit int i=7 machst.
@Stefan
Danke
Diser fix funktioniert :-) , ich habe keiner linkerfehler mehr.
Ich habe einer anderes frage ...
Ich kann nicht die jtagomat (wiggler) (1.2.5 von sourcefourge) , zum
funktionieren mache.
Ich habe deiner upd_jtagomat_20060503.7z , im einer directory macht ,
und auch die jtagomat.exe im selber directory.
Ich krige ein error wann ich sollte die 2 sektoren löschen.
>jtagomat.exe -v BATCH at91-upl.jom FLASHJTAG-O-MAT 1.2.5
Wiggler at LPT1 - Port 0x378
at91-upl.jom(24): RESET
at91-upl.jom(25): BATCH at91-remap.jom
at91-remap.jom(1): ; Remap
at91-remap.jom(2): ; =====
at91-remap.jom(3):
at91-remap.jom(4): ; Enter debug mode and check device
at91-remap.jom(5): HALT
; ARM DBG
R0 0xF00000D3
R1 0xEFFFFDFF
R2 0xFFFF5F7F
R3 0x0072808C
R4 0xFF7F9BBB
R5 0xFBFFF9FB
R6 0xFF7F7FFB
R7 0xFABFEFDE
R8 0xFFFF5F7F
R9 0xFFFDEBFF
R10 0xFF7FF7FF
R11 0xFAD7DF1F
R12 0xDDFFDFDE
SP 0xFFFD7FBB
LR 0x00434234
PC 0x002E7FAC
CPSR 0x000000D7 ; ------------------------IF- ABORT
at91-remap.jom(6): DEVICE $DEVICE
Target ID = 1F0F0F0F
at91-remap.jom(7): ONERR BadDevice
at91-remap.jom(8):
at91-remap.jom(9): ; Do remap
at91-remap.jom(10): LOAD 0x00000000 ; No idea, but this seems to fix a b
at91-remap.jom(11): ; SAVE 0xFFE00000 0x1000213D
at91-remap.jom(12): ; SAVE 0xFFE00004 0x20003E3D
at91-remap.jom(13): SAVE 0xFFE00000 0x01003531
at91-remap.jom(14): SAVE 0xFFE00004 0x03003525
at91-remap.jom(15): SAVE 0xFFE00020 0x00000001
at91-remap.jom(16): ONERR RemapFailed
at91-remap.jom(17):
at91-remap.jom(18): ; Verify result
at91-remap.jom(19): ; LOAD 0xFFE00000 1 0x1000213D
at91-remap.jom(20): ; LOAD 0xFFE00004 1 0x20003E3D
at91-remap.jom(21): LOAD 0xFFE00000 1 0x01003531
at91-remap.jom(22): LOAD 0xFFE00004 1 0x03003525
at91-remap.jom(23): ONERR RemapFailed
at91-remap.jom(24): QUIT
at91-upl.jom(26): ONERR ErrorExit
at91-upl.jom(27): NOTE Reset OK, uploading flasher...
Reset OK, uploading flasher...
at91-upl.jom(28):
at91-upl.jom(29): ; Upload the Flasher Tool
at91-upl.jom(30): SAVE 0x00000000 ./flasher.bin
at91-upl.jom(31): ONERR ErrorExit
at91-upl.jom(32): NOTE Upload OK, starting flasher...
Upload OK, starting flasher...
at91-upl.jom(33):
at91-upl.jom(34): ; Run the Flasher Tool
at91-upl.jom(35): SAVE CPSR 0x000000D3
at91-upl.jom(36): CONTINUE 0
at91-upl.jom(37): WAIT 100
at91-upl.jom(38):
at91-upl.jom(39): FLASH 0x01000000
Flash identifier 0x00900090
at91-upl.jom(40): ONERR ErrorExit
at91-upl.jom(41): NOTE Flasher running and flashing $IMAGE
Flasher running and flashing ./main.bin
at91-upl.jom(42): ; 2 Sektoren l÷schen
at91-upl.jom(43): FLASH 0x01000000 0x01000000
at91-upl.jom(44): ONERR ErrorExit
at91-upl.jom(55): QUIT 3
Mein wiggler funktioniert , und ich kann flashen mit macraigor
flashtools , aber nicht mit jtagomat.
Brauchst jtagomat wiggler auch die com-port zum flash loaden ??? , oder
brauchst er nur wiggler ??.
Ich rxd + txd + gnd verbundet am meiner pc COM1 via einer Max3232 , aber
kein andere signale.
mfg
Bingo
@ Bingo
UART/COM brauchst du beim Jtagomat nicht unbedingt. Das ist nur eine
Option, weil dir das Flasher.bin Statusmeldungen geben will. Ich
vergleiche heute abend mal dein Uploadprotokoll mit einem von mir.
@Stefan
Die jtagomat fungiert jetzt ...
Ich habe die JTAG /rst wire wegnehmen von die navme stecker , und jetzt
fungiert es.
So das war die JTAG reset wire das war einer problem.
/Bingo
Hallo,
lange ist's her. Hat jemand noch dieses Modul noch in Betrieb? Ich habe
gestern das erste mal so ein Modul in Betrieb genommen...
Ich beobachte folgendes:
Die ermittelte Position liegt ca. 40km daneben (6-7 Satelliten werden
empfangen). Diese falsche Position ist aber sehr konstant. Es verbessert
sich auch nichts, wenn ich das Modul > 12.5min in Betrieb halte damit es
die Satelliten-Daten updaten kann. Es bleibt immer falsch, aber sehr
konstant falsch.... (>30min kontinuerlich in Betrieb)
Habt ihr das gleiche Problem oder muss man irgendwie den Update der
Sat-Daten anstossen?
Ich habe extra mein Modul vom Schrank runtergeholt und angeschlossen.
Funktioniert im Meter-Bereich genau: Die gemeldete Position auf der MS
Autoroute-Karte ist direkt vor meiner Wohnung. Ein Update habe ich nie
gemacht und das letzte Mal war das Modul ca. vor 6 Monaten an Saft
angeschlossen.
Vielen Dank dafür Stefan,
dann ist das ganze für mich ein Rätsel. Ich habe zwei GPS receiver
parallel laufen. Einer basiert auf einen Infineon Chip und zeigt die
korrekte Position an, das Navme Modul gibt zwar auch immer die gleiche
Position an, die ist aber falsch...
(Die Koordinaten N, E kann mach auch direkt in google Maps eingeben)
Ich habe mein Modul direkt ausgelötet und nie mit der Hauptplatine
zusammen betrieben, war das bei dir auch so? Vielleicht macht die
Hauptplatine noch ein Update?
Nee, ich habe das GPS-Modul immer noch auf der Navme-Platine.
Ich hatte es damals ja benutzt, um in die ARM7 Programmierung rein zu
schnuppern. Wobei ich derzeit mit AVRs kleinere Brötchen backe, weil
zwei I/O-Pins an dieser Platine arg mager sind und weil mir der
Einzelkampf nicht so viel Spass macht ;-)
Jedenfalls damals hatte ich den ARM so programmiert (Original-OS raus,
Eigenprogrämmchen mit GNUARM erstellen und über JTAG rein), dass er die
Daten vom GPS-Modul empfängt und direkt wieder an der zweiten UART
ausgibt. Dadurch brauchte ich das GPS-Modul selbst nicht runter zu löten
und ich brauchte auch keine TX-Leitung ans GPS-Modul zu löten. Damals
war mir Löten und Löten an SMD im speziellen zu haarig.
Ich war auch dabei, die Daten im RAM zwischenzuspeichern, um einen
GPS-logger zu machen. Externe Versorgung aus einem Camcorder-LiIon-Akku
mit selbstgebautem Akkuwächter zum Schutz vor Tiefentladung und eine
1-Tasten Menüführung hatte ich auch schon gebastelt. Aber das Projekt
ist dann eingeschlafen (warum eigentlich?)
SuperUser wrote:
> Die ermittelte Position liegt ca. 40km daneben (6-7 Satelliten werden> empfangen). Diese falsche Position ist aber sehr konstant.
Welches Koordinatensystem nutzt Du jeweils?
http://de.giswiki.net/wiki/Koordinatentransformation
Problem wurde dort
Beitrag "GPS-Positionsdaten versetzt"
beschrieben und gelöst...
Google Maps braucht entweder die Koordinaten mit Nachkommastellen oder
aufgelöst in Minuten Sekunden etc.
also z.B. für die Nordkoordinate:
N51 21'26.7
oder
N51,357417
Erstmal sorry für das hochholen des alten Threads, aber hat denn noch
jemand von euch eines der GPS-Module oder auch gerne eine ganze Platine
übrig?
Oder kennt jemand eine andere preiswerte Bezugsquelle?
Ich will mir nämlich nach Thomas Pfeiffers Vorbild einen GPS-Tracker
bauen.
Danke für eure Hilfe,
Angelo
Hallo, ich habe noch solche Platinen übrig. Wenn Interesse besteht, hier
mal reinschreiben. Ansonsten habe ich vor, die demnächst bei Ebay zu
verkaufen. Was denkt ihr, welcher Preis ist gerechtfertigt?
Frank wrote:
> 10 Euro würde ich sagen.
Hallo, das halte ich für unrealistisch. Der GPS Empfänger ist ja das
wertbestimmende Bauteil/ Baugruppe dabei.
@ rubi: Du bekommst eine Nachricht.
Hallo
Um 10€ pro Stück hätte ich 2 genommen.
40€ sind mir viel zu teuer, da bekomme ich ja schon einen neuwertigen
Empfänger.
Siehe:
http://www.sparkfun.com/commerce/categories.php?c=4
Für mich hat sich die Sache erledigt.
LG
Michael
für ca. 1€ sehe ich dort nur den Steckverbinder. 40€ für 2 Platinen
incl. Versand, gegenüber 39,95$ für ein Modul plus Versand bezeichne ich
jetzt nicht als Wucher. Würde auch eins für 20€ incl. Versand abgeben.
Will jemand anders? Oder anderer Vorschlag?
Hallo,
hat jemand vielleicht noch den Schaltplan des Navme Moduls. Die
Downloadseite von Birger* (http://birger.homedns.org/GPS-Rx) ist wohl
nicht mehr erreichbar.
Vielen Dank, Peter
Hallo,
hat jemand noch Platinen übrig mit GPS Modul, die er nicht mehr braucht
und verkaufen will? Ich nehme sie gern. Macht mir einen Vorschlag
wieviel ihr haben wollt.
MfG Tom
Hallo,
hat zufällig noch jemand ein oder zwei Platinen übrig, die er mir
verkaufen würde?
Ich möchte mir ein dead reckoning GPS ("Koppelnavigation") fürs Auto
basteln. Die Tyco Module sind dafür optimal geeignet, aber leider schon
lange abgekündigt. Wenn man die Tachopulse im Auto zur Verfügung hat,
braucht man nur noch einen passenden Gyro und die richtige Firmware. Die
FW und einen geeigneten Gyro habe ich schon. Mir fehlt nur noch das
Modul.
MfG Sebastian
