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
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.
Ist denn in euer Frima/Abteilung die Softwareentwicklung in C++ bei den arm cortex Systemen ein "must have"?
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 .
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.
>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.
Hier hast du was für den Einstieg: http://stefanfrings.de/stm32/index.html Module, Doku, Code-Schnipsel und ein Tutorial.
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.
Und immer schön dran denken: Auch wenn hier STM32 dominiert - es gibt noch andere gute Mikrocontroller mit ARM Cortex M.
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 :)
Ein Sprung von AVR zu Cortex A wäre schon sehr heftig. Ich hoffe nicht, dass der E_Techniker das vor hatte.
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...
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?
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?
:
Bearbeitet durch User
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"...
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).
PS: EMBITZ erstellt dir automatisch ein schönes Startprojekt. Im Grunde kann man dann sehr schnell ein Blinky realisieren.
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.
Fußpilz schrieb: > Missionare brauchen halt oft einen langen Atem. Genau wie bei der Behandlung von Fußpilz...
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".
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"
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.
:
Bearbeitet durch User
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
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
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.
Habt ihr denn ein Code Beispiel dafür. Ich suche erstmal nur einen für C
Für AVR, sehr primitiv (geht bestimmt besser):
1 | void setPin (uint8_t iPort, uint8_t iPin, bool value) { |
2 | switch (iPort) { |
3 | case 0: |
4 | PORTA = PORTA & (~(1 << iPin)) | (((uint8_t) value) << iPin); |
5 | case 1: |
6 | PORTB = PORTB & (~(1 << iPin)) | (((uint8_t) value) << iPin); |
7 | case 2: |
8 | PORTC = PORTC & (~(1 << iPin)) | (((uint8_t) value) << iPin); |
9 | }
|
10 | }
|
11 | |
12 | int main (void) { |
13 | setPin (0, 3, 1); |
14 | setPin (1, 2, 0); |
15 | }
|
Auf einem STM32F103 Cortex-M3 könnte man das so ändern:
1 | void setPin2 (uint8_t iPort, uint8_t iPin, bool value) { |
2 | *((volatile uint32_t*) (0x40010800 + iPort * 0x400 + 0x10)) = (1 << (iPin + (1-value)*16)); |
3 | }
|
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.