Hallo, ich brächte einen µControler (bevorzugt AVR) der folgende Features bietet: .) 2 ser. Schnittstellen .) Daten- & Adressleitungen herausgeführt 2 ser. Schnittstellen um eben mit 2 "Geräten" zu kommunizieren (GPS Modul & PC, via IrDA) Daten- & Adressleitungen um auf eine (klarerweise externe g) Compact Flash Karte zugreifen zu können. Der kleinste AVR der diese Bedinungen erfüllt ist der ATMega64, den es nur als SMD Version gibt (was für die ersten Prototypen doch nervig ist). Außerdem is er mit 64 Pins für die wenigen Aufgaben (GPS Modul auslesen, in EPROM buffern, auf CompactFlash schreiben, über IrDa an den PC senden) doch um einiges überdimensioniert. Gibt's irgendeine Möglichkeit, wie ich das ganze mit einem kleineren µC lösen könnte? Auf so Ideen wie CompactFlash Karte hinter einen I2C I/O Expander zu hängen bin ich auch schon gekommen, allerdings ist das meiner Meinung nach zu aufwändig... vorallem weil ich dann noch immer nicht vom ATMega64 loskomm, wegen der ser. Schnittstellen. Bin für jeden Ratschlag dankbar .... mit freundlichen Grüßen, Alexander Höller
Hi ATMega162 erfüllte alle deine Wünsche. Das hättest du aber auch durch einen Blick auf http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC selbst herausfinden können. Matthias
Ahh, vielen Dank ! Hab die Tabelle leider nicht gefunden gehabt ... mit freundlichen Grüßen, Alexander
Hast du zufällig eine Quelle für ein billiges GPS Modul? Ich wollte mir demnächst eine Poor-Man-Navigation für die Hosentasche bauen.
Wenn die Übertragungsgeschwindigkeit nicht zu hoch sein muß, dann kann man die serielle Schnittstelle auch problemlos in Software machen. GPS wird sowieso oft nur mit 9600bps gefahren, da sind die Anforderungen nicht so hoch. Damit hast Du deutlich mehr Möglichkeiten bei der Wahl Deines Controllers. Markus
Nö, Standard fürs NMEA Protokoll ist 4800 Baud. Manche Empfänger können auch schneller, ist aber selten bei NMEA. Garmin schickt das eigene Protokoll z.B. mit 9600.
@Fritz: Billig leider nicht, werd wohl ein Modul von Garmin verwenden --- Stimmt, Standard ist 4800 Baud ... aber bei den Garmin Modulen kann man die Übertragungsgeschw. auf bis zu 38k4 "hochschrauben" - der ATMega162 scheint eh recht brauchbar zu sein ... nur die 16kb Flasg machen mir bisschen Sorgen! Dazu hab ich eh eine Frage, und will nicht gleich nen neuen Thread aufmachen: Hab bis jetzt mit einem 80C517 udn Keil µVision (C-Compiler) programmiert. Da waren 10 kb locker mal erreicht, auch bei kleineren Programmen. Sind bei AVR's die Programme prinzipiell kleiner ? Weil es werden doch recht viele AVRs mit weit unter 10kb Flashangeboten... mit freundlichen Grüßen, Alexander
8051er mit Keil-Compiler ergeben im Allgemeinen kleinere Codegrößen als AVRs mit diversen Compilern.
Dein Hauptproblem sehe ich im IRDA-Stack. Wenn es echtes IRDA sein soll, dann ist das viel Aufwand. Und wenige mc können die IR-Transceiver direkt anschliessen, es gibt aber welche, deren UART können in einen IRDA-Mode geschaltet werden. Schau also erstmal nach diesen Punkten, alles andere kannst Du mit (fast) jedem mc erreichen. Zur CF-Karte: muss es diese sein oder geht auch eine andere (SD, MMC)? Die können teilweise seriell angesteuert werden, und sind vom Steckeraufwand genügsamer. Stefan
Wenn das so ist, wir dum den ATMega64 wohl eh kein weg herumführen. Der hätt im Gegensatz zum ATMega162 ja auch mehr RAM, was mir wieder einen externen Bauteil sparen würde.... Hmmm .... IrDa ein Problem? Ist es nicht so, dass man soclhe IrDA Module einfach an den UART des µC anschließt und fertig ? Die Wanldung auf IrDA nimmt dieses kleine Modul doch intern vor, oder?? Klar wenn ich einfach IR Diode und Trasnsitor dran hängen würd, müsst ich das selber berücksichtigen... Muss es nicht unbedingt, nein ! Es soll nur einige MB (Größenordnung: 15MB) möglichst billig und dauerthaft (auch "stromlos") speichern können. Und da kam mir als erstes eben CF in den Kopf, hab ein wenig im Internet gesucht und bin zum Schluß gekommen, dass CF lesen/schreiben relativ einfahc ist, auch vom Hardwareaufwand. Ansosten bin ich überhaupt nicht auf CF fixsiert... mit freundlichen Grüßen, Alexander
@Alexander: Vielleicht kann das Garmin-Modul mehr als 4800, aber normalerweise haben die bei NMEA 4800, und beim Garmin-Protokoll dann mehr. Das Garmin-Protokoll wie ich es kenne ist für mich aber nicht brauchbar, da es viel zuwenig Infos liefert, es fehlen glaub ich EPE und Satelliten-Signalstärke. Ich suche so ein Ding wie es im Navilock drinnen ist, nur halt billiger. Aber es wird eh dauern, bis ich dazu komme.
Also EPE ist ganz sicher dabei... ob die Sat.-Signastärke dabei ist weiß ich leider nicht ... Aber ich geb dir mel den Link zum DatenblatT http://www.garmin.at/Produkte/GPS15/GPS%2015HL%20Spec.pdf Ab Seite 13 feindest du die Übertragenen Daten + kurzer Erklärung Aber billig ist das Teil mit 113 echt nicht wirklich ;( mit freundlichen Grüßen, Alexander
@Alexander: Die normalen IrDA-Module wandeln nur das Infrarotsignal in etwas UART-taugliches um. Zu IrDA gehört aber auch ein Protokollstack und ohne den kannst Du mit dem PC nicht kommunizieren. Eine freie Implementation gibts hier: http://blaulogic.com/pico_irda.shtml , die brauchen aber schon einige KB an Programmspeicher. Markus
Mhmmm ... ich will IrDA nicht so verwenden, dass ich es zu nem IrDAPort vom PCleg und Windows erkennt sofort, dass dort was liegt bzw. was dort liegt udn will Daten gesendet bekommen, sondern ich will es sozusagen wie eine normale RS-232 Schnittstelle aber eben über Infrarot verwenden. Wenn ich das richtig verstanden habe bis jetzt, scheinen die IR Ports ja als normale COM Schnittstellen beim PC auf, also kann ich sie doch auch genau so auslesen, oder ?? Hab ich da etwas komplett falsch verstanden? mit freundlichen Grüßen, Alexander
Hmm... das geht glaub schon. Du mußt dann halt darauf achten, daß da keine sonstige IrDA-Software auf dem PC an der Schnittstelle rumspielt. Markus
aufatme ... dann ist's eh kein Problem! Vielen Dank für eure Hilfe!! mit freundlichen Grüßen, Alexander
Ich habe mal so ein IR-Modul drangehängt und ein eigenes Protokoll drauf laufen lassen. Das funktioniert (meistens) gut. Bei manchen Modulen gab es aber Probleme mit hoher Baudrate. Mit 9600 kommen sie alle klar, aber 115200 kann problematisch sein (das Modul muss umstellbar sein, und die Umstell-Möglichkeit muss dokumentiert sein ..) Auf der mc-Seite gibt es von Maxim ICs, die IR-Mode unterstützen. Sind aber nicht gerade billig. Bei einem extra Modul taucht das Problem wie oben auf: Baudratenumstellung. Zu Speicherkarten musst Du hier mal suchen, ich habe schon einige Links gefunden, die auf MMC/SD-Karten per AVR und SPI speichern, inkl. Open-Source-Software. Ist meiner Ansicht nach sowohl HW- als auch SW-seitig das Einfachste, vor Allem wenn Du kein Filesystem auf der Karte unterstützen musst. Wenn der Preis nicht so wichtig und Du noch nicht festgelegt bist, würde ich mir mal den Philips-ARM7 anschauen. 48 Pins, genug UARTS, RAM ohne Ende, On-Chip-Debugger. Habe ich (noch) keine Erfahrung damit, aber neugierig bin ich schon sehr, es dauert sicher nicht mehr lange, bis der mir auf den Tisch kommt ;-) Stefan
Hallo, sodalla - bin wieder da, und die Controller-Anvorderungen haben sich ein wenig geändert (MMC scheint echt praktischer zu sein als CF g): 2x U(S)ART 1x SPI 1x ADC (muss nicht sehr genau sein, aber Ref. Spannugn muss extern angelegt werden können) dafür wäre der ATMega162 ja ideal. Problem ist nur, dass 16kb Flash doch einwenig knapp werden könnten, oder? Also, Aufgaben sind: .) GPS-Modul ser. auslesen und ziemlich viele Zeichen (~300) zwischenspeichern (-> genügend RAM) .) diese dann verarbeiten (aus ASCII-BCD (also z.B. werden für 104 die ASCII-Zeichen "1", "0", "4") Werte errechnen) .) diese auf MMC Speichern .) Daten von MMC über UART (RS232/USB Konverter von FTDI) an den PC senden .) Batterie-Spannung messen Habe im Internet ein Projekt gefunden, welches ebenfalls mit einem ATMega eine GPS Maus ausliest. Und allein das Auslesen & Verarbeiten der GPS Daten verbraucht schon ~10kb. Also wird's mit 16 kb gesamt schon sehr knapp, was meint ihr ? Kann man den Flashspeicher eine ATMega162 extern erweitern? mfG Alexander
Hi 16kB reichen für deine Anwendung zumindest in C locker. Mit 5-6k solltest du da hinkommen. Vorrausgesetzt du verzichtest auf printf() und machst solche Dinge dann zu Fuß. Matthias
Wenn die Verbindung zum PC nur über USB und nicht auch noch wahlweise über RS232 gehen muß, dann könntest Du auch den FT245 nehmen, der braucht zwar mehr Pins, aber eben keinen UART. Damit könntest Du z.B. den Mega32 nehmen. Abgesehen davon gibts die ganzen USB-Chip nur als SMD und wenn Du schon USB hast, dann kannst Du auch den Mega64/128 nehmen. Erweitern kann man den Programmspeicher der AVRs übrigens grundsätzlich nicht. Man könnte zwar mit Interpretern auch Steuerungsanweisungen im Datenspeicher unterbringen, aber das will man normalerweise nicht. Wieviel Speicher Du brauchst hängt stark davon ab, was Du denn konkret machen willst: - Willst Du einfach nur den GPS-Datenstrom etwas verarbeiten (BCD nach Binär und so) oder willst Du auch noch Berechnungen mit Fließkommaarithmetik machen? - Willst Du alle NMEA-Datensätze verstehen können oder reicht eine kleine Auswahl? - Willst Du die MMC-Karte immer nur vom Microcontroller auslesen lassen oder wird die auch mal direkt an den PC angeschlossen (dann brauchst Du ein Filesystem)? Markus
Hoi ! MMC Karte: Filesystem brauch ich keines, die Karte bleibt fix im Gerät udn die Daten werden nur vom µC gelesen udn an den PC gesendet. Fließkomma wird schon auch gespeichert. Wie genau muss ich mri noch überlegen, Vor- und Nachkommerstellen können ja getrennt gespeichert werden. Speicherplatz hab ich bei 16 od. 32 MB MMC ja genügend. Alle NEMA Sätze werden nicht gelesen, deswegen auch di eSchätzung mti etwa 300 Zeichen .. der komplette Satz hat ja über 500. Muss ich mal genauer schaun welche Daten ich wirklich alle brauch, aber Projekt is ja noch in der Vorbereitungsphase ;) Verbindung zum PC: USB alleine würd reichen, aber die Kommunikation sollte möglichst einfach sein. Werd mir den FT245 mal genauer anschaun. SMD: Das ist eben mein "Problem". Also schlussendlich soll das ganez eh mit SMD aufgebaut werden, aber für Prototypen ist SMD doch recht umständlich ... aber stimmt eh, die USB Chips sind auch nru in SMD verfügbar, also ist es beim µC auch schon egal! mfG Alexander
@ Matthias: ich selbst kann das schwer einschätzen, aber 5 - 6 kb erscheinen mri doch recht wenig. Das ganze is doch einigermasen aufwendig, kannst dur ja mal den Source von so nem ähnlichen Projekt von Holgi's Elektronikseite anschaun: http://home.t-online.de/home/holger.klabunde/avr/gpsdisp.zip mfG Alexander
Hi Und? Das größte HEX-File das ich da gefunden habe hatte 3,5k (effektiver Programmcode. Größe HEX-File != Größe im Flash). Und beim diagonallesen ist mir zumindest an einer Stelle die unnötige Verwendung eines int statt eines unsigned char aufgefallen. Wenn das öfters vorkommt zieht das auch etwas an der Größe. Wenn du jetzt also für das Speichern und Auslesen der MMC nochmal 3k (Dürfte etwas viel sein. In 3k könnte man sogar das Schreiben in eine bestehende Datei implementieren) brauchst kommt meine Schätzung doch ganz gut hin. Dann hast du immer noch 10k Luft. Matthias
10kb HEX != 10kb im Flash??? - hab ich ja nicht gewusst =))) also, dass da einige konfigurationsbits (fusebits, ...) dabei sind war mir klar, aber das sind doch nur wenige byte, oder?? mfG Alexander
Hi
in einem HEX-File werden die einzelnen Bytes ASCII-kodiert was den
Umfang schonmal verdoppelt. Hinzu kommt dann in jeder Zeile ein ':',
2 Byte Länge, 4 Byte Adresse, 2 Byte Typ, 2 Byte Prüfsumme und der
Zeilenumbruch. In einer typischen Zeile mit 16 Nutzbyte kommst du so
auf
1(':') + 2(Länge) + 4(Adresse) + 2(Typ) + 32(Nutzdaten) +
2(Prüfsumme) + 1/2(Zeilenumbruch Unix/Windows) = (44/45)
Macht einen Faktor von etwa 2,8 von HEX-File zu Größe im Flash. Dieser
Faktor gilt natürlich nur bei Zeilenlängen von 16 Byte. Bei längeren
Zeilen wird dieser Faktor kleiner.
Matthias
Wenn's einem mal jemand sagt is es eigentlich eh einleuchtend - Danke =) Also würd der FlashSpeicher vom ATMega16x deiner Meinung nach vollkommen ausreichen, für meine Zwecke + genügend Restplatz? Welche Tipps gibt es noch, um den kompilierten Code klein zu halten ... also außer "printf" zu vermeiden? mfG Alexander
Keine Fließkommazahlen (single, float) verwenden. Denn dadurch wird oft die gesamte Fließkommalib eingebunden. Bei Bascom macht das z.B. 1,5KB aus. Markus
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.