mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 8051 oder ARM7


Autor: fragensteller (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:
> Der AVR ist doch deutlich komplexer, vor allem die Interruptlogik ist

Muß natürlich heißen: ARM


Peter

Autor: fragensteller (Gast)
Datum:

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

Autor: Profibauer (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Profibauer (Gast)
Datum:

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

Autor: fragensteller (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: fragensteller (Gast)
Datum:

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

Autor: fragensteller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wie kommst du auf 48Byte?

2 AD mit je 8 Kanälen = 16 Kanäle
16 Kanäle je 16Bit = 256Byte

Autor: arc (Gast)
Datum:

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

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.