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
Eine eigene Frage?
Dieser Thread ist über 17 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
