Jump to content

Tinkee24-7

Members
  • Gesamte Inhalte

    9
  • Benutzer seit

  • Letzter Besuch

Tinkee24-7's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. Hallo miteinander, mich hat das Thema einfach nicht losgelassen, vor allem nicht der Wunsch nach einer betriebssystemunabhängigen Lösung... Der PHY der Ethernet-Extension bringt dazu an für sich alles Nötige mit: er besitzt u.a. ein Status-Register, aus welchem via SPI der aktuelle Link-Zustand ausgelesen werden kann. Also habe ich mich etwas eingehender mit der Master-Brick Firmware beschäftigt und basierend auf V2.4.1 um eine Funktion erweitert. Zum Test habe ich die C-API (bislang nur manuell...) um eine entsprechende Funktion int master_is_ethernet_link_up(Master *master, bool *ret_link_up); erweitert. ret_link_up wird 'true', wenn ein Ethernet Link aktiv ist. Das ganze habe ich mit einem kleinen Programm getestet - funktioniert prima! Auf meiner Ethernet-Extension ist ein W5500 PHY, mein Quellcode bedient aber auch den W5200. Hat denn jemand eine Extension mit W5200 und mag einfach mal testen? Im Anhang sind die entsprechende Master-Brick Binärdatei sowie die C API-Dateien und das Testprogramm (geschrieben in C, Dev-C++ Projekt). Wenn ihr in den API-Dateien sehen wollt, was ich ergänzt habe, sucht einfach nach dem Schlüsselwort "PHY-MOD". Falls mir jemand zum Test mit einem W5200 Rückmeldung geben könnte, würde ich mich freuen. Der komplette Quellcode wird nach dem Testen natürlich noch veröffentlicht - vielleicht kann die Funktion ja sonst noch jemand gebrauchen Viele Grüße, Tinkee24-7 link_detect_api+firmware.zip phy_link_testprog.zip
  2. Hallo photron, super, besten Dank für die Tipps - wieder was dazugelernt! Guten Start ins Wochenende und viele Grüße, Tinkee24-7
  3. Hallo photron, gar kein Problem... Vielen Dank für den von dir geposteten Link zu der Anleitung. Diese kenne ich auch - bin aber eben eher in Windows zu Hause und wollte es deswegen erst mal auf dem Windows-Weg probieren Nun habe ich mich als völliger Linux-Newbee mal daran gewagt - hab's nun auch zum Laufen bekommen, hatte auch noch etwas Support von einem netten Kollegen! :D Da ich mich einfach noch nicht so richtig in der Linux-Welt auskenne, noch ein paar Fragen mit Blick auf die Anleitung: Beim Setzen des Symlinks per ln -s ../../../bricklib/ . kam eine Fehlermeldung: "File exists". Habe dann im "Explorer" gesehen, dass diese Verknüpfung im entsprechenden Pfad nach dem Klonen der Git-Repos schon da war. Im zweiten Anlauf habe ich diese Zeile dann einfach weggelassen - hat am Ende offenbar auch alles funktioniert - oder hat der Befehl sonst noch irgendwelche Konsequenzen (sollte z.B. die Verknüpfung aus dem Git-Repo gelöscht und durch diesen Befehl ein neuer Symlink erzeugt werden)? Ein erneutes Compilieren funktioniert bei mir nur, wenn ich den zuvor automatisch generierten Ordner "build" (samt Inhalt) lösche, dann "generate_makefile" ausführe und dann zuletzt "make" aufrufe. Starte ich nach einem ersten, erfolgreichen Build-Vorgang einen weiteren über "make", dann erscheint direkt die Meldung "[100%] Built target master-brick.elf". Wenn ich dann ins "build" Verzeichnis schaue, dann liegt dort noch die .bin-Datei aus der Zeit des ersten Build-Vorgangs. Löschen des "build" Ordners und alles von vorne funktioniert wie gesagt - aber ist das tatsächlich richtig so? Herzlichen Dank nochmal für die schnelle Rückmeldung und viele Grüße, Tinkee24-7
  4. Hallo zusammen, ich habe unter Windows 7 eine Build-Umgebung aufgesetzt, um selbst Brick Firmware ändern und kompilieren zu können. Dazu habe ich mich an diese Anleitungen gehalten: http://www.tinkerforge.com/de/doc/Software/FirmwaresAndPlugins_BuildingBrickFirmware.html http://www.tinkerforge.com/de/doc/Software/Firmwares_And_Plugins.html#firmwares-and-plugins-install Ich habe Sourcery CodeBench Lite 2013.11-24, CMake 3.61 und Make 3.8.1 installiert - die Versionsabfragen auf Kommandozeilenebene funktionieren alle (Path-Variable ist entsprechend gesetzt), demnach sollten die Tools alle einsatzbereit sein. Entsprechend der o.a. Anleitung zum Compilieren einer Brick-Firmware starte ich dann das Skript "generate_makefile.bat" - auch das funktioniert noch, der "build" Ordner wird entsprechend angelegt. Mit c:\mulc\tf\master-brick\software\build make starte ich dann den Compilier-Vorgang - das funktioniert auch soweit, bis am Ende dann eine Fehlermeldung kommt, auf die auch bereits in der Tinkerforge-Anleitung verwiesen wird: process_begin: CreateProcess(NULL, S -O binary master-brick.elf master-brick.bin, ...) failed. make (e=2): Das System kann die angegebene Datei nicht finden. Entsprechend den Empfehlungen bzgl. dieser Fehlermeldung führe ich "generate_makefile.bat" nochmals aus und starte danach erneut c:\mulc\tf\master-brick\software\build make Laut Anleitung sollte der Compilier-Vorgang nun durchlaufen und eine .bin-Datei im Ordner "build" erzeugen. Das tut bei mir leider nicht, nach dem erneuten make-Aufruf kommt bei mir die Fehlermeldung: ARM-NO~3.EXE: error: nosys.specs: No such file or directory make[2]: *** [CMakeFiles/master-brick.elf.dir/src/communication.obj] Fehler 1 make[1]: *** [CMakeFiles/master-brick.elf.dir/all] Fehler 2 make: *** [all] Fehler 2 Auffallend ist, dass zuvor nur beim 2. Aufruf von "generate_makefile.bat" eine CMake Warning kommt: Manually specified variables were not used by the project: CMAKE_TOOLCHAIN_FILE Beim 1. Aufruf der Batch-Datei kommt diese Warnung nicht. Letztendlich liegt im "build" Ordner dann nur die compilierte .elf-Datei, die .bin-Datei wird aufgrund des Fehlers nicht erzeugt. Könnt ihr mir bitte einen Tipp geben, wo hier der Haken ist? (Der Quellcode ist übrigens von Stand heute, frisch aus den Git-Repos als zip-Dateien geladen...) Besten Dank vorab und viele Grüße, Tinkee24-7
  5. Hallo jgmischke, das hast du richtig verstanden - im Falle einer gekappten Verbindung soll letztendlich eine C-Funktion aufgerufen werden, in der ich später dann eine entsprechende Ereignisbehandlung (und nicht nur eine Testausgabe) implementieren kann. Im Prinzip habe ich es ganz ähnlich gemacht, wie du es vorgeschlagen hast, mit system("ping -c 1 -w 1 192.168.178.1"); Hmm, möglicherweise war vielleicht auch noch die Verbindung zum Brick Viewer (per USB) aktiv. Das werde ich am Freitag nochmal nachvollziehen, komme vorher leider nicht dazu. Soweit aber mal vielen Dank & schöne Grüße, Tinkee24-7
  6. Hallo miteinander, zuerst mal besten Dank für eure Antworten! @jgmischke: Zeitkritisch ist das bei mir tatsächlich nicht, das wäre also kein Problem. Dein Ansatz hat sich für meinen Anwendungsfall interessant angehört, deswegen habe ich mich gleich mal eingehender damit beschäftigt. Ergänzend muss ich noch sagen, dass ich auf meinem PC mit Windows 7 arbeite. Das führt zu ein paar nicht ganz schönen Nebeneffekten, da z.B. die Argumente beim Aufruf von 'Ping' bei Windows und Linux eine teils unterschiedliche Syntax haben (Beispiel Windows: -n --> Linux: -c). Ist, wie gesagt, aber kein unlösbares Problem... Beim Ausführen des 'Ping' wird aber offenbar immer nur auf die Netzwerkverbindung meines PC's zugegriffen - selbst dann, wenn ich mein Testprogramm auf einem RED-Brick compiliere und ausführe (an dem dann ein Master-Brick mit der betreffenden Ethernet-Extension hängt). Wenn ich bei diesem Hardware-Setup mein Netzwerk-Kabel an der Ethernet-Extension anstecke oder abziehe passiert gar nichts. Erst wenn ich meine LAN-Verbindung am PC deaktiviere, bekomme ich eine Änderung über mein Programm im RED-Brick angezeigt (-> 'Ping' zur IP des angeschlossenen Routers). Da beiße ich mir gerade noch die Zähne aus. Hast du evtl. noch einen Tipp, auf was ich da achten muss? ethtool habe ich mir ebenfalls angeschaut - liefert auch die interessante Info zum Link-Status. Allerdings möchte ich den Einsatz von ethtool ehrlichgesagt vermeiden, da ich an für sich eine plattformunabhängige Lösung suche (soll auf Windows und Linux lauffähig sein). Daher wäre meine "Wunschvorstellung" irgendeine API-Funktion, die auf die Tinkerforge Hardware zurückgreift (träumen darf man ja ...) @Nic: Der Ansatz in deiner Antwort ist auch interessant - sozusagen Retriggern eines Monoflops über so etwas wie ein "Heartbeat"-Signal via LAN. Nur leider liegt da das Problem: In meinem Anwendungsfall habe ich keine Steuersignale o.ä. die von der Außenwelt per Ethernet an mein Gerät gehen. Der LAN-Anschluss wird nur unidirektional von meinem Gerät zur Kommunikation in die Außenwelt genutzt (-> Mailversand). Damit scheint diese Lösung für meine Anwendung leider nicht praktikabel zu sein...
  7. Hallo allerseits, ich nutze in einer Anwendung (in C programmiert) einen Master-Brick zusammen mit einer Ethernet-Extension (V1.0 Standard, kein PoE). Der Ablauf meines "Hautprogramms" wird im Wesentlichen durch die Zustände einiger Pins an einem IO-16 Bricklet gesteuert, die Anbindung meines Tinkerforge-Systems ans Netzwerk benutze ich nur sporadisch, um Statusmitteilungen (E-Mails) zu versenden. Nun würde ich gerne per Software überwachen, ob mein Master-Brick via Ethernet-Extension eine aktive Verbindung zum Router hat bzw. ob diese Verbindung unterbrochen wurde (z.B. Kabel ausgesteckt) - helfen würde mir im Prinzip eine Funktion, die mir quasi den aktuellen Status der Link-LED der Ethernet-Extension zurückgibt. Leider habe ich bislang noch keinen richtigen Weg und auch keinen sinnvollen Workaround gefunden (bitte korrigiert mich gerne, falls ich im Eifer des Gefechts was übersehen habe): keine Callbacks verfügbar, die z.B. auf einen aktiven (bzw. inaktiven) Link zum Router reagieren keine direkte Funktion zum Abfragen des Link-Status verfügbar Daraufhin habe ich die Funktion 'master_get_ethernet_status()' getestet. Das funktioniert für meinen Fall jedoch nur soweit, dass ich nach einem Power-On und anschließendem Anstecken des Netzwerk-Kabels z.B. eine Änderung der IP-Adresse registrieren kann. Ziehe ich das Netzwerk-Kabel dann wieder ab, bleiben alle Daten auch bei weiterem, zyklischen Aufrufen (alle 500ms) von 'master_get_ethernet_status()' bis zu einem Power-On Reset konstant - TX_count und RX_count sind übrigens immer auf 0. Eine Trennung der Verbindung zum Router bekomme ich so also leider nicht mit... Ich würde mich freuen, wenn mir da jemand mit einem Rat zur Seite stehen könnte
  8. Ich bin genau nach dieser Anleitung vorgegangen - und was soll ich sagen: damit hat es auf Anhieb super funktioniert! Das Starten der Python Skripte aus meinem C Code heraus läuft nun auch auf dem RED-Brick einwandfrei! Ein ganz herzliches Dankeschön für die schnelle und kompetente Hilfe!!
  9. Hallo liebe Community, ich bin noch ein ziemlicher Tinkerforge-Neuling - aber schon jetzt total begeistert, wie schnell man damit Dinge zum Laufen bekommt Leider komme ich aktuell bei einer Sache nicht wirklich weiter und bin dazu auch im Web nicht fündig geworden: Mein Tinkerforge-System besteht aus 1x IO-4 Bricklet, 1x IO-16 Bricklet, 1x Master Brick und 1x RED-Brick. Dazu habe ich eine Anwendung in C geschrieben, die aus mehreren .c und .h Dateien besteht. Diese kann ich über den Brick Viewer auf den RED-Brick laden und dort mittels GCC compilieren, das entsprechende Makefile ist im Anhang. Soweit funktioniert das alles auch bestens, das Programm läuft, wie es soll... Nun möchte ich gerne ein Python Script (aus einer eigenen Datei heraus, z.B. "test.py") aus meinem C-Programm heraus starten können. Das gelingt mir in meiner Windows-Umgebung auch, hier nutze ich Python 3.5 und Dev-C++ mit GCC. In den Projekt-Optionen teile ich dem Linker u.a. über die Optionen -I<Pfad_zu"/include"> bzw. -L<Pfad_zu"/libs"> -lpython35 mit, wo er die entsprechenden Python Incudes bzw. Bibliotheken findet. In meinem C-Programm binde ich die Datei "<Python.h>" ein, alles compiliert sauber und auch die Ausführung der Datei "test.py" aus meinem C-Programm heraus funktioniert - bislang allerdings eben nur unter Windows. Ich scheitere derzeit noch daran, das angehängte Makefile so zu ergänzen, dass dem GCC Compiler auf dem RED-Brick bekannt gemacht wird, wo er dort die entsprechenden Python Includes bzw. Libraries findet. Mit einem "C:\...\..." hinter den Optionen -I bzw. -L ist das beim RED-Brick ja nicht getan Würde mich freuen, wenn mir da jemand einen heißen Tipp geben kann - vielen Dank vorab! Makefile
×
×
  • Neu erstellen...