mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik richtige µController-Wahl ?!?!?!?


Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?...
selbst herausfinden können.

Matthias

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahh, vielen Dank !

Hab die Tabelle leider nicht gefunden gehabt ...

mit freundlichen Grüßen,
Alexander

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
8051er mit Keil-Compiler ergeben im Allgemeinen kleinere Codegrößen als
AVRs mit diversen Compilern.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aufatme ... dann ist's eh kein Problem!

Vielen Dank für eure Hilfe!!

mit freundlichen Grüßen,
Alexander

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.