Empfehlungen für PIC-Programmierer und Debugger gesucht (bin kein µC anfänger mehr!)

ade schrieb:

> Meine Anforderungen wären:
> - USB-Anschluss des Programmers (die meisten Programmer die mir
> empfohlen wurden haben nur RS-232, das hat aber mein Laptop nicht...)
> - Debugmöglichkeit (SEHR wichtig!)
> - Kompatibilität zu den meisten PICs
>
> Beim PIC-Kit 3 wäre das ja alles gegeben, oder? Wie ist das Ding so zu
> bewerten, kann man damit anständig arbeiten? Den Preis von ca. 60$ finde
> ich in Ordnung.
>
> Also was ist eure Meinung dazu? Was wäre geeignet?

Das PicKit3 ist die empfohlene Low-End Standardlösung.

Für größere Projekte darf es dann ein ICD3 (ca 200€) sein, der ist 
deutlich schneller - auch dank USB 2.0 High Speed (480 MBit/s) Anbindung 
(das PicKit3 kann nur Full Speed 12 MBit/s).

Das RealIce (ca 500-700€ je nach Ausstattung) ist nochmals schneller und 
hat die Möglichkeit eines zusätzlichen Real Time Execution Traces über 
Portpins, SPI oder bei den PIC32 im TQFP100/BGA121 den dort vorhanden 
Trace Port. Außerdem wird für ICSP ein differentielles Line-Modul 
angeboten, sodass der ICSP mit höherem Takt gefahren werden kann.

Ich sag mal so: Das RealIce brauchst Du nicht. Über das ICD3 kannst Du 
nachdenken. Ich habe es und möchte es nicht mehr hergeben.

Die ganzen Selbstbau-Brenner lohnen sich eigentlich nicht, weil es eben 
halt meist nur Brenner sind. Dieses Zeugs stammt noch aus der Zeit, als 
die PICs EPROM-Programmspeicher hatten, der entweder OTP war oder per UV 
gelöscht werden musste. Das ist jetzt alles obsolet - gib ja keinen 
einzigen Cent mehr dafür aus.

fchk

Frank K. schrieb:
>...
> fchk

Volle Zustimmung,

Sowohl mit dem PK3 wie auch mit ICD3 kann man alle halbwegs modernen 
PICs Programmieren (Typen mit "F", die relativ alten C Typen können die 
bis auf den 16C84 aber NICHT)
Ob man die Debuggen kann hängt vom PIC ab, Nicht jeder Pic ist debug 
fähig, einige Pics lassen sich auch nur mit Header Board debuggen. 
Allerdings ist das keine Einschränkung dieser Tools sondern eine 
generelle.

Der REAL ICE ist schon ganz nett und bietet hinsichtlich des Debuggens 
noch etwas mehr an möglichkeiten. Aber man kommt sehr gut ohne aus, auch 
im relativ ambitionierten Privaten Bereich sehr gut verzichtbar.
(regelmäßige gewerbliche Entwicklung macht damit schon etwas mehr spass)

Ob man sich jetzt für das günstige PK3 oder den ICD3 entscheidet kommt 
etwas auf den Geschmack an. ICD3 ist etwas schneller und geringfügig 
funktioneller beim Debuggen. Quasi die "Luxusvariante" des PK3...

Frank K. schrieb:
> Die ganzen Selbstbau-Brenner lohnen sich eigentlich nicht, weil es eben
> halt meist nur Brenner sind. Dieses Zeugs stammt noch aus der Zeit, als
> die PICs EPROM-Programmspeicher hatten, der entweder OTP war oder per UV
> gelöscht werden musste. Das ist jetzt alles obsolet - gib ja keinen
> einzigen Cent mehr dafür aus.
>
Ich denke das lag weniger an der Programmiertechnik als an dem Preis für 
die Entwicklungstools. Die ersten Startertools von µC die auch nur 
Programieren konnten (Picstart Plus) haben ja auch gleich mal 
vierhundert DM gekostet. Da waren Selbstbaubrenner schon hilfreich.
Aber im Endeffekt war das wohl eine Kombination vieler Faktoren.
Das die Technik der Fremdprogrammiergeräte -auch Selbstbau- aber obsolet 
sein sollte, da stimme ich voll zu.
Zumindest bei den ganzen Geräten die eigene SW brauchen und nicht direkt 
aus MPLAB funktionieren.
Wer Geld sparen muss, der soll sich einen 100% PK3 Clone aus China 
holen. Kostet incl. Versand ca. 20 Euro, dafür bekommt man kaum die 
Bauteile für die ganzen Selbstbaubrenner, hat aber die volle PK3 
Funktion!
(Microchip hat im Gegensatz zu Atmel sowohl Firmware wie auch Schaltung 
der Einsteigertools offengelegt, 100% Clones sind also kein Hexenwerk.)

Wer die Möglichkeit hat über eine Hochschule zu kaufen bekommt den PK3 
original auch für knapp über 20 Euro...

usuru schrieb:
> Nur zum Brennen reichte ein Brenner von sprut.de, aber Du willst ja auch
> debuggen, das kann sprut nicht.

Zumindest wenn man die Teile nicht alle direkt in der Bastelkiste und 
gerade etwas Langeweile hat machen selbst zum reinen Programmieren 
Fremdprogrammiergeräte wirklich keinen Sinn mehr! Das gilt auch für die 
Sprut brenner! Wenn man die Bauteile erst besorgen muss kostet es auch 
nicht viel weniger, teilweise sogar mehr -je nach Quelle und ggf. 
Versandkosten- als die Originalen PK, dafür muss man wesentlich 
umständlicher arbeiten (Bei Original kann man nach Codeänderungen mit 
einem Click den Programmcode erstellen und automatisch in den Pic 
brennen lassen, bei den nicht MPLAB kompatiblen Fremdprogrammiergeräten 
muss man in MPLab nach Codeänderungen den Programmcode übersetzen und 
abspeichern lassen, dann MPLAB verlassen, Das Fremdprogramm aufrufen, 
die Hex Datei öffnen und dann erst brennen lassen. Spätestens wenn man 
das bei schnellen Tests 10x hintereinander machen musste weiß man wie 
nervig das ist.

Gruß
Carsten

Falls PICkit3 und man das PIC18F Demoboard nicht braucht, reicht das 
PG164130 (PICkit 3 ICD) ~33 €, das DV164131 (PICkit 3 Debug Express) 
liegt bei ~53 € (ohne Umsatzsteuer, Mouser/MicrochipDirect)

der programmer ist der geleiche; beim pickit3 debug express ist noch ein 
2m langes rotes usb-kabel, eine cd mit mplab samt compilern und 
beispielen für das ebenfals beiligende demo-board dabei.

ade schrieb:
> Also sind die 20€ mehr nur für das Testboard oder? Der Programmer ist
> der selbe?
>
> Danke schonmal für die Antworten!

Korrekt!
Beim "Debug Express" Set (DV164131) ist zusätzlich zum reinen PK3-Set 
(PG164130) noch das Demo Board und eine CD mit Übungen/Tutorials dabei. 
Die C-Übungen sind für Einsteiger gar nicht verkehrt, aber halt nur für 
PIC Einsteiger in C. Geht um grundsätzliches wie Portansteuerung, 
Tastenabfrage, aber auch Interruptabfrage.

Ansonsten gibt es keinen Unterschied!
Beim PK3 alleine (PG164130) ist das USB Kabel, der PK3 sowie eine CD mit 
der Software (die man aber auch -meist aktueller- von der Website laden 
kann) im Pakekt.

Sollte man allerdings doch noch später Interesse an den Lesson Files 
haben, so kann man sich auch einfach die Files und DOKU frei von der 
Microchip Website laden und das Demoboard auf Lochraster nachbauen und 
dann auch ohne das teurere Set die Übungen machen... Der Schaltplan ist 
sehr einfach. Spart einem der Lust aufs BAsteln hat immerhin auch 
schnell 17-18Euro. (21Euro abzgl. PIC-Preis)
(unten auf:)
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340&redirects=pickit3

Gruß
Carsten

Hi,

Dario B. schrieb:
> der programmer ist der geleiche; beim pickit3 debug express ist noch ein
> 2m langes rotes usb-kabel, eine cd mit mplab samt compilern und
> beispielen

DAS ist auch alles beim PK3 Solo mit dabei. Sehe gerade sogar die Lesson 
Files Codes und Schaltplan für das Demo Board sind im "Demoboardlosen" 
Pack.

Einziger unterschied (neben dem Preis natürlich) zwischen den Beiden 
Paketen ist also:
>..das ebenfals beiligende demo-board dabei

ALLES andere bis auf das nakte Demoboard ist auch beim PG164130 dabei.

Gruß
Carsten

ade schrieb:
> ok danke! :-) Jetzt ists klar!
>
> Werde mir das Ding dann kaufen! Warte gerade noch drauf dass die mir bei
> Microchipdirect den 25% Studentenrabatt aktivieren. (Da die Uni aber
> keine .edu adresse hat, muss man in den Chat gehen und da nett
> nachfragen dann wirds weitergeleitet und man wird von "normal" auf
> "Student" umgestellt)

JA, Microchip ist da recht unkompliziert...
Da funktioniert das erstaunlicherweise ohne einen riesen 
Bürokratieaufwand und handfesten "Drohungen" verbunden mit 
Wahnsinnslieferzeiten!

Und in Fällen wo jemand wirklich glaubhaft machen kann das er sich mit 
Elektronik beschäftigt aber als Schüler /Student trotz des verbilligten 
Tarifes immer noch am Preis zu Kancken hat, da hört man immer wieder das 
denen dann noch extrem entgegengekommen wird. Gibt da einige Berichte zu 
hier im Forum. (Wobei ich hoffe das dies nicht irgendwann auch durch 
Schnorrer kaputtgemacht wird die das Blaue vom Himmel lügen nur um 10 
oder 20 Euro zu sparen obwohl sie es nicht nötig hätten...)

Da sollten sich so manch andere HErsteller mal eine Scheibe von 
Abschneiden. Direkt über die HS geht -je nach Tool- noch einiges mehr 
als 25%, das wird dann aber vom ablauf anders geregelt, Läuft dann über 
einen deutschen Distri mit teilweise vorheriger Freigabe durch 
Microchip.
(Klingt schlimmer als es ist, ein Anruf...)

GRuß
Carsten

_lubu schrieb:
> Wenn du kein Anfänger mehr bist warum wechselst du dann von einem
> Änfänger/Hobbybastler-Core zum nächsten?

Welchen MC man einsetzt, hat nichts mit Änfänger/Hobbybastler zu tun, 
sondern mit der Anwendung.

Nicht jeder muß unbedingt irgendwelche Grafispielchen in jedes seiner 
Geräte einbauen. Ich hab sogar MCs in Geräten, die haben nichtmal ein 
Display.
Wenn ich >2 Logik-ICs durch einen MC ersetzen kann, dann mache ich das 
einfach.
Für Ablaufsteuerungen und Überwachungen sind 8-Bitter völlig 
ausreichend. Schön ist auch, daß man für Batteriebetrieb nichtmal einen 
Spannungsregler benötigt (Weitbereich 1,8 - 5,5V).


_lubu schrieb:
> Wäre es nicht Zeit für was richtiges wie CortexM3 ?

Ich spiele auch mit dem Gedanken. Leider habe ich bisher noch nicht die 
Killeranwendung, damit ich ihn sinnvoll einsetzen kann. Und nur so als 
Hobby den M3 zu benutzen, dazu fehlt mir einfach die Zeit.
Wer schonmal Geräte entwickelt hat, der weiß, daß man nicht ohne Grund 
mal eben die MC-Familie wechselt, da hängt ein riesen Rattenschwanz an 
Arbeit dran.


Peter

Schaltungswächter schrieb:
> Ich höre noch 1995 die Unkenrufe "Wer braucht 32Bit"...
> Jetzt kommt 64Bit, na und?
>
> Genauso wird es bei MCUs werden. Wer sich also jetzt darauf einlässt den
> nächsten 8Bit Core zu lernen, wird zwar später mal sagen können; "Ja,
> PIC und AVR, da haben wir viel mit gemacht", aber ist es sinnvoll jetzt
> noch so einer "Rakete" Zeit zu widmen?
>
> Denkt daran, ARM ist fast überall, in jedem Handy, SetTopBox etc.

Wer nur einen Hammer hat, für den sieht alles wie ein Nagel aus.

Die Tendenz geht dahin, dass der CPU-Core fast egal wird und es im 
Wesentlichen auf die enthaltene Peripherie ankommt. Und da wird eine 
Motorsteuerung mit ADCs und PWMs sicherlich andere Anforderungen haben 
als eine grafisch orientierte Anwendung auf einem TFT.

Binärkompatibilität ist nur in den Umgebungen wichtig, wo es ein Markt 
für Software von der Stange gibt - PC, Smartphones, Spieleconsolen. Im 
Embedded-Bereich sind Hardware und Software so miteinander verzahnt, da 
ist es fast egal, ob tief unten ein ARM, MIPS, RXirgendwas oder PowerPC 
läuft. Kennt man einen, kennt man sie alle.

PS: Ich baue Ethernet-Geräte für "das Internet der Dinge". In diesen 
Teilen werkelt ein PIC mit integriertem Ethernet MAC+PHY. Die 
Rechenleistung reicht völlig, und die Chips sind so unglaublich billig, 
da ist die RJ45-Buchse das teuerste Bauteil auf der Platine. Warum 
sollte ich meine Marktchancen reduzieren, indem ich teurere Bauteile 
nehme?

fchk

> zudem noch recht veraltet
so bitte nicht. nur weil dein wissen veraltet ist, sind es die neuen uC 
noch lange nicht. schau dir doch mal die neuen PIC33E oder PIC24E an mit 
60MIPS und z.t. DSP und diversen schnittstellen 
http://ww1.microchip.com/downloads/en/DeviceDoc/01032h.pdf

Master Snowman schrieb:
>> zudem noch recht veraltet
> so bitte nicht. nur weil dein wissen veraltet ist, sind es die neuen uC
> noch lange nicht.

Korrekt. Und nicht zu vergessen: PIC32 mit MIPS Kern. (das, was früher 
in den großen UNIX-Workstations von DEC und SGI drin war)

Und alle PICs, egal ob klein oder groß, können mit den gleichen Tools 
programmiert und debuggt werden.

fchk

MCUA schrieb:

>>Kennt man einen, kennt man sie alle.
> Unsinn!
> Die Architekt. sind total unterschiedlich.

Der C Compiler nivelliert vieles.

Und ein wenig Abstraktionsfähigkeit sollte man schon haben.

fchk

_lubu schrieb:
> Wenn du kein Anfänger mehr bist warum wechselst du dann von einem
> Änfänger/Hobbybastler-Core zum nächsten?
>
> Wäre es nicht Zeit für was richtiges wie CortexM3 ?

Warum? Das ist u.a. das schöne an den größeren PICs (PIC24, PIC32) 
Pinout gleich, Libraries zur Ansteuerung auch, "nur" die Rechenleistung 
ist drastisch höher
http://www.coremark.org/benchmark/index.php

MCUA schrieb:
>>>>Kennt man einen, kennt man sie alle.
>>> Unsinn!
>>> Die Architekt. sind total unterschiedlich.
>>Der C Compiler nivelliert vieles.
>>Und ein wenig Abstraktionsfähigkeit sollte man schon haben.
> Dein 'Kennt man einen, kennt man sie alle' bezieht sich auf CPUs, nicht
> auf Compiler. Und da ist die Aussage Unsinn.
> (Ausserdem bin ich mir sicher, dass du diese Architekt. gerade nicht
> kennst, denn sonst würdest du nicht so'n Unsinn reden)

Hast Du ne Ahnung, was ich ich schon alles unter den Fingern gehabt 
habe:
8080/Z80, TMS9900, 6502, 6800, 6809, 68000/Coldfire, 8032, 80x86, Sparc 
(v7, v8, v9), MIPS, 56002, 96002, DSP32C, 21xx, TMS320C40, TMS320C80, 
TMS320C6xxx, ARM (7,9,M0,M3,XScale), PowerPC, AVR, AVR32, 
PIC12/16/18/24/32,... irgendwas werde ich sicher noch vergessen haben. 
In 30 Jahren kommt eben einiges zusammen, und der Überraschungseffekt 
schwindet mit jeder neuen Architektur.

fchk

Hi,

Schaltungswächter schrieb:
>
> Ja. Was heute zählt ist Preis, Lieferzeitraum, Kontinuität, gute Libs,
> Energieverbrauch, endlos Peripherieoptionen...
>

alles Bedingungen die eindeutig FÜR Pics sprechen also.
Zumindest wenn man den Vergleich AVR vs. PIC vollzieht. Denn in ALLEN 
diesen Punkten punktet ein PIC...
Wenn man jetzt bedenkt das man mit dem einfachsten PIC 
Entwicklungswerkzeug gleich ALLE Pics, vom kleinesten 8Bitter bis zur 
32Bit REchenmaschine programmieren und Debuggen kann und dieses auch 
noch fast unkaputtbar ist... Dann liegt nach diesen Gesichtspunkten AVR 
weit ab...

Und ja - die Cortex M3 können mehr als die 16F/18F Pic, keine Frage...
Aber sie sind ebend auch aufwendiger. Für eine einfache steuerung - ja 
sogar noch ein EINFACHES USB oder Ethernet device- ist der "Overhead" 
bei den 32bittern noch enorm groß, da vergeudet man viel Zeit mit.
Das gilt aber für die PIC 32 ebenso.
Mal ganz davon abgesehen das man keinen Cortex M3 im Dip gehäuse 
bekommt, also nicht ebend ein USB-HID mit drei Bauteilen auf Lochraster 
aufbauen kann. MAn ist IMMER gezwungen entweder teure Adapterplatinen zu 
verwenden oder gleich mit eigenen Platinen loszulegen.

Zudem ist es Blödsinn das wenn man Argumentiert das es ja soviele M3 
hersteller gibt und man so eine herstellerübergreifende Riesenauswahl 
hat und beliebig verwenden kann... Der ProzessorKERN ist zwar gleich, 
aber die Peripherie ist VÖLLIG Unterschiedlich, was auch wieder 
verschiedene Bibliotheken und andere Befehle benötigt. Das ist doch das 
entscheidende.
Denn gerade das was den Unterschied MIPS/ARM ausmacht, also der Kern, 
das nimmt der C Programmierer doch am wenigsten als Spezifisch war, da 
sorgt der Compiler für. Das was man jedesmal neu lernen muss sind die 
Peripherieorientierten dinge.
Und da kann es durchaus sein das es leichter ist ein für den Cortex M3 
vom Hersteller A geschriebenes Programm auf den MIPS von HErsteller B zu 
portieren als auf den Cortex M3 von Hersteller C.
Ausserdem sind lange nicht alle Tools für alle M3 tauglich. Und Software 
ist sehr oft erheblich eingeschränkt da die Profitools für richtig 
richtig viel geld verkauft werden sollen. Natürlich gibt es 
glücklicherweise komplett freie Tools, die funktionieren auch, haben 
aber noch ihre Macken.

DAs soll wirklichnicht heißen das die Cortex M3 schlecht sind. Die 
verwende ich im Moment sogar deutlich häufiger als die PIC32. Aber es 
ist nun einmal definitiv so das sich die Prozessorwahl imme rnach der 
Anwendung richten sollte. Und für einfache Dinge ist ein 8Bitter immer 
noch die beste Wahl. Und die werden noch lange nicht aussterben, die 
Absatzzahlen gehen -Wirtschaftkriseneffekt bereinigt- immer noch nach 
oben.
Und bei den 8 Bittern ist: auch wenn viele das nicht glauben wollen, 
anhand der Kriterien:
Schaltungswächter schrieb:
>
> Ja. Was heute zählt ist Preis, Lieferzeitraum, Kontinuität, gute Libs,
> Energieverbrauch, endlos Peripherieoptionen...
>
PIC eine verdammt gute Wahl!

Gruß Carsten
(Pic & AVR Verwender, natürlich nur neben Cortex M3, Renesas, div. 8051, 
8039, 68er Serie)

Schaltungswächter schrieb:
> Ein schönes Plädoyer für PICs, ich bin geneigt mir das PIC-Kit 3
> zuzulegen und das mal genauer unter die Lupe zu nehmen. Wie sind denn
> PIC-Anwender mit der Firmenstrategie zufrieden? Errata ausmerzen, Bugs
> in der IDE beheben.

Errata sind zu lesen! Ausrufezeichen! Die Listen können mitunter auch 
ziemlich lang sein, aber richtige fette Showstopper sind eigentlich 
selten. Damit ist Microchip aber in guter Gesellschaft.

Wenn ich nur an die TI/Luminarys denke, wo bei 70% aller LM3Sxxxx das 
Hibernation Module nicht funktioniert, und dann im Errata steht "The 
Hibernation module on this microcontroller does not operate correctly. 
Workaround: This errata item does not apply to many Stellaris devices 
(hüstel, kotz), […]. Refer to the Stellaris Product Selector Guide […] 
and Errata documents to find an alternative microcontroller that meets 
the design requirements for your application.", dann ist Microchip noch 
wirklich gut dagegen.

Microchip sorgt für Dich. Wenn Du die Bibliotheken (Peripherie, TCP/IP, 
Grafik, USB usw) von denen benutzt, dann sind dort die relevanten 
Workarounds bereits eingepflegt. Ein Grund mehr, die zu verwenden.

Das MPLAB 8 mag etwas altbacken aussehen, aber es funktioniert ganz gut. 
Das neue MPLAB X ist noch im Beta-Stadium, und Beta-Software verwende 
ich nicht, wenn ich es nicht muss. Vergleiche es mit dem AVR Studio 5, 
nur das hier nicht MS, sondern Netbeans dahintersteckt, also Java 
(seufz), aber dafür gibts da sogar eine Version für OSX.

Microchip-Bausteine sind eigentlich immer gut verfügbar. Microchip hat 
seinen eigenen Online-Shop, wo Du auch ungewöhnliche Bauformen oder 
seltene Typen bekommst, wenn Farnell, RS und Konsorten sie nicht haben. 
Die Versandkosten sind zwar nicht ohne, wenn das Zeugs dann per Express 
aus Thailand, Malaysia oder sonstwo kommt, aber Du bekommst das Zeugs 
immerhin.

Während Atmel jetzt alle Controller und Speicher bei externen Foundries 
fertigen lässt (was dazu geführt hat, dass sie zB letztes Jahr fast 
keine Dataflashes liefern konnten), fertigt Microchip fast alles selber.

Wie gesagt, ich habe mich lange Zeit auch von der Architektur der 
PIC16/PIC18 abschrecken lassen, aber seitdem es gute C-Compiler dafür 
gibt, ist das kein Grund mehr. Ich habe angefangen, PICs zu verwenden, 
weil die Peripherieauswahl hier eindeutig größer ist.

fchk

Schaltungswächter schrieb:
> Wie sind denn
> PIC-Anwender mit der Firmenstrategie zufrieden? Errata ausmerzen, Bugs
> in der IDE beheben.

Frank K. schrieb:
> ...
> fchk

Dem ist wirklich nicht mehr viel hinzuzufügen...

Nur folgendes: Ja- MPLAB 8 sieht von der UI fast noch genau so aus wie 
meine erste verwendete Version für Win3.11 von `96. Finde das aber gar 
nicht schlecht. Wobei ich aber diesen älteren UI Stil mag. Ich hätte 
auch heute noch gerne ein Winword das optisc wie 2.0 aussieht, nur mit 
den aktuellen Formaten zurechtkommt.
Hinter den Kulissen tut sich da aber recht viel. Bugs werden sehr 
kurzfristig gefixt, Alleine von der Version 8 gibt es 16 Unterreleases.
(Bugfixes und natürlich überwiegend Einpflegen neuer µC!)
Aktuell ist die Version 8.70 vom 11.05.2011

Die meist deutlich bessere Verfügbarkeit auch seltener PICs wurde ja 
schon genannt. Selbst als Privatmann bekommt man so ALLE Pics in allen 
Varianten innerhalb einiger Tage auch in Kleinmenge. Der "Worst Case" 
sind dann halt 15 Euro Versand. Wobei ich in jüngeren Jahren die 
Erfahrung gemacht habe das wenn man nur einen oder zwei Bausteine als 
Bastler braucht, die aber doch so exotisch sind das die bei den 
"Standartquellen" nicht verfügbar sind und so der Baustein nur für 
20Euro zu bekommen wäre und man deshalb "EHRLICH" mit Microchip Kontakt 
aufnimmt wird einem als Bastler in der Regel auch ohne großen 
Kostenaufwand geholfen.

Für "Standardbausteine" die man bei jedem Versender mit 3Eur. 
Versandkosten bekommt gilt das natürlich nicht...

Das ist aber auch nur in sehr seltenen Fällen überhaupt nötig, denn die 
Angebotspalette bei den Standardhändlern ist sehr gut. Man vergleiche 
nur mal die Verfügbarkeit von µC mit internen Hardware USB Modul für 
Privatleute.

Pics mit USB bekommt man in mehreren Typen und das jeweils im DIP und 
SMD Gehäuse bei den ganzen Standarthändlern wie Reichelt, Conrad und was 
weiß ich nicht alles. Preislich ab 1,80(SMD)/2,30(dip) für den 20Pinner 
18F13K50 bis hin zu 4,95 (44Pin TFQP)/ 5,15 (40 Pin-DIP) für den schon 
"mächtigen" 18F4550. Alles bei Reichelt Verfügbar.
AVR mit USB bekommt man bei CSD-Elektronik (haben auch die USB-Pic) 
einzig im TFQP GEhäuse für 3,95 (AT90USB64) bzw. 11.95 (AT90USB1287)...
Und wo als Privater noch? Was ist wenn dieser eine Händler gerade nicht 
liefern kann? (Falls jemand weitere Quellen kennt wäre die Nennung 
wirklich hilfreich, muss ich nicht immer für Bekannte alles bestellen.)
Selbes bei den Controllern mit CAN!

8 Bit Ethernet PICs hat Reichelt leider nicht, aber 8-Bit Ethernet AVR 
kenne ich überhaupt nicht...

Und dann kommen noch so Dinge wie das Bereitstellen und finden von 
Informationen... Wenn man das System bei Microchip - was ja auch 
zumindest halbwegs logisch aufgebaut ist - auf der Website einmal 
durchschaut hat findet man eigendlich alle benötigten Informationen sehr 
schnell. Und nicht nur die aktuellen Veröffentlichungen. Auch alle alten 
Versionen der Software (IDE/ diverse Compiler seit ende der 90er Jahre) 
sowie die dazugehörigen Veröffentlichungen sind auch weiterhin auf der 
speziellen Archivseite abrufbar. Selbes gilt für die Libs.

Generell besteht der Hauptunterschied beim Support zwischen AVR und PIC 
darin das beim PIC vom Hersteller wirklich eine sehr umfangreiche 
Sammlung an AppNotes, LIBs, Beispielcodes und weiteren Infos bereits ab 
Zeitpunkt der Markteinführung zentral bereitgestellt wird. Alles in 
einem einheitlichen Stil und zueinander kompatibel. Durch die 
"Community" passiert auch etwas, aber bei weiten nicht so viel. 
Hauptsächlich schon sehr sehr spezielle Dinge. Der Bedarf ist bis auf 
diese besonderen Spezialfälle halt nicht wirklich da. Bei 
Supportanfragen im Forum oder direkt wird meist schnell und Kompetent 
geholfen -meist direkt durch Mitarbeiter-.

Bei AVR hingegen geschieht der Großteil des Supports halt durch die 
"Communitiy". Für einige ist das ja auch das einzig Wahre. ICh bin da 
nicht so der Fan von, denn das bedeutet im Umkehrschluss das man sich 
seine Dinge aus vielen verschiedenen Quellen zusammensuchen muss, wobei 
man dann die Wahl zwischen vielen sich im Detail mehr oder weniger 
utnerscheidenden Lösungen hat. Dann kommt es durchaus öfter vor das die 
Lösung dann nur wieder mit einer speziellen Konfiguration der 
Entwicklungsumgebung läuft oder ein relativ allgemeines Problem so 
speziell gelöst wurde das ein zusammenbauen eines Programms aus zwei 
Quellen für die jeweiligen Teilfunktionen nur scheitern kann. (=> wieder 
von vorne anfangen).
Und dann ist da noch die nicht unerhebliche Frage der Lizenzrechte... 
Für den Bastler noch irrelevant, aber wenn der Gewerbliche dann 
feststellt das er den Code gar nicht verwenden darf oder gezwungen ist 
seine unter ausnutzung des "zur verfügung" gestellten Codes erarbeitete 
Lösung offengelegt werden müsste...

Bei MC ist das alles nicht die Frage.Es gelten immer dieselben 
Bedingungen die im großen und ganzen aussagen: Solange PIC µC verwendet 
werden ist jede Nutzung für nicht verbotene Aktivitäten seitens MC 
gestattet!

Und dann sind da natürlich noch eine Menge "weiterer" Kleinigkeiten.
Ein gutes Beispiel sind die USB VID und PID. Jedes USB Gerät braucht ja 
eine  eine individuelle VID&PID Kombination. Eine VID bekommt man aber 
nur gegen Zahlung von einigen tausend Dollar an die USB-IF. Privat kann 
man natürlich alles eintragen was man will, -schlimmstenfalls gibt es am 
eigenen PC Treiberkonflikte- sobald man das aber so weitergibt setzt man 
sich dem Risiko erheblicher zivilrechtlicher Konsequenzen aus. Auch wenn 
man nur 20 Geräte/Jahr verkauft...

Microchip stellt jedem Nutzer der dies benötigt KSOTENLOS eine 
individuelle
VID/PID Kombination zur Verfügung welche in dieser Zusammenstellung 
einzig dann von diesem User verwendet werden darf -sowohl Privat wie 
auch gewerblich- (wobei die VID gruppe auf MC eingetragen ist),
Einzige Bedingung dafür ist die Nutzung mit MC µC und das eine 
Gerätezahl von einigen Tausend verkauften Geräten pro Jahr nicht 
überschritten wird.
(Dann ist eine eigene VID zu beantragen)

Von Atmel gibt es so etwas zum Beispiel überhaupt nicht. Somit muss 
jeder der Atmel USB AVR verwendet und auch nur ein Gerät davon verkaufen 
oder auch nur verschenken will zwangsweise eine eigene VID für 
vierstellige Dollarbeträge beantragen. Natürlich kann man das auch 
ignorieren und willkürlich etwas eintragen. Wird das aber bekannt wird 
es sehr teuer.
(Ok, für eine Bastellei im Freundeskreis sicher kein Problem, aber 
sobald etwas von den GEräten an Unbekannte geht oder das GErät jemand in 
die Finger bekommt der einem was will...)

Und das ist nur ein Beispiel von vielen aus dem die Unterschiede im 
Verhalten gegenüber den "Kleinkunden" bei den Firmen zu tage treten.

Gruß
Carsten

Carsten Sch. schrieb:
> Und dann sind da natürlich noch eine Menge "weiterer" Kleinigkeiten.
> Ein gutes Beispiel sind die USB VID und PID. Jedes USB Gerät braucht ja
> eine  eine individuelle VID&PID Kombination. Eine VID bekommt man aber
> nur gegen Zahlung von einigen tausend Dollar an die USB-IF. Privat kann
> man natürlich alles eintragen was man will, -schlimmstenfalls gibt es am
> eigenen PC Treiberkonflikte- sobald man das aber so weitergibt setzt man
> sich dem Risiko erheblicher zivilrechtlicher Konsequenzen aus. Auch wenn
> man nur 20 Geräte/Jahr verkauft...
>
> Microchip stellt jedem Nutzer der dies benötigt KSOTENLOS eine
> individuelle
> VID/PID Kombination zur Verfügung welche in dieser Zusammenstellung
> einzig dann von diesem User verwendet werden darf -sowohl Privat wie
> auch gewerblich- (wobei die VID gruppe auf MC eingetragen ist),
> Einzige Bedingung dafür ist die Nutzung mit MC µC und das eine
> Gerätezahl von einigen Tausend verkauften Geräten pro Jahr nicht
> überschritten wird.
> (Dann ist eine eigene VID zu beantragen)
>
> Von Atmel gibt es so etwas zum Beispiel überhaupt nicht. Somit muss
> jeder der Atmel USB AVR verwendet und auch nur ein Gerät davon verkaufen
> oder auch nur verschenken will zwangsweise eine eigene VID für
> vierstellige Dollarbeträge beantragen. Natürlich kann man das auch
> ignorieren und willkürlich etwas eintragen. Wird das aber bekannt wird
> es sehr teuer.
> (Ok, für eine Bastellei im Freundeskreis sicher kein Problem, aber
> sobald etwas von den GEräten an Unbekannte geht oder das GErät jemand in
> die Finger bekommt der einem was will...)

Halt! Das war mal tatsächlich so, hat sich aber mittlerweile geändert..
http://support.atmel.com/bin/customer.exe?=&action=viewKbEntry&id=186
http://support.atmel.com/bin/customer.exe?=&action=viewKbEntry&id=220
und
http://www.atmel.com/dyn/resources/prod_documents/AVR32807.pdf
"Customer may keep the Atmel Vendor Identifier (Atmel VID) and Product 
Identifier (PID) in their product that integrates an Atmel USB Flash 
Microcontroller (“Integrated Product”) from one Atmel original example 
subject to the following acknowledgments and/or conditions:"

Danke für eure Tipps, ich habe soeben bestellt.
Die waren sehr freundlich und haben mir auf Nachfrage die 25% Rabatt 
gegeben.

Arc Net schrieb:
> Carsten Sch. schrieb:
>> .....
>
> Halt! Das war mal tatsächlich so, hat sich aber mittlerweile geändert..
> http://support.atmel.com/bin/customer.exe?=&action=viewKbEntry&id=186
> http://support.atmel.com/bin/customer.exe?=&action=viewKbEntry&id=220
> und
> http://www.atmel.com/dyn/resources/prod_documents/AVR32807.pdf
> "Customer may keep the Atmel Vendor Identifier (Atmel VID) and Product
> Identifier (PID) in their product that integrates an Atmel USB Flash
> Microcontroller (“Integrated Product”) from one Atmel original example
> subject to the following acknowledgments and/or conditions:"

Ok, das hatte ich jetzt so noch nicht mitbekommen,
ABER:
Es ist doch etwas völlig anderes als bei Microchip.
Atmel erlaub den Nutzer unter doch recht heftig einschränkenden Auflagen 
die ATMEL VID zusammen mit mit der von Atmel für die jeweilige 
CPU(serie) vergebene PID weiterzunutzen. Eine evtl. vorhandene vonb 
atmel vergebene Seriennummern und descriptor Informationen müssen 
ebenfalls UNVERÄNDERT übernommen und es ist Pflicht den eigenen 
Firmennamen (mgl. Website) verbunden mit (Atmel) Sponsorvermerk 
einzutragen.

Das hat nichts mit irgendeiner individuellen VID/PID Kombination zu tun, 
Wenn du zum Beispiel eine Steuerung mit AT90USB64 aufbasut und das 
NAchbarunternehmen baut ein Radio mit diesem IC würden die Geräte 
niemals am selben PC laufen können da ja PID und VID identisch sind und 
du ja nichtmal die Seriennummer als Alleinstellungsmerkmal nutzen 
dürftest...
(z.B alle deine Geräte bekommen im Descriptor die SNR 123456 und nur auf 
diese würde deine Treiber reagieren...)
Für den gewerblichen Bereich, schon im kleinen, praktisch völlig 
unbrauchbar. Wenn dann nur für Hobbybastler.


Man vergleiche das mal mit den Bedingungen von Microchip:
http://ww1.microchip.com/downloads/en/AppNotes/Application%20for%20USB%20Vendor%20ID%20Sublicense.pdf

Also Zuteilung einer "EIGENEN" PID unter der man dann völlig frei 
Agieren kann, keinerlei Einschränkungen hinsichtlich Descriptor oder 
vermerke.
MAn kann mit Ausnahme des PID und VID Feldes alles so eintragen wie man 
möchte oder es braucht. Also auch frei Seriennummern vergeben (laufende 
Nr. oder aber quasi als SUB PID)
Einzige Bedingung ist das man maximal 10 000 Geräte mit dieser PID 
herstellt, sobald die 10K überschritten wird muss man dann eine eigene 
VID beantragen. Dann dürfte das aber wohl verschmerzbar sein... ;-)
Das ganze ist wohl in erster Linie zur "Startup" Förderung gedacht, also 
für Unternehmen/Existenzgründer die eine "gute" Idee haben aber noch 
keinerlei Sicherheit auf einen Erfolg. Um mit möglichst kleinen 
Anfangsinvestitionen loslegen zu können...

Dazu meine ich stand an mehreren Orten bei MC das für die reinen 
Bastelarbeiten der Hobbyisten ohen gewerbliche weitergabe (wo also eh 
keiner nach kräht was man einträgt) auch die VID/PID aus den Beispielen 
weiterverwendet werden können/sollen.

Das sind Unterschiede, oder?

Klar - es ist Aufwand, verursacht Kosten und ist in erster linie ein 
Argument für kleine bis mittelkleine Kunden. Aber dies spiegelt sehr gut 
die Haltung der Firmen gegenüber den kleinen Kunden wieder.
Natürlich ist es auch bei MC nicht ganz uneigennützig, die wissen genau 
das aus einer zufriedenen Menge X von Kleinanwender durchaus eine 
(deutlich) kleinere menge Y Großabnehmer wird.
Aber es ist eindeutig eine Win-Win Situation für alle!

Gruß
Carsten

kent schrieb:
> [...
> Bei den USB-Controllern fand ich
> die Dokumentation etwas dürftig, da muss man sich erstmal eine Woche
> hinsetzen und den Quellcode durchstöbern um grob zu verstehen was die
> Firmware macht. Wenn einem das aber egal ist, kann man aber auch einfach
> eines der zahlreichen Beispiele anpassen, kompilieren und fertig. Ohne
> jede Vorkenntnisse kann man an einem Tag eine uC-Anwendung mit USB2.0
> programmieren. Das find ich schon ziemlich beeindruckend.
> ...]

Da gibt es "mittlerweile" (Ich weiß nicht ob das bei dir vieleicht noch 
nicht der der Fall war oder du es einfach nicht gesehen hast) eine recht 
gute Dokumentation zu dem Framework, Quasi als Bedienungsanleitung für 
das Framework. Dieses ist dann ergänzend zu den Datenblätern wo wirklich 
nur noch Techniche Dinge drinstehen. (sonst wird es auch zu viel)
Auch lohnt es sich immer die Bedienungsanleitung und die Daten zu den 
"Demo Kits" herunterzuladen und durchzusehen. Auch finden sich darin 
einige interessante Dinge zum allgemein Ablauf (auch die VID PID 
geschichte und die USB IF sind darin erklärt)

Die haben mir bei meinen ersten Gehversuchen sehr geholfen und ich 
konnte tatsächlich am ersten NAchmittag schon das USB Device 
fertigstellen...


Aber sonst kann ich deinem Beitrag nur voll zustimmen!!!

Gruß
Carsten