Hallo, ich lese jetzt hier schon einige Zeit mit und konnte schon viel Hilfe finden. Nun habe ich aber doch mal eine blutige Anfängerfrage. Ich habe mit Arduino angefangen und es hat wirklich Spaß gemacht. Man hatte schnell Erfolge, es gab viele Libraries und und und. Das hat aber nicht mehr gereicht und ich wollte möglichst ohne Libaries auskommen; auch wenn es heißt das Rad zweimal erfinden zu müssen. Später habe ich nur noch Libraries für die IOs, I2C und SPI genutzt. Irgendwann wollte ich mir mal die direkte Programmierung von µC anschauen, um von Arduino etwas weg zu kommen, damit auch mal ein Umstieg auf andere µC nicht so kompliziert ist (den Arduino Bootloader gibt es ja nicht für alle µC). Das GCC-Tutorial habe ich fast durch aber ich frage mich trotzdem noch folgendes: Wie macht ihr das mit I2C z.B.? Nutzt man hier auch Libraries und programmiert man sich das wirklich auch komplett selber? Bei Arduino konnte man leicht in ein Register springen und es lesen bzw. beschreiben. Ich frage mich das, da ich mir nicht sicher bin, ob es sich nun wirklich lohnt oder ob ich bei Arduino vielleicht doch besser aufgehoben bin? Hier scheinen ja auch viele Profis unterwegs zu sein, ich betreibe das ganze allerdings nur als Hobby. Es hat mich aber schon manchmal geärgert, dass einem bei Arduino einige Controller halt vorenthalten werden. Viele Grüße Dominik
Ich habe meistens keine Lust, das Rad neu zu erfinden und freue mich immer, wenn jemand schon eine Library geschrieben hat. Peter Fleury z.B. hat sich um LCDs, UARTs und I2C verdient gemacht und hat gut dokumentierte Bibliotheken dafür auf seiner Homepage: http://homepage.hispeed.ch/peterfleury/
Danke schonmal! Bei so grundlegenden Sachen (I2C) stimme ich dir zu. Aber wenn ich z.B. ein Bauteil habe, möchte ich es selber programmieren, damit ich weiß, wie das ganze funktioniert. Also für eine RTC z.B. selbst den Code zum Auslesen der Register schreiben. Bei so etwas gebe ich die Kontrolle ungern aus der Hand. Ich habe mir die Library mal angeschaut. Letztendlich scheint es ja nicht so viel anders zu sein, als beim Arduino. Man muss sich halt reinlesen. Das motiviert mich dann schon wieder, doch weiter zu machen!
Dominik Gebhardt schrieb: > Danke schonmal! > Bei so grundlegenden Sachen (I2C) stimme ich dir zu. Aber wenn ich z.B. > ein Bauteil habe, möchte ich es selber programmieren, damit ich weiß, > wie das ganze funktioniert. Also für eine RTC z.B. selbst den Code zum > Auslesen der Register schreiben. Bei so etwas gebe ich die Kontrolle > ungern aus der Hand. Ja, kannst du ja. Du musst konkret beim Thema I2C unterscheiden zwischen der Transportschicht und dem was sich dann über diese Transportschicht abspielt. Selbst wenn du ein Fax-gerät selber bauen würdest, würdest du ja nicht das komplette Telefonnetz neu aufbauen :-) Die I2C Libs, zb die vom Fleury, regeln für dich nur den Transport der Daten. Welche Daten du dann damit überträgst, in welche Richtung, was sie bedeuten, das interessiert diese Lib nicht.
Sonst wäre es ja auch zu einfach. ;) Was ich senden möchte, muss ich natürlich selbst entscheiden. Ich hatte nur bedenken, ob ich mir auch Gedanken machen muss, wie ich es schicke. Aber das übernimmt ja die Lib. Welches Register etc. liegt natürlich in meinen Händen. :) Aber dann passt das ja alles und es steht dem Ganzen ja nichts mehr im Wege. :) Aber so richtig nehmen sich die beiden Plattformen dann ja nicht. Ich dachte immer, der große Vorteil von Arduino seien die ganzen Libraries. Aber letztendlich scheint es dies ja auch hier zu geben. Gut, bei Arduino stößt man gerade bei neuen oder unpopulären Bauteilen an Grenzen; weiß man aber mit Registern umzugehen, gibt es doch eigentlich kaum Unterschiede (dann kommt man bei Arduino ja genauso weit)? Aber ich möchte hier lieber nicht einen Glaubenskrieg vom Zaun brechen. ;) Viele Grüße Dominik
Dominik Gebhardt schrieb: > Aber das übernimmt ja die Lib. Welches Register etc. liegt natürlich in > meinen Händen. :) Ich habe auf nahezu jedem MC-Typ, der mir im Laufe der Jahre unter die Finger kam, auch I2C Routinen schreiben müssen, einfach weil es eben kein Internet gab. Aber es ist ja viel schöner, wenn du dich gleich mit den Sachen beschäftigen kannst, die speziell für dein Projekt nötig sind und eben die Erfindung des Rades (und testen desselben) schon erledigt ist. Der grosse Vorteil der Bibliotheken ist eben auch, das vor dir schon einige hundert andere sie geprüft und optimiert/debugged haben.
Wenn ich mir vorstelle, wie viel ich mir über das Internet anlesen konnte. :) Manchmal hilft es aber auch das Rad neu zu erfinden; einfach zum besseren Verständnis. Für viele Bausteine gibt es ja auch schon fertige Libs aber da setze ich mich doch lieber selber ran. Nur Funktionen aufrufen, möchte ich dann doch nicht. :) Nur gerade was die Kommunikation von Bauteilen angeht, bin ich immer wieder begeistert, dass das, was ich auf dem PC schreibe, später funktioniert. Also das der Code irgendwie umgesetzt wird. Grüße
Dominik Gebhardt schrieb: > Manchmal hilft es aber auch das Rad neu zu erfinden; einfach zum > besseren Verständnis. Für viele Bausteine gibt es ja auch schon fertige > Libs aber da setze ich mich doch lieber selber ran. Nur Funktionen > aufrufen, möchte ich dann doch nicht. :) Sehe ich exakt genauso. Ich bekomme die Zusammenhänge viel leichter in den Kopf, wenn ich die Funktionen von Grund auf selber schreibe und dabei Fehler mache. Der Lerneffekt ist wesentlich größer, wenn ich hinterher weiß, warum ein Programm NICHT funktioniert hat, als wenn es sofort läuft. Der Code ist zwar selten optimal, aber man kann später immer noch bei anderen gucken, wie die es lösen und sich Anregungen holen. Fertige Libs sind gut für Leute, die sich für die Programmierung im Detail nicht interessieren, sondern nur schnell ein Gerät praktisch zum Laufen bekommen wollen. Für die Lernphase sind sie m.E. eher kontraproduktiv, weil der copy-n-paste-Programmierer gar nicht versteht, was da unten drunter abläuft.
Icke ®. schrieb: > Für die Lernphase sind sie m.E. eher > kontraproduktiv, weil der copy-n-paste-Programmierer gar nicht versteht, > was da unten drunter abläuft. Als Antithese dazu würde ich mal formulieren: Beim zusammenkopieren lern man mehr weil: -einfach kopieren geht normal eh nicht weil es nie zum eigenen Programmablauf, Variablenkonvention und den anderen Bedürfnissen passt. -durch die auseinandersetzung mit fremden Code stösst man auf Lösungen/Strategien die einem selbst nicht eingefallen wären. -man traut sich eher an Sachen ran von denen man sich sonst überfordert gefühlt hätte. -es geht schneller.
Chr. Messener schrieb: > -einfach kopieren geht normal eh nicht weil es nie zum eigenen > Programmablauf, Variablenkonvention und den anderen Bedürfnissen passt. Richtig. Deswegen tauchen auch regelmäßig Threads mit der Frage auf: "Ich habe die Lib X von Y auf meinen Controller gebrannt, aber die LED leuchtet nicht/das LCD zeigt nichts an, warum?" > -durch die auseinandersetzung mit fremden Code stösst man auf > Lösungen/Strategien die einem selbst nicht eingefallen wären. Auch richtig. Das mache ich aber fast immer erst, nachdem ich die Routine selbst geschrieben habe. Dann verstehe ich nämlich eher, was der Kollege besser gelöst hat. > -man traut sich eher an Sachen ran von denen man sich sonst überfordert > gefühlt hätte. Wenn ich ein Problem nur mit fremdem Code lösen kann, bin ich in der Tat überfordert. Wenn ich in der Lage bin, den fremden Code zu analysieren, denn überfordert mich auch das Schreiben eigenen Codes nicht. Verstehen muß man ihn so oder so. > -es geht schneller. Das zählt beim LERNEN nicht und geht m.E. auch nicht wirklich schneller.
Es kommt ja schließlich auch darauf an, was man machen möchte. Ich experimentiere auch gerne mit neuen Sachen z.B. Als Beispiel hätte ich den AS1130 von ASM. Wollte ich eine Frage dazu stellen, hieß es, dass ich die Matrix mit Shiftregistern und Treibern aufbauen solle. Mich hat es aber interessiert, weil es einfach etwas neues war und ich auf dem Arduino gerade lernen wollte, mit Registern umzugehen. Libraries gab es nicht. Man sollte hier also wissen, wie es funktioniert. Möchte man einfach nur etwas bauen und das ganze soll dan funktionieren sind Libs wiederum von Vorteil. Man sucht sich raus, was man braucht und versucht es für seine Bedürfnisse zusammen zu setzen. Im besten Falle hat man aber auch hier etwas Ahnung, was man da tut, ansonsten kommen nämlich die ganzen Fragen auf, die Icke erwähnt hat. ;) So oder so sehe ich einige Funktionen als Werkzeug an, die man zu bedienen wissen sollte und dann kann man eigentlich auch fast alles schaffen, was man sich vornimmt. Alles möchte ich schließlich auch nicht von vorne machen; deshalb nutze ich auch gerne weiter die <io.h> und die oben erwähnte I2C Library. Beides hat mir bereits erfolge beschert und ich bin froh, dass ich mich jetzt doch direkt mit µC befasse und etwas von Arduino weg komme. Dadurch stehen mir jetzt schon so ziemlich alle I2C Bausteine offen, ohne hier fragen zu müssen. :) Also je nachdem was man machen möchte, muss wohl jeder für sich entscheiden was und wie er es angehen will. Grüße Dominik :)
Ha, habe jetzt aber doch noch eine Frage. Ich habe die I2C-Library von Peter Fleury bisher direkt ins Projekt mit eingebunden. Da ich sie aber wohl öfters brauche, wollte ich so in AVR Studio integrieren, dass ich nur noch sagen muss #include <i2cmaster.h>. Bei Arduino gibt es ein Library-Verzeichnis mit Unterordner für jede Library. Bei google konnte ich nichts konkretes finden, wo ich das fest einfügen könnte? Grüße Dominik
Dominik Gebhardt schrieb: > Da ich sie aber wohl öfters brauche, wollte ich so in AVR > Studio integrieren, dass ich nur noch sagen muss #include <i2cmaster.h>. Du könntest sie zu den anderen avr libs in die gcc-lib legen, aber das ist deswegen nicht sinnvoll, weil da ja auch die Portdefinitionen drin sind, die sich bei jedem 2ten Projekt ändern. Tue es nicht und kopier die Library jeweils mit in den Projekt Ordner, denn dadurch hast du die Dateien zusammen. Bedenke auch, das alle anderen Leute, denen du mal dein Projekt zeigen und zur Verfügung stellen willst, die Konfiguration nicht haben und dann auf Linkerfehler stossen.
Hallo Dominik, wäre es möglich, dass du mir deine private Email gibst? Ich stecke in einer ähnlichen Situation, in der ich überlege, wie ich den Sprung von Arduino zu anderen UC schaffe. Vielleicht kannst du mir ein paar Tipps geben, wie man das gescheit anstellt bezüglich Tools, Evalboard etc. Vg, DigitalCosmos
Digital Cosmos schrieb: > wie ich den Sprung von > Arduino zu anderen UC schaffe Wenn du erstmal bei den AVRs bleiben willst, dann ist die Anschaffung eines ISP Programmers, z.B. des AVR ISP MkII so ziemlich das einzige, was du wirklich brauchst. Die Arduinos sind ja auch ohne die Arduino SDK gut benutzbar. Ich z.B. benutze 2 Arduino 2009 als universelle Evalboards, was auch deswegen praktisch ist, weil sie ja eine brauchbare USB-Bridge für serielle Kommunikation schon an Bord haben. Dann noch ein AVR Studio deiner Wahl (für Neueinsteiger vllt. AS6, für Produktion nehme ich allerdings immer noch AS 4.18) und du hast alles was du brauchst, um auf Assembler oder C-Ebene zu programmieren. Die AVR Studios wollen alle allerdings ein Windows als OS haben.
Matthias Sch. schrieb: > Wenn du erstmal bei den AVRs bleiben willst, dann ist die Anschaffung > eines ISP Programmers, z.B. des AVR ISP MkII so ziemlich das einzige, AVRDragon wäre da auch noch eine Möglichkeit. Ich bin mittlerweile bei AtmelStudio6, AVRDragon sowie Arduino Uno Rev3 gelandet - mit dem richtigen USB Driver lassen sich die prima per RS232 ansprechen, auch ohne Arduino-Überbau. Den Bootloader habe ich so ziemlich als erstes wegkopiert und den Chip gelöscht...
Ja, der Dragon hat den Vorteil, das er auch HV-Programming kann. Dafür kann der AVRISP MkII den TPI Programmiermodus, was für die neuen Winzlinge a la ATTiny 10 benutzt wird. Beide Programmierer beherrschen natürlich das 'normale' ISP und können auch PDI, was bei z.B. den XMegas benutzt wird. Ausserdem kann der Dragon auch noch debugWire, was manchmal nützlich sein kann, habe ich allerdings bisher nicht gebraucht.
Matthias Sch. schrieb: > Ausserdem kann der Dragon auch noch debugWire, was manchmal nützlich > sein kann, habe ich allerdings bisher nicht gebraucht. DebugWire habe ich bisher auch nicht gebraucht - ich bin mit Simulator und Serial Debug Output bisher gut durchgekommen.
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.