Announcement: there is an English version of this forum on Hallo! Hat jemand von euch eine Empfehlung für einen Core für den AtTiny85? Ich hab erst den Core von A. Mellis verwendet, da hat sich dann herausgestellt, dass da das tone() Kommando nicht funktioniert, und bin auf den Core von Spence Konde gestossen. Und jetzt stell ich fest, dass der Core von Konde bei Verwendung von "delay()" hängen bleibt, wenn davor VirtualWire mit "vw_setup()" initialisiert wurde. Der Core von AMellis bleibt in dem Fall nicht hängen, aber das Timing verlangsamt sich plötzlich extrem - eine 100ms Pause dauert plötzlich einen Sekunde. (und dann wär da noch das tone()-Problem). Ich bin ja komplett neu hier, daher mal so rein gefragt: Gibt's "DEN" Standard-Core, den eh alle verwenden? Oder muss man da immer herumprobieren? Oder: Hat jemand von euch VirtualWire zusammen mit dem AtTiny im Einsatz? Wenn ja: Welcher Core? Vielen Dank jetzt schon!!! Ralf
Ralf, ich habe noch nie etwas von einem "Core" gehört. Was sollte das sein ? Ich nehme einen Compiler (Hochsprache oder Assembler) und kodiere mein Problem entsprechen der Problemanalyse usw. in direkt ausführbaren Atmel AVR Code.
Hi >ich habe noch nie etwas von einem "Core" gehört. >Was sollte das sein ? Gibt es schon. Lt. Partdescritionfile hat der ATTiny 85 einen V2 Core ... <PART_NAME>ATtiny85</PART_NAME> ... <CORE> <CORE_VERSION>V2</CORE_VERSION> ... Aber von Core von A. Mellis oder Konde steht da nichts. MfG Spess
Hi 'Riecht' irgendwie nach dem Arduino-Pendant für einen ATtiny85, denke, wird wohl eine LIB sein, Die auf einen ATtiny85 zugeschnitten ist. Lasse mich aber gerne überraschen :) MfG
Verabschiede dich mal von dem Gedanken, dass kleine Tiny-µCs von jedermann mit irgenwelchen "Cores" benutzt werden. So ein "Core" belegt wahrscheinlich 75% der Tiny-Ressourcen um ein paar Allerwelts-Probleme schneller zu lösen. Hast du nur EIN Problem: OK, schnell fertig! Aber wie du schon gemerkt hast, funktioniert die eine "Erleichterung" nicht, wenn die andere genutzt wird, weil sie sich gegenseitig die knappen Ressourcen klauen. Virtual-Wire benutzt irgendeinen Timer - und delay() nutzt ihn anders... Probier mal die Reihenfolge zu ändern! Gibt bestimmt neue Überraschungen! ;-) So kleine µCs können eine ganze Menge leisten, wenn man sich vor das Datenblatt setzt und austüftelt, wie man die Ressourcen optimal für das vorliegende Problem einsetzt: - Der Tiny hat 2 Timer. - Manchmal kann ein Timer-Interrupt mehrere Probleme lösen, wenn die zugehörigen Auslöser/Bedingungen/... in Kürze nacheinander abgehandelt werden. Also: Datenblatt anschauen, und mit etwas Phantasie und C, oder ASM loslegen.
Patrick J. schrieb: > 'Riecht' irgendwie nach dem Arduino-Pendant für einen ATtiny85, denke, > wird wohl eine LIB sein, Die auf einen ATtiny85 zugeschnitten ist. > > Lasse mich aber gerne überraschen :) Das hast du gut erkannt! https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification
Jaja, Arduinos wirken magisch auf Stümper ohne Programmierkenntnisse. Anstatt irgendwelche Cores durchzuprobieren würde sich jeder halbwegs Gescheite das Datenblatt des Tinys zu Herzen nehmen. Da sollten sogar Codebeispiele drin sein...das funktioniert dann fast wie Arduino-Copy-Pasta.
Jacko schrieb: > Verabschiede dich mal von dem Gedanken, dass kleine Tiny-µCs > von jedermann mit irgenwelchen "Cores" benutzt werden. > > So ein "Core" belegt wahrscheinlich 75% der Tiny-Ressourcen um > ... > Also: Datenblatt anschauen, und mit etwas Phantasie und C, > oder ASM loslegen Ganz so schlimm ist's nicht, ein Testprogramm das ab und an einen CRC-gesicherten Datenblock schickt braucht jetzt mit dem Core (und aus der Arduino-IDE raus) knapp 3kb. Das bisserl Sensor-Auslesen das ich da noch dazu brauche, da bin ich mit 4kB, also beim tiny85 mit seinen 8K Flash locker dabei. Aber wie du richtig angemerkt hast, hier gibt's mit dem Core sideeffects und sauberer wird's sicher, wenn man die Arduino-IDE meidet. Und das werd ich jetzt nun vermutlich machen. Die Arduino-IDE war halt für die ersten Schritte echt angenehm, zumal die Eval-Boards de facto nix kosten, man gleich loswerken kann und massenhaft wirklich handliche libraries - wie VirtualWire - vorhanden sind. Und der Core dient als abstraction layer, so dass ich auf einem ATmega328P entwickeln (und debuggen) kann, und wenn dann die Sache läuft, dann schieb ich's auf den Tiny rüber - wo ich keinen Pin mehr für Debuggereien frei hab' - oder geht das trotzdem? Soweit die Theorie. In meinem konkreten Fall hat's mit der Portierung dann doch gehakt. Das AVR-Studio ist ja gleich mal 1GByte gross, und es scheint so zu sein, dass ich da dann einen eigenen Programmier-Adapter brauche. Oder kann ich vom AVR-Studio auch einen ArduinoUNO flashen? (ich werd' mal probieren...) Danke jedenfalls für deine wirklich nette und höfliche Antwort, bei dem Post von User "Core" hab ich lachend wieder an "deutsche Freundlichkeit" denken müssen. Ich weiss nicht woran das liegt, aber in diesem Forum hier wird schon ein wahnsinnig unguter Umgangston gepflegt, das ist in anderen Ländern wirklich besser. Schade, denn die Leute hier haben ja echt was drauf. Dass da immer so untergriffig (bei uns sagt man "gschissen") formuliert wird, wundert wirklich. Lg, Ralf
:
Bearbeitet durch User
Ralf S. schrieb: > In meinem konkreten Fall hat's mit der Portierung dann doch gehakt. Die Register beim Tiny13 z.B. unterscheiden sich zum mega328. Hingegen der Tiny10, dort werden die Register gleich beschrieben und wenn du den Code entsprechend schreibst, kannst du einen 328 nehmen und dort probieren, dann läuft es auch auf dem Tiny10, nach Anpassung der Pins. Allerdings mache ich das so mit dem Studio und Programmieradapter in C. Für mich ist das sehr praktisch, da die Platinen sehr klein sind, ebenso der Tiny10 und ich den vor dem Löten programmiere und so den ISP Anschluss spare. Sollte wirklich noch eine Änderung nötig sein, schmeiß ich entweder die ganze Platine weg oder löte einen neuen Tiny10 auf. Änderungen fallen aber eigentlich nicht an, da die Programme sehr überschaubar sind, ob der geringen Pinanzahl. Trotzdem sollte man die Möglichkeiten von dem Tiny10 nicht unterschätzen, denn der kann ziemlich viel, wie das Datenblatt verrät. Irgendwann will ich einmal etwas Komplexes mit vielen Tiny10 machen, in einem verteilten System.
Warumm werden die Dinge in der Arduino Welt eigentlich nicht beim Bamen genannt? Library -> Core Quelltext -> Sketch Modul/Board/Platine -> Shield Damit fängt es doch schon an lächerlich zu werden. Da wundert es mich nicht mehr, daß Arduino Anwender "stundenlang verzweifelt" nach einer Lösung suchen, den großen Sketch auf mehrere Dateien aufzuteilen. Oder andere ebenso banale Aufgaben. Diese ganzen Arduino Libs scheinen komplexe Dinge zu vereinfachen. In der Realität stößt man dabei allerdings sehr schnell an Grenzen. Wenn die Library nicht tut, was man will oder wenn zwei Libraries zusammen nicht funktionieren, ist man aufgeschmissen. Wer sich die Sachen hingegen selbst programmiert, weiß was er tut und kann solche Probleme schnell lösen. Ja, auch ich bin damit überfordert, einen Algorithmus für Verschlüsselung oder irgendwelche CRC's zu entwicklen. Algorithmen findet man fix und fertig im Netz, und die kann man (wenn man die Programmiersprache verstanden hat) auch problemlos einbinden, denn sie hängen nicht von der Hardware ab. Selbst das Übersetzen von z.B. Java in C ist kein Problem. Für Hardwarebezogene Sachen kann ich mich nur den vorheigen Beiträgen anschließen: Lest die Datenblätter. Und wenn die nicht ausreichen, dann lest die Application Notes. Außerdem ist die Dokumentation von Arduino Komponenten in ihrer Qualität sehr unterschiedlich. Am besten gefallen mir noch die bunten Bildchen mit den Pinbelegungen. Mal ehrlich: Wenn die Bilder das Beste sind, dann gute Nacht. Arduino Software taugt nur für ein erstes schnelles AHA Erlebnis. Danach sollte man sich schleunigst davon trennen.
> Das AVR-Studio ist ja gleich mal 1GByte gross Andere IDE's sind ähnlich groß. Füge mal zur Aduino IDE Unterstützung für den beliebten ESP8266 hinzu, dann ist sie noch größer. > es scheint so zu sein, dass ich da dann einen eigenen Programmier-Adapter > brauche. Wenn du ein mit Bootloader ausgestattete Modul verwendest (z.B. ein Arduino Modul), brauchst du keinen extra Programmieradapter. Arduino nuttzt dazu avrdude, dass du auch einzeln herunterladen kannst. Dazu gibt es grafische Oberflächen udn die kann man (wenn man unbedingt will) in das Atmel Studio integrieren. Aber ob die GUI nun im Menü des Atmel Studios oder im Startmenü von Windows integriert ist, ist doch völlig egal. Für Embed kompatible Boards (z.B. STM32 Nucleo) braucht man nicht einmal ein extra Programm, da genügt Drag&Drop im Dateimanager. STM32F1 Mikrocontroller haben übrigens ab Werk einen seriellen Bootloader drin, der keinen Platz im Flash Speicher belegt. Dafür belegt er einen Pin ganz für sich alleine und einen zweiten schränkt er in der Nutzbarkeit ein. Irgendwo ist immer ein Haken. >> Jaja, Arduinos wirken magisch auf Stümper ohne Programmierkenntnisse. >> Anstatt irgendwelche Cores durchzuprobieren würde sich jeder halbwegs >> Gescheite das Datenblatt des Tinys zu Herzen nehmen. > wird schon ein wahnsinnig unguter Umgangston gepflegt Ja, dennoch ist sein Ratschlag weise.
Stefan U. schrieb: > Diese ganzen Arduino Libs s Noch schlimmer: Was in der Arduino-Welt "Library" oder in Kiddie-Speech "lib" genannt wird, ist keine, sondern banaler Sourcecode, und oft sogar nur 'ne Headerdatei. Das hat schon für sehr viel Verwirrung geführt, denn jeder, der schon mal einem Compiler und einen Linker etwas näher gesehen hat, weiß, daß eine Library etwas anderes ist.
ad schrieb: > Wo ist das Problem? Habe ich auch nicht verstanden, zumal Terrabyte große Platten heute kein Thema mehr sind.
Ralf S. schrieb: > Und jetzt stell ich fest, dass der Core von Konde bei Verwendung von > "delay()" hängen bleibt, wenn davor VirtualWire mit "vw_setup()" > initialisiert wurde. Caution: ATTiny85 has only 2 timers, one (timer 0) usually used for millis() and one (timer 1) for PWM analog outputs. The VirtualWire library, when built for ATTiny85, takes over timer 0, which prevents use of millis() etc but does permit analog outputs. http://www.airspayce.com/mikem/arduino/VirtualWire/
F. F. schrieb: > ad schrieb: >> Wo ist das Problem? > > Habe ich auch nicht verstanden, zumal Terrabyte große Platten heute kein > Thema mehr sind. Die Grösse auf der Platte ist natürlich kein Drama, aber riesige Softwarepakete installieren oft viel Müll, der dann in weiterer Folge den Computer immer unbenutzbarer/langsamer macht. Da war mir die Arduino-IDE mit ihren 100MB und ohne einem einzigen Dienst sympathisch zum schnell-mal-reinschnuppern in die uP-Programmierung.
Rufus Τ. F. schrieb: > Stefan U. schrieb: >> Diese ganzen Arduino Libs s > > Noch schlimmer: Was in der Arduino-Welt "Library" oder in Kiddie-Speech > "lib" genannt wird, ist keine, sondern banaler Sourcecode, und oft sogar > nur 'ne Headerdatei. > > Das hat schon für sehr viel Verwirrung geführt, denn jeder, der schon > mal einem Compiler und einen Linker etwas näher gesehen hat, weiß, daß > eine Library etwas anderes ist. Ich bin zwar frisch in der µC-Programmiererei, ich würd' mich aber nicht als "Kiddie" bezeichnen. Und in meiner Welt sind Libraries (auch von Oldies "libs" genannt) keinesfalls nur vorcompilierte Binaries, sondern (sogar in den meisten Fällen) Sourcen und - wenn die Sprache das vorsieht - die zugehörigen Header files. Magst du mir mal erklären, was deiner Meinung nach eine Library ist, und was nicht? (Nur damit ich hier im Forum alles richtig mache und euer Vokabular richtig verwende)
Stefan U. schrieb: > STM32F1 Mikrocontroller haben übrigens ab Werk einen seriellen > Bootloader drin, der keinen Platz im Flash Speicher belegt. Das haben eigentlich alle uC außer AVR und PIC z.B. EFM8 8051 EFM32 LPC TMS > Für Embed kompatible Boards (z.B. STM32 Nucleo) braucht man nicht einmal > ein extra Programm, da genügt Drag&Drop im Dateimanager. Anmeldung als USB Stick haben verschiedene uC auch ab Werk z.B. LPC11U LPC13 LPC15 LPC54 EFM8UB
Georg M. schrieb: > Ralf S. schrieb: >> Und jetzt stell ich fest, dass der Core von Konde bei Verwendung von >> "delay()" hängen bleibt, wenn davor VirtualWire mit "vw_setup()" >> initialisiert wurde. > > Caution: ATTiny85 has only 2 timers, one (timer 0) usually used for > millis() and one (timer 1) for PWM analog outputs. The VirtualWire > library, when built for ATTiny85, takes over timer 0, which prevents use > of millis() etc but does permit analog outputs. > http://www.airspayce.com/mikem/arduino/VirtualWire/ Top!!! Danke für den Hinweis, das war auf der Seite, die ich für die offizielle VW-Seite gehalten habe, nicht erwähnt.
Stefan U. schrieb: > Diese ganzen Arduino Libs scheinen komplexe Dinge zu vereinfachen. In > der Realität stößt man dabei allerdings sehr schnell an Grenzen. Wenn > die Library nicht tut, was man will oder wenn zwei Libraries zusammen > nicht funktionieren, ist man aufgeschmissen. Man muss aber auch sagen: Das war einst die Grundidee bei Arduino: Man wollte es, für Kinder, einfacher machen in die µC-Welt einzusteigen. Ich denke die Erfinder hatten nicht erwartet, dass Arduino so erfolgreich werden würde und es gibt auch ganz viele Nutzer, die prima damit klar kommen. Wir sehen hier ja meist nur die, die Probleme haben, welcher Art auch immer.
Ralf S. schrieb: > Magst du mir mal erklären, was deiner Meinung nach eine Library ist, und > was nicht? Im Assembler-, C- und C++-Umfeld (und nichts anderes nutzt Arduino) ist der Begriff Library ein feststehender Ausdruck für eine Sammlung von Objektdateien, die in einem linkerabhängigen Dateiformat vorliegen und vom Linker verarbeitet werden. Verbreitet ist die Extension *.a (für gcc & Co.) bzw. *.lib (u.a. bei Microsoft- oder Borland-Compilern). Eine Objektdatei ist das Resultat eines Compilerlaufs und heißt bei gcc & Co. *.o (bzw. *.obj bei Microsoft & Borland). Die Library wird von einem Tool namens ar (bei gcc & Co.) erzeugt. (Bei MS macht das der Linker, bei Borland hab ich's vergessen, 's ist zu lange her) Beim Linken eines Programmes werden zunächst alle direkt zu verwendenden Objektdateien zusammengefügt und dabei etwaige Querreferenzen von Symbolnamen aufgelöst. Alle übrigbleibenden Symbolname werden dann in den angegebenen Libraries gesucht und bei einem Treffer aus den Libraries die das Symbol enthaltenen Objektdateien extrahiert und zum Programm hinzugefügt. (Moderne Systeme können das auch auf Funktionsebene herunterbrechen, aber zum Verständnis des Systems ist diese mittlerweile etwas vereinfachte Darstellung ausreichend). Damit man eine Library verwenden kann, gehören zur Library eine oder auch mehrere Headerdateien, die u.a. Funktionsprototypen der in der Library enthaltenen Funktionen enthalten. Der entscheidende Punkt aber ist der: Nur die Datei namens *.a (bzw. *.lib) ist eine Library. Der Quelltext der Library ist keine Library, sondern der Quelltext, die zur Library gehörenden Headerdateien sind keine Library, sondern eben die Headerdateien.
Rufus Τ. F. schrieb: > Ralf S. schrieb: > Im Assembler-, C- und C++-Umfeld (und nichts anderes nutzt Arduino) ist > der Begriff Library ein feststehender Ausdruck für eine Sammlung von > Objektdateien, die in einem linkerabhängigen Dateiformat vorliegen und > vom Linker verarbeitet werden. Verbreitet ist die Extension *.a (für gcc > & Co.) bzw. *.lib (u.a. bei Microsoft- oder Borland-Compilern). > Der entscheidende Punkt aber ist der: Nur die Datei namens *.a (bzw. > *.lib) ist eine Library. Der Quelltext der Library ist keine Library, > sondern der Quelltext, die zur Library gehörenden Headerdateien sind > keine Library, sondern eben die Headerdateien. Hm. Wir haben sowas "lib-files" oder "object files" genannt. Ok, werde das berücksichtigen. Wie heisst dann eine Funktionsbibliothek wie zB VirtualWire. Also nicht SOUP oder OTS-module, sondern ein Source- plus zugehörigem Headerfile, solange sie nicht vorcompiliert sind? Wäre "Bibliothek" richtig? Und wie nenn ich das dann, wenn ich in einem englischem Forum bin?
:
Bearbeitet durch User
> Man wollte es, für Kinder, einfacher machen in die µC-Welt einzusteigen.
Und das klappt auch offensichtlich. Seit Arduino sind viele spannende
Baugruppen erstaunlich billig und leicht zu haben und viele Leute
schaffen damit ihren Einstieg erfolgreich.
Doch danach sollte man mal über den Tellerrand schauen.
Rufus, du hast den begriff Library meiner meinung nach fachlich korrekt beschrieben. So habe auch ich es gelernt. Allerdings ändert sich die deutsche Sprache fortlaufend, das sollte man nicht vergessen. Im heutigen Sprachgebrauch zählen Sammlungen von Irgendwas auch dazu. Im KiCad hat man zum Beispiel eine Library mit Bauteilen. In der Textverarbeitung hat man eine Library mit Vorlagen und so liegt es nache, eine Sammlung von Quelltexten auch als Library zu bezeichnen. Mein Vorschlag zur Güte: Lass uns zwischen binären Libraries und Quelltext-Libraries Unterscheiden, dabei jedoch akzeptieren, daß beides Libraries sind.
Rufus Τ. F. schrieb: > Im Assembler-, C- und C++-Umfeld (und nichts anderes nutzt Arduino) ist > der Begriff Library ein feststehender Ausdruck für eine Sammlung von > Objektdateien, die in einem linkerabhängigen Dateiformat vorliegen und > vom Linker verarbeitet werden. Ich würde den Begriff nicht ganz so eng definieren, sondern eher so wie hier: https://de.wikipedia.org/wiki/Library Gerade im C++-Umfeld werden oft auch reine Quellcodesammlungen als Library bezeichnet. Prominenteste Beispiele sind die Standard Template Library und die Boost Libraries. Letztere besteht zum größten Teil, erstere sogar ausschließlich aus Header-Files. Stefan U. schrieb: > Lass uns zwischen binären Libraries und Quelltext-Libraries > Unterscheiden, dabei jedoch akzeptieren, daß beides Libraries sind. Mich persönlich hat in Ralfs Fragestellung allerdings der Begriff "Core" etwas verwirrt. Da in der Fragestellung nicht erwähnt wurde, dass es um die Arduino-Umgebung geht, dachte ich zunächst, Ralf sucht einen zum ATtiny kompatiblen CPU-Core zur Implementierung auf einem FPGA und war deswegen schon kurz davor, den Thread in das entsprechende Forum zu verschieben :) Da die potentiellen Helfer aber selber Arduino-User sind, ist ihnen der Begriff natürlich geläufig.
Stefan U. schrieb: > Lass uns zwischen binären Libraries und Quelltext-Libraries > Unterscheiden, dabei jedoch akzeptieren, daß beides Libraries sind. Ja.
Stefan U. schrieb: > Im KiCad hat man zum Beispiel eine Library mit Bauteilen. In der > Textverarbeitung hat man eine Library mit Vorlagen und so liegt es > nache, eine Sammlung von Quelltexten auch als Library zu bezeichnen. Zwar mag es naheliegend sein, aber es bleibt falsch, weil es tausende von Benutzern in die Irre führt, wenn sie versuchen, in ihren IDEs Libraries und Library-Pfade zu konfigurieren, und sich wundern, daß nicht das passiert, was sie erwarten. Oder wenn sie per #include ein zu einer Library gehörendes Headerfile einbinden, und der Linker weiterhin munter Fehlermeldungen ausspuckt.
Das Wort Library ist älter, als die EDV. Man sollte schon so flexibel sein, dass man auch in dem Begriff "Arduino Lib", das übergeordnete, viel ältere, Konzept "Library" wiederfindet.
ad schrieb: > Ralf S. schrieb: >> Das AVR-Studio ist ja gleich mal 1GByte gross > > Wo ist das Problem? Verstehe ich auch nicht. Zumal das AVR-Studio keineswegs die einzige Alternative zu Arduino ist. Selbst wenn man bei Arduino wie "die Arduino Library" bleiben will, braucht man dafür nicht die Arduino-IDE. F. F. schrieb: > Habe ich auch nicht verstanden, zumal Terrabyte große Platten heute kein > Thema mehr sind. Das nun nicht. Platten werden nicht aus Ton gebrannt (aka Irdenware). Solltest du am Ende Terabyte gemeint haben? ;)
M. K. schrieb: > Man > wollte es, für Kinder, einfacher machen in die µC-Welt einzusteigen. Das ist nicht richtig. Der Einstieg sollte vor allem für Künstler leicht gemacht werden. So schreibt es Massimo Banzi jedenfalls in seinem Buch.
Axel S. schrieb: > Solltest du am Ende Terabyte gemeint haben? ;) Jau. Handy. Aber im übrigen gilt: Wer Rechtschreibfehler findet, der darf sie behalten.
F. F. schrieb: > M. K. schrieb: >> Man >> wollte es, für Kinder, einfacher machen in die µC-Welt einzusteigen. > > Das ist nicht richtig. Der Einstieg sollte vor allem für Künstler leicht > gemacht werden. > So schreibt es Massimo Banzi jedenfalls in seinem Buch. Ah, OK. Kann sein, dass ich das vielleicht auch mit dem Raspberry Pi (oder ähnlichem) verwechselt hatte. Auf jeden Fall sollte es nur den Einstieg erleichtern und heute hat Arduino weit mehr an Bedeutung gewonnen als je geplant war.
StefanUs >Warumm werden die Dinge in der Arduino Welt eigentlich nicht beim Bamen >genannt? >Library -> Core >Quelltext -> Sketch >Modul/Board/Platine -> Shield Sie werden beim Namen genannt. So wie bei allen großen Softwarepaketen haben sich auch im Arduino-Zusammenhang eigene Begrifflichkeiten entwickelt. Als "Arduino-Core" wird nicht eine Library sondern die "Kern-Unterstützung" für eine bestimmten Prozessortyp bezeichnet. So finden wir z.B. die Atmel-SAMD hier: https://github.com/arduino/ArduinoCore-samd oder die Unterstützung durch STM hier: https://github.com/stm32duino/Arduino_Core_STM32 Viele Cores kann man auch direkt in der Arduino-IDE installieren, wenn die Entwickler ein JSON file bereitstellen wie bei dem Beispiel für die Attinies hier: "By default Arduino IDE doesn't support ATtiny85 so we should add ATtiny boards to Arduino IDE. Open File -> Preferences and in the Additional Boards Manager URLs give this url https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json.";
Noch ein kleiner Nachtrag zur Einordnung des "Arduino-Cores". Der Arduino-Core beinhaltet das, was man in anderen großen Mikrocontroller-Software-Framewoks als "HAL" ( Hardware-Abstraction-Layer ) bezeichnet. Diese Schicht dient dazu, dass u.a. auf jeder MCU der Befehl "digitalWrite" zur Verfügung steht und vielen Arduino-Libraries auf möglichst vielen MCUs laufen. Viele Libraries beinhalten allerdings AVR-spezifische Registerzugriffe. Das ist historisch bedingt, weil die ersten Arduinos mit AVRs bestückt waren. Diese Libraries laufen dann nicht auf anderen MCUs. Mit dem zunehmenden Einsatz von leistungsstärkeren ARM-Prozessoren und der Tatsache, dass sich zunehmend erfahrene Entwickler für die Plattform interessieren, verbessern sich diese Verhältnisse bei den Libraries etwas.
Rufus Τ. F. schrieb: > weil es tausende > von Benutzern in die Irre führt, wenn sie versuchen, in ihren IDEs > Libraries und Library-Pfade zu konfigurieren, und sich wundern, daß > nicht das passiert, was sie erwarten. Erzähl mal noch einen vom Pferd. Jeder, der schon länger als 3 Tage programmiert hat, kann doch wohl spielend eine Source-Lib von einer Object-Lib unterscheiden. In selbst gebauten Libs habe ich schon zu oft Fehler gefunden oder Verbesserungen benötigt. Daher füge ich sie immer als Source-Lib dem Projekt hinzu. Die Compilezeit spielt bei MCs auch keine Rolle mehr.
Peter D. schrieb: > Erzähl mal noch einen vom Pferd. Ich bekomme mit, welche Probleme in diesem Forum ziemlich häufig diskutiert werden. Pferde brauche ich dafür keine.
Manche Probleme sind aber auch nur in Diskussionen präsent und kaum in der Realität. Da sollte man sich nicht täuschen lassen.
Rufus Τ. F. schrieb: > Ich bekomme mit, welche Probleme in diesem Forum ziemlich häufig > diskutiert werden. Pferde brauche ich dafür keine. > Ein Frosch, der im Brunnen lebt, beurteilt das Ausmaß > des Himmels nach dem Brunnenrand. Merksatz: Halbwegs wache Arduino User stellen hier keine Fragen, weil sie vorher schon gelesen haben wie das Arduino Bashing hier abläuft. Und sind sie so dumm, und tun es doch, werden sie niedergetreten und verschwinden danach. Das ist das, was man hier beobachten kann. Beinahe hätte ich gesagt: (Das ist das, wo du, mit deinen Urteilen, mit an vorderster Front stehst.) Aber das traue ich mich doch dann doch nicht öffentlich zu tun....
Markus schrieb: > StefanUs >>Warumm werden die Dinge in der Arduino Welt eigentlich nicht beim Bamen >>genannt? > >>Library -> Core >>Quelltext -> Sketch >>Modul/Board/Platine -> Shield > > Sie werden beim Namen genannt. > So wie bei allen großen Softwarepaketen haben sich auch im > Arduino-Zusammenhang eigene Begrifflichkeiten entwickelt. Mag sein, dass solch Unfug auch wo anders getrieben wird, aber das macht's nicht besser. Was soll es denn bringen, sich komplett neue Namen für Dinge auszudenken, die eigentlich schon einen Namen haben? Maximale Verwirrung stiften? Sich abgrenzen vom Rest der Welt? Sie scheinen auch nicht so wirklich offen zugeben zu wollen, dass ein "Sketch" am Ende eigentlich nix anderes ist als C++-Code.
:
Bearbeitet durch User
Rolf M. schrieb: > Unfug Es ist recht sinnfrei, die "Frage" zu stellen. Denn dafür ist das "Projekt" Arduino schon zu weit fortgeschritten. Jetzt noch die "Warum" Frage zu stellen, mit dem Unterton "das ist aber falsch", ist wie als wollte man versuchen, Sägemehl zu sägen. Mehr als Polarisierung kann man damit nicht erreichen. Aber wenn das hier der Wunsch ist, dann nur zu. > Gott gebe mir Gelassenheit, hinzunehmen, > was nicht zu ändern ist. > Mut zu ändern, was ich ändern kann. > Und Weisheit, zwischen beidem zu unterscheiden.
Rolf Magnus (rmagnus) >Mag sein, dass solch Unfug auch wo anders getrieben wird, aber das >macht's nicht besser. Was soll es denn bringen, sich komplett neue Namen >für Dinge auszudenken, Ich denke "Core" für den Kern der Mikrocontroller spezifischen Implementierung ist ein ziemlich guter Name. Da die gesamte Arduino-IDE ( also der Java Teil ) inclusive einiger Arduino-Standart-Cores ausgeliefert wird, ist Core für den Mikrocontroller-Kern ein sehr guter Name. Außerdem unterscheidet sich der Core durch sonstige "HAL"s anderer Mikrocontroller dadurch, dass auch gleich einige Basistreiber wie SPI mit drinn stecken. Die Namensgebung macht z.B. besonders im STM32GENERIC Core https://github.com/danieleff/STM32GENERIC/tree/master/STM32 besonders Sinn, weil der die echte STM32 HAL als Unterbau nimmt. Würde das Ding auch HAL heißen, gäbe es nur Namenskonflikte. Übrigens: mittlerweile kann man den STM32-Core von ST standartmässig über den Board-Manager der IDE installieren.
Rolf Magnus (rmagnus) >Sie scheinen auch nicht so wirklich offen zugeben zu wollen, dass ein >"Sketch" am Ende eigentlich nix anderes ist als C++-Code. Auch das ist nicht ganz richtig. Zunächst einmal muss man die "Historie" des "Sketches" sehen. Dort war nämlich die Intention, ein Sketch möglichst kompatibel zu Processing-Sketches aussehen zu lassen: https://processing.org/ Processing sollte zusammen mit dem Programm auf dem Mikrocontroller eine Einheit bilden und der Syntax möglichst gleich sein, um dem Anfänger in beiden Welten einen einfachen Einstieg zu ermöglichen. In beiden heißt das "Hauptblatt" "Sketch". Und in beiden Fällen werden "includes" oder "imports" vor dem Aufruf des Sketches erledigt. Das ist für die meisten einfachen Programme auch nicht nötig.
Markus schrieb: > Rolf Magnus (rmagnus) >>Sie scheinen auch nicht so wirklich offen zugeben zu wollen, dass ein >>"Sketch" am Ende eigentlich nix anderes ist als C++-Code. > > Auch das ist nicht ganz richtig. Stimmt es nicht, dass die .ino-Dateien einfach mit g++ übersetzt werden und damit eben C++ sein müssen? Das dachte ich zumindest immer. Auf der Arduino-Homepage steht das allerdings nirgends so wirklich, und es ist nur ganz nebulös von einer "Arduino programming language" die Rede. Markus schrieb: > In beiden heißt das "Hauptblatt" "Sketch". Ah, ok. Das ist also doch keine Eigenerfinung von Arduino. Nun gut, klingt zumindest nach einer etwas wilden Mischung.
:
Bearbeitet durch User
Naja, das *.ino File hat keinerlei "include". Die Main wird durch die beiden Funktionen setup und loop ersetzt. Vor dem *.ino File wir "Arduino.h" includiert, was deshalb ebenfalls unsichtbar ist, dafür aber die gesamte Aruino-Basis-API anzieht. Man kann einwenden, das sind marginale Kleinigkeiten. Reduzieren aber dafür die Optik auf ein Minimum. Außerdem ist es noch so, dass wenn man im *.ino File eine "main" Funktion schreibt, lässt die IDE die gesamte Arduino-API inclusive setup und loop weg und man kann gewöhnliches C++ programmieren. Ob sonst noch was spezielles passiert, weiß ich nicht.
chris schrieb: > Ob sonst noch was spezielles passiert, weiß ich nicht. Bei den .ino-Dateien werden automatisch Funktionsprototypen generiert und vor dem Kompilieren eingefügt. Folgender Code ist eine legale .ino-Datei, aber kein legales C++:
1 | void setup() { |
2 | }
|
3 | |
4 | void loop() { |
5 | f(); |
6 | }
|
7 | |
8 | void f() { |
9 | }
|
Streng genommen ist die Sketch-Sprache ähnlich, aber nicht gleich C++. Insofern ist es schon nachvollziehbar, warum die Sketch-Dateien nicht die Endung .cpp haben. Dem erfahrenen C++-Programmierer erscheint dies alles zwar seltsam, aber für ihn ist Arduino ja auch nicht gemacht :)
Yalu X. schrieb: > chris schrieb: >> Ob sonst noch was spezielles passiert, weiß ich nicht. > > Bei den .ino-Dateien werden automatisch Funktionsprototypen generiert > und vor dem Kompilieren eingefügt. Folgender Code ist eine legale > .ino-Datei, aber kein legales C++: > >
1 | > void setup() { |
2 | > } |
3 | >
|
4 | > void loop() { |
5 | > f(); |
6 | > } |
7 | >
|
8 | > void f() { |
9 | > } |
10 | >
|
> > Streng genommen ist die Sketch-Sprache ähnlich, aber nicht gleich C++. > Insofern ist es schon nachvollziehbar, warum die Sketch-Dateien nicht > die Endung .cpp haben. Dem erfahrenen C++-Programmierer erscheint dies > alles zwar seltsam, aber für ihn ist Arduino ja auch nicht gemacht :) ooch komm schon Yalu, Freitag iss vorbei und Du warst auch schon besser! So langsam demontierst Du eigenhändig Dein Heldenstatus bei mir ;-) Hier ist alles perfekt nachvollziehbar offen in gewohnter Notation dokumentiert: * <https://packages.debian.org/stretch/arduino-mk>; Es muss heissen: """ Streng genommen ist die *.ino-Datei eines 1-Datei-Sketches eine ungültige C++ Datei weil unvollständig. Arduino-Buildumgebungen (GUI oder CLI) ergänzen die fehlenden Teile ( boilerplate ) während des Buildablaufes, schließlich wird für die Übersetzung in Maschinensprache gcc beigezogen. """ Yalu, streng genommen willst Du doch nicht etwa behaupten dass gcc ungültiges C++ kompilieren kann, gell? ;-) Fazit: - es gibt weder eine "Sketch-Sprache" noch eine "Arduino-Programmiersprache": Arduino setzt C/C++ ein. Punkt. - der Buildablauf bei Arduino entspricht nicht dem gängigen bei C++: er ist so abgewandelt dass dem Benutzer eine einfachere Handhabung geboten wird, zum Preis von weniger Flexibilität ggü. was bei professioneller SW-Entwicklung rund um C/C++/gcc/make/&co üblich ist; - es gibt etwas was man "Arduino-Framework" nennen könnte; [1] - es gibt etwas was man "Arduino-Laufzeitumgebung" ( runtime-environment ) nennen könnte; - [2] [1] mit genau diesem Punkt schliesst sich de Kreis zur Frage: > Warumm werden die Dinge in der Arduino Welt eigentlich nicht beim Namen genannt? > > Library -> Core Quelltext -> Sketch Modul/Board/Platine -> Shield > > Damit fängt es doch schon an lächerlich zu werden. Welches Framework bringt denn KEINEN eigen Jargon/Nomenklatur mit sich? ;-) [2] anders als bei Quellcodegeneratoren wie z.B. flex & bison wo tatsächlich von einer eigenen domainspezifischen Sprache nach C/C++ übersetzt wird, geschieht bei Arduino KEINE übersetztung: nur Ergänzungen und Automationen (--> keine "Arduino-Sprache");
Programmiersprachentheaterintendant schrieb: > Yalu X. schrieb: >> ... >> Streng genommen ist die Sketch-Sprache ähnlich, aber nicht gleich C++. >> ... > > ... > Es muss heissen: > """ > Streng genommen ist die *.ino-Datei eines 1-Datei-Sketches eine > ungültige C++ Datei weil unvollständig. Wo genau liegt jetzt der wesentliche Unterschied zwischen deiner und meiner Formulierung? Programmiersprachentheaterintendant schrieb: > Yalu, streng genommen willst Du doch nicht etwa behaupten dass gcc > ungültiges C++ kompilieren kann, gell? ;-) Nein, will ich nicht. Der GCC muss auch gar kein ungültiges C++ kompilieren, weil er die .ino-Datei mit dem ungültiges C++ gar nie zu Gesicht bekommt.
Yalu X. schrieb: > Nein, will ich nicht. Der GCC muss auch gar kein ungültiges C++ > kompilieren, weil er die .ino-Datei mit dem ungültiges C++ gar nie zu > Gesicht bekommt. Heißt das, dass die Buildumgebung von Arduino da nochmal einen eigenen Präprozessor hat, den sie drüberlaufen lässt, um dann dessen Output an den Compiler weiterzugeben? Ich hätte jetzt eher erwartet, dass die fehlenden Includes und derlei einfach über entsprechende Compiler-Kommandozeilenoptionen dazugebastelt werden.
:
Bearbeitet durch User
Rolf M. schrieb: > Heißt das, dass die Buildumgebung von Arduino da nochmal einen eigenen > Präprozessor hat, den sie drüberlaufen lässt, um dann dessen Output an > den Compiler weiterzugeben? Ja. Aus der Datei test.ino:
1 | void setup() { |
2 | }
|
3 | |
4 | void loop() { |
5 | f(); |
6 | }
|
7 | |
8 | void f() { |
9 | }
|
wird im tmp-Verzeichnis eine neue Datei test.ino.cpp:
1 | #include <Arduino.h> |
2 | #line 1 "/home/me/Arduino/test/test.ino"
|
3 | #line 1 "/home/me/Arduino/test/test.ino"
|
4 | #line 1 "/home/me/Arduino/test/test.ino"
|
5 | void setup(); |
6 | #line 4 "/home/me/Arduino/test/test.ino"
|
7 | void loop(); |
8 | #line 8 "/home/me/Arduino/test/test.ino"
|
9 | void f(); |
10 | #line 1 "/home/me/Arduino/test/test.ino"
|
11 | void setup() { |
12 | }
|
13 | |
14 | void loop() { |
15 | f(); |
16 | }
|
17 | |
18 | void f() { |
19 | }
|
generiert. Diese wird vom GCC kompiliert.
Vielleicht sollte man noch erwähnen, dass man in der Arduino IDE auf der rechten Seite einen Pfeil nach unten findet, mit dem man ( new Tab ) *.cpp, *.c, *.h Files erzeugen kann, die dann ganz normal in das Projekt eingebunden werden. Außerdem kann man die gesamte Build-Umgebung aus der Kommandozeile starten https://github.com/arduino/Arduino/blob/master/build/shared/manpage.adoc und damit Projekte erstellen. Der Vorteil: Alle Compiler-Einstellungen und Download-Tools für die ganzen unterstützten MCUs und Entwicklungsboards sind gleich verfügbar.
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.