Archiv verlassen und diese Seite im Standarddesign anzeigen : asuro lib 3.0 by MadMan2k
gibts in der asuro lib 3.0 eigentlcih irgenwelche grundlegenden unterschiede zur 2.6?
das einzige was mir azf die schnelle aufgefallen ist:
Go heist jetzt Travel
MotorDir heißt jetzt MotorState
Turn heißt jetzt Rotate
...
und die string.h wird nicht mehr benötigt.
ich hab die lieb von http://download.gna.org/asuro-tools/
ist das eigentlich offiziell, oder nur irgendetwas was sich jemand selber zusammengeschustert hat?
damaltor
19.11.2006, 09:52
also die lib 2.6 war privat erstellt worden, und bringt recht viele vorteile durch neue funktionen. ich vermute einfach mal, das das bei der 3.0 genauso ist
aber bei der 3.0 sind im wesentlichen keine neuen funktionen drinn...
nur die namen wurden leicht geändert.
damaltor
19.11.2006, 09:59
Hmmm.. dafür lohnt es sich aber eigentlich nicht, eine neue "haupt"version 3.0 rauszubringen... schau mal nach dem sourceforge projekt, wo es die 2.6 "offiziell" gibt. ist da auch schon 3.0 oder immer noch 2.6? vielleicht hat nur irgend jemand ein paar namen geändert und das dann für sich selbst 3.0 genannt
das es eine drei null veriopn geben soll, steht in der asuro wiki bei news
damaltor
19.11.2006, 10:06
oh ok... hmmm.. ich schau sie mir ma an.
damaltor
19.11.2006, 10:19
also ich kann auch nix neues finden... mal abwarten was die ander sagen.
das schwierigste wird, sich an odometrydata() zu gewöhnen...
m.a.r.v.i.n
19.11.2006, 11:23
Hi,
die Asuro Lib 3.0 wurde von RN-User madman2k erstellt.
Da es in letzter Zeit öfters Probleme mit der Erreichbarkeit von Sourceforge gab, wurde entschieden die neue Lib bei gna.org zu veröffentlichen.
Die 3.0 Version ist zwar auch im Sourceforge Repository, allerdings wurde sie dort bisher nicht released.
Die Änderungen zur 2.6 Version sind im wesentlichen:
* Anpassung an aktuelle AVR-GCC Versionen (signal.h)
* kleine Bugfixes, Aufräumarbeiten
* Umstellung der Ordner Strukturen
* Umbenennung einiger Funktionen (womit ich persönlich nicht einverstanden bin. Habe es selbst erst nach der Veröffentlichung bemerkt)
Leider ist madman2k derzeit der einzige, der diese Lib aktiv pflegt. Ich selbst komm leider kaum noch dazu. Wäre schön wenn sich vielleicht doch noch ein paar Leute finden würden.
Gruß m.a.r.v.i.n
damaltor
19.11.2006, 11:33
naja gut... also runterladen, die funktionen zurückbenennen und glücklich werden... o0
warum benennt der die funktionen um??? son quatsch... allein odometrYdata...
ich hab ne pn an madman2k geschrieben
vieleicht erhört er uns ja, und erklärt den sinn der änderung der namen der funktionen
damaltor
19.11.2006, 13:25
jo das wäre nicht schlecht...
nur mal rein interesse halber:
was für qualifikationen braucht man denn, um an der asuro lib mit zu programmieren?
damaltor
20.11.2006, 17:48
Eigentlich keine. Lade dir die Originale Lib runter, und verbessere sie, erweitere sie, führe sinnvolle Änderungen durch. dann Poste hier ins Forum "Ich habe das und das und das geändert." Und dann Haben Wir die ASuro Lib 3.0 von EDH. Und wenn sie sich durchsetzt, dann bist du der Held =)
oder frag diejenigen Benutzer, die die Lib entwickeln (z.B. MadMan2k) ob du Helfen darfst, bzw sag ihm was dir spontan an verbesserungen einfallen würde. dann gibts die Lib 3.1 von Madmal2k und EDH
also die erste verbesserung die mir einfällt ist diesen murks mit den namen wieder rückgängig zu machen :)
aber eigentlcih meine ich das anders.
wenn man z.b am linux gtk flash tool rumprogrammiert, sollte man sich
(1) mit linux und
(2) mit gtk
auskennen
was sollte man diesbezüglich können?
von programmierung mit windows hab ich zum beispiel gar keine ahnung
damaltor
21.11.2006, 10:13
na da solltest du ahnung von C und Mikrocontrollertechnik haben. wenn du alles verstehst, was in der originalen asuro.c drinsteht, dann kannst du sie auch deinen anforderungen anpassen. und wenn die anpassungen gut zu sein scheinen dann kannst du sie hier veröffentlichen.
MadMan2k
15.04.2007, 16:31
sorry, ich hab keine e-mail benachrichtigung wegen der PN bekommen und den thread erst jetzt entdeckt.
die funktionsnamen habe ich hauptsächlich zur besseren desktiptivität geändert.
Mit MotorDir konnte man z.B. auch in den Leerlauf schalten, worauf der Name nicht hingedeutet hat und bei der Gelegenheit hab ich auch den rechtschreibfehler bei odometrie korrigiert.
um die API Änderungen zu reflektieren habe ich die Versionsnummer auf 3 erhöht.
falls ihr an der lib mitarbeiten wollt müsst ihr euch bei gna.org registrieren und euch zumindest mit patch/ diff auskennen.
falls ihr nur ein mal was korrigieren wollt, reicht es wenn ihr es in einem bug report begründet und den entsprechenden patch dranhängt.
falls ihr dauerhaft mitarbeiten wollt, kann ich euch schreibrechte für das svn repository geben.
damaltor
15.04.2007, 18:09
tjo... wie du evtl bemerkt hast wird die "normale" lib weiter bearbeitet. vielleicht fragst du, ob du nicht da mitarbeiten kannst? wäre doch besser, als das projekt zu spalten.
die version 3.0 wird vom anderen projekt grbaucht werden. benenne deine lin doch anders, evtl Asuro Lib MM2k 3.0 oder so, in anlehnung an deinen nickname, damit die trennung zwischen dom RN-Lib-Projekt und deinem gewährleistet bleibt.
Zusammenarbeit ist besser als konkurrenz, melde dich doch mal bei der anderen Gruppe...
Hallo, hab mal ne Frage und zwar
Habe mir die 2.7 lib runtergeladen (die Objektorientierte) habe allerdings keine Ahnung wie ich sie zu Benutzen habe...?!?
hatte als Anfänger mit der 2.6er lib keine Probleme dank des praktisch vorgefertigten First Try Ordners.
Frage jetzt: Was mach ich mit den ganzen Programmschnippseln ... ?
Und wie hat die Datei zu heißen ( Test.c wirds wohl nicht sein)
Bitte für mich als Programmieranfänger verständlich antworten
Danke schonmal im Voraus
damaltor
15.04.2007, 18:33
bitte lies den rest des threads. da ist alles erklärt.
alternative: lies die doku, die im archiv enthalten ist.
hier nochmal ein link zum thread der version 2.70, also der roboternetz-original-version:
https://www.roboternetz.de/phpBB2/viewtopic.php?t=26594
MadMan2k
15.04.2007, 19:00
tjo... wie du evtl bemerkt hast wird die "normale" lib weiter bearbeitet. vielleicht fragst du, ob du nicht da mitarbeiten kannst? wäre doch besser, als das projekt zu spalten.
das lustige ist, dass ich das schon vor dem release der 3.0 gemacht habe und meine Änderungen dort im Branch 3.0 abgelegt wurden, den ich dann nachdem keine Änderungen vorgeschlagen wurden und das Projekt insgesamt stagniert hat als Version 3.0 übrer gna.org herausgebracht habe. (in absprache mit marvin)
die Änderungen die Interrupts in avr-libc 1.4+ betreffend wurden übrigens nicht in die 2.7 zurückportiert. Und da marvin bei gna.org zu mir gleichwertiger Admin ist frage ich mich wieso man für die 2.7 die veraltete codebase genommen hat und warum man jetzt bei der immernoch veralteten beleiben sollte...
kann ich da die alten Dateien Asuro.src\firsttry bei 2.7 weiterbenutzen oder muss ich mir was neues anlegen.
z.B. im winavr Verzeichnis oder so... :-k :-k
damaltor
15.04.2007, 19:37
tjo... wie du evtl bemerkt hast wird die "normale" lib weiter bearbeitet. vielleicht fragst du, ob du nicht da mitarbeiten kannst? wäre doch besser, als das projekt zu spalten.
das lustige ist, dass ich das schon vor dem release der 3.0 gemacht habe und meine Änderungen dort im Branch 3.0 abgelegt wurden, den ich dann nachdem keine Änderungen vorgeschlagen wurden und das Projekt insgesamt stagniert hat als Version 3.0 übrer gna.org herausgebracht habe. (in absprache mit marvin)
die Änderungen die Interrupts in avr-libc 1.4+ betreffend wurden übrigens nicht in die 2.7 zurückportiert. Und da marvin bei gna.org zu mir gleichwertiger Admin ist frage ich mich wieso man für die 2.7 die veraltete codebase genommen hat und warum man jetzt bei der immernoch veralteten beleiben sollte...
das die änderungen schon vorher bestanden wusste ich, meiner meinung nach ist es allersings ein fehler (ganz besonders gegenüber anfängern) die funktionen umzubenennen. das forum hat auch entsprechend reagiert.
egal, ich will diene arbeit nicht schlecht machen oder kritisieren, im gegenteil, es ist echt klasse wenn weiterentwickelt wird. trotzdem sollte zusammengearbeitet werden. nicht alles was veraltet ist, ist schlecht, wind*ws vista zB hat mehr bugs als eine ameisenkolonie. also sprich mit den anderen, arbeitet zusammen und helft euch gegenseitig, sonst spaltet sich das projekt und das macht es weder für profis noch für anfänger einfacher. also frag doch einfach mal, warum die alte codebase verwendet wird. vielleicht hat es ja einen grund...
MadMan2k
16.04.2007, 14:02
das die änderungen schon vorher bestanden wusste ich, meiner meinung nach ist es allersings ein fehler (ganz besonders gegenüber anfängern) die funktionen umzubenennen.
naja, wenn ein anfänger auf die Lib wechselt, wir er eh die doku wegen den neuen funktionen dazu lesen müssen. Dort kann man dort die Umbenennung vermerken. Die "neuen" Anfänger kann man dann direkt an die neue lib verweisen.
Ich finde es nämlich besser die Bennenung konsistent in englisch zu halten als ewige alte Zöpfe mitzuschleppen. Meinetwegen können wir auch eine Übergangszeit festlegen in der die funktionen deprecated aber noch vorhanden sind.
. nicht alles was veraltet ist, ist schlecht, wind*ws vista zB hat mehr bugs als eine ameisenkolonie.
also übertragen auf die libs darfst du gerne etwas konkreter werden ;)
mit veraltet meinte ich, dass die fehler die ich in der 3.0 gefixt habe noch in der 2.7 drin sind.
damaltor
16.04.2007, 15:04
naja, die alte lib hat fehler. was solls, sie funktioniert recht gut. trotzdem ist nicht zwingend die neue version fehlerfrei; dazu müsste sie erstmal im dauertest laufen. warum meldest du dich nicht mal bei der anderen gruppe, sagst, du willst mitmachen und hast ein paar ideen und bugfixes, und ihr führt das alles wieder zusammen? es ist sehr schade wenn so ein (relativ) großes projekt sich spaltet aus mangelnder zusammenarbeit.
die umbenennung der funktionen:
klar sind die rechtschreibfehler von arexx recht dämlich (break, odometrie usw). aber 99,9 % der geschriebenen programme basieren auf diesen fehlern. man müsste also alle demo-programme von arexx, alle programme hier aus dem forum, alle, die man evtl schonmal geshrieben hat usw ändern bevor man mit der neuen lib arbeiten kann.
sowie das programm kompiliert ist, interessieren die schreibfehler ohnehin keinen mehr, warum sollte man also so eine (zwar fachlich korrekte, aber aus anwendersicht recht unnötige) änderung vornehmen?
m.a.r.v.i.n
16.04.2007, 15:52
Hi,
hier mal mein Vorschlag zur Güte, damit hoffentlich wieder alle glücklich und zufrieden sind:
* wir mergen beide Libs zu einer Version zusammen. Bugfixes aus der 3.0 Version und Doku und neue Funktionen aus der 2.7 Version. Die Doku sollte 2-sprachig de-en bleiben, wie bereits in der 2.7rc3 Version.
* Die nichtenglischen Funktionsnamen und Definitionen werden in englische umbenannt. Trotzdem bleibt die alte Schreibweise als Define vorhanden, damit sich auch alte Quellen ohne Änderungen übersetzen lassen. In der Doku werden die alten Schreibweise als veraltet gekennzeichnet. Die mitausgelieferten Beispiele in der Lib werden auf die neue Schreibweise umgestellt. (ist teilweise auch schon so in der 2.7rc3 gemacht)
* Ob das Repository bei Gna oder Sourceforge liegt, ist mir erstmal egal. 1 Repository sollte längerfristig genug sein. Neue Releases sollte man allerdings auf beiden Servern veröffentlichen.
Hab ich noch irgendwas vergessen, Gegenvorschläge?
damaltor
16.04.2007, 16:02
nein, find ich klasse. so sollte das sein =)
radbruch
16.04.2007, 17:29
MotorPower() als Ersatz für MotorSpeed()?
Ach ja, man könnte die neuen Funktionsnamen doch als #define ergänzen, dann würden auch die alten Programme laufen.
MadMan2k
16.04.2007, 19:49
Hi,
hier mal mein Vorschlag zur Güte, damit hoffentlich wieder alle glücklich und zufrieden sind:
* wir mergen beide Libs zu einer Version zusammen. Bugfixes aus der 3.0 Version und Doku und neue Funktionen aus der 2.7 Version. Die Doku sollte 2-sprachig de-en bleiben, wie bereits in der 2.7rc3 Version.
* Die nichtenglischen Funktionsnamen und Definitionen werden in englische umbenannt. Trotzdem bleibt die alte Schreibweise als Define vorhanden, damit sich auch alte Quellen ohne Änderungen übersetzen lassen. In der Doku werden die alten Schreibweise als veraltet gekennzeichnet. Die mitausgelieferten Beispiele in der Lib werden auf die neue Schreibweise umgestellt. (ist teilweise auch schon so in der 2.7rc3 gemacht)
* Ob das Repository bei Gna oder Sourceforge liegt, ist mir erstmal egal. 1 Repository sollte längerfristig genug sein. Neue Releases sollte man allerdings auf beiden Servern veröffentlichen.
Hab ich noch irgendwas vergessen, Gegenvorschläge?
1. meiner Meinung nach sollte die doku in den sources auf alle fälle englisch sein. Dazu sollte es noch HTML alternativen in anderen Sprachen. (einschließlich deutsch) geben.
2. wär ich auch dafür. leider lässt sich nicht alles über den präprozessor umbiegen. "compat.h"?
3. auf gna hab ich schon den asuro flasher und man kann ohne viel umstellung auch den neuen bootloader hinzufügen. außerdem sind die server von gna deutlich flotter. daher wäre ich hier für gna.org.
außerdem hätte ich noch eine Anmerkung zur Änderung 2.6 -> 2.7:
aufsplitten in viele dateien. warum? ich würde hier höchstens in die kern bibliothek mit der ursprünglichen funktionalität und einige extra libs wie für I2C, UltraSchall etc. unterschieden.
Zudem würde ich noch einige zu spezifische Funktionen ausgliedern und nur optional anbieten. (PrintInt)
damaltor
16.04.2007, 20:42
die teilung ist dazu da, um kleinere hex-files zu produzieren. so werden nur die tatsächlich gebrauchten funktionen mitkompilieren.
Sternthaler
16.04.2007, 21:34
Hallo zusammen (ja zusammen)
Ich war gerade auf dem gna.org-Server, da mich das Thema ja gerade wegen der Doku auch interressiert.
Die auf dem Server abgelegte Doku ist etwas 'schmaler' als die bis jetzt unter sourceforge vorhanden Doku. Das ist nicht so dramatisch.
Aber wie kann ich die doppelt verpackte Lib auspacken. Für tar hätte ich ja was, aber das bz2 kennen meine Entpacker und ich nicht.
damaltor
17.04.2007, 09:10
dann musst du die .zip runterladen...
tar.bz2 ist ein typisches linux-zip-format. der bzip2-algorithmus ist sehr stark, kann aber nur einzelne dateien komprimieren. darum werden alle dateien vorher zu einem tarball zusammengeklebt (tarball - klebrige teerkugel). dadurch werden sie nicht komprimiert (eher im gegenteil, sie werden einige bytes größer), aber danach lässt sich der tarball als einzelne datei mit bzip2 komprimieren.
es sollte auch eine .zip dabei sein; ansonsten nimmt winrar die datei so wie sie ist.
www.rarlabs.com
Hi Sternthaler,
Here you are...
Regards,
_HP_
MadMan2k
17.04.2007, 13:50
die teilung ist dazu da, um kleinere hex-files zu produzieren. so werden nur die tatsächlich gebrauchten funktionen mitkompilieren.
das wird vom Compiler sowieso gemacht - unabhängig davon auf wie viele Dateien die Funktionen verteilt sind!?
edit:
wegen dem archiv: www.7-zip.org kann so ziemlich alles öffnen.
Hi MadMan,
danke für den Link - den Packer kannte ich noch nicht. Aber nur so unter uns (es heißt: wegen des Archives ;-) )
Gruß,
_HP_
damaltor
17.04.2007, 16:14
hmm... naja vielleicht ist es aufgeteilt um es etwas übersichtlicher zu halten, so dass halt nicht so große dateien da sind... naja. mich störts nicht, die dinger braucht man normalerweise ohnehin nur einmal irgendwohinkopieren; und dann ist das ok...
m.a.r.v.i.n
17.04.2007, 16:42
Hi,
das wird vom Compiler sowieso gemacht - unabhängig davon auf wie viele Dateien die Funktionen verteilt sind!?
Das stimmt so nicht. Der Compiler bzw. Linker bindet immer alle Funktionen eines Files ein, egal ob die Funktion aufgerufen wird oder nicht.
Hier mal zum Vergleich ein paar erzeugte Codegrößen:
Version 2.7.0rc3 3.0
FirstTry 658 1896 Bytes
LineTest 1338 2146 Bytes
IRCollision 1686 2038 Bytes
SelfTest 3844 4230 Bytes
1. meiner Meinung nach sollte die doku in den sources auf alle fälle englisch sein. Dazu sollte es noch HTML alternativen in anderen Sprachen. (einschließlich deutsch) geben.
Wie soll man dann mit dem Doxygen Tool eine deutsche Doku erstellen?
Mir ging es nur um die Doxygen Kommentare.
In der Lib 2.7 werden z.B. die Header Files in englisch dokumentiert (mit \lang english) und die Sourcefiles in deutsch (evtl mit \lang german). So hat man eine saubere Trennung bei der Erzeugung der Doxygen Doku.
2. wär ich auch dafür. leider lässt sich nicht alles über den präprozessor umbiegen. "compat.h"?
was geht denn z.B nicht?
aufsplitten in viele dateien. warum? ich würde hier höchstens in die kern bibliothek mit der ursprünglichen funktionalität und einige extra libs wie für I2C, UltraSchall etc. unterschieden.
Zudem würde ich noch einige zu spezifische Funktionen ausgliedern und
nur optional anbieten. (PrintInt)
Genau das passiert bei Verwendung der Objekt-Library. Die nicht verwendete Funktions Gruppen (Fileorientiert) werden auch nicht gelinkt. Man braucht dazu nichts ausgliedern. Wer die Funktion nicht verwenden will, läßt es halt bleiben.
Hallo, hab mal ne Frage und zwar
Habe mir die 2.7 lib runtergeladen (die Objektorientierte) habe allerdings keine Ahnung wie ich sie zu Benutzen habe...?!?
hatte als Anfänger mit der 2.6er lib keine Probleme dank des praktisch vorgefertigten First Try Ordners.
Frage jetzt: Was mach ich mit den ganzen Programmschnippseln ... ?
Und wie hat die Datei zu heißen ( Test.c wirds wohl nicht sein)
Die Objekt Lib hat nichts mit objektorientiert zutun. Das bedeutet nur das die C-Files vorkompiliert sind (zu Objekt Files) und daraus eine Lib (Archiv) gebastelt wurde. Für neue oder alte Projekte bleibt alles wie gehabt. Nur die Makefiles sind leicht modifiziert (siehe examples).
MadMan2k
17.04.2007, 19:32
Das stimmt so nicht. Der Compiler bzw. Linker bindet immer alle Funktionen eines Files ein, egal ob die Funktion aufgerufen wird oder nicht.
ok, stimmt. hatte mir schlechte Beispiele zum ausprobieren gesucht.
1. meiner Meinung nach sollte die doku in den sources auf alle fälle englisch sein. Dazu sollte es noch HTML alternativen in anderen Sprachen. (einschließlich deutsch) geben.
Wie soll man dann mit dem Doxygen Tool eine deutsche Doku erstellen?
Mir ging es nur um die Doxygen Kommentare.
In der Lib 2.7 werden z.B. die Header Files in englisch dokumentiert (mit \lang english) und die Sourcefiles in deutsch (evtl mit \lang german). So hat man eine saubere Trennung bei der Erzeugung der Doxygen Doku.
am besten wäre es wohl alle Übersetzungen in den Header zu packen. Denn die aktuelle Lösung ist auch nur mit 2 Sprachen machbar und wenn man am source arbeitet sind englische kommentare essentiell.
2. wär ich auch dafür. leider lässt sich nicht alles über den präprozessor umbiegen. "compat.h"?
was geht denn z.B nicht?
SerWrite ohne Längenargument. Wo ich jetzt aber länger drüber nachgedacht habe wäre das aber wohl die einzige funktion.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.