photron

Welche Konsole siehst du denn? Das kannst du mittels "tty" Befehl in der jeweiligen Konsole ermitteln. Es gibt tty1 und tty2. Auf tty2 sollte der Desktop starten. Du kannst mit Ctrl+Alt+F2 nach tty2 wechseln. Da sollte entweder der X-Server laufen oder das X-Server Log zu sehen sein. Du kannst dir im Brick Viewer über den Import/Export Tab auch das X-Server Log (Xorg.0.log) ansehen und hier posten, wenn du daraus nicht schlau wirst.

Habe ich das richtig verstanden? Am Anfang funktioniert alles wie es soll: Die 4 Taster funktionieren, das Backlight kann ein- und ausgeschaltet werden und es wird Text angezeigt wie im Brick Viewer eingegeben. Irgendwann funktionieren dann nur noch die Taster, aber das Display selbst nicht mehr. Erst nach einem Reset des Master Bricks funktioniert alles wieder. Nein, das ist kein bekanntes Problem.

Könnte man. Ich setze das mal auf die TODO Liste, was jetzt aber nicht heißt, dass es in der nächsten Brick Viewer Version schon enthalten sein wird

Die Step-Down Power Supply arbeitet als Abwärtswandler (Step Down Converter), daher der Name. Die überflüssige Spannung wird nicht wie bei einem Längsregler (z.B. dem LM7805 Festspannungsregler für 5V) in Abwärme umgesetzt. Daher sollte keine zusätzliche Kühlung nötig sein.

Ich nehme an du hast eine wichtige Zeile im Interrupt Beispiel übersehen: # Enable interrupt on pin 2 of port a io.set_port_interrupt('a', 1 << 2) Standardmäßig sind alle Interrupts aus. Diese Zeile aktiviert den Interrupt Callback für Pin 2 auf Port A. Wenn du das in deinem Programm nicht konfigurierst dann bekommst du auch keine Callbacks. Es funktioniert aber, wenn du im Brick Viewer den IO-16 Tab auswählst, weil dann der Brick Viewer set_port_interrupt() aufruft um selbst den Interrupt Callback zu verwenden. Wenn du den Tab wieder abwählst stellt Brick Viewer den Interrupt Callback wieder aus. Sprich Brick Viewer kommt laufenden Programmen in die Quere, weil er die Callbacks umkonfiguriert. Darüber sind schon einige Leute gestolpert, daher haben wird das für die nächste Brick Viewer Version umgebaut, so dass Brick Viewer dann Callbacks nicht mehr umkonfiguriert.

Die 4 Bit Sequence Number in TCP/IP Paket folgt einfachen Regeln: - Die Anfragen die du sendest dürfen 0 als Sequence Number nicht verwenden, da diese für Callback Antworten vorbehalten ist. - Mit welcher Sequence Number du anfängst spielt im Moment (noch) keine Rolle. Es spielt auch im Moment (noch) keine Rolle in welcher Reihenfolge du die Sequence Numbers verwendest. Am besten folgst du aber dem was die API Bindings tun. Die fangen mit 1 an und erhöhst dann für jede neue Anfrage um +1. Also 1, 2, ..., 14, 15, 1, 2, ... Bei der 8 Bit Sequence Number im Modbus Paket gibt es keine ausgenommenen Werte. Du fängst mit 0 an und erhöhst für jeden neuen Anfrage-Antwort-Zyklus um +1. Also 0, 1, ..., 254, 255, 0, 1, ... Nein, ein Master ACK hat eine "empty message" als Payload: 0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00

Was du auch noch ausprobieren kannst ist den Brick per brick-flash-cmd und --no-restart zu flashen und den Reset danach ohne brick-flash-cmd zu triggern, damit Python, pySerial usw. aus der Gleichung raus sind. Solange der Brick im Bootloader ist kannst du einen Reset auslösen indem du an das /dev/ttyACM0 Device folgenden String sendest: N#W400E1408,A5000A09#W400E1400,A500000D# Wie gesagt mir gehen die Ideen aus. Daher ist das hier auch nur ein weiterer Strohhalm Als Variation kannst du auch testen den Brick direkt zu resetten, ohne ihn zuvor zu flashen.

Da gehen mir langsam die Ideen aus Es funktioniert, wenn brick-flash-cmd am Ende den automatischen Reset weglässt und der Brick dann extern (z.B. durch USB ab- und anstecken) neugestartet wird. Es funktioniert nicht, wenn brick-flash-cmd am Ende den automatischen Reset macht, auch dann nicht wenn davor 5 Sekunden gewartet wird. Der Brick startet zwar neu (das Reset Kommando ist angekommen), aber der PC hat es nicht überlebt. Aber ein Reset aus Brick Viewer heraus funktioniert. Ich denke daher, dass das Problem eher PC seitig als Brick seitig ist. Ich denke es hat auch nichts damit zu tun, wie der Brick an USB angeschlossen ist, oder was sonst noch so an USB hängt. Meine Hoffnung war, dass das ein Timing Problem wäre und ein kurzes Sleep helfen würde. Dem ist wohl nicht so. Ein Unterschied zwischen Brick Viewer Reset und brick-flash-cmd Reset ist folgender: Wenn Brick Viewer den Reset auslöst ist der Brick nicht im Bootloader und die Kommunikation läuft über eine vendorspecific USB Device. Wenn brick-flash-cmd den Reset auslöst ist der Brick im Bootloader und die Kommunikation läuft über ein CDC ACM USB Device. In beiden Fällen führt ein Reset dazu, dass das jeweilige USB Device verschwindet während es gerade für Kommunikation geöffnet ist. Ich könnte da jetzt nach Strohhalmen greifen, einen Kernel Bug herbeireden und behaupten, dass im CDC ACM Fall sich der Kernel beim Verschwinden des USB Devices auf die Nase legt und den Rest des Systems mitnimmt. Von welcher Kernel Version reden wir hier überhaupt? Hast du mal in die Kernel Logs geschaut, ob da irgendwas hierzu drin steht?

ICH? API? Ich frage den Stack per TCP aus der Ferne ab und nutze die API der Bindings nicht. Daher kann ich das so nicht nachstellen. Doch, doch, auch du nutzt die API, wenn auch nicht über Bindings Ich spreche von Function ID 243 im TCP/IP Protokoll. Die API Bindings machen ja nichts weiter als Pakete zu erzeugen und diese zu senden und empfangen. Genau das tust du ja auch, aber von Hand. Sprich auch du kannst den Brick per API mittels Function ID 243 resetten. Die Art und Weise wie im Mikrocontroller des Bricks der Reset ausgelöst wird ist immer gleich, egal ob du im Brick Viewer den Reset Button klickst oder per API Bindings die Reset() Funktion aufrufst oder manuell ein TCP/IP Paket mit Function ID 243 schickst oder brick-flash-cmd nach dem Flashen den Brick per Registerzugriff neustartet. Daher die Hypothese: Wenn ein Reset per Software funktioniert, dann kann der Reset an sich nicht das Problem sein. Heikel ist das falsche Wort, aber bei jedem Hardreset eine PC, und das noch in der Ferne, laueft einem Gaensehaut ueber den Ruecken, zumal es sich in diesem Fall noch um ein Flashmedium handelt. Das System braucht mit zweimaligem Reboot und Filecheck gerne 10 Minuten bis die Pings wieder beantwortet werden. Das ist eine seeeeeeehr lange Zeit wenn man darauf wartet. Das System ist aber nicht lebensnotwendig und so werden wir es mal antesten. Bei solchen Wartezeiten macht das keinen Spaß, das ist verständlich.

Das Script resettet den Brick auf die gleiche Weise wie die Reset() Funktion aller Bricks in den API Bindings. Meine Frage hier wäre: Wenn du den Brick über die API Bindings resettest tritt das Problem dann auch auf? Meine Erwartung ist, dass ein Reset per Software funktioniert und dass das Problem nicht durch den Reset an sich ausgelöst wird. Ich habe dir eine weiter Version angehängt. Diese hat jetzt ein --restart-delay Argument: ./brick-flash-cmd-loetkolben -p /dev/ttyACM0 -f brick_master_firmware_2_3_1.bin --restart-delay 500 Damit wird vor dem Restart 500 Millisekunden gewartet. Meine Erwartung ist, dass das einen Unterschied macht, da ich vermute, dass das Problem durch die engen zeitliche Abfolge der einzelnen Schritte entsteht. Dabei setzte ich voraus, dass nicht schon ein Neustart per API Reset() Funktion das Problem erzeugt Wenn es dir zu heikel ist das zu testen, dann können wir auch hier stoppen und uns mit der Erkenntnis begnügen, dass das Problem ohne Reset am Ende nicht auftritt. Dann würde ich einfach dem Script in der nächsten Version die --no-restart Option mitgeben und der Brick muss dann nach dem Flashen manuelle resettet werden. brick-flash-cmd-loetkolben2

Dass das Verify so viel schneller ist kann normal sein. Die Geschwindigkeit des Flashens variiert hier bei uns auch zwischen verschiedenen Rechner. Es sieht so aus als ob der Write und Verify Schritt durch sind bevor das Problem auftritt. Nach Write und Verify wird noch das Boot Flag Register des Mikrocontrollers von "Boot Loader" auf "Flash" gesetzt. Als Letztes wir der Brick über das Reset Register neugestartet. Ich vermute jetzt mal ins Blaue hinein, dass einer dieser beiden letzten Schritte das Problem verursacht, oder vielleicht auch das Verify. Warum und weshalb das passiert und ob das dann fixbar ist steht auf einem anderen Blatt. Um das Testen zu können habe ich dir eine erweitere Version vom brick-flash-cmd angehängt. Diese Version hat vier weitere Optionen. In diesem Beispiel werden all vier Schritte ausgelassen: ./brick-flash-cmd-loetkolben -p /dev/ttyACM0 -f brick_master_firmware_2_3_1.bin --no-write --no-verify --no-flag --no-restart Damit kannst du jetzt gezielt Schritte auslassen, um so vielleicht herauszufinden wo das Problem steckt. brick-flash-cmd-loetkolben

Derzeit ist da nichts in Planung. Aber mal als Denkanstoß: Wenn schon wechseln, warum dann Micro-USB? Warum dann nicht gleich USB Typ C nehmen?

RED Brick Image 1.6 Add Nagios for Starter Kit: Server Room Monitoring Add openHAB with Tinkerforge bindings Add missing DNS reverse lookup for wireless access point mode Enable kernel drivers for several Bluetooth dongles Set default HDMI fallback resolution to 800x480 Download: RED Brick Image

RED Brick Image 1.6 Nagios für Starterkit: Serverraum-Überwachung hinzugefügt openHAB mit Tinkerforge Bindings hinzugefügt Fehlendes DNS Reverse Lookup for WLAN Access Point Modus hinzugefügt Kernel Treiber für verschiedene Bluetooth Dongles hinzugefügt Standard HDMI Fallback Auflösung auf 800x480 gesetzt Download: RED Brick Image

Brick Viewer 2.2.3 Add server monitoring and openHAB configuration tabs to RED Brick plugin Restore DHCP IP address display for Ethernet Extension in Master Brick plugin Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.2.3 Server Monitoring und openHAB Konfigurations-Tabs zum RED Brick Plugin hinzugefügt DHCP IP Adressanzeige für Ethernet Extension im Master Brick Plugin wiederhergestellt Downloads: Windows, Linux, Mac OS X

Was meinst du mit "das C# Programm wird gestoppt", stürzt es ab? Welche Fehlermeldung bekommst du?

If you installed apscheduler using pip, it'll probably be installed for Python2 only. Try installing it using pip3: sudo pip3 install apscheduler

There is no official documentation about how the generator system works in detail. But you can dive into it and ask questions along the way. You need to clone our generators git from GitHub. It contains the generators for all supported programming languages and the configuration files. In the configs directory there is a config file for each Brick and Bricklet that describes its API. If you want to add a new Bricklet you need to write such a config file. You can look at all the other config files that are already there as examples. Once you have your config file you can run the generators. The C# bindings are the basis for all the .NET based bindings. Go to the csharp directory and run: python generate_csharp_bindings.py You'll need to have Python installed for this. This script will generate a bindings subdirectory containing the generated C# code for the bindings along with a .csproj file. You can now open the .csproj file in Mono Develop (Visual Studio should also work) and compile it.

Yes you can create your own Bricklet. FlyingDoc in the German board is currently developing his own Differential Pressure Bricklet. The Brick/Bricklet system does not work exactly as you described it. Let me just give a brief overview. There are basically three big steps you need to accomplish to create your own Bricklet: 1. Design and build the Bricklet hardware. 2. Write a firmware plugin for the Bricklet. 3. Write a API bindings generator config for the Bricklet. The EEPROM on the Bricklet does not just contain an identifier but a firmware plugin for the Bricklet. This plugin is loaded and executed by the connected Brick. The Brick firmwares and the Brick Daemon doesn't know or care about individual Bricklets and therefore don't need to be modified to support a new Bricklet. All our API bindings are generated, so you don't modify them directly. The API binding generators read a config file per Brick/Bricklet and generate the actual API bindings based on this information.

CIFS: Ich hab's gerade getestet und im Image fehlt das cifs-utils Package dafür: sudo apt-get install cifs-utils Dann funktioniert das hier. "diesen Ordner als ROOT öffnen": Müssen wir mal sehen ob wir das pcmanfm bei bringen können. Ansonsten pcmanfm aus einem Terminal als root starten: sudo pcmanfm Upload Dialog: Der Upload Dialog merkt sich jetzt auch zwischen den Aufrufen den zuletzt verwendeten Ordner. Environment Variable Dropdown: Ich schau mir mal an wie wir das verbessern können.

Okay, you've already check most of the relevant things. There are some things left to do. First, get a debug level log from Brick Daemon: 1. Disconnect the Master Brick from USB. 2. Close Brick Viewer. 3. Start logviewer and switch to Live Debug Log in the View menu. 4. Connect the Master Brick to USB. You should get many debug messages in logviewer now. 5. Save the Live Debug Log output using the Save... item in the File menu. 6. Attach the saved log to your next forum post so I can have a look at it. Second, check to what kind of USB hub/controller the Master Brick is connected: 1. Open the device manager. 2. Switch to Device By Connection mode in the View menu. 3. Expand the tree until you find the Master Brick. 4. What's the name of the parent device of the Master Brick (it should be some kind of USB Root Hub)? A screenshot of the device manager would be nice. 5. Open the properties dialog of that USB Root Hub and go to the Details tab. 6. What are the values for the Device Instance Id, the Hardware Ids, the Service and the Bus Relation fields? Third, if the USB Root Hub or its parent USB Host Controller is a Renesas/NEC USB 3.0 one then check its driver version. If the driver version is older then 2.1.16 then you need to update. See the "Renesas/NEC USB 3.0 controller with old driver" in our FAQ for more details.

Okay, ist jetzt für alle Bricks und Bricklets geändert.

Ändere mal bitte in generate_makefile.bat die cmake Zeile zu cmake -E chdir build/ cmake -G "MinGW Makefiles" -DCMAKE_MAKE_PROGRAM:PATH=make.exe -DCMAKE_TOOLCHAIN_FILE=toolchains/arm-none-eabi.cmake ../ Und führe es erneut aus. Da Problem ist, dass wir cmake vorgeben MinGW Makefiles zu erzeugen. Dafür will cmake aber mingw32-make finden. Nach Anleitung hast du aber nur GCC für ARM, cmake und make installiert, aber kein mingw32-make, was auch nicht notwendig ist. In meinem Test hier funktionierte das gerade, weil ich mingw32-make installiert habe. Damit cmake nicht nach mehr nach mingw32-make sucht gibt die abgeänderte Zeile jetzt mit -DCMAKE_MAKE_PROGRAM:PATH=make.exe vor wo/was (mingw32-)make ist. Damit sollte das jetzt auch bei dir funktionieren. Wenn das bei dir funktioniert, werde ich das für alle Firmwares und Plugins abändern.

Das sieht aus als ob cmake make nicht finden könnte. Komisch, ich kann generate_makefile.bat aber hier erfolgreich ausführen selbst wenn make gar nicht installiert ist. Ist dein cmake richtig installiert? Versuch mal cmake neu zu installieren, oder ein ältere Version wie cmake 2.8 zu installieren. Ich steht da ein bisschen auf dem Schlauch. Edit: Okay, ich konnte den Fehler gerade reproduzieren. Unsere Anleitung passt sozusagen nicht zu generate_makefile.bat. Ein Fix ist in Arbeit.