Jump to content

OutdoorRob

Members
  • Posts

    7
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

OutdoorRob's Achievements

Rookie

Rookie (2/14)

  • Reacting Well Rare
  • First Post
  • Conversation Starter
  • One Month Later
  • Week One Done

Recent Badges

0

Reputation

  1. Eine übergeordnete Windows-Anwendung auf verteilten Rechnern. Das spielt aber aus meiner Sicht keine Rolle für meine Frage bzw. Zielstellung ;-) Ziel: Jedes Gerät soll sich vollständig selbst / autark identifizieren können (sprich: alle seine Meta-Daten dem Fragenden bereitstellen ohne eine zentrale Datenbank wo diese verwaltet werden). Frage: Gibt es eine Möglichkeit spezifische Meta-Daten innerhalb des Bricks / Bricklets abzulegen (Custom Bereich in EEPROM / Flash)? Grüße, Robert
  2. Moinsen Chris, danke für deine Antwort :-) Ich versuch unser System mal an einem Beispiel zu erläutern. physisches Gerät 1 - "Typ 1" - Seriennummer: 1 - Master (UID = abcdef) - IO-4 (UID = aaa1) physisches Gerät 2 - "Typ 1" - Seriennummer: 2 - Master (UID = cccccc) - IO-4 (UID = aaa1) physisches Gerät 3 - "Typ 2" - Seriennummer 1 - Master (UID = xyz123) - IO-4 (UID = aaa1) - IO-16 (UID = aab1) - IO-16 (UID = aab2) Das physische Gerät 1 und 2 sind identische Typen und diese können 1:1 gegeneinander getauscht werden. Sie werden vom übergeordneten System gleich behandelt aber es werden bei Verwendung entsprechende Meta-Informationen (wie z.B. die S/N, HW-Version, ...) mit protokolliert um. Der Bediener kann quasi Gerät 1 oder 2 verwenden aber im Nachgang ist eindeutig nachvollziehbar welches Gerät zum Einsatz kam. Zwei identische Geräte dürfen dann logischerweise nicht gleichzeitig an einem "Arbeitsplatz" im Einsatz sein. Eine separate Datenbank zur Sammlung dieser Informationen ist nicht unsere bevorzugte Variante (zu pflegeintensiv, Synchronisation...). Ziel ist es, dass sich jedes Gerät selbst vollständig identifizieren kann. Deswegen war die Frage, ob der Brick (oder ein Bricklet) die Möglichkeit bietet solche Meta-Informationen irgendwo zu speichern. Zwei API-Funktionen zum Schreiben und Lesen des Custom-Speicherbereichs wären dann ausreichend. Falls es dies nicht gibt, wäre ggf. ein XMC1400 Breakout Bricklet mit eigener Firmware ein möglicher Ausgangspunkt - leider mit viel Entwicklungsaufwand - welcher als reiner Speicher dient. Grüße, Robert
  3. Hallo in die Runde, ich bin leider bei der API des Master-Bricks und hier im Forum leider nicht fündig geworden und vermute, dass es dafür auch nichts passendes gibt - versuche es aber hier trotzdem nochmal: Gibt es eine Möglichkeit Custom / User / Meta Daten irgendwo in den Bricks (notfalls Bricklets oder separates EEPROM-Bricklet) zu speichern? Ich benötige nicht viel Speicher (ein Block von 128 Byte würde ausreichen). Es geht nur darum, zur Unterscheidung gleichartiger Geräte (bestehend aus verschiedenen Bricks und Bricklets), diese mit Meta Daten (z.B. Gerätenummer, Seriennummer, HW-Version, ...) zu versehen um sie in meiner Infrastruktur identifizieren zu können. Als Dirty-Workaround geht vllt. auch der 'Missbrauch' zur Verfügung stehender API-Funktionen (wie z.B. SetWifiConfiguration) und der entsprechenden Werte (z.B. SSID, Key). Hier fehlt mir jedoch leider der tiefere Einblick ob das funktioniert. Dazu wären meine Fragen: Sind diese Funktionen am Brick verfügbar auch wenn real keine entsprechende Extension verbunden ist? Danke euch und viele Grüße, Robert
  4. Hallo Matze, danke für fixe Antwort. Alles schick mit der API - hinterher ist man immer schlauer und irgendwann kommt der Zeitpunkt für eine Version 2.0 wo man all seine Erfahrungen dann einfließen lassen kann ☺️ Für meine Zwecke habe ich bereits einige Gemeinsamkeiten gefunden die ich nutzen kann. Es ist ja eh immer so eine Sache wie sehr eine Vereinheitlichung möglich und sinnvoll ist. Die Bricklets bieten nun mal unterschiedliche Funktionalitäten und es kommen immer neue Dinge hinzu an die man vorher nie gedacht hat - also wird es wohl nie die einheitliche API geben. Auch Software lebt :D Ich werde meine Tabelle einfach hier weiter posten und gern als Excel zur Verfügung stellen wenn Bedarf besteht (oder ihr habt eine Art öffentliches Wiki wo man sowas eintragen kann!?) Danke auf jeden Fall für euer geniales Projekt und vor allem den Open Source Ansatz. - ganz getreu dem Motto Kooperation statt Konkurrenz. Ich hoffe, dass in Zukunft viele Menschen und Unternehmen lernen, dass dies für alle zum Vorteil ist und ein effektiveres und gesünderes Wachstum ermöglicht. In diesem Sinne, noch ein paar ruhige Tage euch allen 🙏
  5. Hallo zusammen, gibt es eine Art Referenz Tabelle (Übersicht) in der ersichtlich ist, welche API Funktionen mit welchen Parametern für welche Bricklets zur Verfügung stehen? Mir ist bewusst, dass diese für die entsprechenden Plugins entsprechend wohl dokumentiert sind. Da ich jedoch jetzt allgemeine Funktionen schreiben möchte, die möglichst unabhängig vom verwendeten Bricklet sind, wäre es gut für ein entsprechendes Konzept den Überblick zu haben, wie sich die Bricklets seitens der API Funktionen unterscheiden. Also in etwa eine solche Übersicht: Falls nicht, werde ich wohl in Zukunft Updates an meiner Tabelle hier posten :-) Oder das Ergebnis ist, dass die Unterschiede viel zu groß sind um irgendwelche nützlichen Gemeinsamkeiten zu finden. Ich werde berichten. Liebe Grüße und ein schönes Weihnachtsfest allen, Robert TinkerForge_C#-API-Function-Reference.pdf TinkerForge_C#-API-Function-Reference.xlsx
  6. Hallo Photron, vielen herzlichen Dank für die aufklärende und schnelle Antwort inkl. der Links! Ein echt klasse Support hier ☺️ Master Brick 3.2 & WSL vorhanden. Solide Anleitung - das klingt gut machbar. Und praktisch, dass man in einem Schritt Bootloader + Firmware flashen kann :) Wenn ihr hier nichts mehr von mir lest, dann hat alles geklappt (Kann aber noch eine Weile dauern - Projekt läuft gerade erst an.) Falls ich als Außenstehender bei dem Prozess auf Probleme stoße werde ich diese dann hier dokumentieren 👍
  7. Hallo Community Für ein Projekt möchte ich mehrere Bricklets auf einer gemeinsamen (selbst gerouteten) Platine vereinen, um einen für mein Gehäuse optimalen Aufbau zu erreichen. Es soll sich dabei um einen 1:1 Nachbau der Bricklets (Hardware + Firmware) handeln - nur eben kombiniert auf einer PCB. Ich habe mich durch die Doku gelesen und hier im Forum gesucht, jedoch leider noch nicht alle Antworten auf meine Fragen gefunden. Hier eine Zusammenfassung meines bisherigen Kenntnisstandes (sofern ich alles richtig verstanden habe, ansonsten bitte berichtigen :-) auf den neuen Bricklets befindet sich ein XMC1100 µC auf diesem µC läuft ein Bootloader und eine Firmware das Update der Firmware erfolgt normalerweise über den BrickViewer Für meinen Fall habe ich folgende Fragen: Mein Nachbau besitzt einen 'leeren' XMC1100. Wie wird der initiale Bootloader auf den µC programmiert? Gibt es die originalen Bootloader / Firmware-Dateien auch als .bin irgendwo zum Download? (Da ich die Firmware 1:1 verwenden möchte, bräuchte ich so nicht er die Build-Umgebung aufsetzen.) Danke schon mal vorab für alle Antworten auf meine (Anfänger-)Fragen Viele Grüße und einen tollen Start ins Wochenende, Robert
×
×
  • Create New...