Forum: Ausbildung, Studium & Beruf Homeoffice im Bereich Embedded System


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von LowLu (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
... ist das überhaupt realistisch möglich?

Wie löst ihr das so?

von Irrer Iwan (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
Hoffentlich hat dieser Homeofficewahn bald ein Ende.

von Walter T. (nicolas)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Udo (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Hier in meinem Homeoffice liegen viele emebbded Systeme rum - Atmega, 
ESP, Raspi

Homeoffice ist eine geile Sache, könnte ewig so weitermachen :)

von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.
von 100Ω W. (tr0ll) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Walter T. schrieb:
> Also hier im Homeoffice bin ich tatsächlich von einer großen Zahl von
> mikrocontrollergesteuerten Geräten umgeben.

Kaffeemaschinen?

von Reinhard S. (rezz)


Bewertung
0 lesenswert
nicht lesenswert
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

von Walter T. (nicolas)


Bewertung
1 lesenswert
nicht lesenswert
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.
von Irrer Iwan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Harz4light (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von LowLu (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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?

von Erwin (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Senf D. (senfdazugeber)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas M. (amesser)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Frickler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Senf D. (senfdazugeber)


Bewertung
-3 lesenswert
nicht lesenswert
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?

von Mark B. (markbrandis)


Bewertung
1 lesenswert
nicht lesenswert
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 ;-)

von Zottel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Qwertz (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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!

von Joseph Jausenvetter (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Hennes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Walter T. (nicolas)


Bewertung
1 lesenswert
nicht lesenswert
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
von dunky (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Hennes schrieb:
> Und was (wer?) ist "Jenkins" ?

https://de.wikipedia.org/wiki/Jenkins_%28Software%29

War jetzt nicht so schwer zu finden, oder? ;-)

von Andreas M. (amesser)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.