Aiken Geschrieben June 17, 2013 at 21:23 Geschrieben June 17, 2013 at 21:23 Hallo allerseits, ich habe mein Projekt fertiggestellt, aber es erscheint mir, als wäre es nicht möglich, es ohne USB-Verbindung und BrickViewer zu verwenden. Ich verwende VB.NET im Visual Studio und "teste" die Software üblicherweise durch einen Klick auf den Compilier-Knopf. Das funktioniert ausgezeichnet, alles läuft wie es soll. Sobald ich aber das USB-Kabel vom Master Brick trenne und das Projekt über den Step-Down-Power-Supply laufen lassen will, leuchtet nur der Master Brick kurz auf, es tut sich aber sonst nichts. Ich vermute, die Software die ich geschrieben habe bleibt nicht auf dem Master Brick sobald ich ihn vom USB abschließe. Kennt jemand eine Lösung? Zitieren
Monti Geschrieben June 18, 2013 at 05:30 Geschrieben June 18, 2013 at 05:30 Das hast du richtig erkannt. Damit dein Projekt läuft, brauchst du den Brickd, nicht den Brickv. Wenn dein Projekt getrennt vom PC aufen soll, hast du 2 möglichkeiten: -embedded Board, z.B. Raspberry Pi -Master Brick Firmware verändern Ich habe mich für 1. entschieden und bin zufrieden Zitieren
Nic Geschrieben June 18, 2013 at 09:05 Geschrieben June 18, 2013 at 09:05 Fairweise sollte man auch noch daraufhinweisen, dass * auf dem RaspberryPI als Betriebssystem nur Linux läuft * die VB.Net Anwendung aber unter einem Windos-Rechner und VisualStudio erstellt wurde, die EXE ist so auf dem Linux erstmal nicht lauffähig (irgendwelche VMs oder WinEmu lassen wir mal weg) * es sei man benutzt den Mono-Framework für Linux: https://www.microsoft.com/germany/msdn/solve/knowhow/howto/cliententwicklung/WieKannIchNETAnwendungenUnterLinuxErstellenUndAusfuehren.aspx Ob der o.g. Code so ohne weitere Anpassung auch unter Mono kompatibel ist, bleibt offen. * Ohne BrickD-Treiber/Service sollte der Betrieb von TF-Bricks nicht möglich sein. Die selbstgeschr. Anwendung egal ob VB.net, C#, Java, C etc. sind erstmal nur lauffähig auf dem Host-PC, auf dem ein BrickD-Dienst installiert und lauffähig ist. Dazu gehört auch der RaspbPi, der allerdings u.a. die Vorteile mitbringt wenig Strom zu verbrauchen und sehr kompakt gegenüber Notebook oder Desktop-PC ist. Wenn das nötig ist, würde sich als Programmiersprache für den RaspPi z.B. Java anbieten. Der Brick-Viewer ist sehr praktisch um die TF-Bricks/bricklets erstmal ohne DIY-Programmierung zu testen oder auszuprobieren. PS: Alternativ um den TF-Stack dezentral vom PC zu betreiben: http://www.tinkerforge.com/de/doc/Hardware/Master_Extensions/WIFI_Extension.html#wifi-extension oder kabelgebunden z.B. http://www.tinkerforge.com/de/doc/Hardware/Master_Extensions/Ethernet_Extension.html#ethernet-extension Zitieren
AuronX Geschrieben June 18, 2013 at 13:29 Geschrieben June 18, 2013 at 13:29 die VB.Net Anwendung aber unter einem Windos-Rechner und VisualStudio erstellt wurde, die EXE ist so auf dem Linux erstmal nicht lauffähig (irgendwelche VMs oder WinEmu lassen wir mal weg) Das ist einfach nicht korrekt. Du brauchst Mono, das ist korrekt. Das mal eben wegzulassen ist aber genauso wie zu sagen Java würde unter Linux nicht laufen, weil du die JVM brauchst. Ich rede hier nicht von WinEMU oder einer vollwertigen VM in der Windows läuft, Mono ist einfach nur die Laufzeitumgebung für C# (so wie Python-Programme die Python-Umgebung brauchen, Java-Programme die JVM, Ruby-Programme die Ruby-Umgebung usw. usf.) Sofern dein VB.Net-Projekt gegen das .NET-Framework 2.0 gebaut wurde läuft es mit Sicherheit. Falls es gegen eine höhere Version gebaut wurde (3.5/4.0) läuft es noch immer mit hoher Wahrscheinlichkeit. Ich verstehe nicht warum alle Welt so tut als wäre C# eine reine Windows-Kiste, nur weil es von Microsoft entwickelt wurde... Das geht nicht gegen dich nic, weil es wirklich so ziemlich alle tun denen ich begegne... .NET-Anwendungen sind plattformunabhängig, sofern du ein CLR für deine Plattform hast. Unter Linux ist das Mono. Du kannst sogar die gleichen Assemblies nutzen, musst also nicht wie bei C für verschiedene Plattformen kompilieren. Das beste Beispiel ist übrigens TF. Soweit ich weiß werden die C#-Bindings die man hier runterladen kann unter Linux mit Mono gebaut. edit: Wie sich herausstellt ist die Situation sogar besser als ich dachte. Ein kurzes Zitat von dieser Seite: The easiest way to describe what Mono currently supports is: Everything in .NET 4.0 except WPF, WWF, and with limited WCF. Zitieren
borg Geschrieben June 19, 2013 at 08:43 Geschrieben June 19, 2013 at 08:43 Eine mit C#/VB.NET erstellte .exe kannst du so wie sie ist unter Linux ausführen, das ist in der Tat unproblematisch und sogar besser integriert als Java. Viele Programme die in C# geschrieben sind verwenden allerdings low-level WinAPI oder DirectX oder vergleichbares. Dadurch funktionieren sie dann wieder nicht out-of-the-box unter Linux. Genauso wie ein Java-Programm welches eine "Windows only"-Library verwendet. Bei C# ist es viel üblicher WinAPI o.ä. zu verwenden als bei Java. Dadurch lassen sich viele Programme die auf der CLR laufen dann doch nicht unter Linux ausführen... Zitieren
Nic Geschrieben June 20, 2013 at 09:09 Geschrieben June 20, 2013 at 09:09 Eine mit C#/VB.NET erstellte .exe kannst du so wie sie ist unter Linux ausführen, das ist in der Tat unproblematisch Also eine typische Linux-Distrib. für den RaspPi hat als Grundbestandteil schon eine Laufzeitumgeb. für .NET integriert ? Und diese ist abwärtskompatibel bis zur 2.0 ? Zitieren
borg Geschrieben June 20, 2013 at 09:19 Geschrieben June 20, 2013 at 09:19 Klar, du musst halt mono installieren (was in den repos drin ist, "mono-runtime" heißt das Paket unter Debian). Genauso wie du java installieren würdest. Wie AuronX schon sagt, die Libs für C#/VB.NET die wir hier verbreiten werden unter Linux mit mono gebaut. Funktionieren aber auch einwandfrei in VS. Das nächste Starter Kit hat ein großes Beispiel welches C# benutzt (mit GUI usw) welches direkt unter Windows/Linux läuft. Zitieren
Nic Geschrieben June 20, 2013 at 09:29 Geschrieben June 20, 2013 at 09:29 Klar, du musst halt mono installieren Ich bin da etwas irretiert, aber das habe ich doch auch in meinem 1.Posting schon erwähnt. Ohne Mono würde die EXE erstmal nicht lauffähig sein. Zitieren
borg Geschrieben June 20, 2013 at 09:42 Geschrieben June 20, 2013 at 09:42 Klar, genauso wie eine java .jar nicht ohne eine jre lauffähig ist, oder Python nicht ohne den Python-Interpreter. Zitieren
Nic Geschrieben June 20, 2013 at 12:23 Geschrieben June 20, 2013 at 12:23 Gut, und nichts anderes hatte ich gemeint; warum AuronX meine Eräuterungen als fachlich falsch interpretiert, wird nur er erklären können Etwa anderes: Aiken beschreibt sein Projekt als lauffähig direkt aus VS, man könnte den Eindruck bekommen, dies funktioniert ohne BrickD. Nicht das ich hier im Forum etwas verpasst hätte, aber eine native Verbindung nur zw. Bindings/TF-Framework und Hardware via USB Kabel ohne BrickD-Treiber ist nicht möglich ?! Zitieren
borg Geschrieben June 20, 2013 at 13:50 Geschrieben June 20, 2013 at 13:50 Wenn du die WIFI/Ethernet Extension benutzt brauchst du keinen brickd auf dem PC (sonst schon). Zitieren
Nic Geschrieben June 20, 2013 at 14:04 Geschrieben June 20, 2013 at 14:04 Achso hatte ich ganz vergessen :'(, dass mit diesen Ext. der BrickD obsolet wird. Zitieren
AuronX Geschrieben June 20, 2013 at 18:04 Geschrieben June 20, 2013 at 18:04 Gut, und nichts anderes hatte ich gemeint; warum AuronX meine Eräuterungen als fachlich falsch interpretiert, wird nur er erklären können Das war nur auf den von mir zitierten Stichpunkt bezogen... Der Stand da so für sich, dass ich den Eindruck gewonnen habe du würdest eine höhere Hürde in der vorhandenen .NET-Anwendung sehen als in einer (imaginären) vorhandenen Java oder Python-Anwendung. Sollte ich das falsch verstanden haben, bitte ich meinen Kommentar nur als Ergänzung zu deinen Ausführungen zu betrachten Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.