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.
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.
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.
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
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 .
>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.
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 :)
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...
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.
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?
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"...
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.
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.
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.
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".
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?
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.
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!!
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.
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?
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...)
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
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
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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" :-)
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.
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.
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.
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.
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 ;)
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.
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.
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.
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.
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.
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).
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?
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.
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
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.
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.
>> 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.
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.
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.
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?
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.
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.
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
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.
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.
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.
