mikrocontroller.net

Forum: Offtopic Sinn und Unsinn eines Codes


Autor: Onur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Willi Wacker (williwacker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimme Timo zu. Ansonsten hätte die Benutzung von Standard-C Libs ja 
garkeinen Sinn.

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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"

Autor: Gast123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> "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.

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: hackklotz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Willi Wacker (williwacker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: hackklotz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gebe dir Recht und entschuldige mich für mein etwas agressives 
Posting.

Autor: Onur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Yahoo-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.