Hallo uC-Gemeinde, ich schiebe nun schon seit ca. 2 Jahren eine Projektidee vor mir her. Mittlerweile bin glaube ich mit den theoretischen Grundlagen soweit, dass ich mich Schritt für Schritt an die Umsetzung wagen kann. Mein Problem ist allerdings, das ich nicht abschätzen kann, welche Rechenleistung im Endeffekt benötigt wird. Auf der einen Seite möchte verhindern, das ich ab einem gewissen Punkt bei der Softwareentwicklung merke, dass die Rechenleistung nicht mehr ausreicht und dann wieder viel Geld in eine neue Platine und Bauteile gesteckt werden muss. Dies könnte man natürlich verhindern, indem man einfach völlig überdimensioniert dran geht. (z.B. mit ARM Cortex-A__ Chips im BGA-Gehäuse) Aber auf der anderen Seite möchte ich die Bauteile auch noch selbst auf die Platine bringen können, also lieber QFP statt BGA. Nun zu meiner Idee: Es geht im Grunde um ein portables Outdoor-Gerät mit GPS und einer ganzen Menge zusätzlicher Sensoren. Grobe Eckdaten: Farb-Display ca. 240*320 mit Display-Controller (u.U. mit Touch) SD-Card (SDHC) USB (Slave-Funktionalität reicht aus, Host/OTG ist nicht notwendig) Sensoren (Temp., Luftfeuchte, Beschleunigung, Gyro, ...) Für GPS werde ich mich wohl aus der uBlox-Familie bedienen, für das Kartenmaterial gibt es eine ganze Menge Ressourcen die auf den Openstreetmap Daten basieren und perfekt für meine Anwendung passen würden. Aus meiner Sicht wird die meiste Rechenleistung für die Darstellung des Kartenmaterials auf dem Display und die Positionsauswertung mit den Beschleunigungs-/Gyro-Sensoren benötigt und vermutlich die Datenschaufelei mit der SDHC-Card. Bisher war meine Idee, einen Controller mit Cortex-M3 Kern zu verwenden, die sollten für mich noch gut zu verarbeiten sein und die gibt es bis 120MHz auch noch in LQFP (LPC.., STM32..). Bin ich damit gut aufgestellt oder sollte ich lieber auf Prozessormodule wie z.B. das "Micro2440 Stamp Module" (ARM9) von FriendlyARM ausweichen? Eine weitere Idee war auch noch, das ich einen Teil der Sensoren wie Temp., Luftfeuchte, Luftdruck, ... z.B. durch einen MSP430 auswerten lasse und dann zur Anzeige und Speicherung an den Cortex-M3 schicke. Ist das sinnvoll oder überhaupt notwendig? Oder doch einen ganz anderen uC bzw. Kombination von ICs? Ich hoffe ihr könnt mir ein paar Tipps geben, auch Kritik nehme ich gerne an. Viele Grüße Johannes Das das kein Wochenend-Projekt wird, ist mir bewusst ;-) Dafür habe ich auch schon zu viele Stunden/Tage und Papier damit gefüllt.
Ich wuerd mal einen Display mit Controller und touch empfehlen. danzu brauchts dann nur noch das GPS. http://www.mikroe.com/eng/products/view/595/mikrommb-for-pic32-board/ Da ist die Haelfte schon gemacht.
Johannes M. schrieb: > Mittlerweile bin glaube ich mit den theoretischen Grundlagen soweit, > dass ich mich Schritt für Schritt an die Umsetzung wagen kann. > Mein Problem ist allerdings, das ich nicht abschätzen kann, welche > Rechenleistung im Endeffekt benötigt wird. Fang doch einfach mal an einen Teil der Aufgaben zu realisieren. Und wenn du merkst, dass der Controller nicht passt, dann wechselt du den einfach aus... Ich würde dir allerdings zu einem ARM uC raten... Such mal bei EBAY nach STM32*
Elektor hat ein Projekt mit Propeller gemacht...
Vielen Dank schon für die Antworten, anhand der Antworten merke ich, das ich noch ein paar Details/Anforderungen unterschlagen habe ;-) Max D. schrieb: > Elektor hat ein Projekt mit Propeller gemacht... Der Propeller klingt wirklich interessant, aber dann fange ich fast wieder bei 0 an (andere Architektur, C Compiler kostet extra,...) Oktal Oschi schrieb: > Ich wuerd mal einen Display mit Controller und touch empfehlen. danzu > brauchts dann nur noch das GPS. > > http://www.mikroe.com/eng/products/view/595/mikrom... > > Da ist die Haelfte schon gemacht. Das sieht schon ganz gut aus, werde ich mir mal genauer durchlesen. Das Display kommt mir ein bischen klein vor, so 3,2" oder 3,5" möchte ich in meinem Gerät einbauen, aber das sollte man auch gut austauschen können. Lothar Miller schrieb: > Fang doch einfach mal an einen Teil der Aufgaben zu realisieren. Und > wenn du merkst, dass der Controller nicht passt, dann wechselt du den > einfach aus... > > Ich würde dir allerdings zu einem ARM uC raten... > Such mal bei EBAY nach STM32* Einfach anfangen wäre doch zu einfach ;-) nene, hast schon recht. Um Ebay habe ich bislang immer einen großen Bogen gemacht, das kommt mir immer etwas dubios vor. Die STM32 Dev-Boards sind aber erstaunlich günstig und wenn man den "Verkaufsvideos" trauen kann auch mit flotter Bildverarbeitung ausgestattet. Bei 40€ inkl. Display kann man ja kaum noch was falsch machen, kommen die Sachen aus Hongkong/China auch wirklich in Deutschland an? ;-)
Johannes M. schrieb: > Grobe Eckdaten: > Farb-Display ca. 240*320 mit Display-Controller (u.U. mit Touch) Da musst Du wissen: Die mit eingebautem Grafikcontroller und Speicher sind nicht sehr schnell, dafür einfach anzusteuern. Die Größe ist auf 240*320 und etwa 3.2" beschränkt, darüber gibt es nichts dergleichen. Die Teile ohne Controller brauchen eine entsprechende Einheit im Prozessor. Das schränkt die Auswahl ganz erheblich ein (an lötbaren Alternativen fällt mir jetzt nur der NXP LPC2478 und der Cortex M3 Nachfolger LPC1788 (ist der überhaupt schon lieferbar?) ein, alles andere ist BGA), aber der Bildspeicher liegt dann direkt im Adressraum des Prozessors, was zu einer deutlich schnelleren Bildschirmdarstellung führt. > Kartenmaterials auf dem Display und die Positionsauswertung mit den > Beschleunigungs-/Gyro-Sensoren benötigt und vermutlich die Positionsauswertung mit Beschleunigungs-/Gyro-Sensoren? Äh, nee, so genau sind die nicht, als dass Du das für eine einigermaßen genaue Indoor-Ortung verwenden könntest. Zumindest nicht die billigen. Oder hast DU das schon mal wirklich ausprobiert? Mach mal, das interessiert mich jetzt. > Bisher war meine Idee, einen Controller mit Cortex-M3 Kern zu verwenden, > die sollten für mich noch gut zu verarbeiten sein und die gibt es bis > 120MHz auch noch in LQFP (LPC.., STM32..). > Bin ich damit gut aufgestellt oder sollte ich lieber auf Prozessormodule > wie z.B. das "Micro2440 Stamp Module" (ARM9) von FriendlyARM ausweichen? Wie gesagt - überlege Dir was mit Deinem Display. > Eine weitere Idee war auch noch, das ich einen Teil der Sensoren wie > Temp., Luftfeuchte, Luftdruck, ... z.B. durch einen MSP430 auswerten > lasse und dann zur Anzeige und Speicherung an den Cortex-M3 schicke. Ist > das sinnvoll oder überhaupt notwendig? Es könnte sinnvoll sein, die gesamte Sensorik inkl GPS und Logging auf den MSP430 zu verlegen, um den Display- und Kartenprozessor zwecks Energieeinsparung komplett abzuschalten. Das hängt dann aber von den Nutzungsszenarien ab, wie das Gerät später verwendet werden soll. Mache Dir möglichst frühzeitig auch noch Gedanken über Deine Stromversorgung und wie Du zB einen LiPo-Akku zu laden gedenkst, ohne dass er Dir abfackelt.
Frank K. schrieb: > Die mit eingebautem Grafikcontroller und Speicher sind nicht sehr > schnell, dafür einfach anzusteuern. Die Größe ist auf 240*320 und etwa > 3.2" beschränkt, darüber gibt es nichts dergleichen. Danke für deine Antworten, was muß ich mir unter nicht sehr schnell vorstellen? ;) (Vorsicht Milchmädchenrechnung) Wenn ich mir anschaue, dass die meisten GPS-Module ihre Daten mit 1-5 Hz ausgeben, würde es dann nicht ausreichen wenn ich die neuen Bildschirmbilder mit ~5-10 Hz erzeuge? Frank K. schrieb: > Die Teile ohne Controller brauchen eine entsprechende Einheit im > Prozessor. Das schränkt die Auswahl ganz erheblich ein (an lötbaren > Alternativen fällt mir jetzt nur der NXP LPC2478 und der Cortex M3 > Nachfolger LPC1788 (ist der überhaupt schon lieferbar?) ein, alles > andere ist BGA), aber der Bildspeicher liegt dann direkt im Adressraum > des Prozessors, was zu einer deutlich schnelleren > Bildschirmdarstellung führt. LPC2478 werde ich mir auch mal anschauen (LQFP-208, da gibts viele Möglichkeiten für Lötbrücken ;-) ). Die LPC17xx sind bei NXP noch alle als "in Development" markiert. Frank K. schrieb: > Positionsauswertung mit Beschleunigungs-/Gyro-Sensoren? Äh, nee, so > genau sind die nicht, als dass Du das für eine einigermaßen genaue > Indoor-Ortung verwenden könntest. Zumindest nicht die billigen. > > Oder hast DU das schon mal wirklich ausprobiert? Mach mal, das > interessiert mich jetzt. Da habe ich mich wieder etwas ungenau ausgedrückt, in erster Linie möchte ich Steigung, Himmelsrichtung, Erschütterungen messen. Wie weit man das noch auf die Positionsbestimmung ausweiten kann muß ich einfach mal ausprobieren, ich werde dann berichten. Frank K. schrieb: > Es könnte sinnvoll sein, die gesamte Sensorik inkl GPS und Logging auf > den MSP430 zu verlegen, um den Display- und Kartenprozessor zwecks > Energieeinsparung komplett abzuschalten. Das hängt dann aber von den > Nutzungsszenarien ab, wie das Gerät später verwendet werden soll. Das ist wahrscheinlich auch der sinnvollste Einstieg in das Projekt, erstmal die Sensoren in Gang bringen und dann mache ich mir über das Display und dessen Ansteuerung Gedanken. Frank K. schrieb: > Mache Dir möglichst frühzeitig auch noch Gedanken über Deine > Stromversorgung und wie Du zB einen LiPo-Akku zu laden gedenkst, ohne > dass er Dir abfackelt. Danke für den Hinweis, da sehe ich im Moment aber die wenigsten Probleme. Seit ca. 2 Jahren habe ich ein Gerät mit NCP1800DM41R2 und einem LiPo-Akku in Betrieb (wird über USB-Anschluss geladen), bisher keine Probleme. Gruß Johannes
Johannes M. schrieb: > GPS-Module ihre Daten mit 1-5 Hz ausgeben, würde es dann nicht > ausreichen wenn ich die neuen Bildschirmbilder mit ~5-10 Hz erzeuge? Mein Navi macht das sogar noch viel langsamer: es wird bei kleinen Positionsänderungen nur der Pfeil in der Mitte neu gezeichnet...
Johannes M. schrieb: > Danke für deine Antworten, was muß ich mir unter nicht sehr schnell > vorstellen? ;) > (Vorsicht Milchmädchenrechnung) Wenn ich mir anschaue, dass die meisten > GPS-Module ihre Daten mit 1-5 Hz ausgeben, würde es dann nicht > ausreichen wenn ich die neuen Bildschirmbilder mit ~5-10 Hz erzeuge? Das kommt auf die Art des Zugriffs an. Bei den üblichen Displays mit Controller (z.B. ILI9325) läuft das so ab: - Fenster X/Y Position setzen - Fenster Höhe/Breite setzen - Schreibrichtung setzen (von links nach rechts oder von oben nach unten etc) - RGB-Daten für das Fenster senden Wenn Du großflächige Bitmaps ans Display sendest, ist das noch recht effizient, weil Du ja nur einmal das Fenster mit der Bildregion setzen musst und dann einfach nur noch Grafikdaten reintakten musst. Wenn Du aber beispielsweise eine Linie zeichnen willst und dafür einzelne Pixel setzen musst, dann wird das ganze extrem ineffizient und damit langsam, weil Du für jedes Pixel wieder einen neuen Datentransfer aufsetzen musst, mit Fenster setzen usw. Du hast eben nur einen sehr indirekten Zugriff auf den Grafikspeicher. Bei Displays ohne Controller liegt der Grafikspeicher im Adressraum des Prozessors. Da ist das Setzen eines Pixels nur ein einziger Speicherzugriff. Es hängt eben davon ab, was genau dargestellt werden soll. Eine Kartendarstellung mit Linien, Kurven, Flächenfüllen ist ein ganz anderer Fall als Textausgabe oder das Anzeigen von Fotos. > LPC2478 werde ich mir auch mal anschauen (LQFP-208, da gibts viele > Möglichkeiten für Lötbrücken ;-) ). Du hast nach dem Spaßfaktor gefragt, hier hast Du ihn. fchk
Gute Erklärung, da muß ich mir mal Gedanken drüber machen was ich da alles einzeigen möchte. Ein weiterer Punkt für meine ToDo Liste. Beim Lesen in den Datenblättern ist mir der FSMC beim STM32 aufgefallen, damit könnte man den Flaschenhals etwas entschärfen, wenn ich das richtig verstanden habe.
Johannes M. schrieb: > Gute Erklärung, da muß ich mir mal Gedanken drüber machen was ich da > alles einzeigen möchte. Ein weiterer Punkt für meine ToDo Liste. > Beim Lesen in den Datenblättern ist mir der FSMC beim STM32 aufgefallen, > damit könnte man den Flaschenhals etwas entschärfen, wenn ich das > richtig verstanden habe. Wobei? Beim Schreiben auf TFTs mit diesen ILI93xx/HX83xx-Controllern? Negertief. Über das Prozessorinterface dieser Displays hast Du nur Zugriff auf die etwa 100 bis 200 Steuerregister des Controllers, und auch das nur mit indirekter Adressierung (Indexregister/Datenregister), also quasi doppelt indirekt. Mehr nicht. Egal wie auch immer Du es wendest, Du hast bei diesen Displays niemals direkten Speicherzugriff. fchk
Hab mir mal all die diversen Antworten durchgelesen und komme zu dem Schluß, daß du dieses Projekt am besten ganz anders angehen solltest: 1. Nimm lieber kein Display mit irgendeinem integrierten Controller. Da kriegst du die Krätze, weil du zum Schluß ja doch alles in einem separaten RAM aufbereiten und dann en bloc zum Display hinschaufeln mußt. Ich weiß das, weil einer meiner Kollegen genau mit SOWAS sich herumschlägt und laut genug dabei flucht. 2. Displays mit 480x272 Pixeln bekommt man bei ebay schon relativ günstig, so um die 20 Euro. Diese Größe ist derzeit das Optimum, wenn man Ansehnlichkeit und technischen Aufwand mal betrachtet. Wenn du ne Verbindung zu Glyn hast, dann besorge dir sowas von denen, die haben für ihre Displays eine vereinheitlichte Schnittstelle (Folienkabel 40 polig, 0.5 Pitch) geschaffen. 3. Für controllerlose Displays brauchst du nen Displaycontroller, den man sich ohne viel Aufwand aus einem CPLD machen kann. Ein Xilinx 95144.. reicht dafür definitiv, mit einem Coolrunner mit 128 Makrozellen kommst du gerade so auch aus. Dazu brauchst du nen schnellen RAM 256x16x10ns als Bildspeicher, den es von Samsung, ISSI und anderen gibt. Das hat den RIESENVORTEIL, daß du damit den Systembus nicht belastest und der Prozessor mit voller Speed laufen kann. Bei dem LPC2478 wird nämlich der Systembus zum Flaschenhals und die CPU wartet sich halbtot. 4. Wenn du den Bildspeicher im Adreßvolumen liegen hast, dann wirst du für sonstige Zwecke (Sektoren der SD puffern usw.) wohl mit 1 MB RAM auskommen. sieh zu, daß du dir einen Controller mit 32 Bit breit herausgeführtem Systembus aussuchst und den RAM z.B. 4x 256x8 oder 2x 512x16 machst. Mit dem LPC2214 kann man das schon, allerdings hat der kein dediziertes SD-Interface. Ist nicht SOOO schlimm, wenn man die häufig benötigten Sektoren im RAM zwischenpuffern kann. Das hängt aber sehr von dem verwendeten Filesystem ab. Das einzige, was ich auf dieser CPU zum passablen Laufen bekommen hab ist die EFSL mit einigen Modifikationen von mir. 5. Hast du schon Vorstellungen zu dem Karten-System? Wahrscheinlich ist es dir zuviel, ein Vektor-Kartensystem zu implementieren, denn dazu müßte man erhebliche Vorarbeit in das Zerpflücken des Planet-Files von OSM stecken - und Vektorkarten sind eine recht große Herausforderung, die nach einer CPU mit Gleitkommaprozessor schreit. Einfacher geht es mit Bitmap-orientierten Karten wie z.B. Google-maps oder eben den 256x256 Tiles, die man von OSM, Yahoo, MSN usw. laden kann. Blöderweise liegen diese jedoch als .PNG oder .JPG vor, was dann einen erheblichen Dekodierungsaufwand und RAM-Bedarf nach sich zieht. Soll mit keiner sagen, daß die ZLib auf nem uC problemlos ist. Ich habe deswegen auch schon mal mir was ausgedacht, das sich folgendermaßen kurz beschreiben läßt: Tiles mit 256x256 Pixeln, mit 48 Farben, auf einfache Weise gepackt, alle Tiles einer Zoomstufe zu einer bestimmten Region in 1 Levelfile gepackt, leicht, schnell und ohne großen RAM-Bedarf entpackbar. Vorarbeiten meinerseits gibt es bereits, einen Map-Viewer dafür für Windows gibt es auch schon, die Implementierung auf einem uC steht aber noch aus. Quellen und Definitionen gibt's bei Bedarf und Nachfrage. 6. Ob DRAM oder SDRAM was Geeignetes für ein Bastelprojekt ist, bei dem einen jede Layoutänderung im Geldbeutel weh tut, wage ich zu bezweifeln. Also besser erstmal versuchen, passenden statischen RAM zu besorgen. Ach ja, das Pinout sowohl beim LPC2478 als auch bei den dickeren STM32 ist alles andere als begeisternd. Schau dir das genau an bevor du dich auf einen bestimmten Chip stürzt. Ich hab da ggf. was zum Posten: ein Board mit LPC2214, eins mit LPC2478 und eins mit STM32xxxx W.S.
Hi Nur in SW: Beitrag "Re: Zeigt her Eure Kunstwerke !" >Wenn Du aber beispielsweise eine Linie zeichnen willst und dafür >einzelne Pixel setzen musst, dann wird das ganze extrem ineffizient und >damit langsam, weil Du für jedes Pixel wieder einen neuen Datentransfer >aufsetzen musst, mit Fenster setzen usw. Du hast eben nur einen sehr >indirekten Zugriff auf den Grafikspeicher. Wenn ich dann solche Aussagen für den anvisierten Controllern lese muss ich echt an der Qualifikation der Poster zweifeln. Das Programm zum obigen Link ist 4k gross. MfG Spess
Danke W.S. für deinen Beitrag, da muß ich erstmal ausgiebig drüber nachdenken. Gut das ich hier mein Projekt frühzeitig zur Diskussion gestellt habe und nicht einfach drauflos "gebastelt" habe. Jetzt wird aber erstmal am Kopfkissen gehorcht und morgen wieder in die Hochschule. Gute Nacht Johannes
@ spess53 Wow, cool! Wie hast du das mit dem Kartenmaterial gemacht?
Hi
>Wow, cool! Wie hast du das mit dem Kartenmaterial gemacht?
Steht weiter unten.
MfG Spess
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.