... ist das überhaupt realistisch möglich? Wie löst ihr das so?
Also hier im Homeoffice bin ich tatsächlich von einer großen Zahl von mikrocontrollergesteuerten Geräten umgeben. Ich würde also eher sagen: Homeoffice außerhalb der Reichweite von embedded systems ist völlig unmöglich.
Hier in meinem Homeoffice liegen viele emebbded Systeme rum - Atmega, ESP, Raspi Homeoffice ist eine geile Sache, könnte ewig so weitermachen :)
Hier in meinem Homeoffice liegen viele emebbded Systeme rum - Atmega, ESP, Raspi Homeoffice ist eine geile Sache, endlich gehe ich wieder gerne zur Arbeit :)
Beitrag #6481833 wurde von einem Moderator gelöscht.
Walter T. schrieb: > Also hier im Homeoffice bin ich tatsächlich von einer großen Zahl von > mikrocontrollergesteuerten Geräten umgeben. Kaffeemaschinen?
LowLu schrieb: > ... ist das überhaupt realistisch möglich? > > Wie löst ihr das so? Was auch immer du unter "Embedded" verstehst... Ein Viertel der Firmen hat bei ihren Home-Office-Leuten gesunkene Produktivität festgestellt: https://www.zdf.de/nachrichten/wirtschaft/homeoffice-umfrage-produktivitaet-100.html
100Ω W. schrieb: > Walter T. schrieb: >> Also hier im Homeoffice bin ich tatsächlich von einer großen Zahl von >> mikrocontrollergesteuerten Geräten umgeben. > > Kaffeemaschinen? Drucker, Teekran, Oszilloskop, Lötstation, Funktionsgenerator, noch ein Drucker, USB-Hubs, Monitore, noch ein Drucker, DECT-Telefon, Multimeter, Schneidplotter, Router, Mini-Drehmaschine... ...aber irgendwie bin ich im Homeoffice technisch sowieso deutlich besser ausgestattet als im Büro. Edit: Einen Drucker habe ich noch vergessen.
:
Bearbeitet durch User
Beitrag #6481852 wurde von einem Moderator gelöscht.
Reinhard S. schrieb: > Ein Viertel der Firmen hat bei ihren Home-Office-Leuten gesunkene > Produktivität festgestellt: Kein Wunder. Denn: Qwertz schrieb im Beitrag #6481833: > Warum sollte man im Home Office überhaupt arbeiten? Der Chef ist nicht > da? Netflix ist doch viel spannender!
Bin aktuell auch im HomeOffice. Gerade wenn man nicht viel zu tun hat ist es richtig geil. Bissl zocken, bissl Netflix, hin und wieder mal gucken ob ne Mail eingetrudelt ist. Aber ab Dezember ist Harz4light angesagt. Kurzarbeit auf 100%. Schließlich will meine Firma auch was von dem großen deutschen Steuerkuchen haben.
Tja einerseits erschreckt was die Deutsche Wirtschaft bzw. die Politik daraus macht. Also ihr müsst zu 100% nicht in die Firma fahren? Oder irgendwelche Reisetätigkeiten unternehmen?
Ich habe das Gefühl, HomeOffice teilt die Kollegen in genau zwei Gruppen: In einer steigt die Produktivität - in der anderen sinkt sie. Was das über die Kollegen aussagt, mag sich jeder selbst denken... Wer in dem Bereich arbeitet, hat doch meist ohnehin ein gut eingerichtetes Labor daheim, aus Geräten, die bei der Arbeit entsorgt wurden?
Erwin schrieb: > Ich habe das Gefühl, HomeOffice teilt die Kollegen in genau zwei > Gruppen: In einer steigt die Produktivität - in der anderen sinkt sie. Im Mittel passt es dann ja wieder, und Alle sind glücklich. Amen.
Ich mache schon seit bald 10 Jahren Homeoffice als Embedded Entwickler. Die letzten paar Wochen 100%. Das ist überhaupt kein Problem. Gerätschaften habe ich alle hier liegen, über Remotedesktop kann ich auf Größere Testumgebungen zugreifen, den Rest erledigt der Jenkins.
Ich schalte mich Remote an meinen Arbeitsrechner wo die Hardware angeschlossen ist. Eine Webcam steht dort auch zum gucken was passiert. Geht wunderbar. Ich muss im Moment aber keine Hardware selbst reparieren/löten sondern nur programmieren.
Frickler schrieb: > Ich muss im Moment aber keine Hardware selbst reparieren/löten sondern > nur programmieren. Du schreibst: programmieren, aber du meinst: frickeln, hab ich recht?
LowLu schrieb: > ... ist das überhaupt realistisch möglich? Natürlich ist das möglich. Wer eine Funktion nicht so schreiben kann, dass sie sowohl auf einem µC als auch auf einem PC kompiliert werden kann, der sollte vielleicht besser kein Entwickler sein ;-)
Ich kann sehr gut Embedded zuhause machen. Code schreibt sich nicht von selbst. Zu embedded Code braucht's dann auch noch ein Stueck PC Software, und die kann ich ja auch mal schreiben. Besser testen und simulieren. Irgendwann muss man's dann vor Ort laufen lassen.
Mark B. schrieb: > Natürlich ist das möglich. > Wer eine Funktion nicht so schreiben kann, dass sie sowohl auf einem µC > als auch auf einem PC kompiliert werden kann, der sollte vielleicht > besser kein Entwickler sein ;-) Wer behauptet, dass man auf Mikrocontrollern kompilieren kann sollte sich nicht so weit aus dem Fenster lehnen! Da hast du dich jetzt ordentlich blamiert!
Qwertz schrieb: > Mark B. schrieb: >> Natürlich ist das möglich. >> Wer eine Funktion nicht so schreiben kann, dass sie sowohl auf einem µC >> als auch auf einem PC kompiliert werden kann, der sollte vielleicht >> besser kein Entwickler sein ;-) > > Wer behauptet, dass man auf Mikrocontrollern kompilieren kann sollte > sich nicht so weit aus dem Fenster lehnen! Da hast du dich jetzt > ordentlich blamiert! Naja, ARM gilt ja als mikrocontroller und spätestens seit Apple wieder PC's mit ARM-prozessor baut (war das nicht eigentlich der Anfang von ARM als "Acorn Risc Machine"???) ist die Vorstellung von kompilierenden Mikrocontroller garnicht so abwegig. Siehe auch: https://de.wikipedia.org/wiki/Tiny_C_Compiler
Hallo Andreas M. schrieb: > das ist überhaupt kein Problem. > Gerätschaften habe ich alle hier liegen, über Remotedesktop kann ich auf > Größere Testumgebungen zugreifen, den Rest erledigt der Jenkins. Als einfacher Facharbeiter der seine Arbeit ganz bestimmt nicht in einen Homeoffice erledigen kann frage ich mich was (wie) da "Fern bedient" (oder ist Remote in der Embedded System Entwicklung was anderes?) gemacht bzw. gearbeitet und gemessen, getestet usw. wird. Kann man da auch das testen was vorher nicht schon sehr genau geplant wurde? Schon irgendwelche Messspitzen an ein Testobjekt bringen, oder der Testobjekt in eine praktische Position zu bringen stelle ich mir ausserhalb von genau vor geplanten und angepassten Umgebungen sehr schwer vor. Oder besteht die Testumgebung rein aus Software und Leistungsfähigen Rechnern und alles ist nur virtuell? Wie gesagt: "Nur" neugieriger Facharbeiter der nur ganz grobe (eventuell falsche) Vorstellungen hat was ein im Embeddes Systems Bereich so gemacht wird - ein wenig an Hardware arbeiten und auch mal was messen wird doch dazu gehören... oder doch nicht? Und was (wer?) ist "Jenkins" ? Ein Messsystem, eine Software, ein "Remote Mitarbeiter" ;-) Hennes
Hennes schrieb: > Kann man da auch das testen was vorher nicht schon sehr genau geplant > wurde? Je größer das embedded-Projekt, desto kleiner ist der Anteil, der wirklich mit der Außenwelt spricht (sprich: auf I/O geht). Wenn man seine Software sauber auftrennt, kann man also alle funktionen, die nicht direkt mit der I/O zu tun haben, auch ohne diese testen. Im Extremfall reicht ein Debugger und z.B. serielle Kommunikation. Beides geht über ein VPN fernzusteuern. Dann hat man zum Testen zumindest - Original-Funktionen - Original-Compiler - Original-Prozessor Damit findet man nicht alle Fehler, aber viele. Und damit müssen für die Software nicht so viele Prototypen-Geräte für die Softwareentwicklung bereitstehen (für die obengenannten Tests reicht ein Eval-Board). Den Schritt weiter - dass der Prozessor in Wirklichkeit auch nicht existiert, sondern nur eine Simulation ist, gibt es auch, ist aber aus verschiedenen Gründen nicht immer beliebt.
:
Bearbeitet durch User
Magst du mehr Infos zu dem Testsetup geben? Es interessiert mich wirklich, da ich mir unschlüssig bin, wie genau ich Unittests für einen Mikrocontroller umsetzen soll. Gebaut wird von Jenkins, aber wo lasse ich die Unittests dann am besten laufen um skalierbar zu bleiben aber auch möglichst aussagekräftige Ergebnisse zu erzielen? Keil bietet ja zum Beispiel einen Simulator an. Oder doch lieber alles per GCC/Clang kompilieren und mit Unittestframework testen?
Hennes schrieb: > Und was (wer?) ist "Jenkins" ? https://de.wikipedia.org/wiki/Jenkins_%28Software%29 War jetzt nicht so schwer zu finden, oder? ;-)
Hennes schrieb: > Kann man da auch das testen was vorher nicht schon sehr genau geplant > wurde? > Schon irgendwelche Messspitzen an ein Testobjekt bringen, oder der > Testobjekt in eine praktische Position zu bringen stelle ich mir > ausserhalb von genau vor geplanten und angepassten Umgebungen sehr > schwer vor. Embedded ist ein sehr weites Feld. In meinem Fall geht es um Kommunikationsprozessoren im Industriellen Umfeld. Da gibt es nicht wirklich was zu messen, bei uns ist eher der Knackpunkt dass die ganze Software auf dem Mikrocontroller Ihre Zeitvorgaben einhält, d.h. das bestimmte Aktionen reproduzierbar immer wieder dem selben Zeitablauf folgen. In meinem speziellen Fall heißt das, dass bestimmte Aktionen in der Software/System mit einer Wiederholgenauigkeit von etwa 10µs ausgeführt werden müssen. Dazu soll das System nebenher natürlich auch noch Webserver, TCP/UDP und sonst was anderes machen. Der Testaufbau besteht im wesentlichen aus einem PC mit vielen Erweiterungskarten welche unsere Kommunikationsprozessoren enthalten/ansprechen. Diese sind alle über einen Netzwerkswitch miteinander verbunden. Typischerweise spielt dann einer der K.-Prozessoren "Steuerung" und die anderen "Gerät". Die Testsoftware läuft auf dem PC in Form von Python Skripten, welche dann verschieden Szenarien durchprüfen, also Aktionen an den K.-Prozessoren auslösen und dann die Reaktionen auswerten, ob diese Erwartungsgemäß funktionieren. Der Fachbegriff dafür ist "Hardware-In-The-Loop" (HIL) Test. Wir haben im Laufe der Zeit einige 1000 Testfälle erstellt und es werden wöchentlich mehr. Die Aufgabe des Jenkins besteht darin, wenn ich eine Quellcodeänderung in unser Versionskontrollsystem (Subversion, Git o.Ä.) einpflege, dann wird der Jenkins automatisch aktiv, übersetzt die Firmwaren neu und führt dann mit diesen neuen Firmwaren automatisiert die o.g. Tests durch. Wenn ein Test fehlschlägt, gibt es eine E-Mail. Dadurch kann man Sicherstellen das während der Entwicklung nicht bereits funktionierende Sachen kaputt gemacht werden. Wenn man etwas ändert, dann testet man selbst nur kurz die direkten Zusammenhänge, alles weitere passiert dann automatisiert, das spart zum einen Zeit und macht die Tests viel besser reproduzierbar. Unser Jenkins hat dazu insgesamt ca 20 Testrechner zu Verfügung welche wie oben beschrieben ausgerüstet sind. Teilweise haben wir statt normalen Netzwerk (für Profinet, EthernetIP, Modbus) auch Testrechner mit Profibus, Powerlink, Ethercat oder DeviceNet Netzwerken/Bussen. Das Ganze kann man dann zum "Test Driven Development" erweitern. Das heist man schreibt zuerst das Testskript welches die (neuen) Vorgaben abprüft und fängt dann erst mit dem Entwickeln an der Software an, optimalerweise zwei unterschiedliche Kollegen. Inzwischen funktioniert das so gut, dass mein Debugger schon wieder seit drei Monaten in der Schublade verstaubt. Den packe ich nur noch bei Härtefällen aus. Ich habe also "Messpitzen", dass sind bei mir die Python Skripte :-) Simulationen nutzen wir auf der Ebene bisher nicht.
Man sollte auch nicht vergessen dass man in größeren Projekten sowieso daran gewöhnt ist über die halbe Welt verteilt zu arbeiten. Schon vor Corona waren bei uns Projekte zusammen mit Entwicklungsteams, Zulieferern usw. in den USA, China, Indien, ... gängig. Da hat man schon längst Arbeitsabläufe die zum größten Teil von Überall ausgeführt werden können.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.