Hallo, ich stehe vor der Frage ob ich für ein Projekt lieber einen 8051 nehme oder einen ARM7 (oder evtl. sogar eine ganz andere CPU) Ich muss über zwei oder drei externe Wandler (SPI, je 8 Kanäle, 13Bit = signed + 12Bit) Messwerte erfassen. Laut Wunsch je schneller desto besser (also min. 5kHz / Kanal). Das würden dann rund 240KB/Sek. ergeben (pro Kanal 16Bit). Wenn es noch schneller geht umso besser :) Über 10kHz ist aber quatsch. Für ein kleines Display, evtl. Kommunikation mit PC brauche ich auch noch was Rechenleistung. Das System soll später evtl. auch um Kanäle erweitert werden (z.B. noch ein AD). Gespeichert werden soll das ganze auf eine MMC/SD oder CompactFlash Karte. Da eine CF zumindest theoretisch durch das parallel-Interface Vorteile hat werde ich wohl darauf zurückgreifen. Nun weis ich nicht welchen µC ich dafür nutzen soll. Viel gearbeitet habe ich bislang mit den 8051 von Silabs (F120, 100MHz, 100MIPS) wobei diese effektiv im durchschnitt 2 Takte / Befehl brauchen also rund 50MIPS. Als Alternative habe ich einen ARM7 erdacht. Doch weis ich nicht, ob ein 55MHz ARM7 (Atmel) wirklich schneller ist. Hab irgendwo gelesen, das ein ARM7 1.9 Takte / Befehl braucht, das wären damit ja rund 27MIPS. Vorteil wäre aber klar der 32Bit Bus, damit kann ich ein 16Bit Word in einem Befehl übertragen während der 8051 dafür Krämpfe erleiden muss ;) Nun zu den Fragen : 1. ARM7 oder 8051? Hat der ARM7 in dem Fall ein ordentlichen Performance Vorteil? Welcher ARM7 ist evtl. besser dafür geeignet? 2. ES gibt ja jetzt von ATMEL die AT91SAM7SE512 ARM7 mit Businterface für CompactFlash. Würden die mir den Datentransfer nicht erheblich beschleunigen im Gegensatz zu Portpins oder nomalem EMI? 3. Evtl. gar ein komplett anderer µC (z.B. NXP ARM7/ARM9 oder AT91RM9200 ARM9 180MHz) 4. Irgendjemand sonst noch ein paar Tipps? :) Ich programmiere übrigens in C (Keil), 8051 auch etwas in ASM, aber aufgrund der Pflegbarkeit lieber in C. Vielen Dank !
Die Aufgabe klingt nicht so, als ob da viel zu tun ist. Wenn Du schon 8051 Erfahrung hast, würde ich dabei bleiben. Der AVR ist doch deutlich komplexer, vor allem die Interruptlogik ist etwas haarig (spurious interrupts, surprise interrupts). Und für das Karteninterface sind die direkten Bitbefehle des 8051 ganz praktisch und schön schnell. Der ARM muß alles erst in seine Register laden, direkte Operationen auf den IOs hatter nich. Peter
Peter Dannegger wrote: > Der AVR ist doch deutlich komplexer, vor allem die Interruptlogik ist Muß natürlich heißen: ARM Peter
Hmm .. die komplexität ist schon klar. Aber ist ein 8051 wirklich schneller wie ein ARM7 mit CompactFlash Interface? Es muss ja nicht nur gespeichert werden (FAT32) sondern auch 8 Messwerte angezeigt werden (umgerechnet) und per UART Daten verschickt werden (ca. 100x pro Sekunde). Ich hätte bei 100MHz (also 98MHz, 100MHz gehen mit internem Quarz nicht) nur rund 400 Takte / Byte bei 240KB/Sek. Klingt viel, aber Daten einsammeln über SPI, FAT verwaltung, UART, Display etc. Bin immer davon ausgegangen das dafür die ARM7 mit DMA und EMI wesentliche Vorteile haben bei sowas.. oder hab ich grade einen Knoten im Kleinhirn? :)
Wenn schon nicht klar ist, ob zwei oder drei ADCs anzuschließen sind, würde ich Leistungsreserven einbauen. Beispielsweise könnte je ein µP einen ADC bedienen. Das schafft ein normaler 8051 locker. Bei der weiteren Verarbeitung ist zu beachten, wieweit die Daten 'zusammenhängend' bearbeitet werden müssen. 240KB/s sind nicht wenig und wenn zum Beispiel größere Datenblöcke im RAM gehalten werden müssen, hat der 8051 auf Grund seines beschränkten Adressraumes/Zugriffszeiten eher schlechte Karten. Ein µP, der die Daten per DMA umschaufeln kann, hätte hier Vorteile. Ein ARM9 erscheint mir aber zu dicke. Wenn Du völlig frei in der Entscheidung bist, kannst Du auch andere µPs ins Auge fassen: Renesas, Infineon, Freescale, ... Es gibt so viele. Wichtig bei Stückzahlen wäre auch der Preis. Für ein Einzelstück reicht wahrscheinlich ein Entwicklungskit.
fragensteller wrote: > Hmm .. die komplexität ist schon klar. Aber ist ein 8051 wirklich > schneller wie ein ARM7 mit CompactFlash Interface? Es muss ja nicht nur > gespeichert werden (FAT32) sondern auch 8 Messwerte angezeigt werden > (umgerechnet) und per UART Daten verschickt werden (ca. 100x pro > Sekunde). Das sind dann also 1000.000 Zyklen (@100MHz) für das UART-Senden, sollte doch reichen. Und für die Anzeige hast Du noch mehr Zeit, mehr als 2..5 Meßwerte / Sekunde ist Unsinn, kann kein Mensch ablesen. Das mit der FAT könnte vielleicht etwas aufwendig sein, habs noch nicht probiert. Ich würde einfach auf dem PC eine unfragmentierte Dummy-Datei anlegen mit der maximalen Größe und einem Magic (16Byte) am Anfang. Und dann auf dem MC sucht man dieses Magic und schreibt einfach an dessen Stelle die Daten hintereinander weg. Und hinter den letzten Datensatz schreibt man noch das Magic, damit man beim nächsten Anschalten weiß, wo man weiter machen muß. Auf dem PC ließt man dann die Datei bis zum Magic aus und schreibt dann das Magic wieder direkt an den Anfang. Man braucht ja eh auf dem PC ein eigenes Programm, um die Daten zu interpretieren. Peter
>also min. 5kHz / Kanal
Das hatte ich übersehen und war von 5000 Abtastungen/s je ADC
ausgegangen. Serielle Datenübertragung kann dabei schnell zum
Flaschenhals werden.
Sinnvoll wären vielleicht ADCs mit paralleler Schnittstelle, die 'memory
mapped' eingelesen werden.
Jein, die Daten sollen auf der CF eigentlich so angeordnet sein, das je Messung eine Datei angelegt wird, mit Datum/Uhrzeit im Attribut. Daher ist ein komplettes FAT schon wichtig. Evtl.sollen später auchmal direkt CSV Dateien angelegt werden, deshalb etwas reserve nach oben... Ich stelle mir auch die Frage ob es nicht eher sinn macht, das Programm einfacher zu gestalten (durch DMA, direkt Interface an CF oder MMC, 16Bit SPI). Klar ist die Konfiguration etwas umständlicher, aber im Endeffekt wird doch das Programm einfacher und schneller. Laut diesem Test http://www.freertos.org/PC/index.html ist das Memory Copy und Compare(fraglich wieviel Compare-Zeit verbraucht wurde) bei NXP ARM7@60MHz faktor 5 schneller wie Silabs F120@100MHz. Das ist schon ne Menge. Nicht das ich unbedingt ein ARM nutzen möchte, nur will ich sichergehen, nachher nicht ein komplettes Redesign machen zu müssen nur weil ein AD dazukommt oder 10kHz .. Preislich ist der ARM7 (AT91SAM7SE512) sogar etwas billiger. Bislang bin ich eher der Meinung ein ARM7 ist besser geeignet.
fragensteller wrote: > Jein, die Daten sollen auf der CF eigentlich so angeordnet sein, das je > Messung eine Datei angelegt wird, mit Datum/Uhrzeit im Attribut. Daher > ist ein komplettes FAT schon wichtig. Evtl.sollen später auchmal direkt > CSV Dateien angelegt werden, deshalb etwas reserve nach oben... Welchen Sinn soll das machen, für 48 Byte an Daten, ein komplettes Cluster von mindestens 2048 Byte zu verschwenden ? Und wenn Du dann noch Programme nutzen willst, die ein bestimmtes Datenbankformat generieren, solltest Du besser gleich nen PDA nehmen. Diese Formate sind im allgemeinen recht komplex und nicht dafür gedacht, in Echtzeit mit beschränkten Ressourcen erstellt zu werden. Das sieht alles so aus, wie mit Kanonen auf Spatzen zu schießen. Nicht nur Ressourcen wirst Du verschwenden, sondern auch sehr viel Entwicklungszeit (Mannjahre könnte hinhauen). Peter
48Byte an Daten in 2048Byte Cluster? Das musst du mir jetzt erklären... Gerät wird angeschaltet, legt File an und misst. ALLE gemessenen Daten werden in der Datei gespeichert (die dann pro Sekunde ca. 250KB groß wird). Irgendwann wird das Gerät ausgeschaltet. Bei einem neuen einschaltet wird dann ein neues File angelegt und darin wieder Daten gespeichert. Im FAT gibt es sowas wie Attribute. Damit kann ich später sehen wann welche Datei erstellt worden ist. Sowas nennt man dann auch Datenaufzeichnung. Bei 5kHz/Kanal und min. 16 Kanälen musst du schnell ein/ausschalten um 48Byte/File zu schaffen.. Welchen Sinn soll es machen für jeden Messwert eine eigene Datei anzulegen? Hab ich das irgendwann so gerieben? 5000 Dateien pro Sekunde.. witzig! Und das direkt in eine CSV zu schreiben macht eigentlich auch sinn, ist aber erstmal nicht notwendig. Damit könnte man z.B. direkt Programme wie Excel oder Diadem nutzen.
Und wie kommst du auf 48Byte? 2 AD mit je 8 Kanälen = 16 Kanäle 16 Kanäle je 16Bit = 256Byte
Falls möglich würde ich mir die AN282 von SiLabs (USB MSD mit CompactFlash und SDCard-Anbindung) ansehen/testen, um zu sehen, ob nach Karten/Dateisystemhandling noch genügend Rechenleistung übrig bleibt. Andere Ideen: - Externer Multiplexer + die integrierten 16-Bit Wandler des C8051F06x mit DMA (allerdings kein gleichzeitiger Zugriff von CPU und DMA auf externes XRAM) - dsPIC30/33 oder eCOG1X wenn's kein ARM sein soll
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.