Hallo, ich habe gerade Semesterferien und hab mir überlegt wie "einfach" es ist eine Selbstgebaute Lüftersteuerung per Windows zu steuern. Ich hab bereits ne Vorlesung zu PICs hinter mir und höre gerade eine zu ARM. Deswegen würde ich das Ganze gerne mit einem ARM machen. Auf sprut.de gibts allerdings sehr viele gute Infos zu USB mit nem PIC. Für ARM hab ich bis jetzt sehr wenig gefunden, und mir das alles selber beizubringen wird denk ich ganz schön viel Zeit kosten. Hatte bisher nur 5 Wochen Vorlesung. Deswegen meine Frage, was ihr mir empfehlen würdet. Gibts zu ARM auch so tolle Tuts (gerne auch Englische)? Gedacht habe ich mir den Aufbau folgendermaßen: OP+pMOSFET zur Spannungsregelung um die Spannung am OP zu Regeln hätte ich jetzt nen Digitalen Poti verwendet. den Poti kann man dann einfach mit Impulsen regeln. Die Impulse kommen naütrlich von meinem uC. Der wiederum soll auch noch die Lüfterdrehzahl einlesen. Die Steuerung erfolgt dann per Windows über USB. Wie gesagt, das was mir am meisten Kopfzerbrechen bereitet ist die USB Geschichte. MfG Nico
Daß ein ARM als Lüftersteuerung vollkommen oversized ist, ist Dir sicher selber klar. Das dürfte auch der Grund dafür sein, daß es keine Projekte dazu gibt. Ich habe selbst mal eine Lüftersteuerung gebaut, ich hatte dazu den kleinsten PIC genommen, den ich gefunden hatte (irgendein Achtfüßler). Um das Ding um ein USB-Interface zu erweitern, würde ich einfach einen FT232RL dranschrauben.
Ich hätte mal ne Frage was die ganze USB Geschichte angeht. Ist die USB Realisierung mit nem PIC oder nem AVR einfacher? Bin gerade am einlesen und mit nem AVR liest sich das irgendwie einfacher, auch wenn ich mit dem relativ wenig erfahrung habe.
Das hab ich auch gesehen. Deswegen meine frage. PICs hatte ich halt in der Vorlesung aner UNI schon. AVR nochnet. Deswegen die frage an diejenigen die das schon gemacht haben was einfacher ist. Aber ich denk ich werds mit AVR probieren.
Ich habe beim Suchen im Internet ein Beispiel gefunden, das genau das ist was ich will. http://www.contrabyte.de/de/?page_id=7 Da kein AVR mehr als 4 PWM hardwareseitig hat, werde ich um Soft-PWM auch nicht herumkommen. Ich bin mittlerweile auch vom V-USB weg, da das anscheinend nicht das Gelbe vom Ei ist. Ich dachte jetzt an eine Realisierung mit nem ATmega16 und einem FTDI chip. Als Grundschaltung würde ich dann sowas nehmen: http://www.rn-wissen.de/images/6/65/Avrtutorial_grundschaltung_max232.gif und dann noch den FT232R mit folgendem schaltplan aus dem Datenblatt (S.27) http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf dazu. An die Pins kommt dann noch meine Schaltung von PWM auf 0-12V und ich wäre von der Hardware theoretisch fertig oder? Das heißt der rest müsste "nurnoch" per Software realisiert werden. Wobei das auchnoch ne Sache für sich ist. Kann ich den AVR direkt ohne Bootloader Programmieren? Funktioniert das mit dem FTDI Chip per usb?
Mal als Anregung ansehen: http://www.elektor.de/jahrgang/2012/marz/sensible-pc-lufter-regelung.2084489.lynkx
Angehängte Dateien:
-
HLLSglcdsmall.jpg
160 KB
1 | Da kein AVR mehr als 4 PWM hardwareseitig hat, werde ich um Soft-PWM |
2 | auch nicht herumkommen. |
Ein Mega64 hat 6x 16 Bit PWM + nochmal 2 von denen eine am selben Pin hängt wie die 16 Bit, also trotzdem noch 7. Hab sowas für meinen Wasser gekühlten PC gemacht, läuft seit >2 Jahren in meinem Computer. Jetzt ist er endlich leise, wenn mehr Wärme abgeführt werden muß, bin ich eh am zocken und hörs nicht. M128 + FT232RL Touch GLCD 6 DS18S20 + die Computer Sensoren via USB
N. M. schrieb: > Ich hätte mal ne Frage was die ganze USB Geschichte angeht. > Ist die USB Realisierung mit nem PIC oder nem AVR einfacher? > > Bin gerade am einlesen und mit nem AVR liest sich das irgendwie > einfacher, auch wenn ich mit dem relativ wenig erfahrung habe. Allerdings frage ich mich gerade WO du denn geschaut hast? USB mit PIC 18F ist wenn man die gesamten Umstände (Herstellerdokus, LIBs, BEispiele vom HErsteller) so ziemlich das einfachste was man an Möglichkeiten der PC <-> Embedded Anbindung findet. Was man nur nicht darf ist sich an den allerersten PIC16 mit USB zu orientieren... Wenn du es ganz einfach möchtest nimm das USB - CDC Serial Demo von Microchip als Ausgangsbasis. Da hast du dann zwei bzw. vier Funktionsaufrufe über die die USB Kommunikation läuft und das meldet sich am PC als Virtuelle COM an. Schau dir einfach mal die Downloads zum USB LOW PIN COUNT DEV KIT von Microchip an. Da ist auch alles an Beispielprogrammen, Anleitungen und Schaltplan dabei. Das Board selber brauchst du nicht unbedingt, PIC18F14K50 solo und Lochraster reicht um das mal durchzugehen... http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en536385 Dann gibt es auch noch die Microchip Application Libraries mit dem USB Framework wo zahlreiche weitere Beispiele enthalten sind. http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784 Gruß Carsten
@ sBronco genau das ist es, was ich auch will. Nur ohne das LCD-Display, dafür per Software aus Windows raus steuern. @ Carsten Die ganzen Beispiele, für PIC und usb waren alle nur für den 18F2550 oder 4550. Der hat aber leider nur 2 PWM ausgänge. Da hatte ich noch nicht an Soft-PWM gedacht. Aber wenn man im Inet ein wenig sucht, und auch hier im Forum, dann findet man viel mehr zu AVRs als zu PICs. Und das einrichten von USB für nen PIC fand ich schwerer als jetzt die Lösung mit nem FTDI Chip. Meine Kentnisse was das Programmieren angeht sind recht beschränkt. Ich habe an der FH bisher nur Info1,2 gehabt und jeweils Vorlesungen zu PICs und gerade ARM. Die Software sollte nicht das Problem sein. Wos an Wissen hapert ist eben die Verbindung zwischen PC und embeddet anwendung. An der FH ham wir halt unsere tollen Demo-Boards etc. Das ist zwar alles schön und gut aber für die Praxis, wie ich es jetzt brauche, ist es eher unbrauchbar. Und da ich gerade ziemlich viel am lesen bin ich gerade noch etwas mit den ganzen Infos überfordert.
Ich hatte vorher eine Regelung, die über einen PTC und LM317 die Spannung geführt hatte. Die Nachteile waren der VDrop vom LM317 und das bescheidene Ansprechverhalten der Regelung. Bin dann über diese Seite [http://www.keiang.de/Content-pid-46.html] gestolpert, den Dallas Chip gibts allerdings seit Jahren nicht mehr, deshalb hab ich dann AVRs programmieren gelernt... Die Idee kam aber von dort.
Hast du das Programmieren dann mit Hilfe der Dokus hier gemacht? http://www.ftdichip.com/Support/Documents/ProgramGuides.htm Ne Seite mit nem Beispiel hat keienr spontan parrat? Die Datenblätter sind halt nicht immer der Beste einstieg. Ich werd mcih nochmal genauer suchen wenn ich meinen PS-Bericht für die FH fertig habe.
N. M. schrieb: > @ Carsten > Die ganzen Beispiele, für PIC und usb waren alle nur für den 18F2550 > oder 4550. Der hat aber leider nur 2 PWM Ausgänge. Da hatte ich noch > nicht an Soft-PWM gedacht. SOFT-PWM und USB ist immer so eine Sache, da BEIDES Zeitkritisch ist. Es funktioniert natürlich oft trotzdem Problemlos nebeneinander, aber man sollte schon vorher überlegen wie man es sauber umsetzt. Wobei aber auch zu sagen ist das wenn es "nur" um eine reine Lüfterregelung geht man es natürlich hinsichtlich der PWM auch etwas lockerer angehen lassen kann. Wenn da mal eine Millisekunde lang das Tastverhältniss nicht stimmt spielt das im gegensatz zu so manch anderer Anwendung für PWM keine Rolle - das wirkt sich nicht aus. Allerdings hast du im Eingangspost kein Wort von "vielen" PWM Kanälen geschrieben. Das ist aber ein nicht unerheblicher Punkt deiner Anforderungen. Wenn es also eine Lüfterregelung mit "vielen" Kanälen sein soll, dann kann es durchaus ein Argument sein um DOCH auch einen "größeren" µC in Betracht zu ziehen. Auch wenn es von der Rechenleistung oversized ist, so kann die passendere Peripherie ein gutes Argument PRO sein. In Betracht ziehen würde ich in deiner Situation entweder die kleineren ARM (ARM7, CortexM3) oder die PIC32 (mit MIPS Kern). > Aber wenn man im Inet ein wenig sucht, und auch hier im Forum, dann > findet man viel mehr zu AVRs als zu PICs. Das ist soweit eine absolut richtige Feststellung. Allerdings sollte man nicht Quantität mit Qualität gleichsetzen. Dieser Unterschied in der häufigkeit der Fundstellen liegt in der recht unterschiedlichen Supportpolitik der Hersteller begründet. Der Support für die AVR erfolgt zum großen Teil durch die "Community" was bedeutet das sich viele Leute die Tools/libs und Beispiele erst selbst erstellen und diese dann Publizieren. Oder mangels Anfängerverständlichen Hinweisen soetwas erstellen. Daraus resultieren die vielen Fundstellen, wo aber nicht selten dasselbe in nur leicht unterschiedlichen Versionen durchgekaut wird. Bei Microchip werden deutlich mehr Hilfsmittel durch den Hersteller direkt zur Verfügung gestellt und diese sind normalerweise auch sehr Zeitnah mit der Verfügbarkeit entsprechender Bausteine Online. Dadurch entfällt die Notwendigkeit eigene Lösungen zu erstellen. Und eine Lösung die man nicht selber erst erstellt braucht man auch nicht Publizieren. Mal als einfaches Beispiel: Für AVR findest du mit Sicherheit ZAHLREICHE Lösungen für Soft-SPI, SOFT-I2C oder auch die Ansteuerung von LCD Textdisplays. Für PIC deutlich weniger... Aber: Für PIC gibt es all diese Sachen schon direkt von Microchip selbst als Bestandteil des kostenlosen Compilers der SOWOHL Libs für die HARDWAREMODULE als auch für solche Softwarelösungen hat. > Und das einrichten von USB für > nen PIC fand ich schwerer als jetzt die Lösung mit nem FTDI Chip. Auch hier ist wieder die Frage: WO hast du denn geschaut? Ich gebe zu, USB kann am Anfang etwas verwirrend sein, einfach weil USB nicht USB ist und man schnell etwas durcheinander wirft. Insbesondere wenn man an verschiedenen Stellen sucht und nicht bemerkt das ein Beispiel die Implemtierung eines CDC Devices beschreibt während das andere ein HID oder gar ein Custom Device ist. Bei einem CDC Device kann man beispielsweise fast alles COPY&PASTE übernehmen, egal ob man nun einen µC mit integrierter HArdware oder aber einen Baustein wie den FTDI verwendet. Näheres Hintergrundwissen zu USB braucht man dazu definitiv nicht. Auf PC Seite behandelt man das dann als normale COM Schnittstelle. Bei HID sind immerhin schon geringe Anpassungen meist zwingend notwendig, bei einem CUSTOM DEVICE ist schon enormes Hintergrundwissen zu USB notwendig. Ich widerhole hier noch mal meine Empfehlung von oben: Gehe mal auf diese Seite und lade dir das Benutzerhandbuch und die Beispiele herunter: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en536385 Im Handbuch findest du eine kurze Einführung mit Anwendungsbeispielen zu USB. Wenn du die durchgehst bist du zumindest in der LAge USB im Modus CDC-Device genauso einfach zu nutzen wie eine normale UART. Der Schaltplan zum Board ist ebenfalls im HAndbuch mit dabei, das kannst du dir für 5Euro material in weniger als einer Stunde Nachbauen, damit hast du auch schon eine gute Referenzschaltung. Wobei allerdings der PIC18F14K50 für eine PWM Schaltung mit vielen Kanälen nicht unbedingt die richtige Wahl ist. Aber man lernt erst einmal damit umzugehen. Und als TIP: Man kann das USB CDC Serial Demo aus dem Microchip Framework nehmen und einfach ohne jede Veränderung auf einen 18F13K50 brennen. Dann hat man eine gute Alternative zu einem FTDI, einen Serial->USB Wandler der weder Initialisiert noch sonstirgendwie vom HauptµC konfiguriert werden muss und einfach funktioniert. Der Vorteil ist das es diesen Baustein sowohl in DIP wie auch in allen gängigen SMD Gehäusen für diese Größe gibt (SOIC, SSOP, QFN) und das er dabei mit knapp 2 Euro nur die hälfte des FTDI232 kostet. Somit kann man auch Problemlos auf Lochraster arbeiten. Einzig ein externer Quarz ist noch notwendig... > > Meine Kentnisse was das Programmieren angeht sind recht beschränkt. Ich > habe an der FH bisher nur Info1,2 gehabt und jeweils Vorlesungen zu PICs > und gerade ARM. Verstehe ich das Richtig? Ihr habt Vorlesungen die sich ganz spezifisch um EINE EINZIGE Architektur drehen? Was soll das bringen? Klar - irgendwelche Bezugsbeispiele braucht man immer. Aber die spezifischen Eigenschaften sind dabei dann doch eher Nebensächlich. Bei uns wurde die Theorie zum Beispiel in der Regel an der MIPS Architektur erläutert während im Praktikum auf einem ARM7 gearbeitet wurde. Aber im Grunde ging es immer um die Grundlagen, die wirklich spezifischen Sachen waren immer nur nebensache, schließlich gibt es so viele Systeme das man die ja gar nicht alle behandeln kann, daher geht es darum die Grundlagen verstanden zu haben und sich damit schnell in eine Architektur hineinzuarbeiten. Eine Vorlesung die mit einer Prüfung endet in der dann abgefragt wird welche Nebenfunktion der RB7 beim PICxxx hat ist daher sicher alles andere als Sinnvoll. > An der FH ham wir halt unsere tollen Demo-Boards etc. Das ist zwar alles > schön und gut aber für die Praxis, wie ich es jetzt brauche, ist es eher > unbrauchbar. Was sind das denn für Demo Boards? Sind das irgendwie mit einem haufen Funktionen wahllos zugeflasterte Boards um damit ein paar Übungen durchzuspielen, oder sind das "richtige" Entwicklungsboards? Zu Anfang meiner Tätigkeit fand ich diese ganzen Demo- und Entwicklungskits auch total unnötig und nutzlos. Mittlerweile habe ich den Sinn dahinter aber gut verstanden und nutze diese als Ausgangsbasis gerne. Mit dem Board hat man einer erste Arbeitsgrundlage wo man eine Funktionierende Hardware und meist auch schon ein Software Grundgerüst hat. Will man nun eine Spezifische Funktion Realisieren so fängt man auf dem Demo Board an, man weiß ja wenn da etwas nicht läuft ist es die Software, die Hardware ist ja in Ordnung. Gleichzeitig Plant man die Hardware wobei man oft den Teil des DemoBoards dessen Funktionalität man benötigt als Referenzdesign nutzt. Wenn dann irgendwan die Platinen/Baugruppen vom Fertiger kommen dann spielt man seinen bis dahin realisierten Softwarestand auf und wenn dann etwas auf dem DemoBoard läuft, auf der eigenen HArdware aber nicht weiß man das die Hardware eine Macke hat. Bis ich das so akzeptiert habe hat es mich aber eine Menge Stunden unnützer Fehlersuche gekostet wo ich nach einem Softwarefehler gesucht hat, aber ein HArdwarefehler vorlag oder umgekehrt. Gruß Carsten
Also die Lüftersteuerung soll aus Windows raus konfiguriert werden können. Sie soll anschlüsse für bis zu 8 Lüfter und deren RPM Signal haben. Mehr net. Keine Temp-Sensoren etc,da ich das alles über das MB auslesen will. Wobei zwei bis drei Sensoren nciht schaden können. Aber das is das geringste problem. Ich will die Lüfter eh nicht direkt per PWM regeln, da ich dafür gar keine Lüfter habe und ich von PWM bei lüftern eh nix halte. Das PWM hätte ich über nen RC geglättet, an nen OP geschickt und dann mit nem pMOSFET die 0-12V Spannung ausgegeben. Es gibt auch Digitale Widerstände, dann könnte die ganze PWM spielerei wegfallen. Aber ob das so gut funktioniert weiß ich nicht, und ich fand das mit PWM die geschicktere Lösung. Die Vorlesungen bei mir heißen Digital- und Mikrocontroler, hier haben wir unsere verscuhe mit dem PIC gemacht. Das heißt nicht das wir uns nur mit dem PIC beschäftigt haben. Die Grundlagen wurden natürlich gelegt. Aber der Fokus war nunmal der PIC. Aber die ganzen uC geben sich nicht allzuviel...wenn man Assembler mit nem PIC kann, dann ist das auch bei nem ARM nicht allzuschwer. Die aktuelle heißt Embeddet Systems. Auch hier gibts Grundlagen, aber der Fokus ist auf dem ARM. Es gibt noch ne andere Vorlesung über AVR, aber die kann ich dieses Semester nicht besuchen. Wir haben z.B. die Laborplatine MCB2300. Ich habe in den letzten zwei Tagen irgendwie zu viel gelesen^^ Das verwirrt mich gerade mehr als das es mir hilft. Deswegen hab ich hier noch ein wenig um Hilfe ersucht ;) Das hier z.B.: http://www.sprut.de/electronic/interfaces/usb/usb.htm Ist schön von grundauf aufgebaut aber wie du schon sagtest...USB halt. Für jemanden der noch nie damit zu tun hatte ist das halt anfangs verwirrend.
N. M. schrieb: > Die aktuelle heißt Embeddet Systems. Auch > hier gibts Grundlagen, aber der Fokus ist auf dem ARM. Es gibt noch ne > andere Vorlesung über AVR, aber die kann ich dieses Semester nicht > besuchen. An welcher Uni/FH bist du? Und was studierst du? Euch scheint ja richtig was im Embedded-Bereich geboten zu werden. Gruß Oliver
N. M. schrieb: > Ich will die Lüfter eh nicht direkt per PWM regeln, da ich dafür gar > keine Lüfter habe und ich von PWM bei lüftern eh nix halte. Das PWM > hätte ich über nen RC geglättet, an nen OP geschickt und dann mit nem > pMOSFET die 0-12V Spannung ausgegeben. Es gibt auch Digitale > Widerstände, dann könnte die ganze PWM spielerei wegfallen. Aber ob das > so gut funktioniert weiß ich nicht, und ich fand das mit PWM die > geschicktere Lösung. Dann hast du pwm nicht verstanden^^
> Ich will die Lüfter eh nicht direkt per PWM regeln, da ich dafür gar > keine Lüfter habe und ich von PWM bei lüftern eh nix halte. Verwechselst Du hier nicht die "normalen" PC-Lüfter mit 3 Pins (+12V, GND, Sensor) mit den 4-Pin CPU-Kühlern (+12V, GND, Sensor, PWM-Signal zur Geschwindigkeitsvorwahl)? Letztere wären für Dein Vorhaben tatsächlich eher ungeeignet, da Du per PWM nicht etwa direkt die Geschwindigkeit wählst, sondern eher einen Temperaturwert überträgst, der dann anhand einer internen Kennlinie im Lüfter in eine Umdrehungsgeschwindigkeit umgesetzt wird. Das wurde von Intel so spezifiziert damit man nur CPU + passenden Boxed-Lüfter braucht und keine Kennlinien im BIOS programmieren muss. Aber einen 3 Pin-Lüfter per PWM anzusteuern ist eigentlich die beste Lösung. Und das machen eigentlich auch alle Mainboards so für ihre Gehäuselüfter. Der Lüftermotor ist so träge, daß Du z.B. bei 100 Hz PWM-Frequenz (also sehr langsam und gut per Soft-PWM zu machen) keinerlei Unterschied im Umdrehungsverhalten siehst. > Das PWM > hätte ich über nen RC geglättet, an nen OP geschickt und dann mit nem > pMOSFET die 0-12V Spannung ausgegeben. Damit betreibst Du Deinen FET im linearen Bereich, verheizt also die überflüssige Spannung. Damit musst Du einen Kühlkörper vorsehen, brauchst einen für Linearbetrieb geeigneten FET, etc. Also nicht wirklich zu empfehlen. Noch nen paar Tips: - Nimm nen N-FET statt nem P und schalte damit das GND des Lüfters (also Lowside). N-FETs sind von den Daten her immer besser als Ps und auch gängiger/billiger/besser vefügbar. - Freilaufdiode nicht vergessen. - Mach ne Frequenzüberwachung für das Sensorsignal auf den Mikrocontroller. Wenn keine Umdrehung mehr entweder ganz abschalten oder noch besser, für ca. 2 Sek. auf 100% Leistung. Wenn er dann immer noch nicht dreht für 15 Sek. aus und wieder mit 100% versuchen. Hintergrund: Wenn der Lüfter wegen zu geringer Leistung stehen bleibt, fährst Du ihn so wieder an. Das passiert bei besseren Modellen so bei 5-10% Leistung. Wenn er dagegen blockiert ist, hilft das auch nix mehr und der Motor zieht viel Strom. Daher für ne Weile abschalten. Diese Überwachung solltest Du auf den Controller packen, wenn Dein Windows gerade Bootet, Updated, abgestürzt ist,... sollten die Lüfter nicht ausgehen oder durchbrennen. Was die Ansteuerung angeht: Ich denke der einfachste Ansatz dürfte nen AVR und nen FTDI FT232R sein. Die Kommunikation zwischen Windows und AVR läuft dann seriell, das ist auf beiden Seiten einfach anzusteuern. Alles was USB direkt macht ist komplexer, auch mit der schönsten Hersteller-Lib. Da diese Kombination auch auf den Arduino-Boards verwendet wird, kannst Du auch deren Libs als Basis nehmen. Da gibt es sehr viel Dokus und Hilfe zu im Netz. Ich find aber deren GUI-Konzept und Make-System gräßlich. Das ist aber persönlicher Geschmack, für den Einstieg kommt man damit schnell über die ersten Hürden.
N. M. schrieb: > Ich will die Lüfter eh nicht direkt per PWM regeln, da ich dafür gar > keine Lüfter habe und ich von PWM bei lüftern eh nix halte. Das PWM > hätte ich über nen RC geglättet, an nen OP geschickt und dann mit nem > pMOSFET die 0-12V Spannung ausgegeben. Es gibt zwei "übliche" Anwendungen für PWM. Einmal als reines Steuer-/Sensorsignal wo der Tastgrad durch Elektronik ausgewertet und in eine weitere Steuergröße umgesetzt wird. Beispielsweise bei Modellbauservos ist es so. Oder es gibt AUCH ABS Sensoren die so arbeiten. Und noch viele viele andere Dinge. ICh vermute mal das hast du gerade im Kopf. Aber es ist in vielen Bereichen wo es um Leistungsregelung geht auch üblich DIREKT das PWM Modulierte Signal auf den Verbraucher einwirken zu lassen. Sofern der Verbraucher eine gewisse Trägheit besitzt (Wärmekapazität bei einer Glühlampe, "Masseträgheit" bei einem Lüfter) wirkt der Verbaucher selbst als Integrator und er integriert das Signal derart das es sich in seinen Auswirkungen nicht von einer Gleichspannung in der Höhe des Effektivwerts der pulsmodulierten Spannung unterscheidet. Je träger der Verbaucher um so "langsamer" kann die PWM sein ohne das es einen Unterschied macht. Oder vereinfacht gesagt: Wenn du ein PWM Signal mit U^ von 12Volt hast das mit 50% Tastgrad ausgegeben wird, dann dreht sich der Lüfter genauso schnell als wenn du eine geglättete 6V Gleichspannung anlegen würdest. 25% Tastgrad entsprechen dann 3V... Es ist für eine Lüftersteuerung also völlig unnötig, ja sogar absolut kontraproduktiv da eine zusätzliche Schaltung zur Integration aufzubauen. Einfach dir PWM direkt auf den Verbaucher geben und den Transistor für die Leistung schön im Schaltbetrieb laufen lassen. Eine 8Kanal PWM bei der es NUR um den zweiten Anwendungsfall geht wie bei deiner Lüftersteuerung oder bei einem Dimmer ist auch bei einem einfachen µC nebenher auch noch bequem mit nur einem Timer möglich. Also auch wenn da noch USB nebenher läuft. Wenn es nur um ein "Stellen" der Drehzahl und keine echte Regelung geht dann erst recht! > Ich habe in den letzten zwei Tagen irgendwie zu viel gelesen^^ > Das verwirrt mich gerade mehr als das es mir hilft. Deswegen hab ich > hier noch ein wenig um Hilfe ersucht ;) > > Das hier z.B.: > http://www.sprut.de/electronic/interfaces/usb/usb.htm > > Ist schön von grundauf aufgebaut aber wie du schon sagtest...USB halt. > Für jemanden der noch nie damit zu tun hatte ist das halt anfangs > verwirrend. JA, und das ist nur eine grobe Übersicht ohne in die Tiefe zu gehen! Aber halt das ganze Spektrum einmal angerissen. Wie gesagt, nehme dir wirklich mal die oben von mir verlinkten MC Dokus vor. Für den Anfang würde ich bei deiner Sache mit einem CDC Device einsteigen. PC Seitig ist das dann COM und bei PICs hast du beispielsweise dann nur ZWEI Arrays, eines in dem die Empfangenen Daten stehen und eines in dem du nur die auszugebenden Daten hineinschreiben musst. Nur die Nutzdaten natürlich, der Rest macht das Framework. 95% können einfach nur Copy&Paste sein. Gerd E. schrieb: > Ich denke der einfachste Ansatz dürfte nen AVR und nen FTDI FT232R sein. > Die Kommunikation zwischen Windows und AVR läuft dann seriell, das ist > auf beiden Seiten einfach anzusteuern. Ne, das sehe ich GERADE HIER anders. Er hat Erfahrung mit PIC und ist dabei am ARM zu lernen. Warum sollte er sich dann in dieser Phase noch mit einer dritten Architektur beschäftigen. (Ist normalerweise schon richtig über den Tellerrand zu schauen, aber doch besser NAcheinander) Man kann aber den FTDI auch an einen PIC hängen, wobei ich das HIER nicht machen würde sondern eher wie oben von mir vorgeschlagen als Konverter, wenn es denn mit einem extra Konverter sein soll, einen 13/14K50 nehmen und das CDC Serial Emulator Demo aufspielen. Damit hat man dann auch den RS232 <-> USB Umsetzer, nur für den halben Preis und wenn man doch alles in einem µC machen will kann man es sich immer noch überlegen und hat dann nicht den "teuren" FTDI da nutzlos in der Ecke liegen. Das ist dann ein wirklich fließender Übergang... Wie gesagt, isch würde hier an stelle des TO die Auswahl nur zwischen den beiden Typen PIC und ARM treffen. ARM ist etwas OVersized, aber für ein einzelnen Bastelstück spielt das kaum eine Rolle und es ist begleitend zu seinem gerade aktuellen Lernstoff. Die PIC hingegen kennt er schon und die sind auch preislich sehr attraktiv. Zudem hat man hier jederzeit die Wahlfreiheit ob man den PIC nur als "billigen" Umsetzer verwendet oder ein richtiges Device damit realisieren will. Gruß Carsten
Ich habe mich bewusst gegen reins PWM entschieden. Ich befasse kich Hobbymäsig gerne mit PC hadware und aus eigener Erfahrung halte ich gar nichts von PWM Lüftersteuerungen. Ich hatte schon so viele Lüfter in den figern und es gibt solche die pfeifen ohne ende und andere wieder stört das PWM gar nicht. Mir is klar, dass ich einiges an Listung verheize. Aber nehmt es einfach als anforderung hin ;) Wenn ich heute abend daheim bin les ich mir das von microchip mal durch. Ich studiere übrigens Mechatronik an der FH in Mannheim. Schwerpunkt Informationstechnik. Sry für Rechtschreibfehler aber bin grad mur mit dem IPod online
> Ich hatte schon so viele Lüfter in den figern und es gibt solche die > pfeifen ohne ende und andere wieder stört das PWM gar nicht. Das kann passieren, dann passt die PWM-Frequenz und der Aufbau des Lüftermotors nicht zusammen. Kannst Du ganz einfach lösen in dem Du mit der PWM-Frequenz etwas hochgehst.
So...ich habs jetzt in den Semesterferien hinbekommen mal alles zusammenzulöten. Funktioniert aber leider nicht. Das Board wird am PC nur als "unknown device" erkannt. Entweder ich hab was falsch zusammengebastelt, oder das geht an meinem PC aus irgendeinem Problem nicht(laut google wäre ich nicht der erste) Eine Frage hätt ich noch zum Schaltplan. Warum sieht der Quarz so komisch aus? Ich kenn das normale zeichen nur als --|0|-- plus eventuell Kapazitäten parallel. Aber da sieht das ganze irgendwie komisch aus. Ist das nen ganz normaler Quarz mit zwei Kapazitäten oder irgendwas besonderes= MfG
So. Funktioniert mitlerweile alles ganz prima. Bin jetzt gerade am überlegen welchen PIC ich dann für mein finales Produkt nehmen kann. Und da bräuchte ich kurz hilfe. Ich wollte mich eigentlich für den PIC18F27J53 entscheiden. Das ist der einzigste mit mehr als zwei CCP Modulen und USB. Frage 1 ist jetzt: Er hat kein EEPROM. Ich wollte eigentlich die Möglichkeit haben in den EEPROM zu schreiben, mit was fürner Umdrehungszahl die Lüfter beim booten des PCs z.b. laufen sollen. Da wäre jetzt die Frage: was heißt self-write? Das nen Bootloader geht? Oder das ich genauso wie den EEPROM den FLASH beschreiben kann? Dann könnte ich den PIC nehmen. Ansonsten müsste ich echt nochmal überlegen. Frage 2: Für den 47J53 gibts von Microchip nen Bootloader. Wollte ich eigentlich auch einbaun. Kann ich den nahezu oder noch besser 1zu1 für den kleineren übernehmen? MfG
Genial...danke. Hat mir echt weitergeholfen! Den 14k50 hab ich zwar im Moment nicht auf meinem Demoboard am laufen aber was solls. Und er hat ja auch mehr als ein CCP Modul...geniale Empfehlung -.-
Thread beobachten
Seitenaufteilung abschalten
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.