Archiv verlassen und diese Seite im Standarddesign anzeigen : AsuroLib V2.8.0rc1 veröffentlicht
m.a.r.v.i.n
29.03.2008, 20:41
Hallo,
Eine neue Release der ASURO Library steht zum Download auf Sourceforge (http://sourceforge.net/projects/asuro) bereit. Noch ist es keine endgültige Version sondern nur ein Release Candidate. Große Änderungen sind aber nicht mehr zu erwarten.
Die wichtigsten Änderungen gegenüber der Vorgänger Version sind:
* Unterstützung für ATmega168 Prozessoren
* neue Funktion ReadADC zur A/D Wandler Abfrage
* neue Funktion PrintLCD_p zur Ausgabe von Strings aus dem Programmspeicher
* neue Funktion SetCharLCD zum Setzen von Sonderzeichen
* neue Funktion PollSwitchLCD zur Abfrage der Tasten des Arexx LCD
* neue Funktion MyMotorSpeed die Korrekturwerte aus der myasuro.h berücksichtigt.
* neue Funktion SerPrint_p zur Ausgabe von Strings aus dem Programmspeicher
* UART Baudrate einstellbar durch Define
* Interrupt User Funktionen für Timer und A/D Wandler
* AVR Studio Projektfiles für alle Beispielprojekte
Viel Spaß beim Ausprobieren.
Eine Exe Installer Version mit der AsuroFlash IDE folgt in Kürze.
damaltor
30.03.2008, 21:52
schöne sache. soll ich den "wichtigste dateien..." thread schon ändern oder hat das zeit bis zum endgültigen release?
m.a.r.v.i.n
01.04.2008, 23:02
schöne sache. soll ich den "wichtigste dateien..." thread schon ändern oder hat das zeit bis zum endgültigen release?
Ich denke das hat noch Zeit.
Die Win32 Installer Version der Version 2.8.0rc1 mit der AsuroFlash IDE (aka eierlegende Wollmich-Sau) von Osser steht nun ebenfalls zum Download (http://downloads.sourceforge.net/asuro/AFSetup_v280rc1.exe?use_mirror=osdn) bereit.
Hallo,
(... Nachbarn, bitte verzei mir fur meiner deutch. Englisch geht mir ganz leichter ab, und ich habe keine ahnung wo ich die deutche special zeichen wie umlaut und so auf mein klavier finden kan. Ich hoffe sie konnen es ohne auch verstehen.)
Also, zur sache. Die AFSetup_v280rc1.exe sagt er wurde Asuro Library 2.7.1 installieren wenn ich mit meiner maus uber dieser component bewegt. Dah stimmt etwas nicht, oder?
m.a.r.v.i.n
11.04.2008, 14:26
Hallo,
danke für die Info. Das ist noch ein kleiner Fehler im Install-Skript. Es wird aber die richtige Version installiert.
Hallo,
Gut, ich werde es mal weiter ausprobieren.
damaltor
11.04.2008, 16:05
Hello Valen. if it is easier for you, you can speak english also, most of us will understand and ill try to translate. Welcome to the forum!
---
Hallo Valen. wenn es einfach er ist, kannst du auch gern eglisch sprechen. die meisten von uns werden es wohl verstehen, und ich werde versuchen zu übersetzen.
Danke, aber ich wölte doch versuchen deutsch zu schreiben. Ich bin auch schön for einiger zeit angefangen 'Das Boot' von Lothar-Günther Buchheim zu lesen. Geht leider nicht so schnell wie english aber gut genug. Und habe nuhn auch herausgefunden wie ich die korrekte zeichen aus meinen UK-klavier tasten zauberen muß. Ich denke ich werde es schön klappen. Übung, übung, übung.
Hallo m.a.r.v.i.n,
ich finde es schade, dass man immer noch die Werte für
MY_ODO_DARK_VALUE_R
MY_ODO_LIGHT_VALUE_R
MY_ODO_DARK_VALUE_L
MY_ODO_LIGHT_VALUE_L
selbst ermitteln muss. Dabei wurden doch im Thread "Regelung fürs Geradeausfahren" schöne Ideen gesammelt wie's besser gehen könnte. Und dabei auch noch Umgebungslichtstabil ist. Hier einfach mal mein Vorschlag. Vielleicht findet er ja seinen Weg in die nächste Lib ?!
SIGNAL (SIG_ADC)
{
const static unsigned char admux[]={
(1 << ADLAR) | (1 << REFS0) | WHEEL_LEFT,
(1 << ADLAR) | (1 << REFS0) | WHEEL_RIGHT};
static int tmp [2], flag [2]={1,1};
static unsigned char toggle = FALSE;
if (autoencode)
{
int sensor = ADCH;
ADMUX = admux[toggle];
tmp[toggle]+=(sensor-tmp[toggle])>>2;
if (flag[toggle]*(sensor-tmp[toggle]) > 2)
{
encoder[toggle]++;
flag [toggle] = -flag [toggle];
}
toggle^=1;
}
}
Bei mir macht der Code (auch bei schlechten Sensorwerten) eine gute Figur und ist auch bei allen Lichtverhältnissen und sogar bei starken und plötzlichen Lichtschwankungen stabil. (Also, mechanisches abdecken der Sensoren, um sie vor störendem Umgebungslicht zu schützen, ist nicht mehr nötig.)
m.a.r.v.i.n
16.04.2008, 13:10
Hallo rossir,
Vielleicht findet er ja seinen Weg in die nächste Lib ?!
Die Chancen, dass eine Funktion in die Asuro Lib übernommen wird, steigen natürlich, je besser diese dokumentiert ist. In deinem Fall also praktisch 0 :wink:
Schließlich sollen gerade auch Anfänger die Lib nicht nur benutzen, sondern auch verstehen, wie die Funktionen arbeiten.
Hallo m.a.r.v.in,
nichts leichter als das:
/************************************************** **************************/
/*
\brief
Interrupt-Funktion fuer den AD-Wandler. Kann ueber autoencode gesteuert\n
die Odometrie-Zaehler in encoder hochzaehlen.
\param
keine
\return
nichts
\see
Die globale Variable autoencode wird hier ausgewertet. Ist sie nicht FALSE,\n
dann wird der AD-Wandler-Wert zum Zaehlen der Odometriewerte in der globalen\n
Variablen encoder benutzt.\n
Es wird auch der AD-Wandler-Kanal auf die 'andere' Seite der Odometrie\n
umgeschaltete und der AD-Wandler neu gestartet.\n
Somit wird erreicht, dass zumindest die Odometriemessung automatisch erfolgt.
\par Beispiel:
int main(void) {
int lSoll=60, rSoll=30, lPwm=lSoll, rPwm=rSoll, delta=50;
Init();
EncoderInit();
EncoderStart();
while(1) {
int lIst=encoder[LEFT], rIst=encoder[RIGHT];
EncoderSet(0, 0);
lPwm+=(delta*lSoll - 1000*lIst)/300;
rPwm+=(delta*rSoll - 1000*rIst)/300;
SetMotorPower(lPwm, rPwm);
Msleep(delta);
}
}
************************************************** ***************************/
SIGNAL (SIG_ADC)
{
const static unsigned char admux[]={
(1 << ADLAR) | (1 << REFS0) | WHEEL_LEFT,
(1 << ADLAR) | (1 << REFS0) | WHEEL_RIGHT};
static int tmp [2], flag [2]={1,1};
static unsigned char toggle = 0;
if (autoencode)
{
// Aktuellen Sensorwert vom AD-Wandler entnehmen (hier nur high-order-byte).
int sensor = ADCH;
// Der AD-Wandler wird schon mal auf den übernächsten Analogkanal eingestellt.
ADMUX = admux[toggle];
// In tmp wird ein gleitender Mittelwert mitgeführt.
tmp[toggle] += (sensor-tmp[toggle])>>2;
// Weicht der aktuelle Sensorwert um mehr als +/- 2 vom gleitenden Mittel ab?
if (flag[toggle]*(sensor-tmp[toggle]) > 2)
{
// Dann zähle einen Tick weiter.
// Und nächster Tick erst wieder bei -/+ 2 Abweichung vom gleitenden Mittel.
encoder[toggle]++;
flag[toggle] = -flag [toggle];
}
toggle ^= 1;
}
}Besser so? Auf jeden Fall deutlich besser kommentiert als das Lib-Orginal ;-)
Sternthaler
17.04.2008, 01:26
Hallo m.a.r.v.i.n
schöne neue Funktionen vor allem auch für die LCD-Erweiterung.
Ich selbst nutze diese Erweiterung zwar nicht, aber die Attraktivität der LIB wird dadurch ja nur größer.
Was ich aber besonders gut finde ist der Punkt:
* Interrupt User Funktionen für Timer und A/D Wandler
Damit kann ja wunderbar in das Interruptgeschehen eingegriffen werden, ohne jedesmal die LIB neu zu übersetzen.
Projektbezogene INT-Funktion wird super möglich. Klasse Idee, diese Technik in die LIB zu bringen \:D/ .
Hallo rossir,
leider muss ich auch m.a.r.v.i.n zustimmen. Seit gestern Nacht starre ich auf deine Funktion und erst durch ein heutiges ECEL-Blatt bin ich schlauer geworden.
Die in tmp[] gebildete Historie in dieser Form zu nutzen, da wollte ich schon vor 'Jahren' selber drauf kommen. Vor allem geht auch der erste Tik fast nie im Excel-Simulator verloren. (Wenn man nicht zu stark an den Schrauben dreht.)
Aber trotz mangelnder Kommentare: Hut ab
(Für den tmp-Startwert würde ich max(ADC-Wert - 20; 0) einsetzen, jedesmal wenn autoencode 'frisch' eingeschaltet wird. Damit wird die 'Anlaufphase' in tmp drastisch reduziert.
Auch den Teiler 2 bei der tmp-Berechnung würde ich auf 8 (mein Spielwert) erhöhen. Damit schrumpt der Abstand zwischen Min- und Maxwerten am ADC von ca. 40 auf nur noch 6 ADC-Einheiten.)
Als Dankeschön gibt es dafür mein EXCEL-Blatt O:).
Und ausserdem sehe ich gerade deinen Beitrag mit Kommentaren. Die allerdings sind auch nur knapp bemessen. Die Details stecken ja doch 'zwischen' den Semikolons. Motz, Mecker, Schimpf. Das ist leicht ;-)
Gruß Sternthaler
m.a.r.v.i.n
17.04.2008, 20:58
Hallo rossir,
Besser so? Auf jeden Fall deutlich besser kommentiert als das Lib-Orginal
ja, so gefällt mir das gleich viel besser. Da habe ich im Gegensatz zu sternthaler nichts mehr zu meckern. O:)
Hallo Sternthaler,
es freut mich, wenn du mal nichts zu meckern hast. :wink:
Dein Diagramm macht den Programm Ablauf noch deutlicher.
Vielleicht sollte man den Teiler und den Startwert als Userdefinierbare Konstanten in die myasuro.h aufnehmen. :-k
Hallo Sternthaler,
ich bin da nicht so pingelig: So kannst Du gerne den Code um erhellende Kommentare ergänzen ;-). Vielleicht um Ausschnitte aus diesem Thread?
1)
Anmerkung: Ich habe keinen Teiler 2 zur tmp-Berechnung sondern ich shifte um 2 und deshalb einen Teiler von 4. (Also nicht mehr ganz so weit weg von Deiner 8.) Ich shifte hier, weil ich vermute, dass eine Division zu teuer ist.
2)
Ich wollte der Interruptroutine Platz und Zeit ersparen und habe deshalb auf eine Initialisierung von tmp verzichtet. Statt dessen habe ich den kleinen Teiler 4 gewählt. Dadurch passt sich tmp sehr rapide den ADC-Werten an. (Doppelt so schnell wie ein Teiler 8.) Und verliert in der Realität auch "nie" den ersten Tick. (So muss ASURO auch meist erst mal anfahren.)
3)
Bei Deiner starken Stauchung von 0,025 (im EXCEL-Simulator) kommt der Vorteil von einem Teiler 8 natürlich zur Geltung. Aber, erstens: ist in der Realität die tatsächliche Sensorkurve in solchen Fällen sowieso zu stark verrauscht und zweitens kommt so eine starke Stauchung in der Realität nicht vor. Dann ist eher was kaputt. Ich meine, selbst bei viel Pech beim Löten und mit den Bauteilen, liegt die kleinste realistische Stauchung bei ca. 0,2. ( Übrigens macht der Teiler 4 erst bei einer Stauchung von 0,06 schlapp. )
4)
Allerdings - und hier habe ich noch nicht probiert - könnte es damit (Teiler 8 ) zum ersten mal gelingen, bei Tageslicht, auch ohne eingeschaltetem Encoder-LED, Ticks zu sammeln (allerdings verrauscht). Und das spart Energie - falls es wirklich darauf ankommt.
5)
Vielen Dank für Deinen EXCEL-Simulator. Ich hatte das seinerzeit mit mitgeloggten Orginaldaten durchprobiert, die Daten und Grafiken aber weggeschmissen. Vielleicht reiche ich die noch nach.
Zusammenfassend: Teiler 8 (also shift um 3) geht auch ;-)
Und Dankeschön zurück.
Hallo m.a.r.v.i.n,
von den userdefinierbare Konstanten in myasuro.h will ich ja gerade weg ;-)
Hallo Leute!
Auch auf die Gefahr hin zu nerven, möchte ich doch noch einmal auf den Schalter-im-Interrupt-Betrieb-Bug hinweisen, der im Thread "Asuro: PollSwitch im Interrupt betrieb" diskutiert wird/wurde. Es wäre sehr schön, wenn einer von den Lib-Leuten mal seine Meinung dazu kund tun könnte...
Gruß farratt
Sternthaler
21.04.2008, 02:54
Hallo farratt,
genervt wird hier nicht.
Für die, die den Thread suchen: Asuro: PollSwitch im Interrupt betrieb (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=17240)
Und darin das Beispiel von farrett mit Lösungsvorschlag ist hier (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=362661#362661).
Die dort von dir gefundene Lösung ist mir nicht einleuchtend.
Spätestens wenn mit dem Aufruf von StartSwitch(), nachdem ein Schleifendurchlauf erfolgte, darin wieder SWITCH_OFF aufgerufen wird, sollte das Verhalten so sein, als ob dein eingebautes SWITCH_ON nicht ausgeführt worden wäre.
Außerdem wird mit dem SWITCH_xxx ja nur? die Datenrichtung vom Interrupt-Pin kontrolliert. Dies deutet mir auf ein Timing-Problem hin.
Ich habe gerade etwas mehr als nur ein Stündchen zu dem Thema hinter mir, und kann auch keine andere Lösung finden, die ich dann auch noch erklären könnte.
Eventuell hilft hier anderen der Hinweis, dass der Interrupt im über das Register MCUCR im Low-Level-Mode betrieben wird, und in diesem Mode das Interrupt-Flag INTF1 im Register GICR nie gesetzt wird. So hat man auch keine Chance dieses Flag selber zu beeinflussen.
@m.a.r.v.i.n
Hast du hier eine andere Lösung in der Tasche? Oder kannst du das erklären?
Gruß Sternthaler
m.a.r.v.i.n
21.04.2008, 22:56
Hallo,
ja ich hab ein andere Lösung, die ich auch schon im Thread PollSwitch im Interrupt Betrieb (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=17240) gepostet habe. Ich denke, diese Lösung ist einleuchtender. :wink:
Die Änderung ist auch schon im SVN eingecheckt und damit in der nächsten Version drin.
Sternthaler
22.04.2008, 01:43
Danke m.a.r.v.i.n,
mit der Lösung, direkt unter die Nase gehalten, kann ich jetzt endlich wieder schlafen. Nur so kann sich das Brett vorm Kopf anfühlen ;-)
Gruß Sternthaler
Hallo wieder,
In die install.txt wird gesagt das nur auf einer stelle Pfad angabe geändert werden muß in de Makefile (sicher wenn neue projekte nicht in der gleiche Verzeichnisebene befinden):
# additional Include path for libraries
LIBPATH = C:/ASURO_SRC/AsuroLib/lib
Aber wenn leute die AVR Compiler auch auf eine 'nicht-default' platz installiert haben mußen sie auch die fölgende stelle ändern denke ich schön:
# Define directories, if needed.
#DIRAVR = C:/WinAVR
Richtig?
m.a.r.v.i.n
01.05.2008, 13:21
# Define directories, if needed.
#DIRAVR = C:/WinAVR
Richtig?
Nein, das ist nicht notwendig. Der AVR Compiler wird über die Pfadangaben in der Systemvariablen PATH gefunden. DIRAVR usw. werden zwar im Makefile gesetzt, aber nirgendwo verwendet.
Danke, ich habe mal in meiner eigener systemvariablen gekückt. Stimmt, genau. Ich wuste nicht das PATH automatisch eingestellt war.
RobotNeu
02.12.2008, 16:26
ich habe eine kleine Frage. Wo wird die F_CPU Variable, die in der Datei asuro.c bei der Funktion Init() benutzt wird, deklariert? es wäre sehr nett, wenn mir da jemand weiterhelfen könnte.
#if defined(__AVR_ATmega168__)
UBRR0L = (uint8_t)(F_CPU/(BAUD_RATE*16L)-1);
UBRR0H = (F_CPU/(BAUD_RATE*16L)-1) >> 8;
UCSR0B = (1<<RXEN0) | (1<<TXEN0);
UCSR0C = (1<<UCSZ00) | (1<<UCSZ01);
#else
UBRRH = (((F_CPU/BAUD_RATE)/16)-1)>>8; // set baud rate
UBRRL = (((F_CPU/BAUD_RATE)/16)-1);
UCSRB = (1<<RXEN)|(1<<TXEN); // enable Rx & Tx
UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // config USART; 8N1
#endif
RobotNeu
02.12.2008, 16:30
Sorry, ich habe das jetzt gefunden. Wird in dem Makefile definiert.
Das ist eine die erste werten die im makefile deklariert werden. Schau mal in die makefile im lib examples.
Hallo marvin,
weshalb ist den asuro.c (hier konkret die Init()-Funktion) nicht in der libasuro.a aufgenommen? Gibt es technische Gründe dafür?
m.a.r.v.i.n
04.03.2009, 23:08
Hallo rossir,
einen driftigen Grund dafür gibt es nicht. Bei Bedarf kann man Erweiterungs Module (LCD, Ultraschall) gleich mit initialiseren, ohne die Lib neu zu übersetzen müssen.
Mit der nächsten Version ist das sowieso alles hinfällig, dann benötigt man keine extra Objekt Library mehr.
Man übersetzt zukünftig einfach alles und über ein paar spezielle Compiler und Linker Optionen im Makefile entfernt der GCC dann alle nicht verwendeten Funktionen und Daten aus dem übersetzten Programm.
Wie das funktioniert, kann man hier nachlesen:
http://www.mikrocontroller.net/topic/103306
Hallo Marvin,
noch was: Wie kann ich eine eigene IsrEnc(void) zum Einsatz bringen ohne die Lib neu zu erzeugen (bzw. anfassen zu müssen)? Irgendwie sieht die Lib heute so aus als könnte man dies erreichen (denn welchen Sinn macht die Variable AdcIntFunc sonst?) aber ich weiß nicht wie ich dies anstellen soll.
m.a.r.v.i.n
05.03.2009, 19:43
Hallo rossir,
eine eigene IsrEnc Funktion einbinden ist recht einfach. Du schreibst deine Funktion (wichtig ist Parameter und Rückgabwert muß void sein)
void myIsrEnc(void)
{
// tu was
}
Deine Funktion bindest du dann einfach mit der folgender Zeile ein:
AdcIntFunc = myIsrEnc;
Genauso wird es in der EncoderInit Funktion gemacht.
Danke!! Bin ich nicht drauf gekommen, war zu einfach ;-). Also, dann immer die folgende Reihenfolge:
EncoderInit();
AdcIntFunc = myIsrEnc;
Ich dachte, ich brauche nur eine gleichnamige Funktion schreiben und schwupps ... würde meine genommen.
Schade eigentlich, denn wenn Du dann demnächst mit den angekündigten speziellen Compiler und Linker Optionen kommst sind beide Funktionen im HEX-File: IsrEnc und myIsrEnc. Oder?
m.a.r.v.i.n
06.03.2009, 22:28
Ich dachte, ich brauche nur eine gleichnamige Funktion schreiben und schwupps ... würde meine genommen.
Hmm, das könnte sogar funktionieren. Habe ich aber selbst noch nicht ausprobiert.
Schade eigentlich, denn wenn Du dann demnächst mit den angekündigten speziellen Compiler und Linker Optionen kommst sind beide Funktionen im HEX-File: IsrEnc und myIsrEnc. Oder?
Das wäre mit der Objekt Lib genauso.
Dachte ich eben auch zuerst. Aber es funktioniert nicht. Es gibt dann die dubiose Fehlermeldung:
???1\avr\bin\ld.exe: Warning: size of symbol `IsrEnc' changed from 152 in ./subsumption.o to 154 in ???2\lib\libasuro.a(encoder_low.o)
Müsste mit der Objekt Lib eigentlich nicht genauso sein - glaub' ich. Wenn man ca. wie folgt seine Interruptfunktion wählen könnte:
EncoderInit(myIsrEnc);
Dann käme IsrEnc nie als verwendete Funktion bzw. Adresse vor und könnte durch -Wl,--gc-sections etc. raus geschmissen werden. Weiß aber nicht genau. Immerhin ... die Chance besteht.
Aber, viel mehr stört mich etwas anderes.
Die Idee hinter "DLR ASURO Flash" -> "flash only new pages" ist zwar schön. Aber, leider wird die LIB immer hinter meinen Programmtext geschrieben. Wenn ich also in meinem Programm etwas ändere, wird es ein wenig kürzer oder (meist) etwas länger. Dadurch ändern bzw, verschieben sich oft alle folgenden Pages (die LIB). Schade eigentlich! Kann man das ändern? Und die Reihenfolge umdrehen?
Hallo marvin,
ich glaube da gibt es ein heftiges Problem in der Lib.
Denn PollSwitch() beeinflußt unangenehm die encoder[]-Werte. Obwohl dies doch die Verwendung von autoencode verhindern sollte.
Ich habe mal die Werte von WHEEL_LEFT und WHEEL_RIGHT in Deiner Interrupt-Routine recorded. Während dessen habe ich 6 mal (um den Effekt hier deutlicher zu zeigen) PollSwitch() aufgerufen. In der angehängten Grafik sieht man den desaströsen Effekt auf die WHEEL_LEFT- und WHEEL_RIGHT-Werte. Entsprechend falsch erhöhen sich dadurch die encoder[]-Werte rasant.
(In meiner konkreten Anwendung, flippt mein PID Regler durch diesen falschen Input, genau in dem Augenblick aus, wo er eigentlich vor einer Wand zum halten kommen sollte :( )
m.a.r.v.i.n
20.03.2009, 20:37
Hallo rossir,
das Problem ist bekannt, leider gibt es dafür (noch) keine Lösung. Die PollSwitch Funktion und die Encoder ISR beharken sich trotz der Verwendung von autoencode. Eine mögliche Lösung wäre es, alle A/D Wandler interrupt gesteuert auszulesen. Dazu müßte die IsrEnc Funktion entsprechend umgebaut werden.
Eine andere Lösung sieht so aus, PollSwitch einfach nicht zu verwenden. Das der Asuro auch ohne Tasterabfrage Kollisionen erkennen kann, hat Stochri in seinem genialen Geheimprogramm (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=23163) bewiesen.
Hallo marvin,
ok.
Aber, welche Gründe verhindern den Umbau/Korrektur der IsrEnc Funktion gleich in der Lib?
m.a.r.v.i.n
25.03.2009, 09:47
Hallo rossir,
Aber, welche Gründe verhindern den Umbau/Korrektur der IsrEnc Funktion gleich in der Lib?
Es muss sich halt jemand finden der Zeit und Muse hat das zu tun. Vielleicht machst du es ja, ich habe nämlich keine Zeit dafür.
Einen Ansatz, wie man das machen könnte gab es schon mal von RN-User Rakke:
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=7571
https://www.roboternetz.de/phpBB2/download.php?id=5106
Hallo marvin,
ok, habe ich gemacht. Siehe patch.zip Datei im Anhang.
Ich bin ausgegangen von eurer SVN Revision 192. Im Patch befinden sich nur die Änderungen welche relativ zu dieser Revision notwendig sind. Das sind 7 geänderte Dateien plus eine readme.txt.
Durch diese Änderung sind alle ADC auf Interrupt umgestellt. Dabei habe ich besonders auf die Rückwärtskompatibilität geachtet.
Die encoder werden weiter unterstützt allerdings so verbessert wie von mir hier in
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=367880#367880
vorgestellt.
Die gesammelten Kommentare zum Patch finden sich in der Datei readme.txt.
Ich hoffe es gefällt Dir.
Sternthaler
01.04.2009, 01:39
Hallo rossir,
ich habe mal einen Blick in deinen Code geworfen.
Schon mal vorab: Mir gefällt vor allem deine intergrierte Gleitwertberechnung für die TIK-Zählerei.
Eine Anmerkung zu der Reihenfolge in asuro.c Init() beim Setzen von ADCSRA und ADMUX. Sollte man nicht umgedreht vorgehen da du mit ADFR und ADSC den Wandler ja schon im 'free running'-Mode startest ohne vorher explizit den Kanal ausgewählt zu haben.
Das folgende sei() erlaubt dann ja nur noch, dass der ADC auch in der Interruptfunktion ankommt.
Ansonsten finde ich extreme Ähnlichkeiten in deinem Aufbau wie ich es schon seit einiger Zeit auch mache.
Auslagern der Datenermittlung in den Interrupt und die 'alten' Funktionen liefern nur noch die Ergebnisse aus der Variablen adcValue[].
Hierzu noch ein Tip. Diese Variable sollte als volatile angelegt werden und in den 'alten' Funktionen sollte vor dem Zugriff auf die Variable der Interrupt gesperrt und danach wieder zugelassen werden.
Liegt daran, dass du sinnvollerweise int-Daten nutzt, die aber dann mehrere Maschinenzyclen zum Auslesen benötigen und somit vom ADC-Interrupt mittendrin unterbrochen werden können. Ein Byte also vom vorletzten ADC-Wert, das andere Byte aber schon vom letzten ADC-Wert.
Hat mich etliche graue Haare gekostet diesen Sachverhalt in der ATmega-Doku zu finden um diese unerwarteten falschen ADC-Werte zu finden.
Ansonsten könnte ich hier noch etwas zu Zeiten beim Ein-/Ausschalten der Sensorbeleuchtungs-LEDs und anderem los werden, aber da kannst du mal bei mir nachsehen. Kommentare sind reichlich vorhanden.
Vorsicht falls du das Programm laufen lässt. Der Asuro fährt mit ein paar Kurven ca. 3-4 Meter weit.
Gruß Sternthaler
m.a.r.v.i.n
01.04.2009, 23:31
Hallo rossir,
toll, das sieht super aus. So kann man das in die Lib übernehmen.
@sternthaler schön, das es dich auch noch gibt. Deine Quellen schau ich mir auch noch durch. Vielleicht kann man ja beides kombinieren.
Sternthaler
03.04.2009, 19:29
Hallo m.a.r.v.i.n, und auch alle anderen.
Ja, ich hatte etwas länger einen 'Durchhänger' aufgrund persönlicher Überlastung. Ich will mich aber wieder bessern.
Und nun aber hurtig auch von mir ein direktes Lob an rossier. Von der ersten Idee, dass du die ADCs per Int lesen willst, bis zu deinem Code, sind ja nur ein paar Tage vergangen. Grandios! Ich werkel an meiner Version schon seit 11.2005 rum.
Kombination wäre nicht schlecht.
Vor allem die von mir angedeuteten Probleme beim Umschalten der Sensorbeleuchtung bringt einen Haufen Code mit sich, der wahrscheinlich in den meisten Fällen nicht relevant ist. Ich bremse bewust die Wandler-Neustart-Geschwindigkeit, damit die LEDs auch sicher AN bzw. AUS sind. (Die CPU ist einfach schneller als die LED hier in der Asuro-Hardware)
Hierdrin liegt der hauptsächliche Unterschied zwischen rossir (und allen Interrupt-Vorgängern) und meinem Code. Ich steuer den ADC-Start selber, anstatt den 'free Willy' äh 'free running'-Mode zu nutzen.
Mein Code ist schon seit 'Jahren' immer wieder mal im Forum aufgetaucht. Jedesmal wenn es dann Fragen gab, wurde aber meistens nach ersten Erklärungsversuchen abgewunken, da die Komplexität 'etwas' größer ist. Viel Spaß beim durchsehen. Ansonsten jederzeit PN-Nachricht. Oder hier für alle ;-).
Gruß und schönes Wochenende für euch alle
Sterntahler
P.S.: Und noch etwas.
Weiss jemand, warum ich nur noch selten Mails bekommen, wenn sich in den Thread mit meiner Beteiligung etwas ändert?
Zu deinem Eintrag m.a.r.v.i.n habe ich auch schon wieder keine E-Mail bekommen. (Zu 2 anderen Threads aber schon!) Ich stolper im Moment sporadisch durch die Beiträge in denen ich mich verewigt hatte um neue Beiträge zu suchen.
Hallo marvin,
das freut mich aber.
Hier noch ein paar Detailverbesserungen die auf noch kürzeren (hex-)Libcode einerseits und weniger #define-Ballast andererseits, abzielen. Und allgemein auf einfacheren Code abzielen. Aber auch unter Berücksichtigung der tiefen Einsichten von Sternthaler -> Danke!
Und ausserdem habe ich noch ein paar klärende Kommentare mehr gestiftet.
Was will man mehr, oder? ;-)
Hat schon mal einer über Exceptions (bzw. Makros dafür) nachgedacht?
Frei nach dem Motto:
try {
// Fahre 2m gerade aus!
GoTurn (2000, 0, 150);
} catch(COLLISION) {
// Aber falls ASURO dabei auf ein Hindernis stößt sofort stoppen!
MotorSpeed (0, 0);
}
Hallo Sternthaler,
ich muß sagen, dass ich immer schlechte Laune bekomme, wenn ich auf den Code (hier test.c) einer State-Transition-Machine (STM) schaue. Das einzige was die Laune bei Deinem STM-Code hebt sind die wirklich ausführlichen und guten Kommentare.
Wie dem auch sei, Dein Programm (und damit der ASURO) läuft erst mal bei mir wie designed.
Mal sehen ob mir was zu "Kombination" einfällt.
Das mit den Switches ist doch empfindlicher (bzgl. Motor an/aus) als ich dachte und ist von mir jetzt etwas sorgfältiger umgesetzt worden. Deshalb der patch3 im Anhang.
Hallo Sternthaler,
hier meine Überlegungen zur "Kombination" (siehe Anhang): Ich habe Deinen, von Dir vorgegebenen Code (V120.zip), ein wenig gemorpht bis er auch mit der Lib 2.8.0 (plus mein patch3) läuft. Du müßtest Deinen (alten) STM-Code darin gut wiedererkennen, oder?
Das Schöne: Jetzt kommt er sogar ohne STM aus. Die (notwendige) Kooperation zwischen den "Prozessen" findet jetzt mittels wait(..) statt. (Stichwort: subsumption)
All Deine Prozesse: PROZESS_Nav_i(), PROZESS_StatusLEDBearbeiten(), etc. und main() benutzen jetzt wait(..). wait(..) wirkt wie MSleep(..), "vergeudet" aber seine Zeit nicht einfach damit zu warten. Sondern übergibt (in der Zwischenzeit) die Kontrolle an Prozesse mit höherer Priorität! Dazu werden Deine Prozesse, ganz zu Beginn, mittels subsumptionInit(..) an wait(..) übergeben.
Damit das extreme HW_MOTOR_DIFF Deines ASURO keine Rolle spielt, habe ich den Code noch um eine PID-Regelung der Motoren erweitert (siehe PROZESS_MotorRegeln).
Hallo Sternthaler,
hier meine Überlegungen zur "Kombination" (siehe Anhang): Ich habe Deinen, von Dir vorgegebenen Code (V120.zip), ein wenig gemorpht bis er auch mit der Lib 2.8.0 (plus mein patch3) läuft. Du müßtest Deinen (alten) STM-Code darin gut wiedererkennen, oder?
Das Schöne: Jetzt kommt er sogar ohne STM aus. Die (notwendige) Kooperation zwischen den "Prozessen" findet jetzt mittels wait(..) statt. (Stichwort: subsumption)
All Deine Prozesse: PROZESS_Nav_i(), PROZESS_StatusLEDBearbeiten(), etc. und main() benutzen jetzt wait(..). wait(..) wirkt wie MSleep(..), "vergeudet" aber seine Zeit nicht einfach damit zu warten. Sondern übergibt (in der Zwischenzeit) die Kontrolle an Prozesse mit höherer Priorität! Dazu werden Deine Prozesse, ganz zu Beginn, mittels subsumptionInit(..) an wait(..) übergeben.
Damit das extreme HW_MOTOR_DIFF Deines ASURO keine Rolle spielt, habe ich den Code noch um eine PID-Regelung der Motoren erweitert (siehe PROZESS_MotorRegeln).
Sternthaler
16.04.2009, 02:18
Hallo rossir,
da hast Du dir ja echt viel Mühe gemacht mein Testprogramm umzugestalten. Ich gebe Dir Recht, die main()-Funktion ist nun hübsch lesbar geworden.
Gut, dass Du als Stichwort Subsumption angeführt hast. Ich hatte vor Jahren (Jahrzehnte wohl eher) mal davon gehört. Aber wie es nun so ist, gerät einiges in Vergessenheit.
Deshalb habe ich auch leichte Probleme damit, wie die von Dir geschriebene wait()-Funktion sicherstellen kann, dass auch die 'Prozesse' mit der niedrigen Prio dran kommen.
Wenn ich als 'böser' Nutzer die Funktion immer nur mit wait(0); aufrufe, dann kann es doch passieren, dass die for()-Schleife nicht bis zur letzten eingetragenen Funktion kommt.
Warum lässt Du die Schleife nicht von 0 bis zur Anzahl der eingetragenen Funktionen/Prozesse laufen?
Oder sogar den Start der For-Variablen mit der letzten Prozessnummer + 1 beginnen? (Klar, am Ende wieder zur ersten Funktion.) Dann kommen auf alle Fälle alle Funktionen mindestens einmal dran.
Was habe ich noch alles vergessen zum Thema Subsumption?
Ansonsten ist die Integration in dieser Form sehr gut gelungen.
Zu Deinem Patch-3 habe ich vor allem zur Funktion adc_low.c/ReadADC() eine Frage.
Warum gibst Du dort mit "return adc >> 6;" den Wert aus adcValue[mux] geshiftet zurück?
In asuro.c/IsrStandard() holt Du die maximale ADC-Auflösung mit "sensor = ADCL | (ADCH << 8 );" und schreibst diesen Wert nach adcValue[adc_cnt]. Somit sind ja erst einmal alle Bits vom Wandler vorhanden. Und auch wenn die Genauigkeit in den unteren Bits eventuell nicht so gut ist, sehe ich keinen Grund die 6 untersten Bits dann zu eliminieren.
In asuro.c/Init() schaltest Du die Odometrie-LEDs ein. Macht ja auch Sinn, wenn der ADC gleich gestartet wird. In adc.c/OdometryData() knipst Du die Lampen auch wieder an und holst die interruptermittelten Daten. Was aber, wenn der 'böse' Nutzer dir die Lampen vorher mal ausgeschaltet hat?
Das gleiche ist auch bei der Front-LED.
Also gilt auch in Deiner Interrupt-Lösung, dass die LEDs, auch die Brems-LEDs, für die Nutzung im eigentlichen Programm tabu sind.
Ich habe für die Brems-LEDs den Ansatz, dass man sie in den Zeiten, in denen die Odo-ADCs nicht in Betrieb sind, den 'Wunsch', die Dinger zu nutzen, dazwischen schiebt. Ist aber noch nicht fehlerfrei, deshalb ist der Code im Timer noch auskommentiert.
Aber zumindest könnten sie dann in Deiner Variante für 4 von 6 ADC-Läufen einschaltbar sein.
Die Einführung vom MY_SWITCH_THRESHHOLD-define ist mir suspekt.
In switches.c/PollSwitch() interpretierst Du einen ADC-Wert größer als dieses Threshhold ja als rauschen. So weit ok.
Aber in asuro.c/IsrStandard() kann ich nicht folgen an der Stelle "switched=switched || sensor<(MY_SWITCH_THRESHHOLD<<6);".
Warum schiebst Du den 'großen' Wert von Threshhold noch mal um 6 Bit. Danach ist es so groß, dass sensor doch immer darunter liegt. Oder etwa doch nicht?
So, genug Fragen für heute.
Dieses Subsumption werde ich jedenfalls auf alle Fälle bei Dir für meine nächsten Test-Programme räubern ;-). Sieht einfach wirklich besser aus.
Gruß Sternthaler
P.S.: Einen Regler habe ich für diesen Test bewusst nicht genutzt, da ich hier die Positionsbestimmung anhand von 'krummen' Geraden sehen will.
Hallo Sternthaler,
zu Subsumption
Subsumption&ASURO war schon mal in einem anderen Thread von mir angesprochen worden.
Siehe Subsumption (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=27009&highlight=subsumption)
So wie ich Subsumption im engen (und ASURO-einfachen) Sinne verstehe kommen Prozesse P(j) mit niedriger Prio erst dran wenn alle Prozesse P(i) mit höherer Prio ( hier i<j ) fertig sind bzw. erst mal "los gelassen" haben. Wenn da ein "unkooperativer" Prozess dabei ist, der z.B. in eine Endlosschleife geht, hat P(j) Pech.
Ich kann auch in wait(..) "die Schleife nicht von 0 bis zur Anzahl der eingetragenen Funktionen/Prozesse laufen" lassen weil P(j) welches ja wait(..) aufgerufen hat sonst ein zweites mal dran käme etc. . Deshalb darf ich die Schleife nur von 0 bis i<j laufen lassen oder, wie im Code steht, "currentTask<callingTask".
Würde mich freuen wenn Du Subsumption nutzt. Hat man mal einen mit dem man drüber reden kann ;-).
zu "return adc >> 6"
Frag mich nicht warum, aber ich habe festgestellt, das gilt
(iADC>>6) == pADC
dabei ist iADC das durch interrupt gewonnene Signal und pADC das entsprechende durch pollen gewonnene Signal!!?? Ok, ADC Werte sind nur 10 Bit genau. (Bemerkung: Ich wüßte auch nichts von 10 + 6 ungenauen unteren Bits.) Vielleicht vergesse ich ja irgendwo ein Flag zu setzen? Keine Ahnung! Entweder habe ich falsch hingeguckt oder die Antwort steht irgendwo im ATMEL Manuel. Da könnte ich Hilfe gebrauchen!
zu adc.c/OdometryData()
Das Einschalten der Odometrie-LEDs habe ich so belassen wie ich es in 2.8.0 vorgefunden hatte. Ich bin darüber hinaus aber der Meinung, dass man hier die Rückwärtskompatibilität aufgeben sollte und die Odometrie-LEDs nicht manipulieren sollte. Denn, wer sie irgendwo im seinem Code ausschaltet wird einen Grund dazu haben.
zu MY_SWITCH_THRESHHOLD
In switches.c/PollSwitch() wird (und wurde schon bei der Jan-Grewe-Formel) von Werten zwischen 0 und 1023 ausgegangen. Und bei dem #define von MY_SWITCH_THRESHHOLD denke ich auch im Intervall [0, 1023].
Wegen "... sensor<(MY_SWITCH_THRESHHOLD<<6);" in asuro.c/IsrStandard() siehe meine Bemerkung zu "return adc >> 6" denn sensor ist ein iADC Wert. Die hübschere Alternative: "... (sensor>>6)<MY_SWITCH_THRESHHOLD;" kostet Laufzeit.
Gruß rossir
Sternthaler
17.04.2009, 03:16
Hallo rossir,
wollte nur kurz mitteilen, dass ich länger im Forum bin als Du ;-). Somit bist Du produktiver beim Codebasteln :cheesy: .
Oh, dann habe ich das sehr wohl richtig gelesen, dass es auch mal zu vernachlässigten Prozessen kommen könnte. Hmm, hmm, ich glaube, dass mir das nicht gefällt. Oder fehlt mir nur die Erfahrung, dass es eigentlich nicht vorkommen wird, wenn die entsprechenden Prozesse richtig arbeiten? Wir werden wohl weiter zum Thema im Gespräch bleiben.
Deine Antwort zu den Shift-Aktionen muss ich mir noch mal ganz in Ruhe ansehen. Möglicherweise habe ich beim Durchstöbern vom Code etwas übersehen. Denn so richtig leuchtet mir jetzt Deine Erklärung nicht ein.
Den Link zum "Siehe Subsumption" kannte ich noch nicht. Interessant, wie sich die Struktur der AktionsList geändert hat.
Gruß Sternthaler
Hallo Sternthaler,
ok, Du hast gewonnen, Du bist länger im Forum drin als ich ;-).
Eigentlich wollte ich gar nicht lange drin sein. Dauert aber so verdammt lange einen Forum-Beitrag zu schreiben. Bin darüber jedes mal aufs Neue überrascht. Gehts Dir da ähnlich?
Ja, es kann zu "vernachlässigten Prozessen kommen". Aber, auch hier könnte man die Ansätze kombinieren. Wie gefällt Dir das Folgende (nur ca.):
/*----------------------------------------------------------------------
Daten sammeln
*/
void PROZESS_DatenSammeln(void) {
static int v_status=0;
static long v_pause_bis;
if (v_taster != T_1) return;
if (v_status == 0)
{
v_LED = RED; // User sieht rot
v_pause_bis = Gettime () + 1000; // Pausenzeit nach Taste losgelassen
//sens.aktiv |= SENS_RAD; // Rad-Sensoren starten
md.i [LINKS] = 0; // Die ersten N Messungen verwerfen
v_status++;
}
if (v_status == 1)
{
if (v_pause_bis < Gettime()) // Pausenzeit abwarten
{
v_LED = GREEN + BLINK; // User warnen: Asuro faehrt los
v_status++;
}
}
if (v_status == 2)
{
/* Motor starten und warten bis der MessDaten-Puffer voll ist */
drive (220, 220); // Geradeaus soll es gehen
md.i [LINKS] = 0; // Die ersten N Messungen verwerfen
v_status++;
}
if (v_status == 3)
{
PositionBerechnen=1; //PROZESS_PositionBerechnen: Macht nur Sinn, wenn die Messdatenaufnahme laeuft.
if (md.i [LINKS] == 20) // Kurve einleiten
{
drive (100, 160);
}
if (md.i [LINKS] == 30) // wieder geradeaus
{
drive (220, 220); // Geradeaus soll es gehen
}
if (md.i [LINKS] == 60) // Kurve einleiten
{
drive (250, 140);
}
if (md.i [LINKS] == 70) // wieder geradeaus
{
drive (220, 220); // Geradeaus soll es gehen
}
if (md.i [LINKS] >= MD_RECORD_ANZ - 1)
{
drive (0, 0); // Motor aus
//MotorDir (BREAK, BREAK);
//sens.aktiv &= ~SENS_RAD; // Rad-Sensoren stoppen
v_LED = RED + BLINK; // User ist wieder daran
v_status = 0;
PositionBerechnen=0;
v_taster=0;
}
}
}
Das ist wahr, "die Struktur der AktionsList" und damit das Subsumption Framework hat sich stark vereinfacht. War viel zu viel Balast für die mit dem ASURO möglichen Programmgrößen.
Gruß rossir
Sternthaler
19.04.2009, 01:17
Hallo zusammen,
um die 'lebenswichtige' Frage von rossir zu beantworten: Ja, ich benötige mindestens 3- bis 12-mal so viel Zeit zum Antworten als ich mir vorgestellt hatte. Ist halt wie im echten Projektleben. Die Verschätzung ist anhängig vom 'PI mal Daumen Faktor' und der Stärke des Sonnenwindes.
Hallo rossir,
auch hier hat alleine das betrachten Deiner Coderevision zu einigen Gehirnaktivitäten geführt. Ich bin nicht davon überzeugt, dass diese Mischform Vorteile bringt.
Wenn der Subsumption-Vorgang diesen Prozess 'vernachlässigt', dann bedeutet die Ablaufsteuerung innerhalb dieses Prozesses ja automatisch, dass sie mehrfach aufgerufen werden muss um wieder in den Zustand "v_status = 0" zu kommen. Somit besteht die Möglichkeit, dass sie bei mehrfacher 'Vernachlässigung' viel länger dauern wird als angenommen wird. Das Timing der Funktion gerät damit in den Bereich, in dem es nicht mehr nachvollziehbar wird.
Da ich dies aber aktuell nur als Theoretiker schreibe, werde ich morgen/heute doch wohl den Test am Asuro abbrechen müssen, wie dick eine Staubschicht dein darf um noch Daten hindurch zu IR-en.
Gut, dass Du schreibst "nur ca.". Ich hätte da schon Probleme mit der ersten Ausstiegsbedingung "if (v_taster != T_1) return;". Für mich sieht das aktuell so aus, als ob ich den Taster die ganze Zeit festhalten müsste während der Asuro seine DatenSammelFahrt macht.
Wahrscheinlich reicht ein
if (v_taster != T_1 && v_status == 0) return; um hier den Prozessablauf 'am Leben' zu halten.
So, jetzt muss ich erst einmal weiter im Buch der Zukunft lesen. Ist aktuell von John Scalzi. Der 4.te Band 'Androiden Träume' (http://de.wikipedia.org/wiki/Scalzi). Ich bin nur begeistert. Das letzte Gedruckte mit echtem Begeisterungsfaktor war 'Die Ringweltsaga' von Larry Niven (http://de.wikipedia.org/wiki/Ringwelt).
Gruß
Sternthaler
foerstie
25.02.2010, 23:57
Hallo zusammen,
dieser thread passt grad für mein Problem, auch wenn länger keiner mehr was geschrieben hat.
Also anfang der Woche hab ich mir nun auch ein asuro zugelegt (jaja, Semesterferien sind laaaange :cheesy: ); daher bin ich in dem Bereich noch ein Anfänger^^. Bisher funktioniert eigentlich alles wunderbar - bis auf dieses leidige problem mit den tastern.
Jedenfalls um auf das eigentliche Problem zurück zu kommen:
Nachdem ich neueren Verionen der Asuro-Libs entdeckt hatte, hab ich mir die neuste (AFSetup_v280rc1) geholt. Wenn man dann die exe-Datei ausführt wird das Programm "Asuro Flash(Alias Eierlegendewollmilchsau) V1.4.6.56" installiert. Wie darf man das jetzt verstehen? Denn unter der lib hab ich mir eigentlich was anderes vorgestellt. Oder beinhaltet dieses Programm die neue lib? Sry für diese wahrscheinlich super-banale Frage, aber bis man sich da mal reinarbeitet isses doch ein längerer weg. :?
Gruß
foerstie
hallo,
Ich melde mich hier, da wir(das Seminar) einige Probleme mit der Installation von der neuen Lib haben.
Wir müssten die Lib auf dem Schulserver installieren. Darum bräuchten wir eine Silent-Install oder eine gute Erklärung wie man die ZIP(Bisher viele Probleme) installiert.
Es wäre auch gut die Parameter/Switches für die Silent-Install zu wissen.
____
Bei der ZIP gibt es viele Fehler.
Ebenso ist eine normal Installation mittels .exe kaum möglich.
____
Ich hoffe auf BALDIGE Antwort.
hallo,
Ich melde mich hier, da wir(das Seminar) einige Probleme mit der Installation von der neuen Lib haben.
Wir müssten die Lib auf dem Schulserver installieren. Darum bräuchten wir eine Silent-Install oder eine gute Erklärung wie man die ZIP(Bisher viele Probleme) installiert.
Es wäre auch gut die Parameter/Switches für die Silent-Install zu wissen.
____
Bei der ZIP gibt es viele Fehler.
Ebenso ist eine normal Installation mittels .exe kaum möglich.
____
Ich hoffe auf BALDIGE Antwort.Es wurde hilfreich von dir sein wenn du schon die bekommen Fehler Meldungen hier gemeldet hatte. Ohne das können wir nur raten.
Die Zip-datei ist einfach auspacken und die readme lesen (install.txt). Aber Netzwerk Installation könnte Problemen liefern. Weil die Pfaden vermutlich nicht richtig verstanden werden. Auch hier muss du etwas mehr Informationen geben. Wir sind nicht Telepathisch.
Ausserdem gibt es eine neue version der Lib seit einige Monaten: AsuroLib-v280rc2.zip
Welcher RC (Release Candidate) hat ihr?
Die .exe version (AFSetup_v280rc1.exe) installiert ein IDE Umgebung genannt AsuroFlash von Osser:
https://www.roboternetz.de/community/threads/22627-Alternative-zu-Flashnnn-exe
Das ist nicht unbedingt nötig für das installieren der Lib, aber den Lib ist enthalten.
Sein Blog: http://seciusoft.com/AsuroFlash/
Welcher RC (Release Candidate) hat ihr?
AsuroLib-v280rc2.zip
Also zu den Pfaden, einfach gesagt der Wunschpfadder Lib ist mal h:\Pinf\AsuroLib.
Beim Fehler kommt halt Library nicht gefunde(bereits zu Hause), dabei bin ich nach der README vorgegangen.
Auf alle Fäle danke schon Mal.
Wie man das mit das AsuroFlash Programm von Osser machst verstehe ich auch nicht genau. Dazu muss du dich zu Osser richten, oder vielleicht Andere Leute die sich mit dieses Programm auskennen.
Ich brauche nur den Lib und die FirstTry Beispiel-Ordners davon wenn ich ein neues Programm schreibe. Ich mache eine Kopie von den ganzen First Try Beispiel Ordner. Ich ändere dann die makefile mit den richtige Libpath und DIRAVR Pfad. Und zur Compilieren Doppelklicke ich auf den Make-all.bat Datei. Wenn den Compiler fertig ist kann man auch den Eventuelle Fehlermeldungen in das DOS-Fenster sehen.
Mal so ich lass das Die exe jetzt mal außen vor.
Und der Anleitung wird nicht gesagt dass man bei. 2.8.2 den Avr Pfad angeben muss.
Er hat bei mir inzwischen auh eine Hex Datei erzeugt ohne Fehlermeldung.
Mein bisheriger Fehler waren die vergessenen ""/Anfuerungsstrichen. :') beim Libpath(Leerzeichen im Pfad).
m.a.r.v.i.n
05.02.2014, 09:33
Hallo,
wie valen schon andeutete. Die zip-Datei sollte für eine Blind Installation ausreichen.
Um ein eigenes Programm zu schreiben oder eines der Beispiel Programme neu übersetzen:
* die AsuroLib in einem Ordner auspacken (möglichst Pfad ohne Leerzeichen)
* Beispiel Ordner kopieren (z.B. FirstTry) (ebenfalls Pfad ohne Leerzeichen verwenden)
* Im Makefile den Pfad zur Asuro-Lib anpassen. z.B. LIBPATH = C:/ASURO_SRC/AsuroLib/lib
* Ggfs im Makefile noch den Pfad zum AVR-GCC/WinAVR Verzeichnis anpassen. z.B. DIRAVR = C:/WinAVR20100110
Der letzte Punkt fehlt noch in der readme. Das muss ich noch korrigieren.
Was die AsuroLib Exe betrifft, ich denke nicht das es einen Silent Install gibt, mach mich aber mal schlau. Es gibt bestimmt ein Plugin für den NSIS Installer, der so etwas ermöglicht.
Also ich hab jetzt alle Änderungen vorgenommen und das ganz mit batch-Dateien "benutzerfreundlicher" gemacht(neues_Pojekt_erstellen.bat/uebersetze_Projekt).
Das Übersetzen funktioniert auch ohne Probleme, also ohne Fehler.
Nun ist das Problem, dass das Flashtool(v1.5.1) streikt beim Senden. Aber nur auf dem Schulserver mit der zip; Daheim läuft es ohne Probleme mit der .exe
Des weiteren die ".exe" ändert gar nichts am libpath("LIBPATH = ../../lib"), wieso geht es dann ohne Probleme?
Als Fehlermeldung kommt vom Flashtool .c=>Checksum Error
Checksum Error. Es sind andere als die vom PC geschickten Daten bei ASURO angekommen.
Das kann durch Störlicht (wie Leuchtstofflampen) kurze Unterbrechungen in der
Sichtverbindung oder ähnliches passieren
Die erste Seite wird gesendet, danach streikt er.
Danke nomal für die bisherige Hilfe
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.