Hallo liebe Gemeinde, ich weiß, dass es schon eine menge ähnlicher Artikel gibt aber auch nach ausgiebigen Lesen habe ich das Gefühl, dass ich doch noch einige Verständnis-Fragen stellen muss... Also zu meiner Ausgangssituation: Ich habe bereits mit den Arduino-Boards gearbeitet und wollte jetzt noch ein wenig "ernster" werden und mit den Mikrocontrollern an sich arbeiten. Da ich noch keine Erfahrung habe schreibe ich nun wohl eine Menge gefährliches Halbwissen, also korrigiert mich wenn ich quatsch erzähle. Ich bin mir noch nicht wirklich sicher ob ich mit einem PIC oder einem AVR beginnen möchte und will hier auch kein Fass aufmachen aber ich wollte doch noch einmal nach der PIC-C-Kompatibilität fragen. Ich wollte sowohl Assembler als auch C programmieren und habe einerseits gelesen, dass AVR-Prozessoren auf C ausgelegt währen andererseits aber auch, dass AVR "nur" eine GCC abwandlung anbietet während PIC einen speziell entwickelten Compiler besitzt. Ich nehme an, dass ich mit beiden Kontroller-Arten gleichermaßen mit C programmieren kann ohne auf größere Probleme zu stoßen? Weiterhin herrscht noch etwas Verwirrung was die PC (USB) zu Mikrokontroller Verbindung und Programmierung angeht. Nach dem was ich auf mikrocontroller.net gelesen habe sind die aktuellen Hardware-Stücke das PicKit3 (PIC) und das Atmel-ICE(Basic) (AVR)? Habe ich hier die richtigen Werkzeuge identifiziert? Ich bin deshalb verwirrt, weil auf der Atmel-Homepage für den Einstieg das Atmel-Dragon-Board beworben wird. Weiterhin wird zudem zu der Verwendung eines In-circuit Debuggers geraten und ich wollte nach der Notwendigkeit eines solchens fragen. Ich habe zudem gelesen, dass es bei AVR einen BitLock gibt, welcher den Chip sperrt und wollte fragen ob sich ein solcher mit dem dem ICE (falls richtig) löschen lässt (High-Voltage Programming reset?)? Ich wollte mich auch erkundigen ob es sich bei PIC Chips mit dem Bootloader genau so verhält wie bei den AVR-Chips? So wie ich es verstanden habe, gibt es hier einen Software-Bootloader, welcher sich auch überschreiben (und mit den oben genannten Werkzeugen wieder herstellen?) lässt? Also ich währe sehr dankbar wenn ihr ein paar meiner Fragen beantworten könntet und freue mich auch über Links und oder Buchempfehlungen. Habe ich soweit alles richtig verstanden?
Warum genau möchtest Du vom AVR weg? Mit den Arduinos hast Du wenigstens schonmal funktionierende Hardware und kannst Dich erstmal auf die Software konzentrieren. Habe ich mit der C-Control so gemacht, und hat perfekt funktioniert.
David P. schrieb: > Ich habe bereits mit den > Arduino-Boards gearbeitet und wollte jetzt noch ein wenig "ernster" > werden Das kannst Du doch mit dem Arduino-Board. Niemand zwingt Dich, die Arduino-Umgebung zu benutzen. Du kannst die Registernamen verwenden, wie sie im Datenblatt stehen. Und wenn Du bereits C kannst, gibt es keinen Grund zu Assembler hinab zu steigen. Du kannst direkt den AVR-GCC oder das AVR-Studio installieren und in C/C++ loslegen. Den Bootloader nimmst Du dann nur noch zum Flashen. Oder kaufst den Atmel-ICE: http://shop.mymcu.de/index.php?sp=article.sp.php&artID=200142
C. W. schrieb: > Warum genau möchtest Du vom AVR weg? Mit den Arduinos hast Du wenigstens > schonmal funktionierende Hardware und kannst Dich erstmal auf die > Software konzentrieren. Habe ich mit der C-Control so gemacht, und hat > perfekt funktioniert. Also ich möchte eigentlich gar nicht von AVR-Weg habe dahin gehend aber auch keine präferenzen. Zumindest habe ich bislang keine stichhaltigen Argumente für oder gegen PIC und AVR gefunden. (So wie ich es verstanden habe ist AVR etwas besser für C geeignet und für Anfänger leichter verständlich PIC hat dafür den schöneren Opcodes wenn es um Assembler geht?) Das ganze ist aber (bislang) auch nicht so wichtig. Mit den Arduinos habe ich zwar funktionierende Hardware und kann mich auf die Software konzentrieren aber darum geht es mir nicht. Ich möchte mir ein tiefer gehendes Hardware-Verständnis erarbeiten und dem entsprechend bewusst den steinigeren weg gehen (es muss nicht produktiv sein). Peter D. schrieb: > Du kannst direkt den AVR-GCC oder das AVR-Studio installieren und in > C/C++ loslegen. Den Bootloader nimmst Du dann nur noch zum Flashen. > Oder kaufst den Atmel-ICE: Macht es denn einen Unterschied ob ich ein Arduino Board zum bespielen des Chips nutze oder ein ICE? Oder anders gefragt: Was kann ein Atmel-ICE was ein Arduino nicht kann?
:
Bearbeitet durch User
David P. schrieb: > PIC hat dafür den schöneren Opcodes wenn es um Assembler > geht Ich hab Assembler für Z80, 8051, AVR gelernt, das ging ganz gut. Aber beim PIC haben meine grauen Zellen sich geweigert, umständlicher gehts nicht. Es gibt für den PIC ne Menge Routinen, auf die man nie und nimmer alleine kommen würde. Z.B.: http://www.piclist.com/techref/microchip/math/add/32brb.htm David P. schrieb: > Was kann ein > Atmel-ICE was ein Arduino nicht kann? Debuggen.
Peter D. schrieb: > Aber beim PIC haben meine grauen Zellen sich geweigert, umständlicher > gehts nicht. Naja, „PIC“ ist bei Mirochip so eine Art Sammelbegriff für so ziemlich alles (außer den Atmel-Neuerwerbungen natürlich), was sie an Microcontrollern produzieren. Insofern gibt es nicht den Assemblercode für PIC. Aber ich würde dir für den alten PIC12-Code sofort recht geben: habe ich einmal probiert, und das war das, was mich damals zu den AVRs gebracht hat. ;-) Der wesentliche Grund war, dass ich mir nicht länger meine Zeit mit sowas vertrödeln wollte, sondern einen Controller benutzen, für den es einen C-Compiler gibt (und das am besten native auf einem Nicht-Windows-System). @TE: kenne mich entsprechend mit PICs nicht zu gut aus, aber meines Wissens gibt es für die diversen PICs keine freien C-Compiler, die nicht in irgendeiner Form (Codegrößenlimitierung, schlechte Optimierung) verkrüppelt wären – nur, falls das für dich eine Rolle spielen sollte.
:
Bearbeitet durch Moderator
PIC ist nicht gleich PIC. Mit einer der PIC-Familien habe ich mal extrem schlechte Erfahrungen gemacht und danach gab es keine 2.Chance mehr für die PICs. David P. schrieb: > dass > AVR "nur" eine GCC abwandlung anbietet Der ggc kist mittlerweile für den AVR sehr gut optimiert: Übrigens benutzt auch Arduino den gcc unter der Haube (warum Arduino als eigene Sprache gilt, ist mir eh nicht ganz klar, für mich ist das C++ mit einer Lib, die extrem auf einfache Benutzbarkeit hin getrimnmt ist, was durchaus eine hervorragende Leistung ist). Daher sollte Dir der Umstieg auf "ernstes" C auf dem AVR nicht so sonderlich schwer fallen. Der Dragon funktioniert bei mir zuverlässig. Ich würde nicht mehr ohne diese Debug-Möglichkeit arbeiten wollen. Ich habe den Verpackungs-Karton gleich als Gehäuse umgebaut: ein paar Löcher an die richtigen Stellen geschnitten, und fertig ist das Low-Cost-Gehäuse. Wenn er Dir nicht zu kompliziert ist, kannst Du auch mal die STM32F-Familie anschauen. Dort bekommst Du Boards inkl. Debug-Port für 10€. Gruß, Stefan
:
Bearbeitet durch User
David P. schrieb: > Also ich möchte eigentlich gar nicht von AVR-Weg habe dahin gehend aber > auch keine präferenzen. Zumindest habe ich bislang keine stichhaltigen > Argumente für oder gegen PIC und AVR gefunden. Die Präferenz hast du selber gesetzt. Du besitzt lt. eigener Aussage bereits Arduinos, also mit hoher Wahrscheinlichkeit Inkarnationen funktionierender AVR8-Hardware. Das erspart dir erstens schlicht die Fehlerklasse "Hardwarefehler im Grundsystem", wenn du bei AVR8 bleibst. Du benutzt einfach die Boards, die du bereits hast. Und zweitens kannst du einen existierenden AVR8-Arduino auch noch zum ISP-Programmer machen. Das spart dir den Kauf eines zusätzlichen Programmers. Spart dir bares Geld. > So wie ich es verstanden > habe ist AVR etwas besser für C geeignet und für Anfänger leichter > verständlich PIC hat dafür den schöneren Opcodes wenn es um Assembler > geht?) Kompletter Unsinn. > Mit den Arduinos habe ich zwar funktionierende Hardware und kann mich > auf die Software konzentrieren aber darum geht es mir nicht. Ich möchte > mir ein tiefer gehendes Hardware-Verständnis erarbeiten und dem > entsprechend bewusst den steinigeren weg gehen (es muss nicht produktiv > sein). Kannst du doch. Eben dadurch, dass du einen Arduino zum ISP-Programmer machst und einen zweiten als Target für deine "bare metal"-Versuche benutzt. Dann hast du zumindest mit dem zweiten auf Wunsch wirklich alle Probleme, die dir bei einem AVR8 überhaupt begegnen können...
Die PIC C-Compiler haben ein vollkommen hirnverbranntes Problem. Bei den kostenlosen Versionen ist der Optimizer ausgeschaltet. Pic18 hat zwar zusätzliche Maschinenbefehle für C. Die kostenlosen Compiler benutzen aber nur die alten, Pic16-artigen Maschinenbefehle. Der Unterschied zwischen PIC und AVR Maschinencode? Die PIC Assemblerbefehle arbeiten direkt mit dem Speicher. Brauchen immer 4 Takte: Daten aus dem Speicher ins Rechenregister - Rechenoperation - Daten aus dem Rechenregister in den Speicher. Der AVR hat 32 Rechenregister. LD, ST und Rechenoperation sind drei einzelne Befehle, die insgesamt 5 Takte brauchen. Für einen C-Compiler sind die 32 Register optimal. Er kann 100 Variablen in 32 Registern halten und fast alle LD und ST weg optimieren. Aber als Assemblerprogrammierer verlierst du ziemlich schnell den Überblick, welche Variable sich zur Zeit in welchem Register befindet.
David P. schrieb: > Also ich möchte eigentlich gar nicht von AVR-Weg habe dahin gehend aber > auch keine präferenzen. Zumindest habe ich bislang keine stichhaltigen > Argumente für oder gegen PIC und AVR gefunden. (So wie ich es verstanden > habe ist AVR etwas besser für C geeignet und für Anfänger leichter > verständlich PIC hat dafür den schöneren Opcodes wenn es um Assembler > geht?) Das ganze ist aber (bislang) auch nicht so wichtig. PIC ist ein Sammelbegriff für drei völlig verschiedenen Architekturen: 1. 8-Bit (PIC12/PIC16/PIC18): ein Akku, max 4k Datenadressraum, etwas krude Assemblerstruktur; das woran die meisten Leute zuerst denken, wenn sie PIC hören 2. 16-Bit (PIC24/dsPIC): ähnlich wie AVR, aber alles in 16 Bit und obendrein dann nochmal Faktor 2-5 so schnell bei ganz ähnlichem Preis 3. 32-Bit (PIC32): MIPS-Kern, das was vor 25 Jahren in den ganz fetten Unix-Workstations gewerkelt hat, geht bis 200-300 MHz, hat also richtig Power. Alle drei Familien haben ihre eigenen Compiler, aber eine gemeinsame IDE und Debugger (PICKIT3 für Hobbyisten, ICD3 und RealICE für die Profis). Bei dieser Auflistung wird schnell klar, dass Du die drei Familien kaum über einen Kamm scheren kannst. Der Vorteil der PICs ist die bessere, leistungsfähigere Peripherie. zB UARTs, die auch LIN oder IRDA hardwaremäßig unterstützen. SPI-Ports, die Framed SPI (TDM, I2S für Audio) können. Es gibt PICs mit eingebautem Ethernet, d.h. Du hast nur noch einen einzigen Chip, wo alles drin ist. Es gibt viele PICs mit CAN oder Hardware-USB, bei AVR wäre das in vielen Fällen ein extra Chip. Es gibt PICs mit programmierbaren Logikblöcken, Frequenzgeneratoren, Digital-Analog-Wandlern und anderen Spezialitäten. Insgesamt kommen da über 1000 verschiedene Typen zusammen. Speziell wenn Du Produktentwicklung betreibst, wirst Du den Controller verwenden, der technisch am geeignetsten ist. Dem Kaufmann auf der anderen Seite des Schreibtisches interessieren nur $$$ bzw €€€ oder ¥¥¥ oder £££, der Rest ist ihm egal. Plus: Microchip hat bislang noch keine PICs abgekündigt. Die machen es über den Preis, indem sie die modernen PICs billiger verkaufen, während die alten Kamellen im Laufe der Zeit immer teurer werden (aber lieferbar bleiben). Wie das mit den AVRs aussieht, die ja jetzt auch Microchip gehören, bleibt abzuwarten. Wahrscheinlich werden die so langen weiter produziert, wie sie Gewinn abwerfen (wie die von SST übernommenen 8051'er), aber ich würde nicht auf großartige Weiterentwicklungen setzen. fchk
Frank K. schrieb: > Wie das mit den AVRs aussieht, die ja jetzt auch Microchip gehören, > bleibt abzuwarten. Sie haben explizit versprochen, ihre „Wir haben noch nie einen IC abgekündigt, den noch jemand kaufen möchte“-Policy auch auf AVRs auszudehnen. Ansonsten sind natürlich viele der Dinge, die du da für PICs genannt hast, in den heute gängigen ARMs der diversen Hersteller genauso vorhanden (und manches davon auch in Xmega AVRs). Wenn der TE also schon von den ihm (von Arduino her) vertrauten AVRs weg wechseln will, dann sollte man die kleineren ARMs auf alle Fälle mit in Betracht ziehen als mögliche Alternative. Wurde ja aber (in Form von STM32) auch schon gesagt.
David P. schrieb: > Argumente für oder gegen PIC und AVR gefunden. (So wie ich es verstanden > habe ist AVR etwas besser für C geeignet Ja, weil er 3 Index-Register hat. David P. schrieb: > PIC hat dafür den schöneren Opcodes wenn es um Assembler > geht?) Das ganze ist aber (bislang) auch nicht so wichtig. Was heisst schöner ? Mein Rat ist: Wenn du etwas kompliziertes als LED-Blinken programmieren willst, vergiss Assembler, wenn du dich ernsthaft mit Programmieren beschäftigen willst, nimm einen STM32.
:
Bearbeitet durch User
Schau dir doch die PIC-Welt mal an, schaden kanns nicht. Die Stärke gegenüber den AVR ist mal sicher die Peripherie neuerer PICs und das PICkit3 (das ein recht brauchbarer Debugger ist). Bei PIC24 dürfte auch die Leistung beträchtlich höher sein. C geht mit allen PICs. Die Compiler gibts in einer Gratisversion (mit reduzierter Optimierung). Als Tool bist du mit dem PICkit3 gut bedient. Das ist ein vollwertiger Debugger, nicht nur ein Programmer. Mit per Software einstellbarer Stromversorgung. Bei den meisten PICs ist kein Standardbootloader drin. Es gibt aber Bootloaderprojekte von Microchip als Muster: http://www.microchip.com/promo/8-bit-bootloader du brauchst oft keinenn Bootloader, zumindest nicht für Bastelprojekte. Sonstiges: Ich persönlich rate dazu, neuere(!) PIC18 zu nehmen, wenn man unbedingt 8-Bitter haben muss, besser aber PIC24. Desweiteren wäre zu sagen, dass man sich nicht unbedingt auf ein Device festlegen sollte. Die besondere Stärke der PICs ist die Peripherie - es gibt fast für jeden Anwendungsfall einen passenden PIC. Unbedingt auch PICs mit Peripheral Remapping in Betracht ziehen, das ist für 1-Layer-Platinen enorm praktisch - Layout kann in Software entwirrt werden. Ein paar schöne Devices sind: - PIC24FV32KA301 : 5V, DIL-Gehäuse - PIC24FJ128GA204 : TQFP44, volles Peripheral Remapping - PIC18F25K40 : Brauchbarer 8-Bitter mit 5V
Hallo, Peter D. schrieb: > David P. schrieb: >> Ich habe bereits mit den >> Arduino-Boards gearbeitet und wollte jetzt noch ein wenig "ernster" >> werden > > Das kannst Du doch mit dem Arduino-Board. Niemand zwingt Dich, die > Arduino-Umgebung zu benutzen. Du kannst die Registernamen verwenden, wie > sie im Datenblatt stehen. Und wenn Du bereits C kannst, gibt es keinen > Grund zu Assembler hinab zu steigen. > > Du kannst direkt den AVR-GCC oder das AVR-Studio installieren und in > C/C++ loslegen. Den Bootloader nimmst Du dann nur noch zum Flashen. > Oder kaufst den Atmel-ICE: > http://shop.mymcu.de/index.php?sp=article.sp.php&artID=200142 erkann auch einfach erstmal setup() und loop() aus dem "leeren" Sketch löschen und den C-Kram da reinschreiben. Ein GCC wohnt letztlich auch nur darunter, programmieren kann er erstmal weiter mit dem Bootloader. Die Arduino-IDE bindet nichts von den Arduino-Sachen ein, wenn im Sketch eine main() zu finden ist. Das hängt alles etwas davon ab, ob er sich mehr für die Details des Mega328 interessiert oder für die Unterschiede zwischen den IDEs. Gruß aus Berlin Michael
Mein Einstieg war mit PIC und SDCC, mit dieser Kombination habe ich später einige recht komplizierte Projekte gemacht. Als Programmer verwende ich einen usbpicprog (selbstgebaut, kann man aber auch fertig kaufen). Nachteil: Debugging geht damit nicht. Ansonten gibts es nichts, was mich an PIC/SDCC so stören würde, dass ich es nicht weiterverwenden würde. Assembler verwende ich nur im äußersten Notfall, bisher ein einziges mal bei einer zeitkritischen Interruptroutine, die der SDCC nicht schnell genug hinbekommen hat. Die Zeiten, wo ich aus Spaß Assemblercode schreibe, sind seit 20 Jahren vorbei (seinerzeit auf dem Z80), aber zum Lernen ist Assembler sicher eine gute Sache. Die AVR-Schiene habe ich bisher nie verwendet.
Als ich mit den Atmel Flash-8051 und AVR angefangen habe, sahen die PICs noch alle so aus: http://download.e-bookshelf.de/download/0002/5271/67/L-X-0002527167-0014204095.XHTML/graphics/f01-08.jpg Also für jeden Programmierversuch erstmal 20 Minuten unter die UV-Lampe legen. Das erklärt vermutlich auch, warum die AVRs so schnell populär geworden sind.
:
Bearbeitet durch User
David P. schrieb: > Ich wollte > sowohl Assembler als auch C programmieren und habe einerseits gelesen, > dass AVR-Prozessoren auf C ausgelegt währen andererseits aber auch, dass > AVR "nur" eine GCC abwandlung anbietet während PIC einen speziell > entwickelten Compiler besitzt. Ich nehme an, dass ich mit beiden > Kontroller-Arten gleichermaßen mit C programmieren kann ohne auf größere > Probleme zu stoßen? Ich würde an deiner Stelle gleich mit C weitermachen und kein ASM mehr nehmen. Ist zwar ganz nett, um tiefer in die Materie einzusteigen, aber es ist einfach unnötig aufwendiger. Die einzelne Peripherie musst du i.d.R. sowieso nochmal genau im Datenblatt angucken, um zu wissen, welche Register wofür sind und was überhaupt machbar ist. Es gibt für AVR und PIC (JEDEM PIC, also auch die PIC10) einen C-Compiler. Und für mich ist es mehr oder weniger egal, ob ein µC "für C gemacht ist" oder nicht, denn C ist eine Abstraktion von der Maschinensprache. Manche µC's haben vielleicht ASM-Befehle, die die Umwandlung von C in ASM effektiver machen, doch das bedeutet nicht, dass man die, die das nicht haben, nicht in C programmieren kann. Zum Beispiel eben die PIC10 mit 256 oder 512 Byte Flash-Größe. David P. schrieb: > Weiterhin herrscht noch etwas Verwirrung was die PC (USB) zu > Mikrokontroller Verbindung und Programmierung angeht. Nach dem was ich > auf mikrocontroller.net gelesen habe sind die aktuellen Hardware-Stücke > das PicKit3 (PIC) und das Atmel-ICE(Basic) (AVR)? Habe ich hier die > richtigen Werkzeuge identifiziert? Das PICKIT3 ist denke ich für dich das passende Werkzeug. Mit einem Sprutbrenner würde ich persönlich nicht mehr mit anfangen (was ich tat). Die Verbindung von PC und µC via USB im allgemeinen geht entweder über extra Chip oder mit einem µC mit USB-Modul. Davon hat Microchip jede Menge. Ab einschließlich PIC16 gibt es in jeder Familie mehrere bis viele Varianten mit USB-Modul - Teilweise auch mit einem ausreichend genauen internen Oscillator für Fullspeed-USB. Es gibt auch nicht wenige PICs im DIP-Package und mit USB. Mein letzter Kenntnisstand war, dass es bei Atmal, wenn überhaupt, nur ein oder zwei AVRs in DIP und mit USB gab. Für Bastler vielleicht nicht uninteressant. Im Allgemeinen hat Microchip alle PICs <=40 Pins im DIP-Package, ob PIC12 oder PIC32. David P. schrieb: > Ich wollte mich auch erkundigen ob es sich bei PIC Chips mit dem > Bootloader genau so verhält wie bei den AVR-Chips? So wie ich es > verstanden habe, gibt es hier einen Software-Bootloader, welcher sich > auch überschreiben (und mit den oben genannten Werkzeugen wieder > herstellen?) lässt? Naja, ein Bootloader ist im Prinzip ja ein Stück Software, was zum Beschreiben des übrig gebliebenen Programmspeichers ist. Der kann aussehen und funktionieren, wie er will. Daher kann man nicht sagen, ob er sich gleich verhält. Er erfüllt seinen Zweck, nämlich er beschreibt den Programmspeicher mit einem Programm, dass im Normalfall ausgeführt wird. Und USB-Bootloader gibt es sicherlich für alle gängigen µCs. David P. schrieb: > Zumindest habe ich bislang keine stichhaltigen > Argumente für oder gegen PIC und AVR gefunden. Die wird es auch nicht im allgemeinen geben. Ist ein Audi oder ein BMW besser? Da wird es keine wichtigen Argumente geben, beides sind gute Autohersteller resp. µCs. Wenn man genauer hinguckt, kann es aber schon unterschiede geben, doch das wären dann eher die Spezialfälle. Die Standard-Projekte wie Uhr, Lauflicht, LED-Cube, Wetterstation, .... wird alles mit den meisten AVRs und PICs gehen. > (So wie ich es verstanden > habe ist AVR etwas besser für C geeignet und für Anfänger leichter > verständlich PIC hat dafür den schöneren Opcodes wenn es um Assembler > geht?) Also ich persönlich beschäftige mich bisher ausschließlich mit PICs. Angefangen habe ich mit denen in der Ausbildung Ende 2005/Anfang 2006. Und ich muss sagen, dass ich sie vom Aufbau her gut nachvollziehen konnte und sie für mich sehr verständlich waren. Das immer über den Assembler-Code vom PIC (speziell die älteren PICs) gemeckert wird, kann ich kaum nachvollziehen, denn das ist der einzige Assembler-"Dialekt" den ich kann. Man hat da halt seine Befehle, die gut dokumentiert sind, und baut sich daraus sein Programm. Mit dem so oft gehassten Bank-Umschalten im RAM hatte ich keine Probleme. Es ist eben so gewesen und sobald eine Bank nicht mehr ausgereicht hat, hat man eben die Bank gewechselt. Wo genau der unterschied ist, weiß ich nicht. Ob man einmal ein Register für die Adressbits 0..7 und ein Register mit den Bank-Select-Bits 0..2 beschreibt oder einmal ein Register für die Adressbits 0..7 und ein Register für die Adressbits 8..10. Irgendwie muss bei einem RAM >256 Byte eine Adresse angegeben werden können, die länger als 8 bit ist. Wie das nun genannt wird, ist mir ja relativ egal. Und mit C ist das eh automatisch im Hintergrund. Die C-Eignung hatte ich oben ja schonmal erwähnt. Ich programmiere seit ca 8 Jahren PICs mit C und hatte nie ein Problem und nie einen PIC, der einen zu kleinen ROM hatte. Bei PICs ist es oft so, dass es Familien gibt, die eine gewisse Peripherieausstattung haben. Doch es gibt verschiedene PICs innerhalb dieser Familien, die sich in IO-Zahl/Package und Speicher unterscheiden. Beispielsweise: PIC18F23K20, PIC18F24K20, PIC18F25K20, PIC18F26K20, PIC18F43K20, PIC18F44K20, PIC18F45K20, PIC18F46K20 Die Zahl hinter dem F gibt das Package an: 2 -> 28pin mit 25 IOs, 4 -> 40/44pin mit 36 IOs. Die Zahl vor dem K gibt den Speicher (Flash/RAM) an: 3 -> 8kB/512B, 4 -> 16kB/768B, 5 -> 32kB/1536B, 6 -> 64kB/3936B. Abgesehen von IOs und Speichergröße sind die PICs identisch und haben auch das selbe Datenblatt. Somit könnte man erstmal Programmieren und dann den passenden PIC suchen, wo das Programm reinpasst. Oder aber bei einem Re-Design bzw. einer Hardwareerweiterung reichen die IO's nicht mehr, dann kann man vom 28pinner zum 40/44pinner wechseln und die Software kann gleich bleiben. Preislich unterscheiden die sich kaum. Auch wenn das mit der beschränkten Optimierung stimmt und u.U. auch einiges an Platz ausmacht, hat man durch die verschiedenen Speichergrößen eigentlich immer einen PIC mit genug Speicher. Ich nutze auch eine Optimierungsbegrenzte Version von XC8, aber hatte nie Probleme mein Programm unterzubringen. Daher kann ich das Argument nicht abstreiten, doch für mich ist es hinfällig, weil es eben bisher immer in den PIC gepasst hat. David P. schrieb: > Mit den Arduinos habe ich zwar funktionierende Hardware und kann mich > auf die Software konzentrieren aber darum geht es mir nicht. Ich möchte > mir ein tiefer gehendes Hardware-Verständnis erarbeiten und dem > entsprechend bewusst den steinigeren weg gehen (es muss nicht produktiv > sein). Auch wenn ich persönlich von den PICs im Allgemeinen begeistert bin, macht es für dich wohl mehr Sinn deine Hardware weiter zu nutzen. Du kannst ja trotzdem tief einsteigen und bei bedarf auch in ASM programmieren. Das schließt die Hardware ja nicht aus. Peter D. schrieb: > Ich hab Assembler für Z80, 8051, AVR gelernt, das ging ganz gut. > Aber beim PIC haben meine grauen Zellen sich geweigert, umständlicher > gehts nicht. Vielleicht fiel mir der PIC-ASM deshalb nicht schwer, weil ich keinen anderen kannte ;) Ich habe später mal ASM für einen (ich glaube) 80C535 gelernt. Was mich da z.B. gestört hat war, dass man zwar einen 1Bit-Speicherbereich hatte, um einzelne Bits abzulegen, aber ich konnte nicht (wie von PIC-ASM gewohnt) einzelne Bits jedes beliebigen Byte-Registers setzen/löschen oder abfragen. Jörg W. schrieb: > @TE: kenne mich entsprechend mit PICs nicht zu gut aus, aber meines > Wissens gibt es für die diversen PICs keine freien C-Compiler, die > nicht in irgendeiner Form (Codegrößenlimitierung, schlechte Optimierung) > verkrüppelt wären – nur, falls das für dich eine Rolle spielen sollte. Meines Wissens nach auch nicht. Allerdings läuft nach der Installation von XC8 eine 60-Tage Testversion der Pro-Version. Man könnte ggf durch beeinflussen der Registry oder einer Virtuellen Maschine, dessen Stand nach der Installation eingefrohren wird, diese Testversion verlängern. In wiefern das funktioniert und legal ist, weiß ich nicht. Letzteres würde mich aber z.B. im Falle der virtuellen Maschine interessieren - allgemein für jegliche andere Testversionen, z.B. auch AutoCAD/Inventor etc. Noch einer schrieb: > Die PIC C-Compiler haben ein vollkommen hirnverbranntes Problem. Naja, die Leute wollen ihre Arbeit bezahlt haben, es gibt für andere µCs auch sicher viele kostenpflichtige Compiler. Das es für die PICs m.W.n. keine freeware-Compiler gibt ist zwar schade, stört mich aber auch nicht weiter. Der erzeugte Code funktioniert auch noch mit geringerer oder ganz ohne Optimierung (glaube bei XC8 ist aber -O1 noch ohne kosten machbar). Es wird auch niemanden verboten, einen kostenlosen Compiler zu entwickeln. > Bei den kostenlosen Versionen ist der Optimizer ausgeschaltet. Pic18 hat > zwar zusätzliche Maschinenbefehle für C. Die kostenlosen Compiler > benutzen aber nur die alten, Pic16-artigen Maschinenbefehle. Das stimmt so nicht. Die Testversion von MikroC for PIC begrenzt auf Codegröße. Und dort kann man meines Wissens auch den erweiterten Befehlssatz nutzen. Also nicht XC8 für alle Compiler sprechen lassen. Letztendlich gibt es keinen hilfreichen Rat für dich. Bei AVR kannst du die Hardware weiter nutzen und hast (hoffentlich) schonmal ein Datenblatt eines AVRs gesehen. Leichter wäre dieser weg. Doch bei PICs wirst du bestimmt ebenso glücklich (vielleicht auch nicht) und du guckst über den Tellerrand. Was du aber nun machen sollst, kann keiner sagen. Es gäbe ja auch noch ARMs und MSP's usw., doch die hast du scheinbar schon irgendwie ausgeklammert, sodass du bei PIC/AVR hängen geblieben bist. Ich hab mir auch immer schon mal vorgenommen einen ARM einzusetzen, doch bisher hatte ich keinen wirklichen Grund dafür. Es gab immer einen fähigen PIC, der das konnte, was ich brauchte. Und nur so just for Fun Geld und Zeit investieren? Nicht ohne Vorteil. Dann investiere ich die Zeit und das Geld lieber in neue Projekte oder aber in ganz andere Ecken wie z.B. FPGAs.
Ich bin seinerzeit auch von Atmel.zu Microchip gewechselt weil die Auswahl riesig war. Vom kleinen 8-bitter bis zum grossen 32-bitter wird alles abgedeckt und das hinsichtlich der Programmierung sehr konsistent. Man kann alles mit den kostenlosen Tools und nem Pickit3 (-Clone) abdecken und sollte man wirklich mal die besseren Optimierungsstufen benötigen kann man die mittlerweile monatsweise zukaufen. Die Atmels waren schön, die Xmegas nicht so der Fortschritt und die UC3 ganz anders.
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.