@ 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.
@Strfan kannst du deiner starupkode aufladen hier bitte ?? mfg Bingo
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
Respekt und danke für den upload. Schade dass meine Module im Moment ungenutzt rumliegen müssen.
Hi Stefan, Ich kann mit den 7z-Dateien leider nix anfangen. Was ist denn das für ein Kompressionsformat? mfg, 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.
@ Black Friday Welchen IC willst du für die Porterweiterung einsetzen, PCF8574 von Philips? Für die Softwareseite ist sicher diese Application Note interessant: "AT91M63200: I2C Drivers for AT24C512 Serial EEPROM (39 pages, Updated 6/01) - Describes the software implementation of an Inter Integrated Circuit Bus (I2C Bus) using the peripherals in the AT91M63200." http://www.atmel.ru/Atmel-2003.September/1/dyn/products/Wcd9027c4ad7d3.htm http://www.atmel.ru/Atmel-2003.September/1/dyn/resources/prod_documents/DOC1742.PDF
Beim Rechnen könnte das weiterhelfen: Aviation Formulary V1.42 by By Ed Williams http://williams.best.vwh.net/avform.htm
@ 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
@ Thomas Danke! Leider muss ich mir mangels ADC was anderes überlegen müssen. Mal sehen.
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.
Angehängte Dateien:
-
Spannungsversorgung.jpg
18 KB
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.shtml http://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
Hallo, arbeitet noch jemand an einem Projekt (Datenlogger ???) für die Platine? Grüße H.H
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 FLASH JTAG-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
> Heh, da ist ja noch einer ;-)
Hey da sind auch noch mehr! Habe auch diese Platinen, nur zu wenig Zeit.
Hoffe auf den Winter ...
@ 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
Bekommt man die Platinen noch irgendwo? Wenn nicht, hat einer von euch eine zu verkaufen?
Würde mich auch mal interssieren. Brauche auch nen GPS Empfänger.
Es gibt wieder einen Empfänger:http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&rd=1&item=320163794711&ssPageName=STRK:MESE:IT&ih=011
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?
> Es werden 200 Stück angeboten, der Preis pro Stück liegt momentan noch > bei 1,- EUR. 1€?
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=120337240284 25,43€ und http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=120342512238 27,75€ ... etwas mehr als der erwähnte 1€ und teurer als die angebotenen 40€ / 2 Platinen (incl. Versand)
Wenn ich den Thread richtig überflogen habe, sind damals die ersten Dinger für 3,- EUR bei *Bay rausgegangen... ist allerdings schon etwas her ;)
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
Lohnt es sich einen so alten Thread wieder auszugraben? In der Markt Rubrik kann man GPS fuer ca 20 Euro kaufen. Ab Lager.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.