Hallo, Ich will es kurz machen. Bisher habe ich Hardware, Tester, usw. entwickelt. Dazu ein bisschen LabView und Arduino. Nun haben wir ein 'größeres' embedded Softwareprojekt welches in 3-6 Monaten starten soll. 16 oder 32 Bit Mikrocontroller, ein paar Sensoren einlesen, Filter (FIR/ IIR), I2C, SPI, CAN Bus, LCD Display, usw. Eigentlich nicht wirklich Schlimmes. Komplexität vielleicht einer mittelmäßig komplexen Diplomarbeit. Nun ist unser frisch eingestellter Programmierer überraschend aus familiäreren Gründen abgesprungen (Frau hat eine Stelle im Ausland erhalten). Da ich im Vorstellungsgespräch (vor ca. 2 Jahre) erwähnt habe das ich mir auch vorstellen konnte in der Software zu arbeiten kam mein Chefchen heute auf die glorreiche Idee mich da rein zustecken. Zeit ist vorhanden und eigentlich hätte ich schon Interesse. Mal etwas neues kennenlernen, die Möglichkeit auf Fortbildung / Weiterbildung usw. Ich kann den Prozessor selber aussuchen, Tools, Compiler usw. Und auch Kurse sind kein Problem. Ich hatte da an www.microconsult.de oder ähnlichem gedacht. Habt ihr vielleicht ein paar Tipps für mich? Ich kann in C programmieren würde aber gern einen Prozessor / Toolchain aussuchen der es mir erlaubt mich auf die eigentliche Aufgabe zu konzentrieren. In einfachen Worten ich möchte keine große Zeit auf Setup, Inbetriebnahme, Toolchain, Registerrumgehopse usw. verschwenden. Das Ganze darf auch ein wenig überdimensioniert ausfallen und darf auch was kosten. Viele liebe Grüße
Farin U. schrieb: > ... Hallo Farin, also, an sich sehe ich da überhaupt kein Problem. Mir ging es eigentlich auch ähnlich. Es hieß vor fünf Jahren, Gerhard, das neue Projekt machst mal mit einem Cortex MCU. Und, ja, auch die Software. Da ich bisher nur 8-Bitter kannte, schnappte ich mir ein Development Bord die (damals noch unbegrenzte) Atollic Lite True Studio und zwei Wochen später konnte ich mit dem Vielbeiner schon ganz gut umgehen. Ähnlich wie bei Dir, ein paar 24-bit ADC andere Sensoren, RTC, I2C, SPI, kein CAN Bus, ZigBee. Vier Monate lief die HW und SW schon ganz leidlich. Die eigentliche SW machte ich dann offiziell mit IAR. Wenn Du auch die HW selber stricken darfst dann ist HW+SW zusammen das Ideal, da man sich schon beim Entwurf der Schaltung die günstigste Pinbelegung und HW/SW Strukturen festlegen kann um auch die Programmierung zu erleichtern. Die Moral von der Geschicht: Du machst Dir zu unnötig zu viel Gedanken. Knie Dich richtig rein und Du wirst schon sehen wie leicht alles im Grunde genommen ist. Wenn Du C schon kannst, dann verschwendest Du mit dem Kurs nur Deine Zeit und Geld. Ein gutes Referenz Buch ist da viel nützlicher. Mit dem MS C Compiler auf dem PC kannst Du spielend leicht Deine Algorithmen durch testen. So habe ich das auch gemacht und glaube bin ganz gut dabei gefahren. Ich arbeitete damals mit dem STM32F103/407 und NXP LPC2477. Und wenn man das große Glück hat noch einen Freund oder Kollegen zu kennen mit denen man ab und zu knifflige Probleme diskutieren kann, dann fährt man ganz gut dabei. Duck und weg, Gerhard
:
Bearbeitet durch User
Nagel halt irgendeinen Scheiß zusammen. Stört ja heutzutage keinen mehr und für Qualität will niemand bezahlen.
Danke für den positiven Zuspruch... Habe vergessen zu erwähnen das ich noch einen Kollegen habe der mitmachen darf. Jedoch hat der auch nicht wirklich Ahnung außer Arduino Programmierung. Na ja, besser als nichts. Jedenfalls würde er gern mitmachen. Habe auch ein, zwei Bekannte die sich mit Software-Entwicklung sehr gut auskennen. Mit den bisher erwähnten Prozessoren... Wie sieht es da mit den Werkzeugen aus? Der ausscheidende Programmierer hat mir gesagt das ich darüber nachdenken sollte vieleicht alles aus einer Hand zu nehmen.... z.B Microchip. Prozessor, Compiler, Programmiergerät alles aus einem Haus und der Support wäre super... Viele liebe Grüße
Die Frage nach den Mitteln ist ja eng mit deinem Budget verbunden. So gibt es natürlich kostenpflichtige Werkzeuge (samt Support), aber auch kostenfreie mit einer Dokumentation die du dann selbst bemühen musst.
Ich wuerde mir die Haltung von wegen "die Toolchain muss schnell aufgesetzt sein" nochmal gut ueberlegen. Meistens ist es doch so dass man bei den komerziellen Tools einfach merkt, dass die leute die es entwickelt haben nicht wirklich Lust drauf hatten und auch keinen Spass am Programmieren. Da gibt es dann 1000 Kleinigkeiten, die einfach den Workflow kaputt machen. Die Alternative: Nimm dir ne Woche Zeit und installier dir Linux, gcc, gdb, openocd, gvim, eclipse, vllt ein vim Plugin fuer Eclipse und so weiter. Bis das laeuft dauert es zwar, aber dann hast du eine Toolchain von der du weisst dass und wie sie funktioniert.
Moin, warum nicht für Beginner einen Atmel Arm nehmen. Da ist die Toolchain fix installiert, funktioniert unter Windows und der TE kann relativ schnell anfangen sich mit der Hardware zu beschäftigen, statt der Toolchain. Grüße,
"Arduino, dickster Hobel erlaubt, erst noch auf ne Schulung, meine Bekannte sind Softwareentwickler,...." Wenn ich sowas lese geht mir das Messer in der Tasche auf, sowas nennt sich Dipl. Ing. Womit bewiesen wäre dass angeblich so angesehnen und qualitativ hochwertige Diplom eine reine Luftnummer war. Sowas würde ich sofort rausschmeissen und nicht noch auf eine Schulung stecken.
Guest schrieb: > Die Alternative: Nimm dir ne Woche Zeit und installier dir Linux, gcc, > gdb, openocd, gvim, eclipse, vllt ein vim Plugin fuer Eclipse und so > weiter. Bis das laeuft dauert es zwar, aber dann hast du eine Toolchain > von der du weisst dass und wie sie funktioniert. Rechne lieber mit ca. 1 Monat. Die OPenSource Lösungen sind oft auch ein zusammengemurkster Mist. Ich habe das mal durchgemacht für einen Atmel. Die Lösungen im Internet haben dann nicht zu der openocd Version gepasst (ja, da wird ständig inkomptaibel geändert). Letztendlich hatte ich aber eine richtig schöne Lösung für Eclipse mit compilieren, debuggen,...
Rausprüfer schrieb: > Wenn ich sowas lese geht mir das Messer in der Tasche auf, sowas nennt > sich Dipl. Ing. Womit bewiesen wäre dass angeblich so angesehnen und > qualitativ hochwertige Diplom eine reine Luftnummer war. DIe Industrie will das so, Hauptsache man hat ein Papier wo ein Titel darauf steht. In Zukunft vielleicht auch für die (diplomierte) Klofrau/mann...
Hannes J. schrieb: > Nagel halt irgendeinen Scheiß zusammen. Stört ja heutzutage keinen mehr > und für Qualität will niemand bezahlen. Leider allzuwahr :) musste trotzdem schmunzeln
xxx schrieb: > Guest schrieb: > Die Alternative: Nimm dir ne Woche Zeit und installier dir Linux, gcc, > gdb, openocd, gvim, eclipse, vllt ein vim Plugin fuer Eclipse und so > weiter. Bis das laeuft dauert es zwar, aber dann hast du eine Toolchain > von der du weisst dass und wie sie funktioniert. > > Rechne lieber mit ca. 1 Monat. Die OPenSource Lösungen sind oft auch ein > zusammengemurkster Mist. Ich habe das mal durchgemacht für einen Atmel. > Die Lösungen im Internet haben dann nicht zu der openocd Version gepasst > (ja, da wird ständig inkomptaibel geändert). > Letztendlich hatte ich aber eine richtig schöne Lösung für Eclipse mit > compilieren, debuggen,... OpenOCD war immer ziemlich kompliziert, das ist richtig. Wenn man eine aktuelle Version benutzt (am besten selber compilen, das geht super fix), ist es erfahrungsgemaess aber stressfrei, die haben in letzter Zeit viele Probleme behoben. Alternativ gibt es auch fuer Segger programmer einen komerziellen GDB Server der sich gut einbinden laesst, bei anderen Firmen sieht das aehnlich aus. Letztendlich ist es halt so dass man mit vernuenftigen tools 3 mal so schnell arbeitet als mit dem Mist der von den chipherstellern fabriziert wird. Wenn ich nur an die ganzen kryptischen eclipse Fehlermeldungen denke weil die da irgendwas reingepatcht haben... Ohne Linux vorkentnisse ist es natuerlich schlechter. Allein schon weil man dann immer das bloede Ubuntu nimmt. Besorg dir Arch und als Oberflaeche den Awesome WM. Als Chip wuerde ich den nehmen, den ich am einfachsten und billigsten beschaffen kann und fuer den es ein nettes Eval Board gibt. Natuerlich muss die Hardware fuer die Aufgabe reichen. Ich wuerde keinen Chip nehmen "weil der so schoen einfach zu programmieren ist". Da kommt meist nur mist bei raus.
Guest schrieb: > Ohne Linux vorkentnisse ist es natuerlich schlechter. Allein schon weil > man dann immer das bloede Ubuntu nimmt. Besorg dir Arch und als > Oberflaeche den Awesome WM. Auf archlinux.de steht: ... Arch Linux ist daher eine perfekte Distribution für erfahrene Anwender — und solche, die es werden wollen... ... Demzufolge doch lieber was anderes. Anstelle von Ubuntu gibt es auch komfortable und leichtgewichtige Ableger (xubuntu z.B.). Ich habe mich damals durch das ganze durchgewurstelt mit folgendem Ziel: - Standardinstallation - Möglichst nichts selber compilieren müssen Grund: Ich verwalte mehrere PCs und es ist einfach angenehmer nicht überall alles mögliche erst compilieren zu müssen bei einem Update. Inzwischen habe ich für solche Fälle ein eigenes Archiv, das in apt-get, aptitude oder <Tool der Wahl hier eintragen> eingebunden werdern kann. Die Ersttelung der deb-Pakete ist leider meistens noch problematisch.
Farin U. schrieb: > Nun haben wir ein 'größeres' embedded Softwareprojekt welches in 3-6 > Monaten starten soll. 16 oder 32 Bit Mikrocontroller, ein paar Sensoren > einlesen, Filter (FIR/ IIR), I2C, SPI, CAN Bus, LCD Display, usw. > Eigentlich nicht wirklich Schlimmes. Komplexität vielleicht einer > mittelmäßig komplexen Diplomarbeit. Schau mal, ob du hier fündig wirst: http://www.microchip.com/pagehandler/en-us/family/16bit/ Kann je nach type schon CAN und Signalprocessing-Libs sind auch da.
Also ich habe mit den STM32 und Coocox sehr gute Erfahrungen gemacht, wenngleich das Atollic Studio auch geil ist (aber teuer). Selbst fürs Hobby nutze ich manchmal einen STM32F050 statt eines Mega328, wenn er auch meistens völliger Overkill ist, aber angesichts des Preises von 3,77€ (AVR) zu 1,60€ (STM32) bei deutlich besserer Hardware? Warum denn dann nicht!
Rausprüfer schrieb: > "Arduino, dickster Hobel erlaubt, erst noch auf ne Schulung, meine > Bekannte sind Softwareentwickler,...." > > Wenn ich sowas lese geht mir das Messer in der Tasche auf, sowas nennt > sich Dipl. Ing. Womit bewiesen wäre dass angeblich so angesehnen und > qualitativ hochwertige Diplom eine reine Luftnummer war. > > Sowas würde ich sofort rausschmeissen und nicht noch auf eine Schulung > stecken. Sad but true
Kann funktionieren, kann aber auch voll in die Hose gehen. An einem Arduino ein paar Leds blinken zu lassen und einen ARM oder ähnliches zu programmieren ist schon ein riesen Unterschied. Chefs denken immer betriebswirtschaftlich, er könnte einen neuen Programmierer einstellen, entscheidet sich aber für dich. Seine Gründe könnten sein vollstes Vertrauen in dich oder die Abwägung, du kostest weniger und das Resultat fällt dann eben schlechter aus. Farin U. schrieb: > Zeit ist vorhanden Farin U. schrieb: > Das Ganze darf auch ein wenig überdimensioniert ausfallen und darf auch > was kosten. Solche Sätze habe ich in meiner Firma noch nie gehört also Vorsicht, kann sein dass du schon sehr bald Resultate vorweisen mußt. Trotzdem viel Erfolg!
Bekommst du jetzt auch mehr Geld, hast ja immerhin auch einen höheren Aufwand?
seit wann sind Dipl.-Ing.s Programmierer? Welch Einfältigkeit manch einer an den Tag legt. Wohl zu sehr unter Herren, die wohl noch einen Ingenieur ohne Dipl. gemacht haben, der alten Riege gelitten was? armselig sowas....
Matthes schrieb: > seit wann sind Dipl.-Ing.s Programmierer? Und warum sollte das deiner Meinung nach nicht gehen, wenn der TE doch schreibt er könne C programmieren und hat Erfahrungen mit Controllern?
Matthes schrieb: > seit wann sind Dipl.-Ing.s Programmierer? Welch Einfältigkeit manch > einer an den Tag legt. Wohl zu sehr unter Herren, die wohl noch einen > Ingenieur ohne Dipl. gemacht haben, der alten Riege gelitten was? > armselig sowas.... Er soll (hardwarenahe) Software für eine kleine CPU schreiben, das gehört durchaus voll in das Aufgabengebiet eines Ing. Was soll der Trollversuch?
xxx schrieb: > Arch Linux ist daher eine perfekte Distribution für erfahrene Anwender > — und solche, die es werden wollen... > ... > > Demzufolge doch lieber was anderes. Anstelle von Ubuntu gibt es auch > komfortable und leichtgewichtige Ableger (xubuntu z.B.). > > Ich habe mich damals durch das ganze durchgewurstelt mit folgendem Ziel: > - Standardinstallation > - Möglichst nichts selber compilieren müssen > > Grund: > Ich verwalte mehrere PCs und es ist einfach angenehmer nicht überall > alles mögliche erst compilieren zu müssen bei einem Update. > > Inzwischen habe ich für solche Fälle ein eigenes Archiv, das in apt-get, > aptitude oder <Tool der Wahl hier eintragen> eingebunden werdern kann. > Die Ersttelung der deb-Pakete ist leider meistens noch problematisch. Genau. Solche die es werden wollen. Also Programmierer und Ingenieure, nich die Oma von nebenan. Das Problem mit dem ganzen *buntu mist und Debian ist, dass die Pakete im Repo veraltet sind. DESWEGEN muss man ständig mist selber compilen oder dritt-repos einfügen. Würde man Arch benutzen, hätte man alle Software in aktueller Version im normalen Repo - perfekt für den Entwickler. Xubuntu ist der gleiche Mist wie das normale Ubuntu, nur ohne das dämliche Unity. Zum surfen im Internet und so ist Xfce super, zum richtig Programmieren ist ein tiling window manager aber das Maß aller Dinge. Awesome wäre da eben zu empfehlen, nicht unity, kde oder sonst was...
Farin U. schrieb: > Compiler ... alles aus einem Haus und der Support wäre super... Was ich bisher von deren Compilern gesehen habe, hat mich eher abgeschreckt. Da wirst du den guten Support auch sicher brauchen... Heutzutage setze ich in jedem Fall auf einen ARM basierten uC mit offener Toolchain (GCC).
Lothar M. schrieb: > Heutzutage setze ich in jedem Fall auf einen ARM basierten uC mit > offener Toolchain (GCC). Die findet man gerne auch mal in einem FPGA wieder. ;)
Matthes schrieb: > seit wann sind Dipl.-Ing.s Programmierer? Auf jeden Fall kann ein Ing. Elektronik einen uC schneller verstehen und besser und effizienter programmieren als ein technischer Informatiker. Denn der Informatiker sagt, wenn sein Code zu "langsam" ist: der uC kann das nicht. Ich brauche einen schnelleren! Der Elektroniker denkt sich: das muss doch gehen. 100MHz reichen sicher! Und er analysiert das Design mit Messgeräten, findet den Flaschenhals und behebt ihn. Das ist leider meine mehrfach selbst erlebte Realität... > Welch Einfältigkeit manch einer an den Tag legt. Man lernt nie aus. Wenn ich nur das gemacht hätte, was ich in der Schule gelernt habe, dann könnte ich heute nicht viel ausrichten oder gar eine Schaltung entwickeln... genervt schrieb: > Die findet man gerne auch mal in einem FPGA wieder. ;) Ja, leider noch nicht... :-(
:
Bearbeitet durch Moderator
xxx schrieb: > Guest schrieb: >> Die Alternative: Nimm dir ne Woche Zeit und installier dir Linux, gcc, >> gdb, openocd, gvim, eclipse, vllt ein vim Plugin fuer Eclipse und so >> weiter. Bis das laeuft dauert es zwar, aber dann hast du eine Toolchain >> von der du weisst dass und wie sie funktioniert. > > Rechne lieber mit ca. 1 Monat. Die OPenSource Lösungen sind oft auch ein > zusammengemurkster Mist. Sehe ich auch so. Das ist was für Hobbybastler die Monatelang ihre Nächste sich um die Ohren schlagen und dann am ende die 1001 Freeware Tools genau so angepasts haben, wie es ihnen gefällt. Wenn du schnell und ohne Probleme starten willst dann nimm was Kommerzielles. Ich würde Keil uVision 5 nehmen. Ne Demo kannst du dir kostenlos runterladen. Dann ein passendes Eva Board und nen uLink dazu. Wenn du nen STM32 nimmst kannst du dir sogar Startup und alles mit einem Programm von ST zusammenklicken. Das geht auch bevor man einen uC gewählt hat, dann sieht man gleich, welche die passende Peripherie haben. Das Programm kann gleich ein Projekt für Keil erstellen.
:
Bearbeitet durch User
Nimm einen STM32. Je nach Typ und Stückzahl gehen da die Preise ab 1$/Stk. los. Ausserdem gibt es je nach Typ auch sehr kleine Gehäuse. Da lohnt sich preislich kein 8Bitter mehr. Für die STM32 gibt es von SGS eine Peripherie Library. Alle Beispiele für die STM32 beruhen auf dieser Bibliothek. So bekommst du schnell etwas zum Laufen, ohne Dich gleich bis ins letzte Bit auskennen zu müssen. Auf Dauer kommst du aber natürlich nicht drumherum ;-). Als IDE sind Keil uVision oder IAR gängig. Was du nimmst spielt keine so grosse Rolle. Denn die Erfahrung zeigt, andere Software andere Probleme, und da ist Opensource keinesfalls von ausgenommen. Was man sich aber anschauen sollte ist der Lieferumfang. Wenn du nur eine Woche an einer Opensource Umgebung bastelst, liegst du von den Kosten her bei Keil oder IAR, eventuell schon drüber. Mit Keil und IAR kannst du gleich nach der Installation anfangen effektiv zu arbeiten. Niemanden interessiert wie elegant dein Quellcode oder deine Entwicklungsumgebung ist. Nur das lauffähige Projekt am Ende zählt. Opensource kommt aus meiner Sicht nur in Frage, wenn du an einer Applikation für ein Embedded Linux werkelst.
>Nun haben wir ein 'größeres' embedded Softwareprojekt welches in 3-6 >Monaten starten soll. 16 oder 32 Bit Mikrocontroller, ein paar Sensoren >einlesen, Filter (FIR/ IIR), I2C, SPI, CAN Bus, LCD Display, usw. >Eigentlich nicht wirklich Schlimmes. Komplexität vielleicht einer >mittelmäßig komplexen Diplomarbeit. Wenn es doch nichts Schlimmes ist und "nur" die Komplexität einer mittelmäßigen Diplomarbeit entspricht, dann frage ich mich warum wird dann hier so ein Zauber gemacht?
Lothar M. schrieb: > Farin U. schrieb: >> Compiler ... alles aus einem Haus und der Support wäre super... > Was ich bisher von deren Compilern gesehen habe, hat mich eher > abgeschreckt. Da wirst du den guten Support auch sicher brauchen... > > Heutzutage setze ich in jedem Fall auf einen ARM basierten uC mit > offener Toolchain (GCC). Melde dich doch einfach mal bei den Leuten von Segger (segger.com), da kannst du alles was du brauchst professionel aus einer Hand bekommen: 1. IDE + GCC Compiler, Segger Embedded Studio, https://www.segger.com/embedded-studio.html 2. JTAG Debug Probe, https://www.segger.com/jlink-debug-probes.html 3. Middleware, falls du nicht alles selbst programmieren möchtest, https://www.segger.com/rtos-and-middleware.html Du brauchst dir dann nur noch ein passende CPU auswählen, z.B. ein beliebiger Cortex M. Und Schulungen machen die auch, sind zwar eigentlich Produktschulungen, aber die haben auch kein Problem damit dir ein bisschen Grundlagen beizubringen.
> Re: Überraschung, ab heute machen sie Software.
Das ist doch nicht ungewöhnlich, zeigt es doch nur das hier mal wieder
die Entscheidungsträger vom Tuten und Blasen keine Ahnung hatten.
Aber was soll es, zieh deine Programmierung durch, egal was für ein
Schrott rauskommt. Auf der Baustelle werden es dann die Inbetriebnehmer
wie Zuckerle und Co. schon richten.
Guest schrieb: > Ich wuerde mir die Haltung von wegen "die Toolchain muss schnell > aufgesetzt sein" nochmal gut ueberlegen. Meistens ist es doch so dass > man bei den komerziellen Tools einfach merkt, dass die leute die es > entwickelt haben nicht wirklich Lust drauf hatten und auch keinen Spass > am Programmieren. Da gibt es dann 1000 Kleinigkeiten, die einfach den > Workflow kaputt machen. > > Die Alternative: Nimm dir ne Woche Zeit und installier dir Linux, gcc, > gdb, openocd, gvim, eclipse, vllt ein vim Plugin fuer Eclipse und so > weiter. Bis das laeuft dauert es zwar, aber dann hast du eine Toolchain > von der du weisst dass und wie sie funktioniert. So einen Scheiß habe ich selten gelesen. Kommerzielle Produkte taugen nichts ... etc. Du baust dir sicher erst auch den Hammer, bevor du einen Nagel in die Wand haust? @TO Was du letztlich nimmst, das hängt doch im großen Maße von der Anwendung ab. Microchip hat ein weit gefächertes Angebot, aber auch PSoC5 solltest du dir mal ansehen. Wenn es ST werden soll, dann hast du ja schon mal Gerhard (liegen Gruß), der die sicher über die anfänglichen Schmerzen weg helfen kann.
:
Bearbeitet durch User
Das mit den Entwicklungsumgebungen ist zweischneidig. Man kommt schnell zu Ergebnissen und kann in allen Arten komfortabel rumdebuggen. Dummerweise hat fast jede Architektur ihre eigene Standard-IDE, selbst wenn sie oft auf irgendwas aus der OpenSource-Ecke beruht (Microchips MPLab auf Netbeans, NXP LPCXpress auf Eclipse, etc.). Und wenn dann mal was nicht geht, egal ob jetzt beim Build oder abstruse Effekte zur (Debug)Laufzeit, versteht keiner mehr was. Bei mir ist das zB. so, dass die Projekte sehr variabel sind. Mal Perl/C/C++/Qt auf dem PC, mal AVR, PIC, ARM in verschiedenen Geschmacksrichtungen, MIPS, FPGAs/VHDL. Teilweise auch parallel (CPU+FPGA). Wenn ich da jedesmal eine neue/andere IDE anfassen müsste, würde ich wahnsinnig. Ich versuche daher, normale IDEs zu vermeiden, Basis ist immer make und emacs. Tastaturcodes identisch unter Windows, Mac und Linux, keine Umgewöhnung notwendig. Beim Debugging lassen sich IDEs manchmal nicht vermeiden, openocd geht recht häufig. Aber generell versuche ich, Weichei-Debugging (Single-Step im Sourcecode) auf uCs zu vermeiden. Algorithmische Probleme lassen sich bequemer auf dem PC lösen, und bei Timing/Stack/IRQ-Sachen stört normales Debugging oft mehr als es nützt. Strategisch platziertes Pinwackeln oder ein paar Chars über die UART helfen da viel mehr... Aber vermutlich bin ich einfach nur altmodisch ;)
Ingo L. schrieb: > wenn der TE doch > schreibt er könne C programmieren und hat Erfahrungen mit Controllern? Er kann kein C programmieren und er hat keine Erfahrung mit Controllern sonst würde er hier nicht nach den Grundlagen fragen sondern hätte schon längst ne lauffähige Toolchain samt IDE und allem Spielzeug im Hobbykeller stehen (oder er wüsste was er installieren muss um eine solche Umgebung binnen eines Vormittags aufzusetzen, wer C kann weiß was er dazu für Werkzeuge braucht), und wenn er "Erfahrung mit Controllern" hätte dann hätte er bereits eine klare Vorstellung welche Controller er dazu schon mal in die engere Wahl ziehen würde, wonach er suchen muss, was er brauchen wird, und könnte dann direkt am Montag schon loslegen mit der Planung des Projekts. Denn die "3 bis 6 Monate" bis es "starten soll" sollte er bei so einer chaotischen Planung durch fachfremde Personen nicht mit Däumchen drehen und abwarten verbringen sondern sofort erledigen was jetzt schon erledigt werden kann (und nichts anderes mehr machen) denn sonst ist es schon zu spät noch bevor es angefangen hat.
:
Bearbeitet durch User
Bernd K. schrieb: > Denn die "3 bis 6 Monate" bis es "starten > soll" sollte er bei so einer chaotischen Planung durch fachfremde > Personen nicht mit Däumchen drehen und abwarten verbringen sondern > sofort erledigen was jetzt schon erledigt werden kann (und nichts > anderes mehr machen) denn sonst ist es schon zu spät noch bevor es > angefangen hat. Das ist genau der falsche Weg. Einfach mal zu tun, was man jetzt "sieht" für nur dazu, dass Dinge getan werden, die trivial sind und hinterher besser und richtiger getan werden könnten. Wichtig ist, zunächst die komplexen Themen in einem Projekt zu klären und zu erledigen und dazu gehört auch die Einarbeitung eventueller neuer Mitarbeiter. Wenn nun diese Planung von eben jenem mitgeleistet werden muss, der selber noch nicht in der lage ist, zu planen oder gar zu entwicklen, dann gute Nacht! Da muss ein erfahrener PL ran, der die tollchains kennt, deren Einsatzfähigkeit beurteilen kann und damit sie projekttechnisch managen kann. Dies umfasst Kosten, Risiken, Festelgung von Absicherungen gegen Verzögerungen etc. Entwickler müssen sinnvoll gesteuert werden, sondern laufen sie und die Kosten ins Nirwana.
Klingt auf jeden Fall nach unprofessioneller Frickelbude. Schau, dass du da möglichst schnell wegkommst.
Konrad schrieb: > Klingt auf jeden Fall nach unprofessioneller Frickelbude. Schau, > dass du da möglichst schnell wegkommst. Das erkennst du woran? In vielen kleinen Buden macht eine Person Software und Hardware. Man kann nicht alles wissen und lernt wie bei allem im Leben mit jedem Projekt dazu. Wer fickelt scheitert gewöhnlich schon am SPICE, bei der EMV oder irgendeinem vorgeschriebenen Test. Je nachdem in welcher Branche man sich befindet und ob es Qualitäter in der Firma gibt.
polb schrieb: > In vielen kleinen Buden macht eine Person > Software und Hardware. Ja, in Frickelbuden.
Konrad schrieb: > Klingt auf jeden Fall nach unprofessioneller Frickelbude. Schau, dass du > da möglichst schnell wegkommst. Denkste, das is bei namhaften Buden ansatzweise besser? Naivling.
Die Buden, die echt noch qualitativ realistischen Code produzieren, sind praktisch alles Idealisten. Entweder welche, wo Herzblut drinsteckt und der Lohn anderweitig gesichert ist. Oder welche, die mit Instituten/Hochschulen zusammenarbeiten. Praktisch alles, was heute kommerziell (also in klassischer Lohnarbeit) erzeugt wird, ist doch effektiv Müll. Vielleicht völlig stupide überdokumentierter, TÜV-zertifizierter und QA-gemänätschter Müll, aber trotzdem nach Codequalität einfach Müll. Schon allein weil das Produkt auf den Markt muss, egal ob getestet oder ausgereift. Nur bei Software fällt der Müll halt net so schnell auf als bei Hardware und Mechanik. Und weils dem Programmierer letztlich egal ist. Und das ist jetzt ein ernstgemeinter Erfahrungswert aus der Praxis in mehreren Unternehmen.
Vielleicht ist die "Bude" auch so gut, verdient so viel Kohle, dass sie es sich leisten können einen Mitarbeiter dessen Potential sie erkannt haben, einfach mal kreativ spielen zu lassen? Dass er hier fragt zeigt schon, dass er offen für alle Wege ist und keine Scheuklappen trägt.
Farin U. schrieb: > Ich kann in C programmieren würde aber gern einen Prozessor / Toolchain > aussuchen der es mir erlaubt mich auf die eigentliche Aufgabe zu > konzentrieren. In einfachen Worten ich möchte keine große Zeit auf > Setup, Inbetriebnahme, Toolchain, Registerrumgehopse usw. verschwenden. > Das Ganze darf auch ein wenig überdimensioniert ausfallen und darf auch > was kosten. Da würde ich die Antworten der beiden Vorredner unterschreiben. Gerhard O. schrieb: > Die eigentliche SW machte > ich dann offiziell mit IAR. Decius schrieb: > Mit Keil > und IAR kannst du gleich nach der Installation anfangen effektiv zu > arbeiten. Um konkreter zu werden und nach dem, was Du so an Anforderungen auflistest, würde ich zum Einstieg ein STM32F411 Nucleo-Board vorschlagen: hohe Leistung, minimaler Preis und vor allem unverbaute IO-Pins. Dazu eine 'IAR Embedded Workbench for ARM' zunächst als größenbegrenzte (32K) Version, mit der Du vielleicht sogar Dein ganzes Vorhaben erledigen kannst. STM32F411 und die (zunächst) kostenlose IAR-IDE haben große Brüder, sodaß die Leistung nach oben nicht begrenzt ist, wenn es 'was kosten darf'.
Ich würde aus den genannten Gründen auch einen STM32 mit IAR-IDE empfehlen. Gaga schrieb: > Praktisch alles, was heute kommerziell (also in klassischer Lohnarbeit) > erzeugt wird, ist doch effektiv Müll. Vielleicht völlig stupide > überdokumentierter, TÜV-zertifizierter und QA-gemänätschter Müll, aber > trotzdem nach Codequalität einfach Müll. > Schon allein weil das Produkt auf den Markt muss, egal ob getestet oder > ausgereift. Nur bei Software fällt der Müll halt net so schnell auf als > bei Hardware und Mechanik. Und weils dem Programmierer letztlich egal > ist. Kannst du dafür Beispiele für Codequalität Müll nennen? Ich kann jetzt nur für die Automotive-Industrie reden, aber unser Unternehmen verlässt kein Release, egal wie sehr der Kunde drängt, ohne das zumindest die QS einen System Test gefahren hat. Das ist eine andere Abteilung, die wir nicht beeinflussen können. Die eigene Doku und Tests können auf ein Minimum zurückgestellt werden, aber trotzdem geht bei SPICE3 nicht, dass du dreck auslieferst. Das würde nur gehen, wenn Leute wie FuSi-Manager und Qualitätstester aus anderen Abteilungen sowie dein Kollege im Review dreck durchwinken.
Gaga schrieb: > Konrad schrieb: > Klingt auf jeden Fall nach unprofessioneller Frickelbude. Schau, dass du > da möglichst schnell wegkommst. > > Denkste, das is bei namhaften Buden ansatzweise besser? > Naivling. Ja, denn da macht eben nicht eine Person fast "alles", sondern die Funktionen sind sinnvollerweise auf verschiedene Leute oder sogar Abteilungen verteilt, so wie polb das im vorigen Beitrag beschrieben hat. Ein geordneter Entwicklungsprozess dauert vielleicht etwas länger, erhöht aber deutlich die Qualität des Produkts. In einer Frickelbude ist das natürlich egal, hauptsache es wird etwas ausgeliefert. Da darf dann auch mal der Hardware-Entwickler wie im Thread beschrieben die Software machen, kann ja nicht so schwer sein. Eigentlich kann er das Zeug auch gleich noch testen, wo er gerade dabei ist, und dann raus damit zum Kunden!
Claus M. schrieb: >> In vielen kleinen Buden macht eine Person >> Software und Hardware. > > Ja, in Frickelbuden. Abgesehen davon, daß Du die Aussage von 'polb' nicht verstanden und verdreht hast, bin auch ich eine 'Frickelbude'. Allein schon, daß ich IAR empfehle, disqualifiziert mich total ;-)
Die Codequalitaet von vielen Produkten ist Schott, weil das Konzept schon Schott ist. Auch wenn alle Qualitaetsansprueche, und Dokumentationsvorgaben erfuellt werden. Das betrifft auch die Autoindustrie. Zb. Weshalb muss ich die Uhr alle halb Jahre neu einstellen, wenn ich schon ein GPS an Board habe ? Das kann's ja nicht sein. Weshalb gibt es nirgendwo einen Konfigurator ? zB fuer immer wenn es sich bewegt, das Licht ein, und beim Stehen, nach N Miunten aus. Nein, das nennt sich dann Laenderspezifische Konfiguration, die ist gesetz, je nach Land, wo ich das Auto kaufe. Das Navi ist eine Vollkruecke. Ich kann zB nicht Kleinochsenberg (Zentrum) eingeben. Ich werde gezwungen eine Strasse inklusive Nummer einzugeben. Updaten geht natuerlich nur per Custom CD, wo man dann merkt, dass man Freiwild ist. Unter Software testen versteht man, das Produkt wird als Produkt getestet. Ist es vom Kunden vernuenftig bedienbar. Keine zwoelf Affengriffe, die man genau einmal im Jahr braucht. Auch wenn diese Definition von der Definition wie sie von Entwicklern kommt abweicht. Sorry.
:
Bearbeitet durch User
Zilp Z. schrieb: > Weshalb gibt es nirgendwo einen Konfigurator ? Konfiguratoren gab es die Tage bei Aldi. Oder was war Dein Problem?
Zilp Z. schrieb: > Die Codequalitaet von vielen Produkten ist Schott, weil das > Konzept schon Schott ist. Auch wenn alle Qualitaetsansprueche, und > Dokumentationsvorgaben erfuellt werden. > Das betrifft auch die Autoindustrie. Wie du in deinen Beispielen verstanden hast, liegt die Schuld eben nicht im Code, sondern im Konzept. Wie viele verschiedene Zulieferer gibt es bei jedem Auto? Viele! Wer macht das Konzept? Keiner von denen die es entwickeln. Eine gute Software erfüllt die Requirements, nicht was sich irgendeine Person als optimal vorstellt. Der Code kann gar nicht Schrott sein, wenn alle Vorgaben erfüllt sind. Es ist sehr einfach ein fertiges Produkt zu kritisieren.
Konrad schrieb: > Klingt auf jeden Fall nach unprofessioneller Frickelbude. Schau, > dass du > da möglichst schnell wegkommst. Hewlett und Packard haben auch in einer Garage angefangen...
> Es ist sehr einfach ein fertiges Produkt zu kritisieren.
Als Kunde bin ich die ultimative Autoritaet was das Produkt anbetrifft.
Ich kann's kaufen, muss aber nicht. Wenn das Produkt wegen einem
vermurksten Konzept Schrott kauf ich allenfalls etwas anderes.
Man muss teilweise schrottige Konzepte hinnehmen, bis ein Mitbewerber
mit etwas besserem daherkommt.
Es gibt spezielle Labors, da wird die Benutzbarkeit von Produkten mit
Kunden und Entwicklern erarbeitet. Diesen Schritt kann man natuerlich
weglassen, wenn man sowie der Hirsch ist, und es keinen "besseren"
gibt...
:
Bearbeitet durch User
So wie die deutschen OEMs dominieren, gibt es also keinen Grund ihre Software zu kritisieren. Die Kunden kaufen es ja und die Hersteller melden fast Jahr für Jahr ein Rekordjahr. Dann ist deine Meinung wohl nicht repräsentativ.
Matthes schrieb: > seit wann sind Dipl.-Ing.s Programmierer? In sehr vielen Firmen sind sie genau das. Lothar M. schrieb: > Auf jeden Fall kann ein Ing. Elektronik einen uC schneller verstehen und > besser und effizienter programmieren als ein technischer Informatiker. Wie kommst Du auf das schmale Brett? :-( Jemand der Technische Informatik studiert hat, hat doch genauso auch Grundlagen der Elektrotechnik an der Hochschule gehört. Er hat ebenso µC im Studium programmiert wie sein E-Tec Kollege. Also warum sollte er das weniger gut können? F. F. schrieb: > Was du letztlich nimmst, das hängt doch im großen Maße von der Anwendung > ab. This. Am Allerwichtigsten ist ein vernünftiges Requirements Management. Also erstmal ein anständiges Lastenheft aufstellen, und dann erst die Hardware auswählen. polb schrieb: > Eine gute Software erfüllt die Requirements, nicht was sich irgendeine > Person als optimal vorstellt. Der Code kann gar nicht Schrott sein, wenn > alle Vorgaben erfüllt sind. Diese Aussage ist definitiv und hundertprozentig falsch. "Requirements erfüllt" und "Code ist lesbar, verständlich und gut zu warten" ist NICHT das gleiche.
Mark B. schrieb: > Diese Aussage ist definitiv und hundertprozentig falsch. "Requirements > erfüllt" und "Code ist lesbar, verständlich und gut zu warten" ist NICHT > das gleiche. Zu den Anforderungen gehört es auch die Coding-Guideline und MISRA zu erfüllen. Darum macht das Review ja auch jemand anderes. Damit sind deine Punkte abgedeckt.
polb schrieb: > Zu den Anforderungen gehört es auch die Coding-Guideline und MISRA zu > erfüllen. Darum macht das Review ja auch jemand anderes. Damit sind > deine Punkte abgedeckt. Bei Automotive-Projekten, in denen streng nach Vorgaben gearbeitet wird, mag das so sein. Für Industrieprojekte im Allgemeinen gilt das so leider nicht.
Hallo… ich nochmal. Erst einmal vielen Dank für die vielen Tipps und konstruktiven Beiträge. Zweitens ein paar Worte zu denen, die so gern Gift und Galle spucken… Man kann auch in C programmieren ohne einen Mikrocontroller. Es soll auch auf einem PC ganz gut funktionieren. Des weiteren frickel ich nicht im Hobbykeller rum. Dafür habe ich als Ehemann und Vater kaum Zeit und verbringe diese lieber mit meiner Familie. Und ich fange genau aus oben genannten Gründen nicht schon heute an, da zuerst ein ordentliches Pflichtenheft usw. her muss. Um euch den Wind aus den Segeln zu nehmen ich bin der unerfahrenste, blondeste Ingenieur den man sich so vorstellen kann. Kann damit aber ganz gut leben und mache nicht jeden der weniger weiß dumm von der Seite an. Zurück zu den netten hier im Forum: Budget. Mein Chef rechnet da recht einfach. Festeinstellung eines Programmierers macht kein Sinn. Also eine Zeitkraft für eine bestimmte Zeit. Wir schätzen 3 Monate um sich in das Thema einzuarbeiten, 3 Monate Vollzeit programmieren aber dann kommen noch etliche Tests, Optimieren, Ausprobieren, usw. Das braucht ca. 6 Monate, jedoch ist dies keine Vollzeitaufgabe mehr. Wir sind schon im Thema drin, brauchen eventuell 6 Monate zum Programmieren und dann 6 Monate fur Tests, Optimieren, Ausprobieren, usw. Auch hier ist das eher keine Vollzeitaufgabe mehr. Unser Chef bevorzugt das wir es selber machen, selbst wenn wir 3 Monate länger bräuchten. Er sieht da keinen finanziellen Vorteil. Der Programmierer ist irgendwann weg und ist eventuell nicht mehr verfügbar. Auch wird es in Zukunft immer wieder mal Programmieraufgaben geben. Haben ja noch ein paar andere Produkte. Stimmt, wir können ein wenig spielen, dafür ist Raum in dieser Firma. Das Produkt wurde vor 3 Jahren extern entwickelt und existiert schon seit einiger Zeit, ist aber nun an seine Grenzen angelangt. Wir arbeiten nun an Generation 2 und haben schon einen Prototypen am Laufen der Dinge macht die andere für unmöglich hielten. Und ja, wir können klotzen da die Firma mit diesem Produkt Geld macht. Des weiteren ist mein Chef nicht vom Fach. Wenn ich sage es dauert 8 Wochen die LED blinken zu lassen dann glaubt er mir das. Spätere Tests werden nicht von mir durchgeführt sondern zuerst von Kollegen und dann auch Kunden. Viele liebe Grüße
Farin U. schrieb: > Spätere Tests werden nicht von mir durchgeführt sondern zuerst von > Kollegen und dann auch Kunden. Dass die Kunden für Euch testen sollen, ist jetzt aber nicht dein Ernst?
Sorry, das war etwas übers Ziel hinausgeschossen bzw. falsch ausgedrückt. Wir haben einen automatischen Tester der das Produkt entsprechend anregt und die Ausgänge ueberwacht. Natürlich lasse ich den Kunden nicht die funktionalen Tests machen... Es wird eine Demonstration für Kunden geben. Diese werden das Produkt bewerten...
> Dass die Kunden für Euch testen sollen, ist jetzt aber nicht dein Ernst?
Wo ist da jetzt dein Problem? Komm mal von deinem Grossindustrie-Trip
runter ;) Bei Spezialentwicklungen kommt es oft vor, dass der einzig
realistische Test nur in der Kundenumgebung unter deren Mithilfe machbar
ist. Und gerade bei kleineren Firmen ist es dann auch noch ohne grosse
Bürokratie möglich, die Requirements im Reality-Check zu optimieren.
Mark B. schrieb: > Lothar M. schrieb: >> Auf jeden Fall kann ein Ing. Elektronik einen uC schneller verstehen und >> besser und effizienter programmieren als ein technischer Informatiker. > Wie kommst Du auf das schmale Brett? :-( Ich bin selbst mit Praktikanten/Diplomanden/Bacheloranden mehrfach drauf gestanden... > Jemand der Technische Informatik studiert hat, hat doch genauso auch > Grundlagen der Elektrotechnik an der Hochschule gehört. Er hat ebenso µC > im Studium programmiert wie sein E-Tec Kollege. Also warum sollte er das > weniger gut können? Weiß ich nicht. Mir ist der Lernprozess unbekannt, ich kann nur die Auswirkungen beschreiben. Vielleicht hatten die technischen Informatiker nicht ausreichend gut "gehört". Denn die schrieben da unbedarft Dinge in ihre C-Dateien, da konnte ich auf Anhieb erkennen, dass das schiefgehen wird. Gut, ich habe die Jungs weiterwerkeln lassen. Und nach einiger Zeit stellte sich heraus: der uC ist zu langsam, der kann das nicht! Fertig! Dann habe ich die Burschen bei der Hand genommen und ihnen einen Ausweg aus dem Dilemma gezeigt. Und voila: nach einer Woche konnte der uC das, was er sollte und es war sogar noch "Luft" im System. Mit Elektronikern habe ich das nie erlebt. Denen war von Anfang an klar, dass ein C-Befehl nicht in der Zeit 0 bearbeitet wird. Den technischen Informatikern musste ich das ert noch an ein paar Dreizeilern deutlich aufzeigen. Kann natürlich auch sein, dass die Elektroniker insgesamt eher durch entsprechende Freizeitbeschäftigung mit der Thematik "vorbelastet" waren...
Farin U. schrieb: > Budget. Mein Chef rechnet da recht einfach. Festeinstellung eines > Programmierers macht kein Sinn. Wieso denn das? Es wurde doch eine Stelle ungeplant frei, also gab es doch wohl Bedarf und Budget für eine Vollzeitszelle. Jedenfalls laut Planung. > Auch wird es in Zukunft immer wieder mal Programmieraufgaben geben. Und eben deshalb ergibt die obige Aussage keinen richtigen Sinn. Wer würde diese Aufgaben denn ausführen, wenn Du gerade mal wieder voll mit der Entwicklung von Hardware beschäftigt bist? Wer welche Aufgaben im aktuellen Projekt übernimmt und wie viele Leute man insgesamt in der Firma braucht sind doch zwei Paar Schuhe.
:
Bearbeitet durch User
Farin U. schrieb: > z.B Microchip. Prozessor, Compiler, Programmiergerät alles aus einem > Haus und der Support wäre super... Wir nehmen STM32 mit IAR und Segger embOS (RTOS) und sind damit die letzten 7 Jahre sehr gut gefahren. Kostet halt, aber der Support ist auch sehr fix. Programmiergerät ist ein Segger J-Link.
Lothar M. schrieb: > Mit Elektronikern habe ich das nie erlebt. Falls das jetzt auf Informatiker Bashing rauslaufen sollte: hab auch schon Code von Nachrichtentechnikern (C++) und E-Techniker (C) gesehen, der nur zum Davonlaufen war. Funktion mit 21 Parametern usw. Nur mal so am Rande, um manche hier wieder zu erden.
Anti-DL schrieb: > embOS (RTOS) und sind damit die > letzten 7 Jahre sehr gut gefahren. Kostet halt, aber der Support ist > auch sehr fix. Danke, ich streng mich an damit der Support gut ist ;-).
Lothar M. schrieb: > Vielleicht hatten die technischen Informatiker nicht ausreichend gut > "gehört". Denn die schrieben da unbedarft Dinge in ihre C-Dateien, da > konnte ich auf Anhieb erkennen, dass das schiefgehen wird. Gut, ich habe > die Jungs weiterwerkeln lassen. Und nach einiger Zeit stellte sich > heraus: der uC ist zu langsam, der kann das nicht! Fertig! > Dann habe ich die Burschen bei der Hand genommen und ihnen einen Ausweg > aus dem Dilemma gezeigt. Und voila: nach einer Woche konnte der uC das, > was er sollte und es war sogar noch "Luft" im System. > Mit Elektronikern habe ich das nie erlebt. Denen war von Anfang an klar, > dass ein C-Befehl nicht in der Zeit 0 bearbeitet wird. Den technischen > Informatikern musste ich das ert noch an ein paar Dreizeilern deutlich > aufzeigen. Naja, jeder hat so seine Erfahrungen. Ich bin da eher auf Marks Seite. Im Info-Studium waren die technischen Grundlagen Pflichtveranstaltung und da war auch allen klar, wie Controller (damals noch 80186) funktionieren und dass die Bearbeitungszeit nicht Null ist :-) > Kann natürlich auch sein, dass die Elektroniker insgesamt eher durch > entsprechende Freizeitbeschäftigung mit der Thematik "vorbelastet" > waren... Ja, das macht viel aus. Ich musste bspw. gestandenen diplomierten E-Technikern (also den Übungsleitern!) im Praktikum erklären, was ein OC-Ausgang ist. Damit (SN7406) hatte ich vorher schon rumgebastelt :-) Genauso könnte ich sagen, dass vielen E-Technikern das Gespür dafür fehlte, welche Laufzeiten sich durch verschiedene Algorithmen ergeben oder wie man Datensätze effizient verwaltet. Einfach weil die Grundlagen nicht da waren. E-Techniker sind eben keine Informatiker (und umgekehrt). Man kann sich aber sehr viel selbst aneignen und wenn man das vorher schon hobbymäßig betreibt, dann fällt einem natürlich vieles deutlich leichter, weil man die Praxis zumindest ein wenig kennt.
Ich habe auch schon viel gruseligen Code von reinen E-Technikern gesehen... Einigen wir uns doch darauf: Der beste Code für mechatronische Systeme kommt dabei heraus, wenn sich die Kompetenzen der verschiedenen Fachgebiete ergänzen. Also wenn der E-Techniker nicht ignorant gegenüber Software-Architektur und Software-Design ist, und der Informatiker nicht ignorant gegenüber der Hardware.
:
Bearbeitet durch User
Lothar M. schrieb: > Auf jeden Fall kann ein Ing. Elektronik einen uC schneller verstehen und > besser und effizienter programmieren als ein technischer Informatiker. Da spricht der Herr Inscheniör. Einfach lachhaft. Oder ist das ein Trollversuch? Ich hab in den letzten 8 Jahren Embedded-Entwicklung keinen (in Zahlen 0) E-Techniker getroffen mit auch nur einer leisen Ahnung von SW-Entwicklung. S.
Stefan schrieb: > Lothar M. schrieb: >> Auf jeden Fall kann ein Ing. Elektronik einen uC schneller verstehen und >> besser und effizienter programmieren als ein technischer Informatiker. > > Da spricht der Herr Inscheniör. Einfach lachhaft. Oder ist das ein > Trollversuch? > Ich hab in den letzten 8 Jahren Embedded-Entwicklung keinen (in Zahlen > 0) E-Techniker getroffen mit auch nur einer leisen Ahnung von > SW-Entwicklung. > S. Also alle doof außer dir? Ein gepflegtes Syndrom unter SW-Entwicklern. Ich hab in mehreren Firmen gearbeitet wo ausschließlich E-Techniker die Embedded-SW gemacht haben. Sicher alles völlig unbrauchbar. Müsste man mal die Profis aus der Informatik ranlassen. Problem: Ohne Terrabyte-Flash kommen die nicht aus!
Claus M. schrieb: > Problem: Ohne Terrabyte-Flash kommen die nicht aus! Doch, tun wir ;-) ST hat jedenfalls noch keine STM32 mit so viel Flash rausgebracht - ich wäre aber nicht abgeneigt ;-) Nun hört mal auf, Euch irgendwelche übertriebenen Verallgemeinerungen um die Ohren zu hauen. Gute Leute gibt es überall und wenn man sich in die Materie einarbeitet, dann kann man auch auf nichtstudiertem Gebiet sehr gute Leistung abliefern. Im Mikrocontrollerbereich geht das nötige Knowhow mMn sowieso immer mehr weg von der reinen Elektrotechnik hin zur Informatik. Es gibt immer mehr nichttriviale Embedded-Systeme mit RTOS, Tasks, Semaphoren, grafischen Oberflächen, Protokollen, Netzwerkfähigketen und abstrakten Schichtenmodellen. Und diese Softwareentwicklung bestimmt immer mehr die Entwicklungsdauer, die reine Elektronik tritt (vom Zeitaufwand her gesehen) immer weiter in den Hintergrund. Eigentlich steigen da die Chancen und Einbringungsmöglichkeiten - selbst für reine Informatiker.
:
Bearbeitet durch Moderator
Chris D. schrieb: > Und diese Softwareentwicklung bestimmt immer mehr die Entwicklungsdauer, > die reine Elektronik tritt (vom Zeitaufwand her gesehen) immer weiter in > den Hintergrund. > > Eigentlich steigen da die Chancen und Einbringungsmöglichkeiten - selbst > für reine Informatiker. So sieht's aus. Aber auch die reinen Informatiker dürfen wissen, wofür EMV steht und welches das heiße Ende vom Lötkolben ist :-)
Stefan schrieb: > Ich hab in den letzten 8 Jahren Embedded-Entwicklung keinen (in Zahlen > 0) E-Techniker getroffen mit auch nur einer leisen Ahnung von > SW-Entwicklung. Ich bin ehrlich gesagt sehr froh, dass ich, obwohl ich E-Techniker bin, auch mal in einer Abteilung für Softwareentwicklung gearbeitet habe. Obwohl ich schon längere Zeit programmiere, war der ganze Entwicklungsprozess, Dokumentationsvorgaben, Testvorgaben etc. erstmal neu für mich. Eine sehr wertvolle Erfahrung war das!
Mark B. schrieb: > Wieso denn das? Es wurde doch eine Stelle ungeplant frei, also gab es > doch wohl Bedarf und Budget für eine Vollzeitszelle. Jedenfalls laut > Planung. Du passt wirklich auf... Man könnte meinen du suchst förmlich nach einem Widerspruch... na wenigstens kann man dir nicht vorwerfen du hättest nicht richtig gelesen... Alte Situation: SW Ingenieur der uns verlässt und HW Ingenieur (ich) Neue Situation: Ein Kollege aus Qualität und ich bilden ein Team und sollen den SW Ingenieur 'spielen' wobei die Qualitätsstelle neu besetzt werden muss. Der jetzige Qualitätskollege ist recht geil auf diese Möglichkeit da er nebenbei abends Elektrotechnik studiert und gerne aus Qualität raus möchte. Bezüglich dem Spagat HW / SW mache ich mir zur Zeit keine großen Gedanken da die meisten Dinge bei uns der Reihe nach abgearbeitet werden. Also HW dann SW. Sollte der Kollege wirklich gut sein wird er wahrscheinlich die SW uebernehmen. LG
Mark B. schrieb: > > Einigen wir uns doch darauf: Der beste Code für mechatronische Systeme > kommt dabei heraus, wenn sich die Kompetenzen der verschiedenen > Fachgebiete ergänzen. Also wenn der E-Techniker nicht ignorant gegenüber > Software-Architektur und Software-Design ist, und der Informatiker nicht > ignorant gegenüber der Hardware. genau so ist es!
Johannes O. schrieb: > Stefan schrieb: >> Ich hab in den letzten 8 Jahren Embedded-Entwicklung keinen (in Zahlen >> 0) E-Techniker getroffen mit auch nur einer leisen Ahnung von >> SW-Entwicklung. > > Ich bin ehrlich gesagt sehr froh, dass ich, obwohl ich E-Techniker bin, > auch mal in einer Abteilung für Softwareentwicklung gearbeitet habe. > Obwohl ich schon längere Zeit programmiere, war der ganze > Entwicklungsprozess, Dokumentationsvorgaben, Testvorgaben etc. erstmal > neu für mich. > Eine sehr wertvolle Erfahrung war das! Und du glaubst, Informatiker kennen sowas? Meinst du bei Microsoft, Google oder Co wird so entwickelt? Nein, das kommt aus der Welt der Ingenieure, nicht der Informatiker.
Idioten mit Diplom bzw. Master gibts überall. Im Endeffekt kommt es nicht auf den Abschluss an, sondern auf die persönlichen Interessen. Hat dann auch weniger mit praktisch vs. theoretisch zu tun, sondern einfach mit begabt oder unbegabt ;)
Georg A. schrieb: >> Dass die Kunden für Euch testen sollen, ist jetzt aber nicht dein Ernst? > > Wo ist da jetzt dein Problem? Komm mal von deinem Grossindustrie-Trip > runter ;) Bei Spezialentwicklungen kommt es oft vor, dass der einzig > realistische Test nur in der Kundenumgebung unter deren Mithilfe machbar > ist. Und gerade bei kleineren Firmen ist es dann auch noch ohne grosse > Bürokratie möglich, die Requirements im Reality-Check zu optimieren. Machen auch die Großen. Wir nennen diese Fahrzeuge "Feldtestgeräte" und fahren sehr gut damit, diese bei ausgesuchten Kunden zu testen.
Farin U. schrieb: > Bezüglich dem Spagat HW / SW mache ich mir zur Zeit keine großen MikroC von mikroelektronika kann ich empfehlen. Die Toolchain ist aus einem Guss und wird von deren Boards, Modulen und Proggern gut bis sehr gut unterstützt. Realtime debugging direkt aus dem Sourcecode funzt out of the box und der Support ist auch ok. Diverse Plattformen (hab selber mit Pic, Pic16, Pic32 und STM Arm gearbeitet) und imho ausgereifte libs. Alles gut dokumentiert und sehr benutzerfreundlich. Dann haben Sie noch jede Menge sog. "Clicks". Module die fast alle Bereiche der Hardware abdecken und immer mit Sourcecode und Beispielen kommen. Der Atmel compiler scheint mir aber etwas lieblos behandelt zu werden. Da ist der gcc einfach zu stark nehme ich an und es lohnt sich nicht.
Hallöchen, nochmals vielen Dank für die Antworten. Habe am Wochenende mit unserem Hauptsitz gesprochen und in die engere Wahl kommen ARM Cortex M0/3 oder PIC32. Hat da vielleicht jemand tiefergehende Erfahrungen mit und würde diese gern teilen? MfG
Bei Cortex M3/M0 sieht es hier im Forum gut aus (Siehe Filter: ARM). PIC32 würde ich nur nehmen wenn schon Erfahrung in der Richtung vorhanden ist.
:
Bearbeitet durch User
Wegen kommerziell und aus einer Hand: Hat einer von euch schon was mit den Infineon XMCs gemacht und deren IDE Dave? Da kann man meines Wissens auch später noch zu Keil / IAR migrieren, falls gewollt? thx, tk
t_k schrieb: > IDE Dave? > Da kann man meines Wissens auch später noch zu Keil / IAR migrieren, > falls gewollt? Dave ist keine IDE bzw. hat keinen Compiler, sondern soll nur die Konfiguration von Peripherie erleichtern. Es gibt von ST aber was vergleichbares (glaube CubeMX oder so heißt).
Guest schrieb: > Das Problem mit dem ganzen *buntu mist und > Debian ist, dass die Pakete im Repo veraltet sind. DESWEGEN muss man > ständig mist selber compilen oder dritt-repos einfügen. Ach, ist das so? Wenn ich auf http://openocd.org/ gehe, blinkt mich eine Meldung vom 18. Mail 2015 an: "OpenOCD 0.9.0 release". Dann schaue ich auf mein Kubuntu 15.10:
1 | $ apt-cache show openocd | grep '^Version:' |
2 | Version: 0.9.0-1build1 |
Auf http://gcc.gnu.org/ vom 16. Juli 2015: "GCC 5.2 released", auf meinem Kubuntu:
1 | $ apt-cache show gcc | grep '^Version:' |
2 | Version: 4:5.2.1-3ubuntu1 |
Also ich sehe da nun wirklich nichts, das veraltet wäre. Darüber hinaus muß man selbstverständlich nicht immer die allerneuesten Pakete benutzen, wobei auch das dank Backports und PPAs meist problemlos möglich ist. Aus diesem Grund wäre es begrüßenswert, wenn Du auf solche unprofessionellen und falschen Aussagen verzichten und wenigstens ehrlich darauf hinweisen würdest, daß Deine Abneigungen gegen Ubuntu und Deine Zuneigung zu Arch Linux nicht sachlich, sondern ideologisch geprägt sind. Danke.
Georg A. schrieb: > Ich versuche daher, normale IDEs zu vermeiden, Basis ist immer make und > emacs. Tastaturcodes identisch unter Windows, Mac und Linux, keine > Umgewöhnung notwendig. > [...] > Aber vermutlich bin ich einfach nur altmodisch ;) Das ist nicht altmodisch, sondern professionell und kompetent. Du willst Dich nicht in das bringen lassen, was der Jurist eine Einsperrung nennt.
X4U schrieb: > MikroC von mikroelektronika kann ich empfehlen. > funzt out of the box Trau nie jemandem, der "funzt" sagt oder schreibt. Die Compiler von Mikroelectronika sind bis heute nicht durch Qualität aufgefallen. Das ist was für Leute die, wenn sie die Wahl zwischen "einfach" oder "richtig" haben, natürlich "einfach" wählen.
Farin U. schrieb: > Habe am Wochenende mit unserem Hauptsitz gesprochen und in die engere > Wahl kommen ARM Cortex M0/3 oder PIC32. > > Hat da vielleicht jemand tiefergehende Erfahrungen mit und würde diese > gern teilen? Ich würde eher ARM Cortex M nehmen. Dafür bekommst du einfach mehr IDEs, Compiler, Evalboards, Devices, Debug Probes, Sample Code, usw. Ich benutze z.B. einen STM32 mit dem ganzen Kram von Segger, also J-Link, SES, embOS, usw... und der Kram funktioniert einfach. So kann ich mich auf meine Applikation konzentrieren. Wenn ich ein Auto repariere will ich ja nicht erstmal das Werkzeug dafür zusammenbasteln müssen. Ist wie in jedem Bereich, mit professionellen Werkzeug bekommt man auch bessere Ergebnisse.
Keine Programmier / Architekturerfahrung und als einziger(?) Entwickler? Viel Glück, ist zum Scheitern verurteilt.
Filth _. schrieb: > Keine Programmier / Architekturerfahrung und als einziger(?) Entwickler? > Viel Glück, ist zum Scheitern verurteilt. Nö, denn Software kann auch funktionieren wenn sie keine gute Qualität aufweist (bezüglich Architektur und Design, Lesbarkeit des Codes, Wiederverwendbarkeit etc.) Aber hinderlich ist es schon wenn keiner dabei ist der Ahnung hat wie man ein solches SW-Projekt richtig aufsetzt und durchzieht. Wer soll dann die Reviews machen?
Mark B. schrieb: > Aber hinderlich ist es schon wenn keiner dabei ist der Ahnung hat wie > man ein solches SW-Projekt richtig aufsetzt und durchzieht. Was heißt hier schon "hinderlich", das geht doch trotzdem und vielleicht sogar schneller. ;o) > Wer soll dann die Reviews machen? Na der Entwickler selbst natürlich. Er ist ganz einfach Requirements Engineer, Developer, Reviewer und Tester zugleich! ;o) Wer in diesem Beitrag Sarkasmus findet, darf ihn behalten.
Servus Farin, erstmal heftige Situation und viel Glück. Ich hoffe ihr habt wirklich genug Zeit alles sauber zu planen. Wenn die Möglichkeit eines Kurses besteht, dann solltest du unbedingt etwas zum Thema Codestrukturierung machen und einen Einsteigerkurs für die ARM-Welt. Darf man denn fragen ob es sich hierbei um ein automotive-Produkt handelt? Fragen die du vorab klären solltest: (1) Was sind die Randbedingungen/Anforderungen für das Produkt? (2) Welche/r Spannungspegel(Leiterplatte/µC) ist gefordert? (3) Wie sieht es mit reprogrammierung im fertigen Produkt aus? (Spannungsfestigkeit der Pins, meiner Erfahrung nach sind die ARM anfälliger als die PICs, falls der Kunde damit in Kontakt treten kann --> ESD!) In deinem Fall kann ich dir aber auch den ARM empfehlen, dank des großartigen Supports. (4) Welche peripherie wollt ihr denn genau verwenden? (Unbedingt Tests mit ausführen bevor ihr in die Designphase startet) Kann aus eigener Erfahrung sagen, wenn das Projekt zu 90% im Ziel ist und dann auffällt, dass der ADC maximal sichere 8 Bit anstelle der im Datenblatt angegebenen 11 Bit kann, kann es sehr ungemütlich werden im Entwicklerstuhl. Hoffe das hilft weiter. beste grüße public
Ingenieur schrieb: > Na der Entwickler selbst natürlich. Er ist ganz einfach Requirements > Engineer, Developer, Reviewer und Tester zugleich! ;o) Nun, bezüglich der Hardware-Entwicklung in dieser Firma waren diese Rollen doch gewiss auf mehrere Personen verteilt. Nicht wahr Farin U.? > Wer in diesem Beitrag Sarkasmus findet, darf ihn behalten. :-)
Ich bin froh, dass mein Unternehmen nicht so dilettantisch arbeitet
public schrieb: > Wenn die Möglichkeit eines Kurses besteht, dann solltest du unbedingt > etwas zum Thema Codestrukturierung machen und einen Einsteigerkurs für > die ARM-Welt. Wo gibt es so was?
F. F. schrieb: > public schrieb: >> Wenn die Möglichkeit eines Kurses besteht, dann solltest du unbedingt >> etwas zum Thema Codestrukturierung machen und einen Einsteigerkurs für >> die ARM-Welt. > > Wo gibt es so was? Zum Beispiel hier: http://www.hilf.de/
filth schrieb: > Ich bin froh, dass mein Unternehmen nicht so dilettantisch > arbeitet Genau das ist auch meine Meinung!
Das ganze nennt sich Softwaretechnik siehe http://www.w3l.de/w3lmedia/W3L/Medium156769/Softwaretechnik1BalzertPrinzipienDerSWT.pdf Kurse dazu gibt es bestimmt an jeder Uni/FH die Informatik als Fach anbietet. Zumindest kann man sich dort schon mal Bücher besorgen und mit den Fachleuten sprechen, vorallem wenn man grundlegende Fragen hat :) Bei www.ixquick.de kann man auch die Worte Softwaretechnik und Strukturierung eingeben. beste grüße public
public schrieb: > Das ganze nennt sich Softwaretechnik siehe > http://www.w3l.de/w3lmedia/W3L/Medium156769/Softwaretechnik1BalzertPrinzipienDerSWT.pdf > > Kurse dazu gibt es bestimmt an jeder Uni/FH die Informatik als Fach > anbietet. Zumindest kann man sich dort schon mal Bücher besorgen und mit > den Fachleuten sprechen, vorallem wenn man grundlegende Fragen hat :) Der Ansatz dürfte zu akademisch sein. Nicht jeder hat die Zeit, um mal eben eine Vorlesung an der örtlichen Hochschule als Gasthörer mitzumachen. (Auch wenn es interessant sein mag.) Auch sind Bücher und Skripte, die für Informatikstudenten geeignet sind, nicht notwendigerweise für beliebige andere Leser geeignet. Die Vorbildung bzw. Interessenslage ist einfach nicht die gleiche. Zuguterletzt: Wenn man ein Industrieprojekt zum Fliegen bringen soll, geht es auch immer um Zeit und Kosten. Gerade diese beiden Faktoren werden im akademischen Elfenbeinturm oft vernachlässigt oder gleich komplett ausgeblendet. Zusammengefasst ist daher ein Seminar bei einer Firma, die darauf spezialisiert ist Kunden aus der Industrie zu schulen, durchaus ein geeigneter Weg.
:
Bearbeitet durch User
Guest schrieb: > Melde dich doch einfach mal bei den Leuten von Segger (segger.com), da > kannst du alles was du brauchst professionel aus einer Hand bekommen: > [...] > > Und Schulungen machen die auch, sind zwar eigentlich Produktschulungen, > aber die haben auch kein Problem damit dir ein bisschen Grundlagen > beizubringen. Was spricht jetzt dagegen? Ist doch schon vorgeschlagen worden.
Hugo schrieb: > Guest schrieb: >> Melde dich doch einfach mal bei den Leuten von Segger (segger.com), da >> kannst du alles was du brauchst professionel aus einer Hand bekommen: >> [...] >> >> Und Schulungen machen die auch, sind zwar eigentlich Produktschulungen, >> aber die haben auch kein Problem damit dir ein bisschen Grundlagen >> beizubringen. > > Was spricht jetzt dagegen? Ist doch schon vorgeschlagen worden. Eventuell spricht dagegen, dass Firmen mit eigenen HW/SW Produkten natürlich vorrangig ihre eigenen Produkte verkaufen wollen. Ich würde mich lieber an eine Firma halten, die Schulungen unabhängig vom Hersteller anbietet - für verschiedenste Hardware, Betriebssysteme und Entwicklungsumgebungen. Der Themenersteller hatte ja selbst schon eine Firma vorgeschlagen (www.microconsult.de), die scheint zumindest vom Programmangebot her einen vernünftigen Eindruck zu machen.
:
Bearbeitet durch User
Mark B. schrieb: > Eventuell spricht dagegen, dass Firmen mit eigenen HW/SW Produkten > natürlich vorrangig ihre eigenen Produkte verkaufen wollen. > > Ich würde mich lieber an eine Firma halten, die Schulungen unabhängig > vom Hersteller anbietet - für verschiedenste Hardware, Betriebssysteme > und Entwicklungsumgebungen. Super, ich gehe also zu einer Firma, die mir etwas über CPU A und IDE B erzählen, um dann später mit CPU C und IDE D zu arbeiten... Außerdem wie lange sollen denn die Schulungen gehen, um sich in verschiedene Hardware, OS und IDs schulen zu lassen...wochenlang? Die Schulungen bei Segger macht man ja auch eigentlich nachdem! man sich für deren Produkte entschieden hat. Also muss man keine Angst haben, das sie einem nochmal etwas verkaufen wollen ;-). Ich habe bei denen z.B. schon mal eine embOS Schulung gemacht. Dabei wurde ich nicht nur in embOS sondern auch allgemein in RTOS und Cortex M Grundlagen geschult. Und der konkrete Einsatz in meinem Produkt wurde auch noch besprochen. Mir war so eine konkrete Schulung lieber als nur so Blabla.
Tester schrieb: > Super, ich gehe also zu einer Firma, die mir etwas über CPU A und IDE B > erzählen, um dann später mit CPU C und IDE D zu arbeiten... Erstens kann man es anders herum machen. Also erst die Hardware / Programmiersprache / was auch immer wählen, und dann die Schulung. Zweitens kann man unabhängig von jeder IDE Software entwickeln. Texteditoren und make-Äquivalente gibt es immer. Drittens sind das meiner Meinung nach gar nicht die herausragenden Probleme. Was nützt es mir, wenn ich das Zielsystem zwar beherrsche, aber nach schludrigen Anforderungen entwickle? Fehler im Produkt werden dann erst sehr spät im Projektverlauf festgestellt, und dann wird es richtig teuer. > Außerdem wie lange sollen denn die Schulungen gehen, um sich in > verschiedene Hardware, OS und IDs schulen zu lassen...wochenlang? In einer idealen Welt wäre das so :-) In realen Industrieprojekten hat man selten mehr als eine Woche Schulung. Wenn überhaupt.
:
Bearbeitet durch User
public schrieb: > Das ganze nennt sich Softwaretechnik Danke! Das sieht schon mal gut aus. Nach so was habe ich eigentlich schon lange gesucht. Eine Sprache lernen, dazu gibt es sicher viele Bücher, aber wie man an komplexe Sachen ran geht, so was habe ich noch nicht gefunden. Nun gut, bisher habe ich nur kleine Sachen gemacht (und gebraucht), was man an meinem lieblings Controller (Attiny10) sicher leicht ablesen kann. So kann man doch wieder einmal was aus einem Thread für sich selbst raus ziehen.
F. F. schrieb: > So kann man doch wieder einmal was aus einem Thread für sich selbst raus > ziehen. Dafür ist das Forum ja auch da. Hier trifft sich die Creme de la Creme der Ingenieurselite.
Danke nochmals... Möchte mich nochmals kurz melden.... und das eine oder andere anmerken. Leider kann ich jedoch keine wirklichen Einzelheiten, was wahrscheinlich verständlich ist, breittreten. Das Produkt ist nicht fur den deutschen Markt und die gesetzlichen Bestimmungen passen auf eine Serviette bzw. gibt es diese nicht wirklich, speziell was HW und SW betrifft. Ein paar mehr uebergeordnetet Regeln die auch nicht wirklich bis ins letzte Detail geordnet sind. Jedoch ist das Produkt Automotivenah. Der uC wird ein paar Analogeingänge, Digitalein- und Ausgänge sowie ein paar niederfrequente PWM Signale verarbeiten. Es wird ein LCD Display geben, CAN (nichts mit Vector, nur Diagnose), LIN (nur Diagnose) und ein Zigbee Modul. Die HW wird von uns gemacht und ist in Teilen mit Hilfe eines Arduino Duo funktionell schon getestet. In der SW wird hauptsächlich gerechnet (FIR, IIR, Closed Loop Control, etc. Logging und Diagnose noch. Des weiteren würde wir gern ein RTOS einsetzten. Bevor jetzt jemand kommt... ja schon mit gearbeitet. Wir (2 Personen) können ca. 2-3 Kurse (jeder einzelne Kurs bis zu einer Woche) belegen. Falls nötig auch im Ausland und/oder einen 4. Kurs wenn es denn sein muss. Wir haben gesehen das zum Beispiel Microconsult auch Consulting bietet, auch dafür wären Mittel da. Wer dazu eventuell etwas sagen könnte, Erfahrungen und / oder andere Firmen kennt die das anbieten, wäre nett. Jedem in der Firma ist klar das dies eine zeitlich längere Strategie ist und das nicht immer alles einfach sein wird. Von Zeit zu Zeit muss man sich an neue Dinge rantrauen. Andernfalls ist es doch langweilig, oder? LG
:
Bearbeitet durch User
Farin U. schrieb: > Wir haben gesehen das zum Beispiel Microconsult auch Consulting bietet, > auch dafür wären Mittel da. Wer dazu eventuell etwas sagen könnte, > Erfahrungen und / oder andere Firmen kennt die das anbieten, wäre nett. Du kannst auch einen Freelancer anheuern. Die sind meist sehr gut im Entwicklerleben und der aktuellen Technik verankert, das ist ja ihr Brot-und-Butter Geschäft... > Des weiteren würde wir gern ein RTOS einsetzten. Warum? Auch mit RTOS muss dir klar sein: ein uC mit 1 Kern kann zur selben Zeit nur 1 Aufgabe erledigen. RT bedeutet also auch dort nicht "Echtzeit" im Sinne von "gleichzeitig". Das wird dir klar werden, wenns mal wirklich eng hergeht und auf die µs ankommt...
Lothar M. schrieb: >> Des weiteren würde wir gern ein RTOS einsetzten. > Warum? > Auch mit RTOS muss dir klar sein: ein uC mit 1 Kern kann zur selben Zeit > nur 1 Aufgabe erledigen. RT bedeutet also auch dort nicht "Echtzeit" im > Sinne von "gleichzeitig". Das wird dir klar werden, wenns mal wirklich > eng hergeht und auf die µs ankommt... Es nimmt dir aber trotzdem einiges an Arbeit ab, weil es einfacher ist die Aufgabe in einzelne getrennte "Task" auzuteilen. Gleichzeitig geht natürlich nicht aber trotzdem kann man entscheiden was höhere Echtzeitanforderungen hat und diesen z.B. eine höhere Task Priorität geben. Davon abgesehen, das man Initialisierungen bei bestimmten CPUs nicht unbedingt selber machen möchte (beim Cortex M kein Problem aber bei ARMv5, ARMv7A wirds schon lustiger). Die Applikation klingt ja schon danach, das mehere Aufgaben "gleichzeitig" erledigt werden müssen. Das in einer Superloop von Hand zu programmieren macht da nicht unbedingt Sinn. Kann man natürlich machen, aber wenn ich da als Ingenieur 2 Wochen dran sitze, damit das Timing stimmt, kann ich auch für 2.5KEuro z.B. ein embOS von Segger kaufen.
Farin U. schrieb: > Des weiteren würde wir gern ein RTOS einsetzten. Das macht man genau dann, wenn es gute Gründe dafür gibt. Die Gründe müssen sich aus den Anforderungen an das System ergeben. Wenn man Dinge wie Speicherverwaltung, Taskverwaltung und Dateisystemveraltung (sofern es Letzteres im System überhaupt gibt) genau so gut oder besser auch ohne Betriebssystem machen kann, dann braucht man auch keines einzusetzen.
Mark B. schrieb: > Wenn man Dinge wie Speicherverwaltung, Taskverwaltung und > Dateisystemveraltung (sofern es Letzteres im System überhaupt gibt) > genau so gut oder besser auch ohne Betriebssystem machen kann, dann > braucht man auch keines einzusetzen. Was für eine lustige Aussage...wenn ich ein Auto selber konstruieren und bauen kann und das noch in Nulllzeit, so das meine Arbeitszeit kein Geld kostet, dann brauche ich keines im Autohaus kaufen... Hat nur leider nichts mit der Realität zu tun. Rechne mal bitte aus wie lange du für 2.5KEuro (embOS object code Preis) arbeiten kannst und ob du in der Zeit ein komplettes RTOS mit BSPs für einen Haufen Evalboards erstellen kannst. Natürlich braucht man nicht für jede Aufgabe ein RTOS aber die Aufgaben, die heutzutage auf einem Mikrocontroller ausgeführt werden sollen, werden immer komplexer und umfangreicher. Es kommt ja auch keiner auf die Idee auf einem PC ohne OS zu arbeiten oder sich das OS erstmal selber zu schreiben.
Luis schrieb: > Natürlich braucht man nicht für jede Aufgabe ein RTOS Genau das ist doch meine Aussage. Wenn man keines braucht, dann verwendet man auch keins --> wenn man eines braucht, dann verwendet man es. Wie komplex oder wie simpel die Systemanforderungen im Endeffekt sind, kann man anhand der vorliegenden Beschreibung nicht so wirklich richtig erkennen. Kann sein dass ein RTOS hier sinnvoll ist. Kann sein dass nicht. Im übrigen habe ich nirgends geschrieben, dass man sein eigenes OS entwickeln soll. Aufgaben priorisieren kann man selbstverständlich auch ohne OS.
:
Bearbeitet durch User
Und nicht vergessen: auch die Einarbeit in ein RTOS und dessen "Denkweise" muss kalkuliert werden. Wie schon gesagt: interessant wirds dann, wenn für das RTOS 5ms schon "Echtzeit" sind, die Anwendung aber gerne 100µs hätte...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Wie schon gesagt: interessant wirds dann, wenn für das RTOS 5ms schon > "Echtzeit" sind, die Anwendung aber gerne 100µs hätte... Jain, das RTOS kennt keine 5 ms oder 100 usec. Das kennt nur Systemticks. Ist aber auch völlig egal, weil Taskwechsel natürlich nicht nur durch den Systemtick sondern durch jeden beliebigen Interrupt ausgelöst werden könnnen. Interessanter sind dann eher Begriffer wie Interrupt Latenz und Context Switching Time, also wie lange brauche ich von dem Interrupt (z.B. ein Notausschalter) bis ich in der Task ankomme und meinen Applikationscode ausführen kann. Wenn das nicht reicht, kann ich natürlich bestimmte Sachen auch direkt in der Interrupt Routine ausführen. Da gibt es aber auch noch Latenz weil diese Interrupts vom RTOS für interne Operationen gesperrt werden könnten. Deshalb gibt es bei vernünftigen RTOS wie z.B. embOS sogenannte Zero Latency Interrupts, die nie vom RTOS gesperrt werden. Ok, das wird jetzt hier sehr technisch und führt wohl zu weit ;-). Wissen muss man nur das man durch ein RTOS eigentlich immer nur gewinnt aber keine Nachteile im Timing zu befürchten hat.
Luis schrieb: > Wissen muss man nur das man durch ein RTOS eigentlich immer nur gewinnt Das RTOS selbst braucht also weder Rechenzeit noch Speicher? :-)
Mark B. schrieb: > Luis schrieb: >> Wissen muss man nur das man durch ein RTOS eigentlich immer nur gewinnt > > Das RTOS selbst braucht also weder Rechenzeit noch Speicher? :-) Bitte wenigstens komplett zitieren, denn es ging um das Timing und nicht um Speicherverbrauch oder Rechenzeit. Natürlich braucht es Speicher, aber wollen wir jetzt über vielleicht 50 Bytes Speicher für den Kernel Haare spalten? (und ja es kommt natürlich mehr dazu für Task Stacks, usw. aber das ist Applikationsabhängig) Wir reden hier schließlich über Anwendungen wo z.B. gleichzeitig USB Host, ein TCP/IP Stack und die Applikation laufen. Und ja, das RTOS braucht keine Rechenzeit während die Applikation in der Task läuft! Denn in dem Moment läuft die Applikation und nichts anderes. Also genauso schnell wie ohne RTOS. Evtl. läuft noch ein Systemtick, aber den brauche ich nicht unbedingt bzw. da gibt es auch geschickte Ansätze (Stichwort Tickless Mode). Wenn du aber den Systemtick und von mir aus auch noch Taskwechselzeiten mit rein rechnen möchtest, hast du üblicherweise eine CPU Auslastung für das RTOS von 1%-2%.
Ich wollte mich nochmals kurz melden.... Habe gestern nochmals mit einem guten Freund gesprochen und er raet mir jemand mit Erfahrung ins Boot zu holen. Wenigstens zeitweise um gemeinsam die Architektur auszuarbeiten, so dass spaetere Erweiterungen / Anderungen nicht immer wieder zur gesamten Umstrukturierung des Codes fuhren. Hat da eventuell jemand Erfahrungen? Micorconsult habe ich ja schon genannt... oder Hilf GmbH?
Farin U. schrieb: > Habe gestern nochmals mit einem guten Freund gesprochen und er raet mir > jemand mit Erfahrung ins Boot zu holen. Wenigstens zeitweise um > gemeinsam die Architektur auszuarbeiten War das vielleicht unser Freund Filth hier? Filth _. schrieb: > Keine Programmier / Architekturerfahrung und als einziger(?) Entwickler? > Viel Glück, ist zum Scheitern verurteilt.
Um Gottes willen.... Nein So zwischen dir und mir... Wenn mir jemand durch geistreiche Kommentare auffällt, dann schau ich mir ab und zu mal dessen Kommentare an. Weiter möchte ich das hier nicht ausführen. Ich hab ja schon die Hose runter gelassen und gesagt das ich ein 'Ingenieuramateur' bin. Damit lehne ich mich einfach nicht weit aus dem Fenster und wecke somit keine unerfüllbaren Erwartungen seitens der Leute die schreiben. Aber ich bin der Meinung alles lässt sich lernen. Vieleicht werde ich nie ein begnadeter Ingenieur / Programmierer sein aber das ist OK und sollte hier im Forum so akzeptiert werden. Ich habe ja auch noch andere Qualitäten... :) LG
:
Bearbeitet durch User
Farin U. schrieb: > Hat da eventuell jemand Erfahrungen? Kannst ja mal bei den Firmen anfragen, ob sie im Rahmen einer Schulung auch auf Euer konkretes Projekt eingehen können. Für zahlende Kunden machen die fast alles. ;-)
Luis schrieb: > Wissen muss man nur das man durch ein RTOS eigentlich immer nur > gewinnt aber keine Nachteile im Timing zu befürchten hat. Das habe ich aber schon signifikant anders erlebt. Mir gefällt hier aber das "eigentlich" vor dem "immer"... ;-)
Lothar M. schrieb: > Das habe ich aber schon signifikant anders erlebt. Mir gefällt hier aber > das "eigentlich" vor dem "immer"... ;-) Ich muss mich entschuldigen wenn ich diesen Thread wegen meiner Neugier entführe, aber was sind genau deine Erfahrungen? Mit welchem RTOS hast du diese gemacht und was waren die Probleme? Ich stecke in der Materie sehr tief drin, weniger als Anwender des RTOS aber mehr als dessen Entwickler ;-). Daher würde ich mich über Feedback freuen.
Guest schrieb: > Mit welchem RTOS hast du diese gemacht Mit Windows CE über viele Generationen hinweg. > und was waren die Probleme? Es waren Probleme, dass irgendwelche Treiber, das BIOS oder die Hardware die Echtzeit kaputt gemacht haben und der eine einzige relevante Interrupt um mehr als 100us gejittert hat. > Mit welchem RTOS hast du diese gemacht Ich spreche hier bewusst von einem RTOS, das eben auch Grafik und viele (universelle) Treiber mit sich bringt. Es ist mir klar, dass ein dediziertes und "schlankes" Embedded OS mit handverlesenen und optimierten Routinen da sicher effizienter ist, aber man kämpft da eben bei jeder neuen Hardware (z.B. USB-WLAN-Interface) erst mal selber rum, um die (wenn überhaupt möglich) zum Laufen zu bekommen.
Vielen Dank für dein Feedback. Lothar M. schrieb: >> Mit welchem RTOS hast du diese gemacht > Mit Windows CE über viele Generationen hinweg. Das erklärt einiges ;-). Ich muss gestehen ich kenne mich mit Windows CE überhaupt nicht aus aber wie du schon sagtest denke ich auch das man das nicht mit einem RTOS wie FreeRTOS, μC/OS oder Segger embOS vergleichen kann. Lothar M. schrieb: > [...], aber man kämpft da eben > bei jeder neuen Hardware (z.B. USB-WLAN-Interface) erst mal selber rum, > um die (wenn überhaupt möglich) zum Laufen zu bekommen. Klar, das ist natürlich ein Unterschied obwohl man ja mittlerweile bei Firmen wie Segger, so ziemlich alles bekommt. USB Device/Host, TCP/IP/WLAN gibt's bei denen auch (und die sorgen dafür das es auf einer bestimmten Hardware läuft).
Hallo, ich wollte mich nochmal kurz nach all der Zeit melden... Was soll ich sagen? Wir haben grünes Licht bekommen uns einen / mehrerer Lehrgänge zusammenzustellen. Gesagt, getan und nach langer Recherche ist ein Anbieter in die nähere Auswahl gekommen. Dann noch einen Projektplan und Budget ausgearbeitet und nun ist das alles schon seit einer Weile beim Management. Der Kollege der mitmachen wollte fällt aus, da er sich am letzten Wochenende entscheiden musste ob er sich auf sein Studium konzentriert (4 Scheine schreibt) oder im Projekt mitmachen möchte und das Studium ein wenig schleifen lässt Dem Management war dieser Termin bekannt und zur Zeit hören wir gar nichts mehr. LG
:
Bearbeitet durch User
Farin U. schrieb: > und nun ist das alles schon seit einer Weile beim Management. > > Dem Management war dieser Termin bekannt und zur Zeit hören wir gar > nichts mehr. Klingt jetzt nicht so, als ob das alles furchtbar dringend wäre...
Ja ich bin mir da auch nicht mehr so sicher... Nun gut, das ganze wurde von mir mit ca. 18 Monaten angesetzt. Angefangen von Spezifikationen schreiben bis zum Anlauf der Produktion. Hoert sich erstmal sehr lange an aber beinhaltet Testing (ca. 3 Monate), End Of Line Tester Entwicklung (waren das letzte mal 2 Monate) und solche banalen Dinge wie Prototypen beim Contract Manufacturer bestellen. Einige Bauteile sind Automotive und haben halt entsprechende Lieferzeiten. Environmental Tests (ca. 40 Tage), Software schreiben, usw, usw. Habe das Gefuehl das alle Plaene ueber den Haufen geschmissen werden und wir eine ganz andere Richtung gehen werden... Na mal sehen...
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.