was muss ich machen, wenn ich kein winavr benutze? bin linux-user und kompiliere den mit kate geschriebenen qullcode mit avr-gcc. wohin müssen die dateien dann kopiert werden? die .h bleibt vermutlich da wo sie immer war, aber die .a datei?
Druckbare Version
was muss ich machen, wenn ich kein winavr benutze? bin linux-user und kompiliere den mit kate geschriebenen qullcode mit avr-gcc. wohin müssen die dateien dann kopiert werden? die .h bleibt vermutlich da wo sie immer war, aber die .a datei?
Entweder du schiebst die Dateien in die include bzw. lib-Verzeichnisse deiner avr-gcc-Installation (bei mir zb. zu finden unter /usr/local/avr/avr/) oder aber du gibst im makefile deines aktuellen Programms einfach -I/pfad/zu/asuro.h in den CFLAGS und -L/pfad/zu/libasuro.a in den LFLAGS an. In beiden Fällen genügt dann im Programmkopf ein #include <asuro.h> und alles sollte klappen.Zitat:
Zitat von damaltor
btw: Solltest du die lib neu übersetzen wollen, muss noch schnell in deren makefile CC auf avr-gcc gesetzt werden, ebenfalls empfehlen kann ich -Os statt O2 :).
Was die userspezifischen Konstanten angeht, so ist ein Block von #defines (entweder in der asuro.h oder in einer weiteren Datei) sicher eine gute Idee, allerdings leuchtet mir im Moment nicht ein, warum man das ganze in eine Struktur packen sollte. Mit dem RAM-Verlust erkauft man sich doch auf diese Art eigentlich nur den "Luxus", dass jemand, der sich die lib besorgt diese nicht selbst compilen muss (so denn libasuro.a im Package erhalten bleibt). Irgendwie erscheint es mir gerade einfacher, schnell nach einmaligem anpassen der config make aufzurufen (evtl auch direkt mit nem install) und dafür auf die Struktur zu verzichten...
Perfekt, vielen Dank. bis jetzt scheints zu funktionieren =)
Hi,
oh ja, die Linux-User hätte ich fast vergessen.
Stimmt, das spart ebenfalls noch ein paar Bytes ein.Zitat:
ebenfalls empfehlen kann ich -Os statt O2
Deswegen wollen wir das ja hier auch erst diskutieren, bevor wir irgendetwas festklopfen. Klar, wäre es einfacher und Ressourcen sparender direkt mit den Defines zu arbeiten. Dann muß halt jeder User die Lib selbst übersetzen, wenn er die Werte ändert.Zitat:
Was die userspezifischen Konstanten angeht, so ist ein Block von #defines (entweder in der asuro.h oder in einer weiteren Datei) sicher eine gute Idee, allerdings leuchtet mir im Moment nicht ein, warum man das ganze in eine Struktur packen sollte. Mit dem RAM-Verlust erkauft man sich doch auf diese Art eigentlich nur den "Luxus", dass jemand, der sich die lib besorgt diese nicht selbst compilen muss (so denn libasuro.a im Package erhalten bleibt). Irgendwie erscheint es mir gerade einfacher, schnell nach einmaligem anpassen der config make aufzurufen (evtl auch direkt mit nem install) und dafür auf die Struktur zu verzichten...
Im Hinterkopf hatte ich aber auch noch ein Kalibrierprogramm, das diese Werte weitestgehend automatisch ermittelt und dem Nutzer dann Vorschläge macht, welche Werte er nehmen soll. Oder noch komfortabler, die Werte gleich in den EEPROM Bereich schreibt, um sie dann beim Programmstart von dort auszulesen.
klar, der eeprom wäre hierfür gut zu nutzen. ausserdem ist er einfach und unkompliziert anzusprechen. die init-funktion würde dann wahrscheinlich gleich die entsprechenden werte abfragen, oder eben die entsprechende funktion die die werte benötigt. an sich: tolle idee, aber:
-> 99% der neuen user, die sich blind die neue lib runterladen werden sich wundern dass "es nicht geht", da sie das kalibrierungsprogramm noch nicht ausgeführt haben und deshalb in jeder zelle des eeprom "." steht. und dann hier einen thread nach dem anderen eröffnen =)
-> ich benutze den eeprom in einigen meiner programme. damit gehöre ich zwar nicht zur masse der user (vermute ich mal) aber es wird bestimmt einige geben. die müssten dann entsprechende änderungen vornehmen, und wahrscheinlich wäre der eeprom dann auch für eigene projekte mit vorsicht zu geniessen. sowie man (auch aus versehen) in eine falsche zelle schreibt, gehen alle anderen programme nicht mehr. und dann darauf zu kommen dass man das kalibrierungs programm wieder mal ausführen muss... ich glaub ich würde ewig suchen.
-> wären dann alle diese variablen in den ram geladen, wäre dieser wahrscheinlich auch recht schnell sehr voll - 1 kilobyte ist nicht sehr viel, und diesen mit variablen zu füllen, die während des ganzen programms konstant bleiben wäre unnötig. man könnte das ganze über eine funktion regeln, die den eeprom liest und den wert zurückgibt, und diese funktion dann an jeder stelle wo ein wert gebraucht wird einsetzen, aber das würde dann recht stark auf kosten der performance gehen.
darum bin ihc für ein kalibrierungsprogramm, welches werte zurückgibt die man dann entsprechend eintragen muss. am besten mit einer absolut idiotensicheren anleitung, was wie wo hingeschrieben werden muss und was dann passieren muss. das spart viel unnötige fragerei und hält den eeprom frei und den ram noch dazu.
Das Problem liese sich umgehen, wenn im EEPROM nach einer Magic-Number gesucht wird und falls diese nicht vorhanden ist, Default-ASURO Werte verwendet - oder die Kallibrierroutinen automatisch gestartet werden.Zitat:
-> 99% der neuen user, die sich blind die neue lib runterladen werden sich wundern dass "es nicht geht", da sie das kalibrierungsprogramm noch nicht ausgeführt haben und deshalb in jeder zelle des eeprom "." steht. und dann hier einen thread nach dem anderen eröffnen =)
Was mir da eher Sorgen macht, ist dass die Einbindung der EEPROM-Routinen wieder eine ganze Menge Programmspeicher fressen könnte.
Gruss,
stochri
Hallo
Ich lese zwar nicht richtig mit, aber für die myasuro-Daten bei meinen eigenen Progs plane ich ein Kalibrierungsproggi das nach Abschluss die Ergebnisse als Textdatei zum Terminal sendet. Dort kopiere ich dann die Daten und speichere sie als Datei die ich dann zusätzlich zur Standart-Lib einbinden möchte.
Gruß
mic
das wäre eigentlich das einfachste, eine komplett ausformulierte datei, die nur noch gespeichert werden muss.
allerdings würde wenn beim übertragen ein einziges byte fehlt oder fehlerhaft übertragen wird, die ganza ktion für die katz sein.
das problem mit der magic number zu lösen ist fein, und auch die eeprom-routinen sind nicht sehr komplex. es werden zum schreiben (wenn ich mich recht erinnere) 3 register geschrieben, und zum lesen wird ein register geschrieben und einer gelesen. kein problem also. allerdings immer noch komplexer und speicherintensiver als konstante werte, die durch zB kalibrierungen fest mit einkompiliert werden. ich denke eher an den ram, der nämlich schon recht gut gefüllt werden dürfte mit daten, die konstant sind - und meiner meinung nach auch so behandelt werden sollten. konstanten werden vor dem kompilieren festgelegt und dann mit kompiliert. dann lieber eine möglichkeit mithilfe der kalibrierung werte zu ermitteln und diese dann zu speichern, und sich dann nicht mehr drum scheren zu müssen ob der eeprom nun bereits gefüllt ist, ob man mit den eigenen daten den wichtigen daten ins gehege kommt (davor schützt auch eine magic numer nicht, da müssten wir schon mit checksums o-Ä. anfangen) und dann einfach wie gewohnt weiterarbeiten.
Hi,
OK. Damit ist wohl entschieden, die Defines direkt zu verwenden, und nicht über zusätzliche Variablen.
Vielen Dank für die konstruktiven Beiträge. Weiter so.
Hi Leute,
Um eventuelle Probleme mit den Speicherpositionen im EEPROM zu umgehen, könnte man folgendermassen vorgehen:
Ist der Wert in der myasuro.h z.B. mit 0 definiert, soll es bedeuten, dass der Wert im EEPROM vorhanden ist und von dort, aus einer noch zu definierenden Adresse, geholt werden muss. Oder es würde bedeuten, dass eben ein in der Init()-Funktion hinterlegter Defaultwert (define) benutzt wird.
Ist aber etwas in der Datei definiert, dann wird erst gar nicht im EEPROM, oder im Init()-Default, nachgeschaut. -> Friss oder Stirb, aber eben ohne Probleme mit den Adressen im EEPROM.
Der Speicherplatzverbrauch im RAM ist, so wie m.a.r.v.i.n schon geschieben hat, zwar vorhanden, aber bis jetzt sieht es so aus, als ob alle Parameter, bis auf einen, als Byte abgelegt werden können. (Der eine wäre ein int, also 2 Byte)
Die bis jetzt vorgeschlagene Parameteranzahl würde also zu einem 'Verbrauch' von 8 Byte betragen. Da ich mir noch einen weiteren Parameter wünsche, wären es dann 9 Byte.
Ich halte dies für einen angemessenen 'Preis', die Lib doch allgemein zu halten.
Ausserdem hat es stochri schon angesprochen: Eine Lese-Funktion für das EEPROM mag noch so klein sein, aber sie belegt auf alle Fälle einiges an Speicher, den wir ja mit dem Gedanken einer Lib eben sparen wollen. (OK, OK, RAM und ROM sind was anderes.)
Die Befürchtung, dass neue Asuro-Besitzer, nicht mit der Lib, bzw. einer myasuro.h, klarkommen werden, kann ich verstehen. Hier ist eben eine gute Unterstützung durch eine möglichst 'wasserdichte' readme.txt zu gewährleisten. Ich würde diese erste Hilfe auch nicht in der HTML-Doku sehen, da man diese ja erst finden und 'starten' muss. (Auch der Weg zur HTML-Doku darf dann natürlich in dieser readme.txt stehen)
Dann tauchte noch die Frage auf, warum eine eigene Datenstruktur 'angedacht' ist. Erstens steht dies nicht fest, ist ja schliesslich unser aller LIB, und auf der anderen Seite findet man solche Variablen einfach besser im Source wieder, wenn man nach dem Strukturnamen suchen kann. Bis jetzt ziehen sich die hier angedachten Variablen durch die Sourcen asuro.c, encoder.c, switches.c und für die Variablendefinition globals.c. Da diese Variablen ja global gültig sein sollen/müssen, ist es ein Ansatz über den Strukturnamen zu sehen wozu sie denn überhaupt gehören. Meines Wissens nach benötigt dies weder mehr Speicherplatz noch Rechenzeit um auf eine Struktur zuzugreifen.
Da ich gerade beim schreiben noch von damaltor 'überholt' wurde, hier auch noch mein Senf zu den Kalibrierungsroutinen.
Grundsätzlich bin ich da absolut für. Aber genau hier muss eben auch an die Anfänger gedacht werden. Wie soll man vermitteln, dass man vor dem Gebrauch der Lib erst noch ein/einige Programm/e auf den Asuro laden muss; diese nach einer Bedienungsanleitung (lesst ihr die immer?) ablaufen lassen muss; eine Terminalemulation gerade auf Empfang steht um da ein paar Bytes in einer Datei natürlich an einer bestimmten Stelle zu speichern.
Tschuldigung, dass ich hier etwas 'ätzend' schreibe, bitte keinesfalls so verstehen, aber ich bin schon der Meinung, dass man versuchen muss eben beide Typen von Usern glücklich zu machen.
Anfänger bekommt eine für ihn editierbare Datei myasuro.h. (plus readme)
Profi kann immer noch die Lib selber umbauen und machen was er will um die Parameter zu erhalten. (Gute, schöne, schnelle, sparsame und natürlich alle glücklichmachende Lösungen unbedingt hier im Thread posten)
Schön, dass hier so viel los ist.
Ich sollte weniger, oder schneller, schreiben.
Hallo m.a.r.v.i.n
Die Daten wären reines ascii und die Datei gegebenenfalls editierbar. Natürlich sollte die Lib mit Defaults laufen. Neulinge, die mit den Ergebnissen mit defaults nicht zufrieden sind, werden sicher auch in der Lage sein, die myasuro-Datei zu erzeugen. Und die Zufriedenen werden sich nicht dran stören.
Das Kalibrierungsproggi kann man bestimmt gut als erweitertes selftest unter die Leute bringen.
ja das ist wahr, also ein kalibrierungsprogramm sollte möglich sein, und das halte ich auch für sehr sinnvoll. es müsste allerdings die datenübertragung möglichst sicher gestaltet werden, damit nicht aufgrund eines fehlerhaften bytes irgend ein mist übertragen wird und der dann in allen (!) programmen kompiliert wird. evtl sollte der nutzer zum abgleich den empfangenen wert nochmal eingeben oder so etwas.
braucht ein integer wirklich nur 2 bytes? wo steht, welchen typ die variable hat? signed oder unsigned? ich kenne mich mit speicherarchitekturen nicht besonders aus, es reicht gerade für ein paar grundsätzliche pointer und adressoperationen. ansonsten könnte man ja die letzten paar bytes des eeprom reservieren, beispielsweise alle über 500 oder alle über 480 oder so. allerdings sollte eine lib so knapp wie möglich sein und deshlab nicht immer auf den eeprom angewiesen sein. auch die wiederkehrenden eeprom lese aktionen machens nicht zwingend einfacher und auch wenn sie nur ein paar bytes belegen müssen die einfach nciht sein.
ich bleibe bei den defines =)
hier mal beispielcode zum schreiben eines bytes in den eeprom (übergeben werden die adresse (ein wert zwischen 0 und 511 bzw 0 und 0x1F) und die daten (ein char)
und zum lesen muss nur die adresse übergeben werden:Code:void EEPROM_write(unsigned int uiAddress, unsigned char ucData)
{
/* Wait for completion of previous write */
while(EECR & (1<<EEWE))
;
/* Set up address and data registers */
EEAR = uiAddress;
EEDR = ucData;
/* Write logical one to EEMWE */
EECR |= (1<<EEMWE);
/* Start eeprom write by setting EEWE */
EECR |= (1<<EEWE);
}
Diese funktionen sind direkt aus dem datenblatt genommen, ich vermute deshalb dass sie so minimalistisch wie möglich sind. aber eben trotzdem eigentlich unnötig.Code:unsigned char EEPROM_read(unsigned int uiAddress)
{
/* Wait for completion of previous write */
while(EECR & (1<<EEWE))
;
/* Set up address register */
EEAR = uiAddress;
/* Start eeprom read by writing EERE */
EECR |= (1<<EERE);
/* Return data from data register */
return EEDR;
}
@radbruch
Das mit den Möglichkeiten eines Kalibrierungsprogramms sehe ich ja auch als sehr gute Idee, um seinen eigenen Asuro möglichst perfekt einzustellen.
Ich wollte hier darauf hinweisen, dass es wichtig ist, jetzt schon mal über die Technik zum Einbinden von 'externen' Konfig-Daten nachzudenken. (Hätte ich ja auch schon füher schreiben können. ](*,) )
ABER VIEL WICHTIGER zum aktuellen Release Candidate 2.
In der Doku zur Funktion EncoderStart() in encoder.c habe ich als Fehler beschrieben, dass die Funktion nicht geeignet ist die Rad-Encoder-Automatik wieder zu starten nach einem EncoderStop().
DAS DORT VON MIR ALS FEHLER BESCHRIEBEN VERHALTEN STIMMT SO NICHT.
stochri hat (natürlich) alles richtig gemacht, da er in EncoderInit() den ADC-Wandler im sogenannten 'free running'-Mode startet. Damit ist es eben doch Möglich die Automatik zu stoppen und mit EncoderStart() wieder zu starten. Tut mir Leid, Doku wird korrigiert.
Na das klingt doch gut...
mehr ideen morgen, ab ins bett jetzt kinder =)
@damaltor (ich werde immer erst um diese Zeit wach)
int ist tatsächlich nicht immer 2 Byte groß. Die tatsächliche Größe hängt vom verwendeten Rechner/CPU (evl. Compiler) ab.
Aus diesem Grund gibt es auch noch eine andere Variante um integer-Variablen zu definieren. Da werden dann z.B. die Typen uint32_t oder int16_t benutzt.
Das u bedeutet dann, dass der Wert als unsingned zu interpretieren ist, und die Zahl gibt die BIT-Anzahl an.
Diese Typen sind in der Include-Datei [AVR-Installation]\avr\include\inttypes.h definiert und stellen auf jedem System sicher, dass die Variablen tatsächlich immer die Größe haben, die der Programmierer haben möchte.
Bei dem unsigned ändert sich auf keinen Fall etwas an der BIT-Anzahl. Du kannst in einer mit 'unsigned char' oder eben mit uint8_t Zahlen zwischen 0 und 255 in den 8 Bits speichern. Wird die Variable als 'char' oder int8_t definiert, ändert sich der Bereich zu -128 bis +127.
Komisch: Eigendlich kannst du in beiden Typen doch immer nur 8 Bits an- bzw. ausgeknipst setzen. Wo kommt also das Vorzeichen mal her und dann doch wieder ohne Vorzeichen.
--> Das Höchstwertige Bit wird bei den signed-Werten einfach mal so als Vorzeichen INTERPRETIERT (0=Plus; 1=Minus und dann kommt da noch bei den negativen Zahlen das 2'er-Komplement hinzu. Bitte weiter fragen bei Bedarf.)
Bei den UNsigned-Werten wird das höchste Bit als weiteres Bit für den Zahlenwert benutzt.
P.S.: Danke für deine Code-Stücke für das EEPROM.
also dass das von der architektur abhängt, das hab ich schonmal gehört, und das zweierkomplement kenne ich auch. so ganz grob weiss ich wie das aussehen muss, aber beispielsweise wird bei float-zahlen doch auch das vorzeichen als eigenes bit gespeichert (0=+,1=-), dann der exponent + BIAS, dann die normierte mantisse ohne 1. irgendwo muss doch vermerkt werden, ob ein wert nun unsigned ist oder nicht, ansonsten wüsste ja niemand ob man 11111111 nun als 255 oder asl -127 ausgeben / rechnen sollte... aber naja. auf die paar bytes kann man zwar wahrscheinlich verzichten, das ist schon wahr. aber ich denk dann immer, man müsste nicht drauf verzichten, schliesslich könnten die werte genausogut einmal definiert werden und dann verwendet werden. schliesslich wurde ja auhc die lib zerlegt, um immer mal einige bytes der nicht benötigten funktionen sparen zu können.
Hallo Lib-Entwickler,
nachdem ich mich eine Weile mit der Frage herumgeschlagen hatte, warum es eine myasuro.h Datei gibt, diese aber nirgends verwendet wird, habe ich in diesem Thread den Grund gefunden. Es wäre wünschenswert, wenn der Hinweis, das diese Werte noch keine Bedeutung habe auch im Kommentar der Datei selbst stehen würde.
Und was mir noch aufgefallen ist: Der 72kHz - Timer wurde auf 36kHz geändert. Leider steht nirgens WARUM?! Könntet Ihr mir das bitte erklären und dann auch in die Doku einfließen lassen. Das wäre Klasse.
Zur Diskussion um die ASURO-spezifischen Werte: Ich bin auch dafür, diese von jedem Nutzer selbst ermiteln zu lassen - und zwar mit gut dokumentierten Testprogrammen. Das fördert das Verständnis über die Sensorproblematik erheblich, und wenn es dann klappt, dann weiß man auch warum...
Sonst aber ein großes Lob für die viele Arbeit, die Ihr Euch gemacht habt. Wenn ich darf - würde ich gern an einer Weiterentwicklung der Lib mitarbeiten...
Gruss,
_HP_
Hi _HP_,
Im aktuellen Entwicklungsstand werden die Defines bereits verwendet. Ich denke, dass dieses Wochenende eine weitere Release veröffentlicht wird.Zitat:
Zitat von _HP_
Gute Frage. Diese Änderung wurde schon vor geraumer Zeit gemacht. Wenn ich mich recht erinnere, im Zusammenhang mit dem Umbau der IR Schnittstelle zur Hinderniserkennung. Mehr weis ich leider auch nicht.Zitat:
Zitat von _HP_
An den Testprogrammen hapert es derzeit noch.Zitat:
Zitat von _HP_
Mitarbeiter sind immer herzlich willkommen. Dazu müßtest du dich als Entwickler bei Sourceforge anmelden und mir deinen Entwicklernamen per PN zukommen lassen. Dann kann ich dich als Entwickler zur Asuro Lib eintragen.Zitat:
Zitat von _HP_
Doch, es gibt folgenden Kommentar in der Doku: (Im Source asuro.c zur Funktion Init() geschrieben.)Zitat:
Zitat von _HP_
Hinweis zur 36 kHz-Frequenz vom Timer 2
Genau diese Frequenz wird von dem Empfaengerbaustein benoetigt und kann
deshalb nicht geaendert werden.
In der urspruenglichen, vom Hersteller ausgelieferten LIB, war diese
Frequenz allerdings auf 72 kHz eingestellt. Durch eine geschickte
Umkonfigurierung durch waste konnte diese aber halbiert werden.
Sinnvoll ist dies, da der durch diesen Timer2 auch ausgeloesste Timer-
Interrupt dann nur noch die Haelfte an Rechenzeit in Anspruch nimmt.
Uff, da bin ich aber froh, dass das schon erledigt ist.
Was gemacht wurde, ist wie angedeutet etwas 'tricki':
Anstatt den Timer so zu programmieren, dass die HARDWARE bis zu dem vorgegeben Wert zählt, den Interrupt auslößt und dann den Zähler wieder initialisiert, wurde es so programmiert, dass in der Interrupt-Funktion zum Timer das Register TCNT2 um Hex 25 erhöht wird. Damit wird erreicht, dass das Taktverhältnis (An-/Aus-Zeit vom Port-Pin zur IR-Kommunikation) 50% bleibt. Ausserdem ist das Verhalten zum Wecheln genau dieses Port-Pins geändert worden.
Unterm Strich ist das Ausgangssignal am Port-Pin gleich geblieben. Nur wird, wie beschrieben, der Interrupt nur noch halb so oft aufgerufen.
That's all, ich hoffe das hilft.
Danke m.a.r.v.i.n und sternthaler für die schnelle Antwort. Ich konnte leider erst jetzt reagieren, da ich meinen Laptop erst einmal retten mußte, aber das ist jetzt geschafft. Einen Accout bei Sourceforge habe ich angelegt und m.a.r.v.i.n eine Mail zukommen lassen - es kann also losgehen. Ich freue mich schon...
Gruß,
_HP_
Hallo,
die auf UartPutc() basierenden Funktionenfunktionieren gut, wenn man sie separat von der IR-Kollisionsvermeidung einsetzt.
- void PrintInt (int wert)
- void PrintLong (long wert)
- void SerPrint (unsigned char *data)
- void UartPutc (unsigned char zeichen)
Die IR-Kollisionsvermeideung (IRCollisionTest/test.c.) funktioniert gut (IR-Hindernisvermeideung, IR-Höhenmesser, ...), wenn man sie separat von auf UartPutc() basierenden Funktionen einsetzt.
Frage:
Gibt es "magic_1" und "magic_2", damit folgender Code funktioniert?
Code:...
Init();
DDRD |= (1 << DDD1); // Port D1 als Ausgang
PORTD &= ~(1 << PD1); // PD1 auf LOW
OCR2 = 0xF7; // Pulsbreite 8
while (1)
{
"magic_1"
if (PIND & (1 << PD0))
StatusLED(GREEN);
else
StatusLED(RED);
"magic_2"
SerPrint(something);
}
...
Was meinst du mit "seperat"? nicht im gleichen programm? oder die funktionen nur ausführen, wenn die IR-kollisionserkennung gerade abgeschaltet ist?
Hallo Hermann,
wie wäre es damit:
"magic_1"
"magic_2"Code:USRB = 0; // UART TX disable
OCR2 = 0xF7; // Pulsbreite 8
Code:OCR2 = 0x91; // Pulsbreite fuer 36kHz
Hallo m.a.r.v.i.n.,
den Beitrag hatte ich bisher irgendwie nicht gesehen -- werde es gleich im Zug mal ausprobieren!Zitat:
Zitat von m.a.r.v.i.n
Hallo Librarians!
Könntet Ihr euch vorstellen, folgenden Abschnitt am Ende von asuro.h reinzunehmen:
Der erste Abschnitt mit REVERSE_DIR ist in folgendem Beitrag besprochen:Code:#ifdef REVERSE_DIR
#undef FWD
#define FWD (1 << PB4) /*!< Motor vorwaerts */
#undef RWD
#define RWD (1 << PB5) /*!< Motor rueckwaerts */
#endif
#ifdef UPSIDE_DOWN
#undef FWD
#define FWD (1 << PB4) /*!< Motor vorwaerts */
#undef RWD
#define RWD (1 << PB5) /*!< Motor rueckwaerts */
#undef LEFT
#define LEFT 1
#undef RIGHT
#define RIGHT 0
#undef LEFT_DIR
#define LEFT_DIR (1 << PB4) | (1 << PB5) /*!< PB4, PB5 Ports fuer Drehrichtung rechter Motor */
#undef RIGHT_DIR
#define RIGHT_DIR (1 << PD4) | (1 << PD5) /*!< PD4, PD5 Ports fuer Drehrichtung linker Motor */
#undef IR_RIGHT
#define IR_RIGHT (1 << MUX0) | (1 << MUX1) /*!< ADC3 A/D Wandler Port fuer Linienfolger Fototransistor links */
#undef IR_LEFT
#define IR_LEFT (1 << MUX1) /*!< ADC2 A/D Wandler Port fuer Linienfolger Fototransistor rechts */
#undef WHEEL_RIGHT
#define WHEEL_RIGHT (1 << MUX0) /*!< ADC1 A/D Wandler Port fuer Odometrie Sensor links*/
#undef WHEEL_LEFT
#define WHEEL_LEFT 0 /*!< ADC0 A/D Wandler Port fuer Odometrie Sensor rechts */
#define BackLED(l,r) BackLED(r,l)
#define MotorDir(l,r) MotorDir(r,l)
#define MotorDir(l,r) MotorDir(r,l)
#define MotorSpeed(l,r) MotorSpeed(r,l)
#define SetMotorPower(l,r) SetMotorPower(r,l)
#endif
https://www.roboternetz.de/phpBB2/vi...=267410#267410
Der Abschnitt mit UPSIDE_DOWN in in diesem Beitrag:
https://www.roboternetz.de/phpBB2/vi...=267146#267146
REVERSE_DIR ermöglicht es, ein "normales" Programm für einen Asuro zu übersetzten, der beide Motoren falsch hermum angeschlossen hat (z.B. weil einer der beiden nur rückwärts dreht, wie aktuell bei mir).
UPSIDE_DOWN ermöglicht es, einen "falsch herum" fahrenden Asuro ohne Änderungen mit "normalen" Programmen ansteuern zu können.
Wenn ja, dann müßte allerdings noch $(DEFS) in die ersten Zeilen von CFLAGS in allen Makefiles eingefügt werden
damit "make DEFS=-DUPSIDE_DOWN" bzw. "make DEFS=-DREVERSE_DIR" den Rest erledigt!Code:...
CFLAGS = -g $(DEFS) -O$(OPT) -I../../lib/inc\
...
Cool finde ich die Makrovertauschungen (z.B. BackLED) am Ende der Einfügung ...
Hi HermannSW,
erst einmal: Ich bin beeindruckt davon, was Du hardwaretechnisch alles angestellt hast - und noch mehr, wie Du das alles unter Einbeziehung Deiner zwei Kinder auf die Reihe bekommst!!!!
Trotzdem würde ich die von Dir vorgeschlagenen Änderungen nicht in die reguläre Lib aufnehmen. Sie sind einfach zu speziell und machen sie für Leute, die neu dazukommen schwer nachvollziehbar. Leider mußt Du dann jedesmal die Lib anpassen, wenn es eine neue Version gibt, aber das geht anderen bestimmt auch so, die Änderungen wollen, die die Lib eben nicht erfüllt.
Sorry...
Aber ich bin natürlich nur ein kleines Licht hier und meine Meinung ist nicht die ausschlaggebene. Wenn die anderen Entwickler meinen, diese Änderung sollte Eingang in die Lib finden...
Gruß,
Helmut
Ich möchte mich dieser Meinung anschließen. Die größten Probleme bei Betriebssystemen, Programmen und Videorecordern hat man dadurch, dass es zuviele Schalter gibt, an denen man drehen kann.Zitat:
Trotzdem würde ich die von Dir vorgeschlagenen Änderungen nicht in die reguläre Lib aufnehmen.
Variabilität erhöht die Komplexität
Gruss,
stochri
Hallo
Ich hab mal gelesen, die Verringerung der Frequenz sollte die Anzahl der Interrupts verringern um dem Hauptprogramm mehr Rechenzeit zu gönnen.(Ohne Gewähr)Zitat:
Der 72kHz - Timer wurde auf 36kHz geändert. Leider steht nirgends WARUM?!
Gruß
mic
Hallo,
Zitat:
Zitat von _HP_
Ihr habt beide Recht, das war wohl ein Schnellschuß von mir, ist ok, wenn das nicht in die Lib kommt. Wenn jemand solche Probleme hat, wird er ja über die Forensuche auch hier fündig werden ...Zitat:
Zitat von stochri
Ist schon ok, ist ja nur einmalig das Reinkopieren in asuro.h.Zitat:
Zitat von _HP_
Letztes Mal hatte ich mehr Glück, PrintLong() hat ja bereits seinen Weg in die Lib gefunden.
Noch eine Frage hinterher:
Unter "9.2.12. unsigned char PollSwitch(void)" werden im Handbuch die Taster K1-K6 benannt.
Wie wäre es denn mit Konstanten K1-K6 im Abschnitt Makrodefinitionen von asuro.h?
Hi Alle,
Ich bin endlich wieder dabei, nach lange pause aus Roboternetz.
Habt ihr schon Ideen, was in der nächsten Version kommen wird?
Hi,
die AsuroLib V2.7.0rc3 wurde heute released. Diesmal auch als Setup Programm für Windows mit Installation/Deinstallation Routinen.
Näheres siehe erstes Post in diesem Thread.
Download unter http://sourceforge.net/projects/asuro
Hallo Marvin,
der Dank der ASURO-Community ist euch gewiss! Vielen Dank also.
Was mir aufgefallen ist: die Funktionen Go() und Turn() sind nirgends zu finden. Weder in der Hilfe, noch als source-Code. Allerdings werden die beiden Funktionenn in den Beispielen noch benutzt.
Es wäre meiner Meinung nach auch sehr nützlich, wenn sich im obersten Verzeichnis die Datei "index.html" oder ein Link darauf befinden würde. Es ist relativ schwierig, besonders falls man noch Anfänger ist, den Startpunkt für die Doku im doc-Verzeichnis zu finden.
Beste Grüße,
stochri
wurden die nicht mal umbenannt....?
Hi,
Die Go und Turn Funktion befindet sich im File encoder.c.
Schaut man sich die Doku zur asuro.h an findet man dort alle Funktionen.
Ebenso gibt es einen alphabetischen Index unter Dateielemente.
Vielleicht wird die Übersicht besser, wenn man die Beispielprogramme aus der Doku herausläßt oder in eine extra Doku verlagert.
Die Idee mit einer index.html direkt im obersten Verzeichnis ist gut.
Dann könnte man von dort auf die Lib Doku, die Beispiel Doku etc. verlinken.
Bei der Installation über die AsuroLib-vXXX-Setup.exe werden allerdings auch eine Programmgruppe mit Links auf die Doku angelegt.
Hallo,
... wenn es denn klappt ...Zitat:
Zitat von m.a.r.v.i.n
Habe gerade AsuroLib-v270rc3-Setup.exe ausgeführt (bisher habe ich immer die Lib entzipped), und erhalte als Fehlermeldung:
"WinAVR is not installed"
Wie stellt die Setuproutine denn fest, daß WinAVR nicht installiert ist?
[Ist bei mir in c:\WinAVR vorhanden, allerdings nach einer Neuinstallation nur dorthin verschoben.]
Sollten irgendwelche Environmentvariablen gesetzt sein?
Oder klappt das nicht mit der [uralten :)] WinAVR-Version von der Asuro-Original-CD?
Hallo Hermann,
interessant, das Setup Programm überprüft den Registry KeyZitat:
Habe gerade AsuroLib-v270rc3-Setup.exe ausgeführt (bisher habe ich immer die Lib entzipped), und erhalte als Fehlermeldung:
"WinAVR is not installed"
Wenn der Registry Key nicht existiert, gibt es die obige Fehlermeldung.Zitat:
HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\WinAVR
Trotzdem ist bei dir fast alles richtig installiert:
* die libasuro.a muß nur noch ins WinAVR\avr\lib Verzeichnis kopiert werden
* das Makefile muß nicht angepaßt, da c:\WinAVR die Voreinstellung ist.
Es sollte in deinem Fall genügen im lib-Verzeichnis
aufzurufen, um die libasuro.a ins WinAVR/avr/lib/ Verzeichnis zu kopieren.Zitat:
make install
Ich werde wohl die Install Routine noch um eine Suche nach Verzeichnis Funktion erweitern müssen. Oder mir fällt eine andere Lösung ein, die ohne kopieren der Lib auskommt.
vielleicht kann man ja eine möglichkeit in das installationsprogramm einbauen, sowas wie
"winavr wurde nicht gefunden. installation aubbrechen oder winavr verzeichnis manuell wählen?"
und dann muss man eine datei aus dem winavr verzeichnis auswählen, damit währe der pfad ja definiert.
Ach da sind die Funktionen. Ich habe sie vergeblich bei motor.c gesucht, das erschien mir am logischsten.Zitat:
Die Go und Turn Funktion befindet sich im File encoder.c.
Aber mal was anderes:
Wenn man ein Projekt mit AVR-Studio und der neuen Lib anlegt, sollte man die vorkompilierten Libs bei AVR-STudio einbinden können. Wenn man jetzt das Projekt speichert, sollte doch alles korrekt und portabel ohne Installation sein, oder?
Zur Not müsste man jedem Projekt halt die ganze Lib mitgeben. Mach ja nichts, 80KB overhead kann man sich bei den heutigen Festplattengrößen ja locker leisten und es besteht nicht immer die Gefahr, dass man die falsche Version der LIB hat.
Gruss,
stochri
Eine kleine Frage:
Wäre es theoretisch denkbar, dass man das ganze noch mit dem Programmers Notepad programmiert? Ich verwende zwar auch dass AVR-Studio, aber für mein Programm (siehe Beitrag: Asuro Entwicklungsumgebung in C) greife ich dennoch teilweise auf die Funktionsweise des Programmers Notepad zurück.