Announcement: there is an English version of this forum on Ich bekomme einen mittelalten ( englisch nur so mittelgut :-( ) Kollegen, der bisher "nur" C# und Java programmiert hat. Jetzt soll ich ihn irgendwie beschäftigen und anlernen, damit er "bald" (sagt der Chef) STM32 und AVRs programmieren kann. Nun bin ich auch kein Programmierer, sondern Elektroniker und muss halt notgedrungen manchmal ein paar Zeilen Code schreiben oder anpassen. Mangels Alternativen muss das aber reichen. Ich bin also offen für Vorschläge, was ich ihm zu lesen geben soll oder ob ein paar sinnlose, aber lehrreiche Übungsprojekte die bessere Wahl wären? Was meinen die Experten hier? Umgang mit Oszi, Lötkolben, LA und Multimeter werde ich mit ihm dann extra üben.
a) Passt besser nach "Ausbildung und Beruf" b) Ist jedenfalls mutig. Nicht zwingend hoffnungslos, aber auch nicht unbedingt vielversprechend. c) Gib dem Menschen einen Arduino, lass' ihn die üblichen Übungen damit durchspielen (LED-Blinker, serielle Datenübertragung, HD44780-Display ansteuern, Takt auf I/O-Pin erzeugen und den mit Oszi mesen) Ruhig mit der Arduino-IDE und -Sprachumgebung. Wenn er damit zu Potte kommt, dann kann man weitermachen.
Mit C# und Java hat er zumindest das Prinzip OOP verstanden, was will man mehr? Möglicherweise fehlt ihm nur die notwendige Hardware-Nähe, aber da bist du ja der Experte. Klingt nach einem DreamTeam :-)
Luky S. schrieb: > Nun bin ich auch kein Programmierer, > sondern Elektroniker und muss halt notgedrungen manchmal ein paar Zeilen > Code schreiben oder anpassen. Mangels Alternativen muss das aber > reichen. Ist doch prima, dann kannst du von ihm einiges über gutes Design lernen. Wie wäre es wenn du ihn einfach fragst was er an hardwarenaher Programmierung schon gemacht hat, anstatt hier einen flame Thread gegen "mittelalte" Programmierer aufmachen zu wollen.
Luky S. schrieb: > Ich bekomme einen mittelalten ( englisch nur so mittelgut :-( ) > Kollegen, der bisher "nur" C# und Java programmiert hat. Jetzt soll ich > ihn irgendwie beschäftigen und anlernen, damit er "bald" (sagt der Chef) > STM32 und AVRs programmieren kann. Naja, wenn er Java und C# kann, dann weiß er, wie Softwareentwicklung funktioniert und was Objektorientierung ist, und beherrscht obendrein den üblichen Kram wie Variablen, Abfragen, und Schleifen. Der muß dann nur noch die Dinge lernen, die spezifisch für Mikrocontroller sind. > Ich bin also offen für Vorschläge, was ich ihm zu lesen geben soll Gib ihm was zum Spielen. Man wird niemals ein guter Entwickler, wenn man nie rumgespielt hat. Daher, die Klassiker: LED zum Blinken bringen, ADC lesen und umrechnen... das Übliche halt.
Problem ist doch nicht, dass er nicht programmieren kann, sondern eher dass er EURE Abläufe/HW zu wenig kennt.
Er muss keine Abläufe kennen, wir sind kein Großunternehmen. Und natürlich kann er programmeren, aber halt mit sehr vielen Frameworks und Abstraktionslayern dazwischen. Keine Register und Interrupts, keine analogen Signale, keine (HW) Debugger etc. Das fehlt alles völlig.
Luky S. schrieb: > Und natürlich kann er programmeren, aber halt mit sehr vielen Frameworks > und Abstraktionslayern dazwischen. Keine Register und Interrupts, keine > analogen Signale, keine (HW) Debugger etc. Das fehlt alles völlig. Wenn Du es auch nicht kannst, lasse die Hose runter und erkläre das Deinem Chef. Wenn der Tischler den Bäcker anlernen soll, endet das halt im Desaster.
Lass ihn echte Arbeit machen und unterstütze ihn dabei. Dir irgendwelche didaktischen Aufgaben zu überlegen ist verschwendete Zeit. Ein Studium lebt von intrinsischer Motivation oder dem Vergleich mit Kommilitonen. Ihr werdet ja irgendwas mit STM und AVR machen, also lass es ihn machen: Prototypen flashen, einen Parameter verstellen, einen Kundenwusch implementieren, ... . Eure SW wird Teile haben, die er problemlos versteht und bearbeiten kann und Teile, die fremd für ihn sind. Oft reichen ein paar Stichworte oder eine Warnung vor Fallen. Und ab und zu referierst Du halt mal über einen Watchdog, ADC oder den Besonderheiten Eurer RTOSe.
Zeige deinem Kollegen das da https://nanoframework.net und lerne selber C#. So kommt ihr euch entgegen und trefft euch auf halbem Weg. Das geht schneller, als wenn nur einer von euch beiden (nämlich dein Kollege) den vollen Weg beschreitet. Nein, das war natürlich nicht ernst gemeint. Nachdem Microsofts Philosophie schon die meisten PCs unbrauchbar macht, muss das nicht auch noch bei den Mikrocontrollern geschehen ;-)
Bruno V. schrieb: > Lass ihn echte Arbeit machen und unterstütze ihn dabei. > > Dir irgendwelche didaktischen Aufgaben zu überlegen ist verschwendete > Zeit. Ein Studium lebt von intrinsischer Motivation Sehe ich auch so. Er wird in kurzer Zeit die Mikrocontroller verstehen. Womöglich programmiert er sie besser als du.
:
Bearbeitet durch User
Da er ja schon programmieren kann, gib ihm ein C Buch, ein Development Board, die Datenblätter und ein paar Beispiele (source code). Damit sollte jeder Entwickler in absehbarer Zeit klar kommen.
Wenn es irgendwie geht, gib ihm zuerst irgendeine Änderung an einem bestehenden Projekt. Aktuellen Stand aufbauen, Verhalten überprüfen, Änderung machen, neues Verhalten überprüfen. Fingerübungen sind für einen erfahrenen Entwickler nicht so toll.
Sheeva P. schrieb: > Naja, wenn er Java und C# kann, dann weiß er, wie Softwareentwicklung > funktioniert und was Objektorientierung ist Daß ich mal nicht gleich laut lache. Nur weil jemand jahrelang in Java und C# programmiert hat, heißt das noch lange nicht, daß er weiß, was Objektorientierung ist.
Irgendwann wurde ich mal für einen "Feuerwehreinsatz" bei einem Kunden gerufen, weil deren Firmware nicht auf dem Gerät lief. Zunächst erklärte mir der kundenseitige Softwareentwickler (Diplom-Informatiker) seine Firmware. Da steckte eine gewaltige Architektur dahinter, in der etliche Muster aus "Design Patterns" von Gamma et al. umgesetzt wurden. Speicher wurde natürlich immer dynamisch belegt. Und er konnte nicht ansatzweise verstehen, warum die Firmware überhaupt nicht lief, sondern sehr schnell abstürzte. Auf meinen Einwand, dass sein Microcontroller (LPC21xx) nur 2 KB RAM habe und dynamische Speicherallozierung zudem noch zu starker Fragmentierung beitrage, bestand er darauf, dass es sich um einen Druckfehler im Datenblatt und selbstverständlich um 2 MB RAM handele. Es sei schließlich völlig unsinnig, einen Microcontroller mit so wenig RAM herzustellen. Jeder PC habe ja schließlich mehrere Gigabyte RAM und dementsprechend seien ja schon 2 MB sehr wenig. Ich finde es schon ziemlich erschreckend, wie realitätsfremd manche Leute sind. Und noch erschreckender finde ich im konkreten Fall, dass der Entwickler offenbar etliche Monate an der Software schrieb, ohne sie jemals auf dem Microcontroller auszuprobieren. Ansonsten hätte ihm das schon viel früher auffallen müssen. Und es gab natürlich auch keine Zugriffsfunktionalität für die ganze Peripherie, sondern das war alles völlig abstrahiert. Letztendlich zog ich unverrichteter Dinge wieder ab und erfuhr kurze Zeit später, dass der Laden das Projekt/Produkt eingestampft hatte. Der Chef hatte nämlich von Software überhaupt keine Ahnung und vertraute seinem Softwareentwickler. Die Hardware war nämlich nicht selbstentwickelt, sondern wurde von einem anderen Unternehmen übernommen.
:
Bearbeitet durch User
Franko S. schrieb: > Wer stellt denn solche Leute ein? Derjenige arbeitete bei dem Unternehmen hauptsächlich an Datenbankanwendungen auf dicken Servern und sollte sich dann "nur" zusätzlich um die Firmware dieses Geräts kümmern.
Andreas S. schrieb: > zusätzlich um die Firmware dieses Geräts kümmern. …und in der Kantine steht er dann um die Mittagszeit noch an der Essensausgabe um dort mitzuhelfen.
Andreas S. schrieb: > in der etliche Muster aus "Design Patterns" von Gamma et al. umgesetzt > wurden Das geht auch auf relativ kleinen Mikrocontrollern gut. z.B. Observer Pattern, State Pattern, Strategy Pattern. Die kann man so umsetzen dass sie nur statischen Speicher nutzen. Aber man muss eben wissen was man tut. Das muss man bei prozeduraler Programmierung aber natürlich auch.
Franko S. schrieb: > Andreas S. schrieb: >> zusätzlich um die Firmware dieses Geräts kümmern. > …und in der Kantine steht er dann um die Mittagszeit noch an der > Essensausgabe um dort mitzuhelfen. Nein. Der Chef (Nicht-IT-ler) war ja nicht blöd, sondern kannte eben einfach nicht den Unterschied zwischen Applikationsentwicklung und Firmwareentwicklung. Er wird mit Sicherheit auch seinen Mitarbeiter gefragt haben, ob er so etwas beherrsche. Und als es ja die aufgeführten Probleme gab, rief er ja auch recht zügig mich zu Hilfe statt es monatelang auszusitzen. Die unternehmerische Entscheidung, die Produktentwicklung daraufhin einzustampfen statt z.B. jemand Externes mit der Firmwareentwicklung zu beauftragen, war nicht unbedingt verkehrt. Die fertig entwickelte Hardware hatte er für kleines Geld übernommen, nachdem ein bekanntes Großunternehmen einen Geschäftsbereich (und das damit verbundene Tochterunternehmen) geschlossen hatte. Die Hardware selbst war zwar eigentlich sehr solide, aber auch viel zu teuer aufgebaut. Jede Teilkomponente befand sich auf einer eigenen Einsteckkarte. Auch schon damals gab es deutlich modernere Microcontroller, in denen fast alles enthalten gewesen wäre. Eine Änderung des Hardwarekonzeptes hätte aber auch bedeutet, neue Spritzgusswerkzeuge herstellen zu lassen, was die Kosten komplett gesprengt hätte. Man hätte auch nicht auf die Einsteckkarten verzichten können, weil die ganzen Gehäuseöffnungen eben genau dafür ausgelegt waren. Zu Zeiten des Apple II und frühen IBM PC wäre jeder stolz auf solch ein modulares Hardwarekonzept gewesen.
Luky S. schrieb: > Ich bekomme einen mittelalten ( englisch nur so mittelgut :-( ) > Kollegen, der bisher "nur" C# und Java programmiert hat. Jetzt soll ich > ihn irgendwie beschäftigen und anlernen, damit er "bald" (sagt der Chef) > STM32 und AVRs programmieren kann. Nun bin ich auch kein Programmierer, > sondern Elektroniker Rein aus Interesse und ohne bösen Hintergedanken: In welcher Branche ist es üblich, Firmware nebenbei von fachfremden Personal entwickeln zu lassen? Welche Geräte vertreibt ihr?
:
Bearbeitet durch User
Wir sind ein Uniinstitut, also hoffentlich nichts, ist besser so ;-)
Luky S. schrieb: > Ich bekomme einen mittelalten Vermutlich 30, denn denn alles dadrüber ist ja schon zu alt und wird nicht mehr eingestellt.
Luky S. schrieb: > Wir sind ein Uniinstitut, also hoffentlich nichts, ist besser so > ;-) Das erklärt alles.
Franko S. schrieb: > Luky S. schrieb: >> Wir sind ein Uniinstitut, also hoffentlich nichts, ist besser so >> ;-) > > Das erklärt alles. Tja bei uns an der Hochschule gab es im Informatik-Fachbereich auch eine Embedded Systems Spezialisierung... da wäre das nicht passiert 😉
Franko S. schrieb: > …und in der Kantine steht er dann um die Mittagszeit noch an der > Essensausgabe um dort mitzuhelfen. Zu trivial. Da er schon Entwickler ist kann er besser die künftigen AGB entwickeln, oder einen neuen Dachstuhl.
Luky S. schrieb: > Ich bekomme einen mittelalten ( englisch nur so mittelgut :-( ) > Kollegen, der bisher "nur" C# und Java programmiert hat. Jetzt soll ich > ihn irgendwie beschäftigen und anlernen, damit er "bald" (sagt der Chef) > STM32 und AVRs programmieren kann. Wenn er keinerlei Ahnung von Hardware hat, dann ist das ein sehr langer Weg. Selbst wenn er wirklich programmieren kann (und nicht nur libs mergen). Dann kann er zwar (relativ) problemlos auf C++ wechseln und damit den gewohnten Vollkomfort von "managed"-Sprachen halbwegs brauchbar nachbauen, aber natürlich schafft genau dieser Komfort Probleme, die man auf kleinen µC eher nicht gebrauchen kann. Das Hauptproblem dürfte aber das Verständnis der Hardware sein, bzw. dessen Mangel.
Ob S. schrieb: >> Kollegen, der bisher "nur" C# und Java programmiert hat. > > Selbst wenn er wirklich programmieren kann (und nicht nur libs > mergen). Ich habe den Eindruck, dass die Javas ähnlich den Arduinos unterwegs sind, klicken fertige Klassen zusammen, ohne diese zu verstehen. Mit C# kannte ich nur einen Kollegen, der hat sich relativ schnell in C++ eingearbeitet - allerdings PC-Software, nicht embedded hardwarenah.
> Das Hauptproblem dürfte aber das Verständnis der Hardware sein, bzw. > dessen Mangel. Das hängt von der individuellen Lernbereitschaft ab. Ich habe den Wechsel vor langer Zeit situationsbedingt machen müssen. Der eine embedded-Entwickler hat die Firma sehr plötzlich (und vermutlich unfreiwillig) verlassen und ich war von den übrigen Entwicklern der geeignetste. Ein sehr früher Aha-Moment kam, als ich mich gewundert habe, warum ein Ablauf, bei dem ein Relais geschaltet wurde, beim Durchsteppen im Debugger funktioniert, aber ohne Debugger nicht. Da fiel dann plötzlich der Groschen und ich habe im Datenblatt nach Schaltzeiten gesucht.
Ich wiederhole meinen in der ersten Antwort in diesem Thread gemachten Vorschlag: Gib dem Menschen einen Arduino, lass' ihn die üblichen Übungen damit durchspielen (LED-Blinker, serielle Datenübertragung, HD44780-Display ansteuern, Takt auf I/O-Pin erzeugen und den mit Oszi mesen) Ruhig mit der Arduino-IDE und -Sprachumgebung. Wenn er damit zu Potte kommt, dann kann man weitermachen. Damit kann man abschätzen, ob derjenige überhaupt einen Zugang zu Hardware und hardwarenahem Denken hinbekommt. Die nächste Übung wäre, ihn mit dem Arduino-Kram mit einem Baustein reden zu lassen, der Eigenleistung erfordert. Irgendwas, was man mit mehreren I/O-Leitungen ansteuern muss, und irgendwas, wo man ein Ergebnis sehen kann. Und Eigenleistung, weil es dafür eben keinen von anderen vorverdauten Code (sog. "lib") geben sollte. Das bedeutet, daß derjenige ein Datenblatt lesen lernen muss, daß derjenige ein Protokoll zur Ansteuerung eines Bausteins verstehen und selbst entwickeln muss, und daß er entsprechende Messtechnik zur Fehlersuche einsetzen muss - ein Oszilloskop hatte ich schon angesprochen, ein Logikanalysator kann dazukommen, wenn mehr als vier Signale gleichzeitig verwendet werden.
Harald K. schrieb: > Gib dem Menschen einen Arduino, lass' ihn die üblichen Übungen damit > durchspielen (LED-Blinker, serielle Datenübertragung, HD44780-Display > ansteuern, Takt auf I/O-Pin erzeugen und den mit Oszi mesen) > > Ruhig mit der Arduino-IDE und -Sprachumgebung. > > Wenn er damit zu Potte kommt, dann kann man weitermachen. Einem erwachsenen Entwickler? Der bekommt ein aktuelles Projekt, eine Einweisung, wie der Basis auf dem bare-Metal-Prozessor so funktioniert, und Zugriff auf die Sourcen aller bisherigen Projekte, und dann los. Fragen kann der dann immer noch. Oliver
Oliver S. schrieb: > Einem erwachsenen Entwickler? Wenn der bislang nur mit C# und Java unter Windows herumgespielt hat: Ja. Definitiv. Oliver S. schrieb: > Der bekommt ein aktuelles Projekt, eine Einweisung, wie der Basis auf > dem bare-Metal-Prozessor so funktioniert Das kann man sich alles sparen, wenn der sich schon bei der Arduino-Kiste die Finger bricht. Denn sonst wird der gnadenlos scheitern. Alleine schon, weil der die bei bare-Metal-Programmierung üblichen Programmiersprachen weder kennt noch beherrscht.
Harald K. schrieb: > Oliver S. schrieb: >> Einem erwachsenen Entwickler? > > Wenn der bislang nur mit C# und Java unter Windows herumgespielt hat: > Ja. Definitiv. Definitiv nein! Bruno V. schrieb: > Lass ihn echte Arbeit machen und unterstütze ihn dabei. > Dir irgendwelche didaktischen Aufgaben zu überlegen ist verschwendete > Zeit. Ein Studium lebt von intrinsischer Motivation oder dem Vergleich > mit Kommilitonen. Genauso. Echte "leichte" Arbeit und ihn dabei unterstützen. Wie spreche ich die HW an, Controller flashen, Debugger, u.s.w. Wenn du ihm einen Arduino zum Spielen gibt's, wird der sich sehr ernst genommen fühlen und so wird seine Motivation sein. ;) Du könntest ihn fragen, ob er einen Arduino zum Spielen möchte. Wenn ja, gib ihm einen. Grundsätzlich ist es gut zu wissen, wie er sich denn in das neue Thema einarbeiten möchte. Du solltest ihn fragen, nicht dieses Forum.
:
Bearbeitet durch User
900ss schrieb: > Du solltest ihn fragen, nicht dieses Forum. Es ist ja nicht "mein" Softwareentwickler, sondern jemand, den ich nicht kenne, und jemand (der Threadstarter), den ich auch nicht kenne. Mir selbst würde ein etwas ausführlicheres Gespräch mit dem Softwareentwickler genügen, um einschätzen zu können, ob es sich lohnt, ihn an ein Embedded-Projekt zu lassen. Ich hab' da genügend Erfahrung. Aber der Threadstarter offensichtlich nicht, sonst wäre er nicht mit dieser Fragestellung hier angekommen. Und ja, ich würde auch einem "gestandenen" Entwickler einen Arduino in die Hand drücken. Wer da sofort mit Standesdünkel und "ist ja Spielzeug" reagiert, als Entwickler, der bislang nur mit C# und Java hantiert hat, der ist damit schon praktisch aus dem Stand ungeeignet. Den kann ich als zukünftigen Embedded-Entwickler nur schwer ernstnehmen. Eine gute Reaktion auf das Arduino-in-die-Hand-gedrückt-bekommen wäre die Antwort, daß man das lieber in nativem C programmieren wolle, mit Datenblatt und so, um die Grundlagen zu verstehen, und nicht sich vom Arduino-Über- (oder Unter-) Bau ablenken zu lassen. Das würde zeigen, daß derjenige sich zumindest schon irgendwie mit dem Thema auseinandergesetzt hat. Wer aber ohne jede Hardwareerfahrung so etwas ablehnt, und mit Halbwissen-Versatzstücken antwortet, und meint, mir erzählen zu müssen, ohne richtiges RTOS und Multicore-Unterstützung würde er gar nicht erst anfangen wollen ... der hätte es nicht so besonders leicht mit mir.
Ich werde ihn sicher dann fragen, was er kann und möchte. Arduino gibts aber mit an Sicherheit grenzender Wahrscheinlichkeit keinen, er soll schon mit einem Debugger umgehen lernen. Irgend ein STM32 Nucleo und analoge Sensoren wirds wohl für den Anfang werden, idealerweise noch ein Display dazu. Danke für die Anregungen!
900ss schrieb: > Du könntest ihn fragen, ob er einen Arduino zum Spielen möchte. Wenn ja, > gib ihm einen. Welcher technisch interessierte Mann ist "unter der Haube" kein Spielkind?
Sherlock 🕵🏽♂️ schrieb: > Welcher technisch interessierte Mann ist "unter der Haube" kein > Spielkind? Ich stimme dir vollkommen zu :) Aber dieses ist nicht der Basteltisch ;)
Andreas S. schrieb: > Auf meinen Einwand, dass sein Microcontroller (LPC21xx) nur 2 > KB RAM habe und dynamische Speicherallozierung zudem noch zu starker > Fragmentierung beitrage, bestand er darauf, dass es sich um einen > Druckfehler im Datenblatt und selbstverständlich um 2 MB RAM handele. > Es sei schließlich völlig unsinnig, einen Microcontroller mit so wenig > RAM herzustellen. Jeder PC habe ja schließlich mehrere Gigabyte RAM und > dementsprechend seien ja schon 2 MB sehr wenig. Abt: Kognitive Dissonanz bzw. ihre reflexartige Bereinigung. In der Spielebranche ist es gerade so, dass wenn ein Spiel (über 5 Jahre Entwicklungsarbeit) nicht gut geworden ist, dann sind die Spieler mit ihren haushohen Erwartungen schuld. Das stimmt insofern indirekt, weil früher gewisse Dinge einfacher waren, und viele mehr und auch viel bessere talentiertere Leute mitentwickelt hatten. Zum lesen für den TO-Kollegen wäre auch K+R-C gut, Erlenkötter C auch, weil es didaktisch aufgebaut ist, und der Inhalt ganz gut zusammengestellt wurde. Dann vielleicht noch Algorithmen in C von Robert Sedgewick. Neben dem Praxiskurs kann man auch noch die Artikelsammlung hier begutachten. https://www.mikrocontroller.net/articles/Absolute_Beginner-AVR_Steckbrettprojekte
Rbx schrieb: > Zum lesen für den TO-Kollegen wäre auch K+R-C gut Aber nur, wenn das die zweite Ausgabe ist, die eben nicht K&R-C beschreibt, sondern C89 (damals auch "ANSI-C" genannt). Die erste Ausgabe beschreibt nur das aus guten Gründen vergessenswerte K&R-C, das keine Funktionsprototypen und damit auch keine Typprüfung kannte, und ist obendrein in der deutschen Übersetzung ein beeindruckend schlechtes Buch (wirkt wie eine schlechte maschninelle Übersetzung und Codebeispiele sind in Proportionalschrift gesetzt). Abzuraten ist hingegen von allem, was ein gewisser "Schellong" geschrieben hat.
Da der Kandidat ja sowieso schon OOP-Sprachen beherrscht, macht es sehr viel Sinn direkt zu C++ zu gehen. C ist halt eben eine recht limitierte Sprache mit wenigen Möglichkeiten, komplexe Programme zu strukturieren. Viele der dem Kandidaten sicherlich bekannten Paradigmen zur Software-Architektur lassen sich wunderbar direkt auf C++ übertragen. Da den Umweg über C zu gehen hat wenig Mehrwert. Da allerdings schon viel vorhandener Code in C geschrieben ist sollte man das schon lesen können; das ergibt sich aber nahezu von alleine wenn man C++ kann.
Niklas G. schrieb: > Da der Kandidat ja sowieso schon OOP-Sprachen beherrscht, macht es sehr > viel Sinn direkt zu C++ zu gehen. Setzt halt voraus, daß das Zielsystem das kann. Und setzt voraus, daß dem OOP-Programmierer klar ist, daß hinter einer simplen Zuweisung sehr, sehr viel Code stecken kann. Gerade bei Leuten, die nur auf normalen PCs gearbeitet haben, und dann auch noch mit eher stark abstrahierenden Sprachen wie C# oder Java, sehe ich da durchaus ... Nachholbedarf. Dazu kommt, daß viele in C++ oder auch anderen OOP-Sprachen vollkommen übliche Konstrukte auch mit dem Erzeugen und Zerstören von Objektinstanzen einhergehen, was etwas ist, was aufgrund der dafür nötigen dynamischen Speicherverwaltung nicht unbedingt zu jedem Microcontroller passt, um es vorsichtig zu formulieren. Dann ist der grundlegende Programmierstil vieler Entwickler gerade aus dem Java-Umfeld nicht frei von Problemen - wer gewohnt ist, Probleme dadurch zu lösen, da0 einfach irgendein fettes Framework verwendet wird, noch ein Sackvoll Libraries drauf geworfen werden und dann so etwas wie Maven dafür sorgt, daß mit dem selbstgeschriebenen Glue-Code irgendwo ein lauffähiges *.jar rausfällt, der wird sich bei Microcontrollern recht heftig und gründlich umgewöhnen müssen. Insofern ist der "Abstieg" in reines C hilfreich, weil da eben nicht eine simple Zuweisung durch Operatorüberladung die halbe Weltgeschichte nacherzählt. Und da kommt wieder der simple Arduino ins Spiel, insbesondere, wenn es ein AVR-basierender Arduino ist: So ein Ding ist dermaßen knapp mit Ressourcen ausgestattet, daß ungünstiger Code einem sehr schnell auf die Füße fällt.
Harald K. schrieb: > Setzt halt voraus, daß das Zielsystem das kann. Können die meisten aktuellen Controller. Man muss ja nicht gleich 8051 nehmen. Harald K. schrieb: > Und setzt voraus, daß dem OOP-Programmierer klar ist, daß hinter einer > simplen Zuweisung sehr, sehr viel Code stecken kann. Das ist sowieso klar weil jeder OOP-Programmierer weiß wie man Operatoren überlädt. Harald K. schrieb: > Zerstören von Objektinstanzen einhergehen, was etwas ist, was aufgrund > der dafür nötigen dynamischen Speicherverwaltung Das ist dazu nicht nötig. Man kann Instanzen statisch allokieren und erzeugen/zerstören. std::optional macht das so. Harald K. schrieb: > wer gewohnt ist, Probleme dadurch zu lösen, da0 einfach irgendein fettes > Framework verwendet wird Das kommt bei Mikrocontrollern auch immer mehr. Mal eben seinen eigenen IP-Stack oder Bluetooth-Implementation schreibt keiner. Also gut wenn man sich in sowas schnell einarbeiten kann. Harald K. schrieb: > Und da kommt wieder der simple Arduino ins Spiel, Arduino ist C++ und nutzt das auch aus. Da werden sogar Objektinstanzen erstellt.
Niklas G. schrieb: > Das ist sowieso klar weil jeder OOP-Programmierer weiß wie man > Operatoren überlädt. Er weiß, wie er Operatoren überlädt, klar, aber was das kostet, das ist ihm, der fettes Blech gewohnt ist, halt eben nicht klar. Sieh Dir doch an, wie heutige von an der "bleeding edge" entwickelnden Menschen erzeugte Software aussieht. Und sieh Dir an, was mittlerweile für Performance in jedem popeligen Mobiltelephon oder Desktoprechner steckt, da denkt doch niemand mehr drüber nach, was das eigentlich bedeutet. Und wenn so jemand mit der harten Realität von 2 kB RAM und 16 kB Flash-ROM konfrontiert wird, ist das Erwachen ... interessant.
Harald K. schrieb: > Und wenn so jemand mit der harten Realität von 2 kB RAM und 16 kB > Flash-ROM konfrontiert wird, ist das Erwachen ... interessant. Das ist ein Uni-Institut. Die bauen keine Serienelektroniken in Milliardenstückzahlen, wo es auf tausendstel Cent ankommt, die basteln Einzelstücke. Wer sich dabei mit zu wenig RAM und zu wenig Leistung grundlos selber unter Druck setzt, hat den Schuß nicht gehört. Oliver
Naja wir bauen auch (Ultra) Low Power Sachen / Energy Harvesting, "IoT" / ... also RAM und Rechenleistung zu verschenken gibts da nicht.
Luky S. schrieb: > RAM und Rechenleistung Steht im Übermaß für kleinstes Geld zur Verfügung. 'Race to sleep' mit einer modernen MCU macht meist Sinn. Halbe Leistungsaufnahme ist ein schwaches Argument, wenn das Energiesparwunder dafür 5mal so lange für die Aufgabe braucht. HAL, HW Konfigurator und er wird mit den HW registern nicht mehr viel am Hut haben. Letztlich sind wartbare Projekte auch wichtiger als der geniale ASM Kniff auf einer grausam begrenzten MCU, der einzig vom 'Genius' verstanden wird und das auch nur, wenn es nicht zu lange her ist. Projekte haben die Eigenart über die Zeit im Funktionsumfang zu wachsen. Wohl dem der sich nicht schon bei der MCU Auswahl die Karten legt. Warum machst Du nicht Projekte mit dem neuen Kollegen zusammen? Was er mit Sicherheit besser kann ist eine wartbare und wiederverwendbare Struktur zu erschaffen, wo unsereins sich Code zusammenklöppelt der die derzeitige Aufgabe irgendwie erledigt. Er kann Dir sicher auch neue Sichtweisen vermitteln.
Wird eine ziemliche Aufgabe, es wäre viel leichter, wenn ich schon einen Embedded-Spezialisten hättet, um den neuen Kollegen anzulernen. Uniinstitut->Das arme Steuergeld Making Embedded Systems: Design Patterns for Great Software https://amzn.eu/d/hVyn9QY Making Embedded Systems: Design Patterns for Great Software (English Edition) https://amzn.eu/d/9bha1YA
Harald K. schrieb: > Er weiß, wie er Operatoren überlädt, klar, aber was das kostet, das ist > ihm, der fettes Blech gewohnt ist, halt eben nicht klar. Aber bei normalen Funktionsaufrufen ist das kein Problem? Bei "addData(int*)" weiß der C-Programmierer automatisch wie dick das Blech ist? Harald K. schrieb: > Und wenn so jemand mit der harten Realität von 2 kB RAM und 16 kB > Flash-ROM konfrontiert wird, ist das Erwachen ... interessant. Dann nimmt man halt einen größeren Controller, der Preis spielt nur bei großen Serien eine Rolle. Luky S. schrieb: > Naja wir bauen auch (Ultra) Low Power Sachen / Energy Harvesting, "IoT" > / ... also RAM und Rechenleistung zu verschenken gibts da nicht. Selbst genau dafür gibt es große Frameworks mit "überladenen Operatoren" und es funktioniert. z.B. für LoRaWAN oder BLE. Das programmiert keiner zu Fuß. Michael schrieb: > Letztlich sind wartbare Projekte auch wichtiger als der geniale ASM > Kniff auf einer grausam begrenzten MCU, Genau so ist es.
Moin, Mein erstes Arbeitsprojekt mit PIC uC war eine bescheidene RTU Anwendung, wo 20 Relais über RS-485 ferngesteuert, geschaltet werden sollten. Der PI16F877A hatte nur 368 Bytes an SRAM. Programmierung war in C (CCS). Ging alles gut von statten und hatte noch 70% SRAM übrig. Heute, wenn ich dort mit STM32 Projekte mache und einige hundert K an Speicher habe, denke ich immer noch daran, keinen Speicherplatz gedankenlos oder leichtfertig zu verschwenden. Mit dieser Einstellung fahren meine Kollegen und ich ganz gut in der Firma. Ich bin der Meinung, daß man mit ihm ein gemütliches Gespräch über seine Vorstellung vom Ansatz machen könnte und dann kollegial Vor- und Nachteile des möglichen Angriffs bespricht. Ihm einen Arduino zum Spielen übergeben, finde ich auch nicht so schlecht. Da bekommt er dann ein Gefühl dafür, wieviel kleiner die Ressourcen beim uC sind. Beim 328er muß er ja im niedrigen KB Bereich jonglieren. Ich sehe die Situation des Fragestellers eigentlich recht locker. Man sollte mit den Vorurteilen eher vorsichtig umgehen:-) Gruß, Gerhard
Manchmal ist ein geeigneter Lehrgang am Ende billiger als Wochen vertrödelter Zeit. Man kann ja trotzdem zukunftsorientiert etwas leistungsfähigere Hardware beschaffen. Später wachsen immer die Wünsche der Kunden.
Lu schrieb: > Später wachsen immer die Wünsche > der Kunden. Ingenieures Denken: möglichst viele Optionen nachrüstbar. Kaufmanns Denken: Geil, richtig viel Umsatz!
Frank O. schrieb: > Lu schrieb: >> Später wachsen immer die Wünsche >> der Kunden. > > Ingenieures Denken: möglichst viele Optionen nachrüstbar. > Kaufmanns Denken: Geil, richtig viel Umsatz! Wie überaus schade, daß Ingenieure selten auch wie Kaufleute, und Kaufleute selten auch wie Ingenieure denken. Denn mit möglichst vielen Optionen lassen sich möglicherweise größere Umsätze erzielen, und mit denen werden dann unser aller Gehälter erwirtschaftet... Nenn mich verrückt, aber ich bin der festen Überzeugung, daß das möglich ist und die Zusammenarbeit beider Seiten häufig sogar viel einfacher, angenehmer und profitabler machen kann. :-)
Sheeva P. schrieb: > daß Ingenieure selten auch wie Kaufleute, und Kaufleute selten auch wie > Ingenieure denken In großen Unternehmen sind die beiden Bereiche so weit voneinander entfernt dass man gar nicht miteinander in Berührung kommt und in diesen Dimensionen denken kann. Das ist das schöne an kleinen Unternehmen; man kommt viel mehr in Kontakt miteinander und alle müssen die anderen Bereiche auch mitdenken. Dazu gehört auch die "product ownership"; die Entwickler müssen auch über die wirtschaftlichen Aspekte nachdenken weil es sonst keiner macht, haben dadurch aber mehr Gestaltungsspielraum. Die Entwickler können sogar direkten Kundenkontakt haben...
Niklas G. schrieb: > Sheeva P. schrieb: >> daß Ingenieure selten auch wie Kaufleute, und Kaufleute selten auch wie >> Ingenieure denken > > In großen Unternehmen sind die beiden Bereiche so weit voneinander > entfernt dass man gar nicht miteinander in Berührung kommt und in diesen > Dimensionen denken kann. > > Das ist das schöne an kleinen Unternehmen; man kommt viel mehr in > Kontakt miteinander und alle müssen die anderen Bereiche auch mitdenken. > Dazu gehört auch die "product ownership"; die Entwickler müssen auch > über die wirtschaftlichen Aspekte nachdenken weil es sonst keiner macht, > haben dadurch aber mehr Gestaltungsspielraum. Die Entwickler können > sogar direkten Kundenkontakt haben... Das bestätige ich 100%. Ich würde es auch nicht anders haben wollen. Diese Art von Kollaboration übt "out of the box" zu denken und manchmal ergeben sich interessante Synergie-Aspekte die zu innovativen Unterlösungen führen. Gerade bei kollegialen Besprechungen gibt es dann Momente wie, wenn Du das ein bisschen anders machst, ergeben sich Vorteile. Das finde ich ganz zielführend. Auch die beste Planung wird manchmal wegen der Vorgaben in eine "dunkle" Box gezwängt, ohne innovative Aspekte bzw Synergies berücksichtigen zu können, weil man die Details und Zusammenhänge oft einfach noch nicht richtig erkennt oder einschätzt. Tiefes Verständnis kommt meist erst während der Einarbeitung in die Details der Materie.
Gerhard O. schrieb: > Diese Art von Kollaboration übt "out of the box" zu denken und manchmal > ergeben sich interessante Synergie-Aspekte die zu innovativen > Unterlösungen führen. Ja, und wenn man keine Auftragsentwicklung macht sondern ein fertiges Serienprodukt für den offenen Markt entwickelt, ist es ja bekanntlich gar nicht so einfach zu entscheiden, was man eigentlich genau entwickeln möchte, was sich gut verkauft. Rein marktbasierte Überlegungen reichen da aber nicht unbedingt; wenn die Entwickler hier noch technische Parameter mit einbeziehen, z.B. auch Konkurrenzprodukte analysieren, oder eben clevere Kombinationen/Synergien der gegebenen technischen Möglichkeiten finden oder Optimierungspotenziale identifizieren an die bisher keiner gedacht hat, kann man ein gutes "rundes" Produktdesign erreichen. Dazu ist es aber natürlich wichtig, dass man da den Einschätzungen der Entwickler auch Glauben schenkt.
Niklas G. schrieb: > Gerhard O. schrieb: >> Diese Art von Kollaboration übt "out of the box" zu denken und manchmal >> ergeben sich interessante Synergie-Aspekte die zu innovativen >> Unterlösungen führen. > > Ja, und wenn man keine Auftragsentwicklung macht sondern ein fertiges > Serienprodukt für den offenen Markt entwickelt, ist es ja bekanntlich > gar nicht so einfach zu entscheiden, was man eigentlich genau > entwickeln möchte, was sich gut verkauft. Da haben wir es leichter, weil die Mehrzahl unserer Produkte Auftragsentwicklungen in industriellen Anwendungen der Energietechnik sind. Da sind die Vorgaben und Zulassungen sehr definiert. Allerdings sind die Sicherheits-Prüfungsanforderungen da sehr strikt und verschlingen sehr viel Gehirnschmalz. Auch verursachen irgendwelche Schaltungsmodifizierungen oder Bauteileänderungen durch Marktlage große "Erschütterungen", weil alles offiziell dokumentiert werden muß und Nachzulassungen erforderlich macht. > > Rein marktbasierte Überlegungen reichen da aber nicht unbedingt; wenn > die Entwickler hier noch technische Parameter mit einbeziehen, z.B. auch > Konkurrenzprodukte analysieren, oder eben clevere > Kombinationen/Synergien der gegebenen technischen Möglichkeiten finden > oder Optimierungspotenziale identifizieren an die bisher keiner gedacht > hat, kann man ein gutes "rundes" Produktdesign erreichen. Das betrifft uns wenig. > > Dazu ist es aber natürlich wichtig, dass man da den Einschätzungen der > Entwickler auch Glauben schenkt. Tut man hier auch.
Gerhard O. schrieb: > Da sind die Vorgaben und Zulassungen sehr definiert. Genau deswegen kann es sinnvoll sein, die Kiste gleich eine Nummer größer zu wählen und zu zertifizieren. Das kann Zeit sparen, weil man nur ein Stück SW weiterentwickeln muß und nicht wieder beim Urschleim mit neuer HW anfängt.
Gerhard O. schrieb: > keinen Speicherplatz > gedankenlos oder leichtfertig zu verschwenden. Wobei C ja genau das ist, wenn man so ein höhersprachiges Programm mal im Hexeditor ansieht. Ich kannte mal ein C-Programm, das hieß "Peep-Hole-Optimizer". Trotzdem ist ein Hexeditoredit um Längen besser als dieser Ansatz. Oder auch: Profiler-Output-Analysen: Die drehen sich meist darum, Bottlenecks abzuarbeiten. Vom Platz sparen hört man diesbezüglich eher weniger. Definitiv besser ist natürlich die Kommunikation wie auch die Standardisierung in C. Nur: Gelegentlich rückt die Assembler-Perspektive gewisse Dinge und Zusammenhänge bei der Programmierung viel besser ins Licht, als C das je könnte.
Rbx schrieb: > Nur: Gelegentlich rückt die Assembler-Perspektive gewisse Dinge und > Zusammenhänge bei der Programmierung viel besser ins Licht, als C das je > könnte. Diese Fälle sind heutzutage sehr, sehr selten anzutreffen, wohingegen heutige Compiler so gut optimieren, dass man es mit handgeschriebenem Assembler nicht mehr hinbekäme. Insbesondere hat ein Compiler die Registernutzung viel besser im Überblick und verwendet sie dementsprechend auch "mehrfach", wohingegen mna als Programmierer wesentlich stärker auf sauberen Code achtet, um sich nicht zu verheddern und die Erweiterbarkeit zu verbessern. Der Compiler hingegen muss beim nächsten Kompilieren keine Rücksicht auf die alte Registerverwendung nehmen. Nur für die Einsprünge in und Rücksprünge aus Funktionen muss sich der Compiler an die jeweiligen Konventionen (z.B. ATPCS) halten; bei rein als static definierten Funktionen, die ja keine Sichtbarkeit außerhalb des jeweiligen Moduls besitzen (sollten), darf er sogar hier ansetzen und das ganze optimieren. Natürlich findet man auch heutzutage noch irgendein Konstrukt, das ein erfahrener Assembler-Programmierer besser gelöst bekommt; das als Beleg dafür zu nehmen, Compiler wären immer noch so doof wie vor zwanzig Jahren, wäre lächerlich. Ich habe übrigens erst vor wenigen Wochen mal wieder ein paar Zeilen Assembler geschrieben, und zwar für die Speicherinitialisierung einer Laufzeitumgebung.
Andreas S. schrieb: > Natürlich findet man auch heutzutage noch irgendein Konstrukt, das ein > erfahrener Assembler-Programmierer besser gelöst bekommt; das als Beleg > dafür zu nehmen, Compiler wären immer noch so doof wie vor zwanzig > Jahren, wäre lächerlich. Da ist was dran, "irgendein Konstrukt" würde ich zwar nicht sagen - aber z.B. beim ARM ist doch der Asm-Code so einschläfernd (kaum Variation) dass allein das schon ein guter Grund ist, einen bewährten Compiler (bzw. Programmiersprache) einzusetzten. Aber auch gerade da kann man ja zumindest mal nachsehen, wie der Compiler mit gewissen Hardware-Gegebenheiten umgeht. Nicht zuletzt kann man ja sogar aus dem Disassembly lernen.
Andreas S. schrieb: >> Gelegentlich rückt die Assembler-Perspektive gewisse Dinge und >> Zusammenhänge bei der Programmierung viel besser ins Licht, als C das je >> könnte. > Diese Fälle sind heutzutage sehr, sehr selten anzutreffen, wohingegen > heutige Compiler so gut optimieren, dass man es mit handgeschriebenem > Assembler nicht mehr hinbekäme. Ich denke, er meint damit nicht, wie gut der Code optimiert wurde, sondern wie gut der Programmierer vor dem Bildschirm versteht, was in der Maschine passiert, wenn er dies oder das programmiert. Mir ist z.B. völlig klar, dass die Nutzung von Fließkomma-Zahlen meistens erheblich aufwändiger als Integer ist. Oder das das zusammen Stückeln (insbesondere Einfügen in) Strings oft teurer ist, als dessen Ausgabe in mehrere Fragmente zu zerlegen. Meinen Java Kollegen war das gar nicht klar.
Niklas G. schrieb: > In großen Unternehmen sind die beiden Bereiche so weit voneinander > entfernt dass man gar nicht miteinander in Berührung kommt und in diesen > Dimensionen denken kann. Gerade in Großunternehmen finden sich aber Unmengen an drittklassigen Leuten im mittleren Management, deren Standardargument lautet: "Der Kunde will das aber genau so haben!". Nein, diesen angeblichen Kunden gibt es nicht, vielleicht höchstens noch in der Phantasie. Oder irgendeine Behauptung wird jemandem ("die da oben") untergeschoben; ich habe mich bei allzu offensichtlichen Lügen bzw. Falschbehauptungen auch schon erdreistet, vorzuschlagen, einfach mal denjenigen direkt zu fragen, ob er das genau so sagte oder meinte. Dann wurde ziemlich schnell zurückgerudert, weil der derjenige genau wusste, dass ich dann tatsächlich nachfragen würde. Oder es wird gedroht: "Derjenige mag es überhaupt nicht, von Dritten gestört zu werden! Lassen Sie das lieber sein, denn sonst wird derjenige <blabla>." Und bei der erfolgenden Rückfrage stellt sich aber heraus, dass der betreffende Geschäftführer/Vorstand o.ä. es eher überhaupt nicht mag, dass ihm seine Leute solche Behauptungen unterstellen.
Sherlock 🕵🏽♂️ schrieb: > Mir ist z.B. völlig klar, dass die Nutzung von Fließkomma-Zahlen > meistens erheblich aufwändiger als Integer ist. Nicht nur das. Es kann ja teilweise auch total viel Spaß machen, gerade gewisse Fließkomma-Rechen-Übungen in eine Integer-Rechnung zu übertragen.
Sherlock 🕵🏽♂️ schrieb: > dass die Nutzung von Fließkomma-Zahlen > meistens erheblich aufwändiger als Integer ist Kommt drauf an; wenn eine FPU vorhanden ist sind viele floating-point-Operationen durchaus effizient. Ganz besonders wenn es eine Vector-FPU ist (z.B. ARM NEON). Manche Dinge (z.B. Konvertierung mit Int) aber nicht... Andreas S. schrieb: > offensichtlichen Lügen bzw. Falschbehauptungen Das ist wohl der übliche Wahnsinn in großen Organisationen und hat dann mit technischen Aspekten nicht mehr viel zu tun, bzw. schadet allen Bereichen.
:
Bearbeitet durch User
Rbx schrieb: > Es kann ja teilweise auch total viel Spaß machen, gerade > gewisse Fließkomma-Rechen-Übungen in eine Integer-Rechnung zu > übertragen. Mir haben schon so oft Überläufe und Rundungsfehler ein Bein gestellt, daß mein Bedarf an solchen Spielchen lebenslang gedeckt ist. Und außerdem ist eine float Division auf einem 8-Bitter sogar schneller als mit 32Bit integer, da float nur 23 Bit Mantisse berechnen muß.
Peter D. schrieb: > Mir haben schon so oft Überläufe und Rundungsfehler ein Bein gestellt, > daß mein Bedarf an solchen Spielchen lebenslang gedeckt ist. Das ganze Fachgebiet der Numerik beschäftigt sich damit, trotz dieser Ungenauigkeiten auf gute Ergebnisse zu kommen 😉
Andreas S. schrieb: > Gerade in Großunternehmen finden sich aber Unmengen an drittklassigen > Leuten im mittleren Management Das mittlere Management entscheidet nicht. Die führen aus was man ihnen aufgetragen hat und arbeiten der Entscheidungsebene zu. Exzellente Techniker kommen nicht ins mittlere Management. Die braucht man viel zu sehr an der Basis. Erstklassige Manager bleiben auch nicht im mittleren Management. Es liegt also in der Natur der Sache das sich im mittleren Management ein bestimmter Schlag Mensch häuft. Oft nicht gerade der den man da gerne als Chef hat. Auch deren Chefs wissen das. Die wollen aber keinen richtig Guten dort sehen, weil der dann ihnen den Job streitig macht. In Klitschen fällt das nur mehr auf, weil man sich nicht so gut hinter den Abläufen und Zuständigkeitsgerangel verstecken kann. Und da in Klitschen der Boss oft am Gewinn beteiligt ist, gibts eine Grenze wie teuer so einer sein darf in seiner Unfähigkeit. Mittelchef wird man aufgrund politischer Überlegungen. Und wer mal Chef war, wird nichts anderes mehr. Auch wenn der scheisse ist, gehts fast nie zurück an die Werkbank. Hat also alles nicht so viel mit herausragender Leistung zu tun. Ist mehr ein Verwaltungsposten. Unternehmen werden nur noch sehr selten von Technikern geführt. Warum sollte also der 'kleine Chef' ein guter Techniker sein? Kann der BWLer doch überhaupt nicht bewerten.
Frank E. schrieb: > Mit C# und Java hat er zumindest das Prinzip OOP verstanden, was > will > man mehr? Möglicherweise fehlt ihm nur die notwendige Hardware-Nähe, > aber da bist du ja der Experte. Klingt nach einem DreamTeam :-) Nur weil man in objektorientierten Sprachen programmiert, muss man die Objektorientierung nicht verstanden haben. Ich kenne Leute, die es nicht verstanden haben.
Rudi R. schrieb: > Nur weil man in objektorientierten Sprachen programmiert, muss man die > Objektorientierung nicht verstanden haben. Es wird auch behauptet, wer erstmal C gelernt hat, hat es mit C++ besonders schwer. Für meinen Teil kann ich das gut nachvollziehen. Ich kriegt ja schon Probleme, bei mehr als 2 Macroinstanzen den Durchblick zu behalten. Bei Klassen, Vererbung, Überladen usw. gehen mir Signalfluß und Ablauf völlig verloren.
Peter D. schrieb: > Bei Klassen, Vererbung, Überladen usw. gehen mir Signalfluß und Ablauf > völlig verloren. Das ist nich harmlos. Schau dir mal an was Java EE mit Annotationen anstellt.
Peter D. schrieb: > Ich kriegt ja schon Probleme, bei mehr als 2 Macroinstanzen den > Durchblick zu behalten. > Bei Klassen, Vererbung, Überladen usw. gehen mir Signalfluß und Ablauf > völlig verloren. Sherlock 🕵🏽♂️ schrieb: > Schau dir mal an was Java EE mit Annotationen anstellt. Da empfehle ich ein Informatik-Studium, dort wird gezeigt wie man diese Tools nutzt um effizient komplexe Software-Architekturen umzusetzen.
Niklas G. schrieb: > Da empfehle ich ein Informatik-Studium, dort wird gezeigt wie man diese > Tools nutzt um effizient komplexe Software-Architekturen umzusetzen. Zu meiner Studienzeit wurden nur hoch theoretische Ansätze erklärt. Die Lösung praktischer Steuerungsaufgaben wurde nicht angekratzt. Ist allerdings auch schon 40 Jahre her. Programmiert wurde in Fortran.
Peter D. schrieb: > Zu meiner Studienzeit wurden nur hoch theoretische Ansätze erklärt. Bei mir war das schon ziemlich praxisnah und ich weiß dass die gezeigten Methoden durchaus genau so genutzt werden. Genug Übung gab es natürlich nicht, das darf man dann selbst machen. Einige der theoretischen Dinge haben sich viel später an ganz unerwarteten Stellen plötzlich als nützlich erwiesen. Was wäre denn so ein hoch-theoretischer Ansatz? Peter D. schrieb: > Ist > allerdings auch schon 40 Jahre her. Programmiert wurde in Fortran. Also lange bevor OOP in Fortran eingeführt wurde - was für Ansätze waren das dann?
:
Bearbeitet durch User
Niklas G. schrieb: > Was wäre denn so ein hoch-theoretischer Ansatz? Damals(tm) in den 1980er und 1990er Jahren musste doch jeder Professor eine neue, völlig revolutionäre Programmiersprache definieren, die auch unmittelbar vor dem großen Durchbruch stünde. Dazu gabe es dann noch ein paar Diplomarbeiten mit Versuchen, einen passenden Compiler oder Interpreter zu bauen. Und dann hat man nie wieder etwas davon gehört. Man kann hierbei Programmiersprache auch durch Beschreibungssprache ersetzen.
:
Bearbeitet durch User
Andreas S. schrieb: > Damals(tm) in den 1980er und 1990er Jahren musste doch jeder Professor > eine neue, völlig revolutionäre Programmiersprache definieren Naja, es werden öfter mal neue Programmiersprachen erfunden die dann auch funktionieren und weite Verbreitung finden, z.B. Swift oder Kotlin. Das ist jetzt erstmal keine hoch-theoretische Angelegenheit. Im Embedded-Bereich hält sich C zwar hartnäckig, aber mit C++ gibt es schon lange eine Alternative und Rust wird hier wahrscheinlich früher oder später auch Einzug halten.
Niklas G. schrieb: > Im Embedded-Bereich hält sich C zwar hartnäckig, aber mit C++ gibt es > schon lange eine Alternative Ich sehe C++ nicht als Alternative, sondern als Add-On zu C.
:
Bearbeitet durch User
Sherlock 🕵🏽♂️ schrieb: > Ich sehe C++ nicht als Alternative, sondern als Add-On zu C. Wenn man davon ausgeht dass man in C geschriebene existierende Frameworks/Bibliotheken nutzen muss, dann ja. Wobei viele Bibliotheken sowieso zu C++ kompatibel sind. Wenn man den gesamten Code selbst schreibt, kann man auch komplett C++ nutzen, da gibt es sehr wenig Grund C mit hinein zu mischen.
Ich würde es mir einfach machen: Besorge ihm eine Entwicklungsumgebung mit einem ähnlichen Prozessor drauf und dem nötigen Drumherum dazu. Ist euer Teil nicht zu exotisch, so sollte sich auch ausreichend Literatur (und Beispiele) dazu finden lassen. Gib ihm ein paar Anfängertipps und dann siehst Du schon sehr bald, ob der Typ in der Lage ist umzudenken.
Rbx schrieb: > Sherlock 🕵🏽♂️ schrieb: >> Mir ist z.B. völlig klar, dass die Nutzung von Fließkomma-Zahlen >> meistens erheblich aufwändiger als Integer ist. > > Nicht nur das. Es kann ja teilweise auch total viel Spaß machen, gerade > gewisse Fließkomma-Rechen-Übungen in eine Integer-Rechnung zu > übertragen. Gerade beim Arduino ohne Fließkommaeinheit kann das richtig viel Geschwindigkeit bringen. Ein Polynom 10. Ordnung habe deshalb mal auf die vier Grundrechenarten umgebaut und es war dann 90 mal schneller. Allerdings sind die vorhandenen Libraries oft nicht wirklich auf Geschwindigkeit getrimmt. Oder sie sind auch einfach falsch.
Niklas G. schrieb: > Da empfehle ich ein Informatik-Studium, dort wird gezeigt wie man diese > Tools nutzt um effizient komplexe Software-Architekturen umzusetzen. Wo hast du denn diesen Unsinn aufgeschnappt?
Franko S. schrieb: > Wo hast du denn diesen Unsinn aufgeschnappt? Lass gut sein. Er wollte damit nur verklausuliert sagen, dass irgend jemand (vermutlich ich) dumm ist. Nach 25 Jahren Arbeit mit Java Web Anwendungen perlt das geschmeidig an mir ab.
Franko S. schrieb: > Wo hast du denn diesen Unsinn aufgeschnappt? Im Informatik-Studium. Sherlock 🕵🏽♂️ schrieb: > Er wollte damit nur verklausuliert sagen, dass irgend jemand (vermutlich > ich) dumm ist. Kristallkugel ist frisch repariert?
Hier ist schon viel Text geflossen, dennoch my 2 cents:
Mit Java und C# (somit sollte auch C/C++ Wissen vorhanden sein) ist
schonmal ein guter Grundstock vorhanden.
Was es jetzt zu lernen gilt, sind die viel viel kleineren Dimensionen in
RAM und Flash, sowie das Konzept, Register anzusprechen um
Hardwarefunktionen auszulösen, dazu das Konzept von Interrupts und DMA.
Dafür ist einiges an Mischverständnis aus Elektrotechnik und Informatik
nötig, was zusammen sicherlich gut erarbeitbar ist.
In den meissten Fällen werden Mikrocontroller rein in C und "while(1) {
... } programmiert, da dies am übersichtlichsten ist. Damit kann man
sicherlich anfangen und kommt schon sehr weit. Bei größeren Projekten
endet das dann im Spahetticode mit sehr vielen globalen Variablen zur
Steuerung.
Ich habe sehr schnell (vor allem auf Arm Cortex-M) die Vorzüge eines
RTOS schätzen gelernt, der Umgang mit Threads und Messages zeigt
schnell, wie viel Leistung wirklich benötigt wird, und wo man noch
Reserven hat. Ausserdem vereinfacht es die Umsetzung komplexerer
Aufgaben ungemein, zumal ich auf eine grafische Auswertung des Thread-
und Interruptverhaltens zurückgreifen kann.
Durch meinen Sprung von C nach C++ auf den kleinen Dingern wurde es dann
wirklich interessant, da die Kapselung auch von Methoden in Objekte
sowie Vererbung einen gewaltigen Vorteil bei der Übersichtlichkeit
bringen kann. Auch ist es einfach, einem Objekt-Thread eine Message
mithilfe des RTOS zu schicken, somit entfällt ein Grossteil globaler
Flag-Variablen.
Mein aktuelles embedded Projekt (STM32F4) hat überhaupt keine globalen
Variablen mehr, sondern ausschließlich Objekte (viele global
erreichbar), welche mit Messages kommunizieren.
Dennoch, hoch ist der "shoot-in-the-foot-Faktor":
- Heap vermeiden (ich habe immer einen "replacer" für malloc, vgl.
$sub/super, falls kein "weak" vorhanden ist, zur Kontrolle vor dem eig.
malloc)
- Achtung bei STL: std::list ist ok, std::map benötigt auch bei const
gut 2k RAM zur Initialisierung. Es gibt embedded Versionen dieser
Libraries. Ansonsten sind vorgefertigte Standard-Container keine
schlechte Idee.
- Nicht einfach so "on the fly" Objekte erzeugen, immer den Speicher im
Blick halten. Für die Kapselung ist es schon ein Gewinn, Objekte zur
Compiletime zu erzeugen.
- und wie immer: Daten möglichst const, wenn sie sich nicht ändern
Ich persönlich bevorzuge zusätzlich noch Intrinsics oder Inline-ASM
falls nötig (z.B. BE/LE Konvertierung), dafür ist eine genauere Kenntnis
der Architektur und etwas Vergleich des (optimierten) Compiler Output
notwendig.
Mein Werdegang: Angefangen mit BASIC C64/PC in der Schule, dann ein
wenig Borland-C, weiter mit embedded AVR C, Arm Cortex-M C,
Windows-Programmierung C/C++/STL/Templates, mittlerweile Typescript :-)
Ansonsten eher elektrotechnischer/Elektronik Hintergrund.
Sehr empfehle ich diesen Vortrag:
CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple
Commodore 64 Game in C++17”
https://www.youtube.com/watch?v=zBkNBP00wJE
:
Bearbeitet durch User
Random .. schrieb: > In den meissten Fällen werden Mikrocontroller rein in C und "while(1) { > ... } programmiert, da dies am übersichtlichsten ist. Vor allem ist die Ausführungsreihenfolge streng deterministisch und eindeutig definiert. Keine Task kann sich unerwartet dazwischen drängeln und alle Variablen sind im Durchlauf konstant, können also mehrfach ausgewertet werden. Es ist auch immmer garantiert, daß alle Tasks auf die aktuellsten Daten zugreifen, die z.B. vom ADC gelesen wurden. Daher sind auch SPSen so beliebt, die machen das genauso. Random .. schrieb: > Bei größeren Projekten > endet das dann im Spahetticode mit sehr vielen globalen Variablen zur > Steuerung. Das muß aber nicht sein. Man sollte in sich geschlossene Abläufe als Funktionen definieren, die dann in der Mainloop nacheinander aufgerufen werden. Zusammen gehörende Variablen kann man als Struct organisieren. Random .. schrieb: > Ich habe sehr schnell (vor allem auf Arm Cortex-M) die Vorzüge eines > RTOS schätzen gelernt Dann braucht es allerdings einen höheren Verwaltungsaufwand, um zu garantieren, daß Daten immer konsistent gelesen und geliefert werden und Tasks nicht in der falschen Reihenfolge dran kommen.
Random .. schrieb: > rein in C und "while(1) C ist sicher dominant, aber längst nicht die einzige Sprache. Mit den heutigen äußerst fetten und hoch getakteten MCUs für kleinstes Geld sind längst andere Sprachen möglich geworden. while(1) ist pure Notwendigkeit, wenn es kein OS gibt an das man nach Programmablauf zurückgeben kann. Random .. schrieb: > die Vorzüge eines > RTOS Selbst erlebt: Linux hat die harten Timings nicht hinbekommen, also wurde dem Embeddet PC ein STM32 zur Seite gestellt. Weils doch so super ist, bekamm der STM32 ein RTOS für das ganze lästige Gesummse drummherum. TATA!!!! Das RTOS packte das harte Timing nicht. Der STM32 bekam einen AVR zur Seite gestellt... Eine wahnsinns Verbesserung im Vergleich zu vorher, wo der STM32 in der Mitte fehlte. Man sollte sich vorher genau überlegen wo die Knackpunkte sind, bevor die Entscheidung RTOS fällt. Manches ist bare metal einfach besser zu lösen, weil man nicht über unbekannte Abhängigkeiten stolpert.
Michael schrieb: > Das RTOS packte das harte Timing nicht. Man kann auch den Teil der das "harte Timing" braucht klassisch "am RTOS vorbei" in ISR's abhandeln aber dennoch mit den normalen Threads kommunizieren. Klingt aber dennoch stark nach Kompetenzproblem. Selbst mit RTOS ist ein STM32 größtenteils schneller als ein AVR... Wenn man taktgenaues Bitbanging braucht kann man das auch in einem Thread machen, der muss dann halt höchste Priorität haben oder nicht-unterbrechbar sein.
:
Bearbeitet durch User
Michael schrieb: > Mit den heutigen äußerst fetten und hoch getakteten MCUs für kleinstes > Geld sind längst andere Sprachen möglich geworden. Ja, wenn die nur fett genug sind, muss der Entwickler gar nicht umlernen, und kann seinen Java- oder auch Electron/Typescript-Bloat 1:1 weiterverwenden.
Harald K. schrieb: > Ja, wenn die nur fett genug sind, muss der Entwickler gar nicht > umlernen, und kann seinen Java- oder auch Electron/Typescript-Bloat 1:1 > weiterverwenden. Du hast es erfasst. Statt also einen Entwickler mit den nötigen Fähigkeiten äußerst zeitaufwendig und kostenintensiv eine bereits längt in Hochsprache geschriebene Lösung nochmal aber deutlich schlechter in ASM implementieren zu lassen, kann der einfach billige MCU ressourcen benutzen und in der gleichen Zeit 10 Projekte erledigen. Und das Beste: Den Java, Electron/Typescript-Bloat kann sogar ein anderer Entwickler in 5J noch lesen, verstehen, pflegen und auf eine dann moderne MCU portieren, wärend der geile ASM Hack nur auf der uralt MCU läuft die man längst zu völlig bizarren Preisen vom Museumshöker aus fragwürdigen Quellen beziehen muss, um das Projekt am leben zu erhalten. Statt eine Aufgabe wieder und wieder und wieder und wieder auf unterschiedlichsten Architekturen zu lösen und sich völlig in einer vielzahl Baustellen zu verzetteln, baut man diese Dinge ein mal. Man baut ein HAL dazu, LIBs die sauber dokumentiert sind und das alles mit einer Hochsprache die leistungsfähige methoden kennt. Weil Speicher und Speed billig sind und fast unbegrenzt zur verfügung stehen, während BRAIN eine äußerst kostbare Ressource ist.
Michael schrieb: > nochmal aber deutlich schlechter in ASM Du bist irgendwo komplett falsch abgebogen. Von Assembler war nicht die Rede, dieses unwartbare Zeug finden nur "Moby" und ähnliche Spinner toll. Wer meint, mit so etwas wie Typescript auf Microcontrollern unterwegs sein zu müssen, der wird schon noch interessante Überraschungen erleben. Eines der Dinge, das sich zwischen "Mainstream"-Gestümper und Embedded-Entwicklung deutlich unterscheidet, sind nämlich die Anforderungen. Aber lass' Deinen Bloatware-Bastler das nur ruhig selbst herausfinden, und sich wundern, mit wieviel Rechenleistung er um sich werfen muss, um ein Problem zu lösen, das andere in anderen Programmiersprachen gar nicht erst hätten. Und nein, ich rede nicht von Assembler. Der bessere Embedded-Entwickler kann zwar auch in Assembler programmieren, aber er tut es nicht. Der schlechtere weiß noch nicht mal, was die Maschine da eigentlich tut. Der sucht dann nach einer neueren Version seiner Libs.
Harald K. schrieb: > Der bessere > Embedded-Entwickler kann zwar auch in Assembler programmieren, aber er > tut es nicht. So ist es. Es schadet aber durchaus nicht, wenn man auch mal ins Listing schauen kann, was da unter der Haube passiert. Manchmal macht man es dem Compiler völlig unnötig schwer und der Code explodiert.
Da fällt mir der Typ ein, der eine XSLT Transformation auf einem Microcontroller vorschlug, um Messwerte im Browser anzuzeigen. Manche Witze hannst du dir nicht ausdenken.
:
Bearbeitet durch User
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.