Hi, was ist besser. Die fertige Bibliothek(wo halt die elementaren Sachen drin stehen, also die Stdio.h) für den Mikrocontroller vom Hersteller verwenden oder selber schreiben? Was ist gängig in der Industrie? Gruß
Das kann man so pauschal nicht sagen. Es gibt mehrere Faktoren wie personeller Zeitaufwand vs. Performance vs. Speicherbedarf. Um hohe Performance zu erreichen braucht es oft viel personellen Zeitaufwand. Zusätzlich ist es oft gebunden an eine Plattform da evtl in ASM. Und Performance steht immer in Konkurrenz mit Speicher. Da gilt es alleine schon abzuwägen wie Performant darf es denn sein und wieviel Speicher steht zur Verfügung. Selbst bei verhältnismäßig leistungsstarken Systemen hat man oft die Wahl. Nehme ich zum Beispiel ein glibc oder ein uClibc für mein Embedded Linux?
Definiere "besser". Meistens bedeutet besser, dass es mit wenig Zeitaufwand gut und stabil laufen soll. Deshalb, und da Zeit deutlich teurer ist als Speicher, werden die fertigen Bibliotheken in den meisten Fällen eingesetzt. Außerdem wurden diese schon ausgiebig getestet, da tausendfach genutzt.
> Was ist gängig in der Industrie?
Fuer irgendwelche Bastelsachen, Pruefaufbauten oder aehnliches kann man
Bibliotheken einsetzen.
Alles was zu Kunden rausgeht muss zu 100% selbst geschrieben sein. Wegen
Coderules/Styles, SIL, Zertifiziertung, Dokumentation, Fehler in
Libaries. Und ganz wichtig, du weisst nicht wie eine fremde Libary mit
deiner eigenen Soft harmoniert. Also wann sie wieviel Rechenzeit oder
Speicher braucht.
Allerdings sammeln sich in Firmen mit der Zeit auch eigene Libaries an
welchen den internen Standards entsprechen. Sowas setzt man natuerlich
gerne eine.
Ausnahmen sind dann noch Libaries die man von Fremdfirmen einkauft. Die
werden aber dann auditiert und bekommen den Arsch aufgerissen wenn es
Probleme gibt. Soll heissen es gibt da jemanden der sich verantwortlich
fuehlt.
Olaf
Man sollte zumindest zum Lernen eine Bibliothek selbst geschrieben oder zumindest angefangen/konzipiert haben, weil man IMHO so am besten mitbekommt was in eine Bibliothek gehört und was nicht. Und wenn man eine vorgefertige Bisbliothek übernimmt dann ist immer noch eine zur Pflege, Überprüfung und Anpassung der selben zu benennen. Auch bei einer Standardbibliothek muss man wissen was man tut.
0815 schrieb: > Die fertige Bibliothek(wo halt die elementaren Sachen > drin stehen, also die Stdio.h) Wenn du damit die Funktionen meinst die ganz offiziell zum Sprachstandart der verwendeten Sprache gehören sind diese natürlich immer vorzuziehen. Bei komplexeren Funktionen sieht es schon etwas differenzierter aus. Da stellt sich immer die Frage nach den Kosten für die Selbstentwicklung gegenüber dem Zukauf. Wenn man was bestimmtes öfters benötigt und die Eigenentwicklung auch nicht zu aufwendig ist kann sich das selber machen aber durchaus rechnen weil man diese meist recht schnell nach den eigenen Bedürfnis eines neuen Projektes anpassen kann und man auch nicht so schnell Probleme mit irgend welchen Lizenzsachen bekommt.
0815 schrieb: > Die fertige Bibliothek(wo halt die elementaren Sachen > drin stehen, also die Stdio.h) Auch Standardbibliotheken sind bekannt für Sicherhheitslücken https://en.wikipedia.org/wiki/C_standard_library#Concepts,_problems_and_workarounds schon deswegen sollte man eine Optimierung an das eigene System nicht ausschliessen. Oft lauern die Lücken in Codeabschnitten, die man nicht wirklich braucht.
0815 schrieb: > Hi, > > was ist besser. Die fertige Bibliothek(wo halt die elementaren Sachen > drin stehen, also die Stdio.h) für den Mikrocontroller vom Hersteller > verwenden oder selber schreiben? Was ist gängig in der Industrie? Was ist besser? Standardschraube für wenig Geld aus dem Baumarkt oder selber Eisen und Kohle schürfen, schmelzen, schmieden und ne Schraube draus machen?
Olaf schrieb: >> Was ist gängig in der Industrie? > > Fuer irgendwelche Bastelsachen, Pruefaufbauten oder aehnliches kann man > Bibliotheken einsetzen. > > Alles was zu Kunden rausgeht muss zu 100% selbst geschrieben sein. Was für ein Käse! Da kannst du ja gleich SÄMTLICHE Framewoks als QT etc. wegwerfen! Schon mal was von Modularisierung und Wiederverwendung gehört? > Wegen > Coderules/Styles, SIL, Zertifiziertung, Dokumentation, Fehler in > Libaries. Nicht jeder baut Raketen, die zum Mars fliegen sollen. > Und ganz wichtig, du weisst nicht wie eine fremde Libary mit > deiner eigenen Soft harmoniert. Also wann sie wieviel Rechenzeit oder > Speicher braucht. Alles gaaaanz schlimm. > Allerdings sammeln sich in Firmen mit der Zeit auch eigene Libaries an > welchen den internen Standards entsprechen. Sowas setzt man natuerlich > gerne eine. Jaja, der übliche, selbstgestrickte halbgare Quark.
0815 schrieb: > Was ist gängig in der Industrie? Es werden natürlich die Bibliotheken des Compilerbauers (z.B. IAR, Keil) verwendet. Man zahlt ja schließlich gutes Geld dafür und kriegt sie auch kaum effizienter selber geschrieben. Nur was man da nicht findet, macht man selber.
Olaf schrieb: >> Was ist gängig in der Industrie? > > Fuer irgendwelche Bastelsachen, Pruefaufbauten oder aehnliches kann man > Bibliotheken einsetzen. > > Alles was zu Kunden rausgeht muss zu 100% selbst geschrieben sein. Ich seh's anders rum: Als Bastler kann man sich (so man will) die Zeit nehmen, alles selber zu basteln, aber wer das professionell macht, kann sich das gar nicht leisten. Da muss man sich drauf konzentrieren, die eigentliche Funktionalität einzubauen und nicht den 10.000sten Aufguss der Standardbibliothek. > Wegen Coderules/Styles, SIL, Zertifiziertung, Dokumentation, Fehler in > Libaries. Und ganz wichtig, du weisst nicht wie eine fremde Libary mit > deiner eigenen Soft harmoniert. Also wann sie wieviel Rechenzeit oder > Speicher braucht. Dann musst du aber auch so konsequent sein und den Compiler auch selber schreiben, denn der erzeugt auch Code, der Fehler haben könnte oder mit deiner Software nicht harmonieren könnte. Am besten dann auch gleich noch den Prozessor selber bauen, denn wer weiß, welche Hardware-Bugs der so mitbringt?
> Dann musst du aber auch so konsequent sein und den Compiler auch selber > schreiben, denn der erzeugt auch Code, der Fehler haben könnte oder mit > deiner Software nicht harmonieren könnte. Das musst du nicht. Schliesslich hast du dem Compilerhersteller schon xxxxxEuro gegeben damit er garantiert das sein Compiler solche Probleme nicht hat. Und wenn du doch mal eines feststellt dann behebt er das auch. Schau mal hier: https://www.iar.com/iar-embedded-workbench/certified-tools-for-functional-safety/certified-tools-faq/ Olaf
Nicht vergessen die Lizenzbedingungen für den Fremdcode prüfen und einhalten. Das kann eine Rechtsabteilung schon gut Beschäftigen und den Anhang zur Dokumentation recht lang machen. Wenn man Pech hat steht dirn das man den Eigene Code dann auch open Source machen muss.
0815 schrieb: > was ist besser. Die fertige Bibliothek(wo halt die elementaren Sachen > drin stehen, also die Stdio.h) Was willst du mit stdio.h auf einem Mikrocontroller? Da hast du erstmal fopen, fclose und andere File-Funktionen, die nur dann greifen, wenn du auch ein Betriebssystem mit drauf hast. Ein gleiches gilt für die Einzelzeichen wie fgetc, fputc und Konsorten. Hast du dazu denn überhaupt eine Art Stream-Verwaltung auf deinem µC? Vermutlich nicht. Dann hast du printf und scanf - und die entweder voll aufgeblasen oder eingekürzt, aber trotzdem Speicherfresser - auch durch die vielen Formatstrings. Also, der ganze Krempel ist OK für das Programmieren von PC-Programmen, aber auf einem Mikrocontroller sieht da Ganze recht deplaziert aus. Mach dir lieber dein Zeugs selbst und passe es an die Verhältnisse auf dem µC an. W.S.
Rolf M. schrieb: > Als Bastler kann man sich (so man will) die Zeit > nehmen, alles selber zu basteln, aber wer das professionell macht, kann > sich das gar nicht leisten. Da muss man sich drauf konzentrieren, die > eigentliche Funktionalität einzubauen und nicht den 10.000sten Aufguss > der Standardbibliothek. Das klingt mir aber nicht nach einem fähigen Programmierer, sondern nach einem, der nicht weiß, wie man die einfachsten Dinge schreibt - oder nach einem, der sich ganz einfach davor scheut. Also genau so wie die vielen Möchtegerns, die fleißig ihre ST-InitStruct's befüllen, um zu vermeiden, ein Hardwarebit, was sie setzen wollen, SELBST zu setzen. Und dabei geht jede Performance zu Boden - und einfacher oder übersichtlicher oder zuverlässiger wird's dadurch auch bloß nicht. W.S.
W.S. schrieb: > Rolf M. schrieb: >> Als Bastler kann man sich (so man will) die Zeit >> nehmen, alles selber zu basteln, aber wer das professionell macht, kann >> sich das gar nicht leisten. Da muss man sich drauf konzentrieren, die >> eigentliche Funktionalität einzubauen und nicht den 10.000sten Aufguss >> der Standardbibliothek. Eben! > Das klingt mir aber nicht nach einem fähigen Programmierer, sondern nach > einem, der nicht weiß, wie man die einfachsten Dinge schreibt - oder > nach einem, der sich ganz einfach davor scheut. Jaja, erfinde dein Rad immer wieder neu und fühl dich als Held! > Also genau so wie die > vielen Möchtegerns, die fleißig ihre ST-InitStruct's befüllen, um zu > vermeiden, ein Hardwarebit, was sie setzen wollen, SELBST zu setzen. Und > dabei geht jede Performance zu Boden - und einfacher oder > übersichtlicher oder zuverlässiger wird's dadurch auch bloß nicht. Davon redet keiner. Aber niemand schreibt eine Lib für USB, FAT, TCP/IP etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!
Ich hab zu Anfang auch vieles selber geschrieben. Mit zunehmender Programmiererfahrung lernt man aber die Bibliotheken zu schätzen. Die wurden nämlich von Profis geschrieben, d.h. es ist schwer, das gleiche Niveau zu erreichen. Es gibt natürlich im Internet auch viele Bibliotheken zum Download, die von Anfängern geschrieben wurden. Die kann man bestenfalls als Idee benutzen, um es dann richtig zu machen. Man muß immer im Hinterkopf behalten, daß absolut jeder etwas im Internet veröffentlichen darf. Auch bei Programmbeispielen von den MC-Herstellern (Michrochip, NXP, ST, TI usw.) muß man immer daran denken, daß es nur Beispiele sind, also weit entfernt von einer ausgereiften Bibliothek.
Der TE bleibt ja leider sehr vage darin, welche Bibliothek er meint wenn er schreibt: 0815 schrieb: > Bibliothek(wo halt die elementaren Sachen drin stehen, also die Stdio.h) Vermutlich meint er damit die libc. Und die kommt im Zweifelsfall mit der Toolchain (vulgo: dem C-Compiler). Deren Hersteller für gewöhnlich nicht der Hersteller des µC ist. Insofern ist die Frage: 0815 schrieb: > vom Hersteller verwenden oder selber schreiben? auch nicht so richtig präzise zu beantworten. Dazu kommt noch, daß gerade stdio.h auf embedded Systemen eine relativ geringe Relevanz hat, weil die meisten der Funktionen daraus auf embedded Systemen nicht verfügbar sind. Die libc an sich wird hingegen durchaus gebraucht. Z.B. für Strings. Oder gar nur für die Definitionen der Datentypen aus stdint.h. Die Antwort ist, daß man bevorzugt die Bibliotheksfunktionen verwenden sollte. Wer glaubt, der Toolchain-Hersteller sei zu inkompetent für eine korrekte Implementierung der libc, der sollte zunächst mal die Frage beantworten, warum er ihm dann im Gegenzug die Kompetenz für die Implementierung des Compilers zugesteht. In Einzelfällen kann es sinnvoll sein, die Funktionalität (oder auch nur Teile davon) von Bibliotheksfunktionen selber zu implementieren. Ein klassisches Beispiel ist eine Funktion zur formatierten Ausgabe von Zahlen analog printf() - aber nur mit dem Umfang, der tatsächlich gebraucht wird. Denn printf() braucht typisch viel Code (weil es umgekehrt auch sehr mächtig ist). Wenn man nun bspw. gar keine Unterstützung für Fließkomma braucht, kann man Speicher sparen indem man eine abgespeckte Variante selber baut. Aber wie gesagt, das sind Einzelfälle.
Mal zur Erinnerung: "Der Heartbleed-Bug ist ein schwerwiegender Programmfehler in älteren Versionen der Open-Source-Bibliothek OpenSSL, durch den über verschlüsselte TLS-Verbindungen private Daten von Clients und Servern ausgelesen werden können. ... Ein großer Teil der Online-Dienste, darunter auch namhafte Websites wie auch VoIP-Telefone, Router und Netzwerkdrucker waren dadurch für Angriffe anfällig " Das eine Bibliothek von extern erstellt wurde und weltweit verbreitet ist, ist kein Qualitätsmerkmal. Eine xterne Bibliothek muss genauso kritische behandelt werden wie selbst erstellter Code. Zumal der Heartbleed-Bug kein besonders "komplizierter" Bug ist sondern auf simple Faulheit grundlegende Programmierregel, wie die Überprüfung von pointern anzuwenden, rückführbar ist. Und der Heartbleedprogrammer war kein frühreifes Computerkid sondern ein Promotionsstudent an der Fakultät Informatik einer Hochschule der am Thema „Strategien zur Sicherung von End-zu-End-Kommunikation" arbeitete....
Axel Zucker schrieb: > Mal zur Erinnerung: Und wer seine eigene Krypto-Bibliothek schreibt, ohne wirklich *richtig viel* Ahnung davon zu haben, im Detail, gehört standesrechtlich erschossen. Ende. Die libc kommt von der Toolchain und ist damit mindestens so vertrauenswürdig wie die Toolchain selbst (allerdings ist es auch in Ordnung, sich auf ein Subset zu beschränken). Für alle anderen Bibliotheken muss man abwägen. Bei uns in der Firma sind GPLv3 und LGPLv3 strikt verboten (wenn solcher Code drin wäre, dürften wir unsere Geräte nicht verkaufen). Alle anderen Open Source-Lizenzen sind grundsätzlich erlaubt.
Ich benutze keine Autos. Die meisten Fabrikanten haben zwar bald ein Jahrhundert an Erfahrung und tausende von Ingenieuren die sich tagtäglich 8h mit nichts anderem als ihrem Schwerpunkt beschäftigen... Aber ich weiß trotzdem einfach alles besser.
Axel Zucker schrieb: > Mal zur Erinnerung: Jeder der schon einmal ernsthaft programmiert hat weiß dass keine Software 100% fehlerfrei ist. Zu glauben so etwas kompliziertes wie OpenSSL selbst zu schreiben und dann noch besser zu sein ist in meinen Augen größenwahnsinnig oder ignorant. Denn das schreiben der Bibliothek und der eigenen Applikation ist die kleine Aufgabe, wenn man 100% Fehlerabdeckung haben möchte. Für einen vernünftigen Test, braucht es um einiges mehr Aufwand als der eigentliche Code und zusätzlich viel Verständnis über übliche Verfahren/Lücken in der Softwareentwicklung. Zusätzlich muss man in der erwähnten Software auch noch nebenbei ein Experte in Kryptographie sein. Kein Problem, macht man kurz in der Kaffeepause.
Ein sehr schönes Beispiel für die Fehleinschätzung der eigenen mathematischen Fähigkeiten ist Detlef Granzow mit seiner Vollbitverschlüsselung. Achtung, Augenkrebsgefahr: https://web.archive.org/web/20140517202802/http://kryptochef.net/
:
Bearbeitet durch User
Andreas S. schrieb: > Ein sehr schönes Beispiel für die Fehleinschätzung der eigenen > mathematischen Fähigkeiten ist Detlef Granzow mit seiner > Vollbitverschlüsselung. > > Achtung, Augenkrebsgefahr: > https://web.archive.org/web/20140517202802/http://kryptochef.net/ Oder es ist einfach Satire ala DMHO.org. Oder Bauernfängerei ala Atomstromfilter, audiophile Technik etc.
Bevor ich ne Lib selbst schreibe schaue ich erstmal was es gibt und ob es meinen Anforderungen genügt. Das ist eigentlich sehr häufig der Fall. Ich sehe ehrlich gesagt gar kein Problem damit, fremde Libs zu nutzen. Das wertvollste, dass ich habe, ist Zeit und eine Lib selbst zu schreiben frisst Zeit. Das habe ich an meiner Lib für die SSD1306/SH1106 Displays gesehen.
Falk B. schrieb: > Oder es ist einfach Satire ala DMHO.org. Oder Bauernfängerei ala > Atomstromfilter, audiophile Technik etc. Nein, das meinte der Typ wohl ziemlich ernst. Es gab ja nicht nur seine Webseite, sondern er war auch ansonsten missionarisch unterwegs. Das ganze verursachte damals in verschiedenen Medien (auch uC...) ziemlich hohe Wellen.
N. M. schrieb: > Axel Zucker schrieb: >> Mal zur Erinnerung: > > Jeder der schon einmal ernsthaft programmiert hat weiß dass keine > Software 100% fehlerfrei ist. Ja, auch ich hege den Verdacht das der TO noch nie ernsthaft programmiert hat, sonst würde er wissen das es sowas wie eine "fertige bibliothek" wie im Threadtitel dummfresch behauptet nicht gibt. > Zu glauben so etwas kompliziertes wie OpenSSL selbst zu schreiben und > dann noch besser zu sein ist in meinen Augen größenwahnsinnig oder > ignorant. Genauso wie die Annahme eine Bibliothek "von draussen" wäre irgendwie fertig und man könne sie einsetzen und vergessen ohne sich um Updates etc. zu kümmern. Und da wären noch die Alternativen zu OpenSSL: https://www.netzwelt.de/alternative-zu/6937-openssl.html Oder man ist so ehrlich und gesteht ein, das es sowas wie eine sichere Übertragung nicht gibt und findet ne Möglichkeit ohne Übertragung senitiver Informationen auszukommen. Und eben nur die Funktionen zu implementieren und anzubieten die man selbst beherrscht um gegebenfalls dem kunden bei der fehlersuche behilflich sein zu können.
Falk B. schrieb: > Aber niemand schreibt eine Lib für USB Nicht immer von sich auf andere schließen.
Bernd K. schrieb: > Nicht immer von sich auf andere schließen. Nicht immer sinnentstellend zitieren.
Frank M. schrieb: > Bernd K. schrieb: >> Nicht immer von sich auf andere schließen. > > Nicht immer sinnentstellend zitieren. Genau! Voller heist es: "Aber niemand schreibt eine Lib für USB, FAT, TCP/IP etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!" Und dem ist zu widersprechen, es kann schon sinnvoll sein eine lib selber zu schreiben, insbesonders wenn man nur ein schmales subset an Funktionen braucht und nicht die HW-resourcen hat den der volle Funktiumsumfang erfordert. beispielsweise statt volles Fat einen single file reader. Oder als kompromiss eine fremde lib aufs brauchbare runterkürzen, was IMHO auch eine Art "selber schreiben" ist auch wenn der überweigende Teil der Arbeit dabei aus Lesen und Wegschmeissen besteht.
Das ist doch sicher ein Thread zum ködern von Trolls oder? Manche schreiben ja sinnige Antworten. Also abgespeckte Libs schreiben die nur einen Teil der Funktion haben ist doch durchaus sinnvoll wenn es für einen reicht. Außerdem gibt es in der Informatik mehr Themen als man überhaupt lernen kann. Wie soll die Menschheit überhaupt weiter kommen, wenn jeder von Vorn anfängt.
Axel Zucker schrieb: > insbesonders wenn man nur ein schmales subset an > Funktionen braucht und nicht die HW-resourcen hat Zum Beispiel den MKL26 der mit 32kB Flash und USB Peripherie verkauft wird. Der vom Hersteller mitgelieferte Codegenerator (weil simplen Beispielcode mitzuliefern mit dem man zur Abwechslung mal was anfangen könnte ist ja neuerdings aus der Mode gekommen) spuckt für dieses Target einen Bloatbrocken von 35kB aus wenn man ein leeres Hello-World USB-HID Projekt haben will. Und wenn man auf Kompilieren drückt sagt einem der Linker daß das 35k Code logischerweise nicht in 32k Flash passen. Ein selber geschriebener USB-Treiber mit HID Endpoint braucht nur etwa 2500 Byte. Wenn man das nicht machen würde könnte man diese Peripherie in diesem Controller in der Form wie er von NXP verkauft wird überhaupt nicht nutzen, die ganze Existenz dieses Dings wäre vollkommen sinnlos!
:
Bearbeitet durch User
Solche Bilbliotheken wie stdio etc., also die libc, kommen in der Regel vom Compiler den du benutzt. Der kann vom Hersteller des Chips kommen, muss aber nicht. Eine Implementierung, die für embedded Systeme sehr beliebt ist, ist die newlib (https://sourceware.org/newlib/). Diese kommt zum Beispiel mit dem arm-none-eabi-gcc. Du kannst dir den Code mal anschauen. Sicher ist auf jeden Fall, dass man das nicht mal eben so schnell runtercodet. Wenn du in einer sicherheitskritischen Ecke arbeitest -- Bahntechnik wäre jetzt ein Beispiel dafür -- dann musst du je nach "Sicherheitsstufe" teilweise auch speziell zertifizierte Compiler und Libraries verwenden. Teilweise sind die dann noch viel schlechter, als alles, was du auf github bekommst. Sind aber halt zugelassen... Gerade im Embedded-Bereich ist es häufig üblich, auf die libc, sprich stdio.h etc. zu verzichten, da diese einen erheblichen Rattenschwanz mit sich bringt. Werden trotzdem Funktionen wie printf() etc. benötigt, implementiert man in einem solchen Fall eine eigene, teils abgespeckte, Variante à la my_printf(). Viele Betriebssysteme für embedded (RTOS, etc...) bringe auch teils ihre eigenen Standardfunktionen mit. Inklusive einer unendlichen Flut von Typedefs. Wenn du n Libraries in deinem Projekt hast, dann hast du schätzungsweise e^n typedefs für einen 32 bit unsigned integer... Hier greift jetzt natürlich wieder das, was vorhin schon gesagt wurde: Coding Style. Wenn du eine Library verwendest, nutzt diese nach Murphy natürlich nie den Coding Style, den du nutzt. Ansich kann man damit leben, dass der Style in verschieden Files anders ist. Aber das aufrufen von Funktionen der Library in deinem Programm führt dann aufgrund des anderen coding Styles zu einem unglaublich widerlichen Mischmasch. Egal welchen Coding Style man bevorzugt: Mischen sollte man auf keinen Fall. Das kann keiner mehr lesen. Der Linux Kernel, als Beispiel, bietet intern auch Funktionen wie malloc, free etc. an. Diese sind allerdings in einer eigenen Variante (kmalloc, kfree, ...) selbst implementiert. Zum einen aus dem Grund, dass diese Funktionen teils noch weitere Parameter fressen, als die Standardfunktionen. Zum anderen sorgt das aber auch dafür, dass der Code in sich komplett ist und keine Abhängigkeit zu einer weiteren Library besteht. Als Nurtzerapplikation auf PC ist eine eigene Implementierung meist nicht sinnvoll. Außer man braucht eben auch hier eine spezielle Zertifizierung, aus welchem Grund auch immer.
M. H. schrieb: > Wenn du in einer sicherheitskritischen Ecke arbeitest -- Bahntechnik > wäre jetzt ein Beispiel dafür -- dann musst du je nach > "Sicherheitsstufe" teilweise auch speziell zertifizierte Compiler und > Libraries verwenden. Teilweise sind die dann noch viel schlechter, als > alles, was du auf github bekommst. Sind aber halt zugelassen... Ja, das ist teilweise ziemlich bitter. Auch bei Halbleitern gibt es solch einen Mist. Aus einem Projekt kenne ich einen Mikroprozessor, der Unmengen an Fehlern aufweist. Kaum ein Peripherieblock funktioniert einwandfrei. Auf massiven Druck meines damaligen Kunden meinte der Hersteller, genau diese Maskenversion sei für einige sicherheitskritische Anwendungen zertifiziert und dürfe deswegen nicht mehr angefasst werden. Dieser Kunde setzte sowohl die Standardversion als auch eine Sonderausführung mit angepasstem On-Chip-Bootloader ein, wobei ich aber nicht weiß, ob selbiger während der Chipfertigung per OTP oder über eine eigene Maske eingebracht wurde.
0815 schrieb: > Die fertige Bibliothek(wo halt die elementaren Sachen > drin stehen, also die Stdio.h) für den Mikrocontroller vom Hersteller > verwenden oder selber schreiben? Am besten ist es mangels eigener Fab einen Prozessor mit ladbarem Mikrocode zu nehmen und diesen von scratch neu zu schreiben. Da hast du dann die Möglichkeit alle Fehler die seit der Entwicklung des ersten Prozessors gemacht wurden zu wiederholen und noch ein paar neue hinzuzufügen. Wenn du damit nächste Woche durch bist kommt das 0815 C dran, die paar Millionen Zeilen Code in den libs und deren Reifung machst du dann nebenbei ;-).
HyperMario schrieb: > Am besten ist es mangels eigener Fab einen Prozessor mit ladbarem > Mikrocode zu nehmen und diesen von scratch neu zu schreiben. Absoluter Schwachsinn. Wir leben doch nicht mehr im Mittelalter. Er soll einen FPGA nehmen.
Bernd K. schrieb: > Und wenn man auf Kompilieren drückt sagt einem der > Linker daß das 35k Code logischerweise nicht in 32k Flash passen Und der Compiler/Linker schmeißt nicht benötigte Funktionen nicht raus? Gute Libraries sollten so strukturiert/modularisiert sein, dass Funktionalität, die nie aufgerufen wird, beim kompilieren verschwindet. Alternativ macht man es manuell, wie bei lwIP, wo man über eine Menge Makros genau definieren kann, was man haben möchte.
Niklas G. schrieb: > Und der Compiler/Linker schmeißt nicht benötigte Funktionen nicht raus? Bei -O0 vermutlich nicht. :p
Niklas G. schrieb: > Und der Compiler/Linker schmeißt nicht benötigte Funktionen nicht raus? Lib-Funktionen werden erst dann eingebunden, wenn man sie auch aufruft, z.B. printf(). Wenn man allerdings keine vorcompilierte Lib erzeugt, sondern Quelltext einbindet, dann belegt der auch Speicherplatz, wenn er nicht aufgerufen wird.
Olaf schrieb: > Alles was zu Kunden rausgeht muss zu 100% selbst geschrieben sein. Das war mal. Heutzutage setzt sich die Erkenntnis durch, dass man das Rad nicht immer und immer wieder neu erfinden muss. Das kostet nur Zeit und Geld. STM beispielsweise hat CubeMX und die dazugehörigen HAL-Bibliotheken nicht für den Bastler im stillen Kämmerlein geschaffen sondern zur Anwendung im professionellen Umfeld. Wenn bei uns ein Entwickler eingestellt wird ist es ein wichtiges Kriterium ob er mit den aktuellen Bibliotheken umgehen kann. Alles selbst machen gibts bei uns schon lange nicht mehr.
Peter D. schrieb: > Wenn man allerdings keine vorcompilierte Lib erzeugt, sondern Quelltext > einbindet, dann belegt der auch Speicherplatz, wenn er nicht aufgerufen > wird. Aber nur wenn man die Compiler/Linker-Optionen zum Löschen ungenutzten Codes explizit aus den Projekteinstellungen entfernt, wo die meisten Projekt-Erzeugungs-Wizwards/Tools sie schon automatisch eintragen.
:
Bearbeitet durch User
M. H. schrieb: > Wenn du in einer sicherheitskritischen Ecke arbeitest -- Bahntechnik > wäre jetzt ein Beispiel dafür -- dann musst du je nach > "Sicherheitsstufe" teilweise auch speziell zertifizierte Compiler und > Libraries verwenden. Teilweise sind die dann noch viel schlechter, als > alles, was du auf github bekommst. Sind aber halt zugelassen... Das hat dann wieder versichungstechnische Aspekte: Wenns abbrennt, dann halt zumindest Normgerecht und wenn man nix aus der Norm genommen hat wirds teuer und die Versicherungen freuen sich...auch wenns besser war, was man genommen hat.
Niklas G. schrieb: > Und der Compiler/Linker schmeißt nicht benötigte Funktionen nicht raus? > Gute Libraries sollten so strukturiert/modularisiert sein, dass > Funktionalität, die nie aufgerufen wird, beim kompilieren verschwindet. Ja. Und der Linker schmeißt alles raus was er rausschmeißen kann. Und wenn danach immer noch auf der höchsten Optimierungsstufe und mit allen diesbezüglichen Flags die mir bzgl. Codegröße einfallen immer noch 35kB Code ausspuckt dann wirkt die Aussicht darauf jetzt Wochen damit verbringen zu dürfen in dem 35kB Misthaufen von generierten Codeabfällen herumzustochern um zu sehen warum das passiert und zu versuchen die 3kB eigentliche Funktionalität zu finden, zu verstehen, zu isolieren und herauszuoperieren ohne sie kaputt zu machen weitaus weniger motivierend als die Aufgabe sich hinzusetzen und die selben zwei Wochen darin zu investieren das Gewünschte sauber und from scratch selbst zu implementieren, das hat auch den Vorteil daß man es hinterher zu 100% verstanden hat und auch sein API so gestalten kann wie es einem angenehm ist und gut mit dem restlichen Code harmoniert. Ich habe in dem konkreten Fall keine 5 Minuten gebraucht um den Entschluss zu fassen daß ich keinesfalls in dem lieblos generierten stinkenden Codemisthaufen herumstochern will um das irgendwie notdürftig zum Laufen zu bringen. Ich will sauberen eleganten Code. Ich bin vorwiegend auf den kleinstmöglichen Controllern unterwegs mit denen sich eine gegebene Aufgabe überhaupt noch lösen lässt, Kreativität und Hirnschmalz ist dort manchmal das einzige was eine Aufgabe überhaupt noch lösbar macht, andernfalls gäbs überhaupt keinen Grund es überhaupt zu versuchen weil nicht ansatzweise Konkurrenzfähig. Das ist also das exakte Gegenteil von "wir schmeißen einfach mehr und teurere Hardware drauf weil die Legosteine aus denen wir bauen alle so groß und unförmig sind" das in anderen Bereichen getrieben wird wo es nicht so eng zugeht.
M. K. schrieb: > wenn man nix aus der Norm genommen hat > wirds teuer und die Versicherungen freuen sich Ich finde Schlimm, dass du damit Recht hast. Jura geht über fachliche Vernunft, weil unsere Gesetze und Gerichte von Juristen gemacht sind. Ebenso stehen die Bedürfnisse der Reichen über denen der Armen, weil unser Land von reichen regiert wird.
Stefanus F. schrieb: > Ich finde Schlimm, dass du damit Recht hast. Jura geht über fachliche > Vernunft, weil unsere Gesetze und Gerichte von Juristen gemacht sind. Und solche Leute verstehen dann auch nicht, dass man die Kirchhoffschen oder Maxwellschen Gesetze nicht einfach per Gesetzgebungsverfahren ändern kann.
Stefanus F. schrieb: > M. K. schrieb: >> wenn man nix aus der Norm genommen hat >> wirds teuer und die Versicherungen freuen sich > > Ich finde Schlimm, dass du damit Recht hast. Jura geht über fachliche > Vernunft, weil unsere Gesetze und Gerichte von Juristen gemacht sind. Wer sollte sie sonst machen? Wurstfachverkäufer? > Ebenso stehen die Bedürfnisse der Reichen über denen der Armen, weil > unser Land von reichen regiert wird. Welche Land wird erfolgreich von Armen regiert? Nordkorea? Reichtum ist eine Manifestation von Macht.
Bernd K. schrieb: > herauszuoperieren ohne sie kaputt zu machen weitaus weniger motivierend > als die Aufgabe sich hinzusetzen und die selben zwei Wochen darin zu > investieren das Gewünschte sauber und from scratch selbst zu > implementieren, das hat auch den Vorteil daß man es hinterher zu 100% > verstanden hat und auch sein API so gestalten kann wie es einem angenehm > ist und gut mit dem restlichen Code harmoniert. Das mag in einigen und auch diesem Fall so sein, allgemeingültig ist es nicht. Wenn man ein Problem lösen will, dann schaut man IMMER erstmal, ob es fertige Lösungen oder Zutaten dazu gibt. Erst wenn es keine gibt oder deren Qualität zu schlecht ist, baut man selber was. Das gilt nicht nur für Software und Ingenieursarbeit sondern so ziemlich alle Lebensbereiche. > Ich habe in dem konkreten Fall keine 5 Minuten gebraucht um den > Entschluss zu fassen daß ich keinesfalls in dem lieblos generierten > stinkenden Codemisthaufen herumstochern will um das irgendwie notdürftig > zum Laufen zu bringen. Klingt verständlich. > Ich will sauberen eleganten Code. Der kann dir bei Bibliotheken und anderen Black Boxes egal sein. > Ich bin > vorwiegend auf den kleinstmöglichen Controllern unterwegs mit denen sich > eine gegebene Aufgabe überhaupt noch lösen lässt, Kreativität und > Hirnschmalz ist dort manchmal das einzige was eine Aufgabe überhaupt > noch lösbar macht, Mag sein, ist aber auch nicht allgemeingültig. Schau dir an, mit was für Overkill und fetter Hardware heute teilweise rumgeworfen wird. Und warum? Weil Speicher und CPU Power verdammt billig geworden sind. > andernfalls gäbs überhaupt keinen Grund es überhaupt > zu versuchen weil nicht ansatzweise Konkurrenzfähig. Baust du so preissensitives Zeug im Massenmarkt? > Das ist also das > exakte Gegenteil von "wir schmeißen einfach mehr und teurere Hardware > drauf weil die Legosteine aus denen wir bauen alle so groß und unförmig > sind" das in anderen Bereichen getrieben wird wo es nicht so eng zugeht. ;-)
Bernd K. schrieb: > Ich bin > vorwiegend auf den kleinstmöglichen Controllern unterwegs mit denen sich > eine gegebene Aufgabe überhaupt noch lösen lässt, Kreativität und > Hirnschmalz ist dort manchmal das einzige was eine Aufgabe überhaupt > noch lösbar macht, andernfalls gäbs überhaupt keinen Grund es überhaupt > zu versuchen weil nicht ansatzweise Konkurrenzfähig. Das ist ein schöner Ansatz, den ich praktisch genauso vertrete. Und das schon seit ich überhaupt programmiere. Die Demoszene auf dem C64 hat mich wohl geprägt :) Das Problem nennst du aber selber im letzten Halbsatz: so ein Ansatz ist im professionellen Umfeld nur seltenst durchzuziehen, weil nicht konkurrenzfähig. Entwicklerzeit ist nun mal so viel teurer als Silizium, daß jeder Betriebswirtschaftler auf teuren Chip und billigen Entwickler setzen wird, statt anders herum. Es gibt wenige Ausnahmen, etwa wenn ein Markt mit zig Millionen Stückzahl sicher ist. Aber wie gesagt: Ausnahme.
Falk B. schrieb: > Aber niemand schreibt eine Lib für USB,.. Ähem.. doch. Ich zum Beispiel. Ist zwar nicht für alle möglichen USB-Verwendungen, sondern nur für VCP, aber dafür ist sie klein und handlich und eine bessere HAL als alles, was ich von den diversen Herstellern bislang gesehen habe. Offenbar bin ich da nicht der Einzige: Bernd K. schrieb: > Ich habe in dem konkreten Fall keine 5 Minuten gebraucht um den > Entschluss zu fassen daß ich keinesfalls in dem lieblos generierten > stinkenden Codemisthaufen herumstochern will.. Eben, geht mir ähnlich. Anstatt mit Krampf irgendwelche "Standard"-Funktionen zu benutzen und diversen Code drumherum zu stricken, bloß um sie an das vorliegende Umfeld anzupassen oder sich mit aufgeblähtem fehlerträchtigen Code herumzuplagen, ist es oftmals besser, sich seinen Kram selber zu machen. Auch wenn Leute, die zu wenig draufhaben, mit der ewigen Ausrede-Leier kommen, daß sie das Rad ja nicht nochmal erfinden wollen. W.S.
Wenn man beruflich ständig mit Gigabytes und Gigahertz nur so um sich wirft, verliert man manchmal den Blick fürs Detail. Meine Hobby-Experimente mit ganz kleinen Mikrocontrollern hatten einen wesentlichen Anteil daran, dass ich inzwischen immer dann gerufen werde, wenn es Probleme mit Performance und/oder Speicher in Java Anwendungen gibt. Die Spielereien mit kleinen Mikrocontrollern haben also auch was Gutes. Ich vergleiche das gerne mit einem Tischler oder Zimmermann, der zuhause Krippenfiguren schnitzt. Das Große und das Kleine ergänzen sich zu einem vernünftigen Gesamtbild, sowohl physisch als auch im Kopf.
W.S. schrieb: > Falk B. schrieb: >> Aber niemand schreibt eine Lib für USB,.. > > Ähem.. doch. > > Ich zum Beispiel. Ist zwar nicht für alle möglichen USB-Verwendungen, > sondern nur für VCP, aber dafür ist sie klein und handlich und eine > bessere HAL als alles, was ich von den diversen Herstellern bislang > gesehen habe. Offenbar bin ich da nicht der Einzige: Du solltest vollständig zitieren! "Davon redet keiner. Aber niemand schreibt eine Lib für USB, FAT, TCP/IP etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!" Die Betonung liegt auf "einfach mal so". Daß man selber sowas machen kann und das in einigen Fällen auch sinnvoll ist, hat keiner bestritten. Wohl aber die Aussage, daß man immer alles selber machen sollte oder muss. > Eben, geht mir ähnlich. Anstatt mit Krampf irgendwelche > "Standard"-Funktionen zu benutzen und diversen Code drumherum zu > stricken, bloß um sie an das vorliegende Umfeld anzupassen oder sich mit > aufgeblähtem fehlerträchtigen Code herumzuplagen, ist es oftmals > besser, sich seinen Kram selber zu machen. Eben das ist so NICHT allgemeingültig! Denn es sind mal sicher nicht alle bestehenden Bibliotheken und Frameworks dermaßen schlecht!
Falk B. schrieb: > "Davon redet keiner. Aber niemand schreibt eine Lib für USB, FAT, TCP/IP > etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!" Viele Leute tun Dinge auch einfach mal so. Eiffelturm aus Streichhölzern bauen, Einen Kurzwellentransceiver entwerfen und zusammenlöten zur rein persönlichen Erbauung, Hubschrauber fliegen lernen, ein Schachprogramm schreiben, einen Treiber für USB oder FAT oder TCP/IP, einen Betriebssystem-Kernel schreiben weil man seinem ehemaligen Inf-Professor das Gegenteil von irgendwas beweisen will, alles weder möglich noch sinnvoll? Ich glaube nicht. Die Geschichte ist voll davon. Und Github ist voll von Software die irgendwer einfach mal so geschrieben hat, entweder aus Jux und Tollerei oder weil er dachte er kann irgendwas besser lösen als die dutzend Alternativen für den selben Zweck und einige davon sind am Ende wirklich besser.
Bernd K. schrieb: > Die Geschichte ist voll davon. Ja, sieht man zum Beispiel an Linux :-) Vielfalt und Ausprobieren sind die Grundlagen für Innovation. Muss ja nicht jedes Mal ein Erfolg sein.
:
Bearbeitet durch User
Bernd K. schrieb: > Falk B. schrieb: >> "Davon redet keiner. Aber niemand schreibt eine Lib für USB, FAT, TCP/IP >> etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!" > > Viele Leute tun Dinge auch einfach mal so. Eiffelturm aus Streichhölzern > bauen, Einen Kurzwellentransceiver entwerfen und zusammenlöten zur rein > persönlichen Erbauung, Hubschrauber fliegen lernen, ein Schachprogramm > schreiben, einen Treiber für USB oder FAT oder TCP/IP, einen Ja, aus Spaß an der Freud. Da kann man fast alles machen. Im produktiven, professionellem Umfeld aber nicht. > Betriebssystem-Kernel schreiben weil man seinem ehemaligen Inf-Professor > das Gegenteil von irgendwas beweisen will, alles weder möglich noch > sinnvoll? Ich glaube nicht. Die Geschichte ist voll davon. Und Github > ist voll von Software die irgendwer einfach mal so geschrieben hat, > entweder aus Jux und Tollerei oder weil er dachte er kann irgendwas > besser lösen als die dutzend Alternativen für den selben Zweck und > einige davon sind am Ende wirklich besser. Eben, EINIGE!
W.S. schrieb: > Falk B. schrieb: >> Aber niemand schreibt eine Lib für USB,.. > > Ähem.. doch. Und schon kommt der nächste, der sinnentstellend zitiert. Aber Falk hat ja eben schon alle Nötige dazu gesagt. Bernd K. schrieb: > Falk B. schrieb: >> "Davon redet keiner. Aber niemand schreibt eine Lib für USB, FAT, TCP/IP >> etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!" > > Viele Leute tun Dinge auch einfach mal so. Eiffelturm aus Streichhölzern > bauen, Einen Kurzwellentransceiver entwerfen und zusammenlöten zur rein > persönlichen Erbauung ... Oder auf einen Berg steigen. Einfach weil er da ist. Ja. <gähn> Das ist kein Widerspruch. Aber eine USB-Lib, gar auf einem F103 schreibt man eher nicht zum Spaß. Genauso wie man zwar vielleicht aus Spaß auf einen Berg steigt, aber nicht auf eine Müllkippe. Und der Vergleich drängt sich förmlich auf.
Axel S. schrieb: > Das ist kein Widerspruch. Aber eine USB-Lib, gar auf einem F103 schreibt > man eher nicht zum Spaß. Genauso wie man zwar vielleicht aus Spaß auf > einen Berg steigt, aber nicht auf eine Müllkippe. Und der Vergleich > drängt sich förmlich auf. Weil USB unter den diversen Protokollen ein eher sauberes, genau spezifiertes, und gar nicht so unübersichtliches ist? Schnittstellen wie die von SD-Karten, WLAN(-Modulen), aber auch solche im Web-Bereich sind da oft viel schlimmer. Die USB-Peripherie vom F103 ist noch ganz erträglich und logisch aufgebaut. Nur die Adressierung ist etwas schräg. Nur weil man keine 587 YouTube-Videos und "Für Dummies"-Bücher zu findet muss man sich davon nicht abschrecken lassen. Daher: W.S. schrieb: > Ich zum Beispiel. Und ich auch: USB-Tutorial mit STM32 Die USB-Library von ST ist wirklich nicht so der Bringer (Bugs, ineffizient). Interessant wäre ein Vergleich mit kommerziellen USB-Stacks.
:
Bearbeitet durch User
W.S. schrieb: > > Auch wenn Leute, die zu wenig draufhaben, mit der ewigen Ausrede-Leier > kommen, daß sie das Rad ja nicht nochmal erfinden wollen. > > W.S. So viel Arroganz lässt sich doch sicher noch steigern ? Gruß, Michael
> Die USB-Peripherie vom F103 ist noch ganz erträglich und > logisch aufgebaut. Nur die Adressierung ist etwas schräg. Auf mich macht sie eher den Eindruck als ob jemand von ST a) bestehende Hardwarefragmente aus alten µC möglichst schnell und billig zusammen frickeln musste um sagen zu können "jetzt können wir auch USB", oder b) zu viel Betäubungsmittel eingenommen hat
Niklas G. schrieb: > Axel S. schrieb: >> ... eine USB-Lib, gar auf einem F103 schreibt >> man eher nicht zum Spaß. Genauso wie man zwar vielleicht aus Spaß auf >> einen Berg steigt, aber nicht auf eine Müllkippe. Und der Vergleich >> drängt sich förmlich auf. > > Die USB-Peripherie vom F103 ist noch ganz > erträglich und logisch aufgebaut. Nur die Adressierung ist etwas schräg. Findest du? > ... ich auch: USB-Tutorial mit STM32 Ja. Eben daher habe ich den Eindruck, daß man den USB low-level Kram auf dem F103 besser delegiert. Außer man ist masochistisch veranlagt.
Stefanus F. schrieb: > a) bestehende Hardwarefragmente aus alten µC möglichst schnell und > billig zusammen frickeln musste um sagen zu können "jetzt können wir > auch USB", Ja, die STM32 und viele ähnliche Controller sind nach dem Baukastenprinzip aufgebaut. Axel S. schrieb: > Findest du? Kennst du einen Controller mit besserer USB-Peripherie? Die "OTG"-Peripherie der größeren STM32 ist noch viel schlimmer.
Niklas G. schrieb: > Kennst du einen Controller mit besserer USB-Peripherie? Die > "OTG"-Peripherie der größeren STM32 ist noch viel schlimmer. Umso dankbarer bin ich für deine Anleitung, die Klarheit verschafft.
M. H. schrieb: > Gerade im Embedded-Bereich ist es häufig üblich, auf die libc, sprich > stdio.h etc. zu verzichten, da diese einen erheblichen Rattenschwanz mit > sich bringt. Das ist so allgemein ziemlich immer falsch. Erstens besteht die libc aus wesentlich mehr als nur stdio.h. Zweitens steht es dem gcc immer (und nicht abschaltbar!) frei, Aufrufe zu mem{cpy,cmp,move,set} zu generieren, und die sind Teil der libc. Man wird sich im Embedded-Bereich allerdings so ziemlich immer auf ein Subset der vollen libc beschränken. Da kann printf drin sein, muss es aber nicht. In meinem Fall ist es das immer (außer in reinen Assembler-Projekten), weil ich den Nutzen deutlich höher einschätze als die (Einmal-)Kosten. Meine Meinung: Man sollte alles einmal selbst gemacht haben (egal ob USB, FAT oder printf), dann aber fertige Bibliotheken (falls existent) nutzen. Warum? Weil man erst dann die Qualität dieser Bibliotheken und die eigentliche Komplexität des Problems halbwegs sinnvoll einschätzen kann.
S. R. schrieb: > Meine Meinung: Man sollte alles einmal selbst gemacht haben (egal ob > USB, FAT oder printf), dann aber fertige Bibliotheken (falls existent) > nutzen. Warum? Weil man erst dann die Qualität dieser Bibliotheken und > die eigentliche Komplexität des Problems halbwegs sinnvoll einschätzen > kann. Find ich nicht. IMO muss man nicht alles selbst einmal gemacht haben. Es ist aber sicher nicht verkehrt auch mal in eine Bibliothek rein zu schaun was da drin alles gemacht wird.
Falk B. schrieb: > Stefanus F. schrieb: >> M. K. schrieb: >>> wenn man nix aus der Norm genommen hat >>> wirds teuer und die Versicherungen freuen sich >> >> Ich finde Schlimm, dass du damit Recht hast. Jura geht über fachliche >> Vernunft, weil unsere Gesetze und Gerichte von Juristen gemacht sind. > > Wer sollte sie sonst machen? Wurstfachverkäufer? Nicht nur Leute, die von Jura Ahnung haben, sondern auch Leute, die das Thema, das gesetzlich geregelt werden soll, wenigstens einigermaßen verstehen. Falk B. schrieb: >> Ich bin >> vorwiegend auf den kleinstmöglichen Controllern unterwegs mit denen sich >> eine gegebene Aufgabe überhaupt noch lösen lässt, Kreativität und >> Hirnschmalz ist dort manchmal das einzige was eine Aufgabe überhaupt >> noch lösbar macht, > > Mag sein, ist aber auch nicht allgemeingültig. Schau dir an, mit was für > Overkill und fetter Hardware heute teilweise rumgeworfen wird. Und > warum? Weil Speicher und CPU Power verdammt billig geworden sind. Es kommt eben auch immer darauf an, was man macht. Wenn man zuhause als Hobyybastler Spaß daran hat, aus möglichst keinen µCs möglichst viel rauszuholen, ist das ja ok. Oder wenn man Geräte entwickelt, die nachher in sehr großen Stückzahlen gebaut werden und jeder Cent in der Produktion eingespart werden soll, auch wenn das vielleicht 100.000 € an zusätzlichen Entwicklungskosten bedeutet. Wenn man dagegen kundenspezifische Einzellösungen baut, ist es praktisch immer viel billiger, den nächstgrößeren Boliden zu kaufen als durch selber schreiben irgendwelcher Libs das Programm zu optimieren. Bernd K. schrieb: > Falk B. schrieb: >> "Davon redet keiner. Aber niemand schreibt eine Lib für USB, FAT, TCP/IP >> etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!" > > Viele Leute tun Dinge auch einfach mal so. Ich würde "einfach mal so" hier weniger als "nur so zum Spaß" verstehen, sondern eher in der Art "so kurz mal nebenher". S. R. schrieb: > Erstens besteht die libc aus wesentlich mehr als nur stdio.h. > Zweitens steht es dem gcc immer (und nicht abschaltbar!) frei, Aufrufe > zu mem{cpy,cmp,move,set} zu generieren, und die sind Teil der libc. Meist wird's aber eher umgekehrt sein, dass gcc einen memcpy-Aufruf selber intern umsetzt, statt die libc-Funktion tatsächlich aufzurufen. > Man wird sich im Embedded-Bereich allerdings so ziemlich immer auf ein > Subset der vollen libc beschränken. Da kann printf drin sein, muss es > aber nicht. In meinem Fall ist es das immer (außer in reinen > Assembler-Projekten), weil ich den Nutzen deutlich höher einschätze als > die (Einmal-)Kosten. Wenn man genug Flash dafür übrig hat, warum auch nicht? Da gilt der bekannte Satz: Man bekommt vom Hersteller kein Geld zurück für nicht benutzten Speicher. Es macht wenig Sinn, krampfhaft auf solche Funktionen zu verzichten und dann nachher noch 75% des Flashs ungenutzt zu lassen.
Wer hier das Wort "Overkill" verwendet, möge bitte mal die Anzahl der Glühlampen und Leuchtdioden (insbesondere bei Lichterketten) in seinem Haushalt zählen. Und dann fragen wir mal einen imaginären Vertreter aus dem 18. Jahrhundert, ob er elektrisches Licht in dieser Ausbaustufe für angemessen hält.
Rolf M. schrieb: > Es macht wenig Sinn, krampfhaft auf solche Funktionen > zu verzichten und dann nachher noch 75% des Flashs ungenutzt > zu lassen. Nun bleibt dann noch die Frage der Updates offen. Wer viel Zeug hat, muß sich um viel Zeug kümmern! Mein größte eierlegende Wollmilchsau wollte dann täglich frische Updates, was zu echten Plage wurde.
Rolf M. schrieb: >>> Ich finde Schlimm, dass du damit Recht hast. Jura geht über fachliche >>> Vernunft, weil unsere Gesetze und Gerichte von Juristen gemacht sind. >> >> Wer sollte sie sonst machen? Wurstfachverkäufer? > > Nicht nur Leute, die von Jura Ahnung haben, sondern auch Leute, die das > Thema, das gesetzlich geregelt werden soll, wenigstens einigermaßen > verstehen. Es gibt Fachjuristen. >> Mag sein, ist aber auch nicht allgemeingültig. Schau dir an, mit was für >> Overkill und fetter Hardware heute teilweise rumgeworfen wird. Und >> warum? Weil Speicher und CPU Power verdammt billig geworden sind. > > Es kommt eben auch immer darauf an, was man macht. Sicher. > Wenn man zuhause als > Hobyybastler Spaß daran hat, aus möglichst keinen µCs möglichst viel > rauszuholen, ist das ja ok. Oder wenn man Geräte entwickelt, die nachher > in sehr großen Stückzahlen gebaut werden und jeder Cent in der > Produktion eingespart werden soll, auch wenn das vielleicht 100.000 € an > zusätzlichen Entwicklungskosten bedeutet. Ja, aber auch da muss man schon GENAU hinschauen und RECHNEN! Einen break even point aka Gewinnschwelle kann man schon mal schnell abschätzen. Machen nur die Allerwenigsten! https://de.wikipedia.org/wiki/Gewinnschwelle Viele Entwickler haben allerdings eine unprofessionelle Bastlermentalität und sind verliebt in ihre Spielzeuge ala Compiler, Frameworks, CAD-Tools, ICs whatever. Da werden keine nüchternen, rationalen, WIRTSCHAFTLICHEN Designentscheidungen getroffen sondern nach Herzenslust drauflosgebastelt um ein möglichst episches Kunstwerk zu schaffen. Menschlich verständlich aber unprofessionell und TEUER! > Wenn man dagegen > kundenspezifische Einzellösungen baut, ist es praktisch immer viel > billiger, den nächstgrößeren Boliden zu kaufen als durch selber > schreiben irgendwelcher Libs das Programm zu optimieren. Das hat mit kundenspezifisch wenig zu tun sondern was mit Stückzahlen. Wenn ich 100.000 Euro Entwicklungskosten habe, die meist zum größten Teil Personalkosten (=Zeit) sind, ist es halt ein Unterschied ob ich die auf 10 oder 10.000 verkaufte Produkte umlegen kann! Time is Money ist kein leeres Geschwätz sondern Realität. > Ich würde "einfach mal so" hier weniger als "nur so zum Spaß" verstehen, > sondern eher in der Art "so kurz mal nebenher". Genau so war das gemeint.
Tägliche updates auf einem Mikrocontroller? Das würde ich nicht einmal mit einem Raspberry Pi machen.
Rolf M. schrieb: > [...] printf [...] > Es macht wenig Sinn, krampfhaft auf solche > Funktionen zu verzichten und dann nachher noch 75% des Flashs ungenutzt > zu lassen. In den meisten Mikrocontrollerprojekten hat man überhaupt keine Verwendung für printf oder Konsorten, dann muss man auch nicht krampfhaft darauf verzichten und das Geld für den gesparten Flash bekommt man zurück indem man den nächstkleineren bestellt und es gar nicht erst bezahlt. Und ein USB-Stack kostet auch keine 100000€ sondern nur einen einzigen engagierten Mitarbeiter der für die Sache lebt und quasi das Hobby zum Beruf gemacht hat und/oder am Gewinn beteiligt oder anderweitig an Gedeih oder Verderb der Firma gebunden ist, so jemand zieht den besagten USB-Stack an ein paar verregneten Sonntagen zuhause durch wenn er gut ist, solche Leute gibts, die Skala für Skill-Level und Leidenschaft ist nach oben offen, das können sich zwangsstudierte nine-to-five-Ingenieure bei denen der letzten Tropfen Motivation schon vor 15 Jahren endgültig ausgesaugt wurde oder gar nie vorhanden war oftmals überhaupt nicht vorstellen.
:
Bearbeitet durch User
Bernd K. schrieb: > Und ein USB-Stack kostet auch keine 100000€ sondern nur einen > engagierten Mitarbeiter der für die Sache lebt und quasi das Hobby zum > Beruf gemacht hat Also ein Nerd und Fachidiot, der sich billig ausbeuten läßt. > und/oder am Gewinn beteiligt oder anderweitig an > Gedeih oder Verderb der Firma gebunden ist, so jemand zieht den besagten > USB-Stack an ein paar verregneten Sonntagen zuhause durch wenn er gut > ist, Jaja, der Supermann. Es mag sein, daß es solche Leute gibt, vielleicht auch mehr als man denkt. Professionell ist das trotzdem nicht. Vor allem weil bei so einem Hackaton der Test und die Validierung arg zu kurz kommen, wie fast immer bei Software 8-0 > solche Leute gibts, die Skala für Skill-Level und Leidenschaft ist > nach oben offen, das können sich zwangsstudierte nine-to-five-Ingenieure > bei denen der letzten Tropfen Motivation schon vor 15 Jahren endgültig > endgültig ausgesaugt wurde oder gar nie vorhanden war oftmals überhaupt > nicht vorstellen. Doch, kann ich, auch wenn ich eher zur ersteren Gruppe gehöre. Vor vielen Jahren hab ich sowas im kleinen Rahmen auch mal gemacht, ist aber Geschichte. Dienst ist Dienst und Schnapps ist Schnapps! Adolf Hennecke ist lange tot und das ist gut so! https://de.wikipedia.org/wiki/Adolf_Hennecke
Falk B. schrieb: > Jaja, der Supermann. Es mag sein, daß es solche Leute gibt, Irgendwann fällt er mal aus, und dann packen alle ein und machen den Laden zu, oder wie soll das ablaufen?
Stefanus F. schrieb: > Falk B. schrieb: >> Jaja, der Supermann. Es mag sein, daß es solche Leute gibt, > > Irgendwann fällt er mal aus, und dann packen alle ein und machen den > Laden zu, oder wie soll das ablaufen? Der Code den er zu Lebzeiten der Firma gespendet hat wird sich durch seinen Weggang sicherlich nicht in Luft auflösen. Die können dann halt nur in Zukunft keine neuen Innovationen mehr machen und müssen davon leben was sie haben, ungefähr so wie Apple.
:
Bearbeitet durch User
Bernd K. schrieb: > Und ein USB-Stack kostet auch keine 100000€ sondern nur einen einzigen > engagierten Mitarbeiter der für die Sache lebt und quasi das Hobby zum > Beruf gemacht hat Puh, das ist brandgefährlich für eine Firma. In der Regel halten solche "Einzelkämpfer" nichts von Dokumentation, Styleguide und Unit testing. D.h. wenn er die Firma verläßt, kann man alles wegschmeißen und neu beginnen. Daher ist es deutlich effizienter, eine Lib zu kaufen, die auch für längere Zeit supportet wird.
Während wir hier über Libraries diskutieren, sind die erfolgreichsten Firmen dieses Landes schon viel weiter. Sie setzen zum Beispiel eine Blockchain für die Funkschlüssel ihrer Autos ein. Die Idiocracy ist mehr als ein lustiger Fil.
Bernd K. schrieb: > Der Code den er zu Lebzeiten der Firma gespendet hat wird sich durch > seinen Weggang sicherlich nicht in Luft auflösen. Code, der nicht wartbar ist, landet unweigerlich in dev/null. Man schmeißt schlechtem Geld nicht auch noch gutes Geld hinterher.
Peter D. schrieb: > Code, der nicht wartbar ist, landet unweigerlich in dev/null. Es könnte auch wartbarer Code sein. Daß der Code nichts gekostet hat sagt nichts über dessen Qualität aus. Wenn derjenige fähig war (was ich voraussetzte) hat er exzellenten und vorbildlichen Code geschrieben.
Bernd K. schrieb: > Stefanus F. schrieb: >> Falk B. schrieb: >>> Jaja, der Supermann. Es mag sein, daß es solche Leute gibt, >> >> Irgendwann fällt er mal aus, und dann packen alle ein und machen den >> Laden zu, oder wie soll das ablaufen? > > Der Code den er zu Lebzeiten der Firma gespendet hat wird sich durch > seinen Weggang sicherlich nicht in Luft auflösen. Ein verbreiteter Irrtum. Code ist wie Fingernägel. Oder Haare. Eine Weile geht es ohne Pflege. Aber nicht auf Dauer.
Stefanus F. schrieb: > Während wir hier über Libraries diskutieren, sind die > erfolgreichsten Firmen dieses Landes schon viel weiter. > > Sie setzen zum Beispiel eine Blockchain für die Funkschlüssel ihrer > Autos ein. Die Idiocracy ist mehr als ein lustiger Fil. "Film" sollte das wohl heißen. Aber Blockchain dürfte sicherer sein als keyless go. Das hat gerade wieder für viele traurige Überraschungen gesorgt.
Das wartbarkeitsproblem kenne ich auch reichlich. Sobald frisches Blut kommt werden alte Quellen verworfen und alles neu gemacht, mit anderen Ansätzen und neueren Technologien. Und neuen Fehlern und neuen Problemen.
Peter D. schrieb: > Puh, das ist brandgefährlich für eine Firma. Nun, wenn es nur die Wahl gibt das Produkt genau so zu machen weil durch eine glückliche Fügung des Schicksals die Nuß geknackt wurde und die einzige Alternative lautet es bleiben zu lassen und jemand anderem beim Erfolg zuzusehen weil man es mit gekauften Legosteinen niemals hätte bauen können, weil Standard-Ings von der Stange nicht kompetent genug oder zu langsam und damit zu teuer wären dann ist das nun mal so.
Axel S. schrieb: > Ein verbreiteter Irrtum. Code ist wie Fingernägel. Oder Haare. Eine > Weile geht es ohne Pflege. Aber nicht auf Dauer. Dann pflegt man ihn halt weiter, wo ist das Problem?
Bernd K. schrieb: > Wenn derjenige fähig war (was ich > voraussetzte) hat er exzellenten und vorbildlichen Code geschrieben. Bernd K. schrieb: > Die können dann halt nur in Zukunft keine neuen Innovationen mehr machen Das widerspricht sich aber. Guter Code kann sehr wohl von anderen weiter entwickelt werden und ich hab das auch mal erfolgreich machen können. Erst dabei merkt man, ob ein in sich schlüssiger Ablaufplan dahinter steckt oder ob es nur hingerotztes Copy&Paste ist.
Michael A. schrieb: > W.S. schrieb: >> >> Auch wenn Leute, die zu wenig draufhaben, mit der ewigen Ausrede-Leier >> kommen, daß sie das Rad ja nicht nochmal erfinden wollen. > So viel Arroganz lässt sich doch sicher noch steigern ? ??? Wo W.S. Recht hat hat er Recht, in 99,99% der Fälle ist "Ich will das Rad nicht neu erfunden" eine Ausrede für (Denk-)Faulheit und Uninspirierte Technikeinstellung. Sollte in Entwicklungsabteilung die oben mitspielen wollen ein Abmahngrund sein. Schliesslich wurde die Person genau für den Zweck eingestellt, ein rad zu erfinden das besser ist als die der mitbewerber und perfekt zum Produkt passt. Ein Porsche fährt eben nicht auf Rädern die ein Neandertaler in der Steinzeit aus einer Mammutrippe schnitzte...
Axel Zucker schrieb: > Wo W.S. Recht hat hat er Recht, in 99,99% der Fälle ist "Ich will das > Rad nicht neu erfunden" eine Ausrede für (Denk-)Faulheit und > Uninspirierte Technikeinstellung. Warst du nicht der Lustige der OpenSSL als negativ Beispiel gebracht hat? Ich hoffe du arbeitest in der Buchhaltung oder im Verkauf...
Axel Zucker schrieb: > Ein Porsche fährt eben nicht auf Rädern die ein Neandertaler in der > Steinzeit aus einer Mammutrippe schnitzte... Und zwar deshalb nicht, weil der Ingenieur auf dem aktuellen Wissensstand aufsetzte, als er die Räder für den Porsche entwickelt hat. Und deshalb widersprichst Du Dir hier selbst. Hätte der Ingenieur ganz von vorne anfangen müssen (wie W.S. es will), würde der Porsche höchstens auf Kutschenrädern fahren. Es kann durchaus von Vorteil sein, auf guten Entwicklungen aufzusetzen und diese weiterzuentwickeln. Genau das macht die Evolution auch. Wenn sie es nicht täte, wären wir noch alle dumme Amöben.
:
Bearbeitet durch Moderator
Vincent H. schrieb: > Axel Zucker schrieb: >> Wo W.S. Recht hat hat er Recht, in 99,99% der Fälle ist "Ich will das >> Rad nicht neu erfunden" eine Ausrede für (Denk-)Faulheit und >> Uninspirierte Technikeinstellung. > > Warst du nicht der Lustige der OpenSSL als negativ Beispiel gebracht > hat? Ich hoffe du arbeitest in der Buchhaltung oder im Verkauf... Na lies mal nach, wofür ich OpenSSL als beispiel genannt habe, kleiner Tipp der Heartbleed-Bug ist keiner der entstand weil das Thema so kompliziert war, sondern weil einer keine Lust hatte bei seiner Arbeit nachzudenken und primitivstes Handwerkszeug ignorierte. Und dann kommst du vielleicht drauf das ich nicht mit Entwicklungsfernen Themen zu tun habe sondern schon so meine Jahrzehnte "Front"-Erfahrung mitbringe.
Peter D. schrieb: > Bernd K. schrieb: >> Wenn derjenige fähig war (was ich >> voraussetzte) hat er exzellenten und vorbildlichen Code geschrieben. > > Bernd K. schrieb: >> Die können dann halt nur in Zukunft keine neuen Innovationen mehr machen > > Das widerspricht sich aber. Nein, damit meinte ich wenn die guten Leute weg sind können sie zwar noch auf dieser Welle weiter reiten und das Produkt und Variationen davon noch jahrelang weiter bauen, sobald aber die Konkurrenz aufgeholt hat und wieder eine ganz neue Idee, ein neuer vergleichbarer Stunt nötig wäre um wieder was unmöglich geglaubtes aus dem Ärmel zu schütteln wäre dann Ende.
Axel Zucker schrieb: > Wo W.S. Recht hat hat er Recht, in 99,99% der Fälle ist "Ich will das > Rad nicht neu erfunden" eine Ausrede für (Denk-)Faulheit und > Uninspirierte Technikeinstellung. Oft genug ist Software und ein µC/PC nur Mittel zum Zweck. Da sitzen E-Techniker, Physiker oder gar Maschinenbauer die auch noch die SW erstellen sollen. Da nimmt man eben was brauchbar aussieht und schnell geht... PS: sollte keine Beleidiung der genannten Berufe sein. Ich kenne auch einen Zahnarzt der schreibt bessere SW als manche Informatiker.
Frank M. schrieb: > Axel Zucker schrieb: >> Ein Porsche fährt eben nicht auf Rädern die ein Neandertaler in der >> Steinzeit aus einer Mammutrippe schnitzte... > > Und zwar deshalb nicht, weil der Ingenieur auf dem aktuellen > Wissensstand aufsetzte, als er die Räder für den Porsche entwickelt hat. Wobei nicht davon auszugehen ist, das der aktuelle Wissenstand zwingend in einer externen Bibliothek zu finden ist. PS: Nichts für Ungut, aber "Auf den aktuellen Wissenstand aufsetzen" ist auch so ne Hohlphrase die man bringt wenn man keinen Bock auf Eigenes Nachdenken hat.
Axel Zucker schrieb: > Nichts für Ungut, aber "Auf den aktuellen Wissenstand aufsetzen" ist > auch so ne Hohlphrase die man bringt wenn man keinen Bock auf Eigenes > Nachdenken hat. Sei froh, dass Deine Eltern das anders gesehen haben, als sie Dir das Sprechen beibrachten. ;-) Trotzdem hast Du Dich bis heute aus eigener Kraft weiterentwickeln können. P.S. Du hast mich sinnenstellend zitiert. Ich schrieb "Auf den aktuellen Wissenstand aufsetzen und diese weiterzuentwickeln "
:
Bearbeitet durch Moderator
Axel Zucker schrieb: > Na lies mal nach, wofür ich OpenSSL als beispiel genannt habe, kleiner > Tipp der Heartbleed-Bug ist keiner der entstand weil das Thema so > kompliziert war, sondern weil einer keine Lust hatte bei seiner Arbeit > nachzudenken und primitivstes Handwerkszeug ignorierte. Bitte erleuchte mich. Welches primitive Handwerkszeug soll das sein? Wer ernsthaft behauptet in C/C++ noch nie einen Range-basierten Bug produziert zu haben der hat Potential in die Politik zu gehn. Dort sucht man immer nach Lügnern.
Vincent H. schrieb: > Axel Zucker schrieb: >> Na lies mal nach, wofür ich OpenSSL als beispiel genannt habe, kleiner >> Tipp der Heartbleed-Bug ist keiner der entstand weil das Thema so >> kompliziert war, sondern weil einer keine Lust hatte bei seiner Arbeit >> nachzudenken und primitivstes Handwerkszeug ignorierte. > > Bitte erleuchte mich. Welches primitive Handwerkszeug soll das sein? Folge dem Link: https://motherboard.vice.com/de/article/kb754w/deutscher-hat-heartbleed-fehler-an-silvester-vor-zwei-jahren-programmiert Ansonsten dürfte es doch einem Entwickler ein Leichtes sein, das entsprechende diff aus dem repo zu holen oder den für ihn verständlichsten Kommentar aus dem Internet zu ziehen.
Frank M. schrieb: > Axel Zucker schrieb: >> Nichts für Ungut, aber "Auf den aktuellen Wissenstand aufsetzen" ist >> auch so ne Hohlphrase die man bringt wenn man keinen Bock auf Eigenes >> Nachdenken hat. > > Sei froh, dass Deine Eltern das anders gesehen haben, als sie Dir das > Sprechen beibrachten. ;-) > > Trotzdem hast Du Dich bis heute aus eigener Kraft weiterentwickeln > können. Sorry, ich verstehe nicht was du sagen willst ??? Das Problem an der Phrase ist: "aufsetzen". Das klingt als ob das auch der ungelernte Möbelschubser kann. Gemeint ist aber das man den "Aktuellen Wissensstand" mindestens verstanden haben muß um ihn sinnvoll anwenden zu können. Und manches versteht man eben am besten, wenn man es (im Ansatz/in Teilen) selber macht. - "Learning by doing" eben. Sonst endet es wieder mal bei wenig hilfreichen: "ich weiss auch nicht wo der fehler liegt aber lass uns mal auf das nächste Update warten ..."
Axel S. schrieb: >> Der Code den er zu Lebzeiten der Firma gespendet hat wird sich durch >> seinen Weggang sicherlich nicht in Luft auflösen. > > Ein verbreiteter Irrtum. Code ist wie Fingernägel. Oder Haare. Eine > Weile geht es ohne Pflege. Aber nicht auf Dauer. Interessanter Vergleich!
Frank M. schrieb: > P.S. > Du hast mich sinnenstellend zitiert. Ich schrieb "Auf den aktuellen > Wissenstand aufsetzen und diese weiterzuentwickeln " Doch, ich habe Dich exakt zitiert: "Und zwar deshalb nicht, weil der Ingenieur auf dem aktuellen Wissensstand aufsetzte, als er die Räder für den Porsche entwickelt hat." Die untere Zitierfähige Stelle zum Wissenstand habe ich überlesen - die klingt für mich aber auch mehr in Richtung Denkvermeidung statt Auseinanderstzung/Hinterfragung.
netzwelt.de, vice Was kommt als nächstes? bild.de? Den "Artikel" hab ich jetzt trotz heftigem Brechreiz gelesen. Meine Frage bleibt allerdings unbeantwortet stehn. Nach wie vor scheinst nur du den heiligen Gral gefunden zu haben mit dem man Buffer-Overflows und Konsorten Herr wird.
Axel Zucker schrieb: > Sorry, ich verstehe nicht was du sagen willst ??? Okay, dann mal ganz langsam: 1. Man kann auf einer Entwicklung aufsetzen. Beispiel: Der Porsche-Räder-Entwickler schaut sich den aktuellen Wissenstand der Autoindustrie an. 2. Man adaptiert diesen Wissensstand (bzw. diese Bibliothek) Beispiel: Der Porsche-Räder-Entwickler berechnet die Geometrie, das Fahrverhalten (und was noch alles) des Porsche und passt den aktuellen Wissensstand, was Räder betrifft, an. Bis hierher hat man nur dumpf abgekupfert und ein wenig angepasst. Jetzt kommt aber der entscheidende Schritt, den Du nicht einfach bisher nicht nachvollziehst: 3. Man verbessert das Produkt anhand dieser Adaption und gibt diese weiter. Beispiel: Der Porsche-Räder-Entwickler verbessert anhand von Versuchen bzw. Computerberechnungen sein Porsche-Rad und veröffentlicht diese neuen Erkenntnisse. Wenn Du Dir Schritt 3. verinnerlichst, magst Du mir nun zustimmen, dass man "auf dem aktuellen Wissensstand aufsetzen" nicht pauschal verteufeln darf! Ganz im Gegenteil: Man spart eine Menge Entwicklungszeit und kann das eigene Produkt wesentlich effizienter weiterentwickeln. Diesen letzten Schritt magst Du vielleicht einem schnöden Bibliotheksanwender absprechen, aber deshalb sind die Schritte 1 und 2 trotzdem auch für einen Entwickler nicht falsch. Jetzt verstanden? Deine Eltern haben Dir etwas auf den Weg gegeben, nämlich "Sprache", die Dir ermöglicht hat, Dich weiterzuentwickeln. Hätten sie das nicht getan, wärest Du vielleicht heute erst dabei, das Lesen zu lernen.
:
Bearbeitet durch Moderator
Vincent H. schrieb: > netzwelt.de, vice > > Was kommt als nächstes? bild.de? > > Den "Artikel" hab ich jetzt trotz heftigem Brechreiz gelesen. Meine > Frage bleibt allerdings unbeantwortet stehn. Nach wie vor scheinst nur > du den heiligen Gral gefunden zu haben mit dem man Buffer-Overflows und > Konsorten Herr wird. Mit Verlaub, ich mach nicht den Dompteur in deinem Affentheater. Folge einfach den Links und du kommst auf die beschreibung: "In one of the new features, unfortunately, I missed validating a variable containing a length." Dr Seggelmann said the error he introduced was "quite trivial", but acknowledged that its impact was "severe"." Und meiner Erfahrung nach lernt man bereits als Informatikschulbub das man die Länge von variablen überprüft um buffer overruns zu vermeiden. Also bsplw. strnlen() statt strlen zu verwenden, wenn überhaupt.
Axel Zucker schrieb: > Nichts für Ungut, aber "Auf den aktuellen Wissenstand aufsetzen" ist > auch so ne Hohlphrase die man bringt wenn man keinen Bock auf Eigenes > Nachdenken hat. Nö, das ist der Grund, warum wir heute dort stehen wo wir stehen, weil eben nicht jeder erst das Rad neu erfinden muss, ebenso wir wir das Ohmsche Gesetz nicht erst neu entdecken müssen, das ist alles schon da.
Axel Zucker schrieb: > Nichts für Ungut, aber "Auf den aktuellen Wissenstand aufsetzen" ist > auch so ne Hohlphrase die man bringt wenn man keinen Bock auf Eigenes > Nachdenken hat. Nö, das ist der Grund, warum wir heute dort stehen wo wir stehen, weil eben nicht jeder erst das Rad neu erfinden muss, ebenso wir wir das Ohmsche Gesetz nicht erst neu entdecken müssen, das ist alles schon da. Axel Zucker schrieb: > Das Problem an der Phrase ist: "aufsetzen". > Das klingt als ob das auch der ungelernte Möbelschubser kann. Ich glaube, das verstehst nur du so... Aber ja, um einen Prozessor zu verwenden, muss ich tatsächlich nicht verstehen, wie er auf Transistorebene funktioniert.
Frank M. schrieb: > 2. Man adaptiert diesen Wissensstand (bzw. diese Bibliothek) > > Beispiel: Der Porsche-Räder-Entwickler berechnet die Geometrie, das > Fahrverhalten (und was noch alles) des Porsche und passt den aktuellen > Wissensstand, was Räder betrifft, an. > > Bis hierher hat man nur dumpf abgekupfert und ein wenig angepasst. > > Jetzt kommt aber der entscheidende Schritt, den Du nicht einfach bisher > nicht nachvollziehst: > > 3. Man verbessert das Produkt anhand dieser Adaption und gibt diese > weiter. Das was du hier als "Schritt" darstellst ist IMHO nur ein rhetorischer Kniff um das Auditorium zu blenden. Ich sehe nicht wie aus einer "Abkupferei" eine "Adaption" wird, in dem man "Schritt" dazusagt. Adaption bedeutet Umbau, und um etwas unzubauen muss man es zerlegen, und um etwas zerlegen zu konnen muss man verstanden haben wie es funktioniert - auf beiden seiten - der eigenen -Porsche- und der anderen -Knochenrad-. Klar kann man auch das Knochenrad mit einer Kohlefasermanchete an den Porsche klatschen um dann in der Validierungsphase draufzukommen, das es so nicht geht Iund das man mit ein bißchen nachdenken das vorher hätte draufkommen können das Knochen den Porsche nicht trägt.
Axel Zucker schrieb: > Und meiner Erfahrung nach lernt man bereits als Informatikschulbub das > man die Länge von variablen überprüft um buffer overruns zu vermeiden. > Also bsplw. strnlen() statt strlen zu verwenden, wenn überhaupt. Und meiner Erfahrung nach sind arrogante Entwickler die, die den schlimmsten Code hinrotzen. Glücklicherweise sind eben jene Entwickler recht leicht zu identifizieren, sie schmeißen nämlich recht gern mit kurzen Phrasen umsich. "Ich hab einen Bug in deinem Code gefunden." "Ich brauch keine Unit Tests." "Ich mach keine Logik Fehler." "Das ist ein Hardware Fehler der noch nicht im Errata steht."
Axel Zucker schrieb: > Das was du hier als "Schritt" darstellst ist IMHO nur ein rhetorischer > Kniff um das Auditorium zu blenden. Ich sehe nicht wie aus einer > "Abkupferei" eine "Adaption" wird, in dem man "Schritt" dazusagt. Sagen wir besser: Du willst es nicht sehen. Oder Du hältst pauschal alle Anwender einer Bibliothek für Idioten. Beides spricht nicht für Dich, egal wie Du es drehst.
Frank M. schrieb: > Beides spricht nicht für Dich, egal wie Du es drehst. Danke, gleichfalls und End of Communication.
Es ist doch ganz einfach: Wenn keine Library existiert die alle Anforderungen erfüllt dann muss man selber eine schreiben oder eine existierende so umbauen/abspecken/aufbohren daß sie es tut. Jeder hat andere Anforderungen, manche haben auch ganz spezielle Anforderungen und manchmal gibts einfach nichts von der Stange. Die gängige deutsche Ingenieursmeinung hier im Forum scheint zu sein stattdessen die Anforderungen so lange runterzuschrauben bis die Herren Entwickler sich nicht mehr anstrengen müssen. Das ist natürlich auch ein Weg den man gehen kann. Andere denken halt anders darüber.
:
Bearbeitet durch User
Bernd K. schrieb: > Die gängige deutsche Ingenieursmeinung hier im Forum scheint zu sein > stattdessen die Anforderungen so lange runterzuschrauben bis die Herren > Entwickler sich nicht mehr anstrengen müssen. Oder man spart sich die Prüfung der Anforderung komplett, deklariert eine beliebige Bibliothek pauschal als "fertig" und versichert sich der Unterstützung aus einem Forum durch einen herbeigekasperten Thread .... PS: Allerdings bin ich nicht der Meinung, das dies "gängige deutsche Ingenieursmeinung" wäre, da ich ansonsten Nationalität und Bildungsweg verleugnen müsste ;-)
Das Genie ist nicht der, der unnützt Zeit damit verschwendet, bereits vorhanden Grundfunktionen nachzuprogrammieren und damit zusätzliche Fehlerquellen einzubauen. Sondern das Genie ist der, der möglichst effizient unter Einsatz der Bibliotheken die eigentliche Aufgabe löst, d.h. innovativ ist. Dann kann man sich voll auf das Problem konzentrieren und ist nicht mit irgendwelchem Urschleim abgelenkt. Ich weiß, wie ich printf verwende, daher muß ich keine Zeit damit vergeuden, eigene Ausgabefunktionen zu schreiben. Wer unbedingt mag, der kann ja Grundfunktionen in seiner Freizeit nachprogrammieren und testen, da muß man dann nicht effizient sein.
Hi Das ist das schöne, an solchen Grabenkriegen.... Solange man den Kontext nicht klärt, schaut jeder aus sich selber heraus auf die Anderen. Damit kommt man dann zu tausend widersprechenden Aussagen, die dann alle (mehr oder weniger) wahr sind. Natürlich macht es Sinn, in der Lernphase, Standard Routinen selber zu schreiben. Ebenso macht es Sinn, wenn die vorhandenen Dinge nicht ausreichen, was neues zu bauen. Und ebenso viel Sinn macht es, sich aus dem Library Baukasten zu bedienen, wenn man schnell fertig werden muss/will. Natürlich spielen dann auch noch die Firmen Richtlinien, und irgendwelche notwendigen Zertifizierungen, eine tragende/richtungsweisende Rolle.
Michael A. schrieb: > W.S. schrieb: >> >> Auch wenn Leute, die zu wenig draufhaben, mit der ewigen Ausrede-Leier >> kommen, daß sie das Rad ja nicht nochmal erfinden wollen. >> >> W.S. > > So viel Arroganz lässt sich doch sicher noch steigern ? > > Gruß, > Michael Du verwechselst da etwas. Ich erinnere mal wieder an Adenauer und dessen Spruch vom Horizont. Arroganz ist, wenn jemand nix drauf hat und dennoch so tut, als hätte er was drauf und die anderen nicht. Aber ich habe das drauf, deswegen ist das eben keine Arroganz. Es wird nur von Leuten gern verwendet, denen nach Stänkern zumute ist. So, ich denke, dieses Teilthema wäre damit final geklärt. Zum Kernthema hier: Die Ansichten einiger hier, daß man auf biegen&brechen bei irgendwelchen Standard-Bibliotheken bleiben soll, deutet mir auf eben eine zu kleine entwicklerische Potenz hin. Ebenso die falsche Aussage, daß es für ungenutzten Flash kein Geld zurück gäbe. Das Geld kommt nämlich vom nächstkleineren Chip. Richtig ist hingegen, daß man schlichtweg Augenmaß haben sollte, was man benutzt und was nicht. Leider ist eben auch richtig, daß Leute, deren Fertigkeiten sich auf copy&paste beschränken, gar keine andere Wahl haben - es sei denn, sie setzen sich auf ihren Hosenboden und lernen dazu (sofern sie können und nicht zu faul sind). Das ist hier vermutlich der tiefere Grund all der gehabten Diskussion. W.S.
W.S. schrieb: > Das Geld kommt nämlich vom > nächstkleineren Chip. In der Regel sind aber nicht die Libs der Hauptverbraucher an Flash. Beim AVR belegt printf ~1kB (ohne float-support). Wenn ich also ein 20kB Programm habe und nun mühsam das printf rausoperiere, dann komme ich vielleicht auf 19,5kB runter, das reicht aber nicht für den nächst kleineren Chip. Der Hauptverbraucher an Flash ist in der Regel eine unüberlegte und planlose Programmierung mit riesigen Copy&Paste Sequenzen. Mit einem durchdachten Programmablaufplan, bevor man überhaupt Code schreibt, kommt man dagegen oft auf 50% Einsparung.
@W.S. schrieb: > Arroganz ist, wenn jemand nix drauf hat und dennoch so tut, als hätte er > was drauf und die anderen nicht. Der geht anders. Ein hohes Niveau sieht nur von unten wie Arroganz aus. ;-) > Die Ansichten einiger hier, daß man auf biegen&brechen bei irgendwelchen > Standard-Bibliotheken bleiben soll, deutet mir auf eben eine zu kleine > entwicklerische Potenz hin. Du solltest an deinem Textverständnis arbeiten. Das hat so kein Einziger weder formuliert noch gemeint. > Richtig ist hingegen, daß man schlichtweg Augenmaß haben sollte, was man > benutzt und was nicht. Ach ne?
W.S. schrieb: > Ebenso die falsche Aussage, daß es für > ungenutzten Flash kein Geld zurück gäbe. Das Geld kommt nämlich vom > nächstkleineren Chip. Wer nur auf Kante näht, kann bald alles wegwerfen (wenn der Platz für Änderungen nicht mehr reicht). Bisher ist mir noch kein Programm aufgefallen, was kleiner geworden ist. Es bestand eher der Wunsch, dem Kunden noch eine "Verbesserung" zu verkaufen.
0815 schrieb: > Hi, > > was ist besser. Die fertige Bibliothek(wo halt die elementaren Sachen > drin stehen, also die Stdio.h) für den Mikrocontroller vom Hersteller > verwenden oder selber schreiben? Was ist gängig in der Industrie? Warum oder? Ich kenne das so, dass beides verwendet wird. Da, wo es schon eine fertige und gut funktionierende Bibliothek für etwas gibt (z.B. gmp, libcurl, ...) sollte man das Rad nicht neu erfinden. Freilich erstellen Firmen auch eigene Bibliotheken. Ist ja nicht so, dass es für jede Branche und für jedes Produkt schon alle Libs vorgefertigt gäbe, die man so brauchen kann.
:
Bearbeitet durch User
Falk B. schrieb: > Rolf M. schrieb: >>>> Ich finde Schlimm, dass du damit Recht hast. Jura geht über fachliche >>>> Vernunft, weil unsere Gesetze und Gerichte von Juristen gemacht sind. >>> >>> Wer sollte sie sonst machen? Wurstfachverkäufer? >> >> Nicht nur Leute, die von Jura Ahnung haben, sondern auch Leute, die das >> Thema, das gesetzlich geregelt werden soll, wenigstens einigermaßen >> verstehen. > > Es gibt Fachjuristen. Ja, die müssen dann aber beim Beschließen eines Gesetzes auch anwesend sein, und nicht erst nachher, um zu versuchen, in das eigentlich unsinnige Gesetz irgendwas brauchbares reinzuinterpretieren. >> Wenn man dagegen >> kundenspezifische Einzellösungen baut, ist es praktisch immer viel >> billiger, den nächstgrößeren Boliden zu kaufen als durch selber >> schreiben irgendwelcher Libs das Programm zu optimieren. > > Das hat mit kundenspezifisch wenig zu tun sondern was mit Stückzahlen. Deswegen schrieb ich ja das Wort "EINZELLÖSUNGEN" dazu - Stückzahl eins. Kennst du da welche, die nicht kundenspezifisch sind? > Wenn ich 100.000 Euro Entwicklungskosten habe, die meist zum größten > Teil Personalkosten (=Zeit) sind, ist es halt ein Unterschied ob ich die > auf 10 oder 10.000 verkaufte Produkte umlegen kann! Bei dem, was ich tue, gibt's meist kein Produkt, sondern ein Gewerk, von dem ich genau 1 verkaufe. Die Personalkosten verteilen sich also nicht. Und genau davon sprach ich: Da lohnt es sich nicht selten, etwas Fertiges für viel Geld zu kaufen, statt es für noch viel mehr Geld selbst zu entwickeln. > Time is Money ist kein leeres Geschwätz sondern Realität. Sag ich ja.
Volle schrieb: > Nicht vergessen die Lizenzbedingungen für den Fremdcode prüfen und > einhalten. Wenn man uC wie Stm32 oder AVR programmiert (natürlich lockbits nicht vergessen) so kann keiner euch nachweisen welche Libs ihr genommen habt. Ansonsen Libs nachschreiben bzw so abändern dass einige Funktionen an anderer Stelle stehen. Sodass auch das Kompilat sich ändert....
Florian schrieb: > Volle schrieb: >> Nicht vergessen die Lizenzbedingungen für den Fremdcode prüfen und >> einhalten. > > Wenn man uC wie Stm32 oder AVR programmiert (natürlich lockbits nicht > vergessen) so kann keiner euch nachweisen welche Libs ihr genommen habt. > > Ansonsen Libs nachschreiben bzw so abändern dass einige Funktionen an > anderer Stelle stehen. Sodass auch das Kompilat sich ändert.... Dir wünsche ich aus vollem Herzen eine Klage an den Hals. Unterirdischer gehts ja wohl nicht mehr, hier öffentlich zu gewerblichen Urheberrechtsverletzungen aufzurufen! Ich glaub mein Schwein pfeift! Ich möchte Dich mal sehen was Du dazu sagen würdest wenn einer Deinen Code klauen und Umsätze damit generieren würde. Aber wahrscheinlich kann das gar nicht geschehen weil Du noch nie was selbst geschaffen hast das es wert gewesen wäre von jemand anderem zu Geld gemacht zu werden, nur so lässt sich so eine kranke Einstellung erklären.
Florian schrieb: > Volle schrieb: >> Nicht vergessen die Lizenzbedingungen für den Fremdcode prüfen und >> einhalten. > > Wenn man uC wie Stm32 oder AVR programmiert (natürlich lockbits nicht > vergessen) so kann keiner euch nachweisen welche Libs ihr genommen habt. > > Ansonsen Libs nachschreiben bzw so abändern dass einige Funktionen an > anderer Stelle stehen. Sodass auch das Kompilat sich ändert.... Du empfiehlst also, gegen die Lizenzbedingungen bewusst zu verstoßen und das einfach durch diese Maßnahmen zu verschleiern? Naja, wenigstens ist so die Strafe höher, wenn es dann doch auffliegt.
Arduino Fanboy D. schrieb: > Und ebenso viel Sinn macht es, sich aus dem Library Baukasten zu > bedienen, wenn man schnell fertig werden muss/will. Aber man sollte sich auch der negativen Auswirkungen bei dauerhaft exzessiven und ausschliesslichem Gebrauch von (zusammengepanschten) Bibliotheken auf den Charakter bewusst sein: -Verlust der Fähigkeit sich in Specs einzulesen oder eigene klar zu formulieren -zunehmende Oberflächlichkeit -gerät Programmiertechnisch" aus der Übung -Verleugnen resp. Verharmlosen von Bugs aus ungesichteten Code -der stete Drang Nachschub in Form von updates zu organisieren lenkt von anderen Optionen der "Problemlösung" ab Ist halt wie der Fahrradfahrer der aufs Auto umsteigt - man wird bequem, fett und unsicher über die eigenen Fähigkeit und beschränkt den Wettbewerb mit Nachwuchstalenten auf grimmiges Knurren und Verweis auf verstaubte Trophäen. ;-)
Βιβλιοθηκονόμος schrieb: > Ist halt wie der Fahrradfahrer der aufs Auto umsteigt - man wird bequem, > fett und unsicher über die eigenen Fähigkeit und beschränkt Wie oft fährst du mit dem Fahhrad Strecken > 50km?
Falk B. schrieb: > Βιβλιοθηκονόμος schrieb: > >> Ist halt wie der Fahrradfahrer der aufs Auto umsteigt - man wird bequem, >> fett und unsicher über die eigenen Fähigkeit und beschränkt > > Wie oft fährst du mit dem Fahhrad Strecken > 50km? Lange Strecken sind keine akzeptierten Ausreden für totalen Bewegungsmangel. So wie man als Berufsfahrer auch mal Strecken zu Fuß gehen oder radeln kann (Freizeitsport, Weg zur Arbeitsstätte), so kann man auch als Entwickler mal ne Funktion selber schreiben, resp. fremde analysieren). Wie heisst es so treffend: "Wer rastet, der rostet" und "Adipositas ist keine Berufskrankheit"
Βιβλιοθηκονόμος schrieb: > kann (Freizeitsport, Weg zur Arbeitsstätte), so kann man auch als > Entwickler mal ne Funktion selber schreiben, resp. fremde analysieren). Hat dis irgenendeiner bestritten oder gar verboten? Die Argumentation lief die meiste Zeit doch nur gegen das "ich kann alles besser, ich mach alles selber".
Falk B. schrieb: > Die Argumentation lief die meiste Zeit doch nur gegen das "ich kann > alles besser, ich mach alles selber". Na und dann Argumentieren wir mal zur Abwechslung: "Ich mach nichts selber, weil das ist mir zu groß und wenn ich irgendwann komplett aus der Übung bin, dann ist das unvermeidbar"
Βιβλιοθηκονόμος schrieb: > Ist halt wie der Fahrradfahrer der aufs Auto umsteigt - man wird bequem, > fett und unsicher über die eigenen Fähigkeit und beschränkt den > Wettbewerb mit Nachwuchstalenten auf grimmiges Knurren und Verweis auf > verstaubte Trophäen. Wenn Du aber mit dem Fahrrad zu spät kommst, fragt man Dich, warum Du nicht das Auto genommen hast. Wenn Du die Programmieraufgabe nicht termingerecht löst, fragt keiner danach, daß Du printf, Ethernet, USB usw. zu Fuß nachentwickelt hast, denn das war nicht Deine Aufgabe. Aber Dein Chef fragt sich, ob er Dich abmahnen soll und die Mitbewerber lachen sich ins Fäustchen. Will man effizient arbeiten, beschränkt man sich nur auf die eigentliche Applikation, d.h. man wird schneller fertig und macht weniger Fehler.
Mark B. schrieb: > Da, wo es schon eine fertige und gut funktionierende Bibliothek für > etwas gibt (z.B. gmp, libcurl, ...) sollte man das Rad nicht neu > erfinden. Wir nutzen auf Arbeit so ein kleines Bibliothekchen namens "Android"... und nein, das entwickeln wir nicht selbst. Auch vermeiden wir unter großen Schmerzen, daran Änderungen vorzunehmen. Und das hat Gründe.
0815 schrieb: > oder selber schreiben? Natürlich selber schreiben, alles, auch den Compiler, das BS deines PCs, alles! :-<<< Warum das Rad neu erfinden. Konzentriere dich auf das Neue, dein Problem und vertraue der Generation vor dir. ;-)
Peter D. schrieb: > Wenn Du aber mit dem Fahrrad zu spät kommst, fragt man Dich, warum Du > nicht das Auto genommen hast. Dann lautet die Antwort, dass man bei Verwendung eines Auto möglicherweise noch viel später angekommen wäre. Warum wird auch in diesem Thread die bedingungslose Überlegenheit von Autos postuliert? Ach, ich vergaß, dass wir in Deutschland sind.
Βιβλιοθηκονόμος schrieb: > So wie man als Berufsfahrer auch mal Strecken zu Fuß gehen oder radeln > kann (Freizeitsport, Weg zur Arbeitsstätte), so kann man auch als > Entwickler mal ne Funktion selber schreiben, resp. fremde analysieren). Mal ne Funktion/Lib selbst schreiben ist auch ne andere Hausnummer als jede Lib selbst zu schreiben. Nicht hier Äpfel mit Birnen vergleichen ;)
Βιβλιοθηκονόμος schrieb: > Aber man sollte sich auch der negativen Auswirkungen bei dauerhaft > exzessiven und ausschliesslichem Gebrauch von (zusammengepanschten) > Bibliotheken auf den Charakter bewusst sein: Ich möchte mal wissen, wie Du herausgelesen hast, daß auch nur ein einziger hier so arbeitet. In meinen Augen ist das ein völlig haltlose Unterstellung. Natürlich kauft man im gewerblichen Umfeld einen professionellen Compiler mit IDE, Bibliotheken und Supportvertrag. Gibt es Probleme mit den Bibliotheken, dann wendet man sich an den Support. Man verschwendet aber keine Zeit damit, Bibliotheken nachzuentwickeln.
Peter D. schrieb: > Natürlich kauft man im gewerblichen Umfeld einen professionellen > Compiler mit IDE, Bibliotheken und Supportvertrag. Gibt es Probleme mit > den Bibliotheken, dann wendet man sich an den Support. Man verschwendet > aber keine Zeit damit, Bibliotheken nachzuentwickeln. Genau. Und aus dem selben Grund lässt man im gewerblichen Umfeld auch keine ASICs entwickeln für Millionen und Abermillionen sondern klöppelt alles aus klobigen Standardbauteilen zusammen, auch wenns dann zwölf mal so groß wird und nicht mehr in so ein schnuckeliges kleines Gehäuse passt wie das der unverantwortlich selbstfrickelnden Mitbewerber. Und wer ganz klug ist entwickelt gar nichts mehr, reine Zeitverschwendung, schließlich kann man heutzutage alles fertig in China kaufen. Nur so wird man zur Hi-Tech Weltmacht. Was wir also in Zukunft brauchen sind Fachkräfte die Tetris mit Lego-Bausteinen spielen können und diese Bausteine fallen bekanntlich vom Himmel wie jeder sicherlich weiß. [Übertreibungen erhöhen die Anschaulichkeit]
:
Bearbeitet durch User
Bernd K. schrieb: > Dir wünsche ich aus vollem Herzen eine Klage an den Hals. Unterirdischer > gehts ja wohl nicht mehr, hier öffentlich zu gewerblichen > Urheberrechtsverletzungen aufzurufen! Ich glaub mein Schwein pfeift! Komm runter von der Palme. Wenn jemand den Chip von Firma X einkauft und den mit den Lib's von Firma X beglückt - welche diese Firma X genau dafür vorgesehen hat - dann steckt da überhaupt keine Rechtsverletzung drin. Aber indem dieser Jemand sich auf die dargebotene Lib von X eingelassen hat, hat er sich fröhlich einen Ring durch die Nase ziehen lassen und ist nun an der Kette der Firma X. Wenn es bei der Firma Y nun einen Chip gibt, der für den Jemand eientlich besser wäre, dann kann er den nicht benutzen, weil die Libs von X partout nicht auf den Chip von Y passen. Also wäre der Jemand drauf angewiesen, sich in den von Y dargebotenen Libs umzusehen und sein ganzes Projekt auf das Zeugs von Y umzustellen. Das wäre der Austausch des Rings durch die Nase von X nach Y. Und: Selbstverständlich kennen die Firmen X und Y sich innig - und so achten sie pingelig darauf, daß kein Kunde ohne erheblichen Mehraufwand eine Lib vom einen mit dem Chip vom anderen verwenden kann. Falls es zu den jeweiligen Libs nen Quellcode geben sollte, dann ist der so gestaltet, daß das Umschreiben möglichst schön aufwendig ist und inhaltlich an eine komplette Neufassung heranreicht. Linux ist da ein klassischer Fall. Nichts von Unix im juristischen Sinne verwendet, sondern alles "selbst und neu" geschrieben. Ähnlichkeiten sind rein zufälliger Art. Das übliche Kleingedruckte eben. Eigentlich ist das Problem klar: Firmen sind bemüht, ihre Kunden an sich zu binden und keinen Vorschub zu leisten für Chips anderer Hersteller - und Anwender sollten eigentlich bemüht sein, sich nicht freiwillig in unnötige Abhängigkeiten zu manövrieren - auch wenn das Dargebotene auf den allerersten Blick vorteilhaft aussehen sollte. Es ist eben ein grundsätzlicher Interessenkonflikt. W.S.
Bernd K. schrieb: > Und aus dem selben Grund lässt man im gewerblichen Umfeld auch > keine ASICs entwickeln für Millionen und Abermillionen sondern klöppelt > alles aus klobigen Standardbauteilen zusammen Woher nimmst Du diese Gewißheit? Man sollte immer die Lösungen nehmen, die für das Problem optimal passen. Für viele Aufgaben wären ASICs der absolute Overkill. Und ja, 0201 Kondensatoren mag ich nicht. Ich nehme die "klobigen" im 0603, die kann ich gerade noch händisch löten. Auf die Gehäusegröße hat das eh keinen Einfluß. Bernd K. schrieb: > Und wer ganz klug ist entwickelt gar nichts mehr, schließlich kann man > heutzutage alles fertig in China kaufen. Schön wärs, wir können uns vor Entwicklungsaufgaben nicht retten, aber Elektronikentwickler sind Mangelware.
W.S. schrieb: > Linux ist da ein klassischer Fall. Nichts von Unix im juristischen Sinne > verwendet, sondern alles "selbst und neu" geschrieben. Ähnlichkeiten > sind rein zufälliger Art. Das übliche Kleingedruckte eben. Die Ähnlichkeiten sind nicht "zufällig", sondern nennen sich POSIX und sind eine ISO- und IEEE-Norm. Es gibt auch einen großen Unterschied, ob man eine eigene Implementation einer Spezifikation schreibt, oder ob man fremden Code illegal in sein Programm einbaut und dann ein paar Sachen ändert und umsortiert, um damit diesen Tatbestand zu verschleiern.
Peter D. schrieb: > Schön wärs, wir können uns vor Entwicklungsaufgaben nicht retten, aber > Elektronikentwickler sind Mangelware. Offenbar aber auch wieder nicht so sehr, als dass man bereit wäre, die Gehälter ordentlich anzuheben. Wie war das doch gleich? Wenn die Nachfrage groß ist und das Angebot gering, dann steigt entsprechend deutlich der Preis... Komischerweise soll das für Personalkosten aber nicht gelten. :-/
Mark B. schrieb: > Wie war das doch gleich? Wenn die Nachfrage groß ist und das Angebot > gering, dann steigt entsprechend deutlich der Preis... Wenn der Preis allerdings die Mittel des Käufers übersteigt gibts gar kein Geschäft und die Mittel des potentialen Käufers sinken weiter. Siehe Stadt Berlin, da läuft ohne Zuschuß wie Länderfinanzausgleich inzwischen garnichts und die Stadt verkommt zu einer H4-Verwahranstalt. Peter D. (peda) hinterliess: >Ich möchte mal wissen, wie Du herausgelesen hast, daß auch nur ein >einziger hier so arbeitet. Siehe die Diskussion zu der Behauptung, das keiner eine USB-Bibliothek selbst erstellt respektive schon der Gedanke daran dazu reine Blasphemie wäre. [Übertreibungen erhöhen die Anschaulichkeit] Und ausserhalb dieses threads die Hilflösung wenn ein ganz bestimmtes Update einer (Arduino-)Bibliothek benötigt wird. Fällt mir persönlich regelmäßig beim Lesen der make auf; da wird gross Hintergrundinfo zu einem technischen Schmankerl versprochen die dann lediglich auf den Verweis auf eine bekantermassen unvollständige und wacklige Bibliothek besteht. Bspw.: https://www.heise.de/select/make/2018/1/1519688503646911
Βιβλιοθηκονόμος schrieb: > Siehe die Diskussion zu der Behauptung, das keiner eine USB-Bibliothek > selbst erstellt respektive schon der Gedanke daran dazu reine Blasphemie > wäre. [Übertreibungen erhöhen die Anschaulichkeit] Du pickst Dir einzelne Meinungen heraus und unterstellst sie als allgemein gültig. Dem ist nicht so. Das hat nichts mit Übertreibung zu tun, sondern ist reines Klischeedenken. Βιβλιοθηκονόμος schrieb: > Fällt mir persönlich > regelmäßig beim Lesen der make auf; Ich bezweifle mal stark, daß hier auch nur ein einziger die make als Fachzeitschrift ansieht. Sich auf die make zu beziehen, ist ein Witz. Damit nimmt Dich niemand mehr ernst. Du solltest Dir mal den Unterschied zwischen professionell und Hobbybastler klarmachen. Den gibt es nämlich.
Peter D. schrieb: > Du solltest Dir mal den Unterschied zwischen professionell und > Hobbybastler klarmachen. Den gibt es nämlich. Das vermischen hier viele und wer will es ihnen schon verdenken ;)
Peter D. schrieb: > Du solltest Dir mal den Unterschied zwischen professionell und > Hobbybastler klarmachen. Den gibt es nämlich. Sicher gibt es den, der hat aber an sich erstmal nichts mit der Qualität zu tun - weder in der Ausführung, noch im Ergebnis. Es gibt aber auf einen Unterschied zwischen ordentlicher Arbeit und "works for me". Und zwischen Embedded-Entwicklung und Web-Development (und den vorherrschenden Mentalitäten). Βιβλιοθηκονόμος schrieb: > [Übertreibungen erhöhen die Anschaulichkeit] Starke Übertreibungen stellen in erster Linie den Übertreiber als inkompetent und/oder böswillig dar. Klassisches Beispiel: Verkäufer.
Peter D. schrieb: > mal den Unterschied zwischen professionell und > Hobbybastler klarmachen. Den gibt es nämlich. > Natürlich kauft man im gewerblichen Umfeld einen professionellen > Compiler mit IDE, Bibliotheken und Supportvertrag. Gibt es Probleme mit > den Bibliotheken, dann wendet man sich an den Support. Also falls man es nicht mit Support als RundUmSorglosPaket kaufen kann, dann setzt man es erst nicht ein - das klingt sehrrrrr professionell! SCNR
Axel Zucker schrieb: > Also falls man es nicht mit Support als RundUmSorglosPaket kaufen kann, > dann setzt man es erst nicht ein - das klingt sehrrrrr professionell! > SCNR Tipp: Wenn erkannt wird, dass eine Aussage falsch ist, dann bedeutet das noch lange nicht, dass das genaue Gegenteil davon automatisch richtig ist.
Axel Zucker schrieb: > Also falls man es nicht mit Support als RundUmSorglosPaket kaufen kann, > dann setzt man es erst nicht ein Schon wieder eine Aussage, die so niemand getroffen hat. Wenn eine Lib mit Support angeboten wird, dann sollte man diese bevorzugen. Erst wenn etwas dagegen spricht, schaut man sich nach anderen Lösungen um oder entwickelt sie selber. Sei doch mal ein bischen flexibel. Das gehört zu einem guten Entwickler einfach dazu. Es gibt für den Entwickler kein RundUmSorglosPaket. Daher muß er ständig abwägen welche Komponente kann er kaufen und welche muß er selber entwickeln.
Peter D. schrieb: > Es gibt für den Entwickler kein RundUmSorglosPaket. Daher muß er ständig > abwägen welche Komponente kann er kaufen und welche muß er selber > entwickeln. Bei dem Erwerb eines RundUmSorglosPakets geht es aber häufig gar nicht um eine technisch funktionsfähige Lösung, sondern um die Möglichkeit, bei beliebigen Problemen auf einen Dritten zeigen zu können. Wenn man dann in solchen Fällen eine juristische Klärung angestoßen hat, hat man wieder Zeit gewonnen, um seine eigenen Leichen im Keller wegzuräumen. Ob dabei irgendwann ein funktionsfähiges Produkt zu akzeptablen Entwicklungskosten entsteht, ist völlig egal. So ist die Denkweise in vielen Großunternehmen.
Peter D. schrieb: > Axel Zucker schrieb: >> Also falls man es nicht mit Support als RundUmSorglosPaket kaufen kann, >> dann setzt man es erst nicht ein > > Schon wieder eine Aussage, die so niemand getroffen hat. Keine Aussage, sondern eine these. Oder eine persönliche Zusammenfassung was an wahren Gehalt der wohlgefeilten Wortblasen "Professioneller Entwicklung" durch Einkauf von 3rd party Produkte hier ankommt. Andreas S. schrieb: "Bei dem Erwerb eines RundUmSorglosPakets geht es aber häufig gar nicht um eine technisch funktionsfähige Lösung, sondern um die Möglichkeit, bei beliebigen Problemen auf einen Dritten zeigen zu können." Na beim "Zeigen auf Dritte" bleibt es meistens nicht, da wird auf (unendliche) Nachbesserung gepocht und der Supportvertrag ausgelutscht bis zum geht nicht mehr. Deshalb sind solche Verträge auf genau umrissene Szenarien beschränkt, typischerweise Installation und Demoapplikation, thats it; gern mit deckel auf ein paar Mannstunden oder Emailsupport mit nach oben offener Antwortzeit. Alles darüber hinaus zählt zu Engineering Dienstleistungen, die extra und auf Stundenbasis buchbar sind.
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.