vom PIC18f umsteigen?

Hi,

Einsteiger mit Pause schrieb:
> nix dazu zu sagen?

Naja, was soll man dazu schon groß sagen...
Das Problem ist das ich (und wahrscheinlich auch der großteil der 
anderen) überhaupt nicht erkennen kann WARUM du überhaupt umsteigen 
möchtest.

Ob die PIC32 leichter zu Programmieren sind oder nicht hängt von deinem 
Inidviduellen Programmierstil  und natürlich auch vom Geschmack ab. Der 
Befehlssatz in den Librarys ist deutlich umfangreicher.
Zudem ist der Aufwand damit der PIC32 überhaupt etwas tut um einiges 
höher.

Ich würde das so sagen:
Zum Lernen, als Einsteiger, ist der PIC18 DEUTLICH einfacher. Die 
Umsetzung großer Projekte ist dann aber auf dem PIC32 einfacher, einfach 
weil dieser mehr Ressourcen hat.

Allerdings kann ich keinen Grund erkennen warum du nicht beide Serien 
nebeneinander Benutzen willst/kannst?
Die IDE ist dieselbe, das Programmiergerät ist, wenn man eine gescheite 
Wahl getroffen hat, dasselbe. Der Befehlssatz ist über weite TEile 
identisch. Der PIC32 hat mehr Befehle, allerdings kann man auchmit dem 
Grundstock der PIC spezifischen Befehle die in beiden Compilern 
unterstützt sind komplette PIC32 Programme schreiben. Ist halt in 
einigen Fällen etwas aufwendiger als nötig...
(Will man einen IO als Input setzen: Es gibt einen PIC32 BEfehl 
"PORTSetPinsDigitalIn" den man verwenden kann. Genauso wie es ähnliche 
Befehle für Analog Input oder diverse Ausgänge gibt.
Aber auch ohne den Befehl geht es natürlich dann setzt man halt händisch 
das Tris REgister, schaltet ggf. die AD Wandler ab und auch die evtl. 
vorhandene andere Pripherie)

Der Vorteil bei den PICs ist es ja gerade, das man mit ein und derselben 
Ausrüstung sowie ein und derselben ENtwicklungsumgebung eine sehr Breite 
Auswahl verschiedenster Controller diverser Leistungsklassen 
programmieren kannst. Da zudem selbst in den dem einfachen Hobbyisten 
zugänglichen Vertriebskanälen die angebotene Bandbreite groß ist spricht 
doch nichts dagegen sich jeweils den benötigten Controller auszusuchen. 
(NAtürlich kann man sich für einfache Dinge auf eine kleine Auswahl 
Controller einschränken die man auf Vorrat hat. Bei den 18ern würde ich 
z.B. den 18F45K20, den 18F4550 sowie als "kleinen" noch den 18F14K50 in 
betracht ziehen. den 45K20 sowie 14K50 bekommt man für um die 2Euro.

Bei den PIC32 ist der PIC32MX795F512L so ziemlich die obere Fahnenstange 
der wohl alles was der Hobbybastler braucht Abdeckt. Allerdings mit um 
die 10Euro pro µC schon eine Hausnummer. Da macht es schonmehr Sinn auch 
mal etwas kleiner zu denken.

Vom PIC abgesehen:
Wenn du schon C Beherscht, dann würde ich ARDUINO maximal als ergänzende 
HArdwarebasis ansehen. Es spricht ja nichts dagenen die "Shields" für 
eigene ZWecke zu nutzen. Auf die eigene Sprache würde ich aber 
verzichten...

Wenn es dir darum geht "mit Kanonen auf Spatzen" zu schiessen könnte man 
auch noch die ARM (am ehesten CORTEX M3) ins Spiel bringen. Allerdings 
sind hier die für "normale Bastler" möglichen Einkaufsmöglichkeiten 
beschränkt und du brauchst neue Software und HArdware. Dazu kommt das 
die meisten Compiler in den freien Versionen Codegrößenbeschränkt sind.
Von der Leistungsfähigkeit liegen die im Bereich der PIC32. Aber auch 
hier gilt, das komplexe Programme deutlich einfacher sind als auf den 
8Bittern, aber gerade die ganz einfachen Dinge wie "Pin Toggeln" oder 
generell der einsatz FÜR EINFACHE STEUERZWECKE im vErgleich zu 8Bit mehr 
aufwand erfordert. Aber darüber nachdenken könntest du mal. Wie gesagt, 
die Leistungsfähigkeit - und vor allem das Preis Leistungsverhältniss 
wenn man die möglichkeiten WIRKLICH Ausnutzt sind da sehr gut. (Nütz nur 
nichts wenn man nur 5% des Programmspeichers sowie zwei AD Wandler 
ausnutzt und der Rest abgeschaltet ist. Dann ist P/L grottig)

Argumente gegen MSP430 fallen mir gerade fast genausowenig ein wie 
dafür. Wer den Mag kann den gerne Verwenden. Ich sehe allerdings in dem 
Wechsel keinen Vorteil gegenüber PIC. Ob die zwei NAchteile die mir 
einfallen in deinem Fall auch als NAchteil in erscheinung treten kannst 
nur du alleine beurteilen. Wobei die auch nicht gravierend sind:
1.) Der MSP430 ist ein 16Bit Controller, es gibt keine 8Bit und auch 
keine 32Bit Controller die du mit identischen WErkzeugen programmieren 
kannst.
2.) Der MSP430 ist unter Hobbyisten weniger verbreitet, also etwas 
geringere Bezugsmöglichkeiten und Unterstützungsmöglichkeiten in Foren 
o.ä.
(Für kommerziellen Einsatz spielt beides keine Rolle)

NAtürlich könnte man noch einen Wechsel auf AVR in Betracht ziehen.
Aber auch hier sehe ich keine Vorteile. ISt in etwas gleichwertig.
Was unterschiedlich ist, das ist der Support mit Software und Librarys.
Für den AVR kommt sehr viel aus der "Community" und verhältnissmäßig 
wenig von ATMEL selbst.
Beim PIC kommt eine sehr breite Softwareunterstützung vom HErsteller. Da 
dadurch aber Bedarf für Selbstentwickeltes gering ist weniger aus 
Drittquellen. Es ist eine Geschmackssache was man besser findet. Ich 
plädiere ganz stark für "alles aus eine Hand", was dann PIC bevorteilt.
Aber andere sehen es anders.
Ein ähnlichen Unterschied gibt es bei der Modellpalette.
AVR haben eine recht überschaubare PAlette mit durchaus Leistungsfähigen 
Controllern (viel Speicher, viel Peripherie)die sich teilweise nur im 
GEhäuse unterscheiden. Universalisten halt.
PIC hat zwar auch solche Generalisten die man als Standardcontroller 
nehmen kann, aber eine sehr viel breitere und vor allem besser 
verfügbare Palette an "SPEZIALISTEN" (So waren USB AVR bis vor kurzem 
für Hobbyistren nur über einige kleine Händler teuer zu bekommen. 
Mittlerweile hat die aber Reichelt auch) Auch hier ist es wieder eine 
Geschmacksfrage...

Ein für einige Bastler wichtiger Punkt ist das Gehäuse der µC. Atmel 
bringt viele AVR nur noch in SMD heraus. So gibt es z.B. KEINE AVR mit 
USB Schnittstelle in DIP. Microchip hingegen bringt bei so gut wie allen 
µC die mit 40 Pinne oder weniger daherkommen auch immer noch eine DIP 
version heraus die man dann bequem auch auf Lochraster oder Steckbrett 
verwenden kann. Auch 16Bit, ja sogar, wie ich die Tage erst bemerkt 
habe, 32BIT µC sind in DIP verfügbar!
Aber auch hier kannst nur du selber beurteilen ob das ein argument für 
dich ist.

Also: Beurteilen kannst nur du selbst. ICh würde bei PIC Bleiben, da 
kennst du die Software und verfügst über die Hardware. Compiler sind 
ohne jede Größenbeschränkung in der freien Version verfügbar. Gute SW 
unterstützung. Lernen und wissen Vertiefen ruhig weiter auf den 18F. 
Wenn es das Projekt zulässt auch ruhig mit einem kleineren PIC als den 
4550 für 4 Euro. Pics derselben Leistungsklasse ohne USB gibt es schon 
für 2 Euro.
ISt dann der Bedarf mal für mehr Rechenleistung da, dann greifst du für 
dieses Projekt halt zum PIC24 oder gar PIC32... ganz nach belieben. 
Funktioniert ja alles mit derselben IDE und Programmierhardware.

Aber das ist nur meine Meinung unter  Berücksichtigung MEINER 
Prioritäten.
Du musst dir schon selber Gedanken machen.

Gruß
Carsten

arduino schrieb:
> Carsten Sch. schrieb:
>> Wenn du schon C Beherscht, dann würde ich ARDUINO maximal als ergänzende
>> HArdwarebasis ansehen. Es spricht ja nichts dagenen die "Shields" für
>> eigene ZWecke zu nutzen. Auf die eigene Sprache würde ich aber
>> verzichten...
>
> Kannst du mal bitte erklären was "die eigene Sprache" ist?

Ja, "eigene Sprache" ist evtl. nicht ganz korrekt, ABER: ISt es nicht 
so, das zu dem Konzept ein stark vereinfachtes C gehört?
JA - ich weiß der Grundstock ist C und wenn ich das jetzt richtigim Kopf 
habe sogar gcc als Compiler. Aber es ist doch so, das wer mit Arduino 
zurecht kommt nicht zwangsläufig auch andere C programmierbare µC ans 
laufen bekommt. Andersherum aber geht es.

GRuß
Carsten

heinzhorst schrieb:
> hro schrieb:
>> Nimm eine ARM-System mit Linux, kostet fast nix und Du hast so viele
>> Moeglichkeiten der Programmierung ...
>
> Man kann auch mit nem 40-Tonner nen einzelnen Schuhkarton
> transportieren...

Ja, ich verstehe auch nicht, daß immer so maßlos übertrieben werden muß.

Mein Lieblings-MC ist ein 8-Pinner (ATtiny25), für kleine Projekte ideal 
und bequem in C zu programmieren.
Und wenn ich mehr IO-Pins brauche, kommt einfach der 14-Pinner 
(ATtiny24) bzw. 20-Pinner (ATtiny261).
Der 28-Pinner (ATmega328p) ist bei mir schon der Bolide für riesig große 
Programme.

Ich mag es auch, daß ich nur einen Chip in die Schaltung einsetzen muß.
Und nicht ein teures Board mit nem Linux-MC und der benötigten riesen 
externen Beschaltung.


Peter

Andreas schrieb:
> PS: Ein Kollege von mir programmiert seit Jahren mit PIC10 und PIC12 und
> ich bin immer wieder erstaunt, was er mit dieen putzigen Controller all
> so Schönes machet.

Zu den PIC10 hat Atmel auch pinkompatible ATtiny4..10.
Blöder Weise hat Atmel da aber die Architektur drastisch geändert, so 
daß sie nicht mehr vom AVR-GCC unterstützt werden. Und C-Programmierung 
möchte ich auch für kleine Anwendungen nicht mehr missen.
Mit Codevision bzw. IAR kann man aber die 6-Pinner AVR auch in C 
programmieren.


Peter

Einsteiger mit Pause schrieb:
> Es ist zwar HArdware nah, aber manchmal nervt mich das schon mit den
> einstellen der Register und der Grundeinstellung bei den PIC.
>
> Da wäre mir ein
>
> PortPinA0= Output;
>
> PortPinA0=1

Naja.. In PIC-ASM:
PortPinA0 = Output -> bcf TRISA,0
PortPinA0 = 1 -> bsf PORTA,0 bzw. bcf LATA,0

Und in C:
TRISA &= 0b11111110;
PORTA |= 0b00000001;
Da viele C-Compiler (zumindest alle, die ich bisher benutzt habe) einen 
bit-Datentyp eingefügt haben, gibt es auch noch sowas wie:
LATAbits.LATA0 = 1;

oder (mikroE z.B.):
sbit Ausgang0 at RA0_bit;
...
Ausgang0 = 1;


Einsteiger mit Pause schrieb:
> So ne Code-Vergleichseite gibt es nicht zufällig (AVR, Arduino,
> PIC18,PIC24, MSP, "Linux").

Das würde mich auch mal interessieren. Jedoch.. Was muss/soll gemacht 
werden. Mit oder ohne initialisierung. USB geht wohl auf nem Linux 
besser als auf nem PIC oder AVR aber dafür ist ein Ausgangsbit setzen 
wohl beim AVR/PIC einfacher..

Michael Skropski schrieb:
> Einsteiger mit Pause schrieb:
>> Es ist zwar HArdware nah, aber manchmal nervt mich das schon mit den
>> einstellen der Register und der Grundeinstellung bei den PIC.
>>
>> Da wäre mir ein
>>
>> PortPinA0= Output;
>>
>> PortPinA0=1
>
> Naja.. In PIC-ASM:
> PortPinA0 = Output -> bcf TRISA,0
> PortPinA0 = 1 -> bsf PORTA,0 bzw. bcf LATA,0
>
> Und in C:
> TRISA &= 0b11111110;
> PORTA |= 0b00000001;
> Da viele C-Compiler (zumindest alle, die ich bisher benutzt habe) einen
> bit-Datentyp eingefügt haben, gibt es auch noch sowas wie:
> LATAbits.LATA0 = 1;
>
> oder (mikroE z.B.):
> sbit Ausgang0 at RA0_bit;
> ...
> Ausgang0 = 1;
>
>
> Einsteiger mit Pause schrieb:
>> So ne Code-Vergleichseite gibt es nicht zufällig (AVR, Arduino,
>> PIC18,PIC24, MSP, "Linux").
>
> Das würde mich auch mal interessieren. Jedoch.. Was muss/soll gemacht
> werden. Mit oder ohne initialisierung. USB geht wohl auf nem Linux
> besser als auf nem PIC oder AVR aber dafür ist ein Ausgangsbit setzen
> wohl beim AVR/PIC einfacher..

Sieben Funktionen implementieren (vier liefern nur eine Konstante 
zurück) bzw., wenn es für die Anwendung reicht, übernehmen (USB MSD mit 
internem Flash) und dazu ein paar ein Definitionen anpassen
http://ww1.microchip.com/downloads/en/AppNotes/01189a.pdf
HID und CDC
http://ww1.microchip.com/downloads/en/AppNotes/01163a.pdf
http://ww1.microchip.com/downloads/en/AppNotes/01164a.pdf
sind ebenso einfach umzusetzen bzw. können übernommen und erweitert 
werden.

Einsteiger mit Pause schrieb:
> Am besten zieh ich mir wohl einfach für jeden die klassiches Beispiele
> für ne blinkende LED.

Z.B. AVR-GCC:

1

#define F_CPU   1e6     // 1MHz

2

3

#include <util/delay.h>

4

#include "sbit.h"

5

6

int main()

7

{

8

  DDR_B0 = 1;           // output

9

  while(1){

10

    PORT_B0 = !PORT_B0; // toggle

11

    _delay_ms( 200 );   // wait

12

  }

13

}

Peter

heinzhorst schrieb:
> Och nö...das blockiert doch.

Kein Problem, wozu gibts Interrupts:

1

// Target: ATtiny13

2

#define F_CPU   1e6     // 1MHz

3

4

#include <avr/interrupt.h>

5

#include "sbit.h"

6

7

int main()

8

{

9

  DDR_B0 = 1;                           // output

10

  TCCR0A = 1<<WGM01;                    // Mode 2: CTC

11

  TCCR0B = 1<<CS02 | 1<<CS00;           // F_CPU / 1024

12

  OCR0A = F_CPU / 1024.0 * 0.2 - 0.5;   // every 200ms

13

  TIMSK0 = 1<<OCIE0A;                   // compare interrupt

14

  sei();                                // Interrupts on

15

  while(1){

16

  }

17

}

18

19

ISR( TIM0_COMPA_vect )                  // Interrupt handler

20

{

21

  PORT_B0 = !PORT_B0;                   // toggle

22

}

Peter

Einsteiger mit Pause schrieb:
> ...
> Ich denke halt manchmal muss man sich zu viele Gedanke num die Register
> etc. machen, kann auch sein, dass mir meine Gedanken da gerade einen
> Streich spielen, hatte noch keine Zeit reinzuschauen.
Naja, für C stimmt das in gewissem Maß für die SFR. So musst du alle 
HArdwareeinstellungn direkt setzen. Also ob der IO nun Ausgang oder 
EIngang ist - oder ob da jetzt ein ADC oder Digital in am Werk sein 
soll.
Das muss mindestens einmal geschehen, wenn sich einstellungen während 
der Laufzeit ändern mehrmals. Aber mit geschickter Programmierung kann 
man dies erheblich vereinfachen. Setzt natürlich ein wenig Erfahrung 
vorraus im wirklich gut darin zu werden.
Aber du WILLST ja LERNEN ;-)

Für ASM ist das natürlich anders. Da sind direkte zugriffe auf die GPR 
Register (aka RAM) wohl mit der zentrale Bestandteil des ASM.

>
> Für die LCD Ansteuerung hab ich mir ja auch nur ein paar "Einfache"
> Funktionen gebastelt um das LCD zu bedienen.
>
> Aber ich denke da manchmal so an die Richtung VBA,
>
> wenn da ne Zelle Rot sein soll, dann sag ich Zelle sei rot
>
> cells(1,1).interior.colorindex= 4
>
> (weiß noch nicht mal ob das gerade stimmt :) )
>
> die ersten Zeilen beim Pic gehen ja auch erstmal ans initalisieren
> verloren, ok wenn man es reicht ja strg+c und strg+v und der aufwand ist
> gleich Null.

Was meinst du jetzt mit Initialisieren? Das generelle Initialisieren des 
µC beim Startup oder das sich wiederholende Initialisieren beim Zugriff 
auf externe Elemente mit komplexer Befehlsfolge?

Für das erstere, KLAR! Das ist nun einmal da. Bei den 32Bittern noch 
deutlich Umfangreicher benötigt. Aber das geschieht beim PC (oder µC mit 
Linux) ja auch, da bemerkst du es im Idealfall halt nicht weil es da das 
Betriebssystem macht! (Aber wehe du hast keinen passenden Treiber und 
musst den erst einmal selbst schreiben...)

Ich habe mir mittlerweile für jeden µC Typ den ich jemals bearbeitet 
habe ein "Startfile" als Blankofile erstellt in dem die Fuses alle 
gesetzt werden, die IRQ Sprungziele definiert sind und ein unterprogramm 
Init vehanden ist, das aus main{} dann als erstes mit Init(); aufgerufen 
wird.
Wenn ich ein neues Projekt starte nehme ich diese Files immer als 
Ausgangspunkt, benenne dann eine Kopie auf den Projektnamen um und los 
gehts. NAtürlich habe ich auch Abweichende Einstellungen, aber dann 
brauche ich nur diesen Punkt ändern...
Ist im Prinzip aber auch nur die Bequemere VErsion von Copy&Paste.

Wenn du die jeweilige Einleitung des Zugriffes auf Komponennten wie 
Displays meinst, dann bist du mit den Selbstgeschriebenen Routinen schon 
auf dem richtigen Weg, musst die nur erweitern.
Als nächstes Schreibst du dann halt eine Routine für jedes Objekt 
welches du häufiger erstellen willst eine Routine die dir dieses 
Zeichnet. Wenn es zum Beispiel eine Tabellenzelle ist, dann kann man das 
durchaus so machen das man entweder die 4 eckkoordinaten oder eine 
Eckkordinate als Größe erstellt. Erstellt man dies dann auch noch so das 
die einzelnen Zellen in einem mindestns 2Dimensionalen Array abgelegt 
kann man später durch Index darauf zugreifen und z.B. eine Funktion 
schreiben die dann ähnlich wie in deinem VBA Beispiel beispielsweise an 
jeder Stelle im Programm mit einem Simplen DisplayOut(Anzeigestelle, 
Farbe); die Farbe Beliebig ändern kann.

ALLERDINGS: Bei "echten" Grafikdisplays, insbesondere mehrfarbigen, wo 
dann auch wirklich Grafikelemente die später noch bearbeitet und 
weiterhin als Einzelne elemente Adressierbar bleiben sollen ist der 
Aufwand schon sehr hoch den man "treiben" muss bevor man die eigendliche 
Anwendug schreibt. Allerdings bieten mittlerweile einige Anbiebter 
selbst spezielle Librarys zur Verfügung die man einbinden kann. Im Fall 
von Microchip PIC macht das Microchip selber und das auch kostenlos:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en543091
HAt man solche Libs zur Verfügung reduziert sich der Aufwand natürlich 
Enorm und man kann nahezu direkt mit der Applikation starten.
Natürlich sollte hier nicht vergessen werde zu erwähnen das solche 
Grafikdinge für einen 8Bit µC teilweise schon wirklich eine Aufgabe 
sind. Simples Pixelweises Bildermalen mag noch drinn sein, komplexe 
Grafik ist aber nicht mehr effizient möglich. (Deshalb ist die MC Lib 
auch erst ab PIC24.) Vorteil bei den PICs hier, ist das man ja beliebig 
für solche Anwendungen dann den "großen" nehmen kann und beim nächsten 
mal für eine Modellbaublinklichtanwendung IM Modell mit der selben 
Ausrüstung dann den PIC10 und für die Steuerung der Weichen über usb 
dann wieder den PIC18. Bei PIC muss man sich deswegen GERADE NICHT auf 
eine Architektur festlegen. Für die ersten Schritte: JA-macht Sinn, 
sobald man es aber beherscht und Effektiv Anwendungen programmieren will 
kann man beliebig von PIC10 über Pic24/dSPIC bis zu PIC32 jeweils den 
passenden auswählen.

> Deswegen ja die Idee/Frage, was tun, damit man eine blinkende LED sieht.
Für die 8Bitter hast du ja jetzt schon Beispiele bekommen. Bei den 
32Bittern OHNE Betriebssystem ist das ähnlich. Im Detail unterscheiden 
sich die Befehle manchmal etwas, aber vom Initvorgang abgesehen ist der 
Aufwand gleich.

Bei Systemen mit Betriebssystem wie ARM9 mit LINUX hast du nicht mehr 
Zwangsläufig den direkten Zugriff auf die Hardware zu regeln. Das 
Arbeiten ist mit dem Programmieren eines PCs schon recht vergleichbar.

Ich finde ein gutes (Gedanken-)Experiment ist folgendes:
Will man wissen wie es ist, dann besorge man sich einen Älteren 
funktionsfähigen PC mit mehreren Parallelen Schnittstellen (LPT) und 
einer NEtzwerkkarte. Auf diesem PC wird nun Linux Installiert, danach 
Monitor und Tastatur abgebaut. Sämtlicher Zugriff erfolgt nun nur noch 
über Netzwerk. DAS IST DANN DEIN ENTWICKLUNGSSYSTEM.
Jetzt kannst du mit einem "normalen" Compiler der in der LAge ist 
Linuxverständliche Binaries zu generieren deine Software als Schreiben 
und die kompilierten Programme auf den "RemotePC" schreiben. Willst du 
z.B. eine LED Bliken lassen müsstest du in C eine Anwendung schreiben 
die wie beim normalen PC auch immer eine Leitung ON/OFF setzt. (Beim 
"echten" LinuxµC ist das natürlich kein LPT und ein Treiber für direkten 
IO Zugriff ist meist dabei). Will man dann z.B. ein Modem oder eine 
Soundkarte anschließen installiert man zusätzlich den Treiber dafür, hat 
man keinen muss man einen Programmieren.
In dieser Konfiguration hat man also mit der HArdware im 
Anwendungsprogramm nur noch wenig zu tun, das System hat schon deutliche 
Ähnlichkeit mit einem richtigen "Computer"

Einen großen Vorteil hat man durch das Betriebssystem wenn man über 
wirklich Leistungsfähige Hardware verfügt und in Richtung Multitasking 
oder ähnliches gehen Will.
Hinsichtlich des Zugriffes auf externe/interne HArdware kommt es dann 
sehr darauf an ob passende Treiber verfügbar sind. Hat man zugriff auf 
für seine Hardware passende Treiber so muss dieser beim Start des 
Betriebssystems eingebunden werden und innerhalb der Anwendung braucht 
man dann nur noch auf die durch den Treiber bereitgestellte 
Schnittstelle zugreifen. Hat man keinen Treiber, so muss man erst einen 
selbst schreiben, der dann aber im gegensatz zur Version ohne BS sowohl 
die Richtige Kommunikation mit der Hardware ALS AUCH den Anforderungen 
des Betriebssystems gerecht werden muss.

Letzten endes ist, wenn man es genau betrachtet, der HArdwarezugriff 
also nicht einmal einfacher. Der Unterschied ist nur wo die 
Unterstützenden Dateien eingebunden werdem. Bei Linuxsystemen ins 
Betriebssystem, bei Controllern ohne BS ist es halt die Lib die direkt 
als Include in den Programmcode eingebettet wird.
Das was manche meinen ist einfach nur das mittlerweile in den 
Linuxversionen für Controller von Haus aus viele Treiber eingebunden 
sind, wohingegen man sonst zumindest noch die datei einmal aktiv ins C 
Projekt aufnehmen muss.

Diese Systeme haben DEFINITIV Ihre Berechtiung, keine Frage. Wenn man 
immer mehr Leistung braucht kommt irgendwann der Punkt an dem man nicht 
mehr drumherum kommt. Allerdings hat das nun nicht mehr viel mit der µC 
Programmierung zu tun an die der Großteil hier bei Nennung der Tätigkeit 
denkt. Die Programmierung am PC ist schon deutlich ähnlicher.

Dazu kommt dann noch das wie oben angedeutet das auch keine µC Systeme 
im engsten Wortsinn mehr sind, da mindestens der Speicher extern sein 
muss. Durch die Layoutvorgaben beim Anschluss des Speichers und alleine 
schon durch die Gehäuseformen/PinCount der Bausteine selbst ist auch der 
Selbstbau alles andere als Einfach. Er werden einige Anforderungen ans 
LAyout gestellt, Lochraster, fliegende Verdrahtung oder gar Breedboard 
sind völlig Unvorstellbar. Bei einigen Bausteinen ist zudem 4Layer oder 
gar 6Layer Layout Pflicht. Für erste Schritte ist allemal ein Fertiges 
Dev.Board angesagt, evtl. geht auch ein "Zweckemdfremdetes" 
Industrieprodukt wie die Seagate Dockstar oder zum Beispiel einige 
Oszilloskope.
Für spätere Einzelentwicklungen ist es dann teilweise deutlich billiger 
ein fertiges Prozessormodul zu kaufen als sich eine 4Layer Platine 
fertigen zu lassen. Dafür bekommt man schon locker mal 10 "normale" µC!

Wo die 32Bit µC wie PIC32 oder CortexM3 für Schritte wie LED Blinken 
schon die "Kanonen" bei der Spatzenjagt" sind, da stellen Linux 
basierende Entwicklungssysteme dann den Father of all Bombs (FAOB / 
größte thermobare Bombe) dar.
Solange keine Videobearbeitung, größere Grafikbearbeitung oder 
umfangreiche Signalanalyse geplant ist würde ich ohne andere besondere 
Anforderungen (wie Multitasking) daran keinen GEdanken verschwenden. Als 
Hobbybastler der nur ein wenig mehr in die Welt der Mikrocontroller 
eintauchen will schon gar nicht!

Gerade als solcher ist man mit den AVR oder PIC Mikrocontrollern schon 
recht gut bedient. Wobei ich halt die "zentrale" Bereitstellung von Libs 
durch den Hersteller wie bei Microchip gegenüber der dezentralen durch 
viele verschiedene Hobbynutzer eindeutig bevorzuge. Aber das ist 
Geschmackssache.
Es hat halt für mich den Vorteil eines immer recht einheitlichen Aufbaus 
und einer immer gleichen Rechtslage bei VErwendung, sowohl als reine 
Bastellei wie auch in komerziellen Produkten. (als reiner Bastler für 
Eigenbedarf ist zumindest die Lizenzfrage aber sowieso recht 
uninteressant, das gestattet wohl so gut wie jeder der seine Libs online 
stellt kostenlos)
Und halt das, was ich als weiteren Vorteil sehe, ich mit derselben recht 
kostengünstigen Hardware sowie dem KOMPLETT vom HErsteller 
bereitgestellten Softwarepaket für Windows UND Linux ALLE Familien von 
8Bit bis 32Bit problemlos ohne Zusatzaufwand je nach Bedarf bearbeiten 
kann. Aber auch das ist eine rine Geschmacksfrage!

Gruß
Carsten