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
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
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
