Guten Abend, ich bin ein eigentlich sehr Guter Hobby-Bastler (-Elektrobastler). Meine bisherigen Projekte mit AVRs wurden aber von meinem Bruder Programmiert. Da der natürlich darauf weder Lust noch Zeit dafür hat, möchte ich mir das Programmieren selbst aneignen. Welche Sprache nutze ich dazu? Ich würde mir eine Sprache aussuchen zu der es viele Anfänger-Tutorials gibt, und in die man nicht viel Investieren muss (Programmiersoftware). Ein Atmel-Evaluationsboard von Pollin besitze ich, ebenfalls ein Steckboard und alle Bauteile um einen ATMega zu betreiben. Bisher habe ich noch keine Kenntnisse im AVR-Programmieren, weshalb ich völlig frei in der Auswahl bin. Ich hoffe ihr versteht was ich möchte und könnt mir helfen. MFG
Dann nimm C/C++ und gehe das Tutorial hier mal durch: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial AVR-Studio, WinAVR und unter Linux GCC können das ;-)
Frag deinen Bruder ;-) ,der kann dann wenigstens helfen .
Hallo Habibi, ich persönlich würde Basic als Programmiersprache empfehlen. Schau Dir mal den BASCOM AVR Compiler an. Hier kann man eine kostenlose Version herunterladen, die lediglich in der Größe des erzeugten Programmcodes eingeschränkt ist. Für einen Anfänger ist der geradezu ideal. http://www.mikrocontroller.net/articles/Bascom_AVR Man findet auch viele einfache Beispiele, die den Einstieg in die Materie leicht macht. Später kannst Du dann immer noch auf andere Sprachen, wie z.B. den GNU C Compiler wechseln, der eher was für Fortgeschrittene ist. Beste Grüße, Norbert
Wenn Du die Sprache sowieso von Grund auf neu lernen musst, dann wuerde ich nichts anderes als C/C++ empfehlen. C gibt Dir die besten Grundlagen.
Hi Nun ja, eigentlich gab es nur eine Antwort, die meiner Meinung nach richtig war: Esoteriker schrieb: > Frag deinen Bruder ;-) ,der kann dann wenigstens helfen . Eine ideale Sprache gibt es nicht. C ist weit verbreitet und ist im professionellen Bereich ein "Muss", aber ob du als Elektronikbastler mit selbst erlernter Software jemals ein Profi wirst ..... die Antwort kannst du dir selber geben. BASCOM ist, wenn man es von Grund auf lernen muss, genauso schwierig, wie C, allerdings ist der Syntax leichter zu verstehen. Aber alles nur eine Kopfsache. In der Regel kann ich nur sagen: die Sprache ist gar nicht so entscheidend. Wichtig ist denken zu können, wie ein Controller. Und da wird die größte Schwierigkeit sein. Nimm es mir nicht übel, aber allein schon die Frage: welche Sprache zeigt mir, wie du denkst. Nix für ungut, soll nicht bös gemeint sein, aber überleg mal selbst, wie man heraus findet, welche Sprache sinnvoll ist und wie man in kurzer Zeit auch Fortschritte macht. In diesem Forum gibt es z. B. Tutorial für C und Assembler. Bei anderen Foren sicherlich auch Anleitungen zu BASCOM. Tja, wie soll ich es sagen... vielleicht so: Wenn du eine Uhr gebaut hast, dann interessiert es dich, wie ein Programm gestaltet werden muss. Also schaust du dir die Beiträge zu diesem Thema an, und versuchst diese dann auszuprobieren. Schritt für Schritt. Schließlich lässt du eigene Ideen einfließen und bist dann ständig in der Hilfe der gewählten Sprache, weil du die Lösung für dein Problem aus der Hilfe ableiten kannst. Aber klar, du kannst auch fragen. Mein Text soll dich nicht vor den Kopf stoßen, sondern ich möchte dir helfen, den Weg zu finden. Der Einstieg in eine Programmiersprache ist um vieles schwieriger, wenn du deine Gedanken nicht in logische Vorgehensweise lenken kannst. Ich hoffe, du findest den Weg, nicht die Sprache. Egal was du anfängst, irgendwann geht es in dieser Sprache nur mit komplizierten Klimmzügen unter Verschwendung von Resourcen. Dann stellst du fest, in einer anderen Sprache werden die Komponenten bereits geliefert und dann setzt du dich hin und liest dich in die Sprache ein, wenn dein Vorhaben damit leichter umsetzbar ist. Beispiel: Mathematische Funktionen in Assembler, BASCOM oder C Gruß oldmax
Wenn Du sicherstellen kannst, niemals mit der Außenwelt in Berührung zu kommen, niemals beruflich damit zu tun zu haben, niemals an fremden Projekten mitarbeiten oder davon partizipieren zu wollen - dann nimm das, was Dein Bruder macht. Ansonsten C. Aber vielleicht benutzt Dein bruder ja auch C ;-))
Auch wenn ihr mich jetzt alle gleich steinigen werdet... :-) Ich würde für den Einstieg lieber Assembler nehmen. Dann bekommt man am ehesten ein Gefühl dafür, was der Mikrocontroller wirklich tut und vermeidet später in C Horror-Konstrukte wie z.B.
1 | double x= 2/y; |
oldmax schrieb: > BASCOM ist, wenn man es von Grund auf lernen > muss, genauso schwierig, wie C, allerdings ist der Syntax leichter zu > verstehen. Wobei man dazu allerdings noch anmerken muß, dass die Entwicklungsumgebung von BASCOM noch einen recht umfangreichen Simulator enthält, der das Ganze für einen Einsteiger doch recht erleichtert. Auch finde ich die ganze Oberfläche von BASCOM in ihrem gesamten Konzept recht übersichtlich und einsteigerfreundlich. Nicht falsch verstehen aber bei einem Einsteiger liegt der Fokus ja nicht nur auf der Programmiersprache. Es geht ja auch um den Mikrocontroller, seinen Aufbau, um die Ansteuerung einer möglichen Peripherie und das ganze weitere Drumherum. Das wird z.B. durch die Simulationsmöglichkeiten im BASCOM sehr anschaulich und für einen Einsteiger nachvollziehbar dargestellt. Ich selbst habe in der Vergangenheit eigentlich fast die ganze AVR Programmierung mit dem WinAVR in C programmiert aber ehrlich gesagt, meine Wunschprogrammiersprache für eingebettete Umgebung ist Ada. Wer mal die Möglichkeit hat in diese Programmiersprache richtig einzusteigen, der packt einen C Compiler nur noch mit absolutem Widerwillen an und wirklich nur noch dann, wenn er unbedingt muß. Es gab zwar mal einen Versuch, Ada auf Atmel AVRs zu portieren aber da ist leider bislang noch nicht viel Brauchbares rausgekommen. Es fehlt einfach noch zuviel von der richtigen Ada Implementation. Gruß, Norbert
oldmax schrub: > Aber alles nur eine Kopfsache. In der Regel kann ich nur > sagen: die Sprache ist gar nicht so entscheidend. Wichtig ist denken zu > können, wie ein Controller. Stimme vollumfassend zu. Nicht nur die Sprache, auch die Compiler haben ihre Pro und Contra. Das muss man im Einzelfall cheken, aber für den Anfang ist das erst mal zweitrangig. Ich empfehle zu Hochsprachen auch immer sich Assembler zusätzlich anzuschauen. Nur bei Assembler hast Du die größtmögliche kontrolle. Bei Hochsprachen kann Dir auch mal der Compiler ein Bein stellen und so was rauszufinden ist eckliger als einen einfachen Programmierfehler auszubügeln.
oldmax schrieb: >... > In der Regel kann ich nur sagen: die Sprache ist gar nicht so > entscheidend. Wichtig ist denken zu können, wie ein Controller. Und da > wird die größte Schwierigkeit sein. >... Um der Arbeitsweise eines Controllers ziemlich nahe zu kommen, ist die Assemblersprache die Beste. http://www.avr-asm-download.de/beginner_de.pdf Bernd_Stein
Besser spät als nie: Für den Einstieg wurde das komplett kostenlose LunaAVR BASIC noch nicht genannt.
Klaus I, zu Deiner anfeindenden Nachricht, ich veröffentliche sie jetzt hier nicht, frage mal bei Richard (rgf) nach, dann siehst Du klarer. Du hast meinen Kommentar falsch verstanden und dadurch ist ein Missverständnis entstanden.
90% der Antworten bei solchen Fragen lauten immer: Nimm [x] weil das die Sprache ist die ich auch nehme. x=Assembler; Bascom; C; C++; sonstige Ansonsten mal ein paar spezifische Antworten: Wenn du schon erfahrungen im programieren hast, kannst du vieleicht die Sprache die du kennst für die µC Programierung verwenden. Wenn dir dein Bruder helfen kann ist seine Sprache sicher auch eine gute Wahl. Du hast Elektronikerfahrungen, solltest du keine Programiererfahrungen haben ist der Einstieg in Assembler am einfachsten. Willst du es später beruflich einsetzen, dann nimm C.
Uwe S. schrieb: > LunaAVR ist kein Basic! Selbst auf der LunaAVR-Homepage wird LunaAVR als "Basic-ähnliche Programmiersprache" bezeichnet. Die werden es ja wohl wissen.
Die Grenzen sind fließend, wie bei allen Sprachen (auch der gesprochenen). Das Beste oder das Schlechteste gibt es dabei nicht, nur das was einem gefällt oder was man beherrschen will. Milliarden Menschen sprechen chinesisch bzw. indisch, deswegen komme ich aber nicht auf die Idee morgen chinesisch oder indisch zu lernen. Olli Hannsen schrieb: > Uwe S. schrieb: >> LunaAVR ist kein Basic! > > Selbst auf der LunaAVR-Homepage wird LunaAVR als "Basic-ähnliche > Programmiersprache" bezeichnet. Die werden es ja wohl wissen. Pascal ist auch Basic-ähnlich und damit aber nicht automatisch ein Basic. Anhand des Sprachaufbaus denke ich ist das auch genau so gemeint, insofern ist der Einwurf weiter oben nicht unberechtigt.
Uwe S. schrieb: > Klaus I, > > zu Deiner anfeindenden Nachricht, ich veröffentliche sie jetzt hier > nicht, frage mal bei Richard (rgf) nach, dann siehst Du klarer. Sorry, das ich "Meine Fresse!" am Anfang und "Glück-Auf Kamerad!" am Ende geschrieben habe und dazwischen Dein Zeitmanagement in Zweifel gezogen habe. Auch der Satz mit "selber mal etwas produktives zu schaffen anstatt immer nur zu mosern" war wohl anfeindend. Ich gelobe Besserung. > Du hast meinen Kommentar falsch verstanden und dadurch ist ein > Missverständnis entstanden. Hier nur mal ein Beispiel für konstruktive Verhalten: Nicht nur vier Wörter hinwerfen, sondern vielleicht Erläutern was die "objektbasierte, moderne Basic/Pascal-ähnliche Programmiersprache" Luna in Deinen Augen ist. Nichts für ungut. Klaus
Ich würde empfehlen, wenn Du ausschließlich im Privaten Bereich bleibst BASCOM. Ist leicht und leserlich. Ansonsten C
Du wirst viel mit Hardware zu tun haben. Da macht es sich gut, wenn Du die hier verfügbaren Unterprogramme einfügen kannst. Ein LCD zu programmieren geht noch, mit einer lib geht es einfacher. Einen OneWire von Null an zu programmieren ist aufwendig. Lieber eine lib einsetzen. Auch wenn ich jetzt gesteinigt werde: Auch mal bei Arduino hereinschauen. Da gibt es auch sehr viele Beispiele (und auch viel Mist). Fazit: bei beidem ist es avr-gcc.
Ich bin ganz schön darüber erstaunt, dass hier so viele Leute ernsthaft BASCOM empfehlen. In Anbetracht der Tatsache, dass man sich damit abhängig von "BASCOM-AVR" macht, welches es nur in einer (veralteten) Demo-Version kostenlos gibt (und nur für Windows) halte ich das für die denkbar schlechteste Option. Überhaupt kommt man mit BASIC nicht besonders weit, sobald man seinen Horizont in Richtung ARM & Co. erweitern will. Dort ist nun einmal C Quasi-Standard. Ansonsten gibt es solche Beiträge immer wieder, daher verweise ich einfach mal auf [1] und zitiere mich selbst ;): Karol Babioch schrieb: > Da wird es wohl keine allgemeingültige Antwort geben. Jemand der > felsenfest davon überzeugt ist, dass Sprache X die einzig richtige Wahl > ist, hat wohl noch einiges zu lernen. > Wie bereits gesagt, schadet es auch nicht seine ersten Gehversuche > direkt mit Assembler zu machen. Dabei dürfte man wohl am Meisten über > die eigentliche Architektur lernen und ein Verständnis dafür entwickeln > wie ein solcher Mikrocontroller von "innen" funktioniert. Allerdings, so > ist zumindest meine Erfahrung, dauert das einfach viel länger bis man da > brauchbare Ergebnisse erzielt. Das kann mitunter ein wenig demotivieren. > Solltest du dich nun für C oder Assembler entscheiden, so findest du in > beiden Fällen brauchbare Tutorials im Wiki > (http://www.mikrocontroller.net/articles/AVR). [1]: Beitrag "Re: Einstieg in die µC Welt"
Karol Babioch schrieb: > Ich bin ganz schön darüber erstaunt, dass hier so viele Leute ernsthaft > BASCOM empfehlen. Ach komm, so schwierig ist es doch gar nicht. Wenn man Einsteiger ist und nur Hobby-Anwendungen im Focus hat, muß man sich doch nicht wirklich C antun. Das Problem mit C haben anscheindend viele Leute und deswegen kommen immer die Fragen nach einfachen Einsteigersprachen (und auch die anderen lustigen Fragen, mit einem C-Quelltext den sie nicht begacken bekommen). Wir wollen nicht alle ein richtiger C-Profi werden und lernen auch mit simplen Programmiersprachen genug. Ist doch super, dass man einzwischen einen z.B. Atmega8 auch einfach so programmieren kann. Bascom würde ich übrigens auch nicht empfehlen, ich bin jetzt nach ein paar Anfänger-Versuchen (inkl. C und Ada) bei LunaAVR gelandet. Für meine Anwendungszwecke ist das wirklich optimal. Aber ja, ich sehe auch die Gründe warum jemand C empfiehlt.
In Basic zu programmieren ist wie mit einem Dreirad zu fahren. Es erscheint vielleicht erstmal einfacher als ein richtiges Fahrrad, aber man kommt damit nicht weit. Als ich von Basic zu C umgestiegen bin, hab ichs bereut, dass ich mich solange mit Basic herumgeärgert hab, und nicht gleich mit C angefangen habe. C ist durchgängig, aus einem Guß, wenn man einige Regeln gelernt hat, kann man damit alles machen. Basic dagegen ist ein einfaches Grundgerüst, dem hier und da was angeflickt wurde und jedes Basic ist etwas anders.
Hi Ich wiederhole mich nur ungern, aber "programmieren" läuft im Kopf ab. Die Sprache ist nur das Werkzeug. Ein Anfänger hat mit jeder Sprache Probleme und jede Sprache hat Eigenheiten, die so leicht nicht erkennbar sind. Wer es von Grund auf gelernt hat, weiß darum und findet das auch nicht weiter schlimm. Wer al Quereinsteiger erste Gehversuche macht, ist froh jemanden an der Hand zu haben, der es bereits kann. Da ist es egal, welche Sprache der Bruder spricht, er ist die erste Wahl. Der Wunsch, eine weitere Sprache hinzu zu nehmen, kommt spätestens dann, wenn das bereits Erlernte für die Umsetzung von Projekten nicht mehr reicht. Klar, man muss sich einem anderen Syntax stellen, aber die Programmierung als solches, die Denkweise dazu, ist dann schon mal erlernt und die Compiler die ich kenne haben alle eine Hilfe integriert. Wenn's dann mal nicht gleich greifbar ist, in der Hilfe findet sich der entsprechende Hinweis. Außerdem: der TO scheint sich für's Schwimmbad und die Weiber entschieden zu haben, während wir noch einen (kleinen) Glaubenskrieg führen. Gruß oldmax
...es wurde Alles schon gesagt, nur von mir noch nicht :-) Für C spricht, das es für so gut wie jede Architektur verfügbar ist, wenn man also vo hat später auch mal einen anderen Prozessor zu verwenden als die AVRs, wie z.B. ARM oder MSP430, sollte man das berücksichtigen. BASCOM gibt es IMHO nur für AVR. Man muß nicht den kompletten Maschinenbefehlssatz kennen wie zwingend bei Assembler notwendig, aber es erspart nicht die Peripherie die sich schon innerhalb einer Architektur sehr stark unterscheiden kann, kennen zu müssen. Ich hacke hier derzeit auf einem MSP430 herum, das Hauptproblem dabei ist genau die "andere" Peripherie, der Prozessorkern eigentlich überhaupt nicht, nicht mal die Tatsache das die CPU 16bittig ist und nicht wie die kleinen Atmels 8bittig stört da, man hantiert auf Grund der 8 Bit breiten Peripherie sowieso meist nur mit Bytes oder logischen Größen. Die selbe Erfahrung hatte ich mit ATXMegas, kein wesentlicher Unterschied. Ich schaue mir aber gerne mal den Output des Compilers als Assemblerquelltext an, da kann man nebenbei lernen oder auch mal stutzig werden wenn der Compiler Sachen weg optimiert (vergessene volatiles). Ich programmiere auch auf dem PC in C, Intel Assembler kann ich aber genau genommen gar nicht (Diverse Microkontroller, 68K u.ä. aber schon) will ich aber auch nicht lernen (...gewisser Ekel vor Intel Architekturen) und hat mir auch noch nie gefehlt. Für 95% der Mikrokontrollerei braucht man auch kein Assembler, maximal für ein paar schnelle Interrupt Service Routinen und das habe ich in Verbindung mit C auch schon öfter genutzt. Von Basic halte ich Nichts, das wird ab einer bestimmten Größe immer unübersichtlicher Spaghettikram. Pascal ist heute eher unüblich und nicht auf allen interessanten Architekturen verfügbar. Interpreter halte ich auf Controllern für suboptimal, ein Laufzeitfehler der das Ding irgendwann anhält wenn man keine Console dran hat lauert immer. Die anderen "neuen" Sprachen .... naja, wenns schee macht...manchmal kann man sich interessant machen wenn man was obskures kann.. @oldmax: Du kennst Compiler mit integrierter Hilfe? Whow. Ich nicht. Ich kenne IDE's mit integrierter Hilfe, aber keine Compiler damit. Ich benutze keine IDE, es sei denn ich muß ein Projekt für einen Kunden auf eine solche "portieren", die Entwicklung mache ich aber unter Unix mit den dort üblichen Utilities, das ist um den Faktor 5-10 schneller.. Gruß, Holm
Holm Tiffe schrieb: > @oldmax: Du kennst Compiler mit integrierter Hilfe? Whow. Ich nicht. Ich schon:
1 | gcc --help |
SCNR ;-) duck & wech
Holm Tiffe schrieb: > Ich benutze keine IDE, es sei denn ich muß ein Projekt für einen Kunden > auf eine solche "portieren", die Entwicklung mache ich aber unter Unix > mit den dort üblichen Utilities, das ist um den Faktor 5-10 schneller.. Und den Faktor 5-10 hast du experimentell festgestellt? Wenn es, um Tools und Workflow geht, dann fahre ich eigentlich nach dem Motto "Jedem das Seine", aber wenn jemand wirklich allen Ernstes behauptet, dass man mit einer IDE langsamer arbeitet, als mit einem Texteditor, dann gehen bei mir die Alarmglocken los. Und das obwohl ich selbst nicht unbedingt der größte Fan von IDEs bin - zumindest nicht für Anfänger. Das ist nur unnötiger Overhead, der eigene Fehlerquellen mitbringt. Außerdem kann es am Anfang nicht schaden zu wissen bzw. zu lernen was nachher im Hintergrund so alles passiert - völlig automatisiert. Des Weiteren gibt es (komplexe) Projekte (und Programmiersprachen), welche den Rahmen, den man mit einfachen Texteditoren & Co. sinnvoll überschauen kann, sprengen. Wieso sollte ich auf Funktionen wie Autovervollständigung verzichten. Gerade, wenn ich viele Klassen habe, und die Namen der einzelnen Methoden bzw. Membervariablen nicht mehr genau im Kopf habe, ist das durchaus von Vorteil. Auch das automatische Einbinden von benötigten Ressourcen ist sicherlich kein Nachteil. Überhaupt bieten moderne IDEs ziemlich viel für die meisten Entwickler praktische Dinge an. Mit freundlichen Grüßen, Karol Babioch
Habibi schrieb: > Meine > bisherigen Projekte mit AVRs wurden aber von meinem Bruder Programmiert. > > [...] > > Ich würde mir eine Sprache aussuchen zu der es viele Anfänger-Tutorials > gibt, und in die man nicht viel Investieren muss (Programmiersoftware). Frag Deinen Bruder. Nicht bei jeder Kleinigkeit, aber welche Sprache er benutzt. Der Vorteil, ein Problem mit einer Person von Angesicht zu Angesicht diskutieren zu können ist viel wert.
Man sollte ruhig mal das Stündchen investieren und das erste Progrämmchen in BASIC (Bascom) schreiben. Schon allein um zu sehen, wie weit man damit kommt. So habe ich es gemacht und es blieb dann auch das letzte BASIC-Programm auf dem AVR.
Hi Sorry für den Compiler... klar ist es die IDE, aber oft sind sie so eng beieinander... und letztlich reden wir hier von C, Bascom, Assembler und was sonst noch. Und da ist die Hilfe auf jeden Fall drin. Aber wem hilft das jetzt. Den TO scheint es nicht mehr zu interessieren. Schwimmbad ist halt doch interessanter. Grußldmax
batman schrieb: > Man sollte ruhig mal das Stündchen investieren und das erste > Progrämmchen in BASIC (Bascom) schreiben. Zu was gibt es denn bessere Informationsquellen und Tutorials? Basic oder C? C ist Industriestandard, deswegen verwende ich persönlich diese Hochsprache, und komme damit reichlich für alle Aufgaben zurecht. Angefangen habe ich mal mit Basic und C64. Basic war gratis verfügbar, andere Compiler nicht. Später auf dem ersten richtigen PC (486DX2) war MSDOS 5.0 drauf, das hatte auch noch einen Basic-Interpreter. Der war immerhin gratis, und die interpretierten Programme liefen darauf eben so schnell wie Compiler. Ein wenig Assembler, um ein Gefühl für die Maschine und Geschwindigkeiten zu bekommen, schadet auch nicht. Der wird aber bei größeren Berechnungen sehr mühsam gegenüber einer Hochsprache. Eine gute komfortable nicht zu komplizierte und von allen Dingen recht unabhängige IDE ist Geany, die ich zusammen mit SDCC verwende.
Jobst Quis schrieb: > In Basic zu programmieren ist wie mit einem Dreirad zu fahren. Es > erscheint vielleicht erstmal einfacher als ein richtiges Fahrrad, aber > man kommt damit nicht weit. Mein Kommentar dazu : Es kann schon sein, daß C oder Assembler besser oder mächtiger sind. ich denke es kommt drauf an, was man als Bastelobjekt machen will. Bisher gab es bei meinem AVR Projekten nichts, was ich mit Bascom nicht lösen konnte. Von meiner Seite aus kann ich sagen, ( habe mir BASCOM selber beigebracht) alle Projekte, die ich bauen wollte, habe ich gebaut und funktionierten von Anfang an ohne grosse Probleme.Ob man es mit C besser machen könnte, interessiert mich nicht am geringsten oder ob durch unschöne Programmierung 47% von Flash verbratet wird anstatt 35 % das ist doch mir jucke. Selbst nach ca 1 Jahr oder etwas mehr mit Bascom, ist für mich ein C Code "unleserlich". smile... If S1=0 then Led=1 End if sowas kann jeder lesen, der nicht programmieren kann.Aber ich will keinen Glaubenskrieg anzetteln.
Hi >Selbst nach ca 1 Jahr oder etwas mehr mit Bascom, ist für mich ein C >Code "unleserlich". Na ja, BASCOM scheint dir auch noch recht fremd zu sein: http://www.mikrocontroller.net/topic/301132#new MfG Spess
Spess, damit Du schon herumhacken kannst... Code angepasst, war suboptimal...jetzt läuft sehe aber nicht ein es zu posten.
@Thomas >Spess, damit Du schon herumhacken kannst... >Code angepasst, war suboptimal...jetzt läuft sehe aber nicht ein es zu >posten. Das ist aber nicht gut. Da wäre nichts Ehrenrühriges dabei -viele Andere haben in der Codesammlung auch schon neuere (bessere) Varianten ihrer Programme gepostet. Wenn Du eine bessere Variante Deines Programmes erstellt hast, warum behältst Du diese dann für Dich? Dann brauchst Du auch gar keinen Quelltext mehr einstellen.... Zu der Sprache C verweise ich auf unzählige Artikel hier, wo es sich herauskristallisiert, daß der Quelltext sich nur mit Axt und Wagenheber übersetzen läßt. Was nützt es, wenn man den Algorithmus des Programmes in Sekundenbruchteilen in die Kiste wämmert, aber dann Tage braucht, um dem Kompiler den Quelltext schmackhaft zu machen? MfG Paul
Thomas der Bastler schrieb: > jetzt läuft sehe aber nicht ein es zu posten. Ganz im Sinne eines Forums. Erst mal falschen Code posten und dann nicht mal die Eier in der Hose haben dies einzugestehen. Und dann noch von "programmieren" sprechen. Echt ulkig...
Paul Baumann schrieb: > Zu der Sprache C verweise ich auf unzählige Artikel hier, wo es sich > herauskristallisiert, daß der Quelltext sich nur mit Axt und Wagenheber > übersetzen läßt. Was nützt es, wenn man den Algorithmus des Programmes > in Sekundenbruchteilen in die Kiste wämmert, aber dann Tage braucht, um > dem Kompiler den Quelltext schmackhaft zu machen? Im privaten Bereich stimme ich dir vollkommen zu. Wenn man (gerade als Anfänger) nicht weiß auf was dass man achten muss bzw. wo es Tücken gibt, gibt es bestimmt bessere Sprachen um an ein einfaches Ziel zu kommen. Ob jetzt ein paar Byte mehr Flash/RAM belegt werden oder das Ganze etwas langsamer ist, spielt im Normalfall keine Rolle. Auch ob für jeden Controller ein passender Compiler vorhanden ist, ist in diesem Fall zweitranging. Wenn es aber darum geht Brötchen zu verdienen spielen Flash/RAM/Compiler eine sehr große Rolle! Gerade bei Automobilern oder im Consumerbereich wo teilweise der Cent im Nachkommabereich umgedreht wird! Hier versucht man Resourcen und damit Geld einzusparen. Auch muss man Überlegungen anstellen was passiert, wenn ein Controller abgekündigt wird. Wenn man sauber programmiert und einen Hardware Abstraction Layer einzieht ist der wechsel auf einen anderen Controller meist relativ schnell erledigt. Was passiert allerding wenn für den neuen Controller kein passender Compiler vorhanden ist? Dann kann ich von Null anfangen! Dann muss ich meine komplette Qualifizierung von vorne anfangen und in Zukunft auch zwei Firmware pflegen. Das macht einen RIESEN Unterschied :-) So, bis jetzt bin ich komplett ohne eine Erwähnung einer speziellen Sprache ausgekommen. Meine Empfehlung (und so ist sie auch zu nehmen, also ein reiner Vorschlag! Kein muss, Kein gepoche auf "Ich habe aber Recht) ist dass man es sich im Privaten (solange es Resourcen, sei es Flash/RAM/Timings) natürlich so einfach wie möglich machen sollte. Und da gibt es leichteres als C/C++. WENN man allerding beruflich damit zu tun hat (und da meine ich nicht nur eine PWM ansteuern und ne LED dimmen), dann sollte man definitiv auf C oder wenn die Komplexität zunimmt auf C++ (auch im Embeddedbereich) setzen! Grüße Babbel (Der jeden Tag in C/C++ beruflich programmieren darf)
Thomas der Bastler schrieb: > Spess, damit Du schon herumhacken kannst... > Code angepasst, war suboptimal...jetzt läuft sehe aber nicht ein es zu > posten. Da brauchst Du Dich doch hier nicht rechtfertigen. Es gibt hier genügend Posts bezüglich C, wo man nachlesen kann wie es Einsteigern damit ergeht. Jeder der das nicht erkennen kann/will darf mich gerne Automatik-Fahrer schimpfen :oD Ich wollte Dich eigentlich nur fragen, warum Du Dich für Bascom entschieden hast und nicht für Luna? Wurde es da noch zu oft akutalisiert oder gabe es Luna da noch gar nicht? Wie ich oben schonmal geschrieben habe, habe ich mal simple Anfänger-Schaltungen in den verbreiteten Sprachen durchprobiert und bin bei LunaAVR hängengeblieben. Da gab es wirklich noch Kinderkrankheiten (auch heute wird man da noch Fehler entdecken), andererseits ist es so wie bei Purebasic interessant die Entwicklung einer neuen Sprache mitzuerleben.
Babbel schrieb: > So, bis jetzt bin ich komplett ohne eine Erwähnung einer speziellen > Sprache ausgekommen. > Meine Empfehlung (und so ist sie auch zu nehmen, also ein reiner > Vorschlag! Kein muss, Kein gepoche auf "Ich habe aber Recht) ist dass > man es sich im Privaten (solange es Resourcen, sei es Flash/RAM/Timings) > natürlich so einfach wie möglich machen sollte. Und da gibt es > leichteres als C/C++. > > WENN man allerding beruflich damit zu tun hat (und da meine ich nicht > nur eine PWM ansteuern und ne LED dimmen), dann sollte man definitiv auf > C oder wenn die Komplexität zunimmt auf C++ (auch im Embeddedbereich) > setzen! So, dass ist doch mal ein Wort!
Thomas der Bastler schrieb: > Spess, damit Du schon herumhacken kannst... > Code angepasst, war suboptimal...jetzt läuft sehe aber nicht ein es zu > posten. Ist auch zu spät. In der dortigen Version hat es ganz sicher nichts in der Codesammlung verloren. Ich habs mal rausgeschossen. Wenn du nachbessern willst, dann sag Bescheid (hier in diesem Thread), dann mach ich die Löschung rückgängig. Aber so wie das gepostet wurde, ist das kein Programm für die Codesammlung. Wenigstens funktionieren sollte es schon.
Der Kommentar war übrigens Antwort Nr. 42.
C ist mächtig und damit in der Hand eines Anfängers auch sehr gefährlich! Wie ein Rasiermesser. Einmal verkantet, AUTSCH! BASIC ist da, trotz anderer Macken, deutlich genügsamer und sicherer. Und schließschließlich braucht der Mensch auch Lernerfolge! Nur die Freaks wühlen sich erst wochenlang duch knochentrockene Assemblergrundlagen, um dann mal ein paar LEDs blinken zu lassen, von LCD, UART & Co ganzt zu schweigen! Pascal ist sauberer als C und BASIC, aber leider nicht wirklich mehr aktuell :-( Das wäre auch eine gute Einsteigersprache. Schlechte Programme mit Spaghetticode kann man in jeder Sprache produzieren.
@Karol: Die Entwicklung "einfacher Texteditoren" ist scheinbar nicht an dem Punkt stehengeblieben and dem Du das letzte mal damit zu tun hattest.(Edit unter DOS?) Du mußt nicht so arbeiten wie ich, aber Alarmglocken mußt Du gleich gar nicht anmachen.. Die Ursache für die enorme Beschleunigung ist das gleichzeitig mögliche offen lassen von Editor, Manual Seite, Webbrowser Debugger und Build-Fenster unter einer Art Console Multiplexer genannt X11. Ich werde mit der Klickerei im AVR Studio wahnsinnig eher die Kiste mal das macht was ich von ihr will und ab Version 5 ist das nur viel schlimmer geworden. Unix und das Make System automatisiert viele Vorgänge, mir gefällt diese Arbeitsweise nun mal deutlich besser als Klickibunti mit Werbung. (Unix ist ein OS von Programmierern für Programmierer und an dieser Stelle spielt es schonungslos seine Stärken gegen Hausfrauensysteme mit NSA Anbindung aus) Ich habe auch Eclipse hier laufen und auch das CCS von TI mal installiert (auch Eclipse) ... ist nicht mein Ding. Allen Oberflächen gemeinsam ist, das sie den Compiler als Kommandozeile rufen, das kann ich aber auch. Klar gibts u.U Gimmiks die interessant sind, aber die wiegen die Nachteile (für mich) nicht auf. @Yalu: blos gut das Du geduckt bist :-) Ansonsten stimme ich explizit Falk zu. Mit Basic erziehlt man realtiv schnell Erfolge, aber auf längere Sicht endet das IMHO in einer Sackgasse, zumal wenn man die Arbeit Anderer (also z.B. auch die der Foristen hier) nutzen will und das auch darf. Gruß, Holm
Holm Tiffe schrieb: > @Karol: Die Entwicklung "einfacher Texteditoren" ist scheinbar nicht an > dem Punkt stehengeblieben and dem Du das letzte mal damit zu tun > hattest.(Edit unter DOS?) Du kannst mir glauben, dass vim & Co. mein täglich Brot sind. Holm Tiffe schrieb: > Ich werde mit der Klickerei im AVR Studio wahnsinnig eher die Kiste mal > das macht was ich von ihr will und ab Version 5 ist das nur viel > schlimmer geworden. Vom AVR Studio an sich halte ich auch absolut nichts (allein schon wegen der Lizenz bzw. dem darunterliegenden MS Kram). Allerdings kann ich mir gut vorstellen, dass jemand, der es regelmäßig benutzt, mindestens genauso schnell ist, wie du mit deinen vielen Anwendungen bzw. Fenstern zwischen denen du wechseln musst. Holm Tiffe schrieb: > Unix und das Make System automatisiert viele > Vorgänge, mir gefällt diese Arbeitsweise nun mal deutlich besser als > Klickibunti mit Werbung. Inwiefern das Ganze jetzt etwas mit Unix bzw. dem darunterliegenden Betriebssystem zu tun hat, sehe ich nicht wirklich. "Texteditor vs. IDE" hat zunächst einmal nichts mit "Windows vs. Unix/Linux" zu tun. "Klickibunti mit Werbung" gibt es übrigens auch in der Unix-Welt. Nennt sich dort Ubuntu ;). Holm Tiffe schrieb: > ... ist nicht mein Ding Und das ist auch voll und ganz in Ordnung. Sobald du aber prinzipiell alle IDEs schlecht machst, geht es zu weit. Letztendlich muss doch jeder für sich selbst entscheiden, wie er entwickeln möchte. Holm Tiffe schrieb: > Klar gibts u.U Gimmiks die interessant sind, aber die wiegen die > Nachteile (für mich) nicht auf. Hast du denn schon einmal an größeren objektorientierten Projekten gearbeitet? Falk Brunner schrieb: > C ist mächtig und damit in der Hand eines Anfängers auch sehr > gefährlich! Klar, aber was ist denn das schlimmste das bei einem Hobbyprojekt passieren kann? Dass es nicht funktioniert, und man sich hier ans Forum wendet? Damit kann ich leben ;). Falk Brunner schrieb: > Schlechte Programme mit Spaghetticode kann man in jeder Sprache > produzieren. Das stimmt definitiv ;). Thomas der Bastler schrieb: > Selbst nach ca 1 Jahr oder etwas mehr mit Bascom, ist für mich ein C > Code "unleserlich". Das ist aber einfach nur "Gewöhnungssache". Ich persönlich habe eigentlich schon immer mit C (bzw. darauf basierenden Sprachen) zu tun gehabt, und kann diese daher bei Weitem besser "lesen" als z.B. BASCOM. Ich denke aber, dass hier ein gewisser Konsens darüber herrscht, dass man mit C weiterkommt, gerade wenn man nachher auch andere Controller(familien) programmieren möchte - unabhängig davon, was nun "einfacher" ist. Für mich wäre das Grund genug mich für C zu entscheiden ;). Allerdings schadet ein Ausflug in die Welt der Alternativen sicherlich auch nicht ... Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Ich denke aber, dass hier ein gewisser Konsens darüber herrscht, dass > man mit C weiterkommt, gerade wenn man nachher auch andere > Controller(familien) programmieren möchte - unabhängig davon, was nun > "einfacher" ist. Für mich wäre das Grund genug mich für C zu entscheiden Das ist der Anspruch, den man in seine Projekte hat. Wenn man bei AVR bleiben will, dann ist das kein Thema. Kennt eigentlich noch jemand das AVR-Basic? Das ist ganz schnell gestorben, als BASCOM erschien. Eigentlich ist es doch wurscht, was in einem MC drin steht. Hauptsache ist, das es macht was es soll. C ist und war die Sprache der Profis. Aber alles ist relativ. Ich hab hier ein "Standard-BASIC" für die späteren DDR-PC. Da wackeln die Ohren was das kann, also keine abgespeckte Version.
@Karol Babioch (johnpatcher) >> C ist mächtig und damit in der Hand eines Anfängers auch sehr >> gefährlich! >Klar, aber was ist denn das schlimmste das bei einem Hobbyprojekt >passieren kann? Dass es nicht funktioniert, und man sich hier ans Forum >wendet? Damit kann ich leben ;). Falsch, dass man tage und wochenlang immer wider über 1001 nebensächliche Fehlerstolpert. Denk mal an deine ersten Programmierversuche zurück! Lief da alles wie geschmiert?
@Karol: Ja ich galube Dir das VIM & CO Dein tägliches Brot sind, ich frage mich dann aber doch warum Du damit ineffektiver arbeitest als mit Visual Studio z.B... Es bleibt doch nicht beim Editor, es geht weiter über Sachen wie grep oder cvs. Ich schrieb das ich damit schneller bin und damit besser zurecht komme als mit dem Klickibunti Kram, laß es doch dabei.. Hier läuft übrigens kein Ubuntu, nicht mal Linux. Nichts desto trotz habe ich die kompletten Sourcen und kann auch das OS neu bauen, gänzlich ohne IDE. @Michael_: Ich weiß was das "Standardbasic" nicht kann, es kann nicht mit den seriellen Schnittstellen des A7150.. Die Doku habe ich irgendwo auf meiner Webseite. Gruß, Holm
Ich verwende mittlerweile fast ausschließlich C. Ich kann damit eine Datenbank schreiben die schnelle Ergebnisse aus 1 TB unter Win liefert oder mit einem uC herumspielen. Oder Webseiten bauen oder mal ein OS schreiben. Da kommt Basic schon an seine Grenzen ;) Wie weiter oben schon gesagt: Programmiert wird im Kopf, die Programmiersprache ist da nur ein Werkzeug. Es muß aber auch überall funktionieren wo ich es brauche.
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.