Hi Zusammen. Ich habe bereits mehr schlecht als recht einige Schaltungen mit PIC aufgebaut und programmiert. Funktionieren tun sie, aber meine Programme sind ein wenig.. naja sagen wir zusammengeklatschtes irgendwas. Ich möchte darum einfach mal so sauber wie möglich programmieren. Mir gefallen die PIC grundsätzlich, da ich nun auch schon einigermassen zu recht komme mit MPLAB und so die üblichen wichtigen Register kenne. Nun meine Frage: Welcher PIC wird von euch am meisten verwendet? Welcher hat sich am meisten bewährt? Ich frage, weil ich definitiv Fragen haben werde und bevor ich mir einen Exot kaufe, frage ich lieber mal nach was ihr so verwendet :) Ob 8, 16 oder 32 Bit ist mir momentan noch nicht so wichtig (geht eher um die kleineren Sachen) vllt. später noch Display ansteuern. Wenn möglich im DIL Gehäuse oder SO wäre auch gut machbar, aller bitte keine TQFP, dafür habe ich einfach nicht die Nerven :) EDIT: Mit Display ansteuern ist (noch) nicht gerade ein RGB Display mit X-Pixel gemeint sondern eher so ein 2, 3 zeiliges :)
der beliebteste PIC? Mein Gott, was ist das denn für eine Frage! Wenn ich eine neue µC-Schaltung aufbaue, dann wähle ich den Prozessor ganz einfach nach den Anforderungen, die ich habe: Anzahl Timer, Port-Pins, Geschwindigkeit usw. Beim Hersteller noch nachschauen, ob das Teil abgekündigt ist und ansonsten bei den Händlern recherchieren, ob genügend das Teil im Angebot haben.
Ja da hast du meinen Text aber gut gelesen. Ich spreche von einem PIC wie man ihn auf einem Entwicklungsboard bekommt. Einfach so ein Allrounder - einer der sich für alle so üblichen Aufgaben wie Uhren, Temperaturanzeige etc. eignet.
> Ja da hast du meinen Text aber gut gelesen. Ich habe das gelesen, was Du geschrieben hast. Wenn ich also eine Antwort parat habe, die Dir nicht paßt, dann liegt das daran, daß Deine Angaben unzureichend waren. Daß es ein Allrounder werden soll für ein Entwicklungsboard kommt erst in Deinem 2. Post. Aber was ist so schwierig dabei, ausgehend von diesen Vorgaben selbst einen passenden PIC auszusuchen? Du könntest z.B. mal schauen, was auf den diversen Entwicklungskits so drauf ist. Oder Dir gleich so einen Kit kaufen.
Dave Chappelle schrieb: > Ich frage, weil ich definitiv Fragen haben werde und bevor ich mir einen > Exot kaufe Wenn Du hier im Forum fragen willst, dann ist jeder PIC ein Exot. Hier sind erheblich mehr AVR-Experten aktiv. Wenn Du in C programmierst, können die natürlich auch eingeschränkt weiter helfen. C ist ja gut portabel. Peter
Die wirklich interessanten IC's haben nun mal alle LQFP mit RM 0,5mm g Kauf die ein paar Rollen Entlötsauglitze und ein paar Tuben Flussmittel und die Teile lassen sich gut löten. Der PIC24 hatte mit mal früher gut gefallen.
Konzentriere mich im Moment auf die PIC24-Serie. Was die Performance angeht schießt man damit manchmal mit Kanonen auf Spatzen, aber der Preisunterschied zum 8-Bitter ist zu vernachlässigen. Dafür ist aber die Architektur und Peripherie deutlich besser als bei PIC16 und PIC18. Welchen 24er ich verwende, hängt von den Anforderungen der jeweiligen Anwendung ab. Und man bekommt viele Modelle noch in DIL.
>Ich spreche von einem PIC wie man ihn auf einem >Entwicklungsboard bekommt. >Einfach so ein Allrounder - einer der sich für alle so >üblichen Aufgaben >wie Uhren, Temperaturanzeige etc. eignet. Sieh' mal bei Beitrag "Pic 16f876 Unterschied" Eine Ergänzung von EV-Board werde ich gleich dort dazuschreiben.
radiostar schrieb: > Aber was ist so schwierig dabei, ausgehend von diesen Vorgaben selbst > einen passenden PIC auszusuchen? Du könntest z.B. mal schauen, was auf > den diversen Entwicklungskits so drauf ist. Oder Dir gleich so einen Kit > kaufen. Ich wäre froh, wenn du weitere Antworten lassen könntest. Du hast augenscheinlich kaum mehr als den Titel überflogen. Peter Dannegger schrieb: > Wenn Du hier im Forum fragen willst, dann ist jeder PIC ein Exot. > Hier sind erheblich mehr AVR-Experten aktiv. > Wenn Du in C programmierst, können die natürlich auch eingeschränkt > weiter helfen. C ist ja gut portabel. Ja, das ist mir auch aufgefallen. Ich programmiere in C, ja. Wenn ich mich hier so umsehe loht es sich wahrscheinlich wirklich fast mir mal einen Brenner für AVR zu zutun und mich da mal reinzulesen. Markus Müller schrieb: > Die wirklich interessanten IC's haben nun mal alle LQFP mit RM 0,5mm g Die Möglichkeiten dazu hätte ich, daran liegt es nicht :D Denkst du an einen bestimmten? Wenn sich der Aufwand lohnt, nehme ich natürlich auch einen solchen.. heinzhorst schrieb: > Konzentriere mich im Moment auf die PIC24-Serie. Was die Performance > angeht schießt man damit manchmal mit Kanonen auf Spatzen, aber der > Preisunterschied zum 8-Bitter ist zu vernachlässigen. Lieber mit Kanonen auf Spatzen als mit Steinschleudern auf Dinosaurier :P Werde mir mal ein paar der 24er Serie anschauen, kannst du einen bestimmten empfehlen? (Wie gesagt so ein bisschen einen Allrounder)
Dave Chappelle schrieb: > un meine Frage: Welcher PIC wird von euch am meisten verwendet? Welcher > hat sich am meisten bewährt? > > Ich frage, weil ich definitiv Fragen haben werde und bevor ich mir einen > Exot kaufe, frage ich lieber mal nach was ihr so verwendet :) Es gibt da keine Exoten, die Pics innerhalb einer Serie sind sehr konsistent und wenn du einen kennst kennst du alle. Es macht mehr Sinn sich mit den einzelnen Funktionen vertraut zu machen. Such dir das Entwicklungsbord deiner Wahl und mach einfach. Es gibt Bords in Hülle und Fülle, sogar mit Steckplätzen für die Arduino shields. Die Kosten sind im Verhältnis zum Zeitaufwand den man reinsteckt ein Witz. Am einfachsten ist die 16F Serie, man kann aber ohne großen Aufwand mit den 18F anfangen. Unter anderem hab ich mir mal dieses hier gekauft. http://de.rs-online.com/web/p/mikrocontroller-prozessoren/0534134/ Ein kleiner "Überblick" was es so gibt: http://de.rs-online.com/web/c/?sra=oss&searchTerm=evaluation+PIC&x=0&y=0
iaoffline schrieb: > ich mir mal dieses hier gekauft. Oke das sieht ja schon mal nicht schlecht aus.. Allerdings würde ich mir lediglich den µC kaufen, damit ich auch schon die Beschaltung etc. für den Einsatz in einer Schaltung zur Hand habe :)
Sieh' mal bei Beitrag "Pic 16f876 Unterschied" Habe dort eine Liste einfacher und preiswerter EV-Board eingestellt, Beitrag Autor: Erich (Gast) Datum: 25.01.2012 15:36 Beitrag "Pic 16f876 Unterschied"
Wenn du einen Allrounder suchst dan wirst du hier im Forum die AVRs am meisten finden. Beliebt sind und meist immer irgendwo zu haben sind z.B.: Atmega32 Atmega8 Atiny2313 Atiny13
Erich schrieb: > Sieh' mal bei Beitrag "Pic 16f876 Unterschied" > > > Habe dort eine Liste einfacher und preiswerter EV-Board eingestellt, > Beitrag Ja, habe mir mal angesehen ziehe ich definitiv auch in Erwägung! Bastler schrieb: > Atmega8 Habe hier in der Tat noch 4 ATMEGA 8-16AU rumliegen. Ich denke ich werde mir mal ein kleies Board dafür ätzen und mal kucken ob ich zurecht komme.
Dave Chappelle schrieb: > Allerdings würde ich mir lediglich den µC kaufen, damit ich auch schon > die Beschaltung etc. für den Einsatz in einer Schaltung zur Hand habe Dann kauf dir bei Reichelt ein paar mit PDIP Gehäuse irgendwas mit 16F am Anfang. Kannst du nichts falsch machen. Dazu das Pickit II (nicht III das taugt weniger) reicht um in Mplab zu debuggen tracen breakpoints zu setzen etc.. Hab mir am Anfang einfach 2x8Pin 16Pin 40 Pin gekauft und dann die Datenblätter gelesen. Das ging mit Steckbrett 2 Wochen dann hab ich mir Demo Boards gekauft.
Die 16er PICS würde ich nicht einsetzen, wenn ich die Wahl habe. Die Organisation des Programmspeichers in 14Bit Worte, machte die Arbeit mit im Speicher abgelegten Tabellen schwieriger. Schöner sind da die PICS der 18er Reihe. Deren Speicher ist ganz normal byteweise organisiert. Einen Lieblings-PIC kann ich dir aber auch nicht nennen. Den folgenden PIC habe ich aber schon mal eingesetzt. Es gibt zwar seid längerer Zeit schon einen PIC18F2580 als Nachfolger zum PIC18F258, aber der PIC18F258 ist im DIL Gehäuse bei Reichelt zu bekommen. Denke schon das man mit diesem PIC viel anfangen kann, allerdings hat er keinen LCD-Controller. Aber ein z.B. charachterorientiertes LC-Displays als Modul bekommt man natürlich trotzdem zum Laufen. PIC 18F258-I/SP ------------------------------- Gehäuse: S-DIL-28 Speicher: 16384x16 Technologie: Flash Temperaturbereich: -40 ... +85 °C Typ: PIC-Controller ADC: 8 MSSP (SPI/I²C): ja Schnittstelle/n: CAN 16-bit Timer: 3 8-bit Timer: 2
Mein neuer Allrounder is der Mega644 im TQFP. Massig Speicher, genug Peripherie... Der PIC16F887 ist bei der IHB wohl sehr beliebt. Ingo
Wenn du mit 3V bzw. 3,3V zurecht kommst, würde ich eine XLP Familie nehmen. Die sind bei Reichelt auch wesentlich günstiger als die "normalen" PIC18Fxxxx. Allerdings haben die kein USB mehr (Es gibt ein paar, die trotzdem noch 5V tolerant sind und USB haben, die kann man aber an einer Hand abzählen). Und man kann sie mit einer einfachen Lithium-Knopfzelle versorgen. Zum Beispiel mit einer CR2032. Wenn du einfach ein paar Typen aufgezählt haben willst, dann schau dir folgende mal an: PIC12F508 (Für absolute Miniprojekte mein Favorit) PIC18F2550 PIC18F4550 PIC18F25K20 PIC18F45K20 PIC24FJ64GA002 PIC24FJ64GB002 PIC33FJ12GP202
Meine beiden Lieblinge, früher 16F84, danach 16F627(A), aber das ist auch schon ein paar Tage her.
Dave Chappelle schrieb: > Nun meine Frage: Welcher PIC wird von euch am meisten verwendet? Welcher > hat sich am meisten bewährt? Ich nehme für jede Aufgabe den dafür passenden. Wenn ich Ethernet haben will, dann gibts einen 18F67J90, wenn ich Audio machen will, kommt ein dsPIC33F mit Stereo-DAC ins System, und wenn ich Rechenleistung brauche ein PIC32MX795, beispielsweise. Immer das, was benötigt wird. Ich verwende keine 16F, wenn ich es nicht muss (aus Kostengründen z.B.), weil die C-Compiler mit dem PIC18F besser zurechtkommen. Im Prinzip ist das so: Kennst Du einen aus der Serie, kennst Du alle. fchk
Also wenn du einen PIC18 beherrscht, dann kannst du mit jedem PIC10, PIC12, PIC16 und PIC18 umgehen, denn die Module sind sehr ähnlich, wenn nicht gleich. Das was sich da so ändert sind Anzahl von ADC-Channels, Speichergröße oder halt speziellere Module wie USB oder so. Meine Allrounder sind PIC18F26K22 (PIC18F26K80 inkl CAN), PIC18F67K22 (PIC18F46K80 inkl CAN) für mehr Pins, PIC18F87K22 (PIC18F66K80 inkl CAN) für noch mehr Pins oder, PIC18F2553 mit USB. Aber man muss halt gucken, ob man USB braucht (oder CAN) oder nicht. Den ultimativen µC gibts nicht. Aber wenn du viele Fliegen mit einer klappe schlagen willst, würd ich den PIC18F46K80 nehmen. 40pol DIP, hat somit bei DIP die meisten IOs und hat noch CAN dabei, 2x USART, 1xSPI/I2C, 5x 10-bit PWM. Allerdings kein USB. Doch es gibt keinen PIC, der USB UND CAN hat, also.. musst du wissen.
OK, wow vielen Dank für die vielen Tipps! Ich sehe, die PIC User sind hier doch nicht so rar wie alle tun :) Wie gesagt, vielen Dank ich werde mir mal die Typen in Ruhe ansehen und dann ein kleines Demo-Board machen.
ich schrieb: > der USB UND > CAN hat, also.. musst du wissen. Also ganz ehrlich, ich habe keine Ahnung was das bedeutet. Heisst das, der µC kann per USB angesteuert werden? Oder kann per USB mit dem PC kommunizieren? Und was ist CAN? Sorry für die trivialen Fragen, ich stehe noch am Anfang :)
Also aus der Historie heraus ist der PIC16F84 mein absoluter Lieblings-PIC. Heutzutage nutze ich allerdings nur noch 16F628a (vor allem wg. den internen Takt), auf welchen ich Programme dieses Klassikers relativ einfach portieren kann. Für einfache Anwendung fahre ich damit (auch heutzutage) immer noch am besten. Dazu wäre vielleicht die Website sprut.de zu erwähnen, ohne jene ich wahrscheinlich nie damit angefangen hätte. Allerdings programmiere ich ausschließlich in Assembler. Wenn es komplexer wird oder/und ich viele Pins brauche, greife ich zum bereits hier erwähnten Atmega644, allerdings im DIL-Gehäuse. Den programmieren ich dann ausschließlich in C, da es den gcc dafür gibt und eben komplexere Sachen (Fließkommaberechnungen o.ä.) mir in Assembler zu kompliziert sind. In C finde ich manche Dinge allerdings komplizierter als in Assembler: Finde es z.B. total umständlich dort nur ein einziges Bit zu setzten oder löschen. Habe schon etwas gebraucht, bis ich das durchblickt habe.
Sebastian Hepp schrieb: > PIC12F508 (Für absolute Miniprojekte mein Favorit) Meiner is da PIC12F1840. Der is schnell, interner Oscillator und kann I²C und PWM über Module gleichzeitig, liegen bei der Belegung also nicht zusammen auf einem Pin. Damit will ich Mini-I²C->PWM Module bauen. Braucht nichts, außer den PIC, nen R und n MOSFET ;) Kevin schrieb: > früher 16F84... Ich liebe ja PIC, aber dieser war der Standard-PIC in der Ausbildung EGS und ich habe ihn gehasst. Klein, langsam, ohne internen oscillator usw...
Dave Chappelle schrieb: > Also ganz ehrlich, ich habe keine Ahnung was das bedeutet. > Heisst das, der µC kann per USB angesteuert werden? Oder kann per USB > mit dem PC kommunizieren? Und was ist CAN? USB heißt, er hat ein USB-Modul in sich drinne. Also hat der PIC verschiedene USB-Modul-Spezifische SFR (Special Function Register) wo z.B. die PID oder VID gespeichert ist. Das erleichtert ein anbinden über USB (sodass dein PIC ein USB-Slave ist, also ein PC-Steuerbares Gerät) and den PC. Nur dazu muss man schon n bisschen fitter sein in PIC (und auch PC) Programmierung. CAN ist ein Bus, ähnlich wie RS232. Am besten du guckst hier auf der Seite bei den Artikeln oder bei wiki.
Dave Chappelle schrieb: > Sorry für die trivialen Fragen, ich stehe noch am Anfang : Dann such dir nicht die eierlegende Wollmilchsau, sondern fange mit einem einfachen an. Lass erst mal ein paar LEDs blinken, Tasten entprellen und eine Zustandsautomat programmieren bevor du ein Motorsteuergerät baust das über Bluetooth vom Smartphone die Parameter verstellt kriegen kann.
@Dominik P. (koelner) >In C finde ich manche Dinge allerdings komplizierter >als in Assembler: >Finde es z.B. total umständlich dort nur ein einziges >Bit zu setzten oder löschen. Warum ??? 2 Beispiele: PORTB |= 0b00000001; // RB0 == ein PORTB &= ~0b00000001; // RB0 == aus Geht natürlich auf bei Variablen genauso.
Peter Dannegger schrieb: > Wenn Du hier im Forum fragen willst, dann ist jeder PIC ein Exot. Also das PICs Exoten sind -auch hier im Forum- halte ich für ein Gerücht. In der Masse mag es zwar mehr AVR Nutzer geben, aber wenn man nur die vergleicht die Ahnung haben dann dürfte das Bild schon recht ausgewogen sein. Es gibt natürlich auch unter den PICs welche die sind eher "allrounder" und welche die sind schon speziell. Allerdings ist es tatsächlich so das es bei PICs wenige gibt die nur "den EINEN" einsetzen. Die PICs zeichnen sich gerade durch eine sehr breite Peripheriepallete aus und sind selbst mit ausgefallenerer Hardware immer noch leicht zu beschaffen. (Vgl. mal die Bezugsquellen für Privatleute für USB AVR mit denen für USB PIC). Da der Kern innerhalb der Familie aber gleich ist gibt es keinen Grund sich Einzuschränken. Ohne jetzt einen neuen AVR vs. PIC Thread vom Zaun zu brechen, so ist es doch bei den meisten Hobbyiste unter den AVR USERN das die wirklich nur ihre 1-3 Typen haben die sich fast nur im Gehäuse unterscheiden und sich alles andere darum bauen. Will man Ethernet nimmt man halt noch einen zusätzlichen Controller (z.B. ENC28J60) Will man USB greift man zum FTDI Wandler usw... Aber im Zentrumm steckt immer derselbe AVR. Wenn ich als PIC user (der natürlich ab und an auch AVR verbaut) USB brauche, dann nehme ich einen PIC mit USB Schnittstelle, der dann 10 Cent mehr kostet als der Ohne. Brauche ich Ethernet, dann nehme ich den PIC mit Ethernet. Will ich sogar einen USB HOST Realisieren, dann nehme ich einen PIC der das bietet. Die bekomme ich als Privatman sogar alle bei Conrad oder REichelt, von den vielen kleinen Händlern ganz zu schweigen! (Wobei ich selbst aber beim Großhandel/Distri kaufen kann) Aber BTT: DEN einen PIC kann man nicht nennen. Jahrelang war dies zwar der PIC16C84/PIC16F84, einfach deshalb weil der erste bequem wiederprogrammierbare war den man auch noch mit einem EinfachstCOM Adapter nur aus drei Widerständen und einer Diode (wenn ich das noch richtig im Kopf habe) Programmieren konnte. Aber dieser Typ ist-obwohl noch hergestellt- heute absolut veraltet, das war der schon vor 10 JAhren. Nur noch von Interesse wenn man ganz alte Schaltungen nachbauen will. Wenn Lernen willst C auf Mikrocontrollern zu programmieren würde ich zum Einstieg die PIC18F Serie empfehlen. Die ist für C Optimiert, es gibt reichlich Lernbeispiele und Demoapplikationen aber die mit der Peripherie verbundenen Register sind noch sehr übersichtlich. Die PIC24 haben technisch gesehen zwar WIRKLICH vorteile, bieten vielleicht sogar das beste Preis Leistungsverhältniss, aber die größeren Möglichkeiten schlagen sich wieder in erhöhten Einstiegsschwierigkeiten nieder. Ein Fahranfänger lernt zu Anfang ja auch mit einem Golf besser als in einem Formel3000 Rennwagen. Davon Abgesehen sind die Nutzer der PIC24 weit weniger Zahlreich. PIC32 ist noch Leistungsfähiger, aber noch einmal etwas Komplizierter für den Einstieg. Ausserdem möchtest du ja gerne DIP, das ist bei den 32 gar nicht -und bei den 24er nur noch bei wenigen Typen- als Gehäuse vertreten. Bei den 16ern und 18ern ist der weit größte Teil noch in DIP verfügbar. Selbst mit Spezialfunktionen! PIC16 kann man zwar in C Programmieren, aber sehr viele Vertreter sind noch auf direkte Assemblerprogrammierung ausgelegt, Vorteile für C bieten erst die neuesten... Daher würde ich dir noch einmal zu der 18F Familie raten. Wenn du jetzt dann eine Typempfehlung möchtest nenne ich dir mal die drei Typen die ich für "allgemeine" Bastelleien am Häufigsten einsetze. 1. Den PIC18F4550. 40 Pinner mit USB Schnittstelle. Gerade für diesen gibt es viele Beispiele. NAtürlich kann er auch völlig ohne USB Funktion genutzt werden, ist aber eher verschwenndung. Pinnkompatibel zu allen anderen 40PIN Pics. Der ist 5V Kompatibel (läuft natürlich auch mit 3V) und sowohl in DIP wie auch in TFQP verfügbar. Kostet bei REichelt als DIP40 gerade 4,85Euro 2. den PIC18F45K20 Das ist so ein Universal-Feld Wald-WiesenPIC. 40 Pinner, Pinnkompatibel zum 18F4550 (bis auf die USB Funktion natürlich) bietet alle Standarddinge die heutige µC so haben (internen OSzillator mit PLL, EEPROM, Alle möglichen Schnittstellen) hat etwas mehr Speicher als der 18F4550 und kostet einiges weniger. 2,15 Euro. Dies ist allerdings ein reiner 3V Typ, 5V verträgt er -au s eigener Erfahrung- zwar kurzzeitig, aber niemand weiß wie lange. Es gibt auch eine ältere 5V Version davon, den 18F4520, der ist aber einiges Teurer. 3. den 18F13K50 Dies ist der "KLEINSTE" USB PIC der 18er Reihe. Verfügbar in 20Pin DIP. Bietet halt auch die ganzen Standartmäßigen µC sachen und eine USB Schnittstelle. Dazu recht günstig. Diesesn Setze ich sogar ab und an mal eine wenn ich gar kein USB brauche. Aber auch als reiner COM-USB Wandler habe ich den schon Missbraucht. Demo Programm von Microchip drauf und du hast für 2,15 einen UART-USB Wandler im DIP Gehäuse den du wirklich fast in jedem Elektronikgeschäft kaufen kannst. Preis wie geschrieben: Bei REichelt 2,10 Euro Es gibt natürlich noch eine Reihe mehr... z.b. mit Ethernet usw. Aber mit diesen Drei kannst du schon eine Menge anfangen. Im Übrigen gibt es von Microchip so einiige Beispielcodes und sogar richtige C Library funktionen zum Ansteuern von LCD Textanzeigen. (Weil du darauf hingewiesen hast) Es gibt ja von Microchip als Einsteigerset auch das PICKIT3 DebugEXpress KIT wo neben dem PICKIT auch eine kleine Experimentierplatine und Übeungsprogramme dabei sind: Auf dieser Platine ist auch ein 18F45K20 (allerdings TQFP) Mein TIP: Besorge die ein paar 18F45K20 und baue mit einem die Übungsplatine auf Lochraster nach und nutze die Demoprogramme dann als Ausgangsbasis für erste Versuche in dem du die immer weiter abänderst. Schaltplan und Übungssoftware sind frei erhältlich http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 (Schaltplan ist im UserGuide drin) Dann hast du für 5Euro MAterialkosten direkt einen Einstieg... Wenn du dann mit USB weitermachen willst besorgst du dir den Schaltplan und die Software des LowPin COunt USB Dev. Kits, Hier wird der PIC18F13K50 verwendet und arbeitest damit. Software und Schalplan sind wieder frei erhältlich http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en536385 Wieder ist man auf Lochraster für unter 5Euro dabei ;-)! Danach sollte dann genug Erfahrung vorhanden sein um sich völlig frei zu bewegen ;-) Gruß Carsten
Dave Chappelle schrieb: > ich schrieb: >> der USB UND >> CAN hat, also.. musst du wissen. > > Also ganz ehrlich, ich habe keine Ahnung was das bedeutet. > Heisst das, der µC kann per USB angesteuert werden? Oder kann per USB > mit dem PC kommunizieren? Und was ist CAN? Das heißt, dass eine USB-Einheit drin ist, die es erlaubt, den PIC als USB-Device zu betreiben. Heißt: Du kannst ihn mit der passenden Software (gibts kostenlos von Microchip) an PCs anschließen und damit eine Maus, Tastatur, Drucker, ... bauen, aber Du kannst nicht selber USB-Mäuse, -Tastaturen etc anschließen. Dazu müsste der PIC ein USB-Host sein, und das kann er nicht. Komplette USB-Host-Stacks sind sehr umfangreich und groß und deswegen eher auf größeren Controllern zu finden. CAN und LIN sind Bussysteme aus der KFZ-Elektronik und der Industrie. fchk
Erich schrieb: > @Dominik P. (koelner) > >>In C finde ich manche Dinge allerdings komplizierter >>als in Assembler: >>Finde es z.B. total umständlich dort nur ein einziges >>Bit zu setzten oder löschen. > > > Warum ??? > 2 Beispiele: > > > PORTB |= 0b00000001; // RB0 == ein > > PORTB &= ~0b00000001; // RB0 == aus > > > Geht natürlich auf bei Variablen genauso. Oder man macht es noch einfacher... LATBbits.LATB1 = 1 // RB1 == ein LATBbits.LATB1 = 0 // RB1 == aus Wenn man es lesbarer haben will und öfter die selben IOs ändern möchte an denen evtl. feste HArdware sitzt macht man es so... Ich schreibe EINMAL im Header "IRGENDWAS.H" #define ON 1 #define OFF 0 #define STATUS_LED LATBbits.LATB1 Und im Programm brauche ich dann nur noch schreiben STATUS_LED = ON; ... ... STATUS_LED = OFF; ICh schreibe selber gerne und auch noch viel SW in Assembler, aber DAS mit den IO Toggeln inst nun wirklich kein Argument... In C ist das DEUTLICH einfacher und vor allem LESBARER! Das von mir als zweites gebrachte Beispiel versteht wohl jeder bei ersten Hinsehen Gruß Carsten
Wow, die Diskussion scheint ja recht Potenzial zu haben! Also mal zur Erklärung: Ich bin kein kompletter Anfänger. In C komme ich eigentlich schon ziemlich gut zu Recht, auch wenn mir natürlich noch vieles nicht geläufig ist. Benutzt habe ich bis jetzt den PIC16F690 und den PIC16F767 - den letzteren mit gemässigter Begeisterung. Carsten Sch. schrieb: > den PIC18F45K20 Das ist so ein Universal-Feld Wald-WiesenPIC. Ja das scheint mir so ziemlich nach dem µC nachdem ich gesucht habe. Und komme ich dann etwas besser zu Recht Carsten Sch. schrieb: > Den PIC18F4550. 40 Pinner mit USB Schnittstelle. werde ich mir definitiv diesen zu tun. Anfangen werde ich einfach mit LED durch Mausklick an und ausschalten etc. Ich denke da wird noch einiges an Stoff zu lesen geben :) Danke an alle für die vielen Vorschläge und die rege Beteiligung.
Frank K. schrieb: > Das heißt, dass eine USB-Einheit drin ist, die es erlaubt, den PIC als > USB-Device zu betreiben. Heißt: Du kannst ihn mit der passenden Software > (gibts kostenlos von Microchip) an PCs anschließen und damit eine Maus, > Tastatur, Drucker, ... bauen, aber Du kannst nicht selber USB-Mäuse, > -Tastaturen etc anschließen. Dazu müsste der PIC ein USB-Host sein, und > das kann er nicht. Komplette USB-Host-Stacks sind sehr umfangreich und > groß und deswegen eher auf größeren Controllern zu finden. > > CAN und LIN sind Bussysteme aus der KFZ-Elektronik und der Industrie. D.h. ich kann den PIC über PC steuern jedoch nicht den PC über PIC :)?
Dave Chappelle schrieb: > Markus Müller schrieb: >> Die wirklich interessanten IC's haben nun mal alle LQFP mit RM 0,5mm g > > Die Möglichkeiten dazu hätte ich, daran liegt es nicht :D > Denkst du an einen bestimmten? Wenn sich der Aufwand lohnt, nehme ich > natürlich auch einen solchen.. Wie ja (fast) alle hier wissen favorisiere ich den STM32Fxxx, 250 verschiedene Typen und jede Menge umfangreiche Peripherie drin. Artikel: STM32 Aber das ist jetzt eine Ecke größer als der PIC. Für mich hat sich der Aufwand gelohnt. Nie wieder überlegen müssen ob der Speicher oder die Peripherie reicht, es ist einfach alles da. Die Chip kosten sind auch überschaubar und nur wenig teurer als der PIC. Bevor Du dich jetzt auf einen PIC voll und ganz konzentrierst solltest Du den STM32 mal anschauen. AVR brauchst Du nicht unbedingt anschauen, denn der ist in etwa gleich. Zwischen AVR/PIC gibt es ohnehin nur einen Glaubenskrieg ohne wirklich fundamentale Hintergründe. (Außer, wenn Du den Prozi gewerblich nutzen willst, würde ich von Atmel abraten, wegen der deutlich schlechteren Verfügbarkeit.)
Frank K. schrieb: > Dave Chappelle schrieb: >> ich schrieb: >>> der USB UND >>> CAN hat, also.. musst du wissen. > >> Also ganz ehrlich, ich habe keine Ahnung was das bedeutet. >> Heisst das, der µC kann per USB angesteuert werden? Oder kann per USB >> mit dem PC kommunizieren? Und was ist CAN? > > Das heißt, dass eine USB-Einheit drin ist, die es erlaubt, den PIC als > USB-Device zu betreiben. Heißt: Du kannst ihn mit der passenden Software > (gibts kostenlos von Microchip) an PCs anschließen und damit eine Maus, > Tastatur, Drucker, ... bauen, Eine Ergänzung hier noch: Für die USB PICs gibt es auch noch die BOOTLOADERFUNKTION. Wenn man es möchte, z.B. zum einfacheren Experimentieren, dann Programmiert man sich EINMAL den BOOTLOADER auf den USB PIC und kann dann ohne Programmiergerät, direkt über die USB Schnittstelle aus MPLAB Heraus den PIC Programmieren. Für Anfänger manchmal ganz nett, wenn auch eindeutig nicht der Haupzweck der USB Schnittstelle. Die soll wirklich für eigene USB Geräte sein. Im gegensatz zu manchen anderen µC mit USB und Bootloadermöglichkeit ist hier aber der BL weder vorinstalliert noch gar fest als ROM vorhanden. Man muss ihn also mindestens einmal mit ienem "normalen" Programmiergerät beschreiben bevor man die Option nutzen kann. Die USB Programmierung mit MC.PICS ist im übrigen wirklich Easy! Frank K. schrieb: > Dazu müsste der PIC ein USB-Host sein, und > das kann er nicht. Komplette USB-Host-Stacks sind sehr umfangreich und > groß und deswegen eher auf größeren Controllern zu finden. Naja- PIC ALLGEMEIN können USB Host schon. Allerdings nur die etwas Leistungsfähigeren PIC24 und PIC32. Für die 8Bit PICs (16F und 18F) stimmt das ohne Ausnahme, die können kein HOST darstellen! Gruß Carsten
Du solltest mit was möglichst einfachem und überschaubarem anfangen. Das hier ist das DM164120-4 , die bereits benannte Platine aus dem anderen Beitrag Beitrag "Pic 16f876 Unterschied" http://i46.photobucket.com/albums/f103/KQ6WQ/PIC%20Micro/DSCF0027.jpg Ist inzwischen mit dem Pic16F1827 bestückt bei Neukauf, und mit diesem Chip gelingt es auch einfache Lochrasteraufbauten selbst fehlerfrei zu erstellen, dank DIP-18 Gehäuse (eine der Gehäusevarianten). USB, CAN, LIN, schnickschnack, das ist dann was in 3-6 Monaten für dich. Lediglich ein Pickit3 brauchste noch dazu.
Carsten Sch. schrieb: > Ausserdem möchtest du ja gerne DIP, das ist bei den 32 > gar nicht -und bei den 24er nur noch bei wenigen Typen- als Gehäuse > vertreten. Das stimmt so nicht ganz;) PIC32MX110F016B, PIC32MX210F016B, PIC32MX220F032B und PIC32MX120F032B sind im DIP28 zu haben. Dave Chappelle schrieb: > D.h. ich kann den PIC über PC steuern jedoch nicht den PC über PIC :)? Du kannst mit dem PC Daten zum PIC schicken und er kann Antworten. Du brauchst passende Software für den PIC und einen Treiber und ein Programm für den PC. Hilfreich ist ein Standardtreiber wie HID, sodass du es an jeden Rechner anschließen kannst und er ohne extra Treiberinstallation läuft. Doch trotzdem ist das absolut kein Anfängerprojekt (aber man kann es als ansporn und motivation im Hinterkopf behalten;) )
Markus Müller schrieb: > Wie ja (fast) alle hier wissen favorisiere ich den STM32Fxxx, > 250 verschiedene Typen und jede Menge umfangreiche Peripherie drin. > Artikel: STM32 > ... > Bevor Du dich jetzt auf einen PIC voll und ganz konzentrierst solltest > Du den STM32 mal anschauen. STM32 sind SPÄTER für Ihn sicher zumindest mal ein Blick Wert. GEnauso wie die PIC32 (je nachdem was einem liegt, oder wie bei mir je nach Anforderung) Aber für einen Einsteiger, insbesondere wo man doch auch Wissenlücken bei den Grundlagen deutlich erkennen kann, da ist ein 32Bitter schon ein wenig Heavy! Insbesondere dann noch STM oder LPC wo der Support auf Einsteigerniveau doch deutlich geringer ist als bei fast jedem gängigen 8Bitter. Gruß Carsten
Also ich mache jetzt mal den Versuch: ATMEGA8-16AU und PIC18F45K20 werde ich mir ein kleines Board machen. Zuerst der eine nachher dasselbe auf dem anderen. Mal sehen mit was ich besser zu Recht komme und das nehme ich dann einfach. Markus Müller schrieb: > Wie ja (fast) alle hier wissen favorisiere ich den STM32Fxxx, > 250 verschiedene Typen und jede Menge umfangreiche Peripherie drin. > Artikel: STM32 Ist nett gemeint aber wirklich anfangen kann ich damit wirklich nix im Moment. Ist auch nicht gerade so der Anfänger-Baustein wenn ich mir so den Artikel ankucke :)
> Also mal zur Erklärung: Ich bin kein kompletter Anfänger. In C komme ich > eigentlich schon ziemlich gut zu Recht, auch wenn mir natürlich noch > vieles nicht geläufig ist. > ATMEGA8-16AU und PIC18F45K20 werde ich mir ein kleines Board machen. > Zuerst der eine nachher dasselbe auf dem anderen. Mal sehen mit was ich > besser zu Recht komme und das nehme ich dann einfach. Den perfekten Einstieg/Umstieg gibt es eh nicht. Wenn Erfahrungen vorhanden sind, warum dann nicht gleich den Umstieg auf 32-Bit? PIC32 gibt es auch in DIP. Oder: Ein PIC32 mit Pinguino ist recht schnell und einfach aufgesetzt, und der Weg zu "direktem" Einsatz ist auch möglich. Schau Dir mal den PIC32 Pinguino Micro an.
Carsten Sch. schrieb: > Erich schrieb: >> @Dominik P. (koelner) >> >>>In C finde ich manche Dinge allerdings komplizierter >>>als in Assembler: >>>Finde es z.B. total umständlich dort nur ein einziges >>>Bit zu setzten oder löschen. >> >> >> Warum ??? >> 2 Beispiele: >> >> >> PORTB |= 0b00000001; // RB0 == ein >> >> PORTB &= ~0b00000001; // RB0 == aus >> >> >> Geht natürlich auf bei Variablen genauso. > > Oder man macht es noch einfacher... > LATBbits.LATB1 = 1 // RB1 == ein > LATBbits.LATB1 = 0 // RB1 == aus So habe ich das noch nicht gesehen und bezweifle, dass allgemein immer so einfach geht (zumindest beim gcc). Das sind vordefinierte Strukturen? Im AVR-GCC Tutorial ist das u.a. so beschrieben, wie man es auch häufig liest:
1 | #include <avr/io.h> |
2 | ... |
3 | PORTB = PORTB | ( 1<<PB2 ) */ |
4 | /* vereinfacht durch Nutzung des |= Operators : */ |
5 | PORTB |= (1<<PB2); |
6 | |
7 | /* auch mehrere "gleichzeitig": */ |
8 | PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */ |
9 | |
10 | "Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog: |
11 | |
12 | #include <avr/io.h> |
13 | ... |
14 | PORTB &= ~(1<<PB2); /* löscht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ |
15 | PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */ |
Allein, dass man zum Setzen/Löschen immer ganze Oder- ,Und- und Nicht- Byte-Verknüpfungen in C braucht, ist sehr gewöhnungsbedürftig. Dann noch die Kurzschreibweise durch diese 'speziellen' Operatoren |= und &=. Die Bit-Verschieberei setzt dem ganzen noch die Krone auf (und so liest man das tatsächlich oft, insbesondere wenn spezielle Options-Register eingestellt werden in einer Zeile). Ich habe zumindest einige Zeit gebraucht um das zu verstehen, als ich sowas es das erste mal in C gesehen habe (und vorher nur Assembler gewöhnt war). Da lobe ich mir doch mein PIC-Assembler, wo ich einzelne Bits einfach so setze: bsf PORTA,0 bcf PORTA,1
Frank K. schrieb: > Wenn ich Ethernet haben will, dann gibts einen 18F67J90 Du meinst PIC18F97J60, oder ? ;-) Grüße Andreas
Andreas schrieb: > Frank K. schrieb: >> Wenn ich Ethernet haben will, dann gibts einen 18F67J90 > Du meinst PIC18F97J60, oder ? Äh, ja, klar. fchk
ich schrieb: > Doch es gibt keinen PIC, der USB UND > CAN hat, also.. musst du wissen. das halte ich für ein Gerücht... z.B. dsPIC33EP256MU806 1x USB, 2x CAN oder PIC32MX775F256H 1x USB OTG, 2xCAN, 1x 10/100 Ethernet
ich bin von den PIC16 & PIC18 ausgegangen. Bei PIC32 gibta klar einen der mehr kann. und bestimmt auch woanders.
Dominik P. schrieb: >> Oder man macht es noch einfacher... >> LATBbits.LATB1 = 1 // RB1 == ein >> LATBbits.LATB1 = 0 // RB1 == aus > > So habe ich das noch nicht gesehen und bezweifle, dass allgemein immer > so einfach geht (zumindest beim gcc). Das sind vordefinierte Strukturen? Doch, es geht so einfach:
1 | #include "sbit.h" |
2 | |
3 | |
4 | int main( void ) |
5 | {
|
6 | DDR_B3 = 1; // output |
7 | DDR_B7 = 1; |
8 | |
9 | for(;;){ |
10 | PORT_B3 = PIN_D0; |
11 | PORT_B7 = !PIN_D0; |
12 | }
|
13 | }
|
Allerdings sind die nötigen Definitionen beim AVR-GCC nicht von Haus aus drin. Anbei die benötigte "sbit.h". Peter
Hi >Da lobe ich mir doch mein PIC-Assembler, wo ich einzelne Bits einfach so >setze: >bsf PORTA,0 >bcf PORTA,1 Und ich den AVR-Assembler, wo ich einzelne Bits einfach so setze: sbi PortA,0 cbi PortA,1 MfG Spess
Ohhh... der Thread verkommt mal wieder zum sinnfreien PIC vs. AVR-Schlagabtausch. Moment! Hole schnell Chips und Cola aus dem Keller...
So, da ich selber erst vor kurzem mit PIC's Angefangen habe, habe ich mich erstmal ein wenig nach Tutorials umgeschaut. Dabei sind besonders der PIC18F2550, PIC18F4550 und der dsPIC30F4011,dsPIC30F4013 aufgetaucht. Ich habe mir dann für den Anfang den PIC18F4553 und den dsPIC30F4011 sowie später noch den größten der PIC32MX die im DIP vorhanden sind geholt. Somit habe ich von allen größeren Bit Familien ein paar Exemplare. Gründe für den PIC18F4553 waren das er noch ein wenig mehr kann als der PIC18F4550 (aber sich in vielen Punkten nicht unterscheidet (dadurch leichteres umsetzen der Tutorials auf den 4553) und für den dsPIC30F4011 gegenüber dem anderen dsPIC das sich der dsPIC30F4011 besser für Roboter und Motor Ansteuerungen eignet der 4013 hat z.B dafür AC97 und son kram. Alle genannten PIC's sind 5V Varianten (bis auf den PIC32MX).
... MEINER IST GRÖSSER ...
> Hole schnell Chips und Cola aus dem Keller...
Die habe ich sicherheitshalber schon griffbereit
Peter Dannegger schrieb: > Dominik P. schrieb: >> So habe ich das noch nicht gesehen und bezweifle, dass allgemein immer >> so einfach geht (zumindest beim gcc). Das sind vordefinierte Strukturen? > > Doch, es geht so einfach: > [c] > #include "sbit.h" [..] > Allerdings sind die nötigen Definitionen beim AVR-GCC nicht von Haus aus > drin. Anbei die benötigte "sbit.h". Wie ich vermutet habe, sind das (mehr oder weniger) "selbstgestrickte" Strukturen. Damit arbeitet man im allgemeinen nicht. Zudem beinhaltet die sbit.h ja nur die Port-Register. Für jede selbstdefinierte Variable müsste man das dann entsprechend erweitern. Insofern finde ich für einfache Zwecke Assembler immer noch deutlich einfacher.
MCUA schrieb: > Was ich nicht kapiere, warum gibt es bei keinem PIC ein ordentliches > ExternBusInterface? Meinst du sowas wie DMA? Wenn ja dann haben die das doch.
Angefangen habe ich mit 16F84, davon habe ich noch ein paar da, verwende sie auf Grund der beschränkten Resourcen nur noch für kleine, schnelle Sachen. Mein Arbeitstier ist zur Zeit noch der 16F876, welcher aber demnächst durch den 18F25K22 abgelöst wird. Bin gerade dabei, mich in das etwas andere Innenleben der PIC18 einzuarbeiten. Als USB-Seriell-Wandler habe ich schon ein paarmal den 18F14K50 verbaut. Mit dem USB-Framework von Microchip lässt sich schnell ein Schnittstellenwandler bauen, der billiger als ein FTDI 232 und dazu noch in DIP zu haben ist. Ansonsten gilt das oben schon gesagte. Die Unterschiede innerhalb einer Familie sind minimal, ..."kennst du einen, kennst du alle...". Wenn mal besondere Anforderungen im Raum stehen, kann man sich auf der Microchip-Seite den passenden raussuchen. Ein nicht unerhebliches Auswahlkriterium für mich ist die Beschaffung. Deshalb nehme ich i.d.R. nur Typen, die Reichelt hat.
MCUA schrieb: > Was ich nicht kapiere, warum gibt es bei keinem PIC ein ordentliches > ExternBusInterface? Weil genau sowas bei dieser Architektur nicht vorgesehen ist. Ursprünglich hatte Microchip 2 verschiedene Architekturen vorgesehen, eine "zentrale" (so nenn ich das mal einfach), die irgendwann untergegangen ist und eine Architektur für "periphere" Dinge, also Bausteine, die als Peripherie-IC's in einem größeren System drinhängen. Daraus sind dann die PIC's entstanden. Guck mal bei den etwas hochpoligeren PIC's, da wirst du einen Port finden, der als 8 Bit Parallelport konfigurierbar ist (PortD für die Daten und PortE für die Steuersignale). Ursprünglich was das so gedacht, daß ein übergeordneter Controller über genau diesen Port dem PIC was sagt bzw. ihn abfragt. und nochwas: Dominik P. schrieb: > Insofern finde ich für > einfache Zwecke Assembler immer noch deutlich einfacher Ja, so meine ich auch. Allerdings hatte ich mir in den 90ern bereits eine eigene Gleitkomma-Lib für die PIC16er geschrieben und damit gehen dann auch anspruchsvollerer Anwendungen auf dem PIC in Assembler. Aber es ist wohl zwecklos, mit AVR-Anhängern darüber zu reden. Also Schwamm drüber.. Wenn ich was größeres als nen PIC16 brauche, greife ich mittlerweile zu Arms oder neuerdings zu Cortexen (Nuvoton und NXP). Da ist kein Platz mehr für AVR's - und eigentlich auch keiner mehr für PIC18 und aufwärts. Klar, ich sehe ein, daß oft die Beschaffungsfrage das Ausschlaggebende ist, gerade wenn man als Bastler ein Teil braucht und es dann bei Sander&Co kaufen muß. Ne Menge Distributoren reden ja nicht mal mit nem Privaten. Ist eigentlich ein elendes Ärgernis. W.S.
@w.s wozu disti? Samples verschickt atmel meist innerhalb 2wochen, den rest hol ich mir bei katalogdistis
Hi, Dominik P. schrieb: > Peter Dannegger schrieb: >> Dominik P. schrieb: >>> So habe ich das noch nicht gesehen und bezweifle, dass allgemein immer >>> so einfach geht (zumindest beim gcc). Das sind vordefinierte Strukturen? >> >> Doch, es geht so einfach: >> [c] >> #include "sbit.h" > [..] >> Allerdings sind die nötigen Definitionen beim AVR-GCC nicht von Haus aus >> drin. Anbei die benötigte "sbit.h". > > Wie ich vermutet habe, sind das (mehr oder weniger) "selbstgestrickte" > Strukturen. Damit arbeitet man im allgemeinen nicht. Zudem beinhaltet > die sbit.h ja nur die Port-Register. Für jede selbstdefinierte Variable > müsste man das dann entsprechend erweitern. Insofern finde ich für > einfache Zwecke Assembler immer noch deutlich einfacher. Ähhh??? Wer sagt das man so nicht arbeitet? Bisher habe ich bei meinen Programmen, zumindest denen die längerfristig genutzt werden sollten (und nicht nur mal als testsignalquelle ein paar Pins wackeln lassen sollen) immer das Ziel maximale Lesbarkeit verfolgt. INSBESONDERE bei Kommerziellen Produkten, also Auftragsentwicklungen. Und soweit ich mich errinnern kann war diese Art des Programmaufbaus, wenn es dazu Vorgaben gab, sogar ausdrücklich gefordert. (Vorgaben zur Ausführung machen ja nur diejenigen die bereits selber über Hintergrundwissen verfügen) Dazu gehört GERADE das man viel auf Strukturen setzt, die aber natürlich gut Kommentiert sind, wenn es die LEsbarkeit erhöht. Aber das spielt hier noch nicht einmal die Rolle: Denn diese hier genannten Definitionen sind zwar nicht globaler Bestandteil von C. Aber für den jeweiligen Prozessor alleine betrachtet gehören sie durchaus zum Standardsprachumfang. Es ist also GERQDE NICHT mit vom Anweder selbstgeschaffenen STrukturen zu verwechseln sondern steht in diesem Ausnahmefall für mich auch einer Ebene mit den C Standardheadern. Es gibt NUR EINEN Grund möglichst auf diese Prozessorspezifischen Standartlibs zu verzichten. Und das ist der Wunsch nach maximaler Portierbarkeit. Wenn man sichbei der Entwicklung der SW absolut noch nicht auf eine Familie, ja einen Hersteller gar, festlegen will. ABER da ist das PIN-Togglen nur das allerkleinste der Probleme. Das bekommt man fuer die meisten µC wirklich noch über Standardbitmanipulationsbefehle geloest. Sobald es aber zum Zugriff auf die hoeherwertigere Peripherie geht ist die "schoene Portierbarkeit" eh dahin. Kluge Köpfe lösen das dann in dem die GERADE eine ZUSÄTZLICHE ABSTRAKTIONSSCHICHT einführen die mit zahlreichen eigenen Struc und Typedefs arbeitet und so den "logischen Teil" der PRogrammgestaltung ueber diese virtuelle ZWischenschicht vom direkten HArdwarezugriff etwas loslösen. Soll dann ein anderer µC zum Zuge kommen müssen nur die Zuordnungen auf der untersten Ebene geaendert werden, das eigendliche Programm packt man gar nicht mehr an. Es gehoert MEINER ANSICHT NACH zum guten Stil, das man dies Standardmäßig so weit einbaut das man wirklich Problemlos entweder innerhalb der Controllerfamilie wechseln kann oder aber das man mit wenigen Klicks die Anschlussbelegung aendern kann ohne in den bestehenden und getesteten Funktionen selbst noch etwas zu aendern. Dies aber jedesmal so weit zu treiben das man Problemlos die HErsteller -ODER GAR DIE ARCHITEKTUR- wechselb kann, das fuehrt meist dann doch zu weit, für Hobbyisten mag das ja eine freie Entscheidung sein. Im Kommerziellen Umfeld aber sind das nur völlig unnötige Kosten. Die C Uhren ticken im Embedded BEreich und im PC Bereich zwar SEHR ÄHNLICH, aber lange nicht völlig identisch was die Programmgestatung und Programmierkonventionen angeht. Wobei ichjetzt noch einmal betonen möchte das man sich diese GEdanken überhaupt nur dann macht wenn man mit dem gedanken Spielt das man so weit wie möglich Portabel sein möchte. Da du aber hier genau die Vorzuege von Assembler preist geht das völlig in die Irre. Denn Assembler ist ja geradezu das Beispiel an inkompatiblität. Wenn man Glück hat kann man gerade noch ohne große Änderungen innerhalb der genauen Serie wechseln. Davon abgesehen verwendest du gerade bei ASSEMBLER ja dieselben von Microchip selbstverfassten Definitionsdateien, oder? Was meinst du was die Pic***.INC ist die du immer EInbindest? Auch in ASSEMBLER ist PORTB nur ein Makro. Oder schreibst du da auch direkt auf die Physikalische Adresse? Dann könntest du aber selbst einen WEchsel von PIC16F84 auf 16F628 nur mit enormen Änderungen durchführen. Nicht falsch verstehen: ICh verwende sehr gerne PICs, sowohl weil die mir in der Regel das bieten was ich brauche als auch weil das Verhalten der Fa. Microchip (ja ich hatte mehrmals direkten Kontakt) mir gegenüber immer VOrbildlich war. ICh schreibe auch heute noch Programme für die 16F viel und gerne komplett in Assembler, habe aber selbst bei den PIC32 kein Problem damit auch hier ASM Quellcode in die C Funktionen einzubetten. Aber trotzdem ist deine Behauptung an dieser Stelle einfach nicht fundiert. Noch einmal zum Vergleich Wenn ich z.B. ein Programm habe wo eine SignalLED immer wieder gesetzt wird, dann schreibe ich in Assembler an vielen Stellen in der Software: BSF PORTB,1... BCF PORTB,1...BCF PORTB,1...BSF PORTB,1 teilweise hunderte male. Oder ich schreibe es wie oben beschrieben EINMAL im Header "***.H" #define ON 1 #define OFF 0 #define STATUS_LED LATBbits.LATB1 Und im Programm dann immer nur: STATUS_LED = ON; ... STATUS_LED = OFF;...STATUS_LED = OFF;...STATUS_LED = ON; HAlt genauso oft wie das PORTB,1 in ASM. Der Riesen Unterschied ist aber nun: Wenn ich jetzt erkenne das ich die DIODE wegen des Layouts besser an IO_RB3 gehangen haette, dann muss ich in Assembler jeden einzelnen Aufruf ändern, hunderte Stellen. Bei C ändere ich EINMAL in der datei "***.H" die Zeile: #define STATUS_LED LATBbits.LATB1 ind die Zeile #define STATUS_LED LATBbits.LATB3 um und es ist alles zuverlässig Erledigt. ODer ich drehe, warum auch immer, die LEDs um (z.B. weil ich den freien Anschluss dort wo die LED ist leichter an +Ub als an GND bekomme. Dann Mache ich aus dem ON 1 halt ein ON 0... Bei ASM muss ich wieder viele hundert stellen ändern. Und wenn ich eine Vergessen habe, dann kann ich aus eigener Erfahrung sagen, gibt es tage da sucht man sich einen Wolf warum das nicht funktioniert! Es springt ja NICHT direkt ins Auge und aus dem Kontext ist der FEhler auch erst erkennbar wenn ich mich TIEF in die jeweilige Stelle im Code einarbeite. (ICh weise aber natürlich darauf hin das es bei vielen Assemblern durchaus die Möglichkeit gibt auch eigene Makros zu definieren und so zumindest in den Grundzügen ähnliche Abstraktionen zu schaffen. Aber gerade das wolltest du ja nicht) Wie gesagt, bei PC ist es teilweise nicht ganz so üblich für einfache Bitmanipulationen an Variablen extra eigene Strukturen zu erschaffen. Obwohl es in sonderfällen auch hier sehr viel Sinn macht und Wünschenswert ist, aber halt nicht so oft. Im Embedded Bereich aber gilt zumindest für ALLES mit direktem HArdwarebezug das es zum guten Ton Gehört genau SOLCHE vordefinierten Strukturen zu verwenden. Davon Abgesehen: Schreibe ernsthaft mal ein Programm für Umfangreiche USB Kommunikation in Assembler. Oder gar Ethernet? Bildbearbeitung alleine reicht aber meist schon. Da sitzt du ewigkeiten dran, teilweise Wochen, ja Monate für eine sichere Grundfunktion. Wohingegen die Kollegen die das in C machen und dazu noch die vorgefertigten Libs verwenden bereits eine Stunde nach dem ersten Kontakt über USB mit dem PC Kommunizieren... Gruß Carsten
>> Was ich nicht kapiere, warum gibt es bei keinem PIC ein ordentliches >> ExternBusInterface? >Weil genau sowas bei dieser Architektur nicht vorgesehen ist. Das ist kein Grund! Wenn das von Anfang an nicht vorgesehen war, heisst es nicht dass man es nicht machen kann. Jede CPU-Architektur kann Speicher adressieren, völlig egal ob intern oder extern. Man mun nur bisschen Periferie dazwischen bauen, damit es geht. Fast jeder Hersteller hat sowas, nur die von PIC nicht. >Guck mal bei den etwas hochpoligeren PIC's, da wirst du einen Port >finden, der als 8 Bit Parallelport konfigurierbar ist .... Ist bekannt. Aber ist kein ExternBusInterface, weil Zugriff auf Mem viel umständlicher ist.
MCUA schrieb: >>> Was ich nicht kapiere, warum gibt es bei keinem PIC ein ordentliches >>> ExternBusInterface? >>Weil genau sowas bei dieser Architektur nicht vorgesehen ist. > Das ist kein Grund! > Wenn das von Anfang an nicht vorgesehen war, heisst es nicht dass man es > nicht machen kann. > Jede CPU-Architektur kann Speicher adressieren, völlig egal ob intern > oder extern. Man mun nur bisschen Periferie dazwischen bauen, damit es > geht. > Fast jeder Hersteller hat sowas, nur die von PIC nicht. Natuerlich haben auch PIC einen VOLLWERTIGEN Anschluss für ein Parallelen Datenbus. Mit Flusskontrolle, Adress- und Datenleitungen (getrennt oder multiplext,je nach Einstellung), Ja SOGAR DMA Fähigkeiten. Die Maximale Datenbreite ist abhängig von der Gehäuseform und kann bis zu 16Bit Wortbreite bei 14Bit Adressbreite betragen. ALLES DA. Nur halt nicht bei den 8Bit PICs, da ist in der Tat der "alte" PSP das hoechste der Gefühle. Aber bei den 24er und bei den 32 ist das alles möglich. Aber wozu braucht man es bei den 8Bittern. Die Anwendungen wo ich soetwas brauche sind in der Regel keine Anwendungen wo ich mit 8 Bittern gut fahre. Da brauche ich meist etwas mehr leistung. Es ist halt eine etwas andere Philosophie... Wer PIC einsetzt will nicht einen µC haben mit dem er alles irgenwie kann, manchmal nur schlecht als recht und unter Rückgriff auf viele Externe Bausteine, sondern man sucht sich für jede Anwendung den passenden PIC raus. Und wenn ich wirklich einen "vollwertigen" P-Bus brauche, dann nehme ich halt einen PIC mit größerer Wortbreite... Deshalb kann man da bei den 8Bittern wunderbar drauf verzichten. Wobei ich aber zustimme des der alte PSP den einige 8BitPICs noch seit den Anfängen mehr schlecht als recht ist mit sich rumschleppen etwas "krank" ist. Ein Interfacce das der µC nur als Slave nutzen kann, der Slave dabei keine eigene Möglichkeit der Flusskontrolle hat, dessen Bedienung in einer Interruptroutine erfolgen muss, dabei aber nur EIN EINZELNES Byte im Buffer platz hat. Dazu noch völlig Ohne Adressleitunge, die Daten kommen rein sequenziell an und man muss hoffen das man ja keines verpasst weil der PIC gerade etwas anderes macht, sonst ist alles um einer STelle verrutscht. Diesen "alten"PSP kann man GETROST vergessen und implementiert lieber etwas eigenes rein in Software, wenn man es den unbedingt bei den 8Bittern braucht. Gruß Carsten
>>>> Was ich nicht kapiere, warum gibt es bei keinem PIC ein ordentliches >>>> ExternBusInterface? >>>Weil genau sowas bei dieser Architektur nicht vorgesehen ist. >> Das ist kein Grund! >> Wenn das von Anfang an nicht vorgesehen war, heisst es nicht dass man es >> nicht machen kann....... >Natuerlich haben auch PIC einen VOLLWERTIGEN Anschluss für ein >Parallelen Datenbus. ....... Dieser ParallelPort ist aber nicht gleich zu setzen mit einem ExternBusInterface, da man immer mehrere ASM-Befehle braucht, um auf ein beliebiges Byte im Ext.Speicher zuzugreifen! (DMA ändert daran überhaupt nichts)
> Der Riesen Unterschied ist aber nun: Wenn ich jetzt erkenne das ich die > DIODE wegen des Layouts besser an IO_RB3 gehangen haette, dann muss ich > in Assembler jeden einzelnen Aufruf ändern, hunderte Stellen. > Bei C ändere ich EINMAL in der datei "***.H" die Zeile: > #define STATUS_LED LATBbits.LATB1 ind die Zeile > #define STATUS_LED LATBbits.LATB3 um und es ist alles zuverlässig Das geht doch auch in Assembler:
1 | #define STATUS_LED LATB, 1 |
Carsten Sch. schrieb: > Noch einmal zum Vergleich Wenn ich z.B. ein Programm habe wo eine > SignalLED immer wieder gesetzt wird, dann schreibe ich in Assembler an > vielen Stellen in der Software: > BSF PORTB,1... BCF PORTB,1...BCF PORTB,1...BSF PORTB,1 teilweise > hunderte male. Du sprichst hier mit leichter Zunge etwas an, das mich vor mehr als 15 Jahren auch schon geärgert hat. Das Innenleben der (klassischen) PIC's und der Befehssatz ist schon genial, aber die Assembler-Notation ist - historisch gewachsen - nicht so gut. Ich hatte mir deshalb damals meinen eigenen Assembler geschrieben und benutze diesen auch seit 15 Jahren. Klar, daß man sowas entweder mit viel Fleiß pflegen oder sich auf die damit programmierbaren Familien beschränken muß, aber: mir gefällt mein eigener Assembler wesentlich besser als das Microchip-Teil. (Ähem.. damals gab's nur den PICALC, falls den jemand noch kennt) Mittlerweile sehe ich das so, daß ich in meinem Umfeld für die "dickeren" PIC's, also PIC18 und aufwärts eigentlich keine Verwendung mehr habe. Was ein PIC16 nicht mehr schafft, wird mit einem Cortex erledigt und Schluss. Aber sowas hängt wirklich vom Umfeld ab, weswegen man es nicht verallgemeinern sollte. Die von dir beschriebene Unschönheit habe ich sehr einfach gelöst: 1. Schritt: vollständige Definition des Bits: MeineLampe: BIT PortC,6 2. Schritt: Benutzung: BSF MeineLampe BCF MeineLampe ...usw. ebenso geht (bei meinem Assembler) SKIP MeineLampe ; entspricht BTFSS PortC,6 GOTO blabla SKIP NOT MeineLampe ; entspricht BTFSC PortC,6 GOTO wasAnderes Der Vorteil dieser Konstruktion ist, daß man an einer Stelle ein bestimmtes Bit definieren und ggf. ändern kann und im Programm darauf mit allen Maschinenbefehlen zugreifen kann, ohne in Gefahr zu laufen, daß man sich mit der Zuordnung von Register und Bit zu vertun. Wäre besser gewesen, Microchip hätte diese Notation verwendet. Ach, es gibt unter Assemblerleuten noch so einiges zu diskutieren, so z.B. die ewigen Blabla: EQU xyz Statements, die man besser einer vom Assembler geführten Platz-Zuweisung hätte überlassen sollen usw. W.S.
usuru schrieb: >> Der Riesen Unterschied ist aber nun: Wenn ich jetzt erkenne das ich die >> DIODE wegen des Layouts besser an IO_RB3 gehangen haette, dann muss ich >> in Assembler jeden einzelnen Aufruf ändern, hunderte Stellen. >> Bei C ändere ich EINMAL in der datei "***.H" die Zeile: >> #define STATUS_LED LATBbits.LATB1 ind die Zeile >> #define STATUS_LED LATBbits.LATB3 um und es ist alles zuverlässig > > Das geht doch auch in Assembler: > #define STATUS_LED LATB, 1 Ja, natürlich ;-) zumindest bei den meisten... HAbe ich ja explizit noch angefügt. Carsten Sch. schrieb: > (ICh weise aber natürlich darauf hin das es bei vielen Assemblern > durchaus die Möglichkeit gibt auch eigene Makros zu definieren und so > zumindest in den Grundzügen ähnliche Abstraktionen zu schaffen. Aber > gerade das wolltest du ja nicht) Aber er hat sich ja gerade mit dem Argument das man KEINE eigenen oder von dritten zugelieferten Datentypen oder MAkros verwenden soll gegen C und für ASM Ausgesprochen No y. schrieb: > Noch besser ist wie oben schonmal gesagt PIC18F4553. Ist sehr ähnlich > zum PIC18F4550... Ja, etwas leistungsfähiger. Aber auch teurer (OK, nicht gravierend) Was aber wirklich (für einen Einsteiger) gegen den 4553 und für den 4550 spricht ist die Tatsache das man den 4550 quasi an jeder Strassenecke bekommt, während der 4553 bie Reichelt und Co nicht im Programm ist. Zudem sind sehr viele Beispiele direkt für den 18F4550 lauffähig, insbesondere auch aus dem Framework. Direkt ohne Änderung aufspielbar. Bei dem 18F4553 kann hier oder da mal eine (kleine) Änderung nötig sein. KLAR: Für jemand der ein paar Wochen Erfahrung mit PICs hat und auch zugriff auf Distris, zumindest aber auf die Katalogdistris, hat, da spielt es keine Rolle. Da ist der 4553 schon gut. Für einen Einsteiger der sich zudem noch über Reichelt oder COnrad versorgen muss sind das aber entscheidende Gründe. Zumal er das mehr an Ressourcen ja meist überhaupt nicht braucht. GRuß Carsten
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.