AVR oder PIC

Es gibt keine eindeutige Antwort, ohne jemandem zu nahe zu treten. Am 
besten informierst Du Dich beim Hersteller, lädst Dir dort die 
Datenblätter und die Programmiersoftware herunter, guckst Dir alles in 
Ruhe an und vergleichst selber, was für Dich am ehesten in Frage kommt. 
Auf diese Weise habe ich mich damals für die AVRs entschieden.

Bei Microchip gibts zwei Studentenversionen der C-Compiler. Asm-Compiler 
gibts so weit ich weiß auch, beides kostenlos.

für den einstieg in die PIC18 kann ich dir die seite sprut.de empfehlen. 
Bedenke aber bitte dass der einstieg in die PIC's etwas teurer ist als 
der in die AVR da letzter einen Bootloader haben und somit einfacher 
programmiert werden können (kenne mich da aber nicht so super aus, 
benutze selber die PIC) die PIC hingegen brauchen allerdings einen 
Brenner, den gibts allerdings schon für 50€ als Nachbau mit 
debug-funktion (such mal in diversen shops nach ICD2-Nachbau, wirste 
sicher was finden). Die Controllerchips von Microchip an sich sind auch 
noch etwas teurer als die AVR's, microchip schickt dir im gegenzug 
allerdings bereitwillig samples, dauert nur ne weile (Kommen über umwege 
wenn ich das recht verstanden habe). Samples sind kostenlos, dürfen aber 
weder verkauft noch in geräte eingebaut werden die verkauft werden, sind 
also nur für die Übungszwecke gedacht(wobei das beiden meisten Bastlern 
wohl ausreicht).
zuletzt bleibt noch zu sagen dass es für die AVR mehr Homepages etc. 
gibt wo man abgucken kann udn wo fertige projekte zu sehn sind, was auch 
nicht unterschätzt werden sollte. Allerdings gibts so was auch für die 
PIC und wenn man die Programmiersprache erstmal halbwegs kann dann 
interessiert einen der Quellcode von anderen Projekten eh meist nicht.

beide haben also ihr vor-und Nachteile, du musst also abwägen was für 
dich persönlich das besste ist. schreib erstmal das ein kleines programm 
für jeden chip und dann kannst du danach entscheiden welchen du benutzen 
möchtest.

mfg, Zachso

hm, mir war so als ob einige AVR's mit einegebranntem Bootloader 
ausgeliefert werden aber kann auch quark gewesen sein, wie gesagt, ich 
weiß es nicht wirklich.

Bootloader runterladen, reinbrennen, fertig!!

Gibt zahlreiche Bootloader im Netz, die für dich in Frage kommen.

Hab für den PIC18F8722 einen Bootloader geschrieben, der auch auf 
externen Speicher schreiben kann.





----------------------------
www.poms-engineering.at

Ein AVR ist ein echter RISC, der ein Register liest, verändert und 
schreibt - in einem Takt. Einige Sprungbefehle oder 
Hardware-Multiplikation brauchen 2 Takte, da Adressen gesichert bzw. 2x 
auf Register geschrieben wird. Ein paar Sprungbefehle benötigen <=3 
Takte. Im Datenblatt diverser AVRs ist diese Arbeitsweise anschaulich 
beschrieben. Insgesamt ist bei allen AVRs der Kern sehr ähnlich 
aufgebaut, lediglich die Namen und Speicherzellen einiger Register sowie 
der Funktionsumfang variieren von Typ zu Typ. Das macht eine 
Codeportierung auch unter Assembler sehr einfach.

Willi wrote:

> Allein der Farbhilfsträger mit 4,43 MHz überfordert den Atiny mit 4 MHZ
> schon völlig.

Ich vermute mal, er meint hier eher ein (monochromes) BAS.  Da gibt's
aber in der Tat Beispiele, wie man selbst mit einem ATtiny13 noch
einen BAS-Monitor direkt ansteuert.

Das mit dem FBAS-Signal ist kein Scherz. Allerdings meinte ich die 
S/W-Version. Ich hab auf einen Tiny15 schon den recht vielversprechenden 
Anfang eines PingPong-Spiels geschrieben (die beiden Schläger waren 
schon auf dem Fernseher). Gescheitert ist es erst einmal daran das es 
eine dumme Idee war den Reset-Eingang als Eingang für eine 
Steuerungstaste freizugeben.....
4 MHz sind übrigens deshalb eine nette Frequenz weil dann eine 
Zeilenbreite gerade die Zeit zwischen zwei Zählerüberlüfen ist...
Farbe dürfte man mit einem Tiny13 (20 Mhz max.!) oder einem 2313 locker 
hinkriegen.

Was das mit dem Takt/4 beim PIC angeht: auch der PIC ist ein RISC, und 
auch er hat eine Pipeline. Genau die macht ja das Problem. Pipelines 
oder Fließbandverarbeitung nimmt man ja, um den Durchsatz zu steigern. 
Dazu legt man die typischen 4 Schritte bei einer Befehlsausführung 
hintereinander, eben wie bei einem Fließband. Diese Schritte sind 
üblicherweise:
 1. Befehl holen & dekodieren
 2. Operanden holen
 3. Befehl ausführen
 4. Ergebnis zurückschreiben
Probleme gibt es allerdings, wenn benachbarte Befehle 
Datenabhängigkeiten haben. Nehmen wir mal den kurzen Codeabschnitt
 inc r0
 shl r0
In der Pipeline würde das dann so aussehen

1. Takt
 Befehl holen:    inc r0
 Operanden holen: -
 Ausführen:       -
 Zurückschreiben: -

2. Takt
 Befehl holen:    shl r0
 Operanden holen: inc r0
 Ausführen:       -
 Zurückschreiben:

3. Takt
 Befehl holen:    -
 Operanden holen: shl r0
 Ausführen:       inc r0

Genau da ergibt sich ein Problem. Im 3. Takt holt sich shl r0 den Inhalt 
des Registers r0. In diesem sollte eigentlich das Ergebnis von inc r0 
stehen. Doch dieses Ergebnis wurde noch nicht zurückgeschrieben!
Beim PIC hat man sich damit beholfen das man die Pipeline eigentlich ad 
adsurdum geführt hat; jeder Befehl rutscht für sich durch die Pipeline, 
und erst wenn er durch ist darf der nächste ran. Der AVR scheint sofort 
zurückschreiben zu können bzw. evtl. sogar ein Bypass zu haben.
Übrigens: solche Probleme waren der Grund dafür warum man bei der SPARC 
nach arithmetischen Befehlen etc. ein NOP einfügen mußte!

Rüdiger Knörig wrote:

> Das mit dem FBAS-Signal ist kein Scherz. Allerdings meinte ich die
> S/W-Version.

Ja, eben: BAS, nicht FBAS.  Bild-, Austast- und Synchronsignal, aber
keine Farbinformation.  Für die steht nämlich das ,F'.

> Übrigens: solche Probleme waren der Grund dafür warum man bei der
> SPARC nach arithmetischen Befehlen etc. ein NOP einfügen mußte!

Naja, nicht ,Problem', sondern 'design'.  Die Idee dahinter ist, dass
sich ein Programmierer um sowas nicht mehr zu Fuß kümmert, sondern
dass ein optimierender Compiler in der Lage ist, mit solchen
Eigenheiten der CPU zurecht zu kommen, d. h. er wird da keinen NOP
eintragen sondern einen sinnvollen Befehl, der vom Ergebnis des
vorherigen Befehls nicht abhängt.  Ähnliches für Sprungbefehle: da die
Dekodierung des Sprunziels einige Zeit in Anspruch nimmt, kann man
nach dem Sprungbefehl (im delay slot) noch einen weiteren Befehl
unterbringen, der aber vor dem Sprung noch abgearbeitet wird.

Damit kommt man mit einer vergleichsweise einfachen CPU (geringe
Komplexität => geringe Fehleranfälligkeit, geringer Stromverbrauch)
auf gute Performance, indem man diese in den Compiler verlagert.