Hi Leute, folgende Ausgangssituation: Ich bin Elektrotechniker und mache öfters auch Hobbyprojekte. Ich würde sagen alles was Analogelektronik, Leistungselektronik, FPGAs angeht komme ich gut mit zurecht. Mit Mikrocontrollern habe ich in der Vergangenheit öfter STM32 programmiert (mit CubeMX und der CubeIDE) sowie den ESP32 direkt mit dem ESP-IDF Framework. Teilweise auch komplexere Sachen wie z.B. UDP Pakete hin und hersenden mit einem externen Phy am STM32. Auf dem PC mache ich auch öfters kleine Tools mit C#. Wenn es aber zu - ich sage mal - "komplexerer Software" kommt auf einem uC mit IP-Stack oder RTOS bin ich immer sehr darauf angewiesen dass ich als Startbedingung eine funktionierende Umgebung habe. Sprich ein im Voraus korrekt integriertes Softwarestack Mal eben schnell ein eigenes IP-Stack einbinden oder größere Software-Libraries führen bei mir immer zu Kopfzerbrechen, wenn diese dann zu endlosen Kompilierfehlern führen und irgendwelche defines nicht aufgelöst werden können oder Sprachkonstrukte vom Compiler nicht geschluckt werden und man am Ende hunderte Error-Warnings gezeigt bekommt. Ich wollte mal fragen, wie man so etwas professioneller angeht oder wie ihr es macht?
Markus schrieb: > Ich wollte mal fragen, wie man so etwas professioneller angeht oder wie > ihr es macht? Man baut auf Teile auf die man schon hat. mfg Klaus
Markus schrieb: > Ich wollte mal fragen, wie man so etwas professioneller angeht oder wie > ihr es macht? Der Startpunkt ist meistens ein Demoboard mit Software. Damit wird rumgespielt bis man die Anforderungen besser versteht und die Machbarkeit geprüft hat. Danach konzentriert man sich auf auf die Portierung. Generell fängt bei uns niemand bei Null an, entweder man kauft sich RTOS Software und Support ein oder hat einen Kollegen der das kann. Dieses Privileg haben wir Hobbyisten leider nicht.
Markus schrieb: > Ich wollte mal fragen, wie man so etwas professioneller angeht Keine open source Elaborate von anderen Bastlern verwenden die es nur 1 x bei sich zu Hause ausprobiert haben, sondern kommerzielles Zeug das auch ordentlich dokumentiert ist. You get what you pay for.
Markus schrieb: > Ich wollte mal fragen, wie man so etwas professioneller angeht oder wie > ihr es macht? Das ist eine Frage von Ausbildung und Erfahrung. Dürfte bei komplexen elektrotechnischen Themen ja nun nicht anders sein. Man kann nicht erwarten mit ein paar Stunden try&error rumfrickeln am Ende dann ein großes Softwareprojekt stemmen zu können. Das geht nur wenn man sich WIRKLICH damit beschäftigt.
Markus schrieb: > folgende Ausgangssituation: > > Ich ... mache öfters auch Hobbyprojekte. > ... > Auf dem PC mache ich auch öfters kleine Tools mit C#. > > Mal eben schnell ein eigenes IP-Stack einbinden oder größere > Software-Libraries führen bei mir immer zu Kopfzerbrechen, wenn diese > dann zu endlosen Kompilierfehlern führen und irgendwelche defines nicht > aufgelöst werden können oder Sprachkonstrukte vom Compiler nicht > geschluckt werden und man am Ende hunderte Error-Warnings gezeigt > bekommt. > > Ich wollte mal fragen, wie man so etwas professioneller angeht oder wie > ihr es macht? Als Hobbyist würde ich jetzt mal vorraussetzen, dass die Lust am lernen/zukünftigen Vermeiden grösser ist als der Wunsch nach effizienter Lösung. Deswegen empfehle ich hier die Fehler als 'Leseempfehlung' zu deuten, nimm den ersten Fehler und versuch ihn zu beseitigen (meist ist es was banalstes.. eine typeninkompatibilität ein fehlendes include.. sowas...) ist der erste Fehler beoben, sind von den hundert ursprünglichen Fehlern vllt noch 80 über, kümmerst Du dich um einen nach dem anderen, gehen die Zahlen immer weiter runter, selten geht die Zahl wieder nach oben (kann aber passieren, wenn man zB ein falsches include erwischt), und wenn man das ein WE durchhält und sich dabei auch ansieht was man tut ggf auch länger als ne Minute um zu verstehen was dahinter steckt, ist man relativ sicher, dass man genug dabei lernt um beim nächsten Hobbyprojekt weniger Fehler beim ersten compilieren zu erhalten. Und nach ausreichend Projekten dieser Art belaufen sich die drei Fehler beim ersten compilieren auf banale Tippfehler, vergessene terminatoren und dergleichen Lächerliches ;) Effizienter ist es mMn die Fehler nach Art zu bearbeiten, je einen für jede erkennbare Fehlerursache, wissend welche Fehler sich selbst erledigen sobald einer seiner Zwillinge ausgemerzt wurde. So hat man in zwei maximal drei Schritten alle Fehler behoben dazu muss man die Fehlerursache aber auch effektiv als 'ähnlich' erkennen, was erst mit der Erfahrung wirklich einfach wird; lernen kann man dabei allerdings so gut wie nichts mehr, denn man achtet nichtmehr auf die Ursachen, nurnoch auf die Lösungen. Also wenn Du sagst Hobby, sag ich, nimm dir die Zeit das langsam aufzulösen, das macht zwar nicht immer Spass, aber immer bleibt was 'neues' hängen ;) 'sid
Da hilt es meist Fehler für Fehler durchzugehen. Irgendwann sieht man auch Licht am Ende des Tunnels.
> Ich wollte mal fragen, wie man so etwas professioneller angeht oder wie > ihr es macht? Nur wenig fremde Software verwenden, ansonsten lernen damit zu leben. Die gesamte Softwareentwicklung faehrt gerade gegen die Wand. Also zuruecklehnen und die Fahrt geniessen. :-D Olaf
Markus schrieb: > Ich wollte mal fragen, wie man so etwas professioneller angeht oder wie > ihr es macht? Ich würde immer versuchen, das die Software sich mit einem Kommando von der command line aus bauen läßt (darauf kann man dann immer noch eine IDE drauf setzen). Dann kannst Du Tools (wie z.B. Conan oder CMake) verwenden, um externe Abhängigkeiten zu versionieren, zu laden oder ggf. sogar auch zu bauen. Alle Regeln (defines, Pfade etc.) kannst Du dann in entsprechenden Skripten hinterlegen und auch wiederverwenden (mit den typischen IDE XML-Dateien geht das eben nicht).
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.