mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PIC oder AVR


Autor: Gerhard Gunzelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

ich lese hier immer wieder Diskussionen welcher uC nun besser ist, die
PIC's oder die AVR's. Jetzt würde mich doch mal interessieren wer
sich schon mal mit beiden auseinandergesetzt hat und sachlich/objektiv
sagen kann wo welcher Vor- bzw Nachteile hat. Ich arbeite schon seit
etwa 5 Jahren mit PIC12, 16, 18 und PIC30, aber ich habe noch nie das
Gefühl gehabt, daß es da etwas gibt, was ich mit denen nicht machen
kann. Alternativen zum PIC sehe ich nur bei uC, die besondere Features
haben, wie z.B. MSP430 als besonders energiesparende uC oder good old
80C166 als Vertreter mit herausgeführten Bus oder echte DSP's. Also
welche Features haben die AVR's - rein auf Hardware-ebene oder eben
auf Feature-ebene, die sie besonders auszeichnet ?

Gerhard

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Hauke Radtki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
soweit ich weis, leigt der Unterschied fast nur in der programmierung!
Ich hab mich mit dem pics noch nicht beschäftigt, aber gehört, dass da
der speicher irgendwie segmentiert ist oder so ... (du solltest es
wissen, wenn du schon so lange mit denen arbeitest)
Vorteil beim tiny26 ist, dass man sehr hohe PWM frequenzen erzeugen
kann ... obs nen gegenstück bei den pics gibt, weiss ich nicht

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wobei man klar sagen muß, daß es für die neuen PICs eh C-Compiler gibt
und somit kann einem die Segmentierung völlig egal sein.

Autor: Hauke Radtki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jo also nur für ASM freaks interessant gg

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gerhard

"ich lese hier immer wieder Diskussionen welcher uC nun besser ist"


Die Frage ist superleicht zu beantworten: "Der, mit dem ich am
effektivsten arbeiten kann".

Und damit ist auch klar, daß die Antwort für jeden eine andere sein
wird.


Ich habe mich z.B. für den 8051 entschieden und damit keine schlechte
Wahl getroffen.

Mit über 600 verschiedenen Typen gibt es eigentlich nichts, was es mit
dem 8051 nicht gibt (MP3, LAN, USB, CAN usw.).

Die 8051 waren auch die ersten weltweit, die preiswert als Flash
verfügbar waren (etwa 1993: Atmel AT89C51). Wo andere noch Löschgeräte
quälten, habe ich schon längst geflasht.

Die 8051 sind auch 100% kompatibel, d.h. mit jedem A51-Assembler oder
C51-Compiler kann ich alle 8051 programmieren von original Intel von
1980 bis zum neuesten Silabs- oder Maxim-Typen, ohne auf Updates
angewiesen zu sein.


Zur Frage AVR vs. PIC:

Die AVRs finde ich auch sehr interessant für kleine Sachen ohne Quarz
oder Resetbeschaltung.
Die 8051-er hatten da den Zug eindeutig verschlafen, inzwischen gibts
da ja auch was (Philips LPC-Serie) und selbst Atmel hat viel Neues
angekündigt (bis 20MIPS).

Auch war es überhaupt kein Problem sich mit den AVRs zurechtzufinden,
wenn man den 8051 schon kannte. Insbesondere sind die Änderungen, wenn
man C-Code vom 8051 auf den AVR übernimmt, nur sehr gering
(Hardwarezugriffe).

Mit den PICs habe ich mal was versucht (PIC12-Derivat), aber da war mir
zu vieles von hinten durch die Brust ins Auge (keine Interruptvektoren,
kein Carry bei Addition, nur 1 Pointer, nur Hardwarestack, RAM-Banking,
Flash-Paging usw.).

In Assembler würde ich also sagen, ist der AVR eindeutig leichter zu
lernen und bequemer zu programmieren.

In der C-Programmierung dürften sich dann diese Vorteile auch
niederschlagen (schnellere Ausführung, geringere Codegröße).

Auch liest man oft, daß viele PIC-Compiler nicht alle Typen können,
sondern nur einige wenige (die 12-er wohl garnicht) und oft nur
eingeschränkte Variablentypen haben (kein long, kein float).

Aufgrund der Unterschiede ist bei neuen PIC-Derivaten in der Regel auch
immer ein Update des Compilers nötig, damit diese programmiert werden
können.


Peter

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein paar Kriterien für den CPU-Core und die µC-Familie:

- Compiler verfügbar, bzw wieviel will man dafür ausgeben?

Für AVR und MSP430 gibt's mit GCC einen guten Compiler für lau.
PIC und i51 entweder SDCC (über dessen Qualität mögen andere urteilen,
ich kenne ihn nicht). Oder diverse Löhnwares, bis 4-stellige Beträge,
teils auch als Demoversion mit Tricks.

- Sind für CPU-spezifische Erweiterungen in C erforderlich?

8051: ja, 5-6 Speicherklassen für die diversen RAM-Varianten.
AVR,PIC: für die RAM/ROM-Problematik (s.u.) ja, sonst nein.
MSP430: nein.

- Sind Daten in RAM und ROM mit dem gleichen Code benutzbar?

AVR, PIC, alle übrigen Harvard-Architekturen: NEIN. Daten im ROM
erfordern anderen Zugriff als Daten im RAM. Entweder versteckt das der
Compiler in Runtime-Routinen für Pointerzugriffe, oder man kann
Routinen nicht so schreiben, dass sie beides als Parameter verdauen
können. Bei kleinen Programmen von ein paar KB kein Problem, bei
grösseren jedoch schon. Bei AVR/GCC ziemlich fehlerträchtig.

MSP430: saubere von-Neumann Architektur. Problemlos.

- Lineare Adressierung vom RAM?

PIC: PIC16 ja, PIC14,PIC12 nein. RAM-Puffer die gösser sind als das RAM
in einer Bank sind nur mit Klimmzügen möglich.

8051,AVR,MSP430 kein Problem.

- Skalierbarkeit? Vor allem für jene wichtig, die sich scheuen, für
verschiedene Aufgaben verschiedene Lösungen zu verwenden.

AVR: 8-Pin/1K bis 64pin/128K Tendenz steigend.
PIC: innerhalb der Familie verschiedene Architekturen.
i51: von klein bis ganz gross (aber jenseits von 64K wird's
hässlich).
MSP430: bei 60K Flash ist definitiv Schluss.

Meine Empfehlung hier trotzdem: diese Klasse nur bis 40-60K verwenden,
darüber auf 32bit (ARM-Core) umsteigen.

- Wie komplex ist interrupt-feste Programmierung von I/O-Ports?

Das ist besonders beim AVR ein Problem. Architekturbedingt ist nur ein
Teil der Ports ist bitweise schaltbar, kein Port kann mehrere Bits
gleichzeitig interrupt-fest schalten (Ausnahme: ganz neue Devices wie
Tiny2313). Daher ist es eigentlich oft nötig, um Port-I/O herum die
Interrupts abzuschalten. Macht aber kaum jemand. Folge: ab und zu
"seltsames Verhalten", nicht repoduzierbar. Besonders gefährlich bei
Software-Baukasten-Prinzip, wenn da manche Selbstverständlichkeiten
eines Moduls plötzlich nicht mehr so selbstverständlich sind.

PIC,i51,MSP430 können AND/XOR/XOR zum Port hin, daher im Prinzip kein
Problem - dran denken muss man aber trotzdem (auch das kommt wohl eher
selten vor).

- Priorisierte Interrupts?

AVR,PIC: nein. Folge: es ist schwierig bis unmöglich, Reaktionszeiten
im unteren Mikrosekundenbereich zu garantieren.

i51: ja.

- I/O Spannung?

AVR,PIC,i51: 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?).
MSP430: nur 3V. Nicht 5V-kompatibel, d.h. 5V-Devices sind nur mit
Pegelkonvertierung einsetzbar.

- Debugging in der Schaltung?

Ist beispielsweise ein günstiges JTAG-Interface für In-Circuit
Debugging verfügbar? AVR: ab 40-Pin-Devices, darunter nicht oder arg
teuer. Andere Familien: keine Ahnung.

- Gehäuse?

Mit DIP oder PLCC bastelt es sich leichter als mit *QFP. Die Domäne von
AVR/PIC/i51.

Autor: jozi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits.
Hallo Peter

So sehr ich Deine Beiträge schätze, kann ich deine Aussage:
>Die Frage ist superleicht zu beantworten: "Der, mit dem ich am
>effektivsten arbeiten kann".
nicht ganz ohne Widerspruch stehen lassen. Das Ziel ist es doch, den
passenden Controller für die jeweilige Applikation zu finden. Also
müsste die Aussage lauten:
"Der, welcher für die jeweilige Aufgabe am besten geeignet ist."

Die PICs haben teilweise sehr interessante Peripherie z.B. für DC/DC
Wandler etc. Es gibt Chips bis 125 Grad Umgebungstemp. etc.
Dafür, und da muss ich Dir leider zustimmen, sind die eigentlichen CPUs
kein grosser Lichtblick. Auch der CAN-Controller ist mehr eine
Notlösung, aber für bestimmte Applikationen völlig ausreichend.

Der AVR bietet mit seinen freien Tools (gcc/WinAVR, AVRStudio, etc.)
einen schnellen preiswerten Einstieg. Der CAN-Controller (Mega128-CAN)
ist sehr leistungsfähig, und die CPU ist sehr schnell. Die Ports können
20mA in beide Richtungen treiben. OnChip Debugging per JTAGICE möglich.
Leider gibt es keine Chips für automotive Applikationen (125 Grad). An
sonsten, ein relativ problemloser Controller für breite Anwendungen.

Beim 8051 benötige ich leider sehr unterschiedliche Tools um meine
Software in die Hardware zu Übertragen. Vom EPROM-Emulator bis zum
JTAG-Flash Tool ist hier, je nach Chip, die Bandbreite ziemlich groß.
Und weder die CPU noch die diversen 8051 Drivate lösen
Begeisterungstürme bei mir aus. (EMV, Befehlssatz, etc.)
Sorry habe meine ersten Gehversuche auf 6800/05/09 Systemen gesammelt.

Und nach meinen ersten Projekten mit Philips ARM7 Controllern habe ich
meine Meinung über Philips mal wieder deutlich nach unten korrigieren
müssen. Wenn man sehr viel Rechenpower zu einem niedrigen Preis
benötigt ist der ARM7 sicherlich eine gute Lösung, allerdings auch mit
diversen Stolperfallen gespickt.

Ergo. Es gibt viele verschieden Aspekte für die Auswahl des passenden
Controllers. Und es ist nicht immer ganz leicht die vollmundigen
Datenblattangaben richtig zu interpretieren. (z.B. 80C515C 4 PWM
Ausgänge, selten habe ich so dumm aus der Wäsche gesehen). Also am
besten mal die Zeit investieren und selbst versuchen ob man mit dem
Chip klar kommt und wo die Fallen sind. Man erweitert damit auf jeden
Fall den eigenen Horizont.


Grüsse

Josef Zimmermann

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> "Der, welcher für die jeweilige Aufgabe am besten geeignet ist."

Nicht jeder springt von Lösung zu Lösung zwischen verschiedenen
Familien locker hin und her. Sicher, manchen fällt das leicht, dann ist
das eher eine Frage der zur Verfügung stehenden Werkzeuge. Andere
wiederum kämpfen schon an einer einzigen Famile arg mit dem Verständnis
der Vorgänge - wie hier oft zu beobachten ist.

Autor: Schoaschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welchen Controller würdet ihr für extrem schnelle digitale
datenverarbeitung empfehlen?also daten von einem externen (sehr
schnellen) AD wandler zu lesen und auf eine ram zu speichern und
zwischendurch vl noch die daten etwas um zu rechnen. oder die daten vom
ram auf einen DA wandler zu schreiben.
er sollte auch relativ schnelle rechenoperationen durchführen können.
und was eigentlich auch sehr wichtig ist! Es sollte für ihn einen
vernünftigen C-Compiler geben.
Welche architektur empfehlt ihr? RISC oder CISC?

mfg schoasch

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist "extrem schnell"?

Autor: Schoaschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
je schneller desto besser ;-)

wenn man zb einen pin nur ein- und ausschaltet, sollte dies schneller
als 2MHz möglich sein. er sollte die 1,6MHz variante des SPI busses
schafen (am liebsten wäre mir ja die 26MHz variante, aber das wird sich
nicht ausgehen ;-))
er soll lediglich so schnell wie möglich daten von einem port einlesen
und diese auf ein anderes port wieder ausgeben und das eben im MHz
bereich. sorry, ich weis nicht wie ich es erklären soll.(ist aber auch
schon spät)

mfg schoasch

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Schoaschi: Du beschreibst ziemlich genau das Aufgabenfeld von DSPs. Und
bis damit vermutlich ein bischen neben dem Thema / den Erfahrungen
dieses Forums.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einlesen und einfach wieder ausgeben ist klingt eher nach CPLD/FPGA.
Ohne genauere Informationen deinerseites kann man aber nur raten.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FPGAs kann man zwar auch zum Rechnen bewegen (das ist ja eine der
Forderungen), aber an C Compilern (eine andere seiner Forderungen)
hapert's bisweilen.

Autor: Schoaschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was sind denn bitte DSPs CPLD/FPGAs?

naja im endeffekt soll es ein gerät werden zur ton aufnahme. also ich
nehme ein audiosignal her und digitalisiere dieses und schreibe es
danach auf eine festplatte oder halt einen anderen speicher. nur je
schnell das das ganze ginge, desto besser wäre es, denn theoretisch
könnte man das ganze auch auf ein kleines KO umbauen. und in weiterer
folge will ich dann den umgekehrten weg angehen. aber das ist eine
andere geschichte ;-)

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DSP: aka Signalprozessor. Konstruiert zur digitalen Verarbeitung
analoger Signale. Das heisst nicht unbedingt, dass da ADCs/DACs drin
sind, sondern dass sie die dafür nötigen Rechenoperationen,
Schnittstellen und Datenverschiebebahnhöfe implementieren. Gibt's von
ziemlich vielen Herstellern, beispielsweise Texas Instruments (320Cxx),
neuerdings auch von Microchip (dsPIC).

CPLD/FPGA: Programmierbare Logik, keine Prozessoren irgeneiner Art
(wenngleich man in grösseren FPGAs welche selber bauen kann).

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein AVR bringt mit "Pin ein- und ausschalten" vielleicht mit Mühe noch
einen Kanal auf die Festplatte (bei 16 MHz Takt und 44.1kS/s bleiben 181
Takte pro Byte). Viel schnellere IOs als beim AVR wirst du nicht finden,
wenn du mehr Geschwindigkeit willst musst du die Platte direkt an den
Bus deines Prozessors hängen. Eventuell ist noch (mehr oder weniger
umfangreiche) Interfacelogik nötig. Compact Flash oder SD-Card wäre für
den Anfang einfacher, da die sich direkt mit Prozessorbus/SPI
vertragen.

Die sinnvolle Untergrenze für den Prozessor (von Controller zu reden
passt da schon langsam nicht mehr) ist so etwa im Bereich LPC2xxx (60
MHz ARM). Wenn du höher hinaus willst, schau dir mal den Blackfin an
(RS hat ein Board für 130 Euro), damit gehen auch "härtere" Dinge wie
Effekte, MP3-Kodierung in Echtzeit usw. Aber da geht's langsam aus dem
Hobby-Bereich heraus, und wenn du fragst "RISC oder CISC?" hast du
dir vermutlich ziemlich viel vorgenommen ;)

Autor: Quark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Und nach meinen ersten Projekten mit Philips ARM7 Controllern habe
ich
meine Meinung über Philips mal wieder deutlich nach unten korrigieren
müssen. Wenn man sehr viel Rechenpower zu einem niedrigen Preis
benötigt ist der ARM7 sicherlich eine gute Lösung, allerdings auch mit
diversen Stolperfallen gespickt."

@jozi
ist wohl OT, vieleicht einen neuen Thread?

würdest Du dazu bitte noch ein paar Sätze (oder Stichpunkte) schreiben,
was Dich an den Philips ARM stört? Mich interessiert schon länger das
Board (LPC-P2106) hier vom mikrocontroller.net Shop.
Wenn Du hier einige Stolperfallen ansprichst, weiß ich (und andere)
worauf man sich beim Philips ARM einlässt, oder vieleicht lieber von
einem anderen Hersteller kauft.

Danke und Grüße
Quark

Autor: Schoaschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@andreas
Achja.. viel habe ich mir schon vorgenommen ;-) aber wenn ich das nicht
tun würde, würde ich noch immer mit widerständen und leds (ohne µC)
arbeiten ;-)
Und das hier ist mal ein sammeln von informationen. danach muss ich
erst mal entscheiden was ich mache.
bezüglich der frage: CISC oder RISC. Mir ist teilweise noch nicht so
ganz klar in welchen fällen welche architektur besser ist. denn jede
hat sicher ihren vorteil und nachteil, ansonst würds ja keine CISC mehr
geben wenn die so schlecht sind oder?

jetz noch ne dumme frage ;-) (ein bisschen träumen wird man wohl dürfen
:-)). ist es möglich das man einen alten Prozessor(Intel 486 DX2) aus
einem PC anspricht und mit diesem arbeitet? hat jemand links dazu oder
sonst irgend eine info. ausser: du bist verrückt und solltest koch
werden;-)... oder ähnliche aussagen.

mfg schoasch

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Gerhard Gunzelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was denkst Du, gewinnst Du mit dem alten 486er ? Das ist ja ein
CISC-Prozessor, der bei 66MHZ wohl nicht mal 10MIPS schafft. Die ollen
Intel-Prozessoren benötigen auch noch zusätzliche Chips zum Ansteuern
von Peripherie und RAM. Ist sicher interessant zum Studium, aber damit
eine Steuerung bauen ? Ne danke.

Gerhard

Autor: dds5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um noch mal ganz auf den Anfang dieses thread zurück zu kommen:
Ich muss mich beruflich mit PIC beschäftigen und mir stinkt am meisten
die zum Teil noch nach vielen Monaten ellenlange Mackenliste in den
errata sheets.
Aktuelles Beispiel
18F242 ist zwar noch erhältlich wird aber nicht für Neukonstruktion
empfohlen, Nachfolgetyp 18F2420. Jetzt habe ich ein mit 18F242
funktionieres UART Modul (ASM) genommen und ins Prg. eingebaut. Ende
vom Lied: es kommt nur Mist raus, weil man während der TX ein Byte
rausschiebt, nicht das Paritybit des nächsten Bytes in das TXSTA
Register schreiben darf weil dabei der (Hardware) Prescaler des
Baudratengenerators zurückgesetzt wird!
Da kann man nur sagen: ohne worte.

Dass ein früheres Projekt um 3 Monate verzögerte wurde, weil die
Interruptpriorität beim 18F242 bis ca. 9 Monate nach Beginn der
Serienlieferung! (nicht samples!) nicht richtig funktionierte sei nur
am Rand erwähnt.

Da muss man sich bei Microchip offenbar dran gewöhnen.

Dieter

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Schoaschi:
Das mit dem 486er habe ich mir auch schon überlegt (schon vor einigen
Jahren, als ARM-Derivate noch kein Thema waren). So ein 486er ist
immerhin 32Bit, kann Multiplikation und Division, hat eine FPU, er
kommt auch mit mehreren MB Speicher problemlos zurecht usw. usf.

Wenn man sich dann aber mal überlegt, was da alles an Peripherie ran
muß, dann merkt man schnell, daß das nicht trivial ist. Da braucht man
eine ganze Menge ICs - aber das gibts ja auch schon fertig, als
sogenannten Chipsatz. Sogar fertig verlötet auf einer Platine - das
Mainboard eben. Das ist an dieser Stelle dann auch die Lösung: Wer
einen 486er verwenden will, der sollte einfach einen alten PC dafür
hernehmen.

Wobei - wie oben schon gesagt wurde - ein 486er nicht mehr Stand der
Technik darstellt. Es gibt heutzutage eben auch Microcontroller, die
mit einem 486er mithalten können.

Autor: jozi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits, hallo Quark.

Anbei auf besonderen Wunsch ein paar Hinweise zu meinen Problemen mit
dem LPC2114 von Philips.

1.) Das Datenblatt/User Manual ist unvollständig und teilweise
irreführend.
2.) Der interne I/O-Bus ist ziemlich langsam und wurde mehr oder
weniger direkt von der 8051 Familie übernommen. Ich habe jetzt keine
exakten Zahlen, aber nach meiner Abschätzung sind die Portzugriffe bei
Ti (TMS470) deutlich schneller.
3.) Einige Funktionen des Orginal ARM7TDMI Kerns fehlen bei Philips
(Umschaltung Big/Little Endian, etc.).
4.) Dummerweise verhält sich der I2C Controller ähnlich wie der im
8051, allerdings nur teilweise. Beispielsweise ist zum Senden des Stop
Bits das Löschen des Interrupt-Flags nötig. Und genau hier wird im
Manual auf das Datenblatt aus der 8051-Familie verwiesen.
5.) JTAG-Interface nur zum flashen und debuggen. Kein Boundary Scan.
6.) Der ARM Debugger ist selbst ziemlich buggy. Abstürze, vergessene
Breakpoints, kein Reset Button.

Gut den letzen Punkt kann man nicht Philips anlasten.

Vielleicht bin von meinem letzen AVR Projekt noch zusehr verwöhnt, aber
im Grossen und Ganzen scheint mir die Dokumentation von Philips mit der
heissen Nadel gestrickt zu sein. Dafür ist der Chip gnadenlos billig.

Ich denke das gibt meine ersten Eindrücke wieder.
Vorher bin ich schon einmal mit einem 8051 von Philips bei der
EMV-Prüfung ziemlich auf die Nase gefallen.

Grüsse

J. Zimmermann

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von ST und Analog gibt's interessante Alternativen zum LPC2xxx.

Autor: Quark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@jozi
Danke nochmal, sehr aufschlußreich.
Dann werde ich erstmal intensiver die Dattenblätter studieren.

@Andreas
guter Tipp, danke.

Grüße
Quark

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin eigentlich noch recht neu in der Thematik, darf aber hier in der
Firma etwas mit PICs "herumspielen", weswegen ich ein paar Anmerkungen
machen möchte. Ich habe mich überwiegend mit dem PIC16F84A und dem
PIC18F452 beschäftigt, weswegen sich meine Kommentare auch überwiegend
auf diese Varianten beziehen werden.

@Peter Dannegger
"kein Carry bei Addition"

Das stimmt definitv für die von Dir angesprochene M-Klasse, aber nicht
mehr für die H-Klasse, also die PIC18 (keine Ahnung, ob es für die 17er
auch gilt, aber wahrscheinlich schon, da die Erweiterung des
Befehlssatzes mit der größeren Befehlskodierung zusammenhängt).

@A.K.
"Compiler [...] teils auch als Demoversion mit Tricks"

Die Limitierungen des CC5X sind, daß maximal 1024 Instruktionen pro
Modul und nicht ganz so gut optimierter Code erzeugt werden, außerdem
können Variablen maximal 16-Bit haben. Ich denke mit den Limitierungen
läßt sich sehr gut leben, wenn man bedenkt, daß die meisten PICs
ohnehin kaum mehr Instruktionen aufnehmen können.
http://www.bknd.com/cc5x/downl-stud.shtml

"Priorisierte Interrupts? [...] PIC: nein"

Der 18er hat zumindest zwei unterschiedliche Interruptverktoren, einen
für niedrige und einen für hohe Priorität. Für die einzelnen
Interruptquellen kann unabhängig eingestellt werden, welche Priorität
sie haben sollen. Was den Interrupt ausgelöst hat, muß man leider immer
noch in der ISR händisch feststellen.

"Debugging in der Schaltung?"

Sollte bei PIC über ICD2 in Kombination mit MPLAB möglich sein. Ich
kann es nicht genau sagen, da ich bisher mit einem etwas veralteten
MPLAB gearbeitet habe, wo es nicht möglich war.
Wenn ich mich nicht irre, bin ich vor kurzem auch über eine Seite
gestolpert, wo beschrieben wurde, wie man sich einen ICD für PIC selber
bauen kann.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael: schreib das bitte direkt in
http://www.mikrocontroller.net/articles/AVR_PIC_51-Vergleich mit rein.

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachdem hier die Frage ob RISC oder CISC aufkam, möchte ich auch dazu
noch ein paar Kommentare abgeben.

Der originale Defintion des Begriffs RISC (Reduced Instruction Set
Computer), den man aber nicht zu wörtlich auslegen sollte, stammt von
David Patterson. Ich werde mich auf eine etwas generalisierte
Definition beziehen, da Patterson sich doch stark am
Berkeley-RISC-Project (aus dem sich SPARC entwickelte) orientierte und
deswegen auch sog. Register-Fenster vorsieht.

Die wichtigsten Punkte der Definition sind:

* Eine Instruktion pro Zyklus
Dies wird übrigens häufig so ausgelegt, daß jede Instruktion einen
Zyklus benötigt, was natürlich falsch ist. Gemeint ist eigentlich, daß
unter der Verwendung von Pipelining im Idealfall eine Instruktion pro
Zyklus abgeschlossen werden sollte.
Hier scheint bei PIC ürigens die Marketingabteilung zugeschlagen zu
haben, da hier auch behauptet wird, daß der Prozessor eine Instruktion
pro Zyklus ausgeführt wird. Interessanterweise meint Microchip damit
aber einen Instruktionszyklus, der allerdings vier Taktzyklen
benötigt.
Pipelining ist bei CISC-Prozessoren aufgrund der (unterschiedlichen)
Komplexität der einzelnen Instruktionen deutlich schwerer zu
bewerkstelligen. Ohne Pipeline würde eine PIC-Instruktion sogar 8
Taktzyklen benötigen, da PIC eine zweistufige Pipeline hat.
Da Interrupts nur zwischen Instruktionen stattfinden können, wirkt sich
die Eigenschaft von RISC-Architekturen, wenige Takte pro Instruktion zu
benötigen, positiv auf die Latenz aus. Dies war wohl auch einer der
Hauptgründe für Acorn nicht auf einen vorhanden Prozesser
zurückzugreifen, sondern den ARM zu entwickeln.

* Eine kleine Zahl von uniformen Instruktionsformaten
RISC bedeutet nicht etwa, daß man sehr wenige Instruktionen hat (es
gibt natürlich architektonische Beispiele dafür, aber mindestens
genauso viele Gegenbeispiele), sondern daß die Zahl der
Instruktionsformate recht gering ist und Instruktionen normalerweise
die gleiche Länge haben, um die Decoder-Einheit des Prozessors zu
vereinfachen.
Im weitesten Sinne halten sie die üblichen RISC-Architekturen daran,
gelegentlich gibt es aber Ausreißer, wo ein Teil einer längeren Adresse
in einer Folgeinstruktion eingebaut ist, die ohne die
Vorgängerinstruktion als NOP interpretiert würde. Das ist bei
Embedded-RISC häufiger anzutreffen, da dort die Instruktionen ohnehin
möglichst kurz sein sollten.
Die Instruktionslänge ist hier natürlich der wichtige Faktor. Während
bei einer RISC-Instruktion aufgrund der festen Länge einige "tote"
Bits vorkommen können, kann man bei CISC versuchen, die Instruktion so
kurz wie möglich zu machen (obwohl sich die gängigen Architekturen
zumindest an das Byte als Grundelement halten).
In der Theorie sollte CISC-Code also weniger Speicherplatz verbrauchen,
als vergleichbarer RISC-Code. Und Speicherplatz ist in Mikrocontrollern
ja meist recht begrenzt. Ich muß allerdings gestehen, daß ich bei den
mir bekannten Architekturen bisher noch keine gravierenden Unterschiede
feststellen konnte.

* Load/Store-Architektur
D.h. Operation werden ausschließlich auf Registern durchgeführt und der
Datenaustausch zwischen Registern und dem Speicher findet ausschließlich
über sog. Lade/Speicher-Instruktionen statt.
Dieser Punkt folgt ja eigentlich aus den beiden vorhergehenden, da man
auf diese Weise sowohl die Instruktionen einfacher gestalten, als auch
die Komplexität der Instruktionsformate reduzieren kann.
Dummerweise heißt das auch, daß einem während einer Operation, die
einen Speicherwert modifizieren soll, ein Interrupt dazwischen kommt,
da man den Wert ja erst laden, dann im Register modifizieren und dann
erst in den Speicher zurückschreiben muß.
Aus diesem Grund ignoriert SuperH (ehemals Hitachi jetzt ???) diese
Vorgabe wohl teilweise und läßt zumindest einige Bit-Instruktionen
direkt auf den Speicher zugreifen.

* Große Zahl von Universalregistern
"Groß" ist hier natürlich relativ. Die meisten
Embedded-RISC-Architekturen haben "nur" 16 Register, wobei AVR mit 32
Registern (?) doch recht ordentlich dasteht.
Auch das hier ist natürlich eine Folgeerscheinung der
Load/Store-Architektur: Wenn man nur auf Registern operieren kann,
sollte man zumindest einige davon haben. Da Registerzugriffe immer noch
am schnellsten sind, wirkt sich das natürlich wieder recht positiv auf
die Latenz aus.
Bei PIC von vielen Registern zu sprechen, halte ich allerdings für
etwas überheblich, da diese sog. "Register" fast ausschließlich im
SRAM liegen (zumindest ist damit die Latenz nicht so schlecht wie bei
DRAM).

Beides hat seine Vor- und Nachteile. Im Embedded-Bereich zeichnen sich
die RISC-Prozessoren vor allem durch gute Latenz-Zeiten aus, allerdings
kann sich die Load/Store-Architektur als ungünstig herausstellen, wenn
einem "eine Operation" durch einen Interrupt unterbrochen wird.
Theoretisch sollte es möglich sein für CISC-Prozessoren kompakteren
Code zu erzeugen.

Im Desktop-Bereich haben die RISC-Prozessoren schon längst gewonnen, da
sich die Prozessoren durch die einfacheren Schaltungen und das
Pipelining deutlich höher Takten lassen. Selbst die IA-32 hat die
x86-Instruktionen nur noch in der Software, die aber vor der
Verarbeitung in der ALU vom Decoder in kleinere RISC-ähnliche
Operationen zerlegt werden.

Ich hoffe, daß der Beitrag zumindest halbwegs nützlich war ;-)

Autor: remstal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Durchaus informativ und gut zu lesen, danke sehr!

Zufälligerweise der M.K. aus de.rec.modelle.bahn?

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Der originale Defintion des Begriffs RISC (Reduced Instruction Set
Computer), den man aber nicht zu wörtlich auslegen sollte, stammt von
David Patterson. Ich werde mich auf eine etwas generalisierte
Definition beziehen, da Patterson sich doch stark am
Berkeley-RISC-Project (aus dem sich SPARC entwickelte) orientierte und
deswegen auch sog. Register-Fenster vorsieht."

Wobei erwähnenswert ist, das der nach üblicher Definition erste
RISC-Computer die CDC6600 von Thornton und Cray ist, gebaut 1964!, er
hatte eine Load-and-Store-Architektur mit nur zwei Addressierungsarten,
Pipelining und nur 74 Opcodes.
Das erste Projekt eines RISC-Chips ist wohl der IBM801, aus dem auch
einiges in die Power-Architektur geflossen ist.


"RISC bedeutet nicht etwa, daß man sehr wenige Instruktionen hat"

Doch, so war das ursprünglich schon angedacht, es geht ja einher mit
der verringerten Anzahl von Instruktionsmodi.


"Berkeley-RISC-Project (aus dem sich SPARC entwickelte)"

Genaugenommen war es das zweite RISC-Projekt (das RISC-II-Design),
welches Sun sich genommen hat und daraus dann den SPARC entwickelte.


"Im Desktop-Bereich haben die RISC-Prozessoren schon längst gewonnen,
da sich die Prozessoren durch die einfacheren Schaltungen und das
Pipelining deutlich höher Takten lassen. Selbst die IA-32 hat die
x86-Instruktionen nur noch in der Software, die aber vor der
Verarbeitung in der ALU vom Decoder in kleinere RISC-ähnliche
Operationen zerlegt werden."

Naja, das kann man natürlich auch anders sehen. Es stellt sich einem
doch sofort die Frage, wieso man dann überhaupt noch den
(unzulänglichen) x86-Aufsatz draufsetzt und nicht gleich nur noch den
RISC-Kern als Komplett-Prozessor verkauft. Das Ganze nur mit der
vorhandenen Software zu erklären, greift wohl nicht (siehe Apple: 68000
-> PowerPC).


Was die PICs von Microchip angeht, so muss man bedenken, dass das eine
uralte Architektur ist, die ja ursprünglich von General Instruments
1975 entwickelt wurde (PIC1650) und somit natürlich den AVRs technisch
stark unterlegen ist.

Autor: Arno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen kleinen Sprung zurück in die Praxis..
habe als Avr Fan immer die PIC`S gemeidet...aber momentan bastle ich an
einem Funkthermometer mit dem PIC 16F684: 1,6 microA   im Sleep Mode
mit laufendem Watchdog der den Pic alle 268 Sekunden weckt,
das schafft kein AVR!!
Arno

Autor: Gerhard Gunzelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der MSP430 sollte da noch besser sein.?

Gerhard

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"das schafft kein AVR!!"

"Der MSP430 sollte da noch besser sein.?"

Das Spielchen könnte man schier endlos ausdehnen.


Ich frage immer zuerst, was brauche ich.
Also z.B. die Batterie hat **Ah und soll **h halten, dann kann ich **µA
verbraten und alles was darunter ist, ist o.k..
Ich suche also nicht das beste, sondern nur das, was gut genug ist.


Peter

P.S.:
Laut Datenblatt zieht der ATTiny2313V mit Watchdog bei 1,8V auch nur
1,8µA.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Batteriebetriebenen Geräten gilt aber auch unabhängig von der
Mindestspezifikation "je länger, desto besser". Der MSP430 kommt bis
in den nA-Bereich runter.

Autor: Arno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Watchdogüberlauf:
ATMega8 ca. 2Sekunden
ATTINY23213 8 Sek.
PIC16f684     268 Sek.!!
Wenn ich nur alle 5 Minuten eine Messung machen muss,ist das schon ein
Unterschied.
Weiterhin kann man beim Pic während der Laufzeit des Programms zwischen
den verschiedenen internen/externen Oszillatoren umschalten.

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich alle 5 Minuten für ein Funkthermometer eine Messung machen
muss, dann nehme ich einen anderen Quarz und habe bei jedem Controller
eine längere Watchdog-Laufzeit.
Du betreibst das Ding doch nicht etwa im Mhz-Bereich?

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ A.K.
Ich denke jetzt müßte ich alle Änderungen an dem MCU-Vergleich gemacht
haben. Hat etwas gedauert, weil ich einige Punkte erst noch überprüfen
wollte.

@ remstal
Was denn, noch ein Namensvetter?
(D.h. ich bin nicht der M.K. aus de.rec.modelle.bahn...)

@ Jochen
"Wobei erwähnenswert ist, das der nach üblicher Definition erste
RISC-Computer die CDC6600 von Thornton und Cray ist"

Stimmt, die CDC6600 war ihrer Zeit weit voraus. Wurde deswegen von IBM
mit viel FUD niedergemacht, wenn ich mich nicht irre, weil sie Angst
hatten, daß ihr noch nicht fertiges System/360 dagegen alt aussehen
könnte.
Ist eigentlich witzig, daß wir damit zwei der wichtigsten Computer in
direkter Konkurrenz hatten. Die CDC6600 als RISC-Vorläufer und die
360er als erste Computerarchitektur, die auch so bezeichnet wurde, und
als erster Computer mit Byte-Adressierung.

"Das erste Projekt eines RISC-Chips ist wohl der IBM801, aus dem auch
einiges in die Power-Architektur geflossen ist."

Auch Korrekt. Allerdings war das meiner Ansicht nach nur ein interner
Prototyp, der erst später der Öffentlichkeit bekannt gemacht wurde.
Außerdem sehe ich POWER/PowerPC fast eher als RISC-CISC-Hybrid.
Der erste kommerzielle RISC-Prozessor war übrigens der ARM.

"Doch, so war das ursprünglich schon angedacht, es geht ja einher mit
der verringerten Anzahl von Instruktionsmodi."

Nicht zwangsläufig. Man hat eben nicht so viele Adressierungsarten und
überwiegend Instruktionen, die mit vollkommen gleichem Layout auf
Registern operieren. Insbesondere bei letzeren kann man sich ordentlich
austoben.

"Genaugenommen war es das zweite RISC-Projekt (das RISC-II-Design),
welches Sun sich genommen hat und daraus dann den SPARC entwickelte."

Kann gut sein, ich habe mich damit nur am Rande beschäftigt.
Iteressant ist allerdings, daß SPARC V1 (?) in bester RISC-Manier auf
Integer-Multiplikation und -Division verzichtet hat. Aufgrund
schlechter Performanz wurden die aber recht schnell nachgeflickt.
ARM und Alpha haben aber bis heute keine Integer-Division und andere
Architekturen (SuperH, PA-RISC, TriCore) zerlegen die Berechnung zwecks
besserer Latenz in einzelne Divisionsschritte.

"Naja, das kann man natürlich auch anders sehen. Es stellt sich einem
doch sofort die Frage, wieso man dann überhaupt noch den
(unzulänglichen) x86-Aufsatz draufsetzt und nicht gleich nur noch den
RISC-Kern als Komplett-Prozessor verkauft."

Die Frage stelle ich mir jedes Mal, wenn ich mir die IA-32 anschaue.
Ich denke mal, daß man es nicht gewagt oder geschafft hat, dem Kunden
eine andere Architektur unterzuschieben. Ansonsten bin ich nämlich auch
der Meinung, daß man spätestens ab dem 386er die Architektur wechseln
und die alten Programme hätte emulieren können.

"Das Ganze nur mit der vorhandenen Software zu erklären, greift wohl
nicht (siehe Apple: 68000 -> PowerPC)."

Genau genommen hat Apple in der Zeit, seit der IBM PC existiert,
bereits die dritte Prozessorarchitektur, da ja vorher der 6502 aktell
war und der Mac erst ca. zwei oder drei Jahre nach dem IBM PC auf den
Markt kam. Ich glaube, daß Apple da einfach Risikobereiter (und beim
Einsatz von Emulatoren auch irgendwie intelligenter) war als die
PC-Hersteller und Microsoft.

Noch idiotischer ist, daß AMDs x86-64 ebenfalls noch mit 2-Adresscode,
variabler Befehlslänge (dank weiterem Präfix von 1 bis 17 Byte) und
immer noch vergleichsweise wenigen Registern ankommt, dabei muß der
64-Bit Instruktionssatz ja zu gar nichts existierendem kompatibel
sein.
Das ist jetzt aber ziemlich off-topic...
Tatsache ist nur, daß die meisten noch aktuellen CISC-Architekturen
intern RISC-Techniken einsetzen, um von der Geschwindigkeit her
mithalten zu können. Insbesondere bei Intel und AMD ginge wohl nichts
mehr ohne das Know-How ehemaliger Alpha-Entwickler.

Bei Mikrocontrollern bin ich mir nicht ganz sicher, obwohl ich mir
nicht vorstellen kann, daß ein Coldfire wie mein alter 68000er
operiert, da die Instruktionen teilweise so viele Taktzyklen fressen,
daß die Latenz-Zeiten äußerst übel wären.

"Was die PICs von Microchip angeht, so muss man bedenken, dass das
eine uralte Architektur ist, die ja ursprünglich von General
Instruments 1975 entwickelt wurde (PIC1650) und somit natürlich den
AVRs technisch stark unterlegen ist."

Vollkommen klar. Ich finde es nur witzig, daß PIC quasi als RISC
angepriesen wird, was aus meiner Sicht einfach nicht der Fall ist.

Mal eine andere Frage zum eigentlichen Thema das Threads:
Wie ist eigentlich die Codequalität das AVR-Backends vom GCC?
Ich weiß nur, daß ich von dem Code das ARM-Backends nicht besonders
begeistert war, als ich von auf meinem RiscPC gearbeitet habe, und das
PPC-Backend scheint selbst nach einigen Änderungen von Apple immer noch
einiges zu wünschen übrig zu lassen.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo wir beim Thema Architektur sind: der MSP430 ist eine ziemlich genaue
Kopie der PDP-11. Irgendwie lustig, dass aus einem schrankgroßen
Stromfresser einer der sparsamsten Prozessoren überhaupt geworden ist.

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"der MSP430 ist eine ziemlich genaue Kopie der PDP-11"

Naja, wie man es nimmt:

auto-decrement und pre-increment fehlen, es sind weniger Instruktionen,
die Multiplikation funktioniert ganz anders...

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die PDP-11 als Vorbild ist wirklich nicht die schlechteste Wahl.IMHO hat
MSP430 die mit reichlich Abstand eleganteste Architektur unter den
8/16-Bit µC.

Wobei man MSP430 freilich auch in der Tradition von TIs eigenem
Minicomputer, der 990-er Reihe, sehen kann (auch 9900). So arg weit war
der auch nicht von der PDP-11 weg, nur nicht annähernd so sauber.

Wenn die eher hardwareseitigen Nachteile nicht wären (3V I/O, wenig
RAM, magere Ausstattung mit Funktionsmodulen vor allem am unteren Ende
der Famile, keine bastelkonformen Gehäuse).

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht sollte man noch die Z8 Encore in den Vergleich aufnehmen.
Kennt sich jemand mit denen genauer aus?

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Michael ("Wie ist eigentlich die Codequalität das AVR-Backends vom
GCC?"): der Code ist, wie man ihn vom gcc erwartet, also etwas größer
und etwas langsamer als nötig. Aber ohne Kompromisse in Zuverlässigkeit
oder Standardtreue. Ich selbst hüte mich, seine Nachteile zu
kritisieren, denn ich selbst habe nichts dazu beigetragen. Der Vorsatz
ist allerdings schon da, wenn ich im Debugger das Compilat betrachte
...

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht sollte man zur MCU-Vergleichsseite noch ein paar
Chip-Empfehlungen hinzufügen.

Hintergrund ist folgender:
Ich habe gerade einen neuen Aufbau mit PIC16F84A bekommen und mußte
feststellen, daß ich ihn mit ICD2 leider nicht programmieren kann...
Ich werde wohl auf den pinkompatiblen 16F627A umsteigen (€3,70).

Wenn man ICD2 und eventuell den PICC Lite von HI-TECH verwenden will,
würden sich vor allem folgende PICs anbieten:
16F877(A), 16F627A (der 16F627 geht mit ICD2 nicht) und 16F684.
Wer es möglichst klein will, die beiden 8-Pin, 12F675 & 12F629, gehen
auch.

@Philipp
Danke und Gruß an einen weiteren Mac-User ;-)
Machst Du Embedded-Programmierung auf dem Mac?
Ich versuche ein hier in der Firma herumliegendes PICkit abzustauben,
da das netterweise mit USB arbeitet.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Folgendes steht in WikiPedia über Philips:
Koninklijke Philips Electronics N.V. (Royal Philips Electronics), kurz
Philips, ist einer der weltgrößten Elektronikhersteller. Philips setzte
2002 31,8 Milliarden € um und beschäftigte 166.000 Menschen in über 60
Ländern. Philips ist in folgende Geschäftsbereiche eingeteilt: Philips
Unterhaltungselektronik, Philips Halbleiter, Philips Beleuchtung,
Philips Medizintechnik und Philips Forschung.

Toll. Und da hat Philips nicht mal das Geld, dass sie einen
deutschsprachigen Mitarbeiter beschäftigt, der sich halbwegs mit ARM
µControllern auskennt.
Wenn man eine Frage hat müsste man irgendwo in Holland anrufen.
Ich glaube die wollen uns verarschen.

Bei Infineon oder Atmel, überall erwischt man jemand in Deutschland
oder Österreich, aber nicht bei Philips.

Tschuldigung, aber das musste raus.

Tschüss

Mario

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Michael: Nein, noch nicht. Mein "prähistorisches" PowerBook hat noch
kein USB und über die LocalTalk-Unterstützung von OS X konnte ich nicht
genug herausfinden, um eine Brücke nach RS-232 zu schlagen. )-: Also
erstmal nicht. (Aber ewig wird das Wally auch nicht halten ...)

@ Mario: Hast Du denn mal in Holland angerufen? Ich habe oft dienstlich
mit NL Firmen (nicht Philips) zu tun und habe noch keinen an der Strippe
gehabt, der sich auf höfliche Nachfrage nicht herabgelassen hätte,
Deutsch mit mir zu sprechen. Und kosten tut das ja heute auch nichts
mehr.

Autor: Peter Gims (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, hier noch eine Info zum Pic. Ich arbeite hauptsächlich mit AVRs,
hab aber mal im Studium mit PICs angefangen. Es ging um Frequenzmessung
und der PIC hatte den Vorteil dass der ext. Counter unabhänig vom
Quarztakt läuft. Beim AVR wird der ClockIn Pin im Quarztakt gesampelt.
So war es möglich mit dem PIC bis zu 40 MHZ zu zählen, wärend beim AVR
bei 1/2 Quarztakt (also max. 8 MHZ) Schluss ist.

cu Peter

Autor: georg siepmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
schade, daß die RISC Serie c166/ST10 fast nur ohne Flash zu erhalten
ist, sonst würde ich diese zu meinem Lieblingcontroller küren. Die
Serie hat ganz viel Pheripherie. So arbeite ich meist mit den Atmel
risc. Die MSP430 benutze ich aus u.g.Gründen (keine Leistungsausgänge
zum direkten Ansteuern von LED's) nicht.
Georg

Autor: Gerhard Gunzelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg

der C167 gehört nicht gerade zu meinen Lieblings- Mikrocontrollern. Bei
der Konfigurationsdatei werd ich fast wahnsinnig. Wenn man ein
Phytec-Board verwenden kann gehts, die liefern gleich das passende
dazu. Aber ich finde die Doku von Siemens/Infineon eine Katastrophe -
zumindest hab ich noch keine vernünftige gefunden - daß man ohne
Probieren die richtigen Einstellungen für selbstdesignte Boards findet.
Da sind mir die PIC's schon lieber.

Gruß
Gerhard

Autor: Kokusnuss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm, ich muss ein Fazit erfragen.
Zwar habe ich kenntnis im bereich Elektronik, aber garnicht im Bereich 
µC.
Nun wollte ich schließlich anfangen und eine kleine Schaltung mit einem 
PIC oder AVR aufbauen. Lerning by doing. Eine fertige platine will ich 
mir keinesfalls kaufen. Nun will ich mit festlegen, denn ich glaube, ich 
werde auch später mit dem µC arbeiten auf den ich mich festlege. Oder 
ist es nicht so, dass man immer den µC benutzt den man gelernt hat?
Jedenfalls wollte ich fragen was mehr sinn macht. Sich in die Materie 
vom PIC oder AVR reinzuhaken?

Autor: Gerhard Gunzelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Kokosnuss

die Frage ist eher, ob für den Heingebrauch oder Bruflich. Berulich ist 
es nach meiner Erfahrung so, dass der uC "schon da ist", das heisst, 
zumeist ist man nicht der Erste, der sich in der Firma mit der Materie 
auseinandersetzt. In meinem Fall zumindest war das so (C167 bzw PIC). 
Dadurch hat sich mir diese Frage nie gestellt. Für den privaten Gebrauch 
ist es so, dass ich mich persönlich von Preisen für Bauteile als auch 
von der Bezugsmöglichkeit und dem Supportleiten lassen würde. Ich kann 
aber nach wie vor nur über die PIC's reden. Wenn du privat oder 
beruflich einen PIC (Menge 1) brauchst, bekommst du den von Microchip 
kostenlos gegen Angabe deines Projektes und wann du vorhast welche in 
Stückzahlen einzusetzen. Für PIC18, 24, 30 und 33 gibts einen 
kostenlosen C-Compiler von Microchip (Studentenversion) und der Support 
im Netz ist ok. Mit dem PICKIT2 hat MIcrochip jetzt auch einen 
bezahlbaren Programmer/Debugger auf den Markt gebracht.  Die PIC16 sind 
preislich günstig aber nicht mehr so ganz state-of-the-art. Die sind 
aber noch ok, um sie in Assembler zu programmieren. An sonsten würde ich 
zum Starten nur PIC18 (z.B. PIC18F1320  (4,40 Euro bei Reichelt) als 
18-pinner oder PIC18F2220 (5,75E bei Reichelt) als 28-pinner verwenden. 
Die Preise liegen damit glaube ich schon deutlich über denen der 
ATMEL's, aber, wie gesagt, gibt es die auch kostenlos von Microchip.

Gerhard

Autor: Igor Metwet (bastel-wastel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Beitrag ist zwar schon uralt, da aber eine aktuelle Anfrage dazu 
kommt, poste ich hier mal einen kleinen (persönlichen) Vergleich 
zwischen den bastlerfreundlichen PICs und AVRs.
(16Fxxx, 18Fxxx) Vergleich:

- ATmegas takten nicht ganz so hoch, benötigen aber weniger Taktzyklen 
für einen Befehl. Damit sind sie etwas schneller als PICs (16Fxxx, 
18Fxxx). Die 16Fxxx haben zudem keine Hardware-Multiplikation. 
Berechnungen werden daher aufendig(Codegröße, Laufzeit).
- ATMegas kosten sehr viel weniger als PICs.
- Für ATmegas gibt es einen kostenlosen C-Compiler. Für die 16Fxxx PICs 
gibts kostenlos eigentlich nur die Demoversion von CC5. Diese ist zwar 
sehr gut, aber eben auf 1k Code begrenzt. Damit lassen sich nur kleine 
Projekte bewerkstelligen. Der SDCC bindet sich nicht in MPLAB ein und 
scheidet daher für mich aus.
- Alle PICs kann man mit zwei Pins in-circuit debuggen. Diese ist nicht 
bei allen AVRs möglich. Deren JTAG benötigt zudem 4 Pins.
- Die Unterstützung ist für PIC und AVR im Internet ziemlich gut.
- PICs haben sehr gute/übersichtliche Datenblätter. Bei den AVRs gibts 
dagegen ein unübersichtliches Fließtext-Datasheet. Das sind wirklich 
zwei verschiedene Welten.


Ich persönlich steige jetzt von PIC auf AVR um. Der Preis und vor allem 
der freie C-Compiler waren für mich ausschlaggebend. Muss ich mich halt 
mit den lumpigen Datenblättern rumärgern ;-)

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kokosnuss:

Hier das gewünschte Fazit:

Wenn du diesen uralten Thread aufmerksam durchgelesen hast, wirst du
festgestellt haben, dass, solange du selber die Wahl hast, es fast
Jacke wie Hose ist, ob du mit AVRs oder PIC arbeitest. Wenn nicht
einer der genannten Vor- oder Nachteile für dich persönlich ein
besonders hohes Gewicht hat, nimmst du am besten den, bei dem dir das
Firmenlogo besser gefällt ;-)

Wenn du Support speziell aus diesem Forum hier erwartest, bist du
vielleicht bei den AVRs etwas besser aufgehoben, da sich hier die
Mehrzahl der Leute offensichtlich auf den AVR eingeschossen hat.
Deswegen gibt es hier ein auch paar gute Einsteiger-Tutorials für
AVRs, und Fragen werden i.Allg. sehr schnell beantwortet. Das heißt
aber nicht, dass du mit einem PIC alleine gelassen wirst.

Du wirst aber sicher woanders im Netz Foren finden, die PIC-lastiger
sind.

Igor Metwet schrieb:

> PICs haben sehr gute/übersichtliche Datenblätter. Bei den AVRs gibts
> dagegen ein unübersichtliches Fließtext-Datasheet. Das sind wirklich
> zwei verschiedene Welten.

Sind die AVR-Datenblätter wirklich so schlecht? Ich komme eigentlich
sehr gut damit zurecht, habe immer schnell die Informationen gefunden,
die ich suchte, und die praktische Umsetzung (bspw. ADC- oder
Timer-Programmierung) hat dank der präzisen Schreibweise fast immer
auf Anhieb funktioniert. Die mir bekannten DBs von C16x und diversen
8051-Derivaten sind nicht besser, die PIC-DBs müsste ich mir mal
anschauen.

Autor: Igor Metwet (bastel-wastel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht ist das AVR Datenblatt nur für mich schwerer zu lesen.

PIC-Datasheets sind so aufgebaut, dass man z.B. beim AD_Wandler-Kapitel 
sofort alle wichtigen Register sieht. Darunter wird jedes Register 
aufgeführt und jedes Bit, bzw. dessen Funktion beschrieben. Das ganze 
ist optisch gut sortiert aufgebaut. Danach kommt noch ne "Checkliste" 
was man alles einstellen muss.
Das ist bei AVRs zwar auch so ähnlich, allerdings ist die 
Übersichtlichkeit bei microchip -meiner Meinung nach- deutlich besser.
Mit der Zeit und Routine kommt man aber wohl mit allen Datenblättern zum 
Ziel - bin da optimistisch ;-)

Autor: Kokusnuss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke an euch.
Ich habe mir bereits ein paar schaltungen angeguckt. Die sehen ja 
allgemein nicht kompliziert aus. Zwar sind mit die verschiedenen werte 
von den einzelden kondensatoren und überhaupt der grund warum die da 
eingesezt sind nicht ganz ersichtlich, aber das kommt wohl mit der Zeit. 
Jedenfalls danke :)

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.