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?
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.
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.
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
AVRs haben keinen Bootloader. Den mußt man genauso einprogrammieren wie bei PICs, denn auch für die gibt es Bootloader.
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
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.
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.
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.
@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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.