Hallo liebe µC-Gemeinde! Ich arbeite zur Zeit an einem (für mich) extrem umfangreichen Projekt. Ich möchte mit einem Raspberry Pi sämtliche Elektronik (abgesehen von der eigentlichen PC-Hardware) in einem (noch zu bauenden) PC-Gehäuse steuern. In den vergangenen Monaten habe ich fast ausschließlich Recherchearbeit betrieben und möchte jetzt so langsam mit der Praxis beginnen. Da hier manche Leute, wie ich gesehen habe, extrem allergisch auf Unklarheiten, bestimmte Fragestellungen, Formulierungen uvm. reagieren, möchte ich gleich Folgendes anmerken: - Bitte KONSTRUKTIVE Beiträge/Kritik - Ich bin noch NEU hier, daher bitte nicht gleich hauen - Ich bin mir noch NICHT über alle Punkte des Projekts im Klaren - Ich habe KEIN Elektronik-Studium abgeschlossen - Ich habe NICHT jeden Beitrag des Forum gelesen - Ich lasse mich jederzeit gerne FREUNDLICH eines Besseren belehren Tut mir Leid, dass ich das jetzt so schreiben musste, aber manche Leute hier werden bereits bei den kleinsten Dingen sehr ungemütlich und dem möchte ich vorbeugen. Wir sind doch alle Menschen und machen Fehler. Deswegen lasst uns freundlich bleiben und die Dinge sachlich klären :) Hinweis: Möglicherweise ist dieser Post zu Anfang noch etwas unstrukturiert, da ich in diesem Moment noch nicht genau weiß, was ich alles schreiben werde. Nach und nach wird dieser Beitrag durchstrukturiert mit Kapiteln wie Vorwort, Einleitung, Anforderungen, To-Do-Liste usw. aber erstmal möchte ich das Wesentliche festhalten. So, und nun zum eigentlichen Thema: Ich möchte wie bereits geschrieben alles in meinem Gehäuse digital steuern können. Das fängt bei dem Schalten der Netzspannung an und geht über das Auslesen von Temperaturen, Flussraten und Drehzahlen bis hin zur Steuerung eines komplexen RGB-Beleuchtungssystems basierend auf Messgrößen, Audiosignalen oder bestimmten Vorgaben. Der Mehrwert einiger Vorhaben darf zu Recht bezweifelt werden, aber das ganze Projekt läuft sowieso eher unter dem Motto "Weil's halt geil ist!" ;) Ich bin Student (Biotechnologie) und verfüge daher bei Bedarf über gute Messinstrumente, eine Vielzahl von Bauteilen sowie eine Werkstatt mit CNC-Fräsen und allem was dazu gehört. Preislich sollte einiges drin sein, da ich das Ganze als Studienprojekt angemeldet habe und deswegen ein Teil übernommen wird und ich ein Budget von ca. 2000€ eingeplant habe. Das soll hinterher dabei rauskommen: + Features: - Selbst designtes und gefertigtes PC-Gehäuse - Mastersteuerung durch Raspberry Pi - 7" (10") Touchscreen über HDMI - 4 LCD-Displays mit RGB-Hintergrundbeleuchtung - Einfache Überwachung/Steuerung über grafische Oberfläche - Wasserkühlung mit 2 Kreisläufen und einigen Ventilen - Zwei unabhängige Stromversorgungen - Leichter Austausch von PC-Komponenten auch mit WaKü - Flexibles und unsichtbares Kabelsystem - Umfangreiche und variable Beleuchtung - Kommunikation mit der Außenwelt über individuelles Backpanel - Integrierter Gigabit-Switch + Das Gehäuse: - Vollständger Selbstbau - Maße: ca. 28x70x80 cm (BxTxH) - Material: Aluminium, eloxiert, 2mm stark - Gewicht: hoffentlich nicht über 50 kg - Ansteckbare Rollen für den Transport - Design noch offen - Grundprinzip steht fest: 3 Etagen mit Kabeln und Rohren dazwischen - Motorisierte Elemente (Servo oder Schrittmotor) -> Öffnung/Schließung von Lüftungsklappen im Gehäusedeckel -> Touchscreen ausfahrbar, um Raspberry Pi entnemhen zu können + Das Interface: - Webinterface mit HTML, CSS und Javascript -> Auch Steuerung über (W-)Lan/Internet möglich - Mehrere Menüs: Übersicht, Details, Konfiguration - Aufbereitung und grafische Darstellung von Datenbank-Inhalten + Die Wasserkühlung: - Leistungsfähige Doppelkreislauf-Wasserkühlung - Je Kreislauf ein 480er Radiator (Vier 120mm-Lüfter pro Radiator) - Pumpe PWM-gesteuert (Eheim-Mod von Aqua Computer) - Ventile, um verschiedene Programme fahren zu können: -> Arbeitsbetrieb -> Kühlflüssigkeit ablassen -> Spülgang -> Neubefüllung - Oben zwei Anschlüsse zum Einfüllen - Unten zwei Anschlüsse zum Ablassen - Möglicher Anschluss weiterer (externer) Radiatoren + Beleuchtungssystem: - Pro Lüfter (ca. 16-20 Stück, warum? Darum! :D) vier RGB-LEDs -> ca 64-80 LEDs = bis zu 240 PWM-Kanäle - Mehrere beleuchtete Regionen wie Front, Deckel, Netzteil, Pumpen etc. - Jede LED einzeln ansteuerbar, um grenzenlose Möglichkeiten zu haben - Beleuchtung von vielen Faktoren steuerbar: -> Sensor-Messwerte (Temperaturen, Drehzahlen, Erschütterung...) -> System-LEDs (Mainboard) -> Audiosignale -> Programm-Ereignisse -> Uhrzeit/Datum -> Vordefinierte Szenarien -> Und alles kombiniert! (Yeah, 3 Jahre programmieren! xD) - Über 10 externe High-Power RGB-Ausgänge auch Zimmerbeleuchtung uvm. steuerbar + LCD-Displays: - RGB-Beleuchtung - Ansteuerung über I²C - Darstellung von Messdaten, Ereignissen, Nachrichten, Datum/Uhrzeit... - Im Seitenteil angebracht, vorne wäre ja Schwachsinn ;) + Weitere Ideen (noch nicht fest eingeplant): - RFID - Fingerabdruckscanner - Gehäuseverriegelung - Detektion von Undichtigkeiten, daraufhin Notabschaltung (Tipps dazu?) - Weiterleitung von Ereignissen unter Windows via SSH - Getränkekühler (schonmal gesehen^^) aber wahrscheinlich kein Platz - Verdunklung der Fenster mit elektrischer Verdunklungsfolie Naja, das ist (erstmal) alles, was mir gerade so einfällt. Zu den meisten der Dinge habe ich mich auch schon informiert, aber in der Praxis hakt es dann ja doch wieder an allen Ecken und Enden ;) Auf die eigentlichen elektronischen Hintergründe bin ich bisher noch nicht eingegangen, das weiß ich. Das wird alles in ein eigenes Kapitel kommen, wo ich dann auch ausführlicher als in Stichpunkten drauf eingehen werde und auch noch einige Fragen habe. Diese werden sich dann wahrscheinlich meistens auf Aspekte der konkreten Umsetzung richten. Ich werde auch noch eine Kategorie mit Fragen, Vorschlägen und Ideen erstellen, eine To-Do-Liste und eine mit den erreichten Zielen erstellen und Aktuelles hervorheben. Zuerst hoffe ich jedoch auf ein bisschen Feedback und Fragen eurerseits, bevor ich hier alles mit Fragen vollkleistere ;)
:
Bearbeitet durch User
??? schrieb: > ...und die Frage lautet? Ein Problem, mit dem ich mich schon länger rumschlage, sind die LCDs. Ich steuere mit dem Raspberry Pi über den I²C-Bus ein LCD-Backpack an, das dann wiederum die Pins des Displays ansteuert. Aus irgendeinem Grund wird mir der Inhalt extrem langsam angezeigt. Es funktioniert zwar prinzipiell, aber bis alle vier Zeilen neu geschrieben wurden, vergeht ca. eine halbe Sekunde. Normalerweise sollte das ja in wenigen Sekundenbruchteilen erledigt sein. Die Software ist im Moment in Python geschrieben. Ich verwende folgende Library:
1 | ''' |
2 | Copyright (C) 2012 Matthew Skolaut |
3 | |
4 | Permission is hereby granted, free of charge, to any person obtaining a copy of this software and |
5 | associated documentation files (the "Software"), to deal in the Software without restriction, |
6 | including without limitation the rights to use, copy, modify, merge, publish, distribute, |
7 | sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is |
8 | furnished to do so, subject to the following conditions: |
9 | |
10 | The above copyright notice and this permission notice shall be included in all copies or substantial |
11 | portions of the Software. |
12 | |
13 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT |
14 | LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. |
15 | IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, |
16 | WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE |
17 | SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. |
18 | ''' |
19 | |
20 | import smbus |
21 | from time import * |
22 | |
23 | # General i2c device class so that other devices can be added easily |
24 | class i2c_device: |
25 | def __init__(self, addr, port): |
26 | self.addr = addr |
27 | self.bus = smbus.SMBus(port) |
28 | |
29 | def write(self, byte): |
30 | self.bus.write_byte(self.addr, byte) |
31 | |
32 | def read(self): |
33 | return self.bus.read_byte(self.addr) |
34 | |
35 | def read_nbytes_data(self, data, n): # For sequential reads > 1 byte |
36 | return self.bus.read_i2c_block_data(self.addr, data, n) |
37 | |
38 | |
39 | class lcd: |
40 | #initializes objects and lcd |
41 | ''' |
42 | Reverse Codes: |
43 | 0: lower 4 bits of expander are commands bits |
44 | 1: top 4 bits of expander are commands bits AND P0-4 P1-5 P2-6 |
45 | 2: top 4 bits of expander are commands bits AND P0-6 P1-5 P2-4 |
46 | ''' |
47 | def __init__(self, addr, port, reverse=0): |
48 | self.reverse = reverse |
49 | self.lcd_device = i2c_device(addr, port) |
50 | if self.reverse: |
51 | self.lcd_device.write(0x30) |
52 | self.lcd_strobe() |
53 | sleep(0.0005) |
54 | self.lcd_strobe() |
55 | sleep(0.0005) |
56 | self.lcd_strobe() |
57 | sleep(0.0005) |
58 | self.lcd_device.write(0x20) |
59 | self.lcd_strobe() |
60 | sleep(0.0005) |
61 | else: |
62 | self.lcd_device.write(0x03) |
63 | self.lcd_strobe() |
64 | sleep(0.0005) |
65 | self.lcd_strobe() |
66 | sleep(0.0005) |
67 | self.lcd_strobe() |
68 | sleep(0.0005) |
69 | self.lcd_device.write(0x02) |
70 | self.lcd_strobe() |
71 | sleep(0.0005) |
72 | |
73 | self.lcd_write(0x28) |
74 | self.lcd_write(0x08) |
75 | self.lcd_write(0x01) |
76 | self.lcd_write(0x06) |
77 | self.lcd_write(0x0C) |
78 | self.lcd_write(0x0F) |
79 | |
80 | # clocks EN to latch command |
81 | def lcd_strobe(self): |
82 | if self.reverse == 1: |
83 | self.lcd_device.write((self.lcd_device.read() | 0x04)) |
84 | self.lcd_device.write((self.lcd_device.read() & 0xFB)) |
85 | elif self.reverse == 2: |
86 | self.lcd_device.write((self.lcd_device.read() | 0x01)) |
87 | self.lcd_device.write((self.lcd_device.read() & 0xFE)) |
88 | else: |
89 | self.lcd_device.write((self.lcd_device.read() | 0x10)) |
90 | self.lcd_device.write((self.lcd_device.read() & 0xEF)) |
91 | |
92 | # write a command to lcd |
93 | def lcd_write(self, cmd): |
94 | if self.reverse: |
95 | self.lcd_device.write((cmd >> 4)<<4) |
96 | self.lcd_strobe() |
97 | self.lcd_device.write((cmd & 0x0F)<<4) |
98 | self.lcd_strobe() |
99 | self.lcd_device.write(0x0) |
100 | else: |
101 | self.lcd_device.write((cmd >> 4)) |
102 | self.lcd_strobe() |
103 | self.lcd_device.write((cmd & 0x0F)) |
104 | self.lcd_strobe() |
105 | self.lcd_device.write(0x0) |
106 | |
107 | # write a character to lcd (or character rom) |
108 | def lcd_write_char(self, charvalue): |
109 | if self.reverse == 1: |
110 | self.lcd_device.write((0x01 | (charvalue >> 4)<<4)) |
111 | self.lcd_strobe() |
112 | self.lcd_device.write((0x01 | (charvalue & 0x0F)<<4)) |
113 | self.lcd_strobe() |
114 | self.lcd_device.write(0x0) |
115 | elif self.reverse == 2: |
116 | self.lcd_device.write((0x04 | (charvalue >> 4)<<4)) |
117 | self.lcd_strobe() |
118 | self.lcd_device.write((0x04 | (charvalue & 0x0F)<<4)) |
119 | self.lcd_strobe() |
120 | self.lcd_device.write(0x0) |
121 | else: |
122 | self.lcd_device.write((0x40 | (charvalue >> 4))) |
123 | self.lcd_strobe() |
124 | self.lcd_device.write((0x40 | (charvalue & 0x0F))) |
125 | self.lcd_strobe() |
126 | self.lcd_device.write(0x0) |
127 | |
128 | # put char function |
129 | def lcd_putc(self, char): |
130 | self.lcd_write_char(ord(char)) |
131 | |
132 | # put string function |
133 | def lcd_puts(self, string, line): |
134 | if line == 1: |
135 | self.lcd_write(0x80) |
136 | if line == 2: |
137 | self.lcd_write(0xC0) |
138 | if line == 3: |
139 | self.lcd_write(0x94) |
140 | if line == 4: |
141 | self.lcd_write(0xD4) |
142 | |
143 | for char in string: |
144 | self.lcd_putc(char) |
145 | |
146 | # clear lcd and set to home |
147 | def lcd_clear(self): |
148 | self.lcd_write(0x1) |
149 | self.lcd_write(0x2) |
150 | |
151 | # add custom characters (0 - 7) |
152 | def lcd_load_custon_chars(self, fontdata): |
153 | self.lcd_device.bus.write(0x40); |
154 | for char in fontdata: |
155 | for line in char: |
156 | self.lcd_write_char(line) |
157 | |
158 | class tmp102: |
159 | def __init__(self, addr, port): |
160 | self.sensor = i2c_device(addr, port) |
161 | |
162 | # read a register |
163 | def read_reg(self, reg): |
164 | return self.sensor.read_nbytes_data(reg, 2) |
165 | |
166 | # read the current temp in celsius |
167 | def read_temp(self): |
168 | tempraw = self.read_reg(0) |
169 | return tempraw[0] + (tempraw[1] >> 4) * 0.0625 |
Warum eine Wasserkühlung, wenn du sowieso 16-20 Lüfter verwenden willst? Sie bringt dann nicht mehr den Vorteil eines leisen Betriebs. Kühlungswirkung ist meist schlechter, da sie nur dort kühlt, wo der Kühler montiert ist und nicht auch die Umgebung. Außerdem ist mir noch schleierhaft, wie du alles in ein PC-Gehäuse unterbringen willst. Hast du für die räumliche Aufteilung schon mal Skizzen gemacht?
Ja, da habe ich schon ganz viel rumskizziert ^^ Grundsätzlich sollen es 3 Etagen werden. Oben die Elektronik (15cm Höhe), in der Mitte Mainboard & Co. und unten die beiden Netzteile und die Pumpen. Da die Breite 28cm beträgt, sollte der Platz nicht so das Problem werden. Und die Lüfter... Naja, ist auch irgendwie was optisches :D Aber wie du schon sagtest, kühlt die WaKü nur lokal, da schadet ein bisschen Wind ja nicht :P EDIT: Weitere Frage! Kann man hier irgendwie elegant Spoiler oder Links einfügen? Habe diese Funktionen nicht unter den Formatierungsoptionen gefunden.
:
Bearbeitet durch User
Kom schrieb: > ist doch klar: "Tipps dazu?" :P für was? ;-) Marlon S. schrieb: > Zuerst hoffe ich jedoch auf ein bisschen Feedback und Fragen eurerseits, > bevor ich hier alles mit Fragen vollkleistere ;) was möchtest du gern von uns? Willst du als "toller Hecht" bezeichnet werden, weil du so tolle Sachen machen möchtest? Jetzt mal im Ernst: hier interessiert keinen was du vor hast! Entweder stellst du eine Lösung zu einem Problem vor, oder du stellst eine Frage zu deinem Problem! Gute Nacht!
??? schrieb: > Kom schrieb: > > was möchtest du gern von uns? Willst du als "toller Hecht" bezeichnet > werden, weil du so tolle Sachen machen möchtest? > > Jetzt mal im Ernst: hier interessiert keinen was du vor hast! Entweder > stellst du eine Lösung zu einem Problem vor, oder du stellst eine Frage > zu deinem Problem! Nein, ich wollte eher eine Art Projektseite einrichten, wo ich die ganze Sache nach und nach entstehen lassen kann, wo andere Leute sich Anregungen holen können und alles dokumentiert ist. Aber mir scheint irgendwie, dass µC.net kein geeigneter Ort dafür ist, da die Bearbeitungsmöglichkeiten auf ein Minimum beschränkt sind :/
Marlon S. schrieb: > ...LCD-Backpack... ähmm, was ist das? Marlon S. schrieb: > Normalerweise sollte das ja in wenigen > Sekundenbruchteilen erledigt sein. wer sagt das?
??? schrieb: > Marlon S. schrieb: >> ...LCD-Backpack... > > ähmm, was ist das? Ine kleine Platine, die ein I²C-Signal auf den 16-Pin-Anschluss des LCDs übersetzt. Im Prinzip ein angepasster I/O-Expander. Google liefert nähere Infos. > Marlon S. schrieb: >> Normalerweise sollte das ja in wenigen >> Sekundenbruchteilen erledigt sein. > > wer sagt das? Hast du schon mal ein (brauchbares) Display gesehen, das für den Bildaufbau derart lange braucht? Es ist ja sogar nur ein 4x20 character Display, da sollte das (wie in vielen Videos auf YT auch zu sehen) einigermaßen schnell gehen.
HI >Aber mir scheint >irgendwie, dass µC.net kein geeigneter Ort dafür ist, da die >Bearbeitungsmöglichkeiten auf ein Minimum beschränkt sind :/ >Ich möchte wie bereits geschrieben alles in meinem Gehäuse digital >steuern können. Das fängt bei dem Schalten der Netzspannung an und geht >über das Auslesen von Temperaturen, Flussraten und Drehzahlen bis hin >zur Steuerung eines komplexen RGB-Beleuchtungssystems basierend auf <Messgrößen, Audiosignalen oder bestimmten Vorgaben. Interessiert eigentlich den Gasmann. Es sei denn, du bist in deinen PC verliebt. MfG Spess
Marlon S. schrieb: > Aber mir scheint > irgendwie, dass µC.net kein geeigneter Ort dafür ist, da die > Bearbeitungsmöglichkeiten auf ein Minimum beschränkt sind :/ ...also ich finde hier eine ganze Reihe von Projektseiten, die von vielen Leuten bearbeitet und genutzt werden. Du nicht? Was vermisst du?
??? schrieb: > ...also ich finde hier eine ganze Reihe von Projektseiten, die von > vielen Leuten bearbeitet und genutzt werden. Du nicht? Was vermisst du? Ich vermisse die Funktion, meinen ersten Beitrag zu bearbeiten. Gibt es da einen geheimen Trick für? Ich bekomme nämlich immer eine Meldung, dass ich ihn nicht ändern könne, weil danach neue Beiträge erschienen sind.
Ich hätte dafür keinen PI genommen. Warum? Du brauchst IOs. Viele IOs, so wie ich das sehe. Die hat der PI nicht, d.h. das wird extra Aufwand, und das zeigt, dass der PI nicht die ideale Plattform dafür ist. Ja, er ist billig. Ja, er ist dick in den Medien drin. Aber es gibt anderes, besseres, was nicht so viel Publicity hat. Der PI hat relativ viel Rechenleistung, aber die brauchst Du hier nicht. Was Du eher brauchen könntest, ist Echtzeitfähigkeit. Das heißt, dass der Controller in einer definierten Zeit reagiert, und zwar immer und unter alles Umständen. Beispielsweise Notaus bei Leckagen. Linux ist für Echtzeitgeschichten nicht ideal, man hat ihm zwar einiges beigebracht, aber es wurde nicht dafür entwickelt. Ich hätte mich gegen Linux und für einen kleinen Echtzeitkernel auf einer Mikrocontrollerplattform wie ARM Cortex M3 oder PIC32MX entschieden. Für die effiziente Steuerung von Hardware ist das die bessere Wahl. Das beginnst Du ja auch langsam bei Deinem I2C-Display zu merken. Webserver ... ja, kann man machen. Ist ja auch schick. Ich hätte die Steuerung vielleicht erstmal einfach als USB-HID an den Rechner gehängt. Die ganzen gängigen Mikrocontroller haben ja alle USB eingebaut. Und/oder an den SMBUS auf dem Mainboard, an dem ja auch die ganzen internen Sensoren hängen. Das wäre auch eine nette Sache. Auf Server-Mainboards gibt es IPMI-Module, die darüber den Server überwachen. fchk
Marlon S. schrieb: > Ine kleine Platine, die ein I²C-Signal auf den 16-Pin-Anschluss des LCDs > übersetzt. Im Prinzip ein angepasster I/O-Expander. ahh, dann schreibe es auch so hin! Marlon S. schrieb: > Google liefert nähere Infos. na dann gebe mal das Wort LCD-Rucksack (...natürlich in Engl....) dort ein und wundere dich über die Ergebnisse! Marlon S. schrieb: > Hast du schon mal ein (brauchbares) Display gesehen, das für den > Bildaufbau derart lange braucht? Es ist ja sogar nur ein 4x20 character > Display, da sollte das (wie in vielen Videos auf YT auch zu sehen) > einigermaßen schnell gehen. vielleicht sind ja die Leitungslängen bis zum Rucksack auf dem Rücken zu lang? Jetzt mal im Ernst: keiner kennt die Schaltung/Datenblatt deines "LCD-Rucksacks" etc.! Wie sieht es denn aus, wenn du mal mit generischen Kommandozeilen-Tools (i2cdetect, i2cset, i2cget) die Sache probierst?
Wenn ich das alles über nen internen USB-Port realisieren könnte, wäre das natürlich richtig cool ^^ Nach wie vor würde ich allerdings gern einen Touchscreen einbauen und völlig unabhängig vom Hauptsystem sein. Für die Echtzeitanwendungen hatte ich mir auch schon nen kleinen Arduino oder einfach nur einen PIC gedacht. ICh brauche auf jeden Fall etwas für die LED-Beleuchtung. Bei 30 "Frames" pro Sekunde komme ich auf einen Traffic von 80-100 kbps, wenn cih das richtig berechnet habe.
Marlon S. schrieb: > weil danach neue Beiträge erschienen > sind. dann wird es wohl auch so sein! Spätestens, wenn du eine Antwort auf einen Beitrag bekommen hast, ist selbiger nicht mehr editierbar.
Was hast du denn so elektronikmäßig oder mit Mikrocontrollern schon gemacht?
??? schrieb: > Marlon S. schrieb: >> Ine kleine Platine, die ein I²C-Signal auf den 16-Pin-Anschluss des LCDs >> übersetzt. Im Prinzip ein angepasster I/O-Expander. > > ahh, dann schreibe es auch so hin! > > Marlon S. schrieb: >> Google liefert nähere Infos. > > na dann gebe mal das Wort LCD-Rucksack (...natürlich in Engl....) dort > ein und wundere dich über die Ergebnisse! Okay, das hätte ich jetzt nicht vermutet :D Ich achte beim nächsten mal drauf ;) > vielleicht sind ja die Leitungslängen bis zum Rucksack auf dem Rücken zu > lang? Nein, das sind gerade mal 20-30cm... > Jetzt mal im Ernst: keiner kennt die Schaltung/Datenblatt deines > "LCD-Rucksacks" etc.! Wie sieht es denn aus, wenn du mal mit generischen > Kommandozeilen-Tools (i2cdetect, i2cset, i2cget) die Sache probierst? Ich finde auf die Schnelle grad nicht den Chip, der darin verbaut ist... Per i2cdetect lässt sich das Ding finden und hat auch die eingestellte Adresse. Die Ausgabe funktioniert ja auch,m nur halt viel zu langsam :/
Marlon S. schrieb: > ICh brauche auf jeden Fall etwas für die LED-Beleuchtung. Bei > 30 "Frames" pro Sekunde komme ich auf einen Traffic von 80-100 kbps, > wenn cih das richtig berechnet habe. "Beleuchtung" und "Frames" passen für mich nicht zusammen. Was willst du mit 30 Frames in der Sekunde beleuchten? Achso, bevor ich es vergesse zu fragen: wozu brauchst du 240 PWM-Kanäle?
Eumel schrieb: > Was hast du denn so elektronikmäßig oder mit Mikrocontrollern schon > gemacht? Elektronikmäßig an sich schon relativ viel herumgebastelt. Hab mir mal einen Näherungssensor gebaut. (Okay, das ist nicht relativ viel xD) Mit µCs noch nicht soo viel, aber mit den grundlegenden Prinzipien bin ich vertraut, denke ich. Möchte jetzt aber auch nicht noch monatelang Dinge mit Mikrocontrollern bauen, nur um dann das eigentliche Projekt anzupacken...
:
Bearbeitet durch User
Marlon S. schrieb: > Die Ausgabe funktioniert ja auch,m nur halt viel zu langsam :/ schon mal daran gedacht, dass eine Interpretersprache nicht ganz so schnell ist, wie ein natives Binary? Ohne jetzt das Programm im Detail zu kennen, bist du uns ja auch schuldig geblieben, finde ich eine 1/2 Sekunde für irgendetwas ermitteln und über TWI auszugeben, gar nicht soooo langsam!
??? schrieb: > "Beleuchtung" und "Frames" passen für mich nicht zusammen. Was willst du > mit 30 Frames in der Sekunde beleuchten? > > Achso, bevor ich es vergesse zu fragen: wozu brauchst du 240 PWM-Kanäle? 30 mal pro Sekunde sollen die Farben ALLER LEDs aktualisiert werden und dabei entweder den vorigen Wert oder eben einen neuen erhalten. Dazu schicke ich ein Bitmuster durch viele hintereinander geschaltete WS2811 PWM-Controller, die scheinen mir da die effektivste und günstigste Lösung zu sein. Ich möchte eben 80 (insgesamt eher 100) RGB-Kanäle einzeln ansteuern können, um nette Beleuchtungseffekte zu kreieren. Dass das nicht notwendig ist, weiß ich auch, aber was ist schon notwendig?
Marlon S. schrieb: > Möchte jetzt aber auch nicht noch monatelang > Dinge mit Mikrocontrollern bauen, nur um dann das eigentliche Projekt > anzupacken... Wäre aber wohl das beste um das ganze sinvoll abschätzen zu können bzw. richtig anzugehen. Mit dem RPI hast du ja z.b. schon schön ins Klo gegriffen.
Marlon S. schrieb: > Möchte jetzt aber auch nicht noch monatelang > Dinge mit Mikrocontrollern bauen, nur um dann das eigentliche Projekt > anzupacken... aber genau das solltest du vielleicht doch machen, wenn in einer endlichen Zeit dein "Projekt" vollständig(!) fertig werden soll. Du wirst nicht daran vorbei kommen, ein paar Grundlagen zu Messen, Steuern, Regeln zu kennen (und wie man das mit geeigneter Hardware auch tatsächlich umsetzt). Achso, Raspberry Pi...: mit den Linux-Basics kennst du dich aus?
??? schrieb: > Marlon S. schrieb: >> Die Ausgabe funktioniert ja auch,m nur halt viel zu langsam :/ > > schon mal daran gedacht, dass eine Interpretersprache nicht ganz so > schnell ist, wie ein natives Binary? Ohne jetzt das Programm im Detail > zu kennen, bist du uns ja auch schuldig geblieben, finde ich eine 1/2 > Sekunde für irgendetwas ermitteln und über TWI auszugeben, gar nicht > soooo langsam! Dass Python etwas langsamer ist, weiß ich. Aber wenn man sich überlegt, dass ein String von 80 Zeichen plus ein paar wenige Commands eine halbe Sekunde über einen 2 MHz Bus benötigt, kann doch irgendwas nicht stimmen... Das Display besitzt ja noch einen Controller (HD44780), der die ankommenden Daten auf den Bildschirm ausgibt. Es handelt sich wohlgemerkt um ein 4x20 Zeichen Display!
Marlon S. schrieb: > Dass Python etwas langsamer ist, weiß ich. Aber wenn man sich überlegt, > dass ein String von 80 Zeichen plus ein paar wenige Commands eine halbe > Sekunde über einen 2 MHz Bus benötigt, kann doch irgendwas nicht > stimmen... Der läuft ja nicht die ganze Zeit weil das RPI zwischendrin noch einen ganze Ecke andere Sachen zu tun hat. Und wenn das I2C Interface des RPI dann keinen Sendebuffer hat wirds halt lahm.
Marlon S. schrieb: > 30 mal pro Sekunde sollen die Farben ALLER LEDs aktualisiert werden und > dabei entweder den vorigen Wert oder eben einen neuen erhalten. Dazu > schicke ich ein Bitmuster durch viele hintereinander geschaltete WS2811 > PWM-Controller, die scheinen mir da die effektivste und günstigste > Lösung zu sein. ohoh, du hast wirklich keine Ahnung! Du bringst recht viele Dinge durcheinander! PWM machen deine WS2811 ganz alleine, du musst den Dingern nur sagen, welchen Wert sie "darstellen" sollen... 240 (oder wie viel auch immer, deine Angaben schwanken ja sehr stark!) PWM-Kanäle parallel zu generieren würde schon einiges bedeuten...
Ja, da hast du doch schon den Salat. Wenn man keine Lust hat sich ernsthaft mit der Technik auseinander zu setzen, dann kommen eben genau solche Fragen dabei raus.
??? schrieb: > Marlon S. schrieb: > aber genau das solltest du vielleicht doch machen, wenn in einer > endlichen Zeit dein "Projekt" vollständig(!) fertig werden soll. Du > wirst nicht daran vorbei kommen, ein paar Grundlagen zu Messen, Steuern, > Regeln zu kennen (und wie man das mit geeigneter Hardware auch > tatsächlich umsetzt). Letztendlich muss ja hauptsächlich die Interaktion mit der Hardware glatt laufen. Der Rest ist dann ja eher Softwaresache... Nächstes Semster habe ich Mess- und Regelungstechnik, da ist ja vielleicht auch was dabei ;) > Achso, Raspberry Pi...: mit den Linux-Basics kennst du dich aus? Ich denke schon... Bin definitiv kein Profi, aber das, was ich brauche, klappt.
??? schrieb: > ohoh, du hast wirklich keine Ahnung! Du bringst recht viele Dinge > durcheinander! PWM machen deine WS2811 ganz alleine, du musst den > Dingern nur sagen, welchen Wert sie "darstellen" sollen... 240 (oder wie > viel auch immer, deine Angaben schwanken ja sehr stark!) PWM-Kanäle > parallel zu generieren würde schon einiges bedeuten... Das habe ich gar nicht geschrieben. Welchen Sinn hätten die Controller, wenn ich das PWM-Singal selbst generieren müsste? Multiplexen ist bei so vielen Kanälen auch Schwachsinn. Ich schicke einen Bitstream rein. Der erste WS2811 nimmt sich 24 Bits (8 pro PWM-Kanal) raus und schickt den Rest weiter. Der zweite nimmt sich wieder 24 Bit raus usw. Die Chips setzen dann dem Bitmuster entsprechend ihr PWM-Signal. Und 30 mal pro Sekunde soll ein neues PWM-Signal gesetzt werden können, um eine für das Auge flüssige Animation entstehen zu lassen.
Marlon S. schrieb: > über einen 2 MHz Bus benötigt ...langsam wird es lustig! Du triffst mich gerade auf meiner "Spezialstrecke"! Wo hast du diese 2MHz her? Schon mal die I2C-Spezifikation im allgemeinen und zu deinen (unbekannten) I2C-Expander im speziellen gelesen? ...und ein Interpreter arbeitet wirklich unendlich schnell? Welcher? Würde mich auch interessieren...!
??? schrieb: > Marlon S. schrieb: >> über einen 2 MHz Bus benötigt > > ...langsam wird es lustig! Du triffst mich gerade auf meiner > "Spezialstrecke"! Wo hast du diese 2MHz her? Schon mal die > I2C-Spezifikation im allgemeinen und zu deinen (unbekannten) > I2C-Expander im speziellen gelesen? ...und ein Interpreter arbeitet > wirklich unendlich schnell? Welcher? Würde mich auch interessieren...! Autsch! Da habe ich ganz grob was durcheinander geworfen! 400 kHz sind es im Fast-Mode beim RPI >.< Aber auch bei der Geschwindigkeit sollte das noch kein Problem sein.
Marlon S. schrieb: > Das habe ich gar nicht geschrieben. Welchen Sinn hätten die Controller, > wenn ich das PWM-Singal selbst generieren müsste? Multiplexen ist bei so > vielen Kanälen auch Schwachsinn. Ich schicke einen Bitstream rein. Der > erste WS2811 nimmt sich 24 Bits (8 pro PWM-Kanal) raus und schickt den > Rest weiter. Der zweite nimmt sich wieder 24 Bit raus usw. Die Chips > setzen dann dem Bitmuster entsprechend ihr PWM-Signal. Und 30 mal pro > Sekunde soll ein neues PWM-Signal gesetzt werden können, um eine für das > Auge flüssige Animation entstehen zu lassen. Ist alles richtig so, du brauchst halt noch Hardware die die WS2811 ansteuert.
Marlon S. schrieb: > Das habe ich gar nicht geschrieben. doch, im Eingangspost: Marlon S. schrieb: > + Beleuchtungssystem: > - Pro Lüfter (ca. 16-20 Stück, warum? Darum! :D) vier RGB-LEDs > -> ca 64-80 LEDs = bis zu 240 PWM-Kanäle bringst nun du oder ich Dinge durcheinander?
Marlon S. schrieb: > 400 kHz sind > es im Fast-Mode beim RPI ...und der Chip in deinem LCD-Rucksack kann was? ...und dein LCD ist wie schnell? ... ...achso, ie schnell ermittelst du die anzuzeigenden Daten?
??? schrieb: > Marlon S. schrieb: >> Das habe ich gar nicht geschrieben. > > doch, im Eingangspost: > > Marlon S. schrieb: >> + Beleuchtungssystem: >> - Pro Lüfter (ca. 16-20 Stück, warum? Darum! :D) vier RGB-LEDs >> -> ca 64-80 LEDs = bis zu 240 PWM-Kanäle > > bringst nun du oder ich Dinge durcheinander? Ich hatte nur nicht näher spezifiziert, wie die PWM-Kanläe gesteuert werden. Wie auch im Eingangspost beschrieben, wollte ich auf die konkreten elektronischen Details später eingehen und musste dann feststellen, dass ich den Post nicht mehr edititeren kann :/
...an deiner Stelle würde ich mir, glaube ich, keine Gedanken darüber machen, warum es eine 1/2 Sekunde dauert, 80 Zeichen auf einem LCD anzuzeigen (wie hast du eigentlich die 0.5s ermittelt?). Versuche erst mal diverse Grundlagen zu verstehen, lerne Datenblätter zu lesen. Vielleicht gelingt es dann auch deine Ideen mit den entsprechenden Grundlagen in Zusammenhang zu bringen.
??? schrieb: > Marlon S. schrieb: >> 400 kHz sind >> es im Fast-Mode beim RPI > > ...und der Chip in deinem LCD-Rucksack kann was? > ...und dein LCD ist wie schnell? > ... > ...achso, ie schnell ermittelst du die anzuzeigenden Daten? Daten werden im Moment noch gar nicht ermittelt. Im Test habe ich einen simplen Befehl gegeben, Text auszugeben. Viel mehr kann der Controller ja auch nicht. Im Python-Programm wird der String für jede Zeile mit rjust, ljust und (cjust? gerade vergessen...) auf eine Länge von 20 Zeichen angepasst. Da das Display die Zeilen in der Reihenfolge 1-3-2-4 beschreibt, werden die vier Einzelstrings entsprechend umsortiert und dann char für char über die lcd_putc Funktion (siehe Lib oben) ausgegeben. Bei allen, die ein solches Backpack verwenden, hat es bisher in ausreichender Geschwindigkeit geklappt. Ich möchte später das Display 2 mal pro Sekunde aktualisieren, aber man sollte natürlich nicht sehen können, wie sich das "Bild" Zeile für Zeile aufbaut. Die halbe Sekunde war gefühlt. Kommt auch nicht auf den genauen Zeitwert an.
:
Bearbeitet durch User
Marlon S. schrieb: > Ich möchte später das Display 2 > mal pro Sekunde aktualisieren, ungeachtet der fehlenden Antworten zu meinen Fragen..., so schnell kannst du lesen? 160 Zeichen (in 4 Zeilen) pro Sekunde? Nicht schlecht! Obwohl, da reicht ja glatt die 0.5s Bildaufbau, wo war nochmal das Problem mit dem LCD-Rucksack?
??? schrieb: > Marlon S. schrieb: >> Ich möchte später das Display 2 >> mal pro Sekunde aktualisieren, > > ungeachtet der fehlenden Antworten zu meinen Fragen..., so schnell > kannst du lesen? 160 Zeichen (in 4 Zeilen) pro Sekunde? Nicht schlecht! > > Obwohl, da reicht ja glatt die 0.5s Bildaufbau, wo war nochmal das > Problem mit dem LCD-Rucksack? 1. Es sind 80 Zeichen. Vielleicht solltest du ein bisschen am Kopfrechnen arbeiten, anstatt dich über andere Leute lustig zu machen. EDIT: Okay, Fehler meinerseits. SORRY! Du hast 160 pro Sekunde geschrieben. 2. Musst du jedes Mal den gesamten Inhalt deines Bildschirms neu lesen, wenn er sich aktualisiert? 60 Mal pro Sekunde ne ganze Internetseite durchlesen? Nicht schlecht! 3. Der Bildaufbau sollte normalerweise aber (augenscheinlich!) instant erfolgen. Sonst kann man nämlich tatsächlich kaum noch was lesen. Willst du mir eigentlich helfen, oder bist du nur hier um... Ja, warum eigentlich?
:
Bearbeitet durch User
Marlon S. schrieb: > simplen Befehl gegeben wo und wie? Marlon S. schrieb: > Viel mehr kann der Controller > ja auch nicht. welcher? Ist Biotechnologie auch so eine diffuse Wissenschaft, wie deine Ausdrucksweise?
??? schrieb: > Marlon S. schrieb: >> simplen Befehl gegeben > > wo und wie? > > Marlon S. schrieb: >> Viel mehr kann der Controller >> ja auch nicht. > > welcher? Ich komme vor lauter Schreiben überhaupt nicht dazu, den Controller rauszusuchen... Als ich den ersten Post hier verfasst hatte, war mir noch nicht ganz klar, dass µC eher ein Frage-Antwort-Spiel ist. Das mit dem Display ist mir dann auf die Nachfrage spontan eingefallen, deswegen habe ich es erwähnt. Ich werde jetzt erstmal schlafen gehen, dann morgen in Ruhe alles zu dem Thema raussuchen und das in einer konkreten Frage und besser vorbereitet formulieren. Gute Nacht.
Marlon S. schrieb: > SORRY! Du hast 160 pro Sekunde > geschrieben. aha! Marlon S. schrieb: > 2. Musst du jedes Mal den gesamten Inhalt deines Bildschirms neu lesen, > wenn er sich aktualisiert? 60 Mal pro Sekunde ne ganze Internetseite > durchlesen? Nicht schlecht! ahhh, und warum muss man dann 2 mal in der Sekunde (oder 60 mal...) der Bildschirminhalt aktualisiert werden? Marlon S. schrieb: > 3. Der Bildaufbau sollte normalerweise aber (augenscheinlich!) instant > erfolgen. Sonst kann man nämlich tatsächlich kaum noch was lesen. 1. man schreibt nur dann was aufs Display raus, wenn es auch etwas neu anzuzeigen gibt! 2. man überschreibt (und löscht nicht vorher) das Display. Im Idealfall überschreibt man sogar nur die Stellen, die sich ändern... 3. ...und dann wird es auch augenscheinlich sofort (instant :-)) erfolgen Marlon S. schrieb: > Willst du mir eigentlich helfen, oder bist du nur hier um... Ja, warum > eigentlich? Um dich mit der Nase darauf zu stossen, wo deine Defizite bei dem Projekt sind! Viel Text ist Schall und Rauch, wenn Grundlagen fehlen!
An einen Moderator, der eventuell mal reinschaut: Bitte meinen Beitrag mit dem ewig langen Code (2. Post) editieren und den Code rausnehmen. Wollte damit nicht den halben Thread zuspammen. Danke!
Okay, es hat jetzt doch etwas länger gedauert als eine Nacht, aber vielleicht war das auch ganz gut so... Der Controller ist ein PCF8574, der nach Aussagen einiger Leute ziemlich langsam sein soll. Daher habe ich mir kurzerhand vier MCP23008 bestellt und werde hoffentlich noch diese Woche das Platinenlayout (alle 4 Displays auf eine Platine) ätzen. Da ich auch neue und hochwertig wirkendere Displays verwende (wobei der Hitachi-Controller ja eigentlich der gleiche ist) habe ich ein ganz gutes Gefühl. Habe auch schon ne hübsche C++ Library mit praktischen Scroll-Funktionen und allem, was das Herz begehrt, gefunden. Allerdings habe ich auch gleich schon eine weitere Frage ;) Ich werde einen Haufen Lüfter einbauen und möchte diese alle mit PWM steuern. Meine Wahl fiel dabei auf die Everest-Serie von Enermax, weil ich bereits sehr gute Erfahrungen mit denen gemacht habe bzw. immer noch mache. Sie sind schön leise, haben einen ordentlichen Luftdurchsatz (besonders die 140er) und sind vor allem transparent. Was diese Eigenschaften angeht, habe ich absolut nichts besseres finden können. Einen Nachteil gibt es jedoch: Die Lüfter haben einen 3-poligen Anschluss, also kein (externes) PWM, sondern regeln sich selbst über einen Temperatursensor. An sich ja ne gute Sache, aber ich möchte nunmal alles zentral steuern können. Meine Überlegung war jetzt, den Temperatursensor ganz einfach abzuknipsen und die Kontakte kurzzuschließen bzw. einen geringen Widerstand einzubauen, damit der Lüfter erstmal auf voller Geschwindigkeit läuft. Dann wollte ich in die GND-Leitung nen Transistor reinhängen und mit einem PWM-Signal ansteuern. Jetzt handelt es sich bei dem Everest aber um einen Brushless-Lüfter, den man ja soweit ich weiß nicht so wirklich (auf diese Weise) per PWM steuern kann. Wie könnte ich das realisieren? Hatte schon über ein digitales Potentiometer nachgedacht, aber das scheint mir auch nicht das Wahre zu sein :/
>1. man schreibt nur dann was aufs Display raus, wenn es auch etwas neu >anzuzeigen gibt! > >2. man überschreibt (und löscht nicht vorher) das Display. Im Idealfall >überschreibt man sogar nur die Stellen, die sich ändern... An sich schon, aber wenn man Text scrollen lassen will (vor allem vertikal), muss man zwangsweise das gesamte Display aktualisieren. Ich möchte das Ganze ja etwas flexibler haben. Wird mit der neuen Lib aber wahrscheinlich eh kein Thema mehr sein, hoffe ich. Seit kurzem ist die nämlich auch mit dem MCP23008 kompatibel. Aber das mit der PWM-Steuerung würde mich mal wirklich interessieren, da steh ich ein bisschen auf dem Schlauch. Falls das mit dem Transistor doch gehen sollte, wär das natürlich super, aber nach dem, was ich gelesen hab, funzt das nicht richtig.
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.