Hi, nachdem ich schon recht viel mit den Mikrocontrollern von Atmel gemacht habe, wollte ich mir auch mal die PICs ansehen. Da scheints ja ne Fülle an Programmiergeräten zu geben, hab sowohl im Internet gesucht als auch ein paar Bekannte gefragt. Aber die Angaben waren oft etwas wiedersprüchlich. 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?
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
Wenn Du erst mal einsteigen willst, würde ich mit PICKIT3 anfangen. Nur zum Brennen reichte ein Brenner von sprut.de, aber Du willst ja auch debuggen, das kann sprut nicht.
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)
Also sind die 20€ mehr nur für das Testboard oder? Der Programmer ist der selbe? Danke schonmal für die Antworten!
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
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)
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
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 ?
_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
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.
Aber auch Heute werden noch 8 Bit uC verwendet. Microchip und Atmel sind sicher nicht nur durch Bastler finanziert. Oftmals findet man sogar einen 74xx Baustein und keinen teuren FPGA... Die Idee beide uC Familien zu nutzen finde ich super. Irgendwann werde ich auch in die AVRs einsteigen. Nur wenn man beide kennt, deren Vor- und Nachteile, kann man entscheiden welcher für eine bestimmte Aufgabe besser geeignet ist. Und ich denke wir haben alle Spass am lernen, sonst würde wir uns die Elektronik nicht antun, oder? Von daher ist es ja nicht verkehrt. :)
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
Ja, das ist alles unbestritten. Jetzt jedoch sind ARM Cortex M3 preislich in Regionen (um 2 Euro) gefallen die bisher PIC und ARM etc. vorbehalten waren. Das wird den Markt regulieren, schon bald. Hier mal Infos zum anfüttern: http://www.elektor.de/elektronik-news/arm-cortex-m3-starterkit-fur-69-dollar.1836326.lynkx http://www.coocox.org/ http://de.farnell.com/stmicroelectronics/stm32f100c4t6b/ic-mcu-32bit-16k-flash-48lqfp/dp/1838504
Ok, lassen wir das mit den HobbyuC mal außen vor... ;-) Ich meinte auch eher dass es keinen Sinn macht eine in ihren Einsatzmöglichkeiten so ähnliche Architektur zu lernen die zudem noch recht veraltet ist statt sich was neues mit Potential anzugucken, was zudem noch preislich inzwischen sehr attraktiv ist wie "Schaltungswächter" schon sagte und auch in der Industrie immer mehr eingesetzt wird.
> 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
>Die Tendenz geht dahin, dass der CPU-Core fast egal wird ... aber nur 'fast', denn eine gewisse Rechenleistung muss das Ding ja haben sonst kann es die Anforderung nicht erfüllen. >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. Ja, sofern die Leistung ausreicht >Kennt man einen, kennt man sie alle. Unsinn! Die Architekt. sind total unterschiedlich.
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
>>>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)
Nun, ich denke was hier passiert ist der Versuch eine Wette abzugeben. Die einen sagen PIC mit MIPS Core ist gleichwertig und meinen aber "ich hoffe der wird sich durchsetzen", was hoffnungslos übertrieben ist. Die anderen möchten gern Ihren Favoriten besser dastehen lassen. Letztendlich ist das Wahrsagerei, kann ich nur mit der Schulter zucken. ----------------- > Und alle PICs, egal ob klein oder groß, können mit den gleichen Tools > programmiert und debuggt werden. Das ist ein unschlagbarer Vorteil und ein gutes Argument. Vermutlich wird das Atmel mit dem Studio5 auch irgendwann schaffen. Für ARM gibt es nicht DAS Tool, sondern eine unüberschaubare Menge an wirklich guten Sachen. Da liegt zum Teil das Problem, man MUSS sich damit beschäftigen. Nur zu, hat APPLE auch gemacht. > Der C Compiler nivelliert vieles. Ja. Was heute zählt ist Preis, Lieferzeitraum, Kontinuität, gute Libs, Energieverbrauch, endlos Peripherieoptionen... http://de.wikipedia.org/wiki/ARM-Architektur#Lizenznehmer http://www.elektor.de/elektronik-news/kostenlose-android-entwicklungssoftware-von-ti.1827248.lynkx http://www.energymicro.com/
_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
>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,... Achsooooooo, die sind alle gleich? wusste ich nicht.
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)
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. Da hat Atmel eindeutig Nachholebedarf. Ich mache auch viel mit dem MSP430, da gibt es fast alles was man braucht. DIP aber, in besser ausgestatteten Varianten sind auch Mangelware. Danke für den Überblick.
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
Ach ihr Streithähne, Cortex versus PIC versus Atmel versus WeissDerKuckuck... Da spielen sowohl die Hardwareeigenschaften als auch Preise und Bezugsmöglichkeiten als auch persönliche Vorlieben eine Rolle. Ich kann mich an den Zwist vor 30 Jahren zwischen der Intel/Zilog-Fraktion und der Motorola-Fraktion entsinnen. Die einen hatten big und die anderen little endian, auch im Assembler wurden die Operanden jeweils anders herum geschrieben und es wurde bis auf's Blut gestritten, welche Architektur denn nun alleinseligmachend sei.. Was mir bei jüngeren Leuten aufgefallen ist, ist die heftige fast schon fanatische Abneigung, irgendetwas von den Hardwarespezifika wissen zu wollen. Als Sprache kommt den meisten nur C in den Sinn, dazu wollen sie eine Treiberbibliothek haben, die die Peripherie möglichst zu 100% abkapselt und zum Schluss kommt der Debugger, der einem die aktuelle C-Quellzeile anzeigt. Wie hieß es hier weiter oben? "Der C-Compiler nivelliert das alles" Was bleibt da noch? Anzahl Megahertz und Kilobyte, basta. Nun gut, wer will, KANN so leben, arbeiten und basteln. Ob ich das gut finde, ist eine ganz andere Sache, denn derartige Leute sehen spezielle Eigenschaften verschiedener Chips nicht und können deshalb auch solche Eigenschaften nicht sinnvoll und nutzbringend einsetzen. Auch der vehemente Ruf nach einem Debugger ist mir suspekt. Solche Dinge wie Logikanalysator oder Debugger sind ja doch nicht die Lösung aller Probleme. Es geht auch ohne. Einfach nur gründlich genug nachdenken. und an Schaltungswächter: >"Wie sind denn PIC-Anwender mit der Firmenstrategie zufrieden? Errata >ausmerzen, Bugs in der IDE beheben." Mit den Schaltkreisen bin ich zufrieden, mit den Tools WAR ich in den 90er Jahren unzufrieden, weswegen ich mir damals mein eigenes Zeug gemacht habe: eigenen Assembler, eigene IDE, eigener Brenner, eigene Header, Libs etc. Ich habe deshalb die IDE von Microchip nie wirklich benutzt, nur mal hineingerochen und dann doch lieber mein eigenes Zeugs genommen. Ich weiß, das ist auf Dauer ne Insel, aber auf selbiger lebt es sich auch ganz gut - und für größere Projekte nehme ich keinen PIC. Die Direktiven beim originalen Microchip-Assembler finde ich schlecht, beispielsweise kann man keine Segmente deklarieren, weswegen RAM-Zellen per EQU deklariert werden müssen und eindeutige Bit-Deklarationen nur per Preprozessor erfolgen können. Aber das interessiert reine C-Programmierer ja sowieso nicht. Die Dokumentationen zu den PIC's sind exzellent, da können sich alle anderen uC-Hersteller ne Scheibe von abschneiden. Die damaligen Beispielquellen waren eher schlecht, beispielsweise waren die Gleitkommaroutinen alles andere als ausgereift. Deshalb habe ich auch seit vielen Jahren meine eigene Gleitkommabibliothek. W.S.
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. Was für ein Aufwand für 35 Euro +/-. Kauf es doch einfach und leg los. Das Ding hat übrigens noch n Terminal drin wo du über Softserial Daten ausgeben und empfangen kannst. In Deutschland ist die AVR Community größer, wenn du englisch kannst ist das international genau umgekehrt. > Wie sind denn > PIC-Anwender mit der Firmenstrategie zufrieden? Errata ausmerzen, läuft sauber > Bugs > in der IDE beheben. das läuft so unter und täglich grüßt das Murmeltier ;-). Ist aber mächtig, selbst z.B. externe Basic Compiler kann die in Sourcecode tracen.
>... ich habe mich lange Zeit auch von der Architektur der PIC16/PIC18 >abschrecken lassen, aber seitdem es gute C-Compiler dafür gibt... C-Compiler können die grässliche Architektur der (kleinen) PICs nicht wegmachen, höchstens einen Teil vorm Anwender verbergen. Ausserdem behauptet Microchip selbst nicht einmal CPUs zu haben, sondern nur PeripheralInterfaceController.
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.
Ich hab 2002 mit PIC's angefangen weil ich zufällig auf die sprut-Seite gestossen war. Damals einen Brenner von kitsrus bestellt - bloß nie wieder! Nur noch original Brenner kaufen - bei den third-party Dingern hat man keinerlei Support, keinerlei Garantie dass künftige Typen überhaupt unterstützt werden, und die paar Euro die man da spart sind es nicht wert. Anfangs habe ich mich etwas geärgert, mit PICs angefangen zu haben, weil die Community in Deutschland primär auf AVR's setzt. Inzwischen bin ich aber froh darüber! Im englischsprachigen raum dominieren ganz klar die PIC's. Außerdem: Niemand weiß wie es mit Amtel weitergeht, die Firma stand zwischenzeitlich kurz vor der Pleite und es gab bereits den (allerdings erfolglosen) Versuch einer feindlichen Übernahme durch Microchip. Das ist jetzt nicht unbedingt eine großartige Zukunft in die man da blickt. Der Support von Microchip, sowohl was Samples und Application Notes angeht, ist einfach nur vorbildlich; man findet für jeden Anwendungsbereich was. 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. Einen 16er-PIC hab neulich noch auf einem Mainboard entdeckt... die werden für solche Anwendungen immer noch benutzt. In einer elektrischen Zahnbürste steckte auch mal einer drin.
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.