mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR oder PIC


Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

Ich möchte in die Mikrocontrollertechnik einsteigen und habe mal ein 
bisschen was im Netz drüber gelesen.
Für den Einstieg sind wohl AVR oder PICs am besten, da die noch nicht so 
hochkomplex sind aber trotzdem noch zeitgemäß sind.

Aber was ist besser geeignet? PICs oder AVRs
Für welche Plattform stehen mehr kostenlose Entwicklungswerkzeuge zur 
Verfügung und welche ist einfacher zu programmieren/ zu handhaben?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: Robin T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Außerdem könntest du die Suche im Forum benutzen. Gibt massenweise 
solcher PIC vs. AVR Beiträge.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibts für PICs auch eine kostenlose Entwicklungsumbegung vom Hersteller? 
Von Atmel gibts ja AVR Studio welches ich ganz gut finde da man schön 
simulieren kann. Habe in dem AVR Studio auch schon eine "Trockenübung" 
mit dem Simulator gemacht. Ist halt alles Assembler das find ich aber 
nicht so schlimm, da ich C oder was es sonst noch für Microcontroller 
gibt auch nicht wirklich programmieren kann, lernen muss ich also 
sowieso.

Autor: Robin T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MPLAB gibts bei Microchip

Autor: Arne Z. (zachso)
Datum:

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

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVRs haben keinen Bootloader. Den mußt man genauso einprogrammieren wie 
bei PICs, denn auch für die gibt es Bootloader.

Autor: Arne Z. (zachso)
Datum:

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

Autor: Rooney Bob (rooney)
Datum:

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

Autor: Rudi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu beachten ist allerdings das der PIC durch seine Pipelinestruktur nur 
effektiv mit Takt/4 läuft. Wenn es jetzt was extrem schnelles sein soll 
muß das beachtet werden. Ein ATiny bekommt mit 4 MHz locker ein 
FBAS-Videosignal hin, ein PIC braucht 20 MHz.
PS: So weit ich verstanden habe ist diese "Runterreglung" darauf 
zurückzuführen das der PIC auf diese Weise Inkonsistenzprobleme durch 
die Pipeline vermeiden will. Der AVR scheint da Bypässe oder so etwas zu 
haben um den Fall zu vermeiden das z.B. ein Register gelesen wird dessen 
neuer Inhalt noch in der Execute-Stufe herumlungert.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: St182 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Original von :  Travel Rec
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.




Es ist beim PIC auch nicht anders.

Autor: Willi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rudi,
>Ein ATiny bekommt mit 4 MHz locker ein FBAS-Videosignal hin

Da übertreibst du aber etwas, ohne Zusatzhardware schafft der das nie.
Kannst du mir das mal zeigen, oder ist es mehr "Hörensagen"...
Allein der Farbhilfsträger mit 4,43 MHz überfordert den Atiny mit 4 MHZ 
schon völlig. Das schafft nicht mal ein AtMega mit 16MHz.

MfG Willi

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

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

Autor: Rüdiger Knörig (sleipnir)
Datum:

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

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

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

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.