Hallo, in Verbindung mit Atmels AVRs wird ja meinst beworben/betont, dass dort die meisten Befehle in einem Takt ausgeführt werden. Also 4MHz -> 4Millionen Befehle pro Sekunde. Wie ist das bei den PIC18F? Lt. Datenblatt gibt es eine Menge Befehle, die auch nur ein Cycle benötigen. Kann ein PIC18F also auch bei 4MHz auch 4 Millionenen Befehle abarbeiten? Sind also die PIC18F mit max. 40MHz etwa doppelt so schnell wie die AVRs mit max. 20MHz? Ich weiss, dass man den Vergleich nicht ganz ziehen kann, aber mir geht es um das Prinzip. Steffen.
Soweit ich weiss wird bei den PIC die Quarzfrequenz intern durch 4 geteilt! 40 MHz bei Befehlt pro Takt entspricht 10 MIPS
Immer diese nutzlosen Fragen. Ich kann 8051 und AVR und wüßte keinerlei Aufgabe, wo ein PIC18F besser geeignet wäre. Also werde ich mich nicht mit dem PIC18F beschäftigen. Wenn Du aber so ein MIPS-Fetischist bist, nimm doch nen Silabs 8051, die gehen bis 100MIPS (interne PLL = 100MHz). Peter
Naja,bei der Mehrzahl aller Anwendungen,wo 10-20 MIPS nicht reichen,ist auch eine 8-BIt ALU nicht mehr ausreichend.Dann ist es egal,wie hoch man seinen 8-Bitter treibt,es wird nie so gut wie z.B. auf einem ARM oder gar einem DSP laufen.Häufig gibt´s bei den kleinen Controllern auch keine Division in Hardware was dann bei komplexen Berechnungen stark ins Gewicht fällt. Allerdings kann man mit den AVRs (und meinetwegen auch PICs) schon eine ganze Menge anfangen.Von der flinken Motorsteuerung über ein SD-Karteninterface bis zum Webserver ist da schon einiges möglich.Als Anfänger wird man wahrscheinlich eher ein Problem mit dem "knappen" RAM haben.
In Details sind die doch sehr unterschiedlich. Der PIC kann z.B. 2 Moden, einmal einen, der (explizit) für C gedacht ist. Daneben gibt es da auch etwas wie eine Totzeit (Bezeichung = ?) bei der PWM, wenn der eine Kanal abgeschaltet wird, wird der andere erst nach einer Zeit eingeschaltet - damit durch Rest-C kein Kurzschluß entstecht. Atmel hat das nicht bei der PWM - bin mir da aber nicht ganz sicher ! USB haben einige PIC18f. (Hier ggf. PIC16, und nicht 18:) Der lineare Addressraum - bzw. das banking der PIC Die Verwaltung der Interruptadressen und deren "Lage" (ATMEL im RAM, PIC separat - und damit deren Anzahl) Mir scheint es so, dass der PIC18F entweder per C oder per Assembler programmiert werden sollte - wegen der Moden haben die Assemblerbefehle sonst andere Wirkungen. Preis = ? Nur ein paar Tipps/Hinweise zu schauen - aber bitte kontrollieren, PICs habe ich lange nicht mehr angesehen bzw. vertausche ich ggf. PIC16 mit PIC18. Gruß, c.
@Peter "Immer diese nutzlosen Fragen." Dann beantworte sie doch nicht und gehe zum nächsten Post... Ich möchte das rein aus Interesse wissen. "Wenn Du aber so ein MIPS-Fetischist bist, nimm doch nen Silabs 8051, die gehen bis 100MIPS (interne PLL = 100MHz)." Ich hab ja nie geschrieben, dass es mir auf die MIPS ankommt. Ich habe momentan gar kein aktuelles Projekt, an dem ich arbeite. Die Frage ist aus der Diskussion mit nem Kumpel entstanden. Und ich kann mir schon vorstellen, dass es Aufgaben gibt, wo man an die Grenzen der Leistungsfähigkeit kommt. Und da ist es dann doch interessant zu wissen, ob ich mit nem Controller A der 40MHz kann, wirklich schneller bin als mit Controller B der "nur" 20MHz kann. Und ja, ich weiss, dass da noch viele andere Faktoren eine Rolle spielen (angefangen, vom C-Compiler, so ich einen verwende, bis hin zum konkreten Befehlssatz des Controllers). Achja, die Frage hat mich auch ein wenig dazu angesp ornt, mal zu schauen, was denn nun die Geschwindigkeit wirklich beeinflusst und ausmacht. @Marco Danke! Das ist doch mal ein Anhaltspunkt. Vielleicht finde ich ja was im Datenblatt dazu. Steffen.
Hallo, ich hab im Datenblatt zum PIC18Firgendwas die Lösung gefunden, die ich beim ersten durchblättern übersehen habe: "One instruction cycle consists of four oscillator periods. Thus, for an oscillator frequency of 4 MHz, the normal instruction execution time is 1 μs." Der PIC scheint 4 Takte zu brauchen, um einen Befehl auszuführen. Danke für die Unterstützung, Steffen.
> Der PIC scheint 4 Takte zu brauchen, um einen Befehl auszuführen.
Genau so ist es. Ist übrigens auch bei den 16-Bit von Microchip so und
die werden dieses (blödsinnige) Prinzip sicher noch sehr sehr lange
benutzen.
Katzebuckel wrote: > Genau so ist es. Ist übrigens auch bei den 16-Bit von Microchip so und > die werden dieses (blödsinnige) Prinzip sicher noch sehr sehr lange > benutzen. Ich würde das nicht als so "blödsinnig" bezeichnen. Jeder Befehl besteht ja aus 4 Takten: - Befehl dekodieren - Operanden holen - Operation ausführen - Ergebnis zurückschreiben Auch die 1-Clocker machen das so. Der Trick besteht bloß darin, daß sie Befehle quasi parallel abarbeiten mit einem Zyklus Versatz. Dabei können dann Probleme auftreten, z.B. waren die ersten AVRs sehr störempfindlich. Auch das Pimpen der 8051 von 12 auf 6 oder 4 Zyklen ging relativ problemlos. Aber beim Pimpen auf einen Zyklus gabs oftmals kritische Erratasheets. Ich hab z.B. noch 2 völlig unbrauchbare DS89C420 Samples irgendwo rumliegen. Peter
Das Prinzip gilt nur, wenn der geholte Befehl der nächste ist. Gibt es da nicht Befehle, (Sprung) die mehr al s4 Takte brauchen ?
Peter Dannegger wrote: > Jeder Befehl besteht ja aus 4 Takten: > - Befehl dekodieren > - Operanden holen > - Operation ausführen > - Ergebnis zurückschreiben > > Auch die 1-Clocker machen das so. Der Trick besteht bloß darin, daß sie > Befehle quasi parallel abarbeiten mit einem Zyklus Versatz. So einfach geht das nicht. Denn damit handelt man sich ja Abhängigkeiten ein. Wenn man das Ergebnis der vorigen Operation braucht, dann kann man ja nicht einfach die Operanden holen, bevor nicht der vorige Befehl das Ergebnis zurückgeschrieben hat. Dann gibts halt einen oder mehrere Wartezyklen. Ich habe aber noch nie davon gehört, dass es sowas bei den AVRs geben soll. Das bedeutet dann wohl, dass sie tatsächlich in einem Takt die Schritte 2-4 ausführen können. Mir ist allerdings nicht ganz klar, wie das sein kann (interne Taktvervielfachung?). Oder sie arbeiten direkt auf den Registern? > Dabei können dann Probleme auftreten, z.B. waren die ersten AVRs sehr > störempfindlich. Naja, die CPUs im PC sind an der Stelle noch deutlich komplexer und funktionieren trotzdem zuverlässig. Markus
Sicher tun sie das, nur die haben nicht einfach nur nen starken pull-up an /RESET um die Funktion zu garantieren.
@Christian: ja das ist richtig, manche befehle brauchen mehr takte, sprungbefehle meist 2 zyklen.
Eine andere Frage wäre: C or Assembler or ... (zB jolt) Die Effektivität des Compilers + der uC: als Summe ist interessanter als einzelne MIPS (spez. bei C, siehe "C-Modus" [heißt der so?] von PIC18F) Über die Robustheit der Pins - siehe auch Datenblatt. - siehe "Internet" Vergleichen würde ich das Gesamtsystem: C+uC Da gibt es irgendwo eine Vergleichsliste im Internet mit verschiedenen uC, wo = ? Da wurden auch verschiedene C-Compiler verglichen. Was bringt ein guter uC, wenn der C-Compiler schlecht ist bzw. das Assembler nicht das Beste ist ?
Hier möchte ich mal mit einem Mythos aufräumen: Kein Prozessor führt wirklich eine Instruktion in einem einzigen Takt aus. Die Verwendung von einer Pipeline führt aber dazu, daß im Idealfall pro Takt eine Instruktion abgeschlossen werden kann. Kleiner aber feiner Unterschied. Wie Du schon richtig bemerkt hast, unterscheidet Microchip Quarz- und Instruktionszyklen und behaupten dann, daß sie pro Instruktion einen Zyklus brauchen, obwohl es natürlich 4 Quarzzyklen sind.
Peter Dannegger wrote: > Immer diese nutzlosen Fragen. > > Ich kann 8051 und AVR und wüßte keinerlei Aufgabe, wo ein PIC18F besser > geeignet wäre. trotzdem ist es evtl. nicht schlecht seine Architektur kennenzulernen, alleine schon um seinen Horizont zu erweitern. > Also werde ich mich nicht mit dem PIC18F beschäftigen. Verlangt ja auch keiner. Warum gleich so aufgebracht? Ob du dich jetzt dem PIC- oder dem AVR-Lager zugehörig fühlst sei mal dahingestellt: Die Fragen vom Threadersteller waren total begründete objektiv gestellte Fragen. Wo ist da das Problem? Dieser ewige PIC-AVR-Bandenkriegt widert mich an.
Markus Kaufmann wrote: > Peter Dannegger wrote: >> Jeder Befehl besteht ja aus 4 Takten: >> - Befehl dekodieren >> - Operanden holen >> - Operation ausführen >> - Ergebnis zurückschreiben >> >> Auch die 1-Clocker machen das so. Der Trick besteht bloß darin, daß sie >> Befehle quasi parallel abarbeiten mit einem Zyklus Versatz. > > So einfach geht das nicht. Denn damit handelt man sich ja Abhängigkeiten > ein. Wenn man das Ergebnis der vorigen Operation braucht, dann kann man > ja nicht einfach die Operanden holen, bevor nicht der vorige Befehl das > Ergebnis zurückgeschrieben hat. Dann gibts halt einen oder mehrere > Wartezyklen. Ich habe aber noch nie davon gehört, dass es sowas bei den > AVRs geben soll. Das bedeutet dann wohl, dass sie tatsächlich in einem > Takt die Schritte 2-4 ausführen können. > > Mir ist allerdings nicht ganz klar, wie das sein kann (interne > Taktvervielfachung?). Oder sie arbeiten direkt auf den Registern? Ich glaube, zwischen euch beiden gibts ein Missverständnis. Vielleicht hilft folgende Skizze: (Keine Garantie für Richtigkeit. Zu groß ist die Gefahr nachher aufgrund eines Fehlers geteert und gefedert zu werden. :-)) ================================== _ Erhöhe Program Counter / | | __ Instruction wird ins Instruction Reg. | / kopiert (nochmals!?) (lt. datenblatt) | | | | __ Operand Read | | / | | | _ Destination Write | | | / | | | | | | | | | | | | +-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+ | Q1 | Q2 | Q3 | Q4 | Q1 | Q2 | Q3 | Q4 | +-------------------+-------------------+ | FETCH | EXECUTE | +-------------------+-------------------+-------------------+ | FETCH | EXECUTE | +-------------------+-------------------+-- - - | FETCH | +-------------------+--- - - OSC.: _ _ _ _ _ _ _ _ _ _ _ / \__/ \__/ \__/ \__/ \__/ \__/ \__/ \__/ \__/ \__/ \__/ \__/ \__ Quelle: Seite 42 vom PIC18F452-Datenblatt. http://ww1.microchip.com/downloads/en/DeviceDoc/39564c.pdf ================================== Viel bleibt zu der Skizze eigentlich nicht zu sagen, ist eigentlich selbsterklärend. Die PICs haben eine 2 stufige Pipeline, FETCH und EXECUTE. Jede dieser Stufen besteht aus vier "Q Cycles": Q1, Q2, Q3, Q4. Die Q Cycles sind synchron mit dem anliegenden Takt. Jeder Befehl durchläuft (bzw. "dauert") 8 Q Cycles = 8 Takte. Nach dem jedoch die ersten vier Q Cycles des nachfolgenden Befehls zeitgleich mit den letzten vier Q Cycles des vorhergehenden bearbeitet werden (-> Pipelining), dauert ein Befehl "eigentlich nur" 4 Takte. (Genaugenommen ist das falsch. Richtigerweise müsste es heißen: Jeder Befehl dauert 8 Takte, jedoch wird durch die Pipeline alle 4 Takte ein Befehl "fertig". Ausnahme: Sprungbefehle zB. Die zerstören die Pipeline. (Siehe Satz "Abhängigkeiten" von Markus Kaufmann.) 2-stufige Befehle gibts auch, die hab ich mir aber noch nicht näher angesehen, da kann ich nichts dazu sagen) Also: 4MHz ====> 1MIPS 4M Takte/Sekunde ====> 1M abgeschlossene Befehle/sek (wegen den vier Q Cycles) Obs jetzt bei den AVRs anders/besser/schlechter/whatever ist, weiß ich nicht. Die kenne ich nur vom Hören-Sagen. Bildungslücke, ich weiß ;/
Tabelle 20-2 zeigt die Anzahl der Takte (also 4x Quarz), die in Befehl braucht, ;-) => MIPS ist immer optimal, ohne Befehle mit 2 or 3 Takte. Bei abhängigen Sprüngen daher in Klammer weitere Angaben. Gruß, C. p.s.: falls der ADU verwendet wird, dann ist der Takt bei hoher Genauigkeit nicht besonders hoch - wegen Störungen. (bei AVR und PIC) p.s.s.: page 39 zeigt obiges Diagramm 4 MHz bedeutet MAXIMAL 1 MIPS, bei PIC, ;-)
Immerhin haben sie bei manchen von den Pics aus der Not eine Tugend gemacht, und bieten eine 10Bit-PWM an, die die 4 LSBs über die sonst "Weggeteilten" Taktzyklen erzeugt. /Ernst
Ist doch letztendlich egal. Der AVR rennt z. B. mit 20MHz, ein NOP dauert also 50ns. Ein PIC rennt vielleicht auch mit 20MHz extern wohl gemerkt, bei dem dauert ein NOP 200ns. Das interessiert den Programmierer, mehr nicht.
@Manuel Wagesreither: Ich bezog mich eigenlich auf die "1-Takter", die Peter anspricht, also z.B. AVR und diverse 8051-Derivate. Denn die müssen ja die 4 Schritte auch durchführen und zumindest bei den AVRs sind viele Befehle mit einem Takt angegeben, d.h. die müssen zumindest die Schritte 2-4 wirklich in einem Takt schaffen. Markus
@Markus Kaufmann >auch durchführen und zumindest bei den AVRs sind viele Befehle mit einem >Takt angegeben, d.h. die müssen zumindest die Schritte 2-4 wirklich in >einem Takt schaffen. Das tun sie auch. Die AVRs haben eine zweistufige Pipeline. Siehe Datenblatt. MfG Falk
Hi! Nur eine kleine Bemerkung: Viele PICs aus der 18F Serie haben eingebauten 4x PLL und fuehren damit eine Instruktion per Aussenzyklus aus. Nur Sprungbefehle brauchen 2 Cyklen. z.B. 18F4520> http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en010297 Gruss, Aleks
Also ich bin auf ARM umgestiegen und voll auf zufrieden damit. Die Programmierung ist zwar nicht mehr so trivial wie von einem AVR oder PIC, aber wenn man den Dreh heraußen hat, dann funktionierts tadellos. Ich würde jetzt mal behaupten, dass ein PIC bessere Peripherie als der AVR hat. Der PIC18F8722 hat beispielsweise ein externes Speicherinterface. So etwas zu haben macht schon in gewissen Applikationen Sinn. Aber egal wie man es dreht, AVRs haben einfach mehr MIPS!!! Man darf jedoch nicht vergessen, dass ein PIC mit 40MHz getaktet werden kann und AVRs jedoch nur mit 20MHz (sollte ich noch am neuesten Stand sein). Schlussendlich bringt der AVR also nicht 4x so viele MIPS sondern nur 2x.
Thomas P. wrote: > Ich würde jetzt mal behaupten, dass ein PIC bessere Peripherie als der > AVR hat. Der PIC18F8722 hat beispielsweise ein externes > Speicherinterface. So etwas zu haben macht schon in gewissen > Applikationen Sinn. Die AVRs wurden als Konkurrenz zum 8051 auf den Markt gebracht und haben daher auch dessen Businterface geerbt. Geht natürlich nur zum Datenzugriff, nicht zum Code ausführen. Einige (ATMega8515, ATMega162) sind auch fast pinkompatibel zum 8051. Das Businterface ist durch das Adreßmultiplex gut zum direkten Anschluß von SJA1000 (CAN) oder LAN91C96 (Ethernet) geeignet. Peter
Hallo, als ich vor paar Jahren bei den µCs eingestiegen bin , stand ich vor der Frage: Atmel oder Microchip? Obwohl die Features der beiden doch recht ähnlich sind, habe ich mich für die PICs entschieden. Das hatte hauptsächlich 2 Gründe: Zum einen hatte ich mit sprut.de für Anfänger eine Top-Seite für den Einstieg gefunden, für AVR nichts vergleichbares. Zum anderen ist die Qualität der Homepage und der Datenblätter von Atmel im Vergleich zu Microchip echt beschissen. Seitdem bin ich auch bei den PICs geblieben. Wie man sieht, sind MIPS, Leistung, etc. eher nebensächlich. Die Benutzerfreundlichkeit, sprich Programmierung, Einstiegshilfen, Entwicklungsumgebung sind die entscheidenden Faktoren, und da liegt Microchip meines Erachtens vorne, obwohl das bei der Leistungfähigkeit nicht unbedingt der Fall ist. Gruß Stampede
@ Stampede >Zum anderen ist die Qualität der Homepage und der Datenblätter von Atmel >im Vergleich zu Microchip echt beschissen. ??? >Wie man sieht, sind MIPS, Leistung, etc. eher nebensächlich. Die ??? Du bist sicher Windows Vista Fan? Ist ja auch sehr sinnvoll, für bissel Word, Excel und Solitär min. 1 GB RAM und ne 3D Karte im Rechner zu haben. Ressourcenverschwendung bis zum Gehtnichtmehr! >Benutzerfreundlichkeit, sprich Programmierung, Einstiegshilfen, >Entwicklungsumgebung sind die entscheidenden Faktoren, und da liegt Es sind AUCH Faktoren, je nach Bewertung wichtig bis sehr wichtig. Aber wer die Leistung der Hardware mal einfach als Nebensächlichkeit abtut (gerade bei solchen kleine uCs), der hat . . ., naja, sollte vielleicht nochmal über das Thema nachdenken. >Microchip meines Erachtens vorne Was ist bei Atmel so schlecht? AVR Studio ist gut, auch wenn hin und wieder ein paar Service Packs gebraucht werden (welche Software braucht das heute nicht?) WINAVR ist auch super Die Doku ist gut Die Hardware erst recht Wo ist das Problem? MFG Falk
> Viele PICs aus der 18F Serie haben eingebauten 4x PLL und fuehren damit > eine Instruktion per Aussenzyklus aus. Nur Sprungbefehle brauchen 2 > Cyklen. Die interne PLL hat nur den Vorteil, dass man extern nicht mit 40MHz auf den µC gehen muß. Nutzt man die PLL, sind extern max. 10MHz machbar, wenn man den Controller nicht außerhalb seiner Spezifikation betreiben will. Naja ansonsten finde ich, dass sowohl MPLAB mit seiner Möglichkeit, den C18 und C30 zu integrieren, als auch AVR Studio mit der Möglichkeit, avr-gcc einzubinden, sehr leistungsfähige Tools sind. Die Datenblätter beider Hersteller sind gut und manch anderer z. B. Philips (jetzt NXP) oder Renesas kann sich da eine Scheibe abschneiden. Einzig negativ ist mir bei Microchip aufgefallen, dass die Produkte auf den Markt werfen, die funktionstechnisch doch extrem grenzwertig sind. Sowohl bei Microcontrollern als auch anderen Bausteinen (z. B. ENC28J60) funktionieren Teile einfach nicht und als Anwender sitzt man da wie ein Ochs vor dem Berg. Jetzt wo ich das schreibe, fällt mir gerade der ATmega169 mit seinem integrierten LCD-Controller ein. Bei dem war auch einiges ziemlich übel.
@Falk: Du hast nicht verstanden, was ich sagen wollte. Ich schrieb: "Beide sind sich, was die Features anbelangt, ähnlich." Die beiden 8-Bit-RISC's sind ähnlich schnell oder langsam, je nach Takt. Was ich sagen wollte: Wenn man also über den Einstieg nachdenkt, ist bei ähnlicher Leistung (10-12MIPS, für mehr sollte man eh 16 oder 32-Bit Architekturen nehmen) die einfache Bedienung und der reibungslose Einstieg wichtiger. Und da ist m.E., Microchip besser. Mit "da" meine ich Dokumente, Einstiegshilfen, web, Entwicklungsumgebung, etc. Ich denke das habe ich aber in meinem vorherigen Beitrag unmisverständlich deutlich gemacht. Das heißt nicht, dass ich Atmel's Produkte schlecht machen will, die haben definitiv auch ihre Vorteile. Btw: mit Vista hab ich nix am Hut... und für Solitär hab ich sogar 2GB RAM und 2GB Auslagerungsdatei reserviert!
Kannst du etwas konkreter sagen, was speziell bei Microchip bez. der "Einstiegshilfen" so sehr viel besser ist?
Hallo, ich möchte hier keine Grundsatzdiskussion anfangen, ich wollte nur erkären WARUM ich mich für PICs entschieden habe. Ich habe mich im Internet zunächst über die Kontroller schlau gemacht, ich war vor Allem auf der Suche nach einer Seite, die mir einen leichten Einstieg bietet. Da bin auf www.sprut.de gestoßen, wirklich DIE Seite was PIC anbelangt. Eine ähnlich gute Seite, die sich mit AVR auseinandersetzt, habe ich leider nicht finden können. Auf der Homepage von Microchip sind Sachen wie "Getting Started" oder Features der Produkte besser zu finden bzw. direkt auf der Startseite dargestellt, man erspart sich nerviges Suchen. Dann sind die Datenblätter von Microchip wirklich besser. Ein Beispiel: Ich hatte eine AVR-Schaltung gefunden, die den ADC benutzt. Daher wollte ich wissen, welche Impedanz die zu messende Größe haben sollte, damit der ADC ordentlich funktioniert. Auch nach langer Suche bin ich da bei Atmel weder im Datenblatt oder auf der Homepage fündig geworden. Zudem haben die meisten Atmel-pdfs keine Lesezeichen, und sind optisch einfach nicht so gut unterlegt wie Microchip das macht. Das sind zwar keine technischen Vor- oder Nachteile, jedoch machen sie die Arbeit deutlich angenehmer. Was die Erratas der AVR's anbelangt, bin ich nicht im Bilde. Da erlaubt sich Microchip schon mal den ein oder anderen Schnitzer. Zudem hat Elektor die MPLAB IDE von Microchip als beste Entwicklungsumgebung bezeichnet, das ist natürlich nicht verbindlich, aber zumindest ein Indiz. Ich habe immer das Gefühl, dass die AVRler sich gleich angegriffen fühlen, wenn man was gegen ihre Kontroller sagt. Vielleicht war ich anfänglcih bisschen hart mit der Kritik. Aber ich nie gesagt, dass "Microchip so viel besser ist". Mir ging es ausschließlich darum, meine Beweggründe für die Entscheidung für die PICs darzustellen. Grüße Stampede
Stampede wrote: > Zudem hat Elektor die MPLAB IDE von Microchip als beste > Entwicklungsumgebung bezeichnet, das ist natürlich nicht verbindlich, > aber zumindest ein Indiz. Wenn ich mir die Abstürtze des MPLAB anseh wenn den ICD2 abzieht und wieder ansteckt und die MPLAB nicht neu startet ohne anschliessenden neu starte der IDE. Dann stürtzt die IDE kommentarlos ab. Oder es dürfen keinen Leerzeichen im Ordnernahme sein.
Bei Microchip sind auf jeden Fall die Application Notes besser und umfangreicher als die bei Atmel. Ich habe zwar noch keine PICs programmiert, aber bei den ANs schon einige interessante Dokumente gefunden (z.B. der 3-Phasen Frequenzumrichter), die auch für nicht PICler interessant sind.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.