chrysophylax
Geomaster
Die Frage, wie das mit den AVRs, den PICs, den Zypressen oder den MSPs ist kommt ja immer mal wieder - und allen Anhängern egal welcher brianistischen Partei tut es wahrscheinlich gut, gelegentlich mal etwas über den Tellerrand zu schauen, was sich bei den anderen so getan hat.
Ich mach mal ein neues Thema auf - mit dem Morse-Thread hat das glaub ich nicht mehr viel zu tun und da regelmässig wieder kommt, kann man vielleicht auch diesen Thread irgendwann mal wieder ausgraben.
Dabei werde ich versuchen, möglichst nicht in Schwanzlängenvergleiche auszuarten "mein Prozessor ist besser als deiner", die Zeit dürfte inzwischen gezeigt haben dass es für Produkte von jedem dieser µC-Herstellers jeweils einen Markt gibt. Die dürften sich zwar deutlich unterscheiden, aber es gibt für sie alle einen Markt.
Um zumindest noch kurz beim Schwanzlängenvergleich zu bleiben: Die Frage, welcher Prozessor besser ist, ist genauso sinnvoll und einfach zu beantworten wie die Frage, ob ein BMW besser ist als ein Daimler. Die einfache Antwort: Sie taugen beide nix, wenn man damit in den Wald Holz machen fahren will. Jedes Produkt hat eine bevorzugte Ziel-Anwendergruppe und ist für andere Anwendungen mal mehr, mal weniger gut geeignet.
Eine der Fragen, die immer mal wieder aufgeworfen wird, ist folgende:
Anhand des Bildchens erkennt man ganz hübsch, wie sich die Teile unterscheiden - grob vereinfacht in der Anzahl Beine und dem Speicherausbau als Kernkriterien. Da dran hängen dann jeweils noch RAM-Ausbau und die Menge an Peripheriebausteinen, die mit integriert sind.
Eine historisch gewachsene Besonderheit der PICs im Vergleich zu den Atmels ist, dass der Hersteller irgendwo in seinen Vorfahren einen Schotten oder einen Schwaben gehabt haben muss, die haben tatsächlich 12 und 14 Bit breite Befehlsworte um zu Zeiten, als es richtig Geld gekostet hat Silizium-Fläche im Flash zu sparen. Der Anwender merkt davon so gut wie gar nichts, weil einen die Werkzeugkette davor beschützt, sich mit 12 oder 14 Bit breiten Werten rumschlagen zu müssen, aber eine leere Flash-Zelle meines Leibundmagen-Prozessors 16F690 hat z.B. den Leerinhalt 0x3fff im Speicher des Programmiergeräts, weil es Bit14 und Bit15 einfach nicht gibt. Die Atmels waren da von vorneherein etwas großzügiger, haben gleich die vollen 16Bit Befehlsbreite eingeführt und dafür einen in einigen Teilen deutlich dankbareren Befehlssatz als die PICs, brauchen dafür aber auch mehr Siliziumfläche für die gleiche Anzahl Befehlsworte.
Selbst familienübergreifend ist gängige Peripherie, die überall drin ist übrigens überwiegend identisch enthalten, den Timer0 kann man in egal welchem PIC identisch benutzen und damit Quellcodes übernehmen.
Wenn man sich ein bisschen Mühe gibt, dann kann man einunddenselben Quellcode durch einbinden unterschiedlicher prozessorspezifischer Include-Dateien (in denen z.B. Registernamen stehen) auf diversen Prozessoren nutzen und ihn unverändert einfach nochmal mit einem anderen Include durch den Compiler jagen. Das hat natürlich Grenzen, wo sich Funktionalität ändert, aber im Großen und Ganzen ist man da doch sehr stringent.
Auch die Pinkompatibilität zwischen einzelnen Mitgliedern einer Familie wird gewaltsam beibehalten, so dass man einen 8beinigen PIC ins gleiche Programmiergerät stecken kann wie einen 40beinigen PIC, weil die Programmierpins an der gleichen Stelle sind. Ziemlich angenehm.
Wenn man die "elektrische" Programmiermethode mit einem AVR vergleicht, dann gibt es bei Microchip nur einen einzigen Modus, der seriell/ISP ist und einen ähnlichen Mechanismus nutzt wie der "HV-Modus" beim Atmel-Programmieren. Das macht die Programmiergeräte aufwendiger, aber man kann sich keine Bausteine "verfusen" weil man egal was man reinprogrammiert hat durch das einmalige Anlegen der hohen Spannung das Teil immer in einen definierten und zugänglichen Modus bringt.
Das bringt uns zur nächsten Frage, der der Entwicklungswerkzeuge:
Für die "grossen" 16bit-Prozessoren (PIC18 aufwärts) und DSPs bietet Microchip selbst was an, inzwischen auch bei Nachweis kostenlos Lehr- und Studentenversionen. Ansonsten fangen die bei 500$ an.
Für die "kleineren" 8bitter wird üblicherweise der HI-TECH C-Compiler empfohlen, den gibts in etwas reduziertem Funktionsumfang (allerdings KEINE Speicher-Restriktionen) kostenlos und ansonsten je nach Ausbau auch ab 500$. Der Herr vom aatis den ich im Rahmen meine Suche nach PIC-Reaktivlichtern fand nutzt z.B. diese kostenlose Lite-Version schon seit Jahren und ist damit recht zufrieden.
Im Heimeinsatz habe ich "sowas wie einen MP3-Player" namens SliMP3 (allerdings aus Zeiten als das noch eine eigene Firma war und sie sich noch nicht an Logitech verkauft und ihre Firmenphilosophie verraten hatten), da ist ein PIC16 mit einem extern angebundenen Ethernet-Phy drin und einem komplett Freeware TCP/IP-Stack, von daher vermute ich mal dass es schon seit mehreren Jahren auch eine klassische linux-basierte gcc-Toolchain dafür gibt. Beim Spontan-googlen hab ich nur SDCC gefunden.
Aber ganz ehrlich: Ich bin ein alter konservativer Sack und programmiere in Assembler... Live und in Farbe gesehen hab ich bisher noch nicht einen der erwähnten Compiler - ganz einfach, weil ich ihn bisher nicht gebraucht habe. Auch meine beruflichen Projekte, die in Großstückzahlen gehen, sind alle in Assembler geschrieben.
chrysophylax.
Ich mach mal ein neues Thema auf - mit dem Morse-Thread hat das glaub ich nicht mehr viel zu tun und da regelmässig wieder kommt, kann man vielleicht auch diesen Thread irgendwann mal wieder ausgraben.
Dabei werde ich versuchen, möglichst nicht in Schwanzlängenvergleiche auszuarten "mein Prozessor ist besser als deiner", die Zeit dürfte inzwischen gezeigt haben dass es für Produkte von jedem dieser µC-Herstellers jeweils einen Markt gibt. Die dürften sich zwar deutlich unterscheiden, aber es gibt für sie alle einen Markt.
Um zumindest noch kurz beim Schwanzlängenvergleich zu bleiben: Die Frage, welcher Prozessor besser ist, ist genauso sinnvoll und einfach zu beantworten wie die Frage, ob ein BMW besser ist als ein Daimler. Die einfache Antwort: Sie taugen beide nix, wenn man damit in den Wald Holz machen fahren will. Jedes Produkt hat eine bevorzugte Ziel-Anwendergruppe und ist für andere Anwendungen mal mehr, mal weniger gut geeignet.
Eine der Fragen, die immer mal wieder aufgeworfen wird, ist folgende:
Ähnlich wie bei den AVRs gibt es da auch diverse Familien, innerhalb derer es es jeweils ähnliche Derivate mit unterschiedlichem Speicher- oder Peripherieausbau gibt. Innerhalb der 8bittigen CPUs gibt es da die Familien PIC10, PIC12, PIC16 und PIC18.stonewood schrieb:
Anhand des Bildchens erkennt man ganz hübsch, wie sich die Teile unterscheiden - grob vereinfacht in der Anzahl Beine und dem Speicherausbau als Kernkriterien. Da dran hängen dann jeweils noch RAM-Ausbau und die Menge an Peripheriebausteinen, die mit integriert sind.
Eine historisch gewachsene Besonderheit der PICs im Vergleich zu den Atmels ist, dass der Hersteller irgendwo in seinen Vorfahren einen Schotten oder einen Schwaben gehabt haben muss, die haben tatsächlich 12 und 14 Bit breite Befehlsworte um zu Zeiten, als es richtig Geld gekostet hat Silizium-Fläche im Flash zu sparen. Der Anwender merkt davon so gut wie gar nichts, weil einen die Werkzeugkette davor beschützt, sich mit 12 oder 14 Bit breiten Werten rumschlagen zu müssen, aber eine leere Flash-Zelle meines Leibundmagen-Prozessors 16F690 hat z.B. den Leerinhalt 0x3fff im Speicher des Programmiergeräts, weil es Bit14 und Bit15 einfach nicht gibt. Die Atmels waren da von vorneherein etwas großzügiger, haben gleich die vollen 16Bit Befehlsbreite eingeführt und dafür einen in einigen Teilen deutlich dankbareren Befehlssatz als die PICs, brauchen dafür aber auch mehr Siliziumfläche für die gleiche Anzahl Befehlsworte.
Selbst familienübergreifend ist gängige Peripherie, die überall drin ist übrigens überwiegend identisch enthalten, den Timer0 kann man in egal welchem PIC identisch benutzen und damit Quellcodes übernehmen.
Wenn man sich ein bisschen Mühe gibt, dann kann man einunddenselben Quellcode durch einbinden unterschiedlicher prozessorspezifischer Include-Dateien (in denen z.B. Registernamen stehen) auf diversen Prozessoren nutzen und ihn unverändert einfach nochmal mit einem anderen Include durch den Compiler jagen. Das hat natürlich Grenzen, wo sich Funktionalität ändert, aber im Großen und Ganzen ist man da doch sehr stringent.
Auch die Pinkompatibilität zwischen einzelnen Mitgliedern einer Familie wird gewaltsam beibehalten, so dass man einen 8beinigen PIC ins gleiche Programmiergerät stecken kann wie einen 40beinigen PIC, weil die Programmierpins an der gleichen Stelle sind. Ziemlich angenehm.
Wenn man die "elektrische" Programmiermethode mit einem AVR vergleicht, dann gibt es bei Microchip nur einen einzigen Modus, der seriell/ISP ist und einen ähnlichen Mechanismus nutzt wie der "HV-Modus" beim Atmel-Programmieren. Das macht die Programmiergeräte aufwendiger, aber man kann sich keine Bausteine "verfusen" weil man egal was man reinprogrammiert hat durch das einmalige Anlegen der hohen Spannung das Teil immer in einen definierten und zugänglichen Modus bringt.
Das bringt uns zur nächsten Frage, der der Entwicklungswerkzeuge:
Gute Frage. Ganz ehrlich: Nicht ganz mein Gebiet. Ich programmiere seit etwas über 20 Jahren PICs, und bin bisher mit der IDE von Microchip, die einen supergeilen Assembler und Simulator bietet selbst bei grösseren Projekten einfach nur glücklich und zufrieden. Im Laufe der Jahre hat sich natürlich eine Art "Bibliothek" von Funktionen angesammelt, die man immer mal wieder braucht, und die sich einfach per include einbinden lässt, von daher muss ich auch das Rad nicht immer neu erfinden. Da fast alles, was ich programmiere so extrem hardwarenah ist, dass ich so oder so ständig Taktzyklen von a nach b von Hand auszähle kann ich es auch gleich in Assembler machen. Zum debuggen ist der Simulator bei grösseren Projekten perfekt geeignet, der ist so gut mit Stimuli-Dateien fütterbar, dass ich bisher noch nichtmal einen In-Circuit-Emulator vermisst habe.jennergruhle schrieb:
Für die "grossen" 16bit-Prozessoren (PIC18 aufwärts) und DSPs bietet Microchip selbst was an, inzwischen auch bei Nachweis kostenlos Lehr- und Studentenversionen. Ansonsten fangen die bei 500$ an.
Für die "kleineren" 8bitter wird üblicherweise der HI-TECH C-Compiler empfohlen, den gibts in etwas reduziertem Funktionsumfang (allerdings KEINE Speicher-Restriktionen) kostenlos und ansonsten je nach Ausbau auch ab 500$. Der Herr vom aatis den ich im Rahmen meine Suche nach PIC-Reaktivlichtern fand nutzt z.B. diese kostenlose Lite-Version schon seit Jahren und ist damit recht zufrieden.
Im Heimeinsatz habe ich "sowas wie einen MP3-Player" namens SliMP3 (allerdings aus Zeiten als das noch eine eigene Firma war und sie sich noch nicht an Logitech verkauft und ihre Firmenphilosophie verraten hatten), da ist ein PIC16 mit einem extern angebundenen Ethernet-Phy drin und einem komplett Freeware TCP/IP-Stack, von daher vermute ich mal dass es schon seit mehreren Jahren auch eine klassische linux-basierte gcc-Toolchain dafür gibt. Beim Spontan-googlen hab ich nur SDCC gefunden.
Aber ganz ehrlich: Ich bin ein alter konservativer Sack und programmiere in Assembler... Live und in Farbe gesehen hab ich bisher noch nicht einen der erwähnten Compiler - ganz einfach, weil ich ihn bisher nicht gebraucht habe. Auch meine beruflichen Projekte, die in Großstückzahlen gehen, sind alle in Assembler geschrieben.
chrysophylax.
