Diverse Problemchen

Hallo,

seit einiger Zeit funktionierten bei mir die Taster nicht (mehr) richtig, aber die brauchte ich auch nicht.

Nachdem ich einmal den Prozessor neu eingesteckt habe, funktionieren die Taster wieder perfekt, und auch die Motoren, die Liniensensoren und die Odometrie, aber die rechte BackLED geht nicht mehr, und die StatusLED kennt nur noch die Zustände GREEN und OFF.
Hiermit könnte ich ja leben (BackLED's kann man sowiso nicht benutzen, wenn man Odometrie macht), aber fast alle meine Programme fangen wie folgt an:

Code:

---

Init();

SerPrint("\r\nBatterie=");
PrintInt(Batterie());
SerPrint("\r\n");

---

Bisher bekam ich da auch immer Werte zwischen 970 (voll) und etwas über 800 (kurz vor VLVLVL) angezeigt.

Seit neuestem werden aber nur Werte unter 200 :( angezeigt ...

Hat jemand 'ne Idee?

Was ist denn SerWrint? warum nicht SerWrite?
Versuch mal eine ältere Version der Asuro Lib, vielleicht hat sich da ein tippfehler in der batterie-funktion eingeschlichen.

Hi,

Zitat:

---

Zitat von damaltor

Was ist denn SerWrint? warum nicht SerWrite?

---

ich verwende die Lib v270, da gibt es sowohl:

Code:

---

void SerPrint  ( unsigned char *  data ) 
Sendet einen null-terminierten String ueber die serielle Schnittstelle. (Autor: stochri)

---

als auch:

Code:

---

void SerWrite  ( unsigned char *  data,  unsigned char  length )   
Ausgabe von Zeichen ueber die serielle Schnittstell

---

Zitat:

---

Zitat von damaltor

Versuch mal eine ältere Version der Asuro Lib, vielleicht hat sich da ein tippfehler in der batterie-funktion eingeschlichen.

---

Das hat aber bis vor kurzem auch mit der Lib v270 funktioniert ...

Naja aber einen Versuch ist es doch wert... bei sourceforge gibt es noch die version 2.61, teste mal mit der.

Hi,

arbeitest du mit auto_encode=TRUE?

Es gibt Probleme, wenn die Rad Encoder im Interrupt Betrieb laufen. Das kann dann A/D Wandler Messungen stören, die in der Hauptschleife aufgerufen werden.

Das steht auch schon auf der Bugliste. In der LineData Funktion ist es z.B. schon gefixed, in der Batterie Funktion noch nicht.

Hi,

Zitat:

---

Zitat von m.a.r.v.i.n

Hi,

arbeitest du mit auto_encode=TRUE?

---

guter Hinweis, aber leider ist das nicht das Problem :(

Die letzten Zeilen von Init() setzen ja autoencode auf FALSE ...

Code:

---

  ...
  MotorSpeed(0,0);
  autoencode = FALSE;
  sei();
}

---

Zitat:

---

Es gibt Probleme, wenn die Rad Encoder im Interrupt Betrieb laufen. Das kann dann A/D Wandler Messungen stören, die in der Hauptschleife aufgerufen werden.

Das steht auch schon auf der Bugliste. In der LineData Funktion ist es z.B. schon gefixed, in der Batterie Funktion noch nicht.

---

Danke für diese Hinweise.

Werden die neuen Versionen der Lib bzw. Hinweise darauf hier im Asuro-Forum gepostet?

Hi,

Zitat:

---

Die letzten Zeilen von Init() setzen ja autoencode auf FALSE ...

---

das stimmt, aber der Aufruf der Funktionen EncoderInit() oder EncoderStart() setzt autoencode auf TRUE.

Die AsuroLib V2.70rc2 wird heute noch veröffentlicht (mit Bugliste, erweiterter Doku).

Hi,

Zitat:

---

Zitat von m.a.r.v.i.n

Zitat:

---

Die letzten Zeilen von Init() setzen ja autoencode auf FALSE ...

---

das stimmt, aber der Aufruf der Funktionen EncoderInit() oder EncoderStart() setzt autoencode auf TRUE. ...

---

aber leider liefert das obige Programmstück ohne Aufruf von EncoderInit() die falschen Werte ...

Hi,

ich habe die rechte BackLED meines Asuro's mit einem Multifunktionsmeßgerät und der Einstellung "--|>+--" getestet -- und sie hat geleuchtet! Dann habe ich die Leiterbahnen durchgemessen, und da gab es keine Verbindung, wo Kontakt sein sollte.
Auflösung:
R21 direkt vor der rechten BackLED war wohl durch häufiges wechseln des Batteriepacks in Mitleidenschaft gezogen worden, und die beiden zu R21 gehörenden Lötpunkte auf der Unterseite der Platine hatten keine Verbindung ... .
Zuerst half einfaches Wackeln am Widerstand, und dann ging die rechte BackLED wieder; später habe ich die Lötstelle aber dann auch noch richtig nachgelötet.

Und das schönste: nachdem die rechte BackLED wieder funktioniert, ist die StatusLED wieder voll funktionsfähig (inkl. RED und YELLOW)! :)

Bleibt nur noch das Problem mit der Funktion Batterie() und den Werten <255 anstelle >800 ...

Hallo Herman,

ohne jetzt genauer nachschauen zu wollen meine ich mich grob zu erinnern, dass es problematisch sein kann, den AD-Wandler zu benutzen, wenn die Encoder-Interrupts laufen. Beisst sich die Konfiguration des Wandlers bei autoencode mit der Konfiguration der Batterie()-Funktion?

Gruss,
stochri

Hallo,

Zitat:

---

Zitat von stochri

Hallo Herman,

ohne jetzt genauer nachschauen zu wollen meine ich mich grob zu erinnern, dass es problematisch sein kann, den AD-Wandler zu benutzen, wenn die Encoder-Interrupts laufen. Beisst sich die Konfiguration des Wandlers bei autoencode mit der Konfiguration der Batterie()-Funktion?

Gruss,
stochri

---

um die Mißverständnisse von oben aufzulösen, autoencode ist auf false.

Das folgende minimale Codestück zeigt das komische Verhalten (Werte <255) -- und wie gesagt, eben erst seit kurzem -- vorher kamen Werte über 800 und bei vollen Batterien über 900 raus:

Code:

---

#include <asuro.h>

int main(void)
{
  Init(); // setzt "autoencode = FALSE;"

  SerPrint("\r\nBatterie=");
  PrintInt(Batterie());
  SerPrint("\r\n");

  while (1) ;

  return 0;
}

---

Vielleicht habe ich neben dem Widerstand R21 noch irgendein anderes Bauteil in eine mißliche Lage gedrückt. Welche Bauteile (außer dem AtMega) haben denn überhaupt mit der Funktion Batterie() zu tun?

Falls es an der Hardware liegen sollte, ist es am einfachsten, mit dem Multimeter die Spannung am Eingang nachzumessen.

Gruss,
stochri

Hallo,

Zitat:

---

Zitat von stochri

Falls es an der Hardware liegen sollte, ist es am einfachsten, mit dem Multimeter die Spannung am Eingang nachzumessen.

---

habe gerade mal gemessen.
Wo die Batterien am Board festgelötet sind: 5.93V
Zwischen den beiden Pins des Schalters, die ON entsprechen: 5.50V
Anzeige des kleinen Programms: Batterie=26

Im eingeschalteten Zustand messe ich 0.72V an der Diode neben dem Einschalter.

Wo soll ich denn jetzt messen -- was meinst du mit Eingang?
Sind das bestimmte Pins am AtMega?

Eigentlich kann dieses Problem nur softwareseitig sein. wenn der asuro hardwareseitig zu gering messen würde, würde er nur blinken und VLVLVL senden.
probiere doch mal die ältere asuro lib von sourceforge.

Gefühlsmässig würde ich auch auf Software tippen, aber messen kann ja auch mal nicht schaden:

Die Batteriespannung wird mit dem PIN28 des Atmega8 gemessen, dort muss die Spannung entsprechend der Spannungsteilergleichung Upin28=Vplus*10k/(10K+12K) betragen, also geschätzt ca. 2,3 V. Die Referenzspannung an PIN20 sollte man vorsichtshalber auch gleich mitmessen.

Was die Softwareseite angeht, meine Vermutung: Irgendwas stellt Dir den ADC vom 10 auf den 8Bit Modus um, deshalb erhältst Du bei Batterie() nur noch 1/4 des Wertes.

Gruss,
stochri

Hallo, und Danke für die Tips!

Zitat:

---

Zitat von stochri

... Die Batteriespannung wird mit dem PIN28 des Atmega8 gemessen, dort muss die Spannung entsprechend der Spannungsteilergleichung Upin28=Vplus*10k/(10K+12K) betragen, also geschätzt ca. 2,3 V. Die Referenzspannung an PIN20 sollte man vorsichtshalber auch gleich mitmessen.

---

Ich habe folgende Werte gemessen (4xAA-Akku mit zusammen 5,37V, Jumper gesteckt):
Pin20: 5,21V
Pin28: 2,35V

Zitat:

---

Zitat von damaltor

... probiere doch mal die ältere asuro lib von sourceforge. ...

---

Hab jetzt auch mal mit der Lib v261 getestet, mit dem folgenden Code (da SerPrint() erst ab Lib v270 verfügbar ist):

Code:

---

#include "asuro.h"

int main(void)
{
  Init(); // setzt "autoencode = FALSE;"

  SerWrite("\r\nBatterie=",11);
  PrintInt(Batterie());
  SerWrite("\r\n",2);

  while (1) ;

  return 0;
}

---

Und nun:
Es werden wieder Werte um 930 angzeigt :)

Aber:
Jetzt funktioniert es auch wieder mit der Lib v270 ... :-k

Tja, dann würde ich auf Wackelkontakt tippen. Lass doch mal die Werte vom ASURO zum PC übertragen und drück ein wenig an den Bauteiilen rum, vielleicht stellt sich der Fehler noch mal ein ...