Hallo, ich versuche mich seit 3-4 Monaten mit dem Thema µ-Elektronik zu beschäftigen. Realisiert habe ich eine Servoansteuerung, PWM-LED Ansteuerung und eine Uhr. Fairerweise muss ich sagen, dass ich einige Codefragmente mir vom Netz gezogen habe. Ich möchte mal eine Frage in den Raum werfen. Ist es besser jedesmal das Rad neu zu erfinden oder von bekannten und ähnlichen Projekten schon existierende Codes zu übernhmen. Wo liegt eigentlich der Sinn? Gruß Onur
Naja, kommt auf die Aufgabenstellung an. Will man etwas lernen, ist es vor allem am Anfang besser, etwas selbst zu entwickeln. Möchte man später nur etwas nutzen, kann man auch auf fertigen Code zurückgreifen. Diesen muss man aber verstehen, um eventuelle Schwierigkeiten beseitigen zu können, man muss also schon vorher etwas gelernt haben.
Es spricht überhaupt nichts dagegen, fertige Codefragmente zu benutzen. Wenn man sie selbst erzeugt hat, fällt das ja nicht unter "Rad neu erfinden", sondern darunter, gelerntes neu anzuwenden. Codefragmente aus dem Netz ziehen kann dann problematisch sein, wenn man sie nur kopiert und nicht die Funktionsweise versteht. Manche lassen sich ihre Programme auch von Wizards erstellen, indem sie nur Blöcke "zusammenklicken".
Für den Neuling kann es interessant sein, sich auf etwas fertiges zu stützen, da hat man sicher erstmals genug Probleme. Dann aber nach und nach erforschen, was man denn da so eingebaut hat. Im Beruflichen Umfeld muss man mit fremdem Code sehr aufpassen, gibt es Probleme, muss man den Code untersuchen, verstehen, den Fehler/das Problem beheben und hinterher hat man öfters mal den Eindruck: Das hättest Du selbst schneller programmiert (und besser) Merke: Fremdcode einsetzen ist Vertrauenssache. Ciao
Stimme Timo zu. Ansonsten hätte die Benutzung von Standard-C Libs ja garkeinen Sinn.
Als alter Assembler Fan kann ich dir einen kleinen Tip zum Umgang mit C geben. Durchforsche mal die Funktionen aus der LIB wie z.B. LTOA, ITOA, ATOI etc. etc. Schreib dir zu jeder Funktion ein kleines Beispiel um die Funktionsweise zu verstehen. 2ter Schritt, schreibe deine eigenen Versionen von den genannten LIB's, du wirst sehr schnell herausfinden das dies recht einfach ist. Bei kleinen Anwendungen wirst du feststellen das du nur einen Bruchteil der LIB's benötigst. Durch Schritt 1, 2 bist du jetzt in der Lage dir die benötigten Komponenten selbst zu schreiben. Fremden Code zu übernehmen ist für Lernzwecke völlig Ok, bei einem Projekt bei dem du die Verantwortung trägst solltest du allerdings jede Zeile des Codes verstehen. Goldene Regel: Verwende nie !ungeprüft! fremden Code. Also, fremder Code ist immer ein guter Lehrmeister. Programmierer mit Erfahrung können einem Anfänger eine Menge Tips geben. Verstehen ist aber oberstes Gebot.
Naja, das kommt immer auf die Komplexität an. Manche Dinge kann man einfach nicht selbst machen, sondern muss auf Bibliotheken zurückgreifen. Auf uC-Ebene geht es vielleicht gerade noch. Natürlich sollte man nicht etwas aus dubiosen Quellen verwenden und ungeprüft übernehmen, wie schon erwähnt wurde, ist das Verständnis sehr wichtig. Was mir schon öfters aufgefallen ist, dass Leute, die das Rad neu erfinden wollen, es meistens eckig erfinden. Man sollte also schon wissen, dass es rund ist. Ich habe eben schon oft beobachtet, und auch manchmal bei mir selbst festgestellt, dass man eine umständliche Lösung entwickelt, weil einem einfach das Handwerkszeug bzw. die Theorie fehlt, oder man zu bequem ist, sich in so etwas einzuarbeiten. Man nimmt sozusagen den Hammer um eine Schraube reinzudrehen, weil man sich mit dem Schraubenzieher nicht auskennt. Also man sollte sich vorher schon gut informieren, welche Lösungsansätze es gibt. Diesen dann nicht von jemand anders zu übernehmen, sondern selbst durchzuführen, ist natürlich dann sinnvoll.
>> Was mir schon öfters aufgefallen ist, dass Leute, die das Rad neu >> erfinden wollen, es meistens eckig erfinden. Der gefällt mir ;-)) aber wenn das eckige Rad fertig ist dann hat man eine Menge gelernt. Aus dieser Erfahrung heraus dann wieder auf die LIB zurückzugreifen ist Ok. >> Manche Dinge kann man einfach nicht selbst machen, sondern muss auf >> Bibliotheken zurückgreifen. Dafür sind diese ja da, dennoch benötigt man bei MC's meist nur Teile davon. Beispiel "printf", sicher eine mächtige Funtkion (auch im Speicherbedarf). Wenn man nur ein bischen Text ausgeben möchte dann sollte man bei MC's auf solche LIB's verzichten. Hier mal ein schönes Beispiel (fremder Code)!! ;-) Beitrag "Zahlenausgabe"
Naja, man hat vielleicht was bei dem eckigen Rad gelernt, aber eben nicht unbedingt das, was einem weiterbringt. Man hat im Prinzip gelernt, wie man es eben nicht machen sollte :) Man kann natürlich dabei aus den Fehlern lernen, man kann aber auch ewig bei seinen Umstandslösungen bleiben.
Joe wrote: > Wenn man nur ein bischen Text ausgeben möchte dann > sollte man bei MC's auf solche LIB's verzichten. "Pausschalaussagen sind immer Mist". :-) Wenn ich einen ATtiny2313 habe, will ich sicher kein printf() zum Debuggen nehmen. Wenn ich sowieso einen ATmega1281 benutze, was soll ich mir die Mühe mit dem Zusammenkratzen irgendwelchen Nicht-Standard-Krempels machen, wenn ich stattdessen durch Benutzung von printf() den ROM-Verbrauch meines Projektes von 34 auf 35 % steigere und damit meine Debugausgaben in 3 Minuten am Laufen habe? Also: einfach den Verstand einschalten und abwägen, was einem jetzt gerade wichtig ist.
>> "Pausschalaussagen sind immer Mist". :-) Da gebe ich dir Recht aber bleib mal auf'm Teppich. Es geht um Kohle und nicht um graue Theorie. Wenn du eine Schaltung kostengünstig realisieren mußt und auf C nicht verzichten willst dann mußt du kreativ sein. Hab ja ein Beispiel verlinkt. Jedenfalls habe ich auch diverse 2k Typen im Einsatz wie MSP430F2013 oder ATTINY's. C Programmierer, insbesondere Anfänger sind schnell am Ende ihrer Künste. >> Wenn ich sowieso einen ATmega1281 benutze, was soll ich mir die >> Mühe mit dem Zusammenkratzen irgendwelchen Nicht-Standard-Krempels >> machen, wenn ich stattdessen durch Benutzung von printf() den >> ROM-Verbrauch meines Projektes von 34 auf 35 % steigere und damit >> meine Debugausgaben in 3 Minuten am Laufen habe? Stimmt wohl, dennoch sollte man selber Denken lernen (selber Programmieren können) und dann LIB's verwenden. Ein schönes Beispiel wäre auch eine Displayansteuerung. Wenn ich mir anschaue was da für ein Mißt herauskommt und dann als "die LIB" angepriesen wird ;-)) Displays sind ja immer wieder einen Thread wert, durchforste mal das Forum zu diesem Thema. Bei den C Freaks lach ich mich dann meistens schlapp. Overhead und Null Verständnis werden hier schnell offensichtlich. In diesem Sinne, viel Spaß beim Lernen.
Nochmal zum Thema Sinn & Unsinn, wenn du einen 2k Chip einsetzt, sagen wir mal für 90 Cent und deine Mitbewerber hier einen 16k Typ für 3 Euro einsetzen, dann erschließt sich vielleicht der Sinn. Produziere jetzt mal ne Stückzahl > 10000. Alles klar ?
Joe wrote: >> "Pausschalaussagen sind immer Mist". :-) > Da gebe ich dir Recht Dann hast du nicht lange genug drüber nachgedacht: da war nicht umsonst ein Smiley dahinter. Das ist nämlich selbst eine Pauschalaussage, führt sich damit selbst ad absurdum. ;-) > Es geht um Kohle und nicht um graue Theorie. Aber erst ab einigen 1000 Stück produzierter Geräte. Viele der hier Mitlesenden werden diese Stückzahl eher nicht erreichen. Bis dahin ist nämlich die Arbeitszeit in der Regel teurer (selbst im Hobbybereich: mit den 2 Stunden, die mir am Abend noch bleiben, möchte ich auch möglichst effektiv umgehen). Selbst für die Entwicklung eines solchen Produkts kann printf() zum Debuggen eine sinnvolle Methode sein, die einem einiges an Zeit sparen kann. Seit dem Zeitalter von Controllerfamilien sollte es nicht zu schwer sein, auf einem größeren Mitglied der Familie zu entwickeln und erst im letzten Viertel der Produktfertigstellung auf den Ziel-Controller "downzusizen" (schlimmes Wort). Ich wollte ja auch nur drauf hingewiesen haben, dass für jede Entscheidung die Umstände zu berücksichtigen sind. Eine Pauschalverteufelung von bewährten und funktionierenden Dingen wie printf() oder selbst malloc() ist genauso verkehrt am Platz wie deren bedenkenloser Einsatz. > Displays sind ja immer wieder einen Thread wert, durchforste mal das > Forum zu diesem Thema. Bei den C Freaks lach ich mich dann meistens > schlapp. Overhead und Null Verständnis werden hier schnell > offensichtlich. Schon wieder eine Pauschalverurteilung... Ich könnte genauso pauschal sagen, dass Assemblerfreaks immer sinnlos viel Zeit in ihre Projekte verplempern. ;-)
>> Schon wieder eine Pauschalverurteilung... Ich könnte genauso pauschal >> sagen, dass Assemblerfreaks immer sinnlos viel Zeit in ihre Projekte >> verplempern. ;-) Deswegen programmiere ich in C ;-)) nicht immer, aber immer öfter.
>Ist es besser jedesmal das Rad neu zu erfinden oder von bekannten >und ähnlichen Projekten schon existierende Codes zu übernhmen. LOL es würde mir im Traum nicht einfallen, z. B. eine einmal geschriebene Software-UART jedesmal neu zu schreiben. Die wird kopiert und fertig.
> LOL es würde mir im Traum nicht einfallen, z. B. eine einmal > geschriebene Software-UART jedesmal neu zu schreiben. Die wird kopiert > und fertig. Schon richtig, aber hier werden - übrigens schon wieder - Äpfel mit Birnen verglichen. Deinen eigenen Code zu verwenden, ist Erste Wahl. Du hast schon gelernt wies geht, kennst den Code und weißt, dass er keine Fallen birgt. Falls denn doch (irgendwie dumm gelaufen zum Beispiel) kennst Du Deinen Code immer noch und findest den Fehler schneller. Aber eigentlich war die Rede von Fremd-Libraries, der Kollege hat sich, wie er schreibt, Codefragmente aus dem Netz geholt. Wenngleich ich mir wünschen würde, dass man etwas schonender miteinander umgeht. Immerhin ist es nicht einfach, dass was man denkt in Worte zu fassen, die das was man denkt auch wiedergeben und auch so verstanden werden. Und wenn dann mal einer was dummes schreibt, dann cool bleiben. Ciao
Ich gebe dir Recht und entschuldige mich für mein etwas agressives Posting.
Servus, für mich als Anfänger ist es schon interessant zu wissen, wie man ein Code selber schreibt, aber viel wichtiger ist es, wie man überlegt und strukturiert vorgeht. Es geht hier nicht um Geld oder Codezeilen. Um es mal kurz auf den Punkt zu bringen: Die Programmierbeispiele von Peter Danegger sind ja mal zum durchlesen gut, aber verstehen tue ich nicht alles, also interpretiere ich sein Code etwas um, in eine vielleicht etwas umständlichere Methode, aber wenigstens blicke ich es dann. Denn um einen Rang wie es der Peter hat zu erreichen, muss ich noch viel viel Code schreiben, vor allem aber ein Schema dazu haben. Nur als Beispiel, ich möchte mir demnächst eine Uhr programmieren, die das DCF77 Signal abgreift und es am LCD ausgibt, mehr nicht. Jetzt kommt der Moment. Also, mache ich mich schlau und versuche im Netz soviele Infos zu besorgen wie es geht (nicht Code). Einen Code zu kopieren ist ganz leicht, wäre dann aber nicht im Sinne unseres Hobbys, oder?? Allenfalls kann ein fremder Code nur ein Denkanstoß geben. Und wenn ich dann alles habe, mir ein Vorgehen überlege, ein Code schreiben, nur dann wäre ich der glücklichste Mensch der Welt. @hackklotz, Ja ich gebe Dir recht. Wenn man eine selber geschrieben UART Routine hat, die immer wieder verwendet werden kann, dann muss ich das nicht immer neu erfinden. Gruß Onur
Bitte 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.