borg

Ich hab ja auch nicht gesagt man sollte dieses LCD benutzen, an der API von dem LCD könnte man sich inspirieren .

Haben wir auch schon drüber nachgedacht, ist halt viel Aufwand dort eine brauchbare API zu machen. Die Daten pixelweise übergeben wäre ja nicht gerade einfach zu benutzen. Dieses Teil hier hat eine tolle API: http://www.reichelt.de/LCD-Module-Touch-Grafik/EA-EDIP-TFT43A/3/index.html?;ACTION=3;LA=2;ARTICLE=86675;GROUPID=3011;artnr=EA+EDIP-TFT43A Sowas müsste man dann selbst bauen. Das wäre dann natürlich ein Brick, ein Bricklet hat da nicht genug Speicher für.

Der Prototyp ist auch gewölbt, sieht man nur auf dem Foto nicht so.

Also 2,4,5,6 und 7 beziehen sich aufs LCD, das könntst du in der Tat gegen ein anderes austauschen. Das LCD muss diesen Treiber besitzen: http://de.wikipedia.org/wiki/HD44780 (oder einen der kompatiblen, letzter Satz im im ersten Absatz). 1) Ich glaube nicht das sich der zusätzliche Preisaufwand da lohnt. Ich wüsste auch gerade gar nicht wo es so ein kleines Poti was da zwischen Bricklet und LCD passt überhaupt gibt. 4) Die Lötpunkte wurden nachgefragt und kosten nichts, deswegen sind sie da . Man könnte da den Stecker von der RS485 Extension einsetzen (passt von der Höhe und hat 6 Pinne), dann kostet das Bricklet aber wieder 1€ mehr, obwohl die allerwenigsten sich externe Knöpfe dran machen. Ist halt immer ein Kompromiss den man da irgendwo fahren muss. @Hingergrundbeleuchtung einbauen: Da müsstest du mal ein LCD auseinander nehmen, vielleicht kann man die LED auslöten und eine andere einlöten. Vorgesehen ist das bei dem LCD aber nicht . Edit: Hab gerade nachgeguckt, die LEDs kann man definitiv nicht auslöten, die sind fest ihm Rahmen integriert.

Bei tk gibt es "after" um Funktionen nach einer bestimmten Zeit aufzurufen, als Alternative zu Callbacks. Also z.B.: class App(): def __init__(self): self.ipcon = IPConnection() self.master = Master(UID, self.ipcon) self.tempbr = Temperature(UID_tempbr, self.ipcon) self.root = tk.Tk() self.label = tk.Label(text="") self.label.pack() self.update() self.root.mainloop() def update(self): t = self.tempbr.get_temperature()/100.0 self.label.configure(str(t)) self.root.after(1000, self.update) app=App() app.mainloop() (ungetestet)

Ui, das klingt vielversprechend! Also unsere 3mm Platten müssten wir auf 80° erhitzen, dann zwei Stunden die Temperatur halten und pro Stunde wieder um maximal 15° abkühlen. Schade das unser kleiner PID geregelter Lötofen nicht groß genug ist für die Acrylplatten. Am besten wir fragen den Hersteller vom Acryl ob die das vielleicht direkt für uns machen können.

Hmpf, die HW-Versions-Erkennung scheint einfach nicht vernünftig zu funktionieren. Ich kann das hier mit den 1.1er LCD Bricklets die ich noch hier hab nicht reproduzieren. Ich splitte die Firmwares am Montag, dann gibt es eine Firmware für <=1.1 und eine Firmware für >=1.2. Ist vermutlich die beste Lösung. Schonmal Entschuldigung für die Probleme!

Das LCD selbst stellen wir ja nicht her. Das sind standard alphanumerische Displays, ein kompatibles gibt es z.B. auch bei Reichelt: http://www.reichelt.de/Hintergrund-blau/LCD-204B-BL/3/index.html?;ACTION=3;LA=2;ARTICLE=53952;GROUPID=3006;artnr=LCD+204B+BL D.h. die Hintergrundfarbe und Schriftfarbe und Buchstabengröße usw suchen wir uns nicht aus, da können wir also auch direkt nichts dran ändern.

Ah, hatte die Debugger-Ausgabe falsch interpretiert. Dann kann es nur sein, dass dein MinGW aus irgendwelchen Gründen __GNUC__ nicht definiert? Kannst du bei den Compiler-Einstellungen ein "-D__GNUC__" mit einfügen zum testen? Der einzige Grund der mir noch einfällt ist nämlich, dass __attribute__((packed)) im EnumerateCallback struct nicht aktiviert ist. Wobei es da eigentlich einen Compiler-Error geben sollte (siehe ip_connection.c Zeile 37ff).

Hast du das Edit oben gelesen? Bitte probier mal einmal aus leconvert_swap32 durch leconvert_swap16 auszutauschen.

Interessant, ab wann hat er denn dann die 0? Hier ist die Funktion die aufgerufen wird: uint16_t leconvert_uint16_from(uint16_t little) { if (native_endian.value == LITTLE_ENDIAN) { return little; } else { return *(uint16_t *)leconvert_swap32(&little); } } Er sollte in den Little-Endian-Fall springen und die 13 direkt wieder zurückgeben. Selbst wenn er in den Else-Fall springen würde, würde nicht 0 dabei rauskommen können . Edit: Uhhhhhh, *Kopfkratz*. Warum steht denn da leconvert_swap32 und nicht leconvert_swap16? Arbeitest du auf einem Big Endian System? Falls ja, tausch mal einmal das leconvert_swap32 durch leconvert_swap16 aus!

Mh, funktioniert bei mir auch. Wenn du da jetzt ein printf("id: %d\n\n", device_identifier); reinpackst gibt das 0 aus?

For small changes i use vim, for bigger changes i use Eclipse with PyDev too . There is a build_pkg.py in the src/ directory. That can be used to build .exe, .dmg and .deb. Especially in the build_windows_pkg you can see all of the dependencies that we put in the windows executable: "includes" : ["sip", "PyQt4.QtCore", "PyQt4.QtGui", "PyQt4.QtOpenGL", "PyQt4.QtSvg", "PyQt4.Qwt5", "OpenGL.GL", "plot_widget", "numpy.core.multiarray", "ctypes.util", "serial", "win32com.client"]

Habs gerade nochmal getestet, bei mir funktionierts: #include <stdio.h> #include "ip_connection.h" #define HOST "localhost" #define PORT 4223 // Print incoming enumeration information void cb_enumerate(const char *uid, const char *connected_uid, char position, uint8_t hardware_version[3], uint8_t firmware_version[3], uint16_t device_identifier, uint8_t enumeration_type, void *user_data) { (void)user_data; printf("UID: %s\n", uid); printf("Enumeration Type: %d\n", enumeration_type); if(enumeration_type == IPCON_ENUMERATION_TYPE_DISCONNECTED) { printf("\n"); return; } printf("Connected UID: %s\n", connected_uid); printf("Position: %c\n", position); printf("Hardware Version: %d.%d.%d\n", hardware_version[0], hardware_version[1], hardware_version[2]); printf("Firmware Version: %d.%d.%d\n", firmware_version[0], firmware_version[1], firmware_version[2]); printf("Device Identifier: %d\n", device_identifier); printf("\n"); } int main() { // Create IP Connection IPConnection ipcon; ipcon_create(&ipcon); if(ipcon_connect(&ipcon, HOST, PORT) < 0) { fprintf(stderr, "Could not connect to brickd\n"); exit(1); } // Register enumeration callback to "cb_enumerate" ipcon_register_callback(&ipcon, IPCON_CALLBACK_ENUMERATE, (void *)cb_enumerate, NULL); // Trigger enumerate ipcon_enumerate(&ipcon); printf("Press key to exit\n"); getchar(); ipcon_destroy(&ipcon); // Calls ipcon_disconnect internally } olaf@pc:~/build20/c$ ./example Press key to exit UID: 6wVE7W Enumeration Type: 0 Connected UID: 0 Position: 0 Hardware Version: 1.1.0 Firmware Version: 2.0.1 Device Identifier: 16 UID: etG Enumeration Type: 0 Connected UID: 6wVE7W Position: a Hardware Version: 1.0.0 Firmware Version: 2.0.1 Device Identifier: 221 Wie sieht cb_enumerate bei dir aus?

Prinzipiell ja. Ich glaube das hat an der Stelle nichts mit Glück zu tun. Ich denke die haben bei der Produktion von ICs eine sehr hohe Reproduziergenauigkeit, wodurch dann die Widerstände an den gleichen Pinnen immer sehr ähnlich sind, solange die Prozessoren aus der gleichen Charge sind.

Alle Pinne des Mikrocontrollers den wir verwenden können Pull-Ups und Pull-Downs anschalten. Wir erkennen ob ein LCD 20x4 HW Version 1.2 angeschlossen ist, in dem wir Pin 4 auf Pull-Down stellen. Bei der 1.2er Version ist der Pin "floating", d.h. wir würden erwarten dort dann ein Low zurücklesen zu können. Soweit zur Theorie. Nun ist es aber so, dass die Pull-Ups/Downs in Mikrocontrollern sehr ungleichmäßig sind, im Datenblatt vom sam3s ist ein Wert von 50-175kΩ angegeben. Nun scheint es gerade so zu sein, dass der Pin der beim Servo Brick an Button 4 angeschlossen ist so hochohmig ist, dass es zulange dauert bis das Signal so niedrig ist, das es als Low interpretiert wird. Dafür setzen wir jetzt einmal für 1000µs (1ms) die Leitung auf Low um sie zu "entladen", dann nochmal für 1ms auf Pull-Down und dann gucken wir ob die Leitung Low oder High ist (also nur 2ms in Summe, keine Sekunde).

Plugins: LCD 20x4 Bricklet 2.0.4 Fix HW version detection if Servo Brick port a is used Download Plugin: LCD 20x4 Bricklet

Plugins: LCD 20x4 Bricklet 2.0.4 Erkennung von HW Version bei Port A von Servo Brick gefixt Download Plugin: LCD 20x4 Bricklet

Das ist ulkig. Das hat nichts mit dem EEPROM zu tun, die Firmware ist bei beiden Ports gleich . Hast du für beide Ports das gleiche Kabel verwendet?

Bei den neueren Raspberry Pis solltest du die Wetterstation über USB versorgen können, die sollten genug Strom liefern.

Servos haben einen zu hohen Anfahrstrom für USB. Braun ist Masse bei dem Servo, also Braun nach unten. Der Brick Viewer fragt die aktuelle Position/Geschwindigkeit in regelmäßigen Abständen ab um sie darzustellen.

Wenn du ein Multimeter hast kannst du auf dem Raspberry Pi zwischen TP1 und TP2 die Spannung messen, dort sollte etwas >4,5V anliegen.

Die Idee hatten wir auch schon, aber da fehlt die Positioniergenauigkeit. Wir können relativ von einem Startpunkt auf wenige µm genau positionieren, aber nicht absolut nachdem wir einmal die Platte gewendet haben. Auch wenn wir nur um 0.5mm daneben liegen, auf so einem 5mm Raster mit 2mm Abstand zwischen den Löchern wäre das viel zu viel.

Der Zwischenstand ist durchwachsen . Wir haben das mit den Puzzleteilen ausprobiert: Allerdings halten die nicht wirklich gut ineinander. Wir haben dann angefangen kleine Verbinder dabei zu machen. Damit ging es dann gut, allerdings brauchten wir dann auch die Puzzlebarkeit nicht mehr wirklich. Also sieht das aktuelle Konzept so aus: Die Einzelplatten haben je 22x10 Löcher. Wir haben die Geschwindigkeit vom Laser Cutter noch ein bisschen tweaken können, das ließe sich so herstellen. Allerdings haben wir noch ein weiteres Problem, die Montageplatten kommen mit Wölbung aus dem Laser Cutter: Da konnten wir bisher noch keine Lösung für finden. Wir haben schon angefangen die Löcher nicht direkt nacheinander sondern mit größerem Abstand zu machen (also z.B. erst ein Loch auf der linken Seite, dann auf der rechten Seite usw). Damit dürfte es weniger Hitzeentwicklung an einer Stelle geben. Allerdings bringt das rein gar nichts. Interessant ist auch, wenn wir das Acryl im Nachhinein nochmal erwärmen und gerade ziehen verformt es sich beim abkühlen wieder in die gewölbte Form. Wir scheinen also durch das durchlöchern irgendwelche Spannungen oder so im Acryl zu erzeugen . Ich befürchte wir müssen uns für die Montageplatten erst noch ein anderes Plastik besorgen.

Das "$ipcon->dispatchCallbacks(-1);" ist im wesentlichen eine Endlosschleife. Die ganzen kleinen Minibeispiele sind dafür da um direkt über PHP aufgerufen zu werden, das Programm kann dann mit "strg+c" beendet werden. Wenn du über Apache ein Skript ausführen möchtest muss das "$ipcon->dispatchCallbacks(-1);" weg, da ist es ja so das ein PHP Script sozusagen immer einer Webanfrage entspricht. Da darf dann ans ende keine Endlosschleife.