Wie programmierfähigkeiten testen? (Embedded)

Michael H. schrieb:
> Gibt es irgendwas, um abzuchecken, dass Leute wirklich embedded
> Programmieren können?

Daraus schließe ich, dass Du selber auch keine Ahnung von embedded hast?

J. W. schrieb:
> Und da musste der Bewerber was einfaches porgrammieren und flashen, LED
> die mit bestimmter Frequenz blinkt.

Im Ernst!?
Wie lange hat man dafür Zeit? Sprich, sich erstmal in die Doku einlesen 
etc?

J. W. schrieb:
> Ich war bei einer Firma, die das hands-on festgestellt hat.
> Da gab es einen PC mit angeschlossenen Evaluation-Board, installierten
> Compiler, usw.
> Und da musste der Bewerber was einfaches porgrammieren und flashen, LED
> die mit bestimmter Frequenz blinkt.
>
> Eine Garantie war das aber auch nicht.
>

Genau, man sollte sich nämlich neben dem dabei herausgekommenen Code 
(auch grausig zusammengefrickelter Code kann eine LED zum Blinken 
bringen - so nach dem Motto aussen hui und innen pfui) auch ansehen, wie 
der/die BewerberIn an die Sache rangeht. Dann kann der Test sogar etwas 
bringen.

Wichtig bei solchen Aufgabenstellungen ist es, den Internetzugang zu 
sperren, damit die Leute tatsächlich gezwungen sind das Datenblatt zu 
lesen, und nicht nur Lösungen aus einem Forum kopieren! Ein schönes 
kleines Beispiel wäre auch die Ansteuerung eines Schieberegisters o.ä. 
per SPI. Wenns am Ende nicht funktioniert ist das ja auch nicht so 
schlimm - wenn man schon nahe an der Lösung dran ist aber nur irgendwo 
ein Bit falsch ist kann man das ja auch gelten lassen.
Man könnte auch ein fehlerhaftes Programm stellen, und den Bewerber den 
Fehler suchen lassen, mithilfe eines Debuggers und eines Oszilloskops - 
man sollte ja beides bedienen können...

Michael H. schrieb:
> wie testet man von Bewerbern am besten die Embedded-Fähigkeiten?

Ohne Bewerbungsunterlagen, mit Zeugnissen, aus dem das hervorgeht?
Gewöhnlich lädt man die ohne doch gar nicht erst ein.
Eigentlich sollte man dich testen oder wenigstens zur Verantwortung
ziehen.

> Ich hatte kürzlich den Fall, dass Leute behaupten sie können was weiß
> ich alles und scheitern dann am einfachen Datenblatt-Lesen oder
> verstehen.

Als Chef, Personaler oder was? Das du als Zugehöriger dieser 
Interessengruppe ausgerechnet hier die überwiegende Zahl von
Arbeitnehmern fragst, stimmt schon etwas nachdenklich.
Woher willst du denn wissen, wer dir antwortet, der darin Erfahrung
hat?

> Gibt es irgendwas, um abzuchecken, dass Leute wirklich embedded
> Programmieren können?

Fehlt nur noch ein Eignungstest. Sollen die AN künftig unternehmerische
Risiken übernehmen? Dann müssen die AN aber auch irgend welche Vorteile
bekommen. Nix gibts umsonst, höchstens leere Versprechungen.

Nach meinen Beobachtungen wissen die AG meist gar nicht was sie wollen
und wenn man Ausschreibungen liest, vermisst man signifikante Angaben,
wie z.B. welche Controllerfamilie erwartet wird und einiges mehr.
Alles wirkt wie anreizlos abgespeckt, aber der AG will entscheiden
über Schicksale wie ein König.

Und so ein König soll einen nachher folgenhaft bewerten?

Michael H. schrieb:
> Ich hatte kürzlich den Fall, dass Leute behaupten sie können was weiß
> ich alles und scheitern dann am einfachen Datenblatt-Lesen oder
> verstehen.

Ich hoffe für Dich, dass die Attitüde, die diese Formulierung rüber 
bringt, nicht wirklich auf Dich zutrifft. Denn Du zeigst hier, dass es 
Dich einen Kehricht interessiert, was Deine Arbeitnehmer wirklich können 
("was weiß ich") und dass Du nicht bereit bist ihnen 
Entwicklungsmöglichkeiten zuzugestehen. Gerade beim Lesen von 
Datenblättern übersieht oder miss-interpretiert man leicht mal ein 
entscheidendes Detail - selbst wenn es sich um ein gut gemachtes 
Datenblatt handelt. Sich dann im Nachhinein großkotzert hinzustellen und 
die grundsätzliche Kompetenz des Arbeitnehmers in Frage zu stellen, ist 
natürlich bequem. Statt Deine Fachkraft zu fördern schmeißt Du sie dann 
lieber weg. Als nächstes kommt dann wohlmöglich noch das Herbeireden 
eines Fachkräftemangels.

Hoffentlich liege ich total falsch. Denn ansonsten kann ich Deinen 
Arbeitnehmern nur wünschen, dass Du als Arbeitgeber möglichst schnell 
vom Markt verschwindest, statt sie zu verschleißen.

Moin,

eine viel wichtigere Frage wäre: Wie checkt man die Fähigkeiten von 
'Managern', die im Embedded Bereich Entwicklungen leiten oder beratend 
tätig sind. Denn die richten deutlich den grösseren Schaden an, als mal 
ein junger Entwickler, der sich aufgrund seiner guten Bologna-Note etwas 
selbst überschätzt.
Die Frage des TO alleine macht mir diesbezüglich schon etwas 
Kopfschmerzen...
Meine Lieblingstest war:
- Irgend ein Assembler-Snippet hinlegen: Was könnte das machen?
- Bei den Eltechnikern: Kirchhoffsche-Regel abchecken (kein Witz!)
- C-Klassiker kommentieren lassen, wie unten (erst WRITE, dann READ, und 
wo steckt die Gefahr)

Mir war immer wichtig, dass die Leute zeigen, dass sie Fehler aufspüren 
und sich 'reinhacken' können. Alles andere lernt man dementsprechend 
schnell.

1

int func(int mode, int *v)

2

{

3

    static int c;

4

    switch (mode) {

5

        case WRITE:

6

            c = *v; break;

7

        case READ:

8

            *v = c; break;

9

    }

10

11

    return 0;

12

}

Michael H. schrieb:
> wie testet man von Bewerbern am besten die Embedded-Fähigkeiten?

Kann man nicht, also das Potential was ein Bewerber mitbringt um nach 
beliebige Länge und Intesivität von Einarbeitung/Schulung zu leisten im 
Idealfall vermag ist IMHO nicht in 1h VG belastbar abtestbar.

Was man aber testen kann, ist was der Bewerber bisher gelernt/Getan hat 
und was er davon praktisch umsetzen kann. Einfach mal im Rollenspiel mit 
Alltagstypischen Szenarien konfrontieren.

Der Compiler meckert  "variable used before assigned" - wie verfährst du 
mit dieser Meldung?

Die Firma entwickelt Kaffeemaschinen, es kommt ein Anruf: Bei Kundex mit 
der Firmware geht nix mehr" - was sind deine nächsten Schritte

Erklären sie Besonderheiten der Nutzerinterface Button, Poti, 
drehencoder

Was sind soft-Buttons.

Was bewacht der Watchdog? was nicht?

Vorschlag für einen build-In-selbst-test der Kaffeemaschine?

Wann ist die Firmware schnell genüg?

Von Frisch-Absolventen würde ich mehr Basics erklären, bspw. 
Ablauf/Steuerung IRQ und bei der Abschlussarbeit bezüglich embedded 
Programmierung nach Details fragen lassen. Bspw was so die 3 dicksten 
bugs waren und wie diese erkannt worden.

Teddy schrieb:
> J. W. schrieb:
>> Und da musste der Bewerber was einfaches porgrammieren und flashen, LED
>> die mit bestimmter Frequenz blinkt.
>
> Im Ernst!?
> Wie lange hat man dafür Zeit? Sprich, sich erstmal in die Doku einlesen
> etc?

Doku einlesen? check den ordner /examples oder grep die *.h nach dem 
string gpio - da sollte man 1,2,3 die Funktion zum Pin-wackeln finden.

> Vorschlag für einen build-In-selbst-test der Kaffeemaschine?

Denglish oder Engleutsch?

Michael H. schrieb:
> Wie macht Ihr das?

Wenn ich als Kandidat um so etwas gebeten werde, biete ich einen 
"Schnuppertag" im Rahmen einer freiberuflichen Beauftragung an.

Das ist aber ganz gewiss nicht kostenlos für das Unternehmen.

Irgendwelche "Testereien" am Tisch gibt es nicht. Machen sowieso nur 
kleine Klitschen, die sich die Probezeit nicht leisten können.

Ordner schrieb:
> Kann man nicht, also das Potential was ein Bewerber mitbringt um nach
> beliebige Länge und Intesivität von Einarbeitung/Schulung zu leisten im
> Idealfall vermag ist IMHO nicht in 1h VG belastbar abtestbar.

Ich denke ein paar Basics kriegt man als erfahrener Entwickler auf jeden 
Fall von einem Uni-Abgänger heraus. Bei Spezialisten ist es teils schon 
kniffliger, denen muss man auch oft nachsehen, dass sie trotz PhD 
einfach gewisse Grundlagen vergessen haben.
Das Problem ist, dass heutzutage schon in vielen Mittelständlerfirmen 
die IoBS-Schwafler und HR-Top-Psychologen die Weichen stellen und kaum 
selber in der Lage sind, richtig gute Fragen zu stellen, da sie selber 
nie im Dreck gewühlt haben.
Ganz toll ist es dann, wenn nach 'nuernberger' die Nerds mit einbezogen 
werden, die Pi auf 240 Stellen auswendig können und eine 
Wahnsinns-Menschenkenntnis zur Schau stellen.
Und so stehen sich viele Firmen, die 'händeringend suchen' und das 
Fachkräftemärchen propagieren, eigentlich selber im Weg und müssen dann 
auf ebenso wasserkochende Personalvermittler zurückgreifen, um ihr Zeug 
irgendwie halbbatzig auf die Kette zu kriegen und faktisch ihre eigenen 
Management-Verkrustungen damit umgehen.

Michael H. schrieb:

> Gibt es irgendwas, um abzuchecken, dass Leute wirklich embedded
> Programmieren können?

Klassiker:
http://www.rmbconsulting.us/a-c-test-the-0x10-best-questions-for-would-be-embedded-programmers

> Was mir spontan einfällt:
> -Referenzprojekte
> -Code Samples

Hauptproblem dabei: professionell ersteller Code ist in der Regel 
Eigentum des AG, so daß der AN da keine Samples vorweisen kann/darf.

Zwar kann man in der Freizeit Opensource-Projekte machen, aber die sind 
dann meistens nicht professionell, sondern mehr quick&dirty. Weil's für 
den Eigenbedarf und den Nutzungsfall halt reicht.

Und selbst WENN man gute OSS-Projekte hat, hilft das wenig, wenn man 
nicht den gesamten Code komplett selber geschrieben hat, weil der neue 
AG das dann ja auch nicht sieht. Bei größeren OSS-Projekten arbeiten 
aber mehrere dran, und sei es nacheinander.

Und selbst WENN man ein gutes OSS-Projekt als Einmannshow hat, hilft das 
nicht, denn dann ist man raus, weil teamunfähig.

Außerdem guckt sich sowieso kein AG ernsthaft OSS-Projekte an, wo viel 
Code einsehbar wäre, weil das ja zu lange dauert.

Die Inkompetenz sitzt hier in der HR, die von der Materie sowenig Plan 
haben, daß sie nichtmal Fachleute von Blendern unterscheiden können - 
und sich deswegen auf das Abhaken von Checklisten konzentrieren.

Würde man bei Taxifahrern genauso vorgehen, dann bekäme ein Taxifahrer 
keinen Job, wenn er Erfahrung mit Mercedes-Taxis hat, aber leider ein 
Fahrer für ein VW-Taxi gesucht wird.

Strubi schrieb:

> int func(int mode, int *v)
> {
>     static int c;
>     switch (mode) {
>         case WRITE:
>             c = *v; break;
>         case READ:
>             *v = c; break;
>     }
>
>     return 0;
> }

Und was soll daran jetzt problematisch sein?

(klar, wenn v in den Wald zeigt, kann das undefiniertes Verhalten geben, 
aber das ist bei Pointerfehlern ja normal.)

Nop schrieb:
> Außerdem guckt sich sowieso kein AG ernsthaft OSS-Projekte an, wo viel
> Code einsehbar wäre, weil das ja zu lange dauert.

Also mir persönlich reicht eine Datei, um sich den Stil mal anzuschauen. 
Da kann man schon mal die Pragmatiker von den K&R-Häretikern trennen :-)

Ansonsten finde ich es auch interessant, wie jemand bei offenen 
Projekten die Bug-Reports handhabt, denn die blockierenden Egos in einem 
Team sind oft die, die nie die Bugs bei sich sehen, aber sich weigern, 
mal 'gcc -S' bei ihrem C++-Konstrukt zu machen um zu schauen, was 
wirklich dabei herauskommt. Sowas hat schon eine Firma in die Insolvenz 
getrieben (und ja, ich war dabei :-/ )

Nop schrieb:
> Strubi schrieb:
>
..
>
> Und was soll daran jetzt problematisch sein?

In der Form nix :-). Und ich gehe davon aus, dass du auch erklären 
könntest, warum/wo's knallt, wenn mans anders macht.

Nop schrieb:
> Strubi schrieb:
>
>> int func(int mode, int *v)
>> {
>>     static int c;
>>     switch (mode) {
>>         case WRITE:
>>             c = *v; break;
>>         case READ:
>>             *v = c; break;
>>     }
>>
>>     return 0;
>> }
>
> Und was soll daran jetzt problematisch sein?

Richtig problematisch sehe ich nix.
Aber warum einen Returnwert, wenn nur 0 zurückgegeben werden kann? -> 
weg damit.
Auf mode wird nie schreibend zugegriffen -> const.
Wenn man ein bißchen pseudo Typsicherheit vorgaukeln wollte, könnte man 
einen enum aus dem mode machen. Dann kann einem so mancher Compiler 
darauf hinweisen, wenn man einen case vergisst.
Natürlich kann man in v irgendeine wild gecastete Adresse auf nicht 
alloziierten Speicher rein werfen und damit beliebig Unfug treiben.
Der Code ist nicht threadsicher. Wollte man das z.B. auch aus einem Mix 
Hauptroutine / Interrupt aufrufen, sollte man c als volatile 
deklarieren.
Das sind so Punkte, die ich ansprechen würde, wenn man mir dieses 
Snippet in einem VG vorsetzte.
Vielleicht noch die Anmerkung, dass ich persönlich zwar nichts davon 
halte break in die gleiche Zeile wie die Operation zuvor zu schreiben. 
Aber wenn das Firmen-Style ist achselzuck kann ich auch mit leben.

Felix F. schrieb:
> Kein NULL-Pointer check.

Und schon trennt sich Spreu von Weizen. Diesen Job bekomme ich wohl 
nicht. :)

Nop schrieb:
> Strubi schrieb:
>
>> int func(int mode, int *v)
>> {
>>     static int c;
>>     switch (mode) {
>>         case WRITE:
>>             c = *v; break;
>>         case READ:
>>             *v = c; break;
>>     }
>>
>>     return 0;
>> }
>
> Und was soll daran jetzt problematisch sein?

Och ein Krümelkacker kackt dir da einen großen Haufen vor die Füß:

Schlecht lesbar da:
 -Kommentare fehlen
 -Leerzeile nach variablen Deklaration fehlt
 -Deklaeration von WRITE und Mode fehlt
 -uneinheitliches setzen von '{'  - mal eizeln auf einer Zeile, mal am 
Zeilende
 -kryptische identifier

wenigstens das spacing ist gut.

unsicher da:
-keine Überprüfung der Eingangsgrößen
-nichtsagnder Return-wert
-mglw Verwendung von Makros (WRITE/READ) besser wäre mode als enum zu 
deklarieren.

Misc Kritiken:
-Header (Autor, filename, Erstelldatum, Copyright) fehlt.

Code hinterlässt den Eindruck das der Autor tippfaul oder ungeübt im 
Umgang mit der Tastatur ist.

PS:
Wär Ironie-tags braucht soll sie selber setzen.

Strubi schrieb:

> Also mir persönlich reicht eine Datei, um sich den Stil mal anzuschauen.
> Da kann man schon mal die Pragmatiker von den K&R-Häretikern trennen :-)

Und woher weißt Du, wer den Code überhaupt geschrieben hat? Gerade bei 
OSS sind ja normalerweise mehrere Urheber dabei, selbst bei 
Einzelprojekten, außer man entwickelt wirklich alles from scratch.

> Ansonsten finde ich es auch interessant, wie jemand bei offenen
> Projekten die Bug-Reports handhabt

Bei vielen Opensource-Projekten: durch Ignorieren. Siehe hier:
https://betanews.com/2015/04/20/why-the-open-source-software-model-is-fundamentally-broken/

Andererseits kann man auch keinen Support verlangen, wenn man nichts 
bezahlt. Jeder gute Wille vom Maintainer ist schon eine Großzügigkeit 
seinerseits und keine Verpflichtung.

Das solltest Du auch bedenken, wenn Du bei offenen Projekten darauf 
schaust, wie mit bug reports umgegangen wird - das kann sich sehr davon 
unterscheiden, wie dieselbe Person reagiert, wenn man ihr Geld für das 
Fixen anbietet.

Gut, den Returnwert könnte man ändern.

Const setze ich nur bei Pointern, weil's da für den Aufrufer auch 
wichtig ist, ob der Buffer sich ändern darf oder nicht.

Nullpointercheck mache ich embedded nie, weil ich wegen 
Speicherfragmentierung und Laufzeitvarianzen ohnehin kein malloc und 
Konsorten verwende. Pointer sind damit entweder statisch allozierter 
Speicher oder Adressen von Stack-Objekten - in beiden Fällen nicht NULL.

Und aus einem Interrupt heraus würde ich so eine Funktion mit unnötigem 
Switch eh nicht aufrufen, sondern das direkt in irgendeinen geeigneten 
Buffer schreiben.

Aber der Punkt mit Threadsicherheit ist gut - als Metaller denkt man da 
nicht sofort dran. Nicht heavy metal, sondern bare metal. ;-)

Naja und ein Misra-Checker könnte den fehlenden default anmeckern.

Herbört schrieb:
> Der Code ist nicht threadsicher. Wollte man das z.B. auch aus einem Mix
> Hauptroutine / Interrupt aufrufen, sollte man c als volatile
> deklarieren.

Da hätte ich jetz gesagt: denken Sie nochmal drüber nach, ob das 
"volatile" wirklich hilft. Oder: wo lebt 'c'.

Aber lustig, das Thema NULL-Pointer kommt öfter auf, als dass jemand auf 
das "static" eingeht (Das fehlt nämlich in Slide n-1).

Ordner schrieb:
> -uneinheitliches setzen von '{'  - mal eizeln auf einer Zeile, mal am
> Zeilende

Auch wenn noch so viel Ironie drinstecken soll: Unterscheide zwischen 
Funktion und Statement...
Aber wo's in die Richtung geht, ist viel Religion (Gnu vs. K&R vs. Linux 
kernel) dabei. Da wird's auch wieder interessant für beide Seiten 
(AN/AG), ob sich jemand auf Coding-Style fokussiert und dabei das Ziel 
vergisst.

Nop schrieb:
> Bei vielen Opensource-Projekten: durch Ignorieren. Siehe hier:
> 
https://betanews.com/2015/04/20/why-the-open-source-software-model-is-fundamentally-broken/

Kompletter nonsense-Artikel von den ersten Zeilen weg (TL;DR). Sorry.
Opensource heisst nicht kostenlos, das wissen Firmen durchaus.

Strubi schrieb:

> Aber lustig, das Thema NULL-Pointer kommt öfter auf, als dass jemand auf
> das "static" eingeht (Das fehlt nämlich in Slide n-1).

Ja wenn's fehlt, ist das Ergebnis des Lesens von c natürlich 
undefiniert. Mit static nicht, auch nicht wenn man das erst mit READ und 
dann mit WRITE aufruft, weil c eine globale Variable (mit lokalem Scope) 
ist, die gemäß C-Standard implizit mit 0 initialisiert wird.

> Opensource heisst nicht kostenlos, das wissen Firmen durchaus.

Klar, wenn mit Opensource hier z.B. gemeint ist, daß Intel-Entwickler an 
Linux mitarbeiten. Natürlich kann Intel die anweisen, was sie wo 
implementieren, dokumentieren und fixen sollen.

Aber die kleineren Projekte sind eben kostenlose Freizeitprojekte, an 
die man nicht denselben Anspruch stellen darf (wenngleich man mitunter 
positiv überrascht wird).


Anyway, eine gute Frage wäre, was schon für interessante 
embedded-spezifische Bugs erlebt hat.

Mein Liebling: Absturz beim Hochfahren in einer Routine, die auf dem PC 
tadellos gelaufen war. Letztlich lag es daran, daß beim Konfigurieren 
wegen eines Drehers im define einer Mode-Maske aus Versehen ein Teil des 
RAMs in den powerdown versetzt wurde. Blöderweise lag da der Stack drin.

Strubi schrieb:
> Da hätte ich jetz gesagt: denken Sie nochmal drüber nach, ob das
> "volatile" wirklich hilft.

Hihi, stimmt, nützt eigentlich gar nix. Konkurrierende Schreibzugriffe 
können sich func immer noch gegenseitig unterbrechen. Da bräuchte es 
schon einen richtigen Mutex. Hat man den aber, dann ist das volatile 
bestenfalls nutzlos, sonst ein Zeitfresser.

> Aber lustig, das Thema NULL-Pointer kommt öfter auf, als dass jemand auf
> das "static" eingeht (Das fehlt nämlich in Slide n-1).

Ich hielt gerade das für den Clou: Eine Art Accessor, der es schafft in 
C so eine Art 'private' Variable zu verkapseln. Würde man c außerhalb 
der Funktion deklarieren, könnte man zwar getrennte getter / setter 
implementieren. Aber alle anderen Funktinen dieser Datei hätten auch 
Zugriff. Mit dieser lokalen statischen Variable nicht.

Letztendlich ist das aber ein rein akademisches Beispiel. Ohne dass eine 
richtige Motivation da ist - warum sollte ich gerade im Embedded Umfeld 
- den Zugriff auf eine Variable kapseln? Deswegen: Weg mit mode, func, 
return, switch. Macht eine einfache Sache sinnlos kompliziert.

Strubi schrieb:
> Ordner schrieb:
>> -uneinheitliches setzen von '{'  - mal eizeln auf einer Zeile, mal am
>> Zeilende
>
> Auch wenn noch so viel Ironie drinstecken soll: Unterscheide zwischen
> Funktion und Statement...

Eigentlich nicht, entweder "braces stand alone" oder eben nicht. aber 
nie gemischt. 
http://homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf

> Aber wo's in die Richtung geht, ist viel Religion (Gnu vs. K&R vs. Linux
> kernel) dabei. Da wird's auch wieder interessant für beide Seiten
> (AN/AG), ob sich jemand auf Coding-Style fokussiert und dabei das Ziel
> vergisst.

Ganz meine Meinung, die Frage ist immer nach dem Zweck/Sinn. Aber es 
soll Bereiche geben da sin Formalismen Krümekacker gern gesehen (QS), 
auch wenn es wirklichen kein Zugewinn am Produktnutzen,-wartbarkeit 
bringt. Trotzdem könnte man sich der Code Style Knute beugen - wenn's 
den Chef glücklich macht ...

Nop schrieb:

> Nullpointercheck mache ich embedded nie, weil ich wegen
> Speicherfragmentierung und Laufzeitvarianzen ohnehin kein malloc und
> Konsorten verwende. Pointer sind damit entweder statisch allozierter
> Speicher oder Adressen von Stack-Objekten - in beiden Fällen nicht NULL.
>
> Und aus einem Interrupt heraus würde ich so eine Funktion mit unnötigem
> Switch eh nicht aufrufen, sondern das direkt in irgendeinen geeigneten
> Buffer schreiben.
>
> Aber der Punkt mit Threadsicherheit ist gut - als Metaller denkt man da
> nicht sofort dran. Nicht heavy metal, sondern bare metal. ;-)


Genau, es ist explizit nach einem Test für Embedded gefragt, da zählt 
Kenntnisse in IRQ, und alles was man für Bare Metal braucht (BootUp 
Code, Systeminitialisierung). Um das zu prüfen ist das oben gezeigte 
Code schnipselchen nur partiell geeignet.

Vielleicht sollte man von Bewerber auflisten lassen, was zur essentialen 
Initialisierung eines Controllers gehört, also
-Stackpointer setzen
-Pin modes konfigurieren
-IRQ konfigurieren
-powermodes konfigurieren
-WDT enablen

und was der Bootloader so treibt.

Oder ist dergleichen aus dem Kenntnissschatz des heutigen Embedded 
Programmieres entschwunden?

Moin,

Nop schrieb:
> Ja wenn's fehlt, ist das Ergebnis des Lesens von c natürlich
> undefiniert. Mit static nicht, auch nicht wenn man das erst mit READ und
> dann mit WRITE aufruft, weil c eine globale Variable (mit lokalem Scope)
> ist, die gemäß C-Standard implizit mit 0 initialisiert wird.

Da frage ich jetz nochmal nach: Wo lebt 'c'? Das fiese an dem non-static 
szenario ist, dass die Routine sogar stabil laufen kann, wenn wir mal 
die Defaults aussen vor lassen, d.h. ein READ nach einem WRITE bringt 
immer das richtige Resultat, ausser, wenn... (oder gerade nur dann, 
wenn...)
Und was die Initialisierung angeht, meine Gegenfrage: In welchem Segment 
würde 'c' landen, und wäre sie wirklich 100% initialisiert? Wie 
nachprüfen?

Herbört schrieb:
> Hihi, stimmt, nützt eigentlich gar nix. Konkurrierende Schreibzugriffe
> können sich func immer noch gegenseitig unterbrechen. Da bräuchte es
> schon einen richtigen Mutex. Hat man den aber, dann ist das volatile
> bestenfalls nutzlos, sonst ein Zeitfresser.

Da käme dann die Frage, ob die Zugriffe noch atomisch (oder atomar) 
sind, aber das ist dann recht fortgeschritten und ginge auf die 
Architektur ein.

Herbört schrieb:
> Letztendlich ist das aber ein rein akademisches Beispiel. Ohne dass eine
> richtige Motivation da ist - warum sollte ich gerade im Embedded Umfeld
> - den Zugriff auf eine Variable kapseln? Deswegen: Weg mit mode, func,
> return, switch. Macht eine einfache Sache sinnlos kompliziert.

Nee, das ist überhaupt kein akademisches Ding, sogar sehr konkret aus 
einem bare-metal OS, natürlich in der auf 'lazy programming' 
runtergestrippten Fassung, aber im Prinzip läuft der Zugriff so. 
Ähnliches ist beim Dauerbrennerthema um Coroutinen oder Proto-Threads 
der Fall, wo man sich gerne und oft ähnlich ins Knie schiessen kann, und 
das viel weniger explizit als oben.


Ordner schrieb:
> Eigentlich nicht, entweder "braces stand alone" oder eben nicht. aber
> nie gemischt.

Wer konsequent nach K&R programmiert, unterscheidet eben genau so 
Funktionen von Statements, siehe Linux-Kernelsource. Und Linus' Dogma 
dürfte bekannt sein... Immer wieder ein nettes Thema.

Da gibt's noch so einen (auf die Gefahr hin, Öl ins Feuer zu giessen):

1

int func(void *p);

2

3

// oder

4

5

int func(void* p);

Bei div. Projekten gibt's automatisierte Erziehungsmethoden, dass der 
Code-Beauty-Checker schlicht die Annahme beim "svn commit" verweigert, 
wenn solche logischen Böcke drin sind.

Nur wenn jemand prinzipiell nur mit Emacs im (IMHO hinderlichen, da 
schlecht lesbar) Gnu-Coding style entwickeln will, kann man ihn 
höchstens noch zu einer brauchbaren Library mit sauber dokumentierter 
API motivieren, obige Erziehungsmethoden kommen dann nicht gut. Denn der 
Fall dass einer schreit, dass er den Code vom Kollegen aus der andern 
Liga nicht anfasst, gibt's halt doch öfters.

Das ist dann wieder ein anderes Thema: Wie kriegste raus, wie gut der 
Kollege im Team funktioniert oder nur SCRUM-Bullshit von sich gibt.

So am Rande: Vor ein paar Jahren wurde ich mal gefragt, wie ich im 'vi' 
einen Zeile einrücke. Fand die Frage gut, und die Antwort fand wohl auch 
der AG gut, d.h. 'PASS'.

Ordner schrieb:
> Genau, es ist explizit nach einem Test für Embedded gefragt, da zählt
> Kenntnisse in IRQ, und alles was man für Bare Metal braucht (BootUp
> Code, Systeminitialisierung). Um das zu prüfen ist das oben gezeigte
> Code schnipselchen nur partiell geeignet.

Ich finde es als 'fuzzy' Vortest schon mal gut, weil erstaunlich ist, 
wieviele hard-core Embedded-Hacker sich darin verirren. Das Thema mit 
dem IRQ/Threads lässt sich damit auch abhaken, siehe Herbörts Einwurf.

Hingegen lässt sich ein klassischer Embedded-Fragebogen gut auswendig 
lernen oder einfach Uni-Wissen/Arduino-Praxis wiedergeben.
Einen Target konfigurieren ist schliesslich "Datenblatt lesen". Aber 
Fehler aufspüren - das was im Projekt am meisten Risiko birgt - braucht 
ne Ecke mehr an tiefgehendem Verständnis.

Bei Berufsanfängern bietet es sich an, über die Masterarbeit zu sprechen 
(vorher darüber informieren!). Dort kann man dann auch rein fragen, wie 
was gelöst wurde und man erfährt dann schnell, ob der Bewerber nur 
oberflächliches Blabla kann oder auch technisch tief drinnen war während 
der Arbeit.

Herbört schrieb im Beitrag #5028392:
> Aber warum? Wenn jemand so einen Aufwand macht, dann hat das einen
> Grund. Und der muss gut sein um diese erhöhte Komplexität, Nachteile in
> nebenläufiger Verarbeitung und Inkaufnahme von
> Performanceverschlechterung zu rechtfertigen.

Es geht dabei eigentlich um Handler zu bspw. Betriebsparametern 
("Property handler"), eigentlich ein ganz aktuelles IoT-Thema. Sagen 
wir, du willst ein i2c-Register ins LAN exportieren und brauchst dazu 
ein Framework oder meinetwegen "OS". Wo sollen da oben die Nachteile 
sein? Der Zugriff ist genau an einem Ort geregelt und der Overhead eines 
Funktionsaufrufs ist wohl kaum der Rede wert...

Strubi schrieb:

> Da frage ich jetz nochmal nach: Wo lebt 'c'?

c ist eine globale Variable, deren Scope auf die Funktion begrenzt ist. 
Mit static liegt C nicht auf dem Stack, sondern im BSS-Segment (ZI), und 
das wird gemäß C-Standard genullt. Daher ist C, da static, sauber 
initialisiert, auch ohne explizites Nullen bei der Deklaration.

Dennoch würde ich explizit hinschreiben "static int c = 0", denn erstens 
ist c dann immer noch initialisiert, wenn man das static wegnimmt (das 
Lesen ergibt dann eben immer 0), und zweitens ist es freundlicher für 
nachfolgende Programmierer, wenn man Dinge explizit statt implizit 
macht.

Wenn der irgendwann unter hohem Zeitdruck einen Bug suchen muß, 
erleichtert es seine Arbeit, wenn er nicht auch noch die Implizitheiten 
des C-Standards dabei berücksichtigen muß.

> Und was die Initialisierung angeht, meine Gegenfrage: In welchem Segment
> würde 'c' landen, und wäre sie wirklich 100% initialisiert? Wie
> nachprüfen?

c landet im BSS-Segment, genauer gesagt unter ZI. Die Initialisierung 
prüft man daher einfach per Mapfile.

Man sollte natürlich außerdem auch seinen Startupcode prüfen, ob der den 
ZI-Bereich wirklich nullt und die Kopierschleife für die initialisierten 
globals beinhaltet.

Auf dem PC wird das von der Runtime automagisch gemacht, embedded ist 
das der Teil zwischen dem Sprung zum Resetvektor und dem Aufruf von 
main().

> Da gibt's noch so einen (auf die Gefahr hin, Öl ins Feuer zu giessen):
>
> int func(void *p);

So mache ich das immer. Denn dann weiß man daß der Stern zur Variablen 
gehört, und dann ist auch offensichtlich, daß bei

1

int *a, b;

b eben ein Integer und kein Pointer ist. In die Falle laufen übrigens 
auch gerne Leute rein, die Pointerstrukturen mit define statt typedef 
definieren. Wobei ich das trotzdem auf zwei Zeilen aufteilen würde, weil 
ich es lieber habe, wenn Pointer separat deklariert sind.

> Das ist dann wieder ein anderes Thema: Wie kriegste raus, wie gut der
> Kollege im Team funktioniert oder nur SCRUM-Bullshit von sich gibt.

Menschenkenntnis - das, was eine Führungspersönlichkeit am dringendsten 
braucht. Fachdetails muß sie nicht draufhaben, dafür stellt sie ja die 
Fachleute ein, aber schon genug Verständnis, um den Übeblick zu 
behalten.

> So am Rande: Vor ein paar Jahren wurde ich mal gefragt, wie ich im 'vi'
> einen Zeile einrücke. Fand die Frage gut, und die Antwort fand wohl auch
> der AG gut, d.h. 'PASS'.

LOL Nichts gegen Fun-Fragen, aber wenn da ein "ich hasse vi" zur 
Ablehnung geführt hätte, wären das dermaßen verkehrte Prioritäten, daß 
man da eh nicht würde anfangen wollen.

>
> LOL Nichts gegen Fun-Fragen, aber wenn da ein "ich hasse vi" zur
> Ablehnung geführt hätte, wären das dermaßen verkehrte Prioritäten, daß
> man da eh nicht würde anfangen wollen.

"Ich hasse xxx" hinterlässt natürlich keinen besonders guten 
Ersteindruck, was Teamfähigkeit etc. angeht. Ich würde es so 
formulieren: "Ein Editor ist ein Werkzeug, und ich interessiere mich 
mehr für das Ergebnis als das Werkzeug. Wenn ein Werkzeug eine 
Einarbeitungszeit von einem Monat benötigt, wo man in notepad++ zum 
Herausfinden derselben Funktionalität zwei Minuten benötigt, wird das 
Werkzeug zur Selbstbeschäftigung und damit zum Hindernis zur 
Produktentwicklung."

Hier gibt es zwei Möglichkeiten: Entweder man punktet mit Pragmatismus, 
oder man ist (wie Du schon selber schreibst) bereits in einem Umfeld 
angekommen, in dem die Selbstbeschäftigung Teil der Firmenkultur ist, 
und damit ist schon klar, dass es beidseitig nicht gut funzen wird.

gnugnu schrieb:

> "Ich hasse xxx" hinterlässt natürlich keinen besonders guten
> Ersteindruck, was Teamfähigkeit etc. angeht.

Ja gut, im Bewerbungsgespräch sollte man schon etwas auf Hochglanz 
machen für den ersten Eindruck, das stimmt. Bei KMUs allerdings 
erheblich weniger als bei Großkonzernen.


Dergute W. schrieb:

> Hm. Ein vi applet ist in busybox drinnen, von notepad++ oder eclipse
> applets hab' ich noch nix gehoert...

Das ist auch das Einzige, wozu ich vi überhaupt gelegentlich nutze - 
wenn ich mich z.B. per SSH irgendwo einwähle und da mal eben ein, zwei 
Settings in irgendeiner Konfig-Datei anpasse.

Für ernsthaftes Editieren finde ich das UI dermaßen daneben, daß ich die 
Datei lokal bearbeiten und dann hochladen würde. Einen Job, wo ich den 
ganzen Tag mit vi texten müßte, überlasse ich gerne vi-Liebhabern (die 
es ja auch gibt).

Bonuspunkte könnte man allerdings wohl sammeln, wenn man vi zu einfach 
findet und lieber gleich mit TECO loslegt. ;-)

Nop schrieb:
> Daher ist C, da static, sauber
> initialisiert, auch ohne explizites Nullen bei der Deklaration.

In der Praxis ist es auf vielen Plattformen nicht initialisiert, mir 
wäre neu, dass das der olle C-Standard abdeckt. Denn die Initialisierung 
des .bss is nicht Sache des Compilers sondern der crt0..

Nop schrieb:
> In die Falle laufen übrigens
> auch gerne Leute rein, die Pointerstrukturen mit define statt typedef
> definieren

Beim typedef kommt die 'falsche' Notation auch ab und an vor. Was man 
nach K&R wohl hören will, ist, dass die Philosophie von C die einer 
Prototypen-orientierten Sprache ist. Demnach gehört der *-Dekorator zur 
Variable und nicht zur Datentyp-Deklaration.

Konrad schrieb im Beitrag #5028470:
> Ein i2c Register ins Lan exportieren zu wollen halte ich eigentlich
> ohnehin für einen Fail. Das ist zu low-level und müsste eher durch ein
> höheres Protokoll gekapselt werden.

Tja, genau das macht das Framework, und da macht der asynchrone 
Co-Routinen-Ansatz Sinn, das Snippet sieht dann allerdings komplexer 
aus, da gibts dann nich mehr READ/WRITE sondern QUEUE/POLL, usw. Aber 
das ginge jetzt zu sehr ins Detail. Macht euch bloss nich ins Hemd, es 
ist nur ein Beispiel. Aber offenbar auch ein ergiebiges, wie die 
Diskussion zeigt. Und die Frage "warum so kompliziert" somit voll 
legitim.


Nop schrieb:
> LOL Nichts gegen Fun-Fragen, aber wenn da ein "ich hasse vi" zur
> Ablehnung geführt hätte, wären das dermaßen verkehrte Prioritäten, daß
> man da eh nicht würde anfangen wollen.

Ich glaube, du verkennst die Prioritäten :-)
Das "Hass"-Wort kommt schnell mal von den Wohlfühlprogrammierern mit 
grossem Ego, die sich früher oder später als wenig teamfähig 
herausstellen. Aber lieber ehrlich als irgend ein aufgesetztes 
Google-Blabla, dann weiss man gleich Bescheid.
Schlussendlich will halt der "Chef", dass du in dem Firmenoekosystem 
"funktionierst". Wenn nicht, passt's eben nicht, dafür vielleicht 
woanders.

Wie kann man überhaupt auf die Idee kommen mit dieser vi-Frage auf die 
Fähigkeiten des Bewerbers zu schliessen? Welche Liebslingfarbe hat ihr 
Mauspad wäre genauso dämlich. Das ist ja sowas von strunzedoof.  Da 
sitzt wohl der Fail auf der anderern Seite des Tisches. 
Bewerbungsgespräche führen sollte man auch können, die andere Seite 
überschätzt sich hier regelmässig masslos und es werden die dümmsten 
Fragen mit dubiosen Begründungen gerechtfertigt.

Ich halte auch diese Testfragen mit Codesnippets usw. für wenig 
aussagekräftig. Daran scheitere ich meist auch obwohl ich die Thematik 
intus habe, lediglich die fremde Situation verwirrt mich mehr unter der 
sie stattfinden. Sitze ich an einer IDE und code an einem realen Projekt 
fallen solche Fehler sofort auf und mache sie erst gar nicht.

Ob einer was taugt merkt man innerhalb der Probezeit an einem realen 
Projekt, diese einstündigen Kaspereien im Bewerbungssgespräch sagen 
absolut nix aus und auch fehl am Platz wenn sich einer mit 5 Jahren 
passender Entwicklererfahrung bewirbt, da gilt es doch nur noch zu 
schauen ob der menschlich ins Team passt, ne Nervensäge ist oder 
nicht,... und auch das kann man nur zuverlässig herausfinden wenn man 
mit dem mal drei Wochen unter Realbedingungen arbeitet.

Diese ganze Bewerbungszirkus ist doch heute völlig aus dem Ruder 
gelaufen, der reinste Affenzirkus ist das nur noch.

Michael H. schrieb:
> Gibt es irgendwas, um abzuchecken, dass Leute wirklich embedded
> Programmieren können?

Ja. Einfach mal 1-2 Tage lang kommen und ein kleines Funprojekt 
durchziehen lassen. Ein Thermometer mit einer gemultiplexten LED-Anzeige 
wäre ein nettes Beispiel. Zur Erweiterung lässt man zusätzlich noch eine 
einfache Uhrenfunktion einbauen.

Ruhig reichlich Beispielcode bereitstellen, so dass man sich die Lösung 
daraus weitestgehend zusammenbasteln kann. Man kann auch ein günstiges 
Eval-Board zum Einarbeiten zu Hause bereitstellen.

Der TE meldet sich nicht mehr zu Wort. Ich muss sagen, dass der Kollege 
hier überrannt, überfordert wurde.

Sicherlich hat er sich etwas ungeschickt ausgedrückt. Und man kann davon 
ausgehen, dass er kein Techniker ist. Aber autentische Antworten gibt es 
nun zu genüge. Jetzt muss der Kollege gucken, was er damit anfangen 
kann.

My 2 Cent:

Ich würde mir einen Techniker dazu holen, der den Bewerber etwas auf den 
Zahn fühlen kann. Wenn der AG vom TE eine große AG ist, dann kann man 
sich sicherlich auch leisten, nur nach Spitzenkanditaten zu gucken, da 
wäre der Personaller aber sicherlich etwas professioneller und würde 
nicht in so einem Forum nach Antworten suchen. Ansonsten muss nehmen was 
kommt und ggf. einfach  mal investieren. Dabei sollte man sich im Umgang 
mit den qualifizierten Fachkräften nicht allzu doof anstellen, denn imho 
sind die schneller wieder weg, als einem lieb ist.

Die Bezahlung ist hier nur ein Argument von vielen(Arbeitsklima, 
Kollegen, Aufgabengebiet, Verantwortung, Karriere....)

Strubi schrieb:

> In der Praxis ist es auf vielen Plattformen nicht initialisiert

Auf welchen genau? Klar, wenn man embedded einen kaputten Startup-Code 
hat, dann kann man solche Probleme schonmal haben. Dann wird aber auch 
explizite Initialisierung nicht mehr weiterhelfen, auch nicht explizit 
mit 0 initialisieren.

Denn der Compiler verfrachtet globale Variablen, die explizit mit 0 
initialisiert werden, auch ins ZI-Segment. Es wird also nicht im ROM der 
Init-Wert 0 abgelegt, und diese Variablen werden auch nicht in der 
Kopierschleife im Startup initialisiert. Spart halt ROM.

Die explizite Initialisierung mit 0 richtet sich lediglich an 
nachfolgende Maintenance-Programmierer, der Übersicht halber.

> wäre neu, dass das der olle C-Standard abdeckt. Denn die Initialisierung
> des .bss is nicht Sache des Compilers sondern der crt0..

Der C-Standard weiß nichts von Stack und BSS und wer da was umsetzt, der 
beschreibt nur Verhalten.

Section 6.7.8 Initialization of C99 standard (n1256):

If an object that has automatic storage duration is not initialized 
explicitly, its value is indeterminate. If an object that has static 
storage duration is not initialized explicitly, then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned) 
zero;
— if it is an aggregate, every member is initialized (recursively) 
according to these rules;
— if it is a union, the first named member is initialized (recursively) 
according to these rules.

> Schlussendlich will halt der "Chef", dass du in dem Firmenoekosystem
> "funktionierst". Wenn nicht, passt's eben nicht, dafür vielleicht
> woanders.

In einem Ökosystem, in dem man ernsthaft vi als Entwicklungsumgebung 
benutzen muß, möchte ich auch gar nicht funktionieren. Es ist dann für 
beide Seiten gut, wenn man sich da so frühzeitig einig wird, daß man 
nicht zusammenpaßt.

Was hingegen durchaus OK ist, das ist der Pin-Debugger, die 
embedded-Entsprechung des altehrwürdigen printf-Debuggers.

Klaus Maus schrieb:
> Diese ganze Bewerbungszirkus ist doch heute völlig aus dem Ruder
> gelaufen, der reinste Affenzirkus ist das nur noch.

Like....;-)

Schreiber schrieb:

> Ja. Einfach mal 1-2 Tage lang kommen und ein kleines Funprojekt
> durchziehen lassen.

Klar doch. Urlaub nehmen zum Probearbeiten.

Klaus Maus schrieb:
> Ich halte auch diese Testfragen mit Codesnippets usw. für wenig
> aussagekräftig. Daran scheitere ich meist auch obwohl ich die Thematik
> intus habe, lediglich die fremde Situation verwirrt mich mehr unter der
> sie stattfinden. Sitze ich an einer IDE und code an einem realen Projekt
> fallen solche Fehler sofort auf und mache sie erst gar nicht.

Also wer in einem Schnupperinterview nicht in der Lage ist ohne 
Computeraufbereitung Quelltexte zu verstehen , kann das sicher auch 
nicht mit IDE-Unterstützung im Büro voll mit Störgeräuschen und unter 
Projektdruck.

> schauen ob der menschlich ins Team passt, ne Nervensäge ist oder
> nicht,... und auch das kann man nur zuverlässig herausfinden wenn man
> mit dem mal drei Wochen unter Realbedingungen arbeitet.

Ooch, unter wohldosierten Stress zeigen die Bewerber ihr wahres Gesicht. 
Und bei manchen genügt die Vorstellung mit dem vi arbeiten zu dürfen zu 
einer veritablen Stresssituation. Die Frage ist, wie handelt der 
Bewerber bei bevorstehenden Kontrollverlust - agiert er iritiert, 
ratlos, verängstigt? Oder bleibt er professionell und handelt rational 
nach seinen Möglichkeiten (sucht proaktiv Hilfe oder Alternative 
Lösungen).

Ordner schrieb:
> Oder bleibt er professionell und handelt rational
> nach seinen Möglichkeiten (sucht proaktiv Hilfe oder Alternative
> Lösungen).

"Proaktiv". Die rationale Lösung ist, sich eine andere Firma zu suchen, 
in der man nicht mit Steinzeittools arbeiten muß, und in der man auch 
nicht schon beim Einstellungstest mit Psychospielchen beharkt wird.

Kurzum, Firmen, in denen der Fachkräftemangel nicht schon in der 
Personalabteilung anfängt.

Das sind übrigens dann Firmen, in denen man sich eher für detailierte 
Kenntnisse des C-Standards als für vi-Fähigkeiten interessiert. ;-)

Falk B. schrieb:

> Dem TMS320/PICCOLO von TI.

Da das im Startupcode reingehört, liegt es beim Entwickler, für eine 
C-Standard-konforme Umgebung zu sorgen.

Das sind ein paar Zeilen Assembler in der Resetroutine, und die muß man 
als embedded-Entwickler auch problemlos schreiben können, weil das 
Programm embedded nicht erst bei main() beginnt.

Die Note von TI sagt das auch ganz deutlich. Andere C-Compiler wie 
beispielsweise GCC tun das ebenfalls nicht, weil es nicht der Job des 
Compilers ist.

Als embedded-Entwickler darf man sich ohnehin nicht auf den vom 
Hersteller gelieferten Democode verlassen, weil der meistens nur zur 
Verdeutlichung des manuals dient und nicht als production code.

Das ist eben einer der Unterschied zwischen Entwicklung auf dem PC und 
embedded, jedenfalls für bare-metal embedded. Mit einem OS wie embedded 
Linux braucht man sich darum natürlich nicht zu kümmern, weil man da 
eine crt hat, die das tut.

> Doch, zumindest bei TI, denn die explizit initialisierten Variablen
> werden initialisiert.

Nur die, welche man im Quelltext als Anweisungen initialisiert, oder 
auch die, welche schon bei der Definition initialisiert werden?

Strubi schrieb:
> Nop schrieb:
>> Bei vielen Opensource-Projekten: durch Ignorieren. Siehe hier:
>>
> 
https://betanews.com/2015/04/20/why-the-open-source-software-model-is-fundamentally-broken/
>
> Kompletter nonsense-Artikel von den ersten Zeilen weg (TL;DR). Sorry.
> Opensource heisst nicht kostenlos, das wissen Firmen durchaus.

Im Gegenteil, sehr schlüssig, gehaltvoll, sorgfältig mit Quellen und 
funktionierenden links belegt. Wer solche Urteile meint fällen zu dürfen 
wie Du, sollte sich schon einer genau so gewissenhaften, glaubhaften und 
sorgfältig recherchierten Argumentationsweise bemühen. Das Wegwischen 
mit einem scheinbar einzig und Allein auf Grund deiner anderen Meinung 
beruhenden Pauschalsatz qualifiziert nicht.

Nop schrieb:
> "Proaktiv". Die rationale Lösung ist, sich eine andere Firma zu suchen,
> in der man nicht mit Steinzeittools arbeiten muß, und in der man auch
> nicht schon beim Einstellungstest mit Psychospielchen beharkt wird.
>

Ehrlich gesagt höre ich lieber noch "hasse vi". Wer einen aktuellen 
'gvim' als Steinzeittool bezeichnet, hat ein bisschen was verpasst.
Ich erwarte von einem Kandidaten, dass er schon mal effizient coden kann 
und mir nicht Eclipse-Code-Completion als Geschwindigkeitsvorteil 
verkauft..
Im beschriebenen Fall auf der anderen Seite der Nahrungskette hatte die 
Frage eine ganz andere Motivation als die meisten hier so zu denken 
scheinen, ich lasse das aber mal offen.

> Kurzum, Firmen, in denen der Fachkräftemangel nicht schon in der
> Personalabteilung anfängt.
>
> Das sind übrigens dann Firmen, in denen man sich eher für detailierte
> Kenntnisse des C-Standards als für vi-Fähigkeiten interessiert. ;-)

Im konkreten Fall dieser Firma interessiert man sich auch dazu noch 
dafür, ob jemand die Feinheiten zwischen ELF-Standard (.bss) und 
C-Standard kennt und in der Lage ist, beweisbaren, robusten Code zu 
entwickeln.
Das andere ist Handwerkszeug, und ja, wer seine Liebe zu Emacs 
glaubwürdig demonstriert, darf auch Emacs.

Klaus Maus schrieb:
> Diese ganze Bewerbungszirkus ist doch heute völlig aus dem Ruder
> gelaufen, der reinste Affenzirkus ist das nur noch.

Der Affenzirkus ist nötig geworden, weil einer Menge Leute mit 1.0 
Abschluss einiges an Kenntnissen fehlt. Das Geschichten-Fass mach ich 
mal gar nicht auf...
Nur ist die Gegenmassnahme in den HR-Abteilungen total pervertiert 
worden (meinetwegen zu "Psychospielchen"). Im Prinzip will man 
non-intrusiv provozieren, weiss nur manchmal nicht ganz, wie, oder es 
kommt als so misstrauensdotiert rüber, dass man gleich rückwärts ausm 
Raum rollen möchte.
Aber im Gegenzug ist es damit auch ganz legitim, den Arbeitgeber ebenso 
zu provozieren und früh abzuklopfen, wie er mit der Waffe Humor als 
Konfliktlösungsmethode umgehen kann, oder rein mit Hierarchie-Gehorsam 
und Druck operiert oder sich die religiösen Egos in einem akademischen 
Kindergarten austoben. Als Fachspezi, den man unbedingt haben muss, hat 
man allenfalls einen gewissen Guru-Heimvorteil, aber man ist auch als 
erster weg, wenn die Firma mal einen Neustart machen muss oder verkauft 
wird, oder es mit den Egos eskaliert.
Wir hatten mal einen Frischling angestellt, der zunächst fachlich so 
mittel schien, aber v.a.: schön rotzfrech (aber nicht arrogant) und 
eiserne Nerven bei den pythonesquen Fragen. War bereichernd.
So abgesehen davon: Der Job soll ja auch Spass machen.

gnugnu schrieb:
> Im Gegenteil, sehr schlüssig, gehaltvoll, sorgfältig mit Quellen und
> funktionierenden links belegt. Wer solche Urteile meint fällen zu dürfen
> wie Du, sollte sich schon einer genau so gewissenhaften, glaubhaften und
> sorgfältig recherchierten Argumentationsweise bemühen. Das Wegwischen
> mit einem scheinbar einzig und Allein auf Grund deiner anderen Meinung
> beruhenden Pauschalsatz qualifiziert nicht.

Sagen wir mal so: Es ist mir zu blöd, Edition 20 eines überlangen 
Beitrags zum Linuxkindergarten, der sich zudem noch einzelne Sachen 
rauspickt um journalistische Qualität zu suggerieren, im Detail zu 
kommentieren. Ist sowieso Off topic.
Wenn so eine aufmerksamkeits-erheischende Überschrift, dann will ich 
auch was zu GNU und Konsorten lesen. Sonst wisch ich's - mit Verlaub - 
weg.

Falk B. schrieb:

> Unsinn!! Das muss der Hersteller der Toolchain liefern!

Nein, denn für den Startupcode ist man nunmal selber verantwortlich. 
Genau wie für Interruptroutinen und sowas. Das ist halt embedded, sehr 
hardwarenah.

> Ob ich das KANN ist gar nicht die Frage, sondern ob ich es WILL!!! Warum
> soll sich JEDER Compilernutzer immer wieder um den gleich Krümelkram
> kümmen. Außer irgendwlechen Freaks will das keiner!

Weil der Startupcode auch immer wieder andere Sachen beinhaltet, ist ja 
nicht nur das Speichernullen. Alles, was man vor main() so braucht.

> Bei mir meistens schon, und das hat gereicht. Die wenigsten Anwendungen
> müssen sich ihren eigenen Startup-Code selber schnitzen. Wozu?

Weil man bei bare metal die volle Kontrolle über das System hat und 
deswegen aber auch für alles verantwortlich ist.

Hat man embedded Linux, dann geht das natürlich allein schon von der 
Menge her nicht mehr, das ist klar.

> Toll. Denkst du, ich les mir erst SÄMTLICHE Doku durch, ehe ich anfange?

Nee, aber ich würde erwarten, daß Du den Startupcode, sofern welcher 
mitgeliefert wird, Dir erstmal durchliest, um das kennenzulernen. Da 
geht das Programm schließlich los. Wenn da keine Nullungsschleife ist, 
dann ist das doch offensichtlich.

Man darf von einem Entwickler doch erwarten, sein Arbeitswerkzeug zu 
kennen. Embedded ist eben hardwarenah und nicht wie auf dem PC. Doku 
nicht lesen, Code nicht lesen und sich dann beschweren, daß was nicht 
läuft.. merkwürdig.

Ich lese ja bei einem Projekt mit unbekannter Hardware auch erstmal das 
Datenblatt des Controllers, Programming Manual mitsamt Befehlssatz und 
Erratasheets. Normal.

> Auch die, welche bei der Definition initialisiert werden.

Dann muß ja jedenfalls die Kopierschleife implementiert sein. Ist das in 
irgendner crt, die nur als Objektcode da ist, oder ist das 
Assembler-Startupcode?

Strubi schrieb:

> Ich erwarte von einem Kandidaten, dass er schon mal effizient coden kann
> und mir nicht Eclipse-Code-Completion als Geschwindigkeitsvorteil
> verkauft..

Das ist doch völlig irrelevant, weil beim Coden nicht die 
Tippgeschwindigkeit entscheidend ist.

> Im konkreten Fall dieser Firma interessiert man sich auch dazu noch
> dafür, ob jemand die Feinheiten zwischen ELF-Standard (.bss) und
> C-Standard kennt

Nunja, daß selbiger die Initialisierung nunmal vorschreibt, was sich 
dann in der Implementierung z.B. im BSS-Segment äußert, ist nunmal so. 
Übrigens sagen viele Leute, mich eingeschlossen, auch dann BSS, wenn es 
gar nicht ELF ist. "better save space" ;-)

> und in der Lage ist, beweisbaren, robusten Code zu entwickeln.

Jepp. Wobei das Coden noch die vergleichsweise einfache Tätigkeit ist. 
Viel schwieriger ist es, festzulegen, was genau denn implementiert 
werden soll, und welche Wechselwirkungen es dabei mit anderen Systemen 
gibt.

> Der Affenzirkus ist nötig geworden, weil einer Menge Leute mit 1.0
> Abschluss einiges an Kenntnissen fehlt. Das Geschichten-Fass mach ich
> mal gar nicht auf...

Och menno, gerade wo es unterhaltsam werden könnte. :-)

> Im Prinzip will man
> non-intrusiv provozieren, weiss nur manchmal nicht ganz, wie, oder es
> kommt als so misstrauensdotiert rüber, dass man gleich rückwärts ausm
> Raum rollen möchte.

Da kann man mit ein wenig Phantasie viel bessere Ergebnisse erzielen. 
Wenn die Simulation lautet "Chef macht mich saublöd an", ist meine 
Reaktion "der hat Führungsdefizite".

Was aber realistisch sein kann: aufgebrachte Kunden. Aufgebracht, weil 
das Produkt nicht funktioniert, wie es soll. Die sind aber nicht einfach 
nur psycho, und das muß man daher auch nicht demütigst erdulden, sondern 
da gibt's einen realen Kern.

In so einem Fall kann man den Kunden erstmal da abholen, wo er steht, 
ihm das Gefühl geben, daß er ernstgenommen wird, und dann das Gespräch 
auf die technische Ebene führen. Also laß mal nen Kollegen, der so einen 
Kunden simuliert, im Besprechungsraum anrufen. Und das dann auch gleich 
noch auf englisch.

Sapperlot W. schrieb:
> Der Frage des Posters nach zu urteilen, wollen sie den Billigsten, da
> sie eh keine Ahnung haben. Das wird auf die Laenge dann der Teuerste.
> Denn der muss wahrscheinlich alleine durch die ganze Lernkurve.

Nur die harten kommen in den Garten. Ungeklärt ist, welche süssen 
Früchte den Ankömmling im Garten denn erwarten.

Übrigens, mal interessehalber gefragt, falls noch Leute mitlesen, die 
sowas mitentscheiden -  wenn ein Bewerber ein nennenswertes 
embedded-Projekt in Opensource vorweisen kann:

- Würdet Ihr Euch das überhaupt näher anschauen?
- Worauf würdet Ihr achten?
- Würdet Ihr Euch wirklich die Mühe machen, auch Sourcen anzusehen, um 
einen Eindruck von den Fähigkeiten zu bekommen?
- Falls ja, worauf würdet Ihr dabei schauen?
- Welche Rolle würde Doku spielen?
- Wäre Github ausreichend, oder wäre eine dedizierte Webseite 
vorzuziehen?
- Falls Letzteres, wäre auch das eigentlich ja recht themenfremde 
Webdesign ein Kriterium?
- Falls ja, inwiefern?

Klaus Maus schrieb:

> Ich halte auch diese Testfragen mit Codesnippets usw. für wenig
> aussagekräftig. Daran scheitere ich meist auch obwohl ich die Thematik
> intus habe, lediglich die fremde Situation verwirrt mich mehr unter der
> sie stattfinden.
>
> Ob einer was taugt merkt man innerhalb der Probezeit an einem realen
> Projekt, diese einstündigen Kaspereien im Bewerbungssgespräch sagen
> absolut nix aus und auch fehl am Platz wenn sich einer mit 5 Jahren
> passender Entwicklererfahrung bewirbt,

Ganz ehrlich, wer mit 5 Jahren Berufserfahrung im Vorstellungsgespräche 
keinen fehlerfreien Code schreiben kann, ist als Programmierer Scheiße 
oder hat über seine Berufserfahrung gelogen.
Bei einem Absolventen ist das vielleicht noch verständlich, aber nach 
1000 Arbeitstagen mit regelmäßigen Code-ungang nicht.

Und es ist einfach diese Fehlleistung abzustellen. Täglich eine Stunde 
Code ohne Hilsmittel schreiben, dann hat man das nach ein paar Wochen 
drauf und kommt auch unter Bewerbungs-Stress klar. Ganz nervöse Fälle 
sollen sich von Arzt was für die Beruhigung verschreiben lassen.

Berufsrevolutionär schrieb:
> Klaus Maus schrieb:
>
>>
>> Ob einer was taugt merkt man innerhalb der Probezeit an einem realen
>> Projekt, diese einstündigen Kaspereien im Bewerbungssgespräch sagen
>> absolut nix aus und auch fehl am Platz wenn sich einer mit 5 Jahren
>> passender Entwicklererfahrung bewirbt,
>
> Ganz ehrlich, wer mit 5 Jahren Berufserfahrung im Vorstellungsgespräche
> keinen fehlerfreien Code schreiben kann, ist als Programmierer Scheiße
> oder hat über seine Berufserfahrung gelogen.
> Bei einem Absolventen ist das vielleicht noch verständlich, aber nach
> 1000 Arbeitstagen mit regelmäßigen Code-ungang nicht.
>

Definiere "fehlerfrei." Wenn Deine Aussage wahr wäre, gäbe es in 
Betrieben, in denen ausschliesslich oder federführend erfahrene 
Programmierer sitzen, keine bugs mehr. Faszinierend. In DIE Parallelwelt 
möchte ich mal reinschnuppern.

Ordner schrieb:
> Computeraufbereitung Quelltexte zu verstehen , kann das sicher auch
> nicht mit IDE-Unterstützung im Büro voll mit Störgeräuschen und unter
> Projektdruck.
Ist eher die prüfungsartige Situation, da gehen bei mir die Rolläden 
runter. Ob es im Büro laut ist stört mich eher weniger, das hat mich zu 
Anfangszeiten mal genervt bin da inzw. relativ schmerzfrei, ausser ein 
Handwerker malträtiert irgendwo im Haus mit ner Hilti den ganzen Tag die 
Wände.

Klaus Maus schrieb:
> Ist eher die prüfungsartige Situation, da gehen bei mir die Rolläden
> runter. Ob es im Büro laut ist stört mich eher weniger, das hat mich zu
> Anfangszeiten mal genervt bin da inzw. relativ schmerzfrei, ausser ein
> Handwerker malträtiert irgendwo im Haus mit ner Hilti den ganzen Tag die
> Wände.

Ok, da stimme ich voll zu, Prüfungssituationen nerven, ev. bis zum 
Trauma (nicht ironisch gemeint).
Genau da liegt der feine Grat zwischen Psychospiel und nettem Interview.
Das meinte ich ansich mit "non-intrusiv": Den Kandidaten "messen", aber 
nicht negativ beeinflussen, sich aber im Gegenzug auch nicht blenden 
lassen. Ich denke, sowas geht, auch mit so einem unauffällig plazierten 
Codesnippet. Wenn sich alle einig sind, dass es kein wahr oder falsch 
gibt und man sich nur kennenlernen möchte, ist ne Menge Druck raus.

Nop schrieb:
> Das ist doch völlig irrelevant, weil beim Coden nicht die
> Tippgeschwindigkeit entscheidend ist.

Naja, wenn einer umständlich mit Maus und Rechtsklick anfängt, Code zu 
kopieren, und 'YP' zu kryptisch findet...
Das meine ich eben mit Handwerkszeug und das merkt man dann in den 
heissen Phasen ("Hackathon" an der Anlage) schon.

Nop schrieb:
>> Der Affenzirkus ist nötig geworden, weil einer Menge Leute mit 1.0
>> Abschluss einiges an Kenntnissen fehlt. Das Geschichten-Fass mach ich
>> mal gar nicht auf...
>
> Och menno, gerade wo es unterhaltsam werden könnte. :-)

Mach doch n neuen Thread auf. Einen hab ich in kurz, allerdings nur aus 
erster Hand: Kollege hatte einen PhD vor sich sitzen, der das Ohmsche 
Gesetz nicht zusammenbekam. (War wohl kein Einzelfall).

Klaus Maus schrieb:
> Ordner schrieb:
>> Computeraufbereitung Quelltexte zu verstehen , kann das sicher auch
>> nicht mit IDE-Unterstützung im Büro voll mit Störgeräuschen und unter
>> Projektdruck.
> Ist eher die prüfungsartige Situation, da gehen bei mir die Rolläden
> runter. Ob es im Büro laut ist stört mich eher weniger, das hat mich zu
> Anfangszeiten mal genervt bin da inzw. relativ schmerzfrei, ausser ein
> Handwerker malträtiert irgendwo im Haus mit ner Hilti den ganzen Tag die
> Wände.

Aber irgendwie musst Du schon Deine prinzipielle Eignung bei der 
Vorstellung nachweisen!
Kein Fahrprüfer gibt dir  nach verpatzter Prüfungsfahrt den Führerschein 
nur auf die bloße Beteuerung hin, das du nur zum Prüfungstermin versagst 
aber die anderen 364 Tage des Jahres brillierst.

Und wer weis was die Prüfungspanik in Dir auslöst und ob diesen Auslöser 
sicher eliminierten kann. Manchen genügt das Bewusstsein das andere 
jederzeit die Arbeit begutachten könnten und stürzen deshalb in 
Versagensängste ab.

J. W. schrieb:
> Es kam mal ein sehr guter Bewerber, der schon beim Herumführen in der
> Abteilung sagte (beim Interview war ich nicht dabei), was hier alles
> suboptimal ist, und was er viel besser machen würde (modernere
> SW-Tools).

Ein Entwickler der auf modische SW-Tools setzt um es besser zu machen, 
ist nicht gut. (abgeleiteter Schluß aus dem Grundsatz "A fool with a 
tool is still a fool").

Ordner schrieb:
> Ein Entwickler der auf modische SW-Tools setzt um es besser zu machen,
> ist nicht gut.

Japp. Deswegen stanzen wir auch immer noch Lochkarten. Weil, das haben 
wir schon immer so gemacht.

Rumple schrieb:
> Ordner schrieb:
>> Ein Entwickler der auf modische SW-Tools setzt um es besser zu machen,
>> ist nicht gut.
>
> Japp. Deswegen stanzen wir auch immer noch Lochkarten. Weil, das haben
> wir schon immer so gemacht.

Nö, deswegen benutzen wir gcc und Shell-script weil die uns die 
Kontrolle übern den Code und Effizienz wiedegeben, die uns die 
Comfort-IDE für Voll-dummies genommen haben.


Und wissen das es nicht die Tools sind die die Software besser macht 
sondern der gescheite Umgang mit diesen. Und das diese Lernprozess nicht 
mit dem bloßen Einkauf/Installation von SW-Gizmos abgeschlossen ist, 
sondern das dann die eigentliche Arbeit erst beginnt.

Le X. schrieb:
> Aber die meisten Entwickler sind hinter der gewohnten IDE besser
> aufgehoben, von wo aus sie die bereits eingerichteten Skripte und Tools
> bequem erreichen.

Ja, und dann kommt ein

> ein sehr guter Bewerber, der schon beim Herumführen in der
> Abteilung sagte (beim Interview war ich nicht dabei), was hier alles
> suboptimal ist, und was er viel besser machen würde (modernere
> SW-Tools).

Also nicht nur Änderungen an Optionen im Buildscript sondern gleich das 
gesamte Entwicklungssystem aus dem Fenster kippen!?
Wie ich schon eingangs sagte "A fool with a tool is still a fool".

> Denn dann weiß man daß der Stern zur Variablen
> gehört, und dann ist auch offensichtlich, daß bei
> int *a, b;
> b eben ein Integer und kein Pointer ist.

Das ist ein Bug der Sprache C.
Java war da schlauer.

gnugnu schrieb:
> Berufsrevolutionär schrieb:
>> Klaus Maus schrieb:
>>
>>>
>>> Ob einer was taugt merkt man innerhalb der Probezeit an einem realen
>>> Projekt, diese einstündigen Kaspereien im Bewerbungssgespräch sagen
>>> absolut nix aus und auch fehl am Platz wenn sich einer mit 5 Jahren
>>> passender Entwicklererfahrung bewirbt,
>>
>> Ganz ehrlich, wer mit 5 Jahren Berufserfahrung im Vorstellungsgespräche
>> keinen fehlerfreien Code schreiben kann, ist als Programmierer Scheiße
>> oder hat über seine Berufserfahrung gelogen.
>> Bei einem Absolventen ist das vielleicht noch verständlich, aber nach
>> 1000 Arbeitstagen mit regelmäßigen Code-ungang nicht.
>>
>
> Definiere "fehlerfrei."

Syntaktisch fehlerfrei, der Compiler spuckt keinen Error. Das sollte man 
schon nach 5 Jahren BE ohne Nutzung von Syntaxhighlight, Code 
vervollstandigung oder code templates drauf haben. Und die 50 
meistgebrauchten functions aus der std-library.

Und Funktional fehlerfrei ist auch kein Hexenwerk, da muss man halt 
Methoden des  Software testing kennen und stur requirements umsetzen 
können.

> Wenn Deine Aussage wahr wäre, gäbe es in
> Betrieben, in denen ausschliesslich oder federführend erfahrene
> Programmierer sitzen, keine bugs mehr.

naja Softwarequalität ist Teamleistung, eine faule Traube bspw Tester 
der Regressiontests vermeidet und der wein istverdorben. Oder die Spec 
hat Fehler resp. ist unvollständig. Oder die verwendete Software hat 
Fehler. Oder die Umgebung wurde falsch spezifiziert (Arien5 BuG) Oder, 
oder. Implementierung ist halt nur eine Phase der Entwicklung deshalb 
fällt auch aus

> Faszinierend. In DIE Parallelwelt
> möchte ich mal reinschnuppern.

Dann schau mal in die Programmierbuden von sicherheitskritischer 
Software (Raumfahrt, Medizintechnik) oder liess dich in die DO-178 ein. 
"Failure is not an Option".

Ich stelle auch den Anspruch fehlerfreien Code zu schreiben. Dazu bedarf 
es den Code aus einem Guss zu schreiben, und alles aufs Mal zu 
verstehen. Und nicht eine Library Funktion zu verwenden, die sich etwa 
so nennt wie ich es mir vorstelle.
Nach der N+1-ten Aenderung ist man wieder beim Spaghetti Code. Dann 
sollte man's eben nochmals neu schreiben.
In der Entwicklungsphase verwende ich natuerlich den Watchdog nicht, 
sonst wuerde ich einen Fehler ja nicht unbedingt finden.

Nop schrieb:
>> Ja. Einfach mal 1-2 Tage lang kommen und ein kleines Funprojekt
>> durchziehen lassen.
>
> Klar doch. Urlaub nehmen zum Probearbeiten.
Für jedes Bewerbungsgespräch benötigt man effektiv (inklusive 
An+Abreise) mindestens 2 Tage Urlaub. Ob man dann jetzt noch einen 
dritten Tag benötigt oder nicht, macht zeitlich und preislich den Kohl 
nicht fett.
Davon abgesehen, ein einfaches Thermometer mit LED-Anzeige sollte an 
einem Tag programmiert sein.

Wir verwenden einfache Arduino-Boards und 7-Segment-LEDs mit variabler 
Anschlussbeschaltung (über Steckbrücken). Erforderd etwas mitdenken, ist 
aber kein Hexenwerk. Etwas Bitbanging, etwas wackeln an den Pins und 
Timer oder Interrups sollte man auch schon mal "gesehen" haben.
Für den Temperatursensor sollte man wissen, was "Spannungsteiler" und 
"AD-Wandler" sind. Etwas Hauptschulmathemathik dazu und schon ist es 
fertig...
Wer sich nicht ganz doof anstellt, der schafft das mit 100-200 Zeilen 
Code.

J. W. schrieb:
> Schreiber schrieb:
>> Ja. Einfach mal 1-2 Tage lang kommen und ein kleines Funprojekt
>> durchziehen lassen.
>
> Es geht aber bei einer Bewerber-Entscheidung auch die Leute zu finden,
> die das Potential zum Programmierer haben, aber noch nicht haben, weil
> sie gerade das Studium beendet haben und die Programmierfähigkeiten noch
> nicht entwickelt haben.
> Die könnten so ein Fun-Projekt allerdings nicht durchziehen.

Etwas Arduino-Code sollte auch ein Anfänger zusammennageln können. 
Verstehen, und erklären(!!!), was der Code macht, sollte man auch 
können.
Als Alternativen steht richtiges C, Bascom oder Assembler zur Verfügung. 
Bei Fragen darf Kollege Google konsultiert werden.

Wer das nicht kann: Üben, und zwar zu Hause, oder einen anderen Beruf 
suchen!

Berufsrevolutionär schrieb:
>
> Und Funktional fehlerfrei ist auch kein Hexenwerk, da muss man halt
> Methoden des  Software testing kennen und stur requirements umsetzen
> können.
>

naja, der fundamentale Fehler dieser Denkweise ist sicherlich schon eine 
Million Mal diskutiert worden, also ist das 1 Mio+1. jetzt auch egal:

Du MEINST "konform zur Spezifikation," schreibst aber "fehlerfrei," was 
etwas völlig Anderes ist und etwas impliziert, was es praktisch nicht 
geben kann, nämlich fehlerfreie Software.

Und damit relativiert sich schon eine ganze Menge, denn erstens steht 
und fehlt damit die faktische Qualität der Software mit der Qualität der 
Spezifikation sowie der Vollständigkeit der Testmatrix. Zweitens ist 
selbst die Konformität zu einer bestehenden Spezifikation nur in 
trivialen Fällen tatsächlich beweisbar. In den meisten praktisch 
vorkommenden Fällen kann man sich dem nur annähern. Selbst wenn in der 
Spec steht "bestanden, wenn das System ohne crash x Stunden durchläuft," 
kann Niemand garantieren, dass dasselbe System nicht nach x Stunden und 
einer Sekunde abschmiert, also genau nachdem der Test "erfolgreich" 
abgebrochen wurde.

Die Puristen reagieren dann darauf, indem sie nicht deterministische 
Konditionen einfach verbieten. Das geht natürlich, aber damit reduzierst 
Du wieder die "beweisbar fehlerfreien Systeme" auf nur einen sehr 
kleinen Bruchteil der heutzutage praktisch nutzbaren Systeme.

Also klar: Du programmierst Satelliten, an die man nicht mehr rankommt, 
sobald sie im Orbit sind. Dafür verzichtest Du auf Alles, was nicht 
deterministisch ist, also Nebenläufigkeit, Kommunikation, dynamische 
Speicherverwaltung, vermutlich sogar Interrupts. So ein System lässt 
sich tatsächlich deterministisch als "fehlerfrei" im Sinn von 
"spezifikationskonform" bezeichnen, wenn eine passende Testmatrix 
definiert wurde. Macht auch Sinn.

Allerdings ist die Menge der Systeme, die auf die Art und Weise 
funktionieren, verschwindend gering. Es gibt z.B. heutzutage so gut wie 
keine Computersysteme mehr, die nicht in irgendeiner Form mit Anderen 
Systemen kommunizieren, und damit kommen nicht mehr komplett testbare 
asynchrone Faktoren ins Spiel.

Und letztendlich diktiert leider (ob das gut ist oder nicht) die 
wirtschaftliche Pragmatik die Entwicklungszyklen, d.h. in den 
Allerwenigsten Projekten sind die Kapazitäten da, die Anforderungen (die 
sich dann auch oft genug während der Entwicklungsphase ändern) in eine 
saubere Spezifikation und eine hinreichende Testmatrix umzusetzen, 
geschweige denn die Testmatrix auch durchzuziehen. Und das hat absolut 
nix mit Frickelbuden zu tun. Patch Days und periodische Updates gibt's 
bei den grossen Herstellern genauso wie bei den Kleinen, und WENN es 
möglich WÄRE, im grossen Stil saubere und fehlerfreie Software zu 
produzieren, dann hätten wir nicht Dinge wie Heartbleed.

Schreiber schrieb:

> Für jedes Bewerbungsgespräch benötigt man effektiv (inklusive
> An+Abreise) mindestens 2 Tage Urlaub.

Wenn man vorhat umzuziehen schon. Sonst reicht einer. Es fallen ja auch 
schon etliche Firmen beim Vorstellungsgespräch durch.

Kritische Fragen sind, wie der Entwicklungsprozeß aussieht, wie 
Change-Management gemacht wird, wie das Config-Management geht, welchen 
Stellenwert Dokumentation denn so hat. Da kommen Frickelbuden ganz 
schnell ins Schwimmen, und der Gesichtsausdruck des Chefs verfinstert 
sich zusehends.

> Wir verwenden einfache Arduino-Boards und 7-Segment-LEDs mit variabler
> Anschlussbeschaltung (über Steckbrücken).

Gibt's Bonuspunkte für die Frage nach ESD-Armbändern? ^^

> Etwas Arduino-Code sollte auch ein Anfänger zusammennageln können.

Äh, nee, könnte ich nicht. Weil ich mich mit dem Framework überhaupt 
nicht beschäftigt habe - ich sehe auch keinen Sinn darin. Aber gut, Du 
bietest ja auch C an.

Abgesehen davon halte ich den ganzen Ansatz aus meiner Sicht aber für 
ineffizient. Man bewirbt sich ja nicht nur bei einer Firma, und ich 
werde sicherlich nicht für mehrere Firmen exzessiv Urlaub für 
Probearbeiten nehmen. Zumal sich bei jeder Firma ja auch nicht nur einer 
um einen Job bewirbt.

Das stiehlt mir zuviel von meiner Zeit, und dann auch noch kostbare 
Urlaubszeit. Effizienter ist es, mal ein cooles Projekt zu machen, dazu 
eine Webseite aufzusetzen und gut. Die Firmen, die auf Arbeitsproben 
stehen, können sich das dann selber angucken.

Das skaliert besser für mich, und außerdem kann man dann auch ein 
Projekt machen, auf das man selber richtig Lust hat, UND das weitaus 
komplexer als ein LED-Thermometer sein darf.

Le X. schrieb:

> Du hast keine Ahnung was Change Management überhaupt ist.

Wovon ich Ahnung habe, davon weißt Du nichts, und wahrscheinlich nicht 
nur davon nicht. Danke, weitergehen.

Strubi schrieb:
> Ganz toll ist es dann, wenn nach 'nuernberger' die Nerds mit einbezogen
> werden, die Pi auf 240 Stellen auswendig können und eine
> Wahnsinns-Menschenkenntnis zur Schau stellen.

Yup, so Vögel zelebrieren es dann richrig einen zu befragen und ihre 
tatsächliche odet vermeintliche Fachkenntnis zur Schau zu stellen. Ob 
man sich damit ein Bild über Fähigkeiten des Bewerbers machen kann, ist 
eine andere Frage. Wer in der besonderen Situation eines 
Bewerbungsgesprächs spontan keine Fragen aus einem weiten Feld 
beantworten kann ist deshalb nicht unfähig. Wer überzeugend Scheiße 
labern kann ist deshalb nicht fähig.

gnugnu schrieb:
>  und WENN es
> möglich WÄRE, im grossen Stil saubere und fehlerfreie Software zu
> produzieren, dann hätten wir nicht Dinge wie Heartbleed.

Gerade Heratbleed zeigt aber das fehlerfreie Software möglich ist. Der 
Bug Auto -ein Doktorand aus Münster- vergass die Überprüfung einer 
Eingangsvariable (Bufferlänge) und ein Review des Codes fand nicht 
statt. Der Autor bezeichnet den Fehler als "normal" und nicht als 
"schwerwiegend".

Wären die Basics der Softwareentwicklung:
 -Überprüfung der Eingangsparamter
 -definierte/kontrolliert Freigabeprozeduren für Code
 -Qualitätskontrolle kritischer Änderungen durch review

beachtet worden, wäre dieses Schnüffel-Scheunentor nie entstanden. Die 
selbstgefällige Schlamperei eines Autors und das blinde Vertrauen der 
Maintainer auf Qualitäten eines ihnen nicht persönlich bekannten Coders 
machten das möglich.

Methoden zur Fehlerbeseitigung muss man nicht nur kennen sondern auch 
Konsequent umsetzen.

Berufsrevolutionär schrieb:
>
> Wären die Basics der Softwareentwicklung:
>  -Überprüfung der Eingangsparamter
>  -definierte/kontrolliert Freigabeprozeduren für Code
>  -Qualitätskontrolle kritischer Änderungen durch review
>
> beachtet worden, wäre dieses Schnüffel-Scheunentor nie entstanden. Die
> selbstgefällige Schlamperei eines Autors und das blinde Vertrauen der
> Maintainer auf Qualitäten eines ihnen nicht persönlich bekannten Coders
> machten das möglich.
>

Hier führst Du aus, dass EINE Fehlerkategorie durch Etablierung und 
Beachtung von Prozessoren zum Teil eliminiert werden kann. Mag sein, 
aber daraus zu schliessen, dass "fehlerfreie Software möglich" ist ist 
falsch (sh. z.B. meine vorherigen Ausführungen über asynchrone 
Konditionen in heterogenen Umfelden, die niemals weder spezifiziert noch 
hinreichend getestet werden können). Der Begriff "eingekapselt 
spezifikationskonform" wäre eine wesentlich bessere Formulierung als 
"fehlerfrei."

> Methoden zur Fehlerbeseitigung muss man nicht nur kennen sondern auch
> Konsequent umsetzen.

Klar. In einer idealen Welt gäbe es auch keine Kriege, Seuchen oder 
Helene Fischer. Die interessante Frage ist allerdings die: WENN es wie 
Du sagst möglich WÄRE, "fehlerfreie" Software zu produzieren, warum 
gehören dann nach wie vor Bugs in jeglicher Form und coleur zum 
täglichen Alltag, selbst wenn es für Softwarequalität Lehrstühle, 
Studiengänge und FDachkongresse bis zum Notarzteinsatz gibt? 
Offensichtlich scheint es ja nicht trivial möglich zu sein, die 
Voraussetzungen für "fehlerfreie Software" zu schaffen, denn die 
Controller sind ja auch nicht immer ganz dumm und würden eine Menge 
dafür tun, den Folgeaufwand für Fehler vermeiden zu können?

So einfach wie Du es Dir denkst ist es nicht, und das kann hier 
sicherlich Jed/r aus dem Arbeitsalltag bestätigen.

Nop schrieb:
> Übrigens, mal interessehalber gefragt, falls noch Leute mitlesen,
> die
> sowas mitentscheiden -  wenn ein Bewerber ein nennenswertes
> embedded-Projekt in Opensource vorweisen kann:
>
> - Würdet Ihr Euch das überhaupt näher anschauen?
> - Worauf würdet Ihr achten?

Ich hatte schon ein paar Bewerber mit Open Source-Projekten auf github 
(wenn auch nicht im embedded-bereich). Ich hab mir 10 Minuten genommen 
da mal reinzuschauen (ist der Aufbau und Code halbwegs sauber, arbeiten 
noch andere an dem Projekt, wie kommuniziert der Bewerber mit den 
Mitarbeitern), und dann den Bewerber darauf angesprochen um den 
Hintergrund (Motivation) für das Projekt zu erfahren. Details zur 
Programmierstil, -sprache waren da weniger interessant, die kann man 
lernen.

Ein Bewerber hat an einem größeren Open Source Projekt mitgearbeitet, 
neue Features implementiert, Code Reviews organisiert, usw. - das war 
für mich und die anderen an der Einstellung beteiligten ein klarer 
Pluspunkt. Da es auch einige Negativpunkte im Gespräch gab, würde ich 
sagen dass das letztendlich den Ausschlag gegeben hat den Bewerber doch 
zu nehmen.

> - Würdet Ihr Euch wirklich die Mühe machen, auch Sourcen anzusehen, um
> einen Eindruck von den Fähigkeiten zu bekommen?

Nur oberflächlich, das frisst zu viel Zeit, und ohne den genauen Kontext 
zu kennen in dem das Projekt entstanden ist hilft das wenig.

> - Wäre Github ausreichend, oder wäre eine dedizierte Webseite
> vorzuziehen?

Also ich hätte weniger Lust mich durch eine selbst designte Webseite 
durchzuklicken.

gnugnu schrieb:
> Klar. In einer idealen Welt gäbe es auch keine Kriege, Seuchen oder
> Helene Fischer. Die interessante Frage ist allerdings die: WENN es wie
> Du sagst möglich WÄRE, "fehlerfreie" Software zu produzieren, warum
> gehören dann nach wie vor Bugs in jeglicher Form und coleur zum
> täglichen Alltag, selbst wenn es für Softwarequalität Lehrstühle,
> Studiengänge und FDachkongresse bis zum Notarzteinsatz gibt?

Ganz einfacher Kostenfaktor oder einfach Bequemlichkeit, die letzten 10m 
zum Ziel tun am meisten weh. Sicher kommt dazu, dass gute/aktuelle 
Testmethoden als weniger "cool" gelten als AO (Agile Onanie). Ich habe 
von diesen Studiengängen nicht so nen guten Eindruck, und was z.B. an 
der Embedded World Conference zu Safety-Aspekten verzapft wird, ist 
teils grobe Marketing-Kamelkacke.
Schlussendlich will der Kunde immer mehr 'billig' und Bananagammelware 
wie zB ein esp8266-SoC gilt dann halt als Messlatte.

> Offensichtlich scheint es ja nicht trivial möglich zu sein, die
> Voraussetzungen für "fehlerfreie Software" zu schaffen, denn die
> Controller sind ja auch nicht immer ganz dumm und würden eine Menge
> dafür tun, den Folgeaufwand für Fehler vermeiden zu können?

Es ist doch eigentlich nicht so höllisch kompliziert, die Siliziumwerker 
machen das täglich, weil dort halt ein Fehlschuss aufm Wafer teurer wird 
als das halbe Jahr Testbench-Entwicklung.
So kann man schon mit geeigneten Software-Techniken und Tools, die über 
lint/MISRA hinausgehen, richtig robuste SW machen, die beweisbar gut 
funktioniert, z.B. angefangen mit malloc-Debuggern (oder gleich eigene 
Pools für seine Objekte anlegen), valgrind, oder die Krönung, gleich das 
ganze Programm zyklengenau bis auf die Hardware runter 
simulieren/verifizieren.
Würde mich interessieren, ob jemand eine Uni/FH kennt, die sowas 
intensiv vermittelt.

P.S. Lass die Helene Fischer doch singen. ("Fehlerlooos, ausgelacht..")

gnugnu schrieb:

> Hier führst Du aus, dass EINE Fehlerkategorie durch Etablierung und
> Beachtung von Prozessoren zum Teil eliminiert werden kann. Mag sein,
> aber daraus zu schliessen, dass "fehlerfreie Software möglich" ist ist
> falsch (sh. z.B. meine vorherigen Ausführungen über asynchrone
> Konditionen in heterogenen Umfelden, die niemals weder spezifiziert noch
> hinreichend getestet werden können). Der Begriff "eingekapselt
> spezifikationskonform" wäre eine wesentlich bessere Formulierung als
> "fehlerfrei."

Blabla -> ich sage, wenn der Doktorand nach den (Grund-)Regeln 
programmiert hätte, wäre der Fehler erst nicht entstanden. Da brauchst 
keine gescheit klingende Formulierung wie "eingekapselt 
spezifikationskonform" sondern eine klare Ansage:
-der "Autor" von Bleeding heart hat geschlampt.
-und der maintainer hat seine Kontrollpflichten gröblichst missachtet

>> Methoden zur Fehlerbeseitigung muss man nicht nur kennen sondern auch
>> Konsequent umsetzen.
>
> Klar. In einer idealen Welt gäbe es auch keine Kriege, Seuchen oder
> Helene Fischer. Die interessante Frage ist allerdings die: WENN es wie
> Du sagst möglich WÄRE, "fehlerfreie" Software zu produzieren, warum
> gehören dann nach wie vor Bugs in jeglicher Form und coleur zum
> täglichen Alltag, selbst wenn es für Softwarequalität Lehrstühle,
> Studiengänge und FDachkongresse bis zum Notarzteinsatz gibt?

Offensichtlich willst Du nicht verstehen, weil das ja genau in dem Satz 
oben drüber steht. Die Bugs gehören zur Realität weil die menschen die 
die Bugs programmieren menschliche Schwächen haben und aus 
unprofessionellen Gründen wie Faulheit, Begriffsstutzigkeit, fehlenden 
Arsch in der Hose, Selbstherrlichkeit die simplen Regeln zur 
Fehlervermeidung ignorieren. Das sind nicht selten die, die im VG keinen 
beispielcode fehlerfrei hinschreiben können und auch auf Nachfrage nach 
praktischen Fehlervermeidungstaktiken nur akadmisch anmuteten Scheiss 
absondern.

> Offensichtlich scheint es ja nicht trivial möglich zu sein, die
> Voraussetzungen für "fehlerfreie Software" zu schaffen, denn die
> Controller sind ja auch nicht immer ganz dumm und würden eine Menge
> dafür tun, den Folgeaufwand für Fehler vermeiden zu können?

sagte ich bereits, Fehlerfreiheit ist Teamleistung, was nützte der beste 
controller wenn der "programmierer" einen Bug nach dem anderen 
einschleust und dann so tut als wäre das ganz normal.

> So einfach wie Du es Dir denkst ist es nicht, und das kann hier
> sicherlich Jed/r aus dem Arbeitsalltag bestätigen.

Doch es ist so einfach: Die Fehler werden von den unfähigen 
Programmierer gemacht und nicht von irgendwelchen bösen Schicksalmächten 
als strafende Plage auf die Menschheit losgelassen. Und genau das 
Aussortieren diese Unfachkräfte ist Zweck des in diesem Threads 
eröterten Eignungstest.

Le X. schrieb:

> Aus dem Kontext schließe ich

Engineering Change Management, meine Güte, man kann sich auch anstellen. 
Praktisch sagt man change management auch im engineering. Die deutschen 
Begriffe kenne ich da nicht einmal, das stimmt, weil die ganzen 
Dokumente ohnehin allesamt auf englisch sind.

Die Frage an sich ist auch eher eine Fangfrage - um rauszubekommen, ob 
man in jeder Projektphase noch mit Änderungswünschen zugekippt wird, bis 
man das nur noch als "rabid pprototyping" (nein, kein Tippfehler) 
bezeichnen kann.

Strubi schrieb:


> Schlussendlich will der Kunde immer mehr 'billig' und Bananagammelware
> wie zB ein esp8266-SoC gilt dann halt als Messlatte.

Nicht jeder Kunde, aber es sind diese Billigheimer-Kunden die die ganze 
Entwicklerszene versauen. Und da kann ich Linus's Tobsuchtssuchtsanfall 
und Steve Jobs Ausraster schon verstehen, wenn sie es im Programmieren 
zu tun haben, die Stringenz und Perfektion für verzichtbar halten. 
https://www.youtube.com/watch?v=-90iRQbd0fg

> Es ist doch eigentlich nicht so höllisch kompliziert, die Siliziumwerker
> machen das täglich, weil dort halt ein Fehlschuss aufm Wafer teurer wird
> als das halbe Jahr Testbench-Entwicklung.

Ja, kenn ich und andere Beispiele. methoden und tools für die 
Entwicklung sichere/robuster Software sind bekannt (wurde 
https://www.oreilly.de/buecher/120174/9783897215672-weniger-schlecht-programmieren.html 
oder DO-178 schon erwähnt ?!) und nicht wirklich kompliziert.


> So kann man schon mit geeigneten Software-Techniken und Tools, die über
> lint/MISRA hinausgehen, richtig robuste SW machen, die beweisbar gut
> funktioniert, z.B. angefangen mit malloc-Debuggern (oder gleich eigene
> Pools für seine Objekte anlegen), valgrind, oder die Krönung, gleich das
> ganze Programm zyklengenau bis auf die Hardware runter
> simulieren/verifizieren.
> Würde mich interessieren, ob jemand eine Uni/FH kennt, die sowas
> intensiv vermittelt.

Mich auch, oder direkt formuliert, ich glaube das wird an keiner 
Hochschule gelehrt sondern das lernt man nur im Beruf weil da Fehler 
einbauen und nicht beheben richtig weh tut.

Tobias P. schrieb:

> * hier ist ein 30 zeilen code snippet, welche Fehler finden sie?
> * schreiben sie einen algorithmus, welcher die gesetzen bits in einem
> vektor zählt. * wie bringen sie eine led mit frequenz x oder duty cycle
> y zu blinken, welche verschiedenen realisierungswege gibt es, welche vor
> und nachteile hat jeder?
>
> Schülerkram ist. Sowas hat man im Studium machen müssen, um den Zettel
> zu bekommen.

--
> * was für projekte haben sie in der vergangenheit realisiert, welche
> probleme hatten sie, wie sind sie die probleme angegangen und wie haben
> sie diese gelößt.
>
> * etwas näher über die fähigkeiten aus dem
> lebenslauf/bewerbungsschreiben ein gehen,

Naja, bei einem Absolventen oder Azubi-bewerber führen diese Fragen 
zwangsläufig auf die zuerst als "Affenzitkus" betitelten Fragen.

Und Berufserfahrene und die dafürgehalten werden wollen, legen sich vor 
dem VG irgendein problem zurecht das sie angeblich heldenhaft bewältigt 
haben. Und schmücken dann im VG die Fähigkeiten die sie in CV beschönigt 
haben noch verbal aus.

Berufsrevolutionär schrieb:
> Doch es ist so einfach: Die Fehler werden von den unfähigen
> Programmierer gemacht und nicht von irgendwelchen bösen Schicksalmächten
> als strafende Plage auf die Menschheit losgelassen. Und genau das
> Aussortieren diese Unfachkräfte ist Zweck des in diesem Threads
> eröterten Eignungstest.

Das ist Unsinn! Ich programmiere jetzt seit mehreren Jahrzehnten in 
vielen Sprachen mit selbständigem beruflichem Hintergrund - ich gehe 
also davon aus, dass ich irgendetwas richtig mache oder zumindest nicht 
schlechter als all die anderen Fachkräfte, die für unser aller 
Software-Angebot mitverantwortlich sind. Und ich versichere Dir, dass 
fehlerfreier Programmcode ab einem gewissen Komplexitätsgrad absolut 
normal ist und nur bedingt mit der Expertise des Programmierers zu tun 
hat. Ein schlechter Programmierer wird zweifellos überwiegend 
fehlerhafte Programme schreiben, aber von einem fehlerhaften Programm 
auf einen unfähigen Programmierer zu schließen, zeugt nur von einem 
fehlenden Bezug zur realen Welt deinerseits. Wer schon mal unter realen 
Bedingungen Software entwickelt hat, der weiß, dass es da noch etwas 
mehr gibt, als die reine Lehre vom sauberen und fehlerfreien 
Programmieren.

Ob das nun ein Mangel an Ressourcen ist, an sportlichen Deadlines vom 
Vertrieb liegt, oder der Art der Entwicklung geschuldet ist, ist dabei 
völlig unerheblich. Am Ende ist immer entscheidend, wie viel Druck auf 
dem einzelnen Programmierer lastet bzw. ob er die Zeit hat, seine Arbeit 
vernünftig zu leisten. Das ist vielleicht kein Schicksal, aber es hat 
sicherlich in erster Linie etwas mit unserer Gesellschaft zu tun, auf 
die der Einzelne nur wenig Einfluss nehmen kann. Als Selbständiger habe 
ich auch schon Aufträge abgelehnt, weil der Auftraggeber der Meinung 
war, die von mir veranschlagte Zeit für Fehlersuche und Absicherung 
gegen Angriffe wären reiner Luxus. Und ich bin auch schon oft genug auf 
meine Kappe vom vereinbarten Pfad abgewichen und habe etwas aufwändiger 
programmiert als zunächst notwendig, einfach, weil ich aus Erfahrung 
wusste, dass das, was der Auftraggeber zunächst kategorisch 
ausgeschlossen hat, sowieso im späteren Projekt-Verlauf als völlig 
überraschende Änderung nachgereicht wird. Das kann man dann ganz regulär 
nachberechnen und man muss nicht das ganze Konzept überdenken. Aber als 
Angestellter kann man sich gegen so etwas nicht so leicht wehren bzw. 
man hat nicht den selben Handlungsspielraum. Und bei größeren Projekten 
werden auch oft genug (Teil-)Aufträge an Externe vergeben und spätestens 
da ist dann alles verloren, sofern man die dadurch vermeintlich 
eingesparte Zeit nicht durch intensive Reviews wieder auffressen möchte.

Und nur mal so: Da ich hobbymäßig mit µCs arbeite, könnte ich mich 
vortrefflich mit jemandem über CAN, I2C, Interrupts, Timer, PWM, etc. 
unterhalten. Ob das aus mir einen erfahrenen Embedded-Entwickler macht, 
lässt sich dadurch aber auch nicht sagen.
Es geht ja teilweise auch darum, WIE fest jemand im Sattel sitzt bzw. 
wie lange man für bestimmte Aufgaben benötigt. Mit diesen Tests filtert 
man höchstens die Totalversager oder mit etwas Pech diejenigen, die zwar 
fachlich kompetent sind, aber durchaus unter so einer Art Lampenfieber 
leiden. Ich halte es für sinnvoller, wenn sich auf AG-Seite jemand mit 
dem Bewerber unterhält, der von den geforderten Dingen wirklich Ahnung 
hat. Und zwar nicht wie bei einem Tribunal, sondern nur diese beiden 
Personen in lockerer Atmosphäre. Der würde recht schnell merken, ob da 
mehr als nur heiße Luft dahinter ist - ganz ohne diese erniedrigenden 
Assessment-Tests.

Strubi schrieb:

> Es ist doch eigentlich nicht so höllisch kompliziert, die Siliziumwerker
> machen das täglich, weil dort halt ein Fehlschuss aufm Wafer teurer wird
> als das halbe Jahr Testbench-Entwicklung.

Ja, aber Du vergisst dabei, dass die Siliziumwerker in einem Anderen 
Universum arbeiten. Für die endet die Welt an ihrem Waferrand. Das ist 
jetzt keine Kritik oder Geringschätzung, es geht auch nicht Anders. Ein 
Siliziumwerker kann jedes Staubkorn im durch seinen Platinenrand 
begrenzten Universum Gradgenau ausrcihten. Das ist seine Aufgabe. Das 
Universum mit Anderen Universen zu verbinden ist die Aufgabe der 
Firmwareentwickler, und damit ändern sich die Regeln!

> oder die Krönung, gleich das
> ganze Programm zyklengenau bis auf die Hardware runter
> simulieren/verifizieren.

Jetzt haben wir es! Was nützt Dir eine zyklengenaue Simulation, wenn 
deine Firmware an einem Netzwerk hängt (und von deren Ereignissen 
mitgesteuert wird), in dem weder das Timing noch die Folge von 
einkommenden Ereignissen noch völlig von der Problemstellung komplett 
unabhängige Drittereignisse wie Broadcaststürme vorhergesagt werden 
können? Oder Kommunikationspartner mal offline gehen oder sich selber 
durch subtile andere Interpretation von Vorgaben (z.B. andere 
Implementation von Protokollspezifikationslücken) unvorgesehen 
verhalten? Wie willst Du das simulieren? Alle möglichen Kombinationen 
von Nullen und einsen im DMA Pufferspeicher durchnudeln? Wie willst Du 
guten Gewissens eine kommunizierende Software schreiben, wenn Du weisst, 
dass da draussen Dutzende von verschiedenen Geräten sind, die Alle etwas 
Anders funktionieren (das Problem jedes Webserverherstellers in Grün)?

Ich sage nicht, dass deswegen alle Firmwareentwicklung in Gottes Hand 
liegt. Aber die rein elektrotechnische Sichtweise "man muss nur Alles 
gut genug und genau genug spezifizieren und seine lineare Testmatrix 
anwenden, und damit sind alle Fehlerquellen abgedeckt" hilft bei der 
Fírmwareentwickluiung über den Platinenrand hinaus nicht weiter. Da muss 
man komplett Andere Wergzeugkisten öffnen.

> Würde mich interessieren, ob jemand eine Uni/FH kennt, die sowas
> intensiv vermittelt.
>

Mich auch, speziell das intensiv vermittelt, was genau zwischen die 
Stühle der Hardware- und Softwareentwicklung fällt.

Gonzo schrieb:
> Berufsrevolutionär schrieb:

> , aber von einem fehlerhaften Programm
> auf einen unfähigen Programmierer zu schließen, zeugt nur von einem
> fehlenden Bezug zur realen Welt deinerseits.

Realitätsverlust? So so, schon mal selbst versucht die Realität hinter 
dem Heartbleedzu recherchieren? Sicher nicht, sonst wuesstest Du da der 
Autor nicht nur einen Fehler in dem Stack hinterlassen hat:

https://www.heise.de/security/meldung/Noch-mehr-Herzbluten-bei-OpenSSL-2217286.html
http://www.netz-trends.de/id/3229/Hacker-Wer-ist-Robin-Seggelmann-der-Heartbleed-Ausloeser/

Und nicht irgendwelche Tippfehler wie if (a=0) oder dreher in der 
argumentenreihenfolge, sondern willentliches weglassen der Prüfung der 
Buffergröße.

Vielleicht sollte man es umformulieren, vielleicht hat ist er vom 
Fach-KnowHow her fähig , er ist trotzdem unfähig weil es ihm an der 
nötige Sorgfalt und Verantwortungsgefühl mangelt. Er verlässt sich 
einfach drauf das im prtotcolheader immer nur erlaubte Werte stehen. Ist 
IMHO ein typisches Problem vom Programmieren die nur den akademischen 
Eifelturm kennen.

Gonzo schrieb:

>
> Ob das nun ein Mangel an Ressourcen ist, an sportlichen Deadlines vom
> Vertrieb liegt, oder der Art der Entwicklung geschuldet ist, ist dabei
> völlig unerheblich. Am Ende ist immer entscheidend, wie viel Druck auf
> dem einzelnen Programmierer lastet bzw. ob er die Zeit hat, seine Arbeit
> vernünftig zu leisten.

Ein Programmiere brauch eben auch den Arsch in der Hose den code nicht 
zum release freizugebeb wenn er nicht seinen Job fertig machen konnte. 
Das nennt man eigenveratwortliches Arbeiten.

Am Ende des Tages muss mit einem Produkt auch Geld verdient werden und 
dafür bleibt nur endliche Zeit. Man kann Perfektion anstreben, aber 
nicht erreichen.
Und wer sich ernsthaft hinstellt und behauptet er könne ein mittleres 
Softwareprojekt komplett bugfrei programmieren (wenn nur <insert reason 
here>), der entlarvt sich einfach als realitätsferner Dampfplauderer.
Warum sich nun an Heartbleed so hochgezogen wird, verstehe ich nicht; ja 
da wurden ein paar grundlegende Prinzipien der Softwareentwicklung grob 
verletzt und das hat sich übel ausgewirkt, aber eine Nichtverletzung 
führt trotzdem nicht automatisch zu richtigem Code.
Spätestens wenn sich das erste Requirement ändert, fängt der Spaß an ;)

Abradolf L. schrieb:
> Am Ende des Tages muss mit einem Produkt auch Geld verdient werden
> und
> dafür bleibt nur endliche Zeit. Man kann Perfektion anstreben, aber
> nicht erreichen.

man KANN Software entwickeln, deren Fehlerfreiheit formal beweisbar ist. 
Kostet aber Geld, sehr sehr viel Geld.

Berufsrevolutionär schrieb:
> Ein Programmiere brauch eben auch den Arsch in der Hose den code nicht
> zum release freizugebeb wenn er nicht seinen Job fertig machen konnte.
> Das nennt man eigenveratwortliches Arbeiten.

Nicht sicherheitsrelevante Funktionen kann man als Firmwareupdate 
nachliefern.

Berufsrevolutionär schrieb:
> Und nicht irgendwelche Tippfehler wie if (a=0) oder dreher in der
> argumentenreihenfolge, sondern willentliches weglassen der Prüfung der
> Buffergröße.

Das willentlich unterstellst Du jetzt aber einfach mal so. Hast Du Dir 
Deine eigenen Links mal durchgelesen? Es war laut seinen eigenen 
Aussagen ein Flüchtigkeitsfehler. Oder anders ausgedrückt: Eigentlich 
weiß er es besser, aber man denkt eben nicht immer an alles. Ist jetzt 
jeder Autofahrer, der nur einmal verschuldet einen Unfall verursacht, 
ein inkompetenter Idiot? Sicherlich genau so wenig wie der Programmierer 
des Heartbleed Bugs!
Menschen machen Fehler, eben weil wir nicht wie Maschinen funktionieren. 
Das 4-Augen-Prinzip gibt es nicht, weil alle außer Papa inkompetent 
sind, sondern weil jeder Mensch mit nur etwas Lebenserfahrung weiß, dass 
man trotz größter Sorgfalt immer mal etwas übersehen oder vergessen 
kann. Der im Arbeitsleben real vorhandene Stress gepaart mit Ablenkung 
verstärken diese Problematik noch zusätzlich. Von daher bestätigst Du 
nur einmal mehr, dass Du nicht viel von der Softwareentwicklung in der 
realen Welt verstehst.

Berufsrevolutionär schrieb:
> Ein Programmiere brauch eben auch den Arsch in der Hose den code nicht
> zum release freizugebeb wenn er nicht seinen Job fertig machen konnte.
> Das nennt man eigenveratwortliches Arbeiten.

In der Theorie gebe ich Dir recht, in der Praxis findet das so leider 
nur selten statt und hat nichts mit "Arsch in der Hose" zu tun. Der 
Heartbleed Bug ist aufgrund seiner Auswirkungen ein besonders 
gefährlicher Fehler und hätte mich persönlich schon aus 
haftungsrechtlichen Gründen (Vulgo: Vorsatz) auch als mitwissenden 
Arbeitnehmer dazu veranlasst, diesen Code nicht zum Release freizugeben. 
Aber wir reden sowohl bei Heartbleed als auch überall sonst in der 
Praxis ja über Fehler, die noch gar nicht gefunden worden sind und die 
sich diskussionstechnisch gefühlt hundert mal schwieriger rechtfertigen 
lassen. Da hängt es dann eher davon ab, ob Dein Vorgesetzter 
IT-Technisch kompetent ist und nicht ob Du als Programmierer es bist. 
Sieh doch einfach mal ein, dass auch als absolut kompetent geltende 
Menschen ab und an Fehler machen - vielleicht nicht so häufig wie 
imkompetente, aber es muss nur der falsche Fehler zur falschen Zeit 
auftreten und schon entwickelt sich daraus eine Desaster und erinnert 
uns daran, dass keiner von uns unfehlbar ist.

Schreiber schrieb:
> Abradolf L. schrieb:
>> Am Ende des Tages muss mit einem Produkt auch Geld verdient werden
>> und
>> dafür bleibt nur endliche Zeit. Man kann Perfektion anstreben, aber
>> nicht erreichen.
>
> man KANN Software entwickeln, deren Fehlerfreiheit formal beweisbar ist.
> Kostet aber Geld, sehr sehr viel Geld.
>

Nein. Nicht für jedes Problem. DAS ist formal beweisbar! Wurde auch 
schon vor gut über 50 Jahren bewiesen!

Mal ganz abgesehen davon, dass selbst der Begriff der "Fehlerfreiheit" 
äusserst debattierbar ist.

gnugnu schrieb:
> Strubi schrieb:
>
>> Es ist doch eigentlich nicht so höllisch kompliziert, die Siliziumwerker
>> machen das täglich, weil dort halt ein Fehlschuss aufm Wafer teurer wird
>> als das halbe Jahr Testbench-Entwicklung.
>
> Ja, aber Du vergisst dabei, dass die Siliziumwerker in einem Anderen
> Universum arbeiten. Für die endet die Welt an ihrem Waferrand. Das ist
> jetzt keine Kritik oder Geringschätzung, es geht auch nicht Anders. Ein
> Siliziumwerker kann jedes Staubkorn im durch seinen Platinenrand
> begrenzten Universum Gradgenau ausrcihten. Das ist seine Aufgabe. Das
> Universum mit Anderen Universen zu verbinden ist die Aufgabe der
> Firmwareentwickler, und damit ändern sich die Regeln!
>

Nein, das ist eben in manchen Fällen nicht mehr so, z.B. wenn ein 
DSP-ASIC entworfen wird. Dann werden schnell mal die Brücken zw. HW und 
SW geschlagen und du musst dich als SW-Entwickler an ein paar Dinge 
"gewöhnen".


>> oder die Krönung, gleich das
>> ganze Programm zyklengenau bis auf die Hardware runter
>> simulieren/verifizieren.
>
> Jetzt haben wir es! Was nützt Dir eine zyklengenaue Simulation, wenn
> deine Firmware an einem Netzwerk hängt (und von deren Ereignissen
> mitgesteuert wird), in dem weder das Timing noch die Folge von
> einkommenden Ereignissen noch völlig von der Problemstellung komplett
> unabhängige Drittereignisse wie Broadcaststürme vorhergesagt werden
> können? Oder Kommunikationspartner mal offline gehen oder sich selber
> durch subtile andere Interpretation von Vorgaben (z.B. andere
> Implementation von Protokollspezifikationslücken) unvorgesehen
> verhalten? Wie willst Du das simulieren? Alle möglichen Kombinationen
> von Nullen und einsen im DMA Pufferspeicher durchnudeln? Wie willst Du
> guten Gewissens eine kommunizierende Software schreiben, wenn Du weisst,
> dass da draussen Dutzende von verschiedenen Geräten sind, die Alle etwas
> Anders funktionieren (das Problem jedes Webserverherstellers in Grün)?
>

Das Stichwort ist "Co-Simulation". Und ja, genau der ganze Krempel wird 
in der Schleife mit teils realen Daten oder pseudozufälligen 
Timing-Szenarien verifiziert. Natürlich simulierst du nicht beliebige 
Komplexität bis auf dem untersten Level, das macht keinen Sinn. D.h. für 
einen MAC muss ich nur zB "beweisen", dass die FIFOs bei einem 
Packet-Burst nicht vollaufen, events verpasst werden, oder feuernde 
reentrante IRQs den Stack nicht trashen können (Klassiker..). Damit kann 
ich dann gewisse Sachen in der Realität schon mal ausschliessen und muss 
nicht immer wieder ganz unten nach Fehlern suchen.
Ab dem Punkt wo alles sowieso extrem nondeterministisch wird, reicht dir 
die Zeit in der Simulation nicht (manche Tests dauern schon Tage), da 
portierst du den ganzen Regresstest dann auf die reale HW.


> Ich sage nicht, dass deswegen alle Firmwareentwicklung in Gottes Hand
> liegt. Aber die rein elektrotechnische Sichtweise "man muss nur Alles
> gut genug und genau genug spezifizieren und seine lineare Testmatrix
> anwenden, und damit sind alle Fehlerquellen abgedeckt" hilft bei der
> Fírmwareentwickluiung über den Platinenrand hinaus nicht weiter. Da muss
> man komplett Andere Wergzeugkisten öffnen.
>

Ich habe die Erfahrung gemacht, dass man deutlich weniger am falschen 
Ende sucht, wenn man die komplette Mainloop mal in die Simulation haut 
und die  "Coverage" durchspult, wenn Tool XY mal wieder was übersehen 
hat oder man irgendwo nen Bock in der Register-Initialisierung hat. 
Welche Werkzeugkiste soll mir das abnehmen?