www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Controllertypen: Blick über den Tellerrand


Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich bin mit den 8-Bit AVRs eigentlich recht zufrieden. Ich will aber 
auch nicht in die "Was der Bauer nicht kennt"-Falle laufen und 
vielleicht etwas verpassen. Ich habe mir deshalb diese Seite 
http://www.mikrocontroller.net/articles/Mikrocontr... einmal 
angesehen und auch sonst noch etwas recherchiert. Vielleicht können mir 
Leute, die sich mit anderen Familien auskennen, meine Vorurteile 
bestätigen oder zerstreuen. Es geht um Basteleien, wichtig sind daher 
auch die Verfügbarkeit (Reichelt &Co.) und die Lochrastertauglichkeit 
(DIP-Gehäuse).

8051: Angefangen habe ich einmal damit. Die Akku-zentrierte Architektur 
kann einem unter C eigentlich Wurscht sein. Die Rechenleistung/Takt ist 
aber aus meiner Sicht nicht so toll und es gibt auch eher weniger 
On-Board-Hardware als beim AVR. (z.B. SPI, I²C etc. fehlen)

PIC: Als ich vor Jahren nach einer Alternative zu 8051 suchte, wurde mir 
davon abgeraten. Es würden zwar viele verschiedene Controller 
angekündigt, die seien aber dann schwer zu bekommen. Außerdem 
unterscheiden sich die einzelnen Typen teilweise sehr und man muss quasi 
bei jedem IC mehr oder weniger von vorne anfangen.

MSP430: Wirbt mit "16-Bit". Im DIP-Gehäuse sind aber nur wenige zu 
erhalten, so auf ATTiny-Niveau, was den Speicherausbau betrifft. Die 
Rechenleistung ist trotz "16-Bit" eher mau, dafür stromsparend. Auch 
eher sparsam, was die Ausstattung mit On-Board-Hardware betrifft.

8-Bit AVR: Kenne ich inzwischen sehr gut. Die ATMegas sind in den 
Grundfunktionen einander sehr ähnlich - kennt man erst einmal einen, 
fühlt man sich auch auf den anderen schnell zu Hause. Im DIP-Gehäuse 
kommt man bis 128k Flash und 16k SRAM. Viele Typen bei den üblichen 
Verdächtigen verfügbar.

XMEGAs: Kein DIP-Gehäuse :(. Nur wenige Typen erhältlich. Mehr 
Funktionen als die normalen Megas, aber irgendwie nur der halbe Weg zum 
AVR32, der auch nicht teurer ist.

AVR32: Ebenfalls kein DIP-Gehäuse und nur wenige Typen frei verfügbar. 
Bieten aber mehr Rechenleistung als die 8-Bit (32 Bit und höhere 
Taktrate). Wäre daher meine erste Wahl, wenn es mit den ATMegas nicht 
mehr reicht.

R8: Keine Ahnung

R32: Keine Ahnung.

Bin jetzt schon gespannt, was an Kommentaren kommt. (Aber bitte keine 
Flame-Wars etc. Jede Architektur hat ihre Existenzberechtigung und den 
"besten" Controller gibt es sowieso nicht, weil es immer auf die 
Anforderungen ankommt.)

Gruß, DetlevT

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die diversen ARMs fehlen in deiner Auflistung.

Von der Forderung, alles noch in einem DIP-Gehäuse zu bekommen, nur
damit du das auf ein Steckbrett nageln kannst, darfst du dich wohl
allmählich trennen.  QFP lässt sich allemal brauchbar mit der Hand
löten, sogar auf selbstgemachten Platinen, zumindest in den größeren
Rastermaßen (bei 0,5 mm braucht man dann schon ein bisschen Löt-
erfahrung, wobei der Entlötlitzentrick allemal funktioniert).

Sieh's positiv: dank SMD werden auch die Baugruppen der Hobbyisten
viel kleiner, als man sich das vor 20 Jahren je hätte vorstellen
können.

Autor: Lehrmann Michael (ubimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:
> PIC: Als ich vor Jahren nach einer Alternative zu 8051 suchte, wurde mir
> davon abgeraten. Es würden zwar viele verschiedene Controller
> angekündigt, die seien aber dann schwer zu bekommen. Außerdem
> unterscheiden sich die einzelnen Typen teilweise sehr und man muss quasi
> bei jedem IC mehr oder weniger von vorne anfangen.

Ich wäre hier mit solchen Themen sehr vorsichtig. Ich sag dir ehrlich 
ich bin auch ein PIC-Verfechter. Die PICs sind genauso leicht zu 
bekommen wie die AVRs. Das die sich unterscheiden wäre mir auch neu - 
okay man muss manchmal Controllerspezifisches im Datenblatt nachschlagen 
aber es ist genau das gleiche wie bei den ATMEGAs (mit denen ich auch 
schon gearbeitet habe).

Bei den AVR hat mich ehrlich gesagt aufgeregt, dass sie so kleine 
Kinderkrankheiten wie die Möglichkeit des Verfusen bieten.

Ansonsten sind AVR und PIC gleichzusetzen. PICs sind leicht teurer dafür 
in meinen Augen ausgereifter.

Deine Liste möchte ich in diesem Sinne noch mit anderen PIC-Typen 
ergänzen die mit den normalen PICs recht wenig zu tun haben. (Weder vom 
Aufbau noch von der Programmierung)

dsPICs (mit DSP Unit)

PIC32

Autor: Thomas Kiss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PIC Programmer sind auch wesentlich teuerer oder ?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lehrmann Michael schrieb:

> Das die sich unterscheiden wäre mir auch neu -

Die Typen mit 12/14-Bit und 16-Bit Codewortbreite unterscheiden sich im 
Befehlssatz signifikant. Infolgedessen sind dafür unterschiedliche 
C-Compiler nötig. Bei den 16-Bit Typen existieren dann noch zwei 
signifikant verschiedene Generationen, die älteren arbeiten mit direkter 
Adressierung, die neueren beherrschen alternativ die 
Compiler-freundlichere Offset-Adressierung.

> dsPICs (mit DSP Unit)

Interessant ist die ganze PIC30 Familie, ob mit oder ohne DSP: dsPIC30, 
PIC24, dsPIC33, wobei sich die bis 40pin in DIP erhältlichen dsPIC30 
aufgrund ihres Stromverbrauchs auch als Kaffeewärmer eignen ;-).

Allerdings sollte man vorher das betreffende Errata-Sheet lesen. 
Insbesondere wenn man bisher nur AVRs kannte. Die PIC30 sind in der 
Hinsicht ähnlich ergiebig wie die 32-Bitter anderer Anbieter.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Kiss schrieb:

> PIC Programmer sind auch wesentlich teuerer oder ?

Nein. Wobei vor dem Auftauchen des AVR-Dragon die 
Programmer/Debugger-Kombis bei PICs deutlich günstiger waren als der 
sauteure JTAG-Mk2 der AVRs. Die diversen als Programmer und Debugger 
einsetzbaren ICD2-Clones für die PICs liegen in ähnlicher Preisklasse 
wie der Dragon.

Allerdings ist die Programmiertechnik der AVRs etwas freundlicher in der 
Systemintegration, denn die Programmierpins sind da nur bei aktivem 
Reset aktiv, wodurch sich diese Pins oft problemlos mit einer anderen 
Funktion ausserhalb des Resets kombinieren oder alternativ per 
Reset-Signal unterscheiden lassen. Bei den 8-Bit PICs ist das allein 
schon aufgrund des völlig andersartigen Reset-Signals nicht ganz so 
einfach.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:
> MSP430: Wirbt mit "16-Bit". Im DIP-Gehäuse sind aber nur wenige zu
> erhalten, so auf ATTiny-Niveau, was den Speicherausbau betrifft. Die
> Rechenleistung ist trotz "16-Bit" eher mau, dafür stromsparend. Auch
> eher sparsam, was die Ausstattung mit On-Board-Hardware betrifft.

Deine MSP430-Interpretation ist nur dann korrekt, wenn man sich auf die 
im DIP-Gehäuse verfügbaren Typen beschränkt. Diese aber machen nur einen 
verschwindend geringen Bruchteil der MSP430-Familie aus, die in Sachen 
Speicherausbau bis 16 kByte RAM und 256 kByte Flash-ROM geht, mit bis zu 
25 MHz Taktfrequenz, einem "barrel shifter" (der Schiebeoperationen 
beschleunigt) und einem Hardwaremultiplikator durchaus einiges an 
Rechenleistung hinbekommen kann.

Auch die Peripherie ist bei den ernstgemeinten MSP430-Varianten durchaus 
sehenswert, beim derzeitigen "Dickschiff" 'F5438 beispielsweise gibt es 
vier USCI_A/B-Pärchen, die simultanen Betrieb mit vier seriellen 
Schnittstellen und vier SPI- oder I2C-Schnittstellen erlaubt. Ein 
16kanaliger 12-Bit-ADC mit mehreren hundert kHz Samplerate kommt noch 
dazu.

Was es bei keinem einzigen MSP430 gibt, ist ein externes 
Speicherinterface. Anwendungen, die nicht mit den 16 kBye RAM der 
größten Familienmitglieder auskommen, sind somit eher 'ne Sache für 
andere Controllerfamilien.

Die 16 Bit sind durchaus ernstzunehmen, das "Dickschiff" kann auch echte 
16-Bit-Portzugriffe durchführen, was, wenn man so etwas wie eine 
IDE-Festplatte oder eine CF-Karte ansteuern möchte, einiges an 
Performance gegenüber sequentiellen 8-Bit-Zugriffen mit sich bringt.

Die MSP430-Reihe wird im Bastelsegment ziemlich stiefmütterlich 
behandelt, Olimex beispielsweise ignoriert seit Jahren alle neu auf den 
Markt gekommenen Controller - das "Dickschiff" beispielsweise kennen die 
nicht, nach den Platinen für die schon etwas angejahrten 'F169-12 ist 
nichts wesentliches mehr geschehen.
Die neue Platine für den 'F2618 ist auch nur ein Aufguss der Platine für 
den 'F169, denn die Dinger sind weitestgehend pinkompatibel.

Auch das Angebot bei Händlern wie Reichelt ist ziemlich dürftig, 
einerseits rufen die völlige Phantasiepreise für den 'F1611 auf, 
andererseits haben sie nichts neueres.

Der 'F5438 ist trotz erheblich gesteigerter Leistung gegenüber dem 
'F1611 deutlich günstiger (TI selbst nennt etwa den halben Preis).

Möglicherweise belebt sich die Situation mit der Launchpad-Aktion etwas, 
immerhin lässt sich das Launchpad auch als Debug- und 
Programmierinterface für den 'F5438 verwenden und dürfte damit so 
ziemlich das kostengünstigste JTAG(artige) Interface auf dem Markt sein.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

vielen Dank für eure Hinweise. Das hat mir schon weiter geholfen. ARM 
hatte ich tatsächlich noch nicht auf dem Radar. Irgendwie verbinde ich 
damit "da muss Linux drauf laufen", aber dem ist ja nicht so. Sollte ich 
irgendwann mit AVR32 liebäugeln, werde ich ARM als Alternative in 
Betracht ziehen.

Mit PIC brauche ich mich dann wohl wirklich nicht beschäftigen, da es 
den großen Vorteil zu AVR8 offenbar nicht gibt. Das ist wohl eher wie 
der Unterschied von Coke und Pepsi. ;) Die volatile Entwicklung der 
PIC-Controller gefällt mir da wirklich nicht, auch wenn es im 
Zweifelsfall der Compiler ist, der sich damit herum ärgern muss. Da 
finde ich die konservative Einstellung beim AVR besser, auch wenn das 
zunehmend Probleme macht. (z.B. bei Flash größer 128kB und Ports 
jenseits von 0x3F, die nicht mehr via OUT/IN erreichbar sind).

BTW: So manches Mal hat mich auch gestört, dass externe 
Speicherinterfaces so selten sind. Ist aber auch eine zweischneidige 
Sache, weil Parallel-Interfaces natürlich Pinfresser sind. Ich freunde 
mich da zunehmend mit dem Gedanken an, SRAM auch einmal per SPI 
anzubinden. Mit dem 23K256 (3,3V) von Microchip gibt es da immerhin 
32kiB, sogar im DIP-Gehäuse. Mit etwa 20 Takten/Byte (AVR8) beim 
sequentiellen Zugriff ist das zwar lange nicht so schnell wie parallel 
und vom Compiler wird das natürlich auch nicht direkt unterstützt. Aber 
für manche Anwendungen vielleicht doch ganz brauchbar und wahrscheinlich 
immer noch besser als ein Parallelinterface, das man in Software 
implementieren muss.

Gruß, DetlevT

Autor: mmhh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:
> PIC: Als ich vor Jahren nach einer Alternative zu 8051 suchte, wurde mir
> davon abgeraten. Es würden zwar viele verschiedene Controller
> angekündigt, die seien aber dann schwer zu bekommen. Außerdem
> unterscheiden sich die einzelnen Typen teilweise sehr und man muss quasi
> bei jedem IC mehr oder weniger von vorne anfangen.


Bitte nicht alle PICs über einen Kamm scheren.
PIC10/12 sind wirklich nur für Dinge geeignet die als einzige 
Vorrausetzung ein möglichst kleines Gehäuse haben.

Auch die PIC16 Reihe ist total veraltet.

Wenn dann musst du die PIC18 Reihe als Vergleich nehmen. Die sind 
ähnlich schnell wie AVR, es gibt MASSIG Typen (auch in DIP) mit sehr 
interessanter Peripherie: CAN, USB, Ethernet. CAN und USB Controller 
gibts in DIP und z.B. bei R

Programmiertools sind günstig: Pickit3 (Programmer und Debugger) 69€ und 
nicht so leicht tot zu bekommen wie ein Dragon

Ich kann jetzt nur von C sprechen und da geben sich AVR und PIC18 nix.
Außerdem muss ich der Aussage widersprechen, dass sich die Typen stark 
unterscheiden.
Das Gegenteil ist der Fall: Du hast durchgängig von PIC10 (8biter, 12bit 
Wortbreite) über Pic18 (8biter) über PIC24 (16biter), dsPIC(16bit DSP) 
und PIC32 (32biter) die gleiche Oberfläche.
Der Wechsel von PIC18 zu PIC24 gestaltet sich (zumindest in C) sehr 
einfach...

Aber wirklich rentieren tut es sich nicht wenn du dich mit den AVRs gut 
auskennst würde ich mich eher nach "oben" (also z.B. ARM, PIC32) und 
nicht zur Seite orientieren.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kuck Dir unbedingt den STM32 mal an 
http://www.mikrocontroller.net/articles/STM32

Das ist mein aktueller Liebling vor allem wegen der komfortablen C 
Firmwarebibliothek.
http://www.mikrocontroller.net/articles/STM32F10x_...

Gruß
Tom

Autor: mmhh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Tipp. Mir war gar nicht bewusst, dass der STM32 ein ARM 
Cortex ist...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:

> vielen Dank für eure Hinweise. Das hat mir schon weiter geholfen. ARM
> hatte ich tatsächlich noch nicht auf dem Radar. Irgendwie verbinde ich
> damit "da muss Linux drauf laufen",

Kannst ja auch NetBSD nehmen. ;-)

> aber dem ist ja nicht so.

ARM != ARM.  Es gibt halt welche, die mit einem virtuellen Speicher-
system aufwarten, auf denen sich dann wirklich ein OS wohl fühlt
(ARM9).  Das sind aber nicht mehr wirklich Controller, sondern
regelrechte Prozessoren (Speicher komplett extern).

Die kleineren ARMs (ARM7TDMI, Cortex M3) sind jedoch "echte"
Controller und passen daher an vielen Stellen, wo man etwas mehr
Rechenleistung haben will.

> BTW: So manches Mal hat mich auch gestört, dass externe
> Speicherinterfaces so selten sind. Ist aber auch eine zweischneidige
> Sache, weil Parallel-Interfaces natürlich Pinfresser sind. Ich freunde
> mich da zunehmend mit dem Gedanken an, SRAM auch einmal per SPI
> anzubinden.

Naja, es ist ja nicht nur SRAM, was man da anschließen kann.  Ein
FT245 lässt sich dann einfach mit memcpy() beschreiben, und man muss
sich um keine Datenrate und Quarzfrequenz und sowas Gedanken machen
(wie beim FT232).  Ich baue im Moment gerade ein Interface für einen
Signalgenerator, der auf 10 Stellen mit BCD parallel gefüttert werden
möchte.  Eine Reihe 74HC574 an den Speicherbus gehängt, und ab geht
die Post: ein Frequenzupdate ist in 3 µs durch (der Generator braucht
20 µs dann zum Einpegeln der neuen Frequenz).  Manchmal ist MMIO schon
praktisch.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die MSP430 sind wirklich einen Blick wert, insbesondere die 
ez430-Chronos. Im Vergleich zu den AVRs sind die MSP430 jedoch IMHO 
relativ komplex, man sehe sich nur das Powermangament an. Auch die 
Taktverteilung ist im Vergleich zu den AVRs sehr umfangreich. Besonders 
gelungen ist auch das Portmapping, man kann also z.B. den PWM-Ausgang 
auf beinahe jeden Pin routen, das gibt einem bestimmt enorme Freiheiten 
beim Layout.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:
> Mit etwa 20 Takten/Byte (AVR8) beim
> sequentiellen Zugriff ist das zwar lange nicht so schnell wie parallel
> und vom Compiler wird das natürlich auch nicht direkt unterstützt. Aber
> für manche Anwendungen vielleicht doch ganz brauchbar und wahrscheinlich
> immer noch besser als ein Parallelinterface, das man in Software
> implementieren muss.

Also so ein Parallelinterface ist sehr, sehr einfach implementiert und 
je nach Speicher auch sehr schnell.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Luk4s K. schrieb:
> Auch die Taktverteilung ist im Vergleich zu den AVRs sehr umfangreich.

Ja, aber dafür hat man auch keine "Fuses", die die Takterzeugung 
betreffen und geschätzte 30 % aller Anfängerprobleme beim AVR ausmachen. 
Vielmehr ist es möglich, im Betrieb die Taktquelle zu ändern, was 
reizvolle Möglichkeiten zum Stromsparen ergibt.

Luk4s K. schrieb:
> Besonders > gelungen ist auch das Portmapping, man kann also
> z.B. den PWM-Ausgang auf beinahe jeden Pin routen

Das ist leider eher Zufall denn üblich, normalerweise gibt es da gar 
keine Freiheitsgrade.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino G. schrieb:
> Also so ein Parallelinterface ist sehr, sehr einfach implementiert und
> je nach Speicher auch sehr schnell.

Für den wahlfreien Zugriff ist das sicher der Fall, weil man beim 
SPI-SRAM sonst erst die Adresse übertragen muss. Deswegen schrieb ich ja 
explizit von sequentiellem Lesen/Schreiben. Parallel mit dem üblichem 
Latch komme ich da auf folgende Rechnung (AVR8): Adresse an Ports 
ausgeben (2 Takte), Latch triggern (2 Takte), AD-Port auf Input (1 Takt) 
OE auf low (1 Takt) auf SRAM warten (1-2 Takte) Byte einlesen (1 Takt) 
OE auf high (1 Takt), AD-Port auf Ausgang (1 Takt), 16-Bit Adresse 
inkrementieren (2 Takte), das Ganze von vorn. Macht 12-13 Takte vs. 18 
bei maximaler SPI-Geschwindigkeit. (Eventuell sogar nur 16, wenn man ein 
doppelt gepuffertes USART dafür missbrauchen kann) Parallel ist man da 
also nur etwa 33% schneller.


Rufus t. Firefly schrieb:
> Vielmehr ist es möglich, im Betrieb die Taktquelle zu ändern, was
> reizvolle Möglichkeiten zum Stromsparen ergibt.

Bei den neueren AVRs kann man im Betrieb den Prescaler für den Takt 
ändern.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Prescaler. Aber kann man auch zwischen internem RC-Oszillator, 
externem LF-Oszillator und externem HF-Oszillator hin- und herschalten?

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:
> Parallel ist man da
> also nur etwa 33% schneller.

PS: Ich vergaß: Dann hat man das Byte ja noch nicht abgespeichert (2 
Takte). Das kann man bei SPI tun, während die Hardware schon nächste 
Byte holt. Bei dem Software-Parallelinterface aber nicht. Also steht es 
für diese spezielle Anwendung (mehrere Bytes sequentiell lesen) nur noch 
14-15 zu 18 für Software-Parallel.  Da kommt man schon ins Grübeln, 
oder?

Rufus t. Firefly schrieb:
> Aber kann man auch zwischen internem RC-Oszillator,
> externem LF-Oszillator und externem HF-Oszillator hin- und herschalten?

Nö. Habe ich aber auch noch nie gebraucht. ;)

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly schrieb:
> Luk4s K. schrieb:
>> Besonders > gelungen ist auch das Portmapping, man kann also
>> z.B. den PWM-Ausgang auf beinahe jeden Pin routen
>
> Das ist leider eher Zufall denn üblich, normalerweise gibt es da gar
> keine Freiheitsgrade.

Habe ich da etwas falsch verstanden?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly schrieb:
> Den Prescaler. Aber kann man auch zwischen internem RC-Oszillator,
> externem LF-Oszillator und externem HF-Oszillator hin- und herschalten?

Seit Xmega ja, davor nur vereinzelt (beispielsweise bei den kleinen
AT90USBxx).

Autor: frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:
> Parallel mit dem üblichem
> Latch komme ich da auf folgende Rechnung (AVR8): Adresse an Ports
> ausgeben (2 Takte), Latch triggern (2 Takte), AD-Port auf Input (1 Takt)
> OE auf low (1 Takt) auf SRAM warten (1-2 Takte) Byte einlesen (1 Takt)
> OE auf high (1 Takt), AD-Port auf Ausgang (1 Takt), 16-Bit Adresse
> inkrementieren (2 Takte), das Ganze von vorn. Macht 12-13 Takte vs. 18
> bei maximaler SPI-Geschwindigkeit. (Eventuell sogar nur 16, wenn man ein
> doppelt gepuffertes USART dafür missbrauchen kann) Parallel ist man da
> also nur etwa 33% schneller.

Die Rechnung stimmt aber nur wenn du es "von Hand" machst und nicht bei 
echtem ext. RAM Port. Schau mal ins Datenblatt von z.B. 8515 wie da das 
Timing ist. Und von Hand kann man ja außerdem mit jedem µC mit 
ausreichend Portpins, also keine Frage der µC-Familien.
frank

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo frank,

da hast du recht, aber darum ging es hier auch gar nicht:

Gastino G. schrieb:
> Detlev T. schrieb:
>> für manche Anwendungen vielleicht doch ganz brauchbar und wahrscheinlich
>> immer noch besser als ein Parallelinterface, das man in Software
>> implementieren muss.
>
> Also so ein Parallelinterface ist sehr, sehr einfach implementiert und
> je nach Speicher auch sehr schnell.

Thema war also explizit Parallelinterface in Software vs. SRAM via 
SPI. Und da schneidet aus meiner Sicht SPI überraschend gut ab, was die 
Geschwindigkeit betrifft. Bei wahlfreiem Zugriff hat selbst 
Software-Parallel die Nase weit vorn (14-15 Takte vs. 54), Nur wenn man 
regelmäßig auf mehrere Bytes sequentiell zugreift, kommt SPI näher 
heran. Dafür braucht es weniger Pins (4 statt 19) und auch weniger Platz 
auf der Platine. Was da am Ende wirklich besser ist, hängt dann halt von 
den Anforderungen ab.

Gruß, DetlevT

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:
> Mit PIC brauche ich mich dann wohl wirklich nicht beschäftigen, da es
> den großen Vorteil zu AVR8 offenbar nicht gibt.

Sehe ich auch so. Besonders die kleinen PICs sind extrem umständlich zu 
programmieren (Hardwarestack, keine Interrupts), da beißen sich die 
Compilerbauer die Zähne aus.
Die AVRs sind dazu im Gegensatz schon ab 6 Pins voll ausgerüstet, nur 
der MUL-Befehl fehlt bis zu den 20-Pinnern.
Ein AVR-Projekt läßt sich also wesentlich bequemer downsizen.


> (z.B. bei Flash größer 128kB

Da würde ich ganz konsequent sein, 8Bit nur bis max 64kB, darüber nur 
32Bit mit 32Bit Adresssen.
Ich denke, der ARM-Cortex-M3 ist da zu empfehlen. Schließlich haben den 
mindestens 4 Firmen im Programm (Atmel, NXP, ST, TI/Luminary),


Peter

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
>> (z.B. bei Flash größer 128kB
>
> Da würde ich ganz konsequent sein, 8Bit nur bis max 64kB, darüber nur
> 32Bit mit 32Bit Adresssen.

Da beim AVR8 der Programmzähler auf 16-Bit Wörtern arbeitet, sehe ich 
hier die natürliche Grenze bei 128k, davon maximal 64k Daten. Aber das 
ist bei Controllern ja schon eine ganze Menge.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> R8: Keine Ahnung
> R32: Keine Ahnung.

Diese japanischen Microcontroller sind an und für sich
ziemlich coole Typen.

Sie basieren von der Architektur auf dem Motorola 68000,
der Prozessor vom Mac/AtariST/Amiga, mal abgespeckt, mal
aufgerüstet, und sind deswegen sehr angenehm zu
programmieren, sowohl in Assembler als auch in höheren
Sprachen einfach für die Compilerbauer.

Die Japaner haben also nicht den Fehler gemacht, auf
eine bis zum geht-nicht-mehr reduzierte Spararchitektur
zu setzen die dann nur noch Problem macht, wie bei PIC
oder 8051.

Zudem waren sie schon lange vor den amerikanischen (oder,
falls  man den MSP mitzählt, deutschen) Microcontrollern
NÜTZLICH, d.h. sie hatten sinnvolle Stromsparfunktionen
und vor allem wieder Aufwachfunktionen, liefen an 2
Batteriezellen, konnten LCDs direkt ansteuern, Sonderfunktion
für Drehstrommotorsteuerung etc.

Nur leider sind gerade die R8/M16/R32 ziemlich blöd und
geizig bei den Ports. Statt jedes als I/O nutzbar zu
machen, sind die in Gruppen organisiert um ein paar Bits
zu sparen.

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.