mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Beruflich für ARM CORTEX fit machen


Autor: E_Techniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte beruflich gerne für arm cortex embedded systeme Software 
entwicklen, welche "Skills" sind dafür wichtig?

Bisher habe ich bloß 8 bit Systeme genutzt und zwar Atmel AVR 8 bit und 
alles in C.
Richtig viel hab ich in C nicht dazu gelernt, da ja vieles vorgeben 
verfügbar ist, das habe ich bisher alles verstanden. Deshalb überlege 
ich auch und frage, wie man dann später komplexere Software entwickelt?

Hab Ihr da Buchempfehlungen oder Skripte bzw. ähnliches?
Bin für jeden Tipp und Ratschlag dankbar.

: Verschoben durch Moderator
Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einfach mal einarbeiten

Autor: Adib T. (adib_t)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Joseph Yiu
The Definitive Guide to ARM® Cortex®-M3 and Cortex®-M4 Processors

Enthält eine Referenz mit Code Beispielen.

Bei den ARM Programmierst du eigentlich in C/C++.
Unterschiedlich sind die Peripherie Einheiten.

Grüße, Adib.

Autor: E_Techniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist denn in euer Frima/Abteilung die Softwareentwicklung in C++ bei den 
arm cortex Systemen ein "must have"?

Autor: Adib T. (adib_t)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
E_Techniker schrieb:
> Ist denn in euer Frima/Abteilung die Softwareentwicklung in C++ bei den
> arm cortex Systemen ein "must have"?

Nicht im Speziellen. Aber C als Hochsprache. Mit Assembler kommst du 
nicht weit ...

Grüße Adib.

Autor: J. Zimmermann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Einfach mal einarbeiten

Genau. Wenn Du die AVR's bisher mit dem AS7 programmiert hast, geht das 
quasi ganz "nahtlos", einfach mal ein kleines ARM-Board besorgen, 
empfehle das kleine SAM-D21-Board (CORTEX M0+, glaube von WeMos, ebay 
ca. 10€), und dann mit Hilfe des ASF schauen wie's gemacht wird.

mfg
Achim

Autor: Ruediger A. (Firma: keine) (rac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
E_Techniker schrieb:
> Ich möchte beruflich gerne für arm cortex embedded systeme Software
> entwicklen, welche "Skills" sind dafür wichtig?
>
> Bisher habe ich bloß 8 bit Systeme genutzt und zwar Atmel AVR 8 bit und
> alles in C.
> Richtig viel hab ich in C nicht dazu gelernt, da ja vieles vorgeben
> verfügbar ist, das habe ich bisher alles verstanden. Deshalb überlege
> ich auch und frage, wie man dann später komplexere Software entwickelt?
>
> Hab Ihr da Buchempfehlungen oder Skripte bzw. ähnliches?
> Bin für jeden Tipp und Ratschlag dankbar.

Vorsicht Eigenwerbung:

https://www.springer.com/de/book/9783658148492

Der Beispielcode (auf der Seite unter "Zusatzmaterial") ist frei und 
ohne Registierung herunterladbar. Ergänzungen/Errata etc. unter 
http://www.ruediger-asche.de/Blog .

Autor: Hannes J. (pnuebergang)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
E_Techniker schrieb:
> Richtig viel hab ich in C nicht dazu gelernt,

Dann wäre da ansetzen ein vernünftiger Anfang.

> Hab Ihr da Buchempfehlungen oder Skripte bzw. ähnliches?

Es gibt seit vielen Jahren ein kleines Büchlein zum Lernen von C. Da die 
Hipster hier allerdings ausflippen wenn man es erwähnt überlasse ich dir 
die Suche danach. Die Hipster fühlen sich durch das Büchlein nicht 
ausreichend bespaßt.

Zu ARM:

Brauchbar: https://www.cs.indiana.edu/~geobrown/book.pdf

Ohne den zugehörigen Kurs grenzwertig, da nur Vortragsfolien: 
http://www.eng.auburn.edu/~nelson/courses/elec3040_3050/C%20programming%20for%20embedded%20system%20applications.pdf

Ein Bisschen was über Datenstrukturen und Algorithmen kann ie schaden: 
https://faculty.washington.edu/jstraub/dsa/Master_2_7a.pdf
Wobei ich da eher eines der "Algorithms" Bücher von Robert Sedgewick 
empfehlen würde. Die gibt es in verschiedenen Ausgaben und für 
verschiedene Programmiersprachen.

Autor: Florain (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Einfach mal einarbeiten
Sehe ich genauso. Machen. Nimm ein Projekt, dass Dich begeistert und 
motiviert. Anspruchsvoll aber machbar und mach!

Parallel dazu kann man dann immer noch zur Literatur greifen.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier hast du was für den Einstieg:
http://stefanfrings.de/stm32/index.html

Module, Doku, Code-Schnipsel und ein Tutorial.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes J. schrieb:
> Brauchbar: https://www.cs.indiana.edu/~geobrown/book.pdf

Das ist ein sehr schönes Tutorial, leider nutzt es aber intensiv die 
Standard Peripheral Library, welche bereits seit einigen Jahren 
abgekündigt ist.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Und immer schön dran denken: Auch wenn hier STM32 dominiert - es gibt 
noch andere gute Mikrocontroller mit ARM Cortex M.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cortex-M oder Cortex-A? Es ist ein gewisser Unterschied einen kleinen 
Cortex-M Mikrocontroller zu ohne OS programmieren oder einen dicken 
Cortex-A Multicore Prozessor z.B. unter Linux zu bearbeiten. Die kann 
man zwar auch ohne OS programmieren, aber das ist ne ganz andere 
Hausnummer. Paradoxerweise braucht man da sogar mehr Assembler :)

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Sprung von AVR zu Cortex A wäre schon sehr heftig. Ich hoffe nicht, 
dass der E_Techniker das vor hatte.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ein Sprung von AVR zu Cortex A wäre schon sehr heftig

Linux Anwendungen unter Cortex-A sind doch halb so schlimm. Geht sogar 
in Python, Java usw. Ist doch fast wie am PC. Aber halt was anderes als 
AVR...

Autor: temp (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Ruediger A. schrieb:
> Vorsicht Eigenwerbung:
>
> https://www.springer.com/de/book/9783658148492

geladen, rein geguckt und gelöscht.
Wieso muss auch noch die Bücherschreiberfraktion den Leuten vermitteln 
dass STM32 und HAL untrennbar miteinander verbunden sind?

Autor: Hannes J. (pnuebergang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Hannes J. schrieb:
>> Brauchbar: https://www.cs.indiana.edu/~geobrown/book.pdf
>
> Das ist ein sehr schönes Tutorial, leider nutzt es aber intensiv die
> Standard Peripheral Library, welche bereits seit einigen Jahren
> abgekündigt ist.

Auch ST hat mittlerweile gemerkt, dass Millionen von Entwicklern weiter 
die Standard Peripheral Library verwenden und sagt mittlerweile, Zitat:
> ST continues its support for the software ...

Wer ganz hart drauf ist, der kann sich dem STM32Cube Zeug durch eine 
Portierung seines Standard Peripheral Library Code nach STM32Cube LL 
annähern. Das Portierungs-Tool von ST dafür taugt allerdings nichts.

Autor: Ruediger A. (Firma: keine) (rac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
temp schrieb:
> Ruediger A. schrieb:
>> Vorsicht Eigenwerbung:
>>
>> https://www.springer.com/de/book/9783658148492
>
> geladen, rein geguckt und gelöscht.
> Wieso muss auch noch die Bücherschreiberfraktion den Leuten vermitteln
> dass STM32 und HAL untrennbar miteinander verbunden sind?

HÄ????

Wo bitte schön liest Du DAS denn heraus? Hast Du das was falsches 
heruntergeladen??? Lies bitte mal Abschnitt 2.1.1 und sag mir, wo da das 
steht, was Du da hereinliest. Und wie interpretierst Du den letzten Satz 
in genau diesem Abschnitt, der da heisst "Als Konsequenz daraus [einer 
eindeutig kritischen vorhergehenden Auseinandersetzung mit 
Abstraktionslayern und dessen fehlender Kompatibilität miteinander, 
Ergänzung hier von mir] findet man deswegen nicht selten Codebasen, die 
auf Abstraktionslayer verzichten oder in denen im Gegenteil sogar Arbeit 
darin investiert wurde, bestehende Abstraktionslayer wieder zu 
eliminieren?"

Du hast hier meine explizite Erlaubnis, diejenigen Stellen in meinem 
Buch, die deine Interpretation stützen, zu zitieren. Ich bin mir sicher, 
dass Du keine finden kannst.

Was soll so eine Aussage?

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Ruediger A. schrieb:
> Wo bitte schön liest Du DAS denn heraus?

Das ist nur ein Troll und Unruhestifter, nimm's nicht zu ernst. Manche 
Leute werden halt schnell neidisch wenn sie die Werke anderer sehen und 
suchen dann nicht-vorhandene Haare in der Suppe. Gehört hier im Forum 
doch zum "guten Ton"...

Autor: nip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich würde mir einfach ein einfaches stm32Discovery Board für ein paar 
Euro besorgen und loslegen. Sehr empfehlen kann ich die kostenlose IDE 
EMBITZ:

Das Board:

https://www.amazon.de/STM32-von-ST-STM32VLDDISCOVERY-Discovery-STM32-F100RB/dp/B07216WS4X/ref=sr_1_1?ie=UTF8&qid=1546096789&sr=8-1&keywords=stm32vldiscovery

die IDE:

https://www.embitz.org/

Der Einstieg ist total einfach. Ich habe damit den Einstieg gemacht :-)

ich nutze übrigens immer die Standard Peripheral Library. Mann kann 
diese Library auch nutzen um zu sehen wie die Peripherie-Register 
konfiguriert werden. Theoretisch kann man dann auch seine eigene 
Implementierung nutzen (ist aber eigentlich nicht nötig).

Autor: nip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: EMBITZ erstellt dir automatisch ein schönes Startprojekt. Im Grunde 
kann man dann sehr schnell ein Blinky realisieren.

Autor: temp (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Ruediger A. schrieb:
> HÄ????
>
> Wo bitte schön liest Du DAS denn heraus?

Ruediger A. schrieb:
> Der Beispielcode (auf der Seite unter "Zusatzmaterial") ist frei und
> ohne Registierung herunterladbar. Ergänzungen/Errata etc. unter
> http://www.ruediger-asche.de/Blog

Ich hab das Zusatzmaterial runter geladen, in die ersten 4 Verzeichnisse 
geguckt und dort jedes mal ein Unterverzeichnis mit der STM32-HAL oder 
Lib gefunden. Danach war die Sache für mich entschieden.

Dr. Sommer schrieb:
> Das ist nur ein Troll und Unruhestifter, nimm's nicht zu ernst. Manche
> Leute werden halt schnell neidisch wenn sie die Werke anderer sehen und
> suchen dann nicht-vorhandene Haare in der Suppe.

Das ist Käse. Ich hab meine Meinung zu den STM32-Libs und überhaupt den 
sorglosen und ausufernden Umgang mit Libs im embedded Bereich selbst für 
die kleinsten Aufgaben. Das habe ich hier schon oft genug Kund getan. 
Und wenn ich dann im Beispielcode von Büchern dieses Zeug finde ist mein 
Urteil darüber klar. Und ich bin ganz bestimmt nicht neidisch auf 
jemanden der die STM-Libs verwendet. Ganz im Gegenteil, ich hab Mitleid.

Autor: temp (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ruediger A. schrieb:
> Du hast hier meine explizite Erlaubnis, diejenigen Stellen in meinem
> Buch, die deine Interpretation stützen, zu zitieren. Ich bin mir sicher,
> dass Du keine finden kannst.
>
> Was soll so eine Aussage?

Ich habe weder dein Buch gelesen, noch beziehe ich mich auf das Buch. 
Mir geht es um das Zusatzmaterial für das du geworben hast. Nicht mehr 
und nicht weniger.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
temp schrieb:
> Das habe ich hier schon oft genug Kund getan.

Reicht das dann nicht irgendwann?

Autor: temp (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Reicht das dann nicht irgendwann?

Ich denke nicht.

Autor: Name: Name: (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> temp schrieb:
>> Das habe ich hier schon oft genug Kund getan.
>
> Reicht das dann nicht irgendwann?

Manche Meinungen sind halt wichtiger als andere. Und durch wiederholung 
werden diese überzeugender. Das ist mit Peitschenhieben auch so.

Autor: Fußpilz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Missionare brauchen halt oft einen langen Atem.

Autor: temp (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Fußpilz schrieb:
> Missionare brauchen halt oft einen langen Atem.

Genau wie bei der Behandlung von Fußpilz...

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:

> Reicht das dann nicht irgendwann?

Solange die ST-Libs empfohlen werden, u.a. in diesem Thread, gehört die 
Kritik daran auch dazu. Schon damit ein Einsteiger nicht denkt, die Libs 
seien ja toll und "das macht man heute eben so".

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
E_Techniker schrieb:
> Hab Ihr da Buchempfehlungen oder Skripte bzw. ähnliches?
> Bin für jeden Tipp und Ratschlag dankbar.

Es gab da mal einen Qualifikations-Kurs zum ARM (Cortex)-Spezialisten 
und
ISBN: 978-0-12-408082-9 ist empfehlenswert.

Beitrag "ARM Accredited MCU Engineer"
Beitrag "ARM Accredited Engineer Program (AAE)"
Beitrag "ARM M4 Dokumentation"

Autor: E_Techniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh je was ist denn jetzt genau an mit der HAL oder den anderen Lib.'s 
falsch??

Oder kann das sein, dass man in einer Firma/Abteilung sein eigenen Still 
mitbringen darf?
Nach welchen Vorgaben entwicklt ihr denn in eurer Firma?
Ich meine, wenn ich so in C weiter mache, wie ich es gelernt habe, 
schaffe ich auch alles, man muss nur das Datascheet und die Bausteine 
beim Controller vom Hersteller verstehen, da gibt es dann Beispiele.
Also nach Schema F und fertig ist.
So richtig komplexe Systeme habe ich ja noch nie programmiert, deshalb 
stellt sich mir halt auch die Frage, ab wann ist man wirklich quasi 
"ausgebildet" bzw. "arbeitsreif" ?

Ich habe die große Hoffnung, dass mir hier das jemand erklären kann, der 
damit täglich zu tuen hat?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
E_Techniker schrieb:
> ab wann ist man wirklich quasi "ausgebildet" bzw. "arbeitsreif" ?

Softwareentwickler müssen ständig dazu lernen, um mit dem Stand der 
Technik halbwegs mit zu kommen. Arbeitsreif bist du dann, wenn du in 
einem Team deine Leistung einbringen kannst.

Es macht jedenfalls kaum Sinn, irgendeine Technologie oder Arbeitsweise 
zu lernen und sich dann den passenden Job dazu zu suchen. Lerne lieber 
das, was  vom aktuellen Job gefordert wird. Du hast nur selten die freue 
Wahl.

Autor: fsdf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wichtig ist eher ein Problem zu erkennen ,
zu analysieren und so zu arbeiten das man zielgerichtet eine lösung 
erarbeitet

ob das nun ein Cortex M A oder ein 8051 ist ... egal
wichtig für einen arbeitgeber ist auch .. eine ungefähre 
zeitabschätzung.

zB als feature :  ein USB gerät als massenspeicher am Cortex M4
da bekannt ist was gespeichert/geladen werden soll,  wie lange brauchst 
du für die implementation?

ob das nun ein STM mit HAL.. ohne HAL .. oder LL
oder ein NXP  oder Renesas ist ...
das ist eher eine sache.. daran gewöhnt man sich

ich habe mir diverse wrapper geschrieben.
kann dort HAL , LL oder auch andere  libs nutzen.

so böse sind die nicht wenn man sich darauf nicht 100%ig verlässt.
Das sollte man immer im auge behalten

das eigene zeug sollte dambei immer modular gestaltet werden ..
und so flexibel wie NÖTIG .. nicht möglich!!

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
E_Techniker schrieb:
> Oh je was ist denn jetzt genau an mit der HAL oder den anderen Lib.'s
> falsch??
>
> Oder kann das sein, dass man in einer Firma/Abteilung sein eigenen Still
> mitbringen darf?
> Nach welchen Vorgaben entwicklt ihr denn in eurer Firma?
> Ich meine, wenn ich so in C weiter mache, wie ich es gelernt habe,
> schaffe ich auch alles, man muss nur das Datascheet und die Bausteine
> beim Controller vom Hersteller verstehen, da gibt es dann Beispiele.
> Also nach Schema F und fertig ist.

Also erstens ist an den von den diversen Herstellern angebotenen 
Hilfsmittelchen immer falsch, daß sie nicht FÜR die Käufer der Chips 
geschrieben sind, sondern dafür, daß diese Käufer auch bei der Stange 
gehalten werden. Wir hatten hier neulich grad einen Thread, wo dieses 
Zeugs als "Ganzkörper-Kondom" bezeichnet wurde, was ich als sehr 
treffend ansehe. Es hält einen davon ab, tatsächlich mit der Hardware 
umzugehen und schafft bei den Benutzern eine Gewöhnung, die eben genau 
so gewollt ist. Umsteigen auf andere Hersteller ist damit weitgehend 
verhindert.

Bei ST geht's ja grad noch, da kann man ohne Umschweife auf das ganze 
Zeugs verzichten und seinen eigenen Weg gehen. Aber guck dir mal die 
Chips von Infinion an. Die haben ROM ab Adresse null und der ist zum 
größten Teil undokumentiert. Da kommt man ohne DAVE kaum aus, ohne graue 
Haare zu kriegen.

Und was den Stil in der Firma betrifft, da mußt du gucken, in was für 
eine Firma du eintrittst. Reine Programmierknechte sind eigentlich 
selten gefragt, da ist man eher Entwickler und das heißt, man macht 
alles - von der Konzeption bis hin zur Kundenpflege. Da ist 
Programmieren nur ein kleiner Teil der Aufgaben.

Vorgaben? Als Entwickler hat man ein Entwicklungsziel vor Augen, z.B. 
ein neues Gerät auf den Markt zu bringen. Alles weitere ist Inhalt des 
eigenen Jobs.

Wenn du nur C kannst, dann ist das zu wenig. Programmieren besteht NICHT 
daraus, C schreiben zu können. Sowas wird hier von manchen Leuten 
abschätzig "Codeaffe" genannt. Du solltest Elektronik können. Dazu zählt 
auch Programmieren und das nicht nur in C sondern auch in Assembler und 
anderen Programmiesprachen. Frei nach Goethe sag ich hier: Mehr 
Horizont!

W.S.

Autor: E_Techniker (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
fsdf schrieb:

> ich habe mir diverse wrapper geschrieben.
> kann dort HAL , LL oder auch andere  libs nutzen.

Wie ist ein wrapper in c aufgebaut? Gibt es dazu nähere Infos bzw. mal 
ein Beispiel?

Autor: E_Techniker (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
W.S. schrieb:

> Wenn du nur C kannst, dann ist das zu wenig. Programmieren besteht NICHT
> daraus, C schreiben zu können. Sowas wird hier von manchen Leuten
> abschätzig "Codeaffe" genannt. Du solltest Elektronik können. Dazu zählt
> auch Programmieren und das nicht nur in C sondern auch in Assembler und
> anderen Programmiesprachen. Frei nach Goethe sag ich hier: Mehr
> Horizont!
>
> W.S.

Also sollte ich mir ein Projekt erarbeiten, das einen Umfang etwa einer 
Hochschulabschlussarbeit hat, und das im Internet mal veröffentlichen 
und bei meiner Bewerbung dadrauf hinweisen, u. a. mit einem Link und 
kurzen Projektbeschreibung.

Das schätze ich mal so in etwa ein, sind meine Vormutungen hierbei 
richtig?

Was sollte das heutzutage beinhalten, dass ich ernstgenommen werde? (Ich 
weiß z. B. das viele diese Arduino Hobby Plattform eher als unwissend 
einschätz...)

Autor: J. Zimmermann (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
E_Techniker schrieb:
> Bisher habe ich bloß 8 bit Systeme genutzt und zwar Atmel AVR 8 bit und
> alles in C.

Wäre irgendwie zielführend, wenn Du mal ansagst, welche Plattform (OS, 
IDE, Hardware(tiny, mega, xmega?)) Du dabei verwendet hast und wie Du 
Deine Kenntnisse einschätzt - quasi, kann man darauf aufbauen, oder wäre 
kompletter Umstieg sinnvoll?

> Ich weiß z. B. das viele diese Arduino Hobby Plattform eher als
> unwissend einschätz...)

Etwas "hart" formuliert. Fakt ist, dass vieles "vorgekaut" ist. Wenn man 
vorhat, ernsthaft in Elektronik/Programmierung einzusteigen, mMn. 
tatsächlich nicht der beste Weg.

> Also sollte ich mir ein Projekt erarbeiten, das einen Umfang etwa einer
> Hochschulabschlussarbeit hat, und das im Internet mal veröffentlichen
> und bei meiner Bewerbung dadrauf hinweisen, u. a. mit einem Link und
> kurzen Projektbeschreibung.

Sicher, aber nicht damit anfangen! Vielleicht startest Du erstmal mit 
einer blinkenden LED.

mfg

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiss nicht Recht, wie Du Dir Einarbeitung vorstellst.

Wenn wir jemanden suchen, dann ist eher wichtig, dass er weiss, was er 
weiss. Beispiel RTOS: besser irgend eines richtig kennen als das 
richtige nur oberflächlich. Genauso bei serieller Übertragung, 
API-strukturen, Treiber, C-konstrukten, etc.

Sieh mE ieber zu, irgend einen passenden embedded Job zu bekommen, egal 
mit welchem uC. Nur Arm-Cortex wäre wie Kurierfahrer, aber nur im 
VW-Golf

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
E_Techniker schrieb:
> Oh je was ist denn jetzt genau an mit der HAL oder den anderen Lib.'s
> falsch??

> Ich meine, wenn ich so in C weiter mache, wie ich es gelernt habe,
> schaffe ich auch alles, man muss nur das Datascheet und die Bausteine
> beim Controller vom Hersteller verstehen, da gibt es dann Beispiele.
> Also nach Schema F und fertig ist.

Wann ist fertig?
Also das Datenblatt verstanden und in der Lage sein alle beispiel zu 
modifizieren genügt wahrscheinlich nicht. Jedenfalls nicht fürs 
produktive Teamwork.

Fürs "Teamwork" ist es (leider) notwendig, das auch Kollegen mit dem 
Code arbeiten können als wärs der eigene. Deshalb ist mensch erst dann 
fertig wenn mensch Code schreibt das auch der Jung-Idiot frisch von der 
Hochschule und der Alt-Idiot aus der BASIC-Grundschule nichts zu meckern 
hat. Und damit ist man leider gezwungen, sich auch in der 
Herstellerspezifischen HAL's und LACH's und ULK's auszukennen, selbst 
wenn es eigenen Ansprüchen zuwider läuft.
Für ARM heisst (hiess?) das eben, das man CMSIS-* kennen muss, ebenso 
RTX-Kernel, SVC, 3 der gängisten IDE's (Keil, IAR) mit dem unnützen 
Debug-Zucker für Warmduscher etc. pp..

Aber das ist IQ-mäßig nicht besonders schwierig, es beisst halt nur an 
der persönlichen Eitelkeit.
Wenn Cheffe/Kunde es so haben will, dann kriegt er es eben, persönlich 
verbucht man das dann eben als Negativbeispiel wie man es bei völliger 
Selbstbestimmung aus Effizienzgründen nicht machen würde.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
E_Techniker schrieb:
> Also sollte ich mir ein Projekt erarbeiten, das einen Umfang etwa einer
> Hochschulabschlussarbeit hat, und das im Internet mal veröffentlichen
> und bei meiner Bewerbung darauf hinweisen, u. a. mit einem Link und
> kurzen Projektbeschreibung.

Nein, kaum jemand interessiert sich im Detail für deine Hobby Projekte. 
Die sind wenig Aussagekräftig, weil du im Hobby die Freiheit hast, 
beliebig schlampig oder gründlich zu arbeiten. Was allerdings von 
Interesse sein dürfte ist eine kurze Angabe, welche Komponenten und 
Arbeitsmittel du dort verwendest hast.

> Was sollte das heutzutage beinhalten, dass ich ernstgenommen werde?

Auflistung deiner Fähigkeiten (womit kennst du dich aus, womit hast du 
gearbeitet, und wo hast du das getan?). Wenn dein ganzes Know-How nur 
aus Schule und Hobby kommt, dann schreibe das auch ehrlich hin. Ein 
Bewerbungsschreiben, das unehrlich oder nicht nachvollziehbar wirkt, 
landet ganz schnell im Papierkorb.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
E_Techniker schrieb:
> Bisher habe ich bloß 8 bit Systeme genutzt und zwar Atmel AVR 8 bit und
> alles in C.
> Richtig viel hab ich in C nicht dazu gelernt

Das ist schade, gerade das Programmieren sollte man gründlich lernen, 
die Architektur ist dabei völlig nebensächlich. Wenn man gut 
programmieren kann, ist die Portierung eines AVR-Programms z.B. auf 
einen Cortex-M3 ein Klacks.
Wichtig ist daher erstmal, eine Aufgabe in einen Programmablaufplan zu 
überführen und erst, wenn man diesen auf logische Funktionsfähigkeit 
durchgespielt hat, mit dem Coden anzufangen.

Wer aber gleich mit int main(void){} anfängt und dann planlos 
Spaghetticode reinhackt, der hat schon verloren.

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Peter D. schrieb:
> Wichtig ist daher erstmal, eine Aufgabe in einen Programmablaufplan zu
> überführen

PAPs werden hier oft empfohlen. Im Informatik-Studium kommen die 
interessanterweise überhaupt nicht dran. Hier wird mehr Wert auf 
UML-Diagramme (Sequenz, Klasse, Aktivität, Use Case) gelegt.

Hier ( http://www.holzers-familie.de/schule/book/pap.html ) heißt es 
sogar:
> PAPs eignen sich nicht für den Entwurf von Programmen in Hochsprachen, da
> Verzweigungen sehr nahe an den Sprungbefehl angelent sind. Für prozedurale
> Sprachen eignen sich daher eher Struktogramme und für objektorientierte
> Sprachen UML.

Wie passt das zusammen?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> PAPs werden hier oft empfohlen. Im Informatik-Studium kommen die
> interessanterweise überhaupt nicht dran. Hier wird mehr Wert auf
> UML-Diagramme (Sequenz, Klasse, Aktivität, Use Case) gelegt.

So ist es sinnvoll, denke ich.

Die einzelnen Funktionsaufrufe kann man in der Entwicklungsumgebung am 
Quelltext ablesen - sofern man es nicht mit Reflection übertreibt.

Das Arbeiten mit Diagrammen, die aus dem Quelltext heraus generiert 
werden (oder umgekehrt) halte ich für Zeitverschwendung. Der Quelltext 
sollte von sich aus (ggf. mit knappen Kommentaren) übersichtlich genug 
sein.

Wichtiger ist, dass die Kommunikation zwischen Komponenten klar 
dokumentiert wird. Da sind Sequenz-Diagramme für Use-Case wesentlich 
hilfreicher. Für Prozesse kann eine gemischt grafische/textuelle 
Darstellung der Zustände und Zustandswechsel auch sehr hilfreich sein.

: Bearbeitet durch User
Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Wichtig ist daher erstmal, eine Aufgabe in einen Programmablaufplan zu
> überführen und erst, wenn man diesen auf logische Funktionsfähigkeit
> durchgespielt hat, mit dem Coden anzufangen.
>
> Wer aber gleich mit int main(void){} anfängt und dann planlos
> Spaghetticode reinhackt, der hat schon verloren.

Das seh ich persönlich anders. Flowcharts sind meiner Meinung nach nur 
für Assembler-Code sinnvoll. In höheren Sprache ist das Beschreiben von 
Kommunikationswegen wesentlich sinnvoller.

Auch gegen das reinhacken von Code hab ich nichts. Wirklich schöner Code 
entsteht meist erst nach dem WET (Write Everything Twice) Prinzip.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> gerade das Programmieren sollte man gründlich lernen,
> die Architektur ist dabei völlig nebensächlich.

Wie bitte?

Wir sind hier nicht in einem Forum für Tabellenkalkulationen, sondern 
für Mikrocontroller! Da ist es durchaus von geradezu dramatischer 
Wichtigkeit, die Architektur zu kennen, auf der man reiten will.

Von wegen "Architektur ist völlig nebensächlich."


Dr. Sommer schrieb:
> PAPs werden hier oft empfohlen. Im Informatik-Studium kommen die
> interessanterweise überhaupt nicht dran. Hier wird mehr Wert auf
> UML-Diagramme (Sequenz, Klasse, Aktivität, Use Case) gelegt.

Naja, es gibt viele unterschiedliche Arten der Selbstbefriedigung. Auf 
früheren Embedded's standen jedesmal irgendwelche Leutchen herum, die 
über die weltbewegenden und unbestreitbaren grandiosen Vorteile ihrer 
jeweiligen Modellierungssprachen referierten. Ich gönne jedem seinen 
eigenen Elfenbeinturm.

PAPs sind hingegen ein gutes Mittel, um Leuten, die nicht logisch denken 
können, selbiges beizubringen - oder zumindest dies zu versuchen. In 
realer Firmware für nen µC hat sowas jedoch nur eher lokale Bedeutung.

W.S.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Auf
> früheren Embedded's standen jedesmal irgendwelche Leutchen herum, die
> über die weltbewegenden und unbestreitbaren grandiosen Vorteile ihrer
> jeweiligen Modellierungssprachen referierten.

Simulink... Das wird auch immer noch als heiliger Gral angepriesen.

W.S. schrieb:
> Da ist es durchaus von geradezu dramatischer
> Wichtigkeit, die Architektur zu kennen, auf der man reiten will.
Vernünftiger™ C-Code oberhalb der Treiber-Ebene sollte 
Architektur-unabhängig sein.

Autor: A. S. (achs)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wir habe akuten Fachkräftemangel, was Sw-entwickler angeht. Wenn jemand 
embedded angibt und aus den Bereichen

Linker/makefiles
RTOS/Race conditions
I2C/SPI/UART
C/C++
Prozessor-Datenblatt (egal welcher)

2 ein wenig kennt (eigene Erfahrungen hat, keine Allgemeinplätze zum 
Besten gibt) und bei den anderen Themen ehrlich sagt: hab ich gehört, 
kenne ich nicht, dann kann er anfangen.

Ob er UML oder PAP kann, ist erstmal egal, da niemand (mangels Compiler) 
es dort zu tieferem Erkenntnisgewinn bringt.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Oh, ich kann alle Punkte positiv beantworten, hätte mich aber nie in der 
Branche beworben weil der ganze Elektronik/Mikrocontroller Kram seit 
meiner Ausbildung nur als Hobby weitergeführt wurde.

Beruflich programmiere ich ganz woanders: Java Backend, gelegentlich 
auch Frontend.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> 2 ein wenig kennt

Steht das auch so in euren Stellenausschreibungen? Da werden oft 
Expertenkenntnisse in sehr speziellen Bereichen gefordert, so ala:
TCP Stacks, USB Stacks, Autosar, Regelungstechnik, DSP, ... die man 
nicht mal eben in einem Hobby-Projekt und im Studium schon gar nicht 
lernt. Die von dir aufgelisteten Dinge dürfte das halbe Forum hier gut 
beherrschen

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Vernünftiger™ C-Code oberhalb der Treiber-Ebene sollte
> Architektur-unabhängig sein.

Firmware von Mikrocontrollern ist per se NIEMALS völlig unabhängig von 
Architektur und Projekt. Schließlich ist der Endzweck, daß ein Stück 
Hardware auf einer Leiterplatte so funktioniert, wie es die übrigen 
Bestandteile auf dieser Leiterplatte erfordern.

Was du meinst, ist unabhängig von Lowlevel-Dingen wie z.B. 
UART-Treibern, Pin-Setup und dergleichen. Das sehe ich ebenso.

W.S.

Autor: A. S. (achs)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Die von dir aufgelisteten Dinge dürfte das halbe Forum hier gut
> beherrschen

Ja, jede Menge gestandene Programmierer mit mehreren Jahren Erfahrung. 
Die kommen aber für IGM-Tarif(-Ende) nicht, weil sie da schon sitzen. 
DUnd die, die kommen würden, deuten im Vorstellungsgespräch schon an, 
dass sie keinesfalls unseren (Allman) Einrückungsstil verwenden.

Andere berufen sich auf C und kennen nicht den Sinn von static, const 
oder volatile (3 der 32 Schlüsselwörter in C90). (*)

I2C und Uart? Ja, mit einem Framework.

Race Conditions? OT: "Ja, Designfehler, sowas macht man heute nicht 
mehr"

Linker/Makefiles, ... macht doch die IDE. Das macht man heute nicht per 
Hand.

(*) Das wäre auch nicht schlimm. Schlimm daran ist nur, dass sie 
(mangels eigener Erfahrung) auch nicht wissen, dass sie diese 
Schlüsselworte (noch) nicht verstanden haben. Wenn jemand haltloses Zeug 
zu allen 3 schwadroniert, ist das schlimm. OK ist, wenn er sagt, static 
und const noch nie benutzt zu haben, aber eine while-Schleife mal nicht 
funktioniert hat, weil er volatile vergessen hat.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Da werden oft
> Expertenkenntnisse in sehr speziellen Bereichen gefordert, so ala:
> TCP Stacks, USB Stacks, Autosar, Regelungstechnik, DSP, ... die man
> nicht mal eben in einem Hobby-Projekt und im Studium schon gar nicht
> lernt.

Auch da reichen dann meist 2, oft auch nur 1, damit der Personaler uns 
die Unterlagen weiterreicht oder gleich einen Termin vereinbart.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Schließlich ist der Endzweck, daß ein Stück
> Hardware auf einer Leiterplatte so funktioniert, wie es die übrigen
> Bestandteile auf dieser Leiterplatte erfordern.

Auch Peripherie kann man abstrahieren... Der JS-Code dieser Website ist 
wohl auch nicht abhängig von der Maus. Das kann man alles der 
Treiberebene zugehörig sehen...

W.S. schrieb:
> Was du meinst, ist unabhängig von Lowlevel-Dingen wie z.B.
> UART-Treibern, Pin-Setup und dergleichen. Das sehe ich ebenso.
Was ich nicht nur gemeint, sondern sogar geschrieben habe.

A. S. schrieb:
> Race Conditions? OT: "Ja, Designfehler, sowas macht man heute nicht
> mehr"
Ja, passiert nicht wenn man z.B. das Aktor-Modell nutzt ;-)

A. S. schrieb:
> Linker/Makefiles, ... macht doch die IDE. Das macht man heute nicht per
> Hand.

Ist nicht ganz falsch. Man sollte aber trotzdem wissen wie es 
funktioniert...

Das sind wohl die Leute die hier im Forum über die Fachkräfte-Lüge 
jammern weil sie nichts finden? Erinnert mich ein bisschen an:
https://workplace.stackexchange.com/q/125402
Das kommt wohl davon wenn alle nur Soft Skills predigen...

Kleine Anekdote: Ich wurde im VG gefragt, was virtual inheritance in C++ 
ist. Ich setzte an zu antworten "If you have a diamond inheritance 
situation, ..." und erhielt die Antwort "Oh that's enough, I see you 
know what this is about" :-)

Autor: Peter D. (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Auch gegen das reinhacken von Code hab ich nichts. Wirklich schöner Code
> entsteht meist erst nach dem WET (Write Everything Twice) Prinzip.

Ich sehe nicht ein, warum man sich doppelte Arbeit machen sollte. Auch 
geht das in der Praxis nicht. Sobald etwas auch nur den Anschein hat, 
daß es funktionieren könnte, fällt der Hammer und es wird verkauft. Daß 
es völliger Schrott ist, merken erst die armen Teufel nach Dir, die es 
supporten sollen. Also programmiert man es besser gleich sauber, d.h. 
das Grundkonzept muß schon stimmen. Und das geht nur mit Planung und 
nicht mit drauflos hacken.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Wenn die Firma die QA auflöst und Updates Freitags nachmittags um 17:00 
in Betrieb nimmt, läuft zwar einiges gehörig schief

aber die Softwareentwickler erkennen daran, dass man ihnen im höchsten 
Masse vertraut. Das ist indirektes Feedback zur Arbeitsleistung. Ich 
erlebe das gerade und bin hin und her gerissen, was ich davon halten 
soll.

: Bearbeitet durch User
Autor: Peter D. (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> PAPs werden hier oft empfohlen. Im Informatik-Studium kommen die
> interessanterweise überhaupt nicht dran. Hier wird mehr Wert auf
> UML-Diagramme (Sequenz, Klasse, Aktivität, Use Case) gelegt.

In der hardwarenahen Programmierung kommt es oft darauf an, daß Abläufe 
exakt stimmen und Zeitbedingungen genau eingehalten werden und dafür 
eignet sich ein PAP sehr gut.

Ein schönens Beispiel ist z.B. im DS18B20 Datenblatt zu finden:
https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf
Figure 13. ROM Commands Flowchart

Damit konnte ich dann sehr leicht das "Search ROM" implementieren und es 
funktionierte auf Anhieb.

Autor: ja, ja Fachkräftemangel (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
A. S. schrieb:
> Wir habe akuten Fachkräftemangel, was Sw-entwickler angeht. Wenn jemand
> embedded angibt und aus den Bereichen
>
> Linker/makefiles
> RTOS/Race conditions
> I2C/SPI/UART
> C/C++
> Prozessor-Datenblatt (egal welcher)
>
> 2 ein wenig kennt (eigene Erfahrungen hat, keine Allgemeinplätze zum
> Besten gibt) und bei den anderen Themen ehrlich sagt: hab ich gehört,
> kenne ich nicht, dann kann er anfangen.

Für Appel und ein Ei. Been there, seen it, bought the t-shirt.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
A. S. schrieb:
> die kommen würden, deuten im Vorstellungsgespräch schon an,
> dass sie keinesfalls unseren (Allman) Einrückungsstil verwenden.

Ja warum nehmt ihr denn auch nicht den Stil von den C Entwicklern (K&R) 
und von DEM C++ (Stroustrup) Entwickler?
Selber Schuld ;)

Autor: void (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> PAPs werden hier oft empfohlen. Im Informatik-Studium kommen die
> interessanterweise überhaupt nicht dran.

Naja, in dem genannten Link steht aber etwas anderes.
  "Für prozedurale Sprachen eignen sich daher eher Struktogramme"
Es werden also anstatt PAPs Struktogramme (Nassi-Shneiderman-Diagramme) 
empfohlen.

Diese werden an Universitäten wohl bevorzugt weil diese, im Gegensatz zu 
PAPs, einen restriktiveren Umgang mit Kontrollstrukturen bieten. Das 
hilft den Studenten eine Struktur ohne ständige unüberlegt "goto" Pfade 
zu erzeugen.
Generell spricht gegen die Verwendung von PAPs nichts, wie das Beispiel 
von Peter gut zeigt.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Ein schönens Beispiel ist z.B. im DS18B20 Datenblatt zu finden:

Das dokumentiert aber die Abläufe der relativ simplen Hardware. Die 
Abläufe in einer realen Software sind um viele Größenordnungen 
komplexer, da bräuchte man sehr viel Papier um die so zu 
dokumentieren...

void schrieb:
> Diese werden an Universitäten wohl bevorzugt weil diese, im Gegensatz zu
> PAPs, einen restriktiveren Umgang mit Kontrollstrukturen bieten.

Hatten wir in der Schule bei einem Seiteneinsteiger-Informatiklehrer, 
aber im Informatik-Studium nie. Aus mMn gutem Grund, weil die sehr 
schnell riesig und unübersichtlich werden.

Ich male hauptsächlich "frei-form" Architekturdiagramme, UML-Klassen-, 
-Sequenz- und State-Diagramme. Diese High-Level Sichtweise ist viel 
hilfreicher und wichtiger als Details, an welcher Stelle jetzt welche 
if-Abfrage kommt.

Autor: Peter D. (peda)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Das dokumentiert aber die Abläufe der relativ simplen Hardware. Die
> Abläufe in einer realen Software sind um viele Größenordnungen
> komplexer, da bräuchte man sehr viel Papier um die so zu
> dokumentieren...

Der Trick beim Programmieren ist aber, komplexe Aufgaben in einfachere 
Teilaufgaben herunterzubrechen. Auch PAPs kann man hierachisch 
aufteilen.
Für mich ist die optimale Größe ein A4-Blatt. Sobald ein PAP größer 
wird, erstelle ich Teilaufgaben als eigene PAPs.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Für mich ist die optimale Größe ein A4-Blatt. Sobald ein PAP größer
> wird, erstelle ich Teilaufgaben als eigene PAPs.

Kannst du mal ein Beispiel dafür zeigen für ein Projekt mit so ab 
10kLoc, welches mehr also nur prozedurale Programmierung macht, also 
z.B. OOP, IoC, Nebenläufige Programmierung, Metaprogrammierung? Kann mir 
schwer vorstellen wie sowas aussieht.

Autor: void (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Ich male hauptsächlich "frei-form" Architekturdiagramme, UML-Klassen-,
> -Sequenz- und State-Diagramme. Diese High-Level Sichtweise ist viel
> hilfreicher

Das hat nicht zwangsweise mit dem Abstraktions-Level zu tun, sondern mit 
dem darzustellenden Sachverhalt.

Für die Beschreibung eines Zustandsautomaten sind eben sowohl ein 
UML-Sequenz Diagram als auch ein PAP total ungeeignet.
Für ein Challenge-Rensponse-Verschlüsselungsverfahren ein 
UML-Sequenz-Diagram einem PAP (aber auch einem State-Diagram) klar 
überlegen.

In der Anwendung Treiber für Mikrocontroller -oder ähnlich simpler 
Hardware wie du dich ausdrückst- sind PAP (und State-Diagram) aber 
durchaus sinnvoll, wenn es auf die genaue Beschreibung ankommt.

An den Stellen wo es wichtig ist, darf man schon einmal ein Blatt 
(virtuelles) Papier spendieren.

Autor: Theo Praktiker (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ich finde die Fragestellung sehr faszinierend. Wir müssen aber sehr 
darauf aufpassen, hier nicht mehrere Dinge in einen Topf zu werfen.

Am Ende des Tages geht es um die Frage "Was ist Informatik?"

Ist es

a) die Aufgabe, gegebene Computer (also zum Beispiel ein vorhandenes ARM 
basiertes Board mit unveränderbarer Peripherie) dazu zu bringen 
(=programmieren), eine definierte Problemstellung zu lösen,

oder

b) Probleme auf einer abstrakten Ebene zu formulieren (also unabhängig 
von der unterliegenden, die Lösungsstrategie umzusetzenden Hardware, so 
dass als Beispiel ein neuronaler Biocumputercompiler mit einem 
entsprechenden "Compiler" dasselbe Ablaufdiagramm ausführen könnte wie 
ein auf einem ARM System laufender elektronischer Computer mit Hilfe 
"seines" Compilers)?

Je nachdem wie man die Frage für sich beantwortet kommt man auf sehr 
verschiedene Definitionen dessen, was unsere Aufgabe ist und welche 
Werkzeuge dafür geeignet sind.

Wer sich als Programmierer "seiner" Plattform (in dieser Form 
elektronischer Rechner) ansieht, wird sich mit "seiner" Hardware 
auseinandersetzen müssen und auch wollen. Es ist genau so irrwitzig zu 
denken, man könnte einen Computer ohne Verständnis dessen Architektur zu 
programmieren wie zu denken, man könnte ein Experte in amerikanischer 
Kultur und Sprache werden, ohne jemals Englisch gelernt zu haben (selbst 
wenn es noch so guter Übersetzungen von 90% amerikanischer Literatur 
gibt). Jeder Praktiker der Programmierung weiss aus der Erfahrung ganz 
einfach, dass früher oder später der Zeitpunkt kommt, wo ein gegebener 
Abstraktionslayer (sei es Java, UML o.ä.) mit einer speziellen Plattform 
Probleme kriegt oder gewisse Dinge auf Grund von 
Plattformbeschränkungen, Bugs im Compiler, relevante 
Performanzoptimierungsoptionen o.ä. wieder an eine konkrete Hardware 
angepasst werden muss.

Deswegen ist die Aufgabenstellung des "vollberuflichen 
Algorithmenentwerfers," der nur in komplett plattformunabhängigen 
Modellen arbeitet, erstmal nicht obsolet oder vollkommen unrealistisch. 
Aber es ist praktisch unmöglich, die zwei Aufgabenstellungen "abstrakter 
Algorithmenformulierer" und "mikroskopischer Plattformumsetzter" 
unabhängig voneinander zu sehen. Vielleicht lassen sich in grösseren 
Organisationen mit genügend Manpower diese Aufgaben getrennt voneinander 
besetzen, aber zunächst einmal werden solche Leute niemals unabhängig 
voneinander arbeiten können und in enger Interaktion miteinander stehen, 
und zweitens Mal ist es ein Irrglaube, dass einer der beiden Positionen 
höhere Qualifikationen verlange als der Andere. Es sind halt sehr 
verschiedene Aufgabenstellungen.

Also ist die Diskussion "C oder UML?" in der Praxis komplett sinnfrei, 
selbst im "reinen Softwarebereich" (also wo auf sehr generischen 
Plattformen wie für PCs gearbeitet wird).

Autor: E_Techniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwie sind wir etwas abgeschweift, was meine Fragen betrifft.

Oder ist es später auch so, dass man irgendwie ein Projekt fertig macht, 
so wie man es halt drauf hat?
Dann brauch man nur der Firma klar darstellen, was man alles kennt und 
kann. Somit scheint mir C/C++ wichtig hatte da mal den Erlorenköter oder 
wie der sich schrieb und dann habe danach mir immer Beispiele aus 
verschiedenen Quellen genommen und angepasst bzw. erweitert.

Gibes dadrüber hinaus etwas was mir fehlen könnte? Z. B. so ein wrapper 
in c habe ich noch nie gesehen.
Gibt es dafür ein Buch, das muss ja alles schon extra Kenntnisse C sein?

Zu den ARM CORTEX System werde ich mir ein Buch nehmen und es 
durcharbeiten. Danach versuche ich eine andere Controller zu nehmen, ob 
ich dann damit klar komme? So leicht wie beim AVR wird es wohl nicht 
sein schätze ich mal?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
E_Techniker schrieb:
> Oder ist es später auch so, dass man irgendwie ein Projekt fertig macht,
> so wie man es halt drauf hat?

Ich verstehe die Frage nicht. Jeder arbeitet immer entsprechend seiner 
Fähigkeiten, oder nicht?

> Dann brauch man nur der Firma klar darstellen,
> was man alles kennt und kann.

Sage ich doch. Die Bewerbungsunterlagen sollten ehrlich beschrieben, was 
du schon kannst. Nenne Dich z.B. nicht schon ARM Experte, wenn du nur 
ein Tutorial mit einem STM32 durchgearbeitet hast.

Wenn Du Lust auf Lernen hast, solltest du das auch deutlich sagen. Dann 
kann die Firma entscheiden, ob Sie die dafür nötige Zeit und das Geld 
investieren möchte, oder nicht. Im Bewerbungsgespräch kann man dann 
klären, wie das mit dem Lernen stattfinden soll (Schulungen, Bücher, 
Material, zu hause oder am Arbeitsplatz).

Wenn du dich schon einmal an einem Arbeitsplatz weiter entwickelt hast 
(was der Regelfall sein dürfte), dann gebe das an. Schreibe hin, was du 
bei welchem Projekt neues dazu gelernt hast.

> Somit scheint mir C/C++ wichtig

Auf jede Fall. Bei Mikrocontrollern führt an C langfristig kein Weg 
vorbei - trotz der zahlreichen Alternativen. Ebenso würde ich zumindest 
rudimentäre Linux Kenntnisse dringend empfehlen.

> Z. B. so ein wrapper in c habe ich noch nie gesehen.

Dazu gibt es keine Vorgaben und ehrlich gesagt halte ich auch nichts von 
Wrappern, die fremde Libraries kapseln. Wenn mal etwas nicht 
funktioniert, zeigen die Entwickler gegenseitig auseinander und weisen 
sich die Schuld zu. Dann nützt Dir am Ende nicht einmal kommerzieller 
Support. Ich habe das bei kommerziellen Projekten im Java Backend zu oft 
erlebt, um hier auch nur ein gute Wort über Wrapper los zu werden.

Für C/C++ kann ich die Bücher von Stroustroup, Kernighan/Ritchie 
empfehlen. Empfehlungen, wie man bestimmte Aufgaben lösen kann, nennt 
man "Patterns". Diese sind überwiegend sogar weitgehend unabhängig von 
der Programmiersprache, und daher besonders lernenswert.

Zu den ARM CORTEX System werde ich mir ein Buch nehmen und es
durcharbeiten. Lies dieses: 
https://www.eecs.umich.edu/courses/eecs373/labs/refs/M3%20Guide.pdf Oder 
kaufe die neuere Auflage davon, die auch Cortex M4 abdeckt. Und 
verfestige das mit ein paar Experimenten an einem konkreten 
Mikrocontroller.

Nie vergessen: ARM ist nicht gleich ARM. Zwischen einem Cortex M3 und 
einem Smartphone-SOC liegen Welten. Und letztendlich spezifiziert ARM 
nur den Prozessor-kern. Die ganzen I/O Funktionen drumherum sind immer 
Hersteller-spezifisch.

Schau Dir diese Seite an: http://stefanfrings.de/stm32/index.html dort 
beschreibe ich die STM32F103 Serie so weit, dass man erste ernsthafte 
Programme damit schreiben kann. Einschliesslich Links zu Doku und einem 
Tutorial.

> Danach versuche ich eine andere Controller zu nehmen, ob
> ich dann damit klar komme? So leicht wie beim AVR wird es wohl nicht
> sein schätze ich mal?

Wenn Du Dich mit 8bit Mikrocontrollern auseinandersetzen möchtest, würde 
ich Dir AVR empfehlen, weil die sehr gut dokumentiert sind und du dafür 
hier im Forum den meisten Support bekommen wirst. 
http://stefanfrings.de/mikrocontroller_buch/index.html

Um noch einen Einstieg in die Welt weiter "oben" zu bekommen, könntest 
du dich mit einem Raspberry Pi oder Odroid beschäftigen. Der hat einen 
SOC der Art drauf, wie auch in den Smartphones steckt, kann aber im 
Gegensatz zu Smartphones auch von normal sterblichen hardwarenah 
programmiert werden - wenn man es denn will.

: Bearbeitet durch User
Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Wenn Du Lust auf Lernen hast, solltest du das auch deutlich sagen. Dann
> kann die Firma entscheiden, ob Sie die dafür nötige Zeit und das Geld
> investieren möchte, oder nicht. Im Bewerbungsgespräch kann man dann
> klären, wie das mit dem Lernen stattfinden soll (Schulungen, Bücher,
> Material, zu hause oder am Arbeitsplatz).

Sowas spricht man im Bewerbungsgespräch an?
Klingt nach jemandem, der vor sich hin studiert hat, und nicht wirklich 
daran interessiert ist, für seinen Lohn etwas für die Firma sinnvolles 
zu tun.
Wenn man Projekte vorweisen kann, die man ggf. schon mit 
unterschiedlichen Prozessoren/Architekturen (erfolgreich)erstellt hat, 
dann wird man für Firmen interessant. Da geht es auch um die Art des 
selbständigen Einarbeitens in ein (neues) Thema.

Leider gibt es nur bezogen auf den Controller-Kern allgemeingültige 
Doku.
Die Controller-Herseller verfolgen leider unterschiedliche Philosophien 
bei der Doku und anderem Support.
Ich finde das System von STM sehr schlüssig, da man z.B. mit dem 
TrueStudio eine "eigene" IDE wie Atmel mit dem AVR/Atemel-Studio hat.
Der Einstieg (Controller-Konfiguration) klappt auch ganz gut mit CubeMX 
(auch, wenn das leider nicht ganz fehlerfrei ist).
Das einfachste:
- Tutorium finden, das Stilmäßig gefällt
- passendes Developement-Board besorgen
- rumspielen

Autor: Ein Suchender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe das im Netz gefunden. Er verwendet auch ein kleines Board mit einem 
SAM. Sind auch Beispiele dabei und Erklärung.

https://playground.boxtec.ch/doku.php/tutorials/start

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STK500-Besitzer schrieb:
> Sowas (Lernen) spricht man im Bewerbungsgespräch an?

Auf jeden Fall!

Ich habe schon einige Leute erlebt, die ausschliesslich das machen 
wollen, was sie bereits gelernt haben. Solche Leute können nur wenige 
Firmen gebrauchen.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ich habe schon einige Leute erlebt, die ausschliesslich das machen
> wollen, was sie bereits gelernt haben.
Wenn sie darin gut / Experte sind?!
Mir kannst du mit Projektleitung gestohlen bleiben...


> Solche Leute können nur wenige
> Firmen gebrauchen.

Kommt auf die Firma an. Manche wollen nur einen Programmieraffen 
einstellen. Das dürfte aber inzwischen dei Minderheit sein.

Dass man lernwillig ist, sollte dadurch erkennbar sein, dass man schon 
verchiedene Projekte durchgeführt hat. Vor allem als Einsteiger.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Ich habe schon einige Leute erlebt, die ausschliesslich das machen
>> wollen, was sie bereits gelernt haben.

STK500-Besitzer schrieb:
> Wenn sie darin gut / Experte sind?!
> Mir kannst du mit Projektleitung gestohlen bleiben...

Siehst du, deswegen sollte man solche Dinge spätestens im 
Vorstellungsgespräch klären. Denn mit dieser Einstellung passt du eben 
nicht überall rein.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Siehst du, deswegen sollte man solche Dinge spätestens im
> Vorstellungsgespräch klären. Denn mit dieser Einstellung passt du eben
> nicht überall rein.

Das hat aber nichts mit gewünschter Fortbildung zu tun.
Ich habe auf dem Sektor schon Erfahrung, bin aber aufgrund gewisser 
gesundheitlicher Einschränkungen nicht wirklich dazu geeignet.
Dein Satz liest sich so, als sollte man gleich im Vorstellungsgespräch 
(externe) Fortbildung fordern.

Ist aber inzwischen offtopic.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
STK500-Besitzer schrieb:
> Dein Satz liest sich so, als sollte man gleich im Vorstellungsgespräch
> (externe) Fortbildung fordern.

Fordern kommt im Vorstellungsgespräch sicher nicht gut an. Aber 
Bereitschaft signalisieren, dass man gerne noch mehr dazu lernt, 
eventuell auch zuhause. Das hören Chefs gerne.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
E_Techniker schrieb:
> Bisher habe ich bloß 8 bit Systeme genutzt und zwar Atmel AVR 8 bit und
> alles in C.
> Richtig viel hab ich in C nicht dazu gelernt, da ja vieles vorgeben
> verfügbar ist, das habe ich bisher alles verstanden. Deshalb überlege
> ich auch und frage, wie man dann später komplexere Software entwickelt?

Um wieder in ontopic zu werden:
Was hast du damit bis jetzt erstellt?
Wir verwenden in der Firma auch AVR und STM32 parallel.
Das AVR-System ist historisch auf Basis einer Bachelor-Arbeit gewachsen 
(vor meiner Zeit) und das STM32-System wurde als neues Arbeitspferd 
eingeführt (ersetzt ein "Uralt-System" aus den späten 1990ern).

Siehst du für Euch irgendwo das Ende Fahnenstange für den AVR?
Oder zumindest Potential, für Mehrpower?

Das Yiu-Buch wurde ja schon angesprochen - das dürfte als K&R des arm 
gelten.
Was meinst du mit "komplexere Software"?
Multitasking / RTOS? Echtzeit?

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
E_Techniker schrieb:
> Gibes dadrüber hinaus etwas was mir fehlen könnte? Z. B. so ein wrapper
> in c habe ich noch nie gesehen.
> Gibt es dafür ein Buch, das muss ja alles schon extra Kenntnisse C sein?

Nein, Wrapper gibt es nicht nur in der Sprache C, im Gegenteil. Bei 
Arduino sind beispielsweise die meisten Hardware-Zugriffe als 
C-Funktionen ausgeführt. Darauf aufbauend gibt es dann C++-Wrapper, 
welche die C-Funktionen verkapseln (sprich einwickeln).

Wrapper-Funktionen nutzt man immer dann wenn man nach außen hin ein 
stabiles, einheitliches Interface haben möchte, gegen das man 
programmiert.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Wrapper-Funktionen nutzt man immer dann wenn man nach außen hin ein
> stabiles, einheitliches Interface haben möchte, gegen das man
> programmiert.

Oder wenn man die dahinter liegende Komplexität verbergen will, wie es 
z.B. Arduino tut.

Autor: E_Techniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt ihr denn ein Code Beispiel dafür. Ich suche erstmal nur einen für C

Autor: Ein Fragender (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Sorry für meine unwissenheit. Was ist Wrapper?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Für AVR, sehr primitiv (geht bestimmt besser):
void setPin (uint8_t iPort, uint8_t iPin, bool value) {
  switch (iPort) {
    case 0:
      PORTA = PORTA & (~(1 << iPin)) | (((uint8_t) value) << iPin);
    case 1:
      PORTB = PORTB & (~(1 << iPin)) | (((uint8_t) value) << iPin);
    case 2:
      PORTC = PORTC & (~(1 << iPin)) | (((uint8_t) value) << iPin);
  }
}

int main (void) {
  setPin (0, 3, 1);
  setPin (1, 2, 0);
}
Auf einem STM32F103 Cortex-M3 könnte man das so ändern:
void setPin2 (uint8_t iPort, uint8_t iPin, bool value) {
  *((volatile uint32_t*) (0x40010800 + iPort * 0x400 + 0x10)) = (1 << (iPin + (1-value)*16));
}

Die Funktion setPin ist hier also ein Wrapper um die GPIO-Funktionalität 
des Controllers. Sie ist gleichzeitig ein HAL, weil sie die Hardware 
abstrahiert. Im restlichen Code kann man dann einfach per setPin die 
Pins setzen, ohne sich darum zu kümmern, wie das auf der jeweiligen 
Hardware jetzt funktioniert. So etwas geht in C++ natürlich besser, weil 
C++ mehr Möglichkeiten zur Abstraktion bietet.

Siehe: https://de.wikipedia.org/wiki/Wrapper

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> Und die, die kommen würden, deuten im Vorstellungsgespräch schon an,
> dass sie keinesfalls unseren (Allman) Einrückungsstil verwenden.

Ein guter Programmierer sollte schon flexibel sein und Teamfähigkeit 
mitbringen. Sich an den Styleguide des Kollektivs anzupassen, darf kein 
Problem sein. Mit AStyle läßt sich auch älterer Code leicht übernehmen.

Autor: E_Techniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Für AVR, sehr primitiv (geht bestimmt besser):void setPin (uint8_t
> iPort, uint8_t iPin, bool value) {
>   switch (iPort) {
>     case 0:
>       PORTA = PORTA & (~(1 << iPin)) | (((uint8_t) value) << iPin);
>     case 1:
>       PORTB = PORTB & (~(1 << iPin)) | (((uint8_t) value) << iPin);
>     case 2:
>       PORTC = PORTC & (~(1 << iPin)) | (((uint8_t) value) << iPin);
>   }
> }
>
> int main (void) {
>   setPin (0, 3, 1);
>   setPin (1, 2, 0);
> }
Alles klar ja das ist gut, da spart man sich dann schon Arbeit mit 
Wiederholstätern.

>Auf einem STM32F103 Cortex-M3 könnte man das so ändern:void setPin2
> (uint8_t iPort, uint8_t iPin, bool value) {
>   *((volatile uint32_t*) (0x40010800 + iPort * 0x400 + 0x10)) = (1 <<
> (iPin + (1-value)*16));
> }

Das verstehe ich nicht, das müsste ich Schritt für Schritt erstmal 
verstehen. Da  merke ich wieder, dass ab arm cortex M... bei mir einiges 
aufzuholen ist!

> Die Funktion setPin ist hier also ein Wrapper um die GPIO-Funktionalität
> des Controllers. Sie ist gleichzeitig ein HAL, weil sie die Hardware
> abstrahiert. Im restlichen Code kann man dann einfach per setPin die
> Pins setzen, ohne sich darum zu kümmern, wie das auf der jeweiligen
> Hardware jetzt funktioniert. So etwas geht in C++ natürlich besser, weil
> C++ mehr Möglichkeiten zur Abstraktion bietet.
>
> Siehe: https://de.wikipedia.org/wiki/Wrapper

Wenn man die HAL sauber dokumentieren kann, also dazu fähig ist, dann 
kann jeder damit schnelle Ergebnisse schaffen, das Portieren stelle ich 
mir auch leicht vor.

Schade, dass es so etwas in meinen damaligen Büchern nicht gab, einfach 
ein simples Beispiel und dann in paar Stufen, dass man selbst komplexe 
Wrapper bauen kann, die man auch wirklich versteht.
Finde es immer schade, dass komlexe Themen zu kompliziert umschrieben 
werden, aber meist nicht erklärt werden können, weil für die Leute schon 
zu viel selbstverständlich ist. Aber dann einen eben die Schuld der 
nicht vorhandenen Grundkenntnisse zu unrecht unterstellen.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STK500-Besitzer schrieb:
> Das hat aber nichts mit gewünschter Fortbildung zu tun.
> Ich habe auf dem Sektor schon Erfahrung, bin aber aufgrund gewisser
> gesundheitlicher Einschränkungen nicht wirklich dazu geeignet.
> Dein Satz liest sich so, als sollte man gleich im Vorstellungsgespräch
> (externe) Fortbildung fordern.
>
> Ist aber inzwischen offtopic.

Ja, sollte man, und nein, ist nicht OT.

Der TO will in einem (für ihn) neuen Gebiet Anfangen. Er fragt nach 
Anfänger-Übungen und ist ein Anfänger.

Anfänger müssen lernen wollen.
Sonst bleiben es Anfänger, auch nach vielen Jahren BE.

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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