Hallo, muss für ein Projekt wegen der Verfügbarkeit auf die megaAVR 0 Serie zugreifen. Hab leider seit gut 15 Jahren keinen AVR mehr in der Hand gehabt und Zeit zur Wiedereinarbeitung ist (wie immer) knapp....:) Gibt es dafür irgendwelche komfortablen Libraries um das Leben zu vereinfachen? Alles was man so findet für die älteren AVRs kann man leider nicht verwenden, weil die Registernamen und Speicheradressen unterschiedlich sind. Danke für jeden Tipp!
Nimm die mitgelieferten Header und fertig. Programmiere nach Datenblatt.
Thomas F. schrieb: > Gibt es dafür irgendwelche komfortablen Libraries um das Leben zu > vereinfachen? Vielleicht ist hier was dabei: https://github.com/MCUdude
Thomas F. schrieb: > Danke, aber das ist leider für Arduino. Na und? Du hast nach "irgendwelche komfortablen Libraries" gefragt. Arduino fällt ganz sicher in diese Kategorie. Und das schöne an Arduino ist, dass du weder auf die IDE festgenagelt bist, noch sonstwie eingeschränkt wirst. Du kannst C und C++ verwenden und auch immer noch direkt auf Register zugreifen, wenn du willst.
Ich hab da bisher immer einen Bogen herum gemacht :) Wie sieht das aus beim Kompilieren bezüglich Codesize und Geschwindigkeit gegenüber nativem Code?
abc schrieb: > Es ist nativer code...halt schön verpackt.. Und sau lahm. Weil jede Funktion darauf ausgelegt ist, dass sie von einem Affen mit Schlaganfall aufgerufen wird.
:
Bearbeitet durch User
Cyblord -. schrieb: > Und sau lahm. > Weil jede Funktion darauf ausgelegt ist, dass sie von einem Affen mit > Schlaganfall aufgerufen wird. Du meinst wohl hauptsächlich digitalWrite() und digitalRead(). Die muss man nicht benutzen. Betrachte sie als optionale Komfortfunktionen.
Hallo, @ TO: Du hast demnach beim lesen des Wortes 'Arduino' schon abgebrochen weiterzulesen? Dann hast du die fertigen Libs von MCUdude leider auch nicht verdient. Leichter kann man es nun wirklich nicht auf dem Silberteller serviert bekommen. Selbst für das Pin schalten sind schnellere Funktionen dabei. Müßtest ja nur das was du brauchst extrahieren. Aber wenn du nicht willst, dann eben nicht.
Der megaAVR bringt doch für die Ports schon "Komfortregister" zum Ein-, Aus- und Umschalten der Richtung und Ausgangswerte der Pins (DIRSET/DIRCLR/DIRTGL/OUTSET/OUTCLR/OUTTGL) mit. Wozu braucht man da noch Komfortfunktionen? Es kommt immer darauf an, was man machen möchte. Für simple Portansteuerung oder das Senden von ein paar Bytes per UART benötigt man sicherlich keine Bibliotheken. Bei komplexeren Aufgaben sieht das natürlich anders aus. Wenn der TE wirklich Bibliotheken verwenden möchte: Einfach die vorhandenen Bibliotheken auf den neuen AVR anpassen kommt für dich nicht in Frage? Mit etwas Glück hält sich der Aufwand in Grenzen.
:
Bearbeitet durch User
>Vielleicht ist hier was dabei: >https://github.com/MCUdude By the way: Sieht jemand den Unterschied zwischen dem "Migthy-Core" und dem "Mega-Core" in dem Repositiory? Warum gibt es zwei "Cöre"?
Florian S. schrieb: > Wozu braucht man da noch Komfortfunktionen? Zur Übersetzung der Arduino Port Nummern in AVR Port+Pin.
Stefan ⛄ F. schrieb: > Florian S. schrieb: >> Wozu braucht man da noch Komfortfunktionen? > > Zur Übersetzung der Arduino Port Nummern in AVR Port+Pin. Das ist sehr wichtig für intellektuell herausgeforderte Entwickler mit besonderen Bedürfnissen.
Cyblord -. schrieb: > Das ist sehr wichtig für intellektuell herausgeforderte Entwickler mit > besonderen Bedürfnissen. Schön formuliert. Warum haben die Arduino Erfinder sich diesen Quatsch eigentlich angetan?
Hallo, Gegenfrage. Warum soll das Quatsch sein? Dann wäre ja jede C++ OOP Lib Quatsch die man sich schreibt um sich das Leben einfacher zu machen. Um bei den Pins zu bleiben. Warum soll man sich in seinem Programmcode ständig mit Ports und Bits rumschlagen? Das macht auf Dauer keinen Sinn. In C schlägt man sich deswegen mit define Makros durch. In C++ gehts besser.
Veit D. schrieb: > Warum soll das Quatsch sein? Da fragt einer nach megaAVR 0 Libs, bekommt eine große Sammlung vorgesetzt. Die schmeckt ihm nicht. Soweit so gut. Damit könnte fertig sein. Aber dann kommen mal wieder die Basher aus den Büschen gesprungen, und es wird lustig. Leider ist denen mit Argumenten nicht bei zu kommen. Vorurteilsträger sind dafür nicht zugänglich! Da muss wohl irgendeine "Arduino Weltverschwörung" mit allen Mitteln unterbunden werden. Danke fürs lesen und Tschüss.
>von Stefan ⛄ F. (stefanus) >14.09.2021 10:44 >Cyblord -. schrieb: >> Das ist sehr wichtig für intellektuell herausgeforderte Entwickler mit >> besonderen Bedürfnissen. >Schön formuliert. Warum haben die Arduino Erfinder sich diesen Quatsch >eigentlich angetan? Tja, da sind wahrscheinlich 10 Millionen Arduinonutzer anderer Meinung als ihr zwei Spezialisten. Aber wenn du's wirklich wissen willst, kannst du es hier genau nachlesen: https://arduinohistory.github.io/
Markus schrieb: > https://arduinohistory.github.io/ Danke für den interessanten Link. Mein Resümee daraus ist das Open Source leider auch ausgenutzt wird. Leider.
Hi >Tja, da sind wahrscheinlich 10 Millionen Arduinonutzer anderer Meinung >als ihr zwei Spezialisten. Leute, fresst Scheiße, denn Millionen Fliegen können sich nicht irren. MfG Spess
Veit D. schrieb: > Mein Resümee daraus ist das Open > Source leider auch ausgenutzt wird. Entschuldige mal, aber das ist ein Sinn von Open Source. Schau dir mal die gängigen Lizenzen an, dann siehst du, dass kommerzielle Nutzung der Werke ausdrücklich vorgesehen ist. Wer das verhindern will, muss das halt in seinem Lizenztext verbieten. Die meisten Opern-Source Entwickler wollen es aber absichtlich zulassen.
Veit D. schrieb: > Um bei den Pins zu bleiben. Warum soll man sich in seinem Programmcode > ständig mit Ports und Bits rumschlagen? Das macht auf Dauer keinen Sinn. > In C schlägt man sich deswegen mit define Makros durch. Man kann einem Macro auch 2 Parameter übergeben und damit einen bestimmten Pin definieren. Damit ist man sehr flexibel, Pins nachträglich zu ändern. Ich schreibe diese Definitionen in ein "hardware.h". Das Arduino-Mapping einer Zahl auf einen Pin gilt nur für Arduion-Boards und läßt sich daher nicht auf eigene Projekte anwenden. Man müßte sonst eine zusätzliche Tabelle mit dem Mapping der magischen Zahl auf einen physischen Pin mitpflegen. Damit fügt man eine zusätzliche Fehlerquelle hinzu und der Betrachter des Schaltplans steht beim Debugging ziemlich ratlos da.
Sie dich erst mal auf der Microchip Seite um!³ Dann gibts auch noch den Code Configurator, der viel Tipparbeit erspart. In wie weit die AVRs bereits unterstützt werden kA. aber da sollte sich schon was finden lassen!
Es macht halt wenig Sinn von einer Portnummerierung auf eine Andere Portnummerierung zu abstrahieren. Das wird sowieso nur bei generischen Boards benötigt. Für eine spezielle Applikation abstrahiert man im Code so schnell wie möglich über die eigentliche Funktion. Und da ist es egal ob das PORTB.3 oder Pin 8 ist.
Teo schrieb: > Dann gibts auch noch den Code Configurator, der viel Tipparbeit erspart. Solche Wizards können schnell Ärger bereiten. Man ist dann auf Gedei und Verderb auf eine ganz bestimmte Umgebung angewiesen und kann nicht eben mal auf einen anderen Compiler wechseln. Und wenn man mal ein älteres Projekt wieder anfassen muß, wurde der Wizard mehrfach geändert und versteht die alten Datenformate bzw. alte Chipversionen nicht mehr. Die originale Wizardversion wurde natürlich von der Downloadseite entfernt oder geht mit aktuellen Windows/PCs nicht mehr.
Hallo, @ Stefan: Hast du den Link gelesen oder nur auf meinen Kommentar reagiert? Ich empfehle erstmal zu lesen. @ Peter: Es hält einen niemand davon ab auch bei eigenen Boards die Pins durchzunummieren. Wer das mag. Dann kann man mittels for Schleife darüber iterieren. Man kann den Nummern auch eindeutige Namen geben. In meiner Lib habe ich alle Möglichkeiten ohne Einschränkung. Ich kann einen Pin mit Nummer oder Namen ansprechen. Die Idee von MCUdude gefiel mir und habe ich übernommen. Das macht absolut keinen Unterschied. Weder in der Codegröße noch in der Geschwindigkeit. Am Ende spielt das weniger eine Rolle wie man denkt, weil man mit C++ in Objekten denkt (bzw. denken sollte) und weniger an die eigentliche Hardware. Ich sage nicht schalte Pin 2 ein sondern ich sage schalte Pumpe ein. Damit weiß ich beim Code lesen was geschalten wird. Und ich kann versehentlich weniger Unsinn machen. Bspw. kann ich einen konfigurierten Eingangspin nicht schalten.
1 | // In original Arduino sieht das so aus.
|
2 | // Man hat mit den Nummern im Grunde auch nur einmal etwas zu tun.
|
3 | const byte pumpe {2}; |
4 | pinMode(pumpe, OUTPUT); |
5 | digitalWrite(pumpe, HIGH); |
6 | |
7 | // Mit meiner Lib sieht das so aus. pumpe wird zum Objekt.
|
8 | OutputPin <2> pumpe; // oder bspw. OutputPin <pinPA2> pumpe; |
9 | pumpe.init(); |
10 | pumpe.setOn(); |
11 | |
12 | // Bei dir sieht das dann so oder so ähnlich aus.
|
13 | #define pumpe_OUT sbi (DDRA,2)
|
14 | #define pumpe_ON sbi (PORTA,2)
|
Das was du in deiner hardware.h stehen hast, steht bei mir Sinngemäß in einer Registertabelle. Bei einem angenommen neuen Boarddesign müssen wir beide nur die eine Datei anpassen. Die andere Datei bei mir mit den Methoden/Elementfunktionen bleibt ja immer gleich. Allen ist bewusst das die Arduino Pin Funktionen nicht gerade die Schnellsten sind. Für das Pin Schnelligkeitsproblem kenne ich einen User im Arduino Forum der das Problem gelöst hast. Das habe ich adaptiert, verstanden und für den ATtiny841, Nano Every Board und AVRxDB umgesetzt. MCUdude und Spencekonde haben das etwas anders im #define Style gelöst. Hat den Grund das die Schreibweise für den User nahezu identisch bleibt. Das Ergebnis ist in allen Fällen gleich. Es wird ein Takt zum Pin schalten benötigt. Damit ist die Schwachstelle vom Tisch. Aber nur um das klarzustellen. Mir ist es egal ob jemand C oder C++ programmiert. Soll jeder machen wie er mag. Grabenkämpfe sind eh sinnlos. Und wenn jemand Arduino nicht mag dann eben nicht. Nur dann soll er diese Leute in Ruhe lasen. Genauso wie ich Bascom und Assemblerprogrammierer in Ruhe lasse. Gegenseitig kann man dennoch etwas lernen bzw. mitnehmen. Es kommt auf die grundlegende Idee an. Umsetzen muss es dann jeder in seiner bevorzugten Programmiersprache. @ Teo: diesen Wizard habe ich einmal in Atmel Studio ausprobiert. Schrecklich. Es werden tausende Dateien erstellt durch die man sich erstmal durchwühlen muss um zu sehen wie die Funktionen denn nun lauten um sie zu nutzen. Und irgendwelche Timer zu konfigurieren macht darin auch keinen Spass. Weil man erst wissen muss was die Auswahlfelder genau bedeuten. Mit Manual und paar Zeilen Code tippen kommt man wesentlich besser und schneller zum Ziel und hat keinen Wust an Headerfiles. Das ist bestimmt alles gut gemeint, schießt aber am Ziel vorbei.
Veit D. schrieb: > Hast du den Link gelesen oder nur auf meinen Kommentar reagiert? Ich habe nur auf deinen Kommentar reagiert. Die Story von Arduino habe ich nur noch grob in Erinnerung, ich las sie vor ein paar Jahren mal komplett durch als ich Interesse daran hatte.
Peter D. schrieb: > Solche Wizards können schnell Ärger bereiten. Man ist dann auf Gedei und > Verderb auf eine ganz bestimmte Umgebung angewiesen und kann nicht eben > mal auf einen anderen Compiler wechseln. Jo, macht ja auch Sinn, hier den Compiler zu wechseln.....? Peter D. schrieb: > Und wenn man mal ein älteres Projekt wieder anfassen muß, wurde der > Wizard mehrfach geändert und Na dann gehts halt zu Fuß weiter, so als hätte es nie einen gegeben. Da wird ja nix kryptisches erzeugt! Und auch noch Dokumentiert..... Veit D. schrieb: > @ Teo: > diesen Wizard habe ich einmal in Atmel Studio ausprobiert. Schrecklich. > Es werden tausende Dateien erstellt durch die man sich erstmal > durchwühlen muss um zu sehen wie die Funktionen denn nun lauten um sie > zu nutzen. Und irgendwelche Timer zu konfigurieren macht darin auch > keinen Spass. Kenns nur aus dem MPLAB X und für PICs. Tausende? Nö! Viele, Ja klar, für jedes Modul zwei, foo.h und foo.c :) Zurechtfinden ist leicht. Nur muss man halt viel ungenutzten Sourcecode mit rumschleppen, sonnst wird die Weiterverwendung des Generators "nervig" (Code merging). Das MPLAB-X und Co, mit etlichen, seit Jahren nicht behobenen Bugs nervt, is ne andere Geschichte. :/
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.