Guten morgen, gerade habe ich mein myAVR Board (Das mit dem LPT Anschluß) fertig zusammengelötet und ein wenig die einzelnen Beispiele probiert. So, während es am Anfang überhaupt nicht geklappt hat, habe ich nun über Google, Eclipse AVR, gedit und dem ersten selbstgeschriebenen Make-File in Ubuntu 10.04 schon div. Beispiele hier aus der Codesammlung und von einigen Seiten im Internet übersetzt und auf dem Board eingespielt. Dabei bin ich immer wieder auf Programme gestoßen, die nicht laufen, obwohl der Compiler keine Fehler meldet. Auch die Sache mit den Sicherungen (oder sind die FUSES im AVR keine Sicherungen ?) habe ich hier mal als Suchwort eingegeben und da kam ja eine Menge raus, dass man falsch machen kann. Wenn ich z.B. so einen I2C Entfernungsmesser von Robotikhardware den wir für die Schule auslesen sollen und die Entfernung über die USART Schnittstelle ausgeben sollen, auslesen will. Wie fange ich die Sache an ? #define am Anfang vom Quelltext ist schon klar und auch das irgendwo dann mal void main (void) kommt. Wir sind zwar noch bei den Basics wie Datenregister und so und aber am Ende vom Schuljahr hat unser Dozent in der Berufschule gesagt, dass wir den I2C Bus drin haben wollen / sollen. Irgendwie erschlägt mich das Tutorial mit speziellen Sachen wie Timer laden, ADC einstellen und so Sachen. Aber wie fange ich ein Programm an ? Welche Überlegungen muß ich anstellen um dann z.B. irgendwann so Sachen #include <lcd.c> #include <lcd.h> zu benutzen und ab wann brauche ich solche "ausgelagerten Funktionen" (Nicht hauen, habe ich irgendwo gelesen.)? Entweder ist es weil ich schon seit 16 Uhr mit dem myAVR spiele und Teste oder ich habe da ein grundlegendes Problem der Planung und des Verständnis. Helft mir da mal bitte auf den Pfad, dass ich irgendwann mal "normgerecht" also für jeden von euch hier verständlich, Programme machen kann. Die nächste Woche soll laut Amazon der Kerningham Richie, der hier so oft als "Bibel für C" genannt wird kommen. Incl. dem Übungsbuch. Bis dahin will ich aber soweit schon mal wissen, wie ich das C dann für den ATmega8 benutzen soll. Jürgen
Gestern zusammen gelötet und Heute willst du schon programmieren können? Wow. Soll ja Wunderkinder geben, die schon nach ein paar Wochen programmieren können - aber nach einen Tag? Einfach mit irgendwelchen übersichtlichen Beispielen anfangen. Mit der Zeit kommt Routine und dann siehst du auch, wie du komplexe Aufgaben aus diesen Einzelteilen zusammensetzt. Diese Verwirrung am Anfang ist ganz normal. Nicht irritieren lassen.
Ich denke, vor allem muß man sich von der Vorstellung verabschieden, daß man sich etwas zusammenkopiert, laufen lässt und davon einen Erkenntnisgewinn hat. Natürlich erleichtert es den Einstieg enorm, wenn man zumindest ein lauffähiges Beispiel irgendwoher hat und damit etwas blinken lassen kann. Aber das ändert nichts daran, daß ein Verständnis für die Materie erst mit einiger Zeit und viel Mühe kommt. Solange du am Tutorial scheiterst, brauchst du auch keine eigenen tollen Projekte anfangen - mit denen wirst du auch scheitern. Bestenfalls erfreust du hier noch Sadisten wie mich, indem du eine peinliche Fragestunde über elementarste Grundlagen ablieferst, die vom allgemeinen Unterhaltungswert abgesehen vollkommen sinnlos ist. Wenn du also wirklich mit Mikrocontrollern warm werden willst, musst du dich durchbeißen: lesen, probieren, Fehler suchen, probieren, lesen... Wenn es wirklich hakt, ist es sicher gut zu fragen. Aber das hat keinen Sinn, solange man nicht selbst Zeit investiert. Damit würde man sich hier nur wie viele andere zum Narren machen. Wenn man aber wirklich sich auf die Materie einlässt und nach Wegen sucht, wird einem hier sicher gerne weiter geholfen. Also viel Spaß! Schüler und AVRNeuling schrieb: > Die nächste Woche soll laut Amazon der Kerningham Richie, der hier so > oft als "Bibel für C" genannt wird kommen. Incl. dem Übungsbuch. Das ist sicher sinnvoll. Allerdings lernt man die Grundlagen damit wesentlich leichter erstmal am PC. Da ist vieles einfacher, aber immer noch schwer genug. Schüler und AVRNeuling schrieb: > Aber wie fange ich ein Programm an ? Typischerweise mit einem Primitivstprogram wie "Hello World". Und von dort aus dann mühsam vortasten... Schüler und AVRNeuling schrieb: > Dabei bin ich immer wieder auf Programme gestoßen, die nicht laufen, > obwohl der Compiler keine Fehler meldet. Damit ein Programm sinnvoll läuft, ist fehlerfreies Übersetzen eine notwendige Bedingung, aber keine hinreichende. Schüler und AVRNeuling schrieb: > Irgendwie erschlägt mich das Tutorial mit speziellen Sachen wie Timer > laden, ADC einstellen und so Sachen. Im Tutorial stehen eigentlich (fast) nur Sachen, die man wirklich dauernd braucht. Nicht alles gleich, insofern kann man auch etwas auslassen. Aber irgendwann dann komischerweise doch... Schüler und AVRNeuling schrieb: > #define am Anfang vom Quelltext ist schon klar Wirklich? In den meisten Programmen fange ich NICHT mit einem #define an. Wozu auch? Schüler und AVRNeuling schrieb: > Entweder ist es weil ich schon seit 16 Uhr mit dem myAVR spiele und > Teste oder ich habe da ein grundlegendes Problem der Planung und des > Verständnis. Ein paar Stunden sind doch gar nichts :-)
@ Kein Name (Gast) : Bist du der bisherige Noname? :-) Sehe ich genauso, du hast es nur kompakter formuliert.
Schon seit 16Uhr....das ist nicht wirklich lange :-) Versuch als erstes zu verstehen, wie so ein Mikrocontroller überhaupt funktioniert. Die grundlegenden Sachen wie Befehlsabarbeitung, Datenmanipulation, Speicherbereiche und I/O-Ports. Dann kannst du dir die zusätzlichen Peripherieeinheiten wie Kommunikation, Timer und A/D-Wandler reinziehen. Stück für Stück. Erst weitermachen, wenn du einen Teil verstanden hast. Ein C-Buch nutzt dir nicht wirklich viel, wenn du nicht verstehst, was tatsächlich passiert. Nach wenigen Stunden kannst du dann eine LED blinken lassen oder an ein Terminalprogramm "Hello world" schicken. Der Rest kommt dann, wenn du dran bleibst, von alleine.
step by step, das Tutorial hier im Forum durcharbeiten und dann das C Buch.
Evtl. fällt dir der Einstieg mit Bascom etwas leichter, ist aber hier etwas verpönt.. Mir passts jedenfalls.
@ Klaus Wachtler >@ Kein Name (Gast) : >Bist du der bisherige Noname? :-) >Sehe ich genauso, du hast es nur kompakter formuliert. Nein. Ist er nicht. Aber ich sehe es genauso wie ihr. Der TO erinnert mich an meine Anfangszeit (vor gut 30 Jahren). Ein Wahnsinns Wust an Details, die sich nach ein paar Tagen, immer_ _noch nicht :-) zu einem Ganzen fügen wollte. Dann eine konkrete Aufgabe. Irgendwie hat man von allem schonmal gehört und gelesen. Aber wenn man das selbst machen muss? Wie verbinde ich diese Teile? Wie zeichne ich einen Kreis. Bewege ein Sprite (C64). Das zergliedernde und synthetische Denken (lernen). Na gut. Ich denke das lag und liegt mir. Und immer wieder ein schier unüberwindlich scheinender Berg an Details. USART geht nicht. Nach ein paar Tagen: Ach wie blöd. Parity war falsch. Interrupt will nicht: Falscher Vektor. Falsche Taste erkannt: Falsche boolsche Verknüpfungen. Und das noch und das noch und das noch, etcpp. Und Checksummen und Pull-Ups. Und immer wieder denselben Quelltext gelesen bis es mal Klick macht. Na gut. Wertestarrheit: Das muss doch aber gehen! Wieso geht das nicht? Aber ich las schon immer gerne Science Fiction. Maschinen, Raumschiffe, Computer. Das lag mir. Hoffe es geht dem TO auch so. Wenn es Dich wirklich fasziniert dann wühlst Du Dich durch und das die Nächte durch. Wenn Du es nur lernen musst, weil es zum Unterricht gehört, dann wird es mühsam. Du solltest das Tutorial durcharbeiten. Am besten parallel zum C Buch. Meine Meinung. Also: Viel Spass und viel Erfolg.
Danke für die Ermutigung. Ich habe schon gedacht, bei mir wäre Irgendwas zurückgeblieben und ich würde einfache Sachen nicht verstehen ... Die div. "Hello World !" Beispiele, mal mit einfach nur LED ein, for Schleife und LED aus sowie die schon komplexeren mit delay und so (Bei der Recherche zu diesem _delay_ms(ms) habe ich zum ersten Mal den Sinn der Fuses halbwegs kapiert ... (Google sei Dank und einem gewissen Mr. Pascal Stang von der Stanford Uni). Auch die Sachen mit dem DDR und die Unterschiede zwischen PIN und PORT habe ich nun soweit kapiert. Was ich aber noch nicht so richtig nachvollziehen kann ist die Vielfalt an Befehlen in C für ein und die dieselbe Sache. Warum heißt es einmal pin_is_set(), dann PIN und in einem anderen Beispiel dann if PORT ... ? PIN und PORT kriege ich vielleicht noch hin, weil einmal eine 8 Bit Integer für PORT zum Vergleich genommen wird und bei PIN nur ein PIN beschrieben ist. Warum schreibt man aber pin_is_set() ? So, nun lege ich mich aber mal wieder auf’s Ohr. Habe nur ein paar Stunden geschlafen und seit etwa 5 Uhr wieder am PC mit dem myAVR Board "gekämpft". Jürgen
Schüler und AVRNeuling schrieb: > Warum schreibt man aber pin_is_set() ? Einfach, weil es jemandem besser gefallen hat als die hier sonst übliche Bitfummelei mit Schieben und Maskieren. Du kannst es ebenso machen, oder dir etwas anderes angewöhnen. Bei MC-Programmierung muß man halt oft gezielt prüfen, ob ein bestimmtes Bit in einem Wert gesetzt ist oder man möchte so ein Bit setzen oder löschen. Ob man das jetzt direkt mit C-Operatoren macht ( if( wert & ( 1 << 5 ) )... oder if( wert & 0b00100000 ... ) oder sich dieses hässliche Gefummel in eine Funktion packt, ist weitgehend Geschmackssache. Je nach Fall kann das eine oder das andere sinnvoll sein. (Ich tendiere meistens eher weniger zum Einen noch zum Andere, sondern zu Bitfeldern.) Wie du es irgendwann mal machst, bleibt dir überlassen. Eine Meinung dazu kannst du aber erst haben, wenn du mehrere Varianten probiert hast. Ein Vorschlag für eine Übung, der HW-seitig sehr einfach ist und den ich aber noch nie in freier Wildbahn gesehen habe: Du kannst doch mal "Hallo Welt" oder sowas mit einer LED als Morsecode ausgeben. Das ist eigentlich nicht schwer, aber man kann viel darüber sinnieren, wie man ein Programm halbwegs elegant aufbaut.
Klaus Wachtler schrieb: > Ob man das jetzt direkt mit C-Operatoren macht ( if( wert & ( 1 << 5 ) > )... oder if( wert & 0b00100000 ... ) oder sich dieses hässliche > Gefummel in eine Funktion packt, ist weitgehend Geschmackssache. Das ist sicher nicht nur Geschmackssache, sondern hängt ganz entscheidend von den Anforderungen ab. Die direkte Kodierung mit Werten ist sicher das Übelste, was man machen kann. Spätestens nach drei Tagen weiß man nicht mehr, wie die Werte vom Himmel gefallen sind. Wehe man möchte später irgendwelche Änderungen am Code machen und sei es nur, dass man eine I/O-Funktion auf einen anderen Pin legen möchte. Das sollten wegen des besseren Wartbarkeit des Codes also mindestens Konstanten sein, die über #define an zentraler Stelle definiert werden. Ein echter Funktionsaufruf erzeugt wesentlich mehr Overhead, d.h. wenn die Geschwindigkeit wichtig ist, wird man das bei solchen elementaren Operationen besser lassen. Hier sind oft Makros sehr praktisch, die z.B. die Operation wie einen Funktionsaufruf aussehen lassen und tatsächlich einen kompakten oder schnellen Code erzeugen. Und dann optimiert der Compiler je nach Einstellungen noch viele Dinge, so dass es oft auch gut ist, im List-File nachzusehen, welcher Assembler-Code aus dem C-Code erzeugt worden ist.
Klaus Wachtler schrieb: > Ein Vorschlag für eine Übung, der HW-seitig sehr einfach ist und den ich > aber noch nie in freier Wildbahn gesehen habe: > Du kannst doch mal "Hallo Welt" oder sowas mit einer LED als Morsecode > ausgeben. > Das ist eigentlich nicht schwer, aber man kann viel darüber sinnieren, > wie man ein Programm halbwegs elegant aufbaut. Das liest sich interessant ... Den Morsecode habe ich nun aus Google mal als Tabelle ausgedruckt. Die Sache mit den PIN, PORT und bit_is_set() Definitionen habe ich, so glaube ich, auch kapiert. Das hängt wohl auch noch von dem Alter der avrlibc ab. Irgendwo im AVR GCC Tutorial gibt es ein Kapitel, wo veraltete Aufrufe und Funktionen genannt werden. Mit Google habe ich da noch ein paar Stellen im Netz gefunden, wo Änderungen in der avrlibc aufgeführt sind. Danach werde ich mir wohl angewöhnen müssen Ausgänge mit PORTB |= (1<<PB2); (Als Beispiel) zu setzen und mit PORTB &= ~(1<<PB2); (Als Beispiel) zurückzusetzen. Für die Abfrage dann eben statt bit_is_set() if (PORTB &= ~(1<<PB2);) ... usw. Das scheint die gängige Definition in der neuesten avrLibc zu sein, die ich wohl mit #include <avr/io.h> am Anfang meines Programmes einbinden muss. Um auf den "Hallo Welt" Vorschlag von Klaus Wachtler zurückzukommen ... Das ist ja nach kurzem Nachdenken gar nicht so einfach ... Eine LED An- und Auszuschalten ist leicht. Nur die Pausen und die 2 verschiedenen Zeiten für Strich und Punkt (lang und kurz) für jeden Teil eines Buchstaben und die Pause zwischen den Buchstaben ... Als Anfänger, der ich bin wird Das eine Menge for-next Schleifen oder das Programm besteht fast 50:50 aus PORT und _delayms(ms) Anweisungen. Es sei denn, ich finde nächste Woche beim Lesen des Kerningham Richie eine Möglichkeit, wie man Datenbausteine in C anlegt und dann einen Zeiger auf die einzelnen Datenwörter im Datenbaustein definiert, der nach und nach zwei for - next Schleifen einmal mit der Zeigerposition bedient und einmal den Zeitwert aus dem Datenwort ablaufen lässt. (Da sind wir in der Berufsschule dran. Indirekte Adressierung mit Step/7, deshalb "protze" ich hier so rum damit.) Ich werde mich da mal ein wenig mehr mit beschäftigen ... Klingt wirklich interessant. Jürgen
Schüler und AVRNeuling schrieb: > Die Sache mit den PIN, PORT und bit_is_set() Definitionen habe ich, so > glaube ich, auch kapiert. Das hängt wohl auch noch von dem Alter der > avrlibc ab. Ich denke, dieser Aussage kann man zustimmen. Der springende Punkt ist der, dass es für solche Pinabfragen direkt am µC spezielle Assembler-Instruktionen gibt, die besonders schnell ablaufen. Die wollte man in C auch verfügbar machen. Schrieb man die kanonische C-Lösung, so waren frühere Compilerversionen nicht soweit, dass sie diese Abfragen auf diese speziellen Instruktionen optimieren konnten. Also hat man eben scshweren Herzens dafür spezielle 'Funktionen' eingeführt, in denen man dem Compiler etwas half. Spätere Compilerversionen schafften aber dann diese Optimiereungen von sich aus, so dass diese dann alten Spezialfunktionen nicht mehr notwendig waren und man lieber wieder zurück auf Standard-C Mitteln ging. > Danach werde ich mir wohl angewöhnen müssen Ausgänge mit PORTB |= > (1<<PB2); (Als Beispiel) zu setzen und mit PORTB &= ~(1<<PB2); (Als > Beispiel) zurückzusetzen. Für die Abfrage dann eben statt bit_is_set() > if (PORTB &= ~(1<<PB2);) ... usw. Das ist sicher keine schlechte Variante und nach kurzer Zeit geht das in Fleisch und Blut über. UNd dann gibt es ja auch noch die Möglichkeit, dass man sich mit C-Sprachmitteln diese Syntax, wenn man sie denn als ekelhaft unübersichtlich empfindet, so zu verstecken, dass im eigentlichen Programmtext die Dinge so aufscheinen, dass man selber das gut lesen kann. > Das scheint die gängige Definition in der neuesten avrLibc zu sein, Diese Schreibweise hat eigentlich mit der avrLibc wenig zu tun. Variable |= ( 1 << Bitnummer ); ist ganz einfach ein C-Ausdruck, der in einer Variablen ein Bit setzt. Mehr gibt es dazu eigentlich nicht zu sagen. Das ist so wie 5 + 4 eben 9 ergibt. Dazu kommt, dass man in einem richtigen Programm dann ja sowieso nicht PORTB |= ( 1 << PB0 ); schreiben wird, sondern lieber SUMMER_PORT |= ( 1 << SUMMER_BIT ); um anzudeuten, dass hier ein Summer (und eben nicht die FLutlichtanlage) eingeschaltet werden soll. Mit ein wenig sonstiger Makro-Magie kann man das dann als C-Kundiger so hinkriegen, dass zwar im Programmtext steht TURN_ON( SUMMER ); und man hier noch einmel einen in Punkto Lesbarkeit drauflegt, ganz hinten aber vom Compiler genau derselbe Code generiert wird, wie im Falle von PORTB |= ( 1 << PB0 ); nur mit dem Unterschied, dass die letzte Variante vom menschlichen Leser eine Gedächtnisleistung erfordert, indem er sich merken muss, dass am Port B und dort wieder am Pin 0 der Summer hängt und daher diese Zeile wohl irgendwas mit dem Summer macht, während ich mir das bei TURN_ON( SUMMER ); das alles eben NICHT merken muss. Ich kann mich als menschlicher Programmierer ganz auf die Logik des Programms konzentrieren (warum wird da der Summer eingeschaltet? Ist es richtig, dass hier der Summer eingeschaltet wird oder wollte ich nicht eigentlich eher die grüne Fehler Led eingeschaltet haben?) und nicht so sehr auf die technischen Details. > Das ist ja nach kurzem Nachdenken gar nicht so einfach ... > Eine LED An- und Auszuschalten ist leicht. Nur die Pausen und die 2 > verschiedenen Zeiten für Strich und Punkt (lang und kurz) für jeden Teil > eines Buchstaben und die Pause zwischen den Buchstaben ... Als Anfänger, > der ich bin wird Das eine Menge for-next Schleifen oder das Programm > besteht fast 50:50 aus PORT und _delayms(ms) Anweisungen. Für einen Anfänger ist das ok. Später wirst du dann Techniken kennenlernen, wie man das alles radikal vereinfachen kann. Zunächst mal durch den Einsatz von Arrays, dann wird eine struct dir eine bessere Programmstruktur geben und zu guter letzt wird ein Timer den _delay_ms ersetzen. Aber: NIcht alles auf einmal! zunächst musst du krabbeln lernen, ehe du zu gehen und laufen kommen kannst. Fahrradfahren kommt erst viel später. Wenn du als 5-jähriger die Fläche eines Grundstücks bestimmen sollst, dann malst du dir ein Rechteck mit 5 Feldern Breite und 3 Feldern länge auf und zählst die. Später dann, mit mehr wissen, lässt du das Aufzeichnen weg und ersetzt es dadurch, dass du 3 + 3 + 3 + 3 + 3 addierst (5 mal, weil die andere Seitenlänge eben 5 ist) und zum selben Ergebnis kommst. Und wieder etwas später hast du dann gelernt, dass du dieses wiederrum durch 5 * 3 ersetzen kannst. Mit mehr Wissen verändern sich also auch die Lösungsmethoden für ein bestimmtes Problem. Aber: Dieses Wissen muss man erst mal haben und man muss es sicher beherrschen. > Es sei denn, ich finde nächste Woche beim Lesen des Kerningham Richie > eine Möglichkeit, wie man Datenbausteine in C anlegt und dann einen > Zeiger auf die einzelnen Datenwörter im Datenbaustein definiert, Vergiss das alles. Du hast eine steile Lernkurve vor dir. Das geht nicht in ein paar Stunden. Eher Wochen bzw. Monate. Wenn ich Lehrlinge ausbilde, dann rechne ich damit, dass er ungefähr 1 Jahr braucht, ehe ich ihn zum industriellen Software-Entwickeln übernehmen kann, weil es eben so lange dauert, bis er zum einen sein Basishandwerk (die Programmiersprache) beherrscht als auch er eben die wichtigsten Algorithmen und Techniken lernen muss. Und mit 1 Jahr hast du noch lange nicht die Kurve zum Profi gekratzt. Wir bemessen die Lernzeit eines Software-Entwicklers in Jahren und nicht in Stunden.
Schüler und AVRNeuling schrieb: > (Da sind wir in der Berufsschule dran. Indirekte Adressierung > mit Step/7, deshalb "protze" ich hier so rum damit.) Ganz wichtig: SPS-"Programmiererei" ist etwas sehr spezielles, das sehr wenig mit Mikrocontrollern oder gar "ausgewachsenen" Computer zu vergleichen ist. Erschwerend kommt dazu, dass bei Siemens (Step7) alles anderes ist, als beim Rest in der Branche. Es gibt so schöne, sinnvolle, IEC-Normen für die (etwas kranke) SPS-Welt. Nur hält sich Siemens nicht daran und bastelt seinen eigene Mist, der ziemlich krude ist und irgendwo in den 60er Jahren stecken geblieben ist. Du solltest da schon sehr trennen, zwischen Step7-Gelumpe und AVR-Mikrocontrollern. Beide machen in etwa das gleiche, aber sind grundverschieden. Ist so wie mit einer Schreibmaschine und einem Computer. Beide haben eine Tastatur, sind aber sehr, sehr unterschiedlich.
Ich muß mich nochmal melden ... Auf dem PC laufen nun die meisten meiner Programme, die ich mit dem Wissen aus den Büchern von Kerningham & Richie so schreibe. Wenn ich aber ein Programm in etwa so:
1 | /* Test 1 Hello World mit Befehlen aus dem AVR Tutorial */
|
und danach dann die (obligatorischen) Zeilen:
1 | #ifndef
|
2 | #F_CPU = 36864000
|
3 | |
4 | #include <avr/io.h> |
5 | #include <avr/delay.h> |
6 | #include <avr/stdint.h> |
7 | |
8 | uint8_t kurz = 10; // 10 ms fuer einen Punkt |
9 | unit8_t lang = 20; // 20 ms fuer einen Strich |
10 | uint8_t pause = 40; // 40 ms fuer die Pause zwischen den Zeichen |
11 | uint8_t zeit = 0; // Fuer die for - next Schleife um die Zeiten zu bilden |
schreibe und dann versuche, das zu compilieren, also das Makefile ausführen lasse, kommt keine Hex - Datei dabei heraus. Ich weiß schon, dass die Zeilen da oben noch kein Programm sind und auch noch keine main() Funktion existiert. Ich wollte eben nur mal antesten ob der Compiler meckert. Tut er aber auch nicht. Gibt es eine Lösung, notfalls auch Windows und WinAVR wo man sehen kann ob da Etwas an Code entstanden ist ? Achso: Mein System besteht aus Ubuntu 10.04, avr-libc 1.8.x und dazu passend avr-gcc, binutils, usw. aus dem Ubuntu Synaptic Repository. Ich habe Eclipse AVR installiert und würde sagen, dass ich mich da in den letzten Wochen ganz gut eingearbeitet habe. Schließlich will ich ja Klaus Wachtler noch in diesem Leben und sogar noch in diesem Jahr den "Hello World !" in Morsecode präsentieren. Wenn es aber schon so anfängt, dass noch nicht einmal ein Teilprogramm richtig übersetzt wird, dann ist mein Problem wohl schon viel früher zu suchen. Jürgen
Schüler und AVRNeuling schrieb: > und danach dann die (obligatorischen) Zeilen Und was soll dieser Unsinn, daß du von fehlerhaften Zeilen erwartest, daß da irgendwas Sinnvolles bei raus kommt? Schüler und AVRNeuling schrieb: > Wenn es aber schon so anfängt, dass noch nicht einmal ein Teilprogramm > richtig übersetzt wird Was fängt an? Du hast noch gar nichts angefangen. Schreib' erstmal ein Programm. mfg.
Schüler und AVRNeuling schrieb: > Ich wollte eben nur mal antesten > ob der Compiler meckert. Tut er aber auch nicht. Ich nehme doch mal an das du das ueber die shell machst. Poste doch mal Ein und Ausgabe
Schüler und AVRNeuling schrieb: > So, während es am Anfang überhaupt nicht geklappt hat, habe ich nun über > Google, Eclipse AVR, gedit und dem ersten selbstgeschriebenen Make-File > in Ubuntu 10.04 schon div. Beispiele hier.. Hmm... Du hantierst also mit selbstgeschriebenen Makefiles, Eclipse bis hin zu "Google".... herum. Meisterhaft! Meine Ratschläge: 1. Lies das Manual zu dem von dir benutzten Chip, und zwar gründlich. 2. Lies dir ein Tutorial zum Programmieren im Allgemeinen und eins zum Schreiben von C-Programmen durch. Sowas findest du per Google. 3. Besorge dir einen der vielen kostenlosen C-Compiler für den PC und schreib erstmal ein klitzekleines Programm für deinen PC, z.B. eines, das die ersten 10 Primzahlen auf der Konsole ausgibt. 4. Dann erst mach dich daran, dein Programm für den uC zu konzipieren. 5. Mach erstmal ein Programm bestehend aus einer Quelle, für das man noch kein Makefile benötigt, sondern das man noch in einem Rutsch compiliert und gelinkt bekommt. W.S.
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.