Hallo MC-Forum! Dies ist mein erster Beitrag hier, also bitte nicht gleich lynchen, wenn das hier falsch oder zu viel auf einmal ist. Für meinen Homeserver suche ich die passende uC-Lösung. Da ich mit der Materie im Prinzip noch nie zu tun hatte wäre es super, wenn ihr mir hier helfen könnt. Lest bitte einfach mal weiter, worum es genau geht. Es ist ein Haufen Zeug auf einmal, also lasst euch ruhig etwas Zeit. Ich dachte nur ich schreib alles rein, bevor dann erst grundlegende Rückfragen geklärt werden müssen. Zum Thema: Der Server an sich ist ein Mainboard aus einer t-online S100 Set-Top Box. Dieses Board habe ich schon in ein Dbox2 Gehäuse verfrachtet. Auf der Kiste läuft Debian 5 ganz passabel. Was mir jetzt fehlt ist ein passendes "Frontend" für das Ganze. Das Bedienteil der S100 passt nicht in die Dbox und ich das Dbox2-Display kann bisher wohl auch nicht verwendet werden (unbekannte Ansteuerung). Es sind +5V DC geregelt mit max. noch 1-1,5A reichlich zur Verfügung, der ganze ATX konforme Rest incl. 12V eher weniger (picoPSU-60-WI). Ich habe folgende Dinge gegeben: - eine minimalistische serielle Schnittstelle (+5V,RX,TX,GND), TTL Pegel - 3 Taster (Mirkoschalter) - 2 Temperaturfühler (CPU und Netzteil) - 1 Lichtabhängigen Widerstand (LDR) - 1 12cm Lüfter mit 3-poligem Anschluss - Platz für ein Display (ca. 80x46x15 mm) Was ich gern hätte ist Folgendes (Achtung, möglicherweise Wunschdenken!): Hardware: --------- 1. Einen Mikrocontroller, der das "Frontend" incl. Display und Sensoren verwaltet und Lüfterdrehzahl sowie LCD-Beleuchtung per PWM regelt. Dazu eine passende Platine, wo der Controller und die Anschlüsse ordentlich drauf passen. Das Display sollte am Gehäuserahmen befestigt sein, geht aber auch auf der Platine. 2. Der uC sollte über die RX/TX Leitungen von einem Linux-Programm auslesbar und konfigurierbar sein. Die Steuerung/Regelung sollte möglichst komplett über externe Software gehen, also nicht fest in der Firmware des uC implementiert. 3. Ein Display, was möglichst gut den vorhandenen Platz ausfüllt und dabei auch noch möglichst viel Anzeigefläche hat. Grafisch wäre übertrieben, mir reichen 4x20 Textzeilen. Die Hintergrundbeleuchtung oder Helligkeit sollte von außen regelbar sein (vom uC). Farbe Blau oder weiß, zur Not auch grün. Software: --------- Ich hab ja keine Ahnung ob das so möglich ist, aber meine Vorstellung ist diese: Der uC kennt folgende Sensoren / Werte: - Widerstand von CPU-Sensor 8 Bit / alternativ Temperaturwert in K oder °C - Widerstand von PSU-Sensor 8 Bit / alternativ Temperaturwert in K oder °C - Lüfterdrehzahl (soll) PWM 5 Bit / 32 stufige Regelung reicht dick aus - Lüfterdrehzahl (ist) 13 Bit / alternativ Klartext Zahl - Widerstand Lichtsensor 8 Bit - Helligkeit Display PWM 8 Bit / das muss schon etwas geschmeidig regeln - Taster am Bedienteil mit 3 Bit - 4-20 Zeichen Displaytext 80 Byte Per default (meinetwegen in der Firmware als default-Werte) sind Lüfterdrehzahl und Displayhelligkeit auf je 75% gestellt. Außerdem ist ein Displaytext vorgegeben. Der Rest wird dann beim Start des uC eingelesen. Diese Werte legt der Controller sich irgendwo in den Speicher. Müsste ja kaum mehr als 87 Bytes sein, mit Klartextwerten kaum 100. Auf Anfrage (pre)-Pseudocode vom Linux-Programm: Yo uC, sag mal den Widerstand vom CPU Fühler / Temperatur; Antwort vom uC: (irgendwas zwischen 0 und 255) / 25 (Grad); So könnte das Programm unter Linux meinetwegen 5 Mal in der Sekunde die Werte Abrufen und dann je nach Config sagen: Yo uC, mach mal Lüfter eine Stufe höher; Antwort vom uC: OK Oder der uC sendet paar mal in der Sekunde die Werte rüber und das Prog lauscht und regelt nur nach, wenn was nicht passt. Den Displaytext braucht der uC ja eigentlich nicht wieder zurückschicken, also wären das nur unter 20 Byte pro Mitteilung. Das müsste man dann noch klären, wie das genau laufen soll. ------ dicker Strich drunter ------ Das brauch ich alles. Wenn ich dann sehe was der uC dann sendet und wie das mit der Regelung gehen muss, schreib ich mir das Linux Programm auch selbst. Das wird dann sowieso ein längerer Akt, denke ich mal. Also bitte lest euch das gesamte Vorhaben durch. Wichtig wäre erstmal, wieviel von dem Wunschdenken wirklich möglich ist und wo es eventuell haken könnte. Vor allem brauche ich Hilfe bei der Wahl des richtigen Controllers. Weitere Anschaltungen daran sind eher nicht geplant, außer es gibt noch vernünftige Vorschläge, die mich interessieren könnten. Außerdem bräuchte ich mal eine grobe Abschätzung, wie das finanziell so aussehen könnte. Ich brauche Controller (möglichst incl. Programmierung), Platine (Spezialanfertigung?), Display und Kleinkram wie Stecker und Widerstände usw. Von Späßen à la "3500 Cash und ein Haftungsausschluss und ich bau dir das bis morgen" bitte ich abzusehen. Ansonsten erstmal "Danke" fürs lesen und grübeln. Wer mal Bilder von dem Teil bis jetzt sehen will, der sollte mal einen Blick in das Zenega-Forum werfen: http://forum.zenega-user.de/viewtopic.php?f=34&t=6910&p=48430#p48430 Dort habe ich auch schon nachgefragt, aber das ist dort nicht die richtige Zielgruppe für sowas, denke ich. MfG Ceekay
Machbar. Ich gehe mal von AVR µCs aus: 35€ besserer ISP-Programmieradapter für AVR µC (wiederverwendbar oder später wieder verkaufen) 20€ AVR µC, Bauteile, Lochrasterplatine o.ä. 20€ 4x20 LCD 0€ Literatur AVR-Tutorial (Grundaufbau, UART, LCD, ADC, PWM) ggf. AVR-GCC-Tutorial 0€ Software Windows: AVR-Studio ggf. AVR GCC als WinAVR Linux: AVR GCC, AVRDUDE MacOSX: AVR GCC, AVRDUDE AVR mit 2x PWM und 3x ADC kann man mit einer Suche bei Atmel finden (http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&). Irgendwas in Richtung Atmega8 (passt ideal zum AVR-Tutorial) oder besser würde ich nehmen Wenn du dich ordentlich reinhängst und schon Programmiererfahrung (C optimal) hast, kannst du das ein 1-2 Monaten (1 Woche pro "Kapitel" aus dem Tutorial gerechnet) nebenher/abends schaffen.
Hört sich interessant an. Tips/Vorschläge: Lüfternachregeln bei Abweichung würd ich erst mal lassen, da musst du dich mit Reglern beschäftigen. Da du eh ein Hauptprogramm für den PC schreiben musst, würd ich es so machen, dass du mit dem uC nur deine Sensoren einliest und an den PC per UART schickst. Der PC setzt dann per UART direkt die Register, bspw. für die PWM. Der uC ist also nur dafür da Daten zu sammeln und deine Geräte wie Lüfter/LCD/LCD Beleuchtung anzusteuern. Gerechnet und Schnickschnack macht dann dein PC Programm.
Stefan B. wrote: > Machbar. Ich gehe mal von AVR µCs aus: > > 35€ besserer ISP-Programmieradapter für AVR µC > (wiederverwendbar oder später wieder verkaufen) > 20€ AVR µC, Bauteile, Lochrasterplatine o.ä. > 20€ 4x20 LCD > 0€ Literatur > AVR-Tutorial (Grundaufbau, UART, LCD, ADC, PWM) > ggf. AVR-GCC-Tutorial > 0€ Software > Windows: AVR-Studio ggf. AVR GCC als WinAVR > Linux: AVR GCC, AVRDUDE > MacOSX: AVR GCC, AVRDUDE OK, das ist schonmal erfreulich, wenns so geht und ne finanzielle Hausnummer. Kann man da parallele Displays nehmen oder empfielt sich eins mit seriellem Anschluss? Das LCD kommt ja an den AVR, nicht an die RS232, richtig? Stefan B. wrote: > AVR mit 2x PWM und 3x ADC kann man mit einer Suche bei Atmel finden > (http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&). > Irgendwas in Richtung Atmega8 (passt ideal zum AVR-Tutorial) oder besser > würde ich nehmen Da fängt es schon an, es gibt 4 verschiedene ATmega8 Teile und 7 verschiedene 16er. Woher sehe ich, was da richtig ist, v.a. bezogen auf die LCD Geschichte. Den Rest haben doch alle reichlich (PWM und A/D Wandler), oder seh ich da nicht ganz klar? Stefan B. wrote: > Wenn du dich ordentlich reinhängst und schon Programmiererfahrung (C > optimal) hast, kannst du das ein 1-2 Monaten (1 Woche pro "Kapitel" aus > dem Tutorial gerechnet) nebenher/abends schaffen. Ja, das dachte ich mir fast, dass es nicht "über Nacht" geht. Die Einarbeitung hätte ich mir zwar lieber gespart, aber man weiß ja nie, wofür man diese AVRs nicht alles gebrauchen kann. Scheinbar ist ja (fast) alles möglich. Würde anscheinend auch wenig Sinn machen, wenn ich einen Chip von jemandem aus dem Forum programmieren lasse. Kann ja immer sein, dass noch was zu ändern ist. Oder kann man den Chip mit sowas wie einem Bootloader versehen und dann "on the fly" im Gerät(Serverbox) neu bruzzeln? Felix C. wrote: > Hört sich interessant an. Na das hoffe ich doch, sonst wäre es ja auch doof, wenn es keiner interessant findet und mir helfen will ;) > Tips/Vorschläge: > Lüfternachregeln bei Abweichung würd ich erst mal lassen, da musst du > dich mit Reglern beschäftigen. > Da du eh ein Hauptprogramm für den PC schreiben musst, würd ich es so > machen, dass du mit dem uC nur deine Sensoren einliest und an den PC per > UART schickst. Der PC setzt dann per UART direkt die Register, bspw. für > die PWM. Der uC ist also nur dafür da Daten zu sammeln und deine Geräte > wie Lüfter/LCD/LCD Beleuchtung anzusteuern. Gerechnet und Schnickschnack > macht dann dein PC Programm. Genau so hab ich das vor. Programmierung in Ansi C ist kein Ding; FH Elektrotechnik, 1. Semester - Klausur grad geschrieben ;) Thx erstmal an euch beide! Ich werde wohl noch 1-2 blöde Fragen stellen, bitte verzeiht schonmal :) MfG Ceekay
Christian K. wrote: > Kann man da parallele Displays nehmen oder empfielt sich eins mit > seriellem Anschluss? Das LCD kommt ja an den AVR, nicht an die RS232, > richtig? Richtig. Eine UART am µC benutzt du für die Kommunikation mit dem Server. Da gehört u.U. auch noch ein RS232-to-TLL Pegelwandler ("MAX232") hin. Kommt darauf an, ob der Server eine serielle Schnittstelle mit RS232-Pegeln hat oder auch TTL-Pegel Zur Kommunikation einem seriellen LCD bräuchtest du eine zweite UART (oder I2C oder SPI je nach LCD). Viele µC haben nur eine Hardware-UART, also bei solchen ggf. eine in Software an einem beliebigen I/O-Pin programmieren. Gibt es eine kostenlose Appnote von Atmel zu. Oder einen fetten, teureren µC mit 2 UARTs einsetzen. Zur Kommunikation mit einem parallel angeschlossenen LCD brauchst du eine Handvoll I/O Pins. Die hast du eigentlich noch frei und das ist am Anfang der einfachste Weg. > Da fängt es schon an, es gibt 4 verschiedene ATmega8 Teile und 7 > verschiedene 16er. Woher sehe ich, was da richtig ist, v.a. bezogen auf > die LCD Geschichte. Datenblätter kosten bei Atmel auch nichts ;-) Schau unter den "ordinären", also nicht die besonders stromsparenden oder die für Automotive... Dann schau dir die Bauform an, die du noch verarbeiten willst. Für den Anfang Finger weg von SMD Typen. > Den Rest haben doch alle reichlich (PWM und A/D > Wandler), oder seh ich da nicht ganz klar? Ja, die sind meist ausreichend ausgestattet. Vorauswahl in der Tabelle und dann im Datenblatt lesen, ob es einen Haken (Auflösung PWM ok?, I/O Pins ausreichend?) gibt. > Oder kann man den Chip mit sowas wie einem > Bootloader versehen und dann "on the fly" im Gerät(Serverbox) neu > bruzzeln? Kann man. Bootloader gibt es auch in der Codesammlung freie Exemplare.
Alles klar, fürs Erste :). Ich such mir mal paar Sachen zusammen. Werde das Ganze erstmal theoretisch aufbauen, also virtuell. Kann ja sein, dass ich dann noch paar grobe Schnitzer drin hab. Auf jeden Fall werd ich es hier updaten, wenn ich weiter bin. MfG Ceekay
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.