Diskussion:Mikrocontroller Vergleich

Auch hier sollte man den urspruenglichen Author noch fragen, ob er mit einer Veroeffentlichung hier im Wiki, d.h. dann auch mit den Lizenzbedingungen, einverstanden ist...

Bin einverstanden - A.K.

Vergleich der Grenzwerte

Hallo!

Was mich noch interessieren würde, wären ein Vergleich der Grenzwerte der AVR-, Pic- und 8051er Modelle. Also Programmspeichergrößen, E²PROM-Größen, RAM-Größen, MIPS und MHz. Suche schon seit einiger Zeit nach diesen Informationen, kann sie aber nirgends finden. Vielleicht könntet ihr/du mir weiterhelfen.

Danke im Vorraus,

mit freundlichen Grüßen Tom

Der Abschnitt zur Skalierbarkeit könnte schon etwas mehr Details vertragen. Allein - mir fehlt da die Übersicht, besonders bei den i51ern mit beliebig vielen Herstellern. MIPS/MHz zu vergleichen ist arg problematisch und konfliktträchtig, Vorsicht dabei - schon mit meinen knappen Kommentaren zur C-Eignung bin ich offenbar einem PIC-Freund sehr auf die Nerven gegangen.

Letztlich helfen aber meist nur die parametrischen Suchseiten vom Hersteller. Und wenn es i51-er mit 0,5MB Flash geben mag, heisst das nicht, dass man für Neu-Projekte darauf setzen sollte. Darum meine Bemerkung, jenseits von natürlichen Grenzen (bei 8bittern 40-60KB oder notfalls KW Flash) den hier betrachteten Sektor zu verlassen.

A.K.

---

Hi! Als interessierter Neuling würde mich bei so einem Vergleich auch den Aufwand der Grundbeschaltung interessieren. Was wird ausser dem Controller benötigt? Kosten der Entwicklerboards, günstige Alternativen? MGF jan

Sehr gute Fragen, deren erschöpfende Antwort nicht so einfach ist. Bei Dingen, die man noch benötigt, fallen einem schnell Programmer ein und da werden Antworten gerade bei der Vielfalt der 8051'er schnell diffus :) Nichtsdestotrotz können wir ja versuchen, dazu noch was einzubauen. Wegen Devkits kann man schon mal auf die vorhandenen Artikel verweisen. --Yahp 22:08, 1. Jul 2005 (CEST)

Die geänderte Sortierung bitte nicht wertend verstehen oder als Angriff nehmen :-) Ich bin der Meinung, dass eine gleichartige Sortierung in den einzelnen Abschnitten dem Erfassen der relevanten Informationen nur zuträglich ist. Alles in allem schreien diese Infos natürlich nach tabellarischer Darstellung, aber das wäre ein Monster von Tabelle... --Yahp 22:36, 1. Jul 2005 (CEST)

Übersichtlichkeit

Hallo, ich finde, dass der Artikel mit zunehmender Zahl an Codebeispielen einzelner Architekturen an abnehmender Übersichtlichkeit zu leiden beginnt. Je komplexer und weiter ausholend das Ganze ist, desto weniger wird der Einsteiger daraus entnehmen können... --Yahp 01:18, 11. Jul 2005 (CEST)

Ich habe mier erlaubt, für die weitere Diskussion im Forum einen Thread zu eröffnen: Diskussion:Mikrocontroller Vergleich Ich hoffe, das ist OK so. -- Torsten c 22:49, 28. Mai 2013 (UTC)

Anmerkungen

Ein paar kleine Anmerkungen:

• Compilerverfuegbarkeit: Das der gcc fuer AVR und msp gut handhabbar ist, liegt an der Verfuegbarkeit fertiger Linker-Skripts und Startup-Codes und nicht aussschliesslich "am gcc". Hat man "vorgekaute" Linker-Skripte und Startup-Code fuer gcc/gas/ld und den betreffenden ARM-Controller, ist fuer Standardanwendungen auch keine "Handarbeit" mehr noetig. IAR auch keine gute Empfehlung, falls die Kickstart-Version nicht mehr ausreicht, da Anwendung und interne Einstellung sehr firmenspezifisch. Meiner Meinung bessere Alternative wenn schon kommerzieller Compiler: Keil Testversion. Auf 16kB beschraenkt bei Keil-eigenem Compiler, unbeschraenkt (ausser Debugger/Simulator) mit gcc-Toolchain von Keil. Bei spaeterem Umstieg auf "gnu-only" kann man viel des Gelernten mitnehmen.

• Architektur: ARM: Thumb ist auf jeden Fall kompakt, muss aber nicht unbedingt langsamer sein, kommt auf Cache und Pipeline an, da Lesezugriff auf Programmspeicher/Flash viel Zeit verbraucht.

• CPU-spezifische Erweiterungen: Sind die Besonderheiten zur Programmierung von ISRs nicht bei allen Plattformen Erweiterungen? Ob nun durch Macros/Attribute getarnt oder nicht. Falls "Progmem" fuer AVR als Erweiterung bezeichnet wird, muessten es die ISR Macros/Attribute auch. Vgl. auch gcc-Dokumentation "target specific...".

• Skalierbarkeit: ARM != ARM. Speicher/Pinanzahl ist nicht alles. Integrierte "Zellen" um den ARM-Kern sind teilweise unterschiedlich (vgl. z.B. Interrupt-System STR7/LPC2k/SAM7, UART LPC/AT91SAM7, ...). Uprade von zu klein gewordenem ARM-Controller zu einen groesseren eines anderen Herstellers mglw. mit viel Codeaenderung verbunden.

• Interruptfeste I/O-Ports: warum die scheinbar bei allen ARM-GPIO uebliche SET/CLR-Methode nicht "interruptfest" sein soll, ist mir nicht klar. Wenn schon SAM7 "besser" als LPC2k (welcher? die "aelteren" oder auch die "neuen" lpc213x/214x), dann muesste man eigentlich die herstellerspezifische GPIO-Ansteuerung um den ARM-Kern erlaeutern.

-- Martin Thomas

• GCC Scripte: Wenn man mal saubere Versionen von crt.s und Linker-Scripten hat, ja dann. Einfach aus den Netz klauben ist arg problematisch, bei vielen fehlt beispielsweise der C++-Support, die Speicherparameter müssen angepasst werden, weil für das falsche Modell, die Exceptions heissen überall anders, ... Der Weg dahin ist die erwähnte Handarbeit und setzt recht viel Verständnis voraus.

• Das Kriterium "Performance" würde m.E. den Rahmen sprengen. Ja, man kann nicht alle ARMs über einen Kamm scheren, mir ging es hier um die grundlegende Architektur, nicht die konkrete Implementierungen. Die "Krone" gebührt wohl ADuC7000 mit 16bit-Flash.

• Skalierbarkeit: Bei 256KB Code dürfte der Anteil modellspezifischen Codes recht gering sein. Saubere Programmierung vorausgesetzt.

• Erweiterungen: Wenn man ins crt.s einen besseren IRQ-Handler steckt, sind spezielle Frames nicht erforderlich. Nebenbei gibt's dann auch Thumb Interrupts, das IRQ/FIQ-Maskierungsproblem ist weg, und bei Interrupt-Nesting muss man sich nicht um den Stack-Switch kümmern. Aber wie auch immer, Exception-Attribute sind vergleichweise selten und unproblematisch, Erweiterungen für Datenadressierung durchziehen jedoch oft den ganzen Code.

• Interruptfeste I/O-Ports: Bei LPC2000 fehlen SET/CLR bei der Richtungssteuerung. Bei Open-Drain Funktion wird aber genau damit der Pin gesteuert.

• Compiler: yep, schreib's rein.

-- A.K.

verfügbare Libs

Ich denke ein sehr wichtiger Punkt wäre auch die Verfügbarkeit von kostenlosen Librarys. Denn man will ja das Rad nicht 2 mal erfinden.

Code zum Compiler-Vergleich

Der Code zum Compiler-Vergleich:

#define CRC8POLY	0x18	//0X18 = X^8+X^5+X^4+X^0

typedef unsigned char	data_t; // 8-Bit
//typedef unsigned	data_t; // 16/32-Bit

data_t
crc8(data_t accu, data_t dat) reentrant
{
    data_t bit_counter = 8;
    do {
	data_t feedback = accu ^ dat;
	if (feedback & 1)
	    accu = accu ^ CRC8POLY;
	accu = (accu >> 1) & 0x7F;
	if (feedback & 1)
	    accu = accu | 0x80;
	dat = dat >> 1;
	bit_counter--;
    } while (bit_counter > 0);
    return accu;
}

/*
This is based on code from :

Copyright (c) 2002 Colin O'Flynn

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/

-- A.K.

EmbeddedArtists-Baords "sinnvoller konstruiert als die Olimex-Boards"

Das habe ich entfernt. Die früheren Olimex-Boards waren z.T. etwas seltsam designed, aber das ist IMO inzwischen nicht mehr der Fall, und die Boards vom EmbeddedArtists haben auch so ihre Merkwürdigkeiten (USB-Port nur zur Stromversorgung, Datenleitungen überhaupt nicht angeschlossen).

--

Wir können ja mal eine Sammlung an Denkwürdigkeiten aufmachen.

Für Olimex hätte ich da zu bieten:

• Sub-D-Buchsen so dicht beisammen, dass oftmals nur ein Stecker reingeht, der zweite passt dann nicht mehr (lpc2129). Neuere Boards sind zwar besser, aber am alten Layout wird natürlich nichts geändert.
• Nett, eine Reset-Control per DTR einzubauen, wie Philips nahelegt. Aber ziemlich sinnlos, wenn man konsequent die Bootselect-Control per RTS vergisst. Unverändert bis heute.
• Prima Idee, einen CAN Controller mit einem Baudratenquarz zu versehen. Schon mal versucht, aus 59MHz irgend eine sinnvolle CAN-Rate abzuleiten? Ich verstehe ja, dass 10 und 12MHz ein Problem sind, aber RS232 dürfte mit 15 statt 14,7MHz kein Problem haben und CAN wäre glücklich.

Und zu Embedded-Artists:

• Sub-D Buchse auf dem Baseboard so genial plaziert, dass alle Quickstart-Boards mit Sub-D (also fast alle) grundsätzlich nicht ohne zusätzliche Etage etwas kontaktunfreudiger Zwischenstecker reinpassen, von denen immerhin ein paar vom falschen Typ beiliegen. Immerhin haben sie's allerdings schon selber gemerkt und laut Auskunft die n䣨ste Charge umkonstruiert.
• Ein Ground-Plane auf der Lötseite einer Lötpunktrasterfläche erschwert eine sinnvolle Nutzung dieser Fläche erheblich (oben ist's ok, aber unten kriegt man so keinen blanken Draht mehr drauf). Ausserdem merkt man, dass die noch sehr junge Augen haben müssen. Die freien Flächen zwischen Lötauge und Umgebung sind so extrem eng, dass ich ?lles mit der Lupe dr?uss, was sonst nur in Ausnahmefällen nötig ist.
• Bei einem der Quickstart-Boards die Pfostenleisten im Abstand von 850mil plaziert. Was folglich nirgends reinpasst, wo man ein solches Board braucht, denn wer mit einem 50mil-Raster etwas anfangen kann, der braucht kein solches Board. Abhilfe angekündigt.

A.K.

Interruptprioritäten beim PIC (16F84)

Beim PIC kann man den einzelnen Interrupts Prioritäten zuweisen, anderfalls hätte meine SMBUS Implementiereung in den 16F84 nicht funktioniert. Der SMBUS braucht einfach eine höhere Priorität, sonst gibt es "Bit-verschlucker".

Langes Gerede kurzer Sinn, hier ein Beispiel:

org 0x04
goto INT_VECTOR


INT_VECTOR:
  <status & W sichern (push)>

  btfsc INTCON, 6
    goto INT_VECTOR_1

  btfsc INTCON, 5
    goto INT_VECTOR_2

  btfsc INTCON, 4
    goto INT_VECTOR_3

  INT_VECTOR_EXIT:
  <status & W wiederherstellen (pop)>
  retfie


INT_VECTOR_1:
  <ISR>
  goto INT_VECTOR_EXIT

INT_VECTOR_2:
  <ISR>
  goto INT_VECTOR_EXIT

INT_VECTOR_3:
  <ISR>
  goto INT_VECTOR_EXIT

So, hier kann man sehen dass INT_VECTOR_1 die höchste Priorität hat.

- Feadi

Priorisierte Interrupts heisst üblicherweise: Ein höher priorisierter Interrupt kann einen niedriger oder gleich priorisierten Interrupt-Handler unterbrechen, aber nicht umgekehrt. Und in diesem Kontext ist entsprechender Hardware-Support gemeint.

Was damit nicht gemeint ist: Welcher Vektor bei gleichzeitig auflaufenden Anforderungen vom Prozessor angesprungen wird (AVR) oder vom Interrupt-Handler nacheinander abgefragt wird (o.A. Beispiel - sowas geht überall und immer, kann also kein Kriterium sein).

Mit vektorisieren Interrupts ist es ähnlich. Auch da lässt sich natürlich immer wie gezeigt ein Handler schreiben, der alle Quellen abfragt und entsprechend verzweigt. Wenn sowas in Hardware geschieht, dann sind die Interrupts im Sinne des Textes vektorisiert, sonst nicht.

A.K.