mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik XMEGA verliert Pin Status


Autor: Peter (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo alle zusammen,

an einem XMEGA 256A3BU stelle ich folgendes sehr merkwürdiges verhalten 
fest. An dem PORTF des XMEGA sind drei Hall-Sensoren angeschlossen. Ob 
die Sensoren betätigt sind oder nicht, stelle ich mit LEDs fest. Das 
komische ist, sobald ich einen Sensor anspreche, blitzen kurz auch die 
anderen LEDs an. Egal ob diese im Programm abgefragt werden oder nicht. 
Noch schlimmer ist, dass in einer while Schleife verblieben wird, 
solange ein Sensor betätigt ist. In dieser Schleife blinken die LED 
durch Timer Interrupt. Nun passiert aber folgendes, dass diese While 
Schleife sporadisch verlassen wird, wobei sichergestellt ist, dass die 
Sensoren betätigt sind. Das komische, dieses verhalten ist nur an PORTF 
festzustellen.
Kennt jemand diese Probleme?

Grüße Peter

Autor: Draco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gib mal Code bitte...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Immer diese vergeblichen Versuche, Programme als Prosa zu posten.

Ich hab mich auch schonmal gewundert. Ursache war ein fehlendes ;

Autor: Peter (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
also abgefragt wird mit

if (PORTF.IN & 0b00000100)
{
    PORTB.OUTSET = PIN5_BM;
}

parallel läuft ein Timer der eine weitere LED blinken lässt. das 
Komische ist auch, dass die Einabfrage mal früher mal später verlassen 
wird, wobei der Pin immer betätigt ist. Das sagt zumindest das Oszi und 
mein Finger am Sensor.

Autor: Draco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Immer diese vergeblichen Versuche, Programme als Prosa zu posten.
>
> Ich hab mich auch schonmal gewundert. Ursache war ein fehlendes ;

Ich hab mich auch schonmal gewundert. Ursache war ein fehlendes }

Autor: Peter (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Habe jetzt nochmal ganz in ruhe meine Schaltung geprüft. Auf einem 
Eingang des XMEGA generiere ich ein Eingangssignal mit ca 1 kHz. Kann 
das sein, dass sich die Frequenz überlagert und im ungünstigen 
Augenblick meinen Eingang an PORTF als LOW erkennen lässt?

Wenn ja wie kann ich das verhindern? Internen PullUp an betroffen Pin 
aktivieren und gegen Masse einen Kondensator?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Deine Schlussfolgerungen sind Quark. Zeige das ganze Programm.

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, schau mal, ob der C-Compiler einen Read-Modify-Write Sequenz 
erzeugt?
Wenn der vom Interrupt unterbrochen wird, und auf den Selben Port 
zugegrift wirds Äpfel und Bananen.

Also ich habe einiges schon mit den Xmegas gemacht, nie Probleme gehabt, 
sind klasse Teile. Besonders der 32E5.

Autor: Toralf Wilhelm (willi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Sascha schrieb:
> C-Compiler einen Read-Modify-Write Sequenz
> erzeugt

auf einem Xmega sollte der PORTB.OUTSET das nicht machen, genau dagegen 
ist der doch eingeführt....

Aber wie schon erwähnt ohne Schaltung und Code .....

Autor: Peter (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Also am Code kann es nicht liegen. Habe den statt den Eingang an PORTF 
einfach mal durch eine anderen ersetzt und dann läuft das Programm 
normal durch. Nun wenn ich den PIN abfrage, neben welchem diese 1 KHZ 
Frequenz eingeht, gibt es Probleme, Also muss sich doch diese Frequenz 
da mit Übertragen?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anstatt hier dumm herum zu raten solltest du bitte endlich den Code und 
den Schaltplan vorzeigen.

Autor: spess53 (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Hi

>Also am Code kann es nicht liegen.

Standardspruch unfähiger Softwerker.

MfG Spess

Autor: Peter (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Ganz geschmeidig ;)Also der Schaltplan ist quasi nicht vorhanden, da es 
ein XPLAIn Board ist. an das schliesse ich einfach paar tasten mit 
PULLDown 10K an und drei Hellsensoren. An diesen sind zwischen VCC und 
GND 100nF und zwischen OUT und VCC 10 K. Dazu liegt an den gleichen Eins 
ein zweiter AVR "Arduino" der einfach in 1 KHZ Takt einen Ausgang 
triggert.

Autor: Peter (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Danke für die sehr hilfreichen Ratschläge. Wenn der Code mit Abfrage 
eines anderen PINS läuft, muss es doch an der Hardware liegen? Wie 
gesagt vermute ich eine Überlagerung der Frequenz. Gibt es denn 
Hardwaremittel um das zu verhindern?

Autor: Peter (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Habe nochmal folgendes Aufgebaut. Ein Hallenser wird mit einem Magneten 
dauerhaft geschalten. Programm macht was es soll. Nun lege ich an dem 
zweiten Hallsensor mit einem Ringmagneten und einer Bohrmaschine ein 
wechselndes Signal an. Dieses Signal ist dem immer geschaltetem Sensor 
wirklich überlagert. Dann spinnt auch das Programm!

Autor: Bastian Werner (jackfrost)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du den ganzen Code postest dann sieht man vielleicht ob an andere 
Stelle was nicht passt.

Nur weil die eine Stelle geht heisst es nicht das der ganze Code passt.

Sicher das deine Abfrage alle passen ?

Bei
if (PORTF.IN & 0b00000100)
{
    PORTB.OUTSET = PIN5_BM;
}

kannst dich ja leicht um ne Null verschrieben haben.

Einfacher ist doch
if (PORTF.IN & PIN2_bm)
{
    PORTB.OUTSET = PIN5_BM;
}

Im Else Zweig löscht den Port wieder oder machst du das ein ner weiteren 
Abfrage.

Gruß JackFrost

Autor: Peter (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Die Abfrage ist in einer While-Schleife. Solange gedrückt wird leuchtet 
es. Darum sehe ich auch das Flakern. Schreibstill mit 0b oder Pin2 
bringen beide den selben Fehler. Nur ein gänzlich anderer Pin läuft

Autor: Marc Horby (marchorby)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Poste doch mal den ganzen code oder leave!

Autor: Peter (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Habe den Code leider jetzt nicht mehr zu Hand, vermute aber nach wie vor 
das überlagerte Signal. Das Flachbandkabel welches ich verwende ist 
bestimmt nicht das beste?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
> Habe den Code leider jetzt nicht mehr zu Hand

Du verschaukelst uns, oder?
Dann schreib jetzt nochmal den ganzen Code neu, teste ihn und fange 
nochmal ganz von Vorne mit vernünftigen Fragen an. Vernünftig Fragen 
beginnt mit Schaltplan und dem kompletten Code.

Autor: Peter (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Nein ich verschaukel keinen. Möchte doch nur wissen ob sich solch ein 
Signal überlagern kann und wenn ich mit welchen Komponenten ich es 
unterdrücken kann. Das Programm läuft ja wenn ich statt dem Pin einen 
anderen Abfrage!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Wenn der Code mit Abfrage
> eines anderen PINS läuft, muss es doch an der Hardware liegen?

Nö.
Solange man den Fehler nicht gefunden hat, ist ein SW-Fehler am 
warscheinlichsten.
Und insbesondere dann, wenn man den kompletten Code nicht zeigt.

Es kann aber nichts schaden, wenn man sich die Erratas im Datenblatt 
anschaut.
Z.B. der Attiny1634 hat nen ganz fiesen Bug, da geht Pin PB3 nicht als 
Eingang, solange der Watchdog nicht läuft.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
 #define F_CPU 32000000UL

 #include <avr/io.h>
 #include <avr/interrupt.h>
 #include <util/delay.h>

volatile uint8_t Null = 0;

 ISR(PORTD_INT0_vect)
 {
   Null = 1;
 }

 void main()
 {
        // Takt auf extern 16 MHZ und PLL so dass 32 MHZ aktiv sind

  OSC_XOSCCTRL = OSC_XOSCSEL_XTAL_16KCLK_gc | OSC_FRQRANGE_12TO16_gc;
  OSC.CTRL = OSC_XOSCEN_bm;
  while(!(OSC.STATUS & OSC_XOSCRDY_bm));
  OSC.PLLCTRL = OSC_PLLSRC_XOSC_gc | 2;
  OSC.CTRL |= OSC_PLLEN_bm;
  while(!(OSC.STATUS & OSC_PLLRDY_bm));
  CCP = CCP_IOREG_gc;
  CLK.CTRL = CLK_SCLKSEL_PLL_gc;
  
  /*
  Ein und Ausgänge konfigurieren
  */
  PORTE.DIRSET = PIN4_bm;

  PORTF.DIRCLR = PIN2_bm;
  
  PMIC.CTRL = PMIC_HILVLEN_bm | PMIC_MEDLVLEN_bm |PMIC_LOLVLEN_bm;
  
  sei();
  while(1)
  {

   if (!(PORTF.IN & 0b00000100)) // Wenn einschalter gedrückt ausführen
   {
                 // Interrupt für Nulldurchgänge
     PORTD.INTCTRL = PORT_INT0LVL_HI_gc;
     PORTD.INT0MASK = 0b00000001;
     PORTD.PIN0CTRL = PORT_ISC_BOTHEDGES_gc;
    
     while (!(PORTF.IN & 0b00000100))
     {
      if (Null == 1)
      {
        Null = 0;
        _delay_ms(6);
        PORTE.OUTSET = PIN4_bm;
        _delay_ms(1);
        PORTE.OUTCLR = PIN4_bm;
      }

     }

     _delay_ms(1000);
     PORTE.OUTCLR = PIN4_bm;
     TCE0.CTRLA = TC_CLKSEL_OFF_gc;
     counter = 0;
     PORTD.INTCTRL = 0x00;
     PORTD.INT0MASK = 0b00000000;
   }
   if (PORTF.IN & 0b00000100)
   {
     update = 0;

     PORTE.OUTCLR = PIN4_bm;
     TCE0.CTRLA = TC_CLKSEL_OFF_gc;
     //TCF0.CTRLA = TC_CLKSEL_OFF_gc;
     counter = 0;
     PORTD.INTCTRL = 0x00;
     PORTD.INT0MASK = 0b00000000;
   }
   }
 }

hier der Code.

Die While Schleife "Solange taster nicht gedrückt (umgekehrte Logik da 
Hallsensor aktiv LOW ausgibt), wird in ungleichen Abständen verlassen. 
Wenn die Abfrage an einem anderen PORT als an PORTF gemacht wird, läuft 
es aber durch. So scheint es jedenfalls.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
>  Möchte doch nur wissen ob sich solch ein Signal überlagern kann

Signale können sich überlagern. Ohne Schaltplan kann ich Dir keine 
Antwort geben, die in diesem konkreten Fall hilft.

> schliesse ich einfach paar tasten mit PULLDown 10K an

Das passt aber nicht zum Programmcode.

> if (!(PORTF.IN & 0b00000100)) // Wenn einschalter gedrückt ausführen

Hier wird etwas gemacht, wenn der Eingang auf LOW liegt. Wenn dein 
Taster in gedrücktem Zustand ein LOW liefert und du auch noch einen 
Pull-Down Widerstand parallel geschaltet hast, kann niemals ein HIGH 
anliegen.

Also: Schaltplan bitte!

Rücke den Quelltext anständig ein, so kann das ja keiner lesen.

Was mir spontan auffällt:

[code]
if (!(PORTF.IN & 0b00000100)) // Wenn einschalter gedrückt ausführen
{
    ...
    while (!(PORTF.IN & 0b00000100))
    {
    }
}
if (PORTF.IN & 0b00000100)
{
}

Du willst hier wohl irgendwas machen, wenn der Taster gedrückt wird und 
solange wiederholen, wie er gedrückt ist.

Taster prellen aber. Zwischen der if Abfrage und der while Schleife kann 
der Taster durchaus wieder in den "losgelassen" Zustand wechseln, so 
dass die while Schleife manchmal gar nicht ausgeführt wird.

Weiterhin kann es aus dem selben Grund passieren, dass weder der erste 
noch der zweite if Ausdruck wahr ist und es kann passieren, dass beide 
wahr sind.

Hast du das berücksichtigt?

> Noch schlimmer ist, dass in einer while Schleife verblieben wird,
> solange ein Sensor betätigt ist.

Naja, das st doch der Sinn von while(). Kann es sein, dass nicht einmal 
du Dir darüber im klaren bist, was wo angeschlossen ist und wann die 
Eingänge HIGH bzw. LOW sind?

Ich wundere mich auch sehr darüber, dass du hier mit Interrupts 
arbeitest. Dein Programm sieht ziemlich wirr aus. Wie soll es überhaupt 
funktionieren? Zeichne mal einen Programmablaufplan, zerlege es in 
Funktionen mit sprechenden Namen und benutze anständige Variablen-Namen. 
"Null" ist ein schlechter Witz.

Ich denke, wenn du die Struktur sauber hast und den Plan gezeichnet 
hast, wird Dir schon selbst auffallen, wo der Denkfehler ist. Wenn 
nicht, helfen wir dann auch gerne weiter.

> TCE0.CTRLA = TC_CLKSEL_OFF_gc;

Welche Funktion hat der Timer in deiner Anwendung und warum ist das der 
einzige Wert, den du bei unterschiedlichen Ereignissen wiederholt in 
dieses Register schreibst? Das kann so keine Sinnvolle Funktion haben!

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, danke für die Antwort. Vieles im Programm ist vom Testen über 
geblieben. Daher auch sinnlose Variablennamen oder übrig geblieben 
Timer.

Das prellen der Taster ist mir bekannt. Hier sind Hallsensoren verbaut, 
die aktiv LOW liefern. Diese Prellen nicht!

Autor: Bastian Werner (jackfrost)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

if (!(PORTF.IN & 0b00000100)) // Wenn einschalter gedrückt ausführen
   {
                 // Interrupt für Nulldurchgänge
     PORTD.INTCTRL = PORT_INT0LVL_HI_gc;
     PORTD.INT0MASK = 0b00000001;
     PORTD.PIN0CTRL = PORT_ISC_BOTHEDGES_gc;
    
     while (!(PORTF.IN & 0b00000100))
     {
      if (Null == 1)
      {
        Null = 0;
        _delay_ms(6);
        PORTE.OUTSET = PIN4_bm;
        _delay_ms(1);
        PORTE.OUTCLR = PIN4_bm;
      }

     }

    ...
   }


Ich geh mal davon aus das an PD0 der 1kHz Taktgeber sitzt, oder ? Du 
setzt die Variable bei jeder Flanke und damit ist das keine 
Nulldurchgangserkennung.


Du mischt 0x mit 0b und den "Definitions". Bleib doch bei einem

Den Intlvl kannst du doch auch einfach damit löschen :
PORTD.INTCTRL = TC_OVFINTLVL_OFF_gc


Vorallem sollte das reichen. Die Maske wegen dem INT0 Pin brauchst du 
dann nicht mehr ändern. Auch kannst du die PORTD.PIN0CTRL vor dein 
while(1) setzen.
if (Null == 1)
      {
        Null = 0;
        _delay_ms(6);
        PORTE.OUTSET = PIN4_bm;
        _delay_ms(1);
        PORTE.OUTCLR = PIN4_bm;
      }

Du setzt 0 Null auf 0 und wartest dann 6 ms und dann triggerst du den 
PE4 für eine ms ? Sind da deine LEDs dran , siehst du das oder willst du 
das nur mit dem Oszi sehen ?

Während der Wartezeit ist Null wieder 1 da die ISR bei 1kHz mindestens 6 
mal ausgelöst wurde. Dein Null=0 am Anfang bringt also nix. Wenn das 
Programm wieder bei if steht wird das ausgeführt und es ist nicht 
definiert wie der Zustand an deinem PD0 ist.

Du wartest dann noch eine Sekunde
_delay_ms(1000);

Und auch da wird Null wieder auf 1 gesetzt.

Die beiden
PORTE.OUTCLR = PIN4_bm;
weiter unten kannst du dir auch sparen , da der PE4 bereits 0 ist wenn 
du die while Schleife verlässt. Vermutlich wird das Compiler eh löschen.

Wie hast du denn die Hallsensoren an den PORTF gehängt ? Laut dem 
Schaltplan vom XPLAIN 256A3BU sind an PF die Taster, der Flash und der 
Qtouch aber da geht kein PIN von PF auf die Stiftleisten.

Peter schrieb:
> an das schliesse ich einfach paar tasten mit
> PULLDown 10K an und drei Hellsensoren. An diesen sind zwischen VCC und
> GND 100nF und zwischen OUT und VCC 10 K. Dazu liegt an den gleichen Eins
> ein zweiter AVR "Arduino" der einfach in 1 KHZ Takt einen Ausgang
> triggert.


Zeichne mal einen Plan das kann doch keiner mehr verstehen wie deine 
Hardware aufgebaut ist. Sind da nun Taster oder nicht ? Was meinst du 
mit an den gleichen PINs ist der Taktgeber ?

Gruß JackFrost

: Bearbeitet durch User
Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Poste uns doch mal bitte einen Schaltplan! Wenn du keinen hast, dann 
zeichne einen! Ich habe gehört das soll sogar mit Papier und Bleistift 
gehen!

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja und wie kommt der Plan dann ins Internet? Mit dem Smarphone kann er 
doch nur Fotos machen :-)

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin gerade im Auto und kann leider nicht malen. Das Programm von vorhin 
passt nicht mehr zur gestrigen Beschreibung, da ich das mit der Frequenz 
ausschließen wollte. Habe nur noch mit 50Hz getriggert und dann den 
Hallsensor mit einem Magneten angesprochen. Laut Oszi ist das Signal 
dauerhaft auf Low, der Xmega verliert aber den Status. Der Fehler 
scheint weg zu sein, wenn ich nah an den bin einen Kondensator mit 4.7 
nF schalte.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Peter schrieb:
> Laut Oszi ist das Signal
> dauerhaft auf Low, der Xmega verliert aber den Status.

Der XMEGA verliert gar nichts! Du konfigurierst die Ports nicht richtig 
oder Dein Programm macht Unsinn. Punkt.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das irgendwas Unsinn macht ist mir klar und ist ja mein Problem! Aber 
wie soll ich anders Konfigurieren als oben?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bilde mir auch ein, dass das Programm geht weil: wird ein anderer 
Pin abgefragt als der Hallsensor läuft alles ohne Probleme. Demnach muss 
der Hallsensor was einkoppeln. Und der Fehler kommt mal nach 5 min dann 
lange gar nicht mehr oder in kurzen Abständen hintereinander. Darum 
vermute ich halt dass die Hardware nicht ganz klappt. Der Hallsensor ist 
mit dem Ausgang direkt am Pin des Xmega inkl Pullup.

Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das soll auf einem Xplain-Board laufen. Atmel hat sicher Doku über das 
Board online.

Autor: Bastian Werner (jackfrost)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Ich bilde mir auch ein, dass das Programm geht weil: wird ein anderer
> Pin abgefragt als der Hallsensor läuft alles ohne Probleme. Demnach muss
> der Hallsensor was einkoppeln. Und der Fehler kommt mal nach 5 min dann
> lange gar nicht mehr oder in kurzen Abständen hintereinander. Darum
> vermute ich halt dass die Hardware nicht ganz klappt. Der Hallsensor ist
> mit dem Ausgang direkt am Pin des Xmega inkl Pullup.

Du hast also an den Pin des XMEGA eine Pullup und die Flachbandleitung 
angelötet. An dem gleichen Pin an dem auf dem Board der Taster ist und 
ein 100 k Pullup ? Schonmal auf Zinnbrücken überprüft ?

Und wenn du einen x belobigen Pin abfragst obwohl de Hallsensor 
angeschlossen ist dann geht dein Program ? Wenn ja, dann liegt der 
Fehler in der Software.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein. Sorry blöd ausgedrückt. Habe ein weiteres Board gekauft wo ein 
Xmega mit randbeschaltung vorhanden ist aber keine Taster. Dann schließe 
ich einen Taster an mit 10k pullup und löte ein Flachbandkabel ca 20cm 
lang an. An dem Ende an Vcc und Gnd den Hallsensor und dann den dritten 
Pin über das Kabel an den Xmega. Dazu kommt nur ein pullup vom Ausgang 
des Sensors auf Vcc. Wenn ich nun das Programm laufen lasse und den 
Taster Abfrage läuft es richtig durch. Beim Abfragen des Hallsensor 
springt es in unterschiedlichen Abständen aus der while schleife. Die 
korrekte Funktion wird durch ein blinken einer LED angezeigt.

Autor: Bastian Werner (jackfrost)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Poste einfach einen Schaltplan. Keine außer dir weiß was da verbaut ist 
und ob das alles passt.

Gruß JackFrost

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sitze gerade im Auto da ist zeichnen nach wie vor schlecht. Deshalb 
versuche ich es so gut wie möglich zu erklären.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> versuche ich es so gut wie möglich zu erklären.
Lass es, ist Zeitverschwendung.

Autor: Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier der Anschluss von Sensor und Taster. Der Kondensator im 
gestricheltem Kästchen bewirkt dass das Programm scheinbar richtig 
läuft. Kann es nicht hundert pro sagen da es auch ohne mal länger mal 
kürzer läuft. Mit Kondensator jedoch bis jetzt ohne Aussetzer.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Findet ihr noch grobe Fehlet im Code oder sollte es vom Prinzip so 
laufen? Mögliche Bugs oder Stolperstellen mit Atmel Studio 7 oder Xmega? 
Könnte mir sonst nur mit dem eingezeichneten Kondensator helfen oder die 
whileschleife eventuell erst verlassen wenn 10 ms hintereinander der Pin 
einen High Zustand hat? Dafür müsste man aber genau wissen dass der 
Fehler vom Hallsensor kommt. Warum sieht man nichts auf dem Oszi?

Autor: Hubert G. (hubertg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir wissen nicht was da an Störungen bei dir herumläuft.
Mir hat in einem ähnlichen Fall folgendes geholfen:
Nimm ein 5adriges Flachbandkabel, Q in die Mitte. Die Leitungen links 
und rechts davon legst du nur auf der µC Seite auf GND. Für VCC und GND 
zum Sensor nimmst du die jeweils äußeren Adern.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber sollte man die Störungen nicht auf dem Oszi sehen können?

Autor: Hubert G. (hubertg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Demnach muss
> der Hallsensor was einkoppeln. Und der Fehler kommt mal nach 5 min dann
> lange gar nicht mehr oder in kurzen Abständen hintereinander.

Ob du das im Oszi siehst?

Autor: Gerhard G. (xmega)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,


siehe Schaltbild


Gruß G.G.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Schaldbild ist mir bekannt aber für den div 5023 unnötig oder?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>div 5023

Was soll das sein?

MfG Spess

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry Dvc 5023. das sind die Sensoren von TI.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Sorry Dvc 5023. das sind die Sensoren von TI.

Verarschen kann ich mich selber.

MfG Spess

Autor: Christian Müller (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> image.jpeg

GND an DVC angeschlossen?

Chregu

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry war richtig auf dem Falschen Dampfer. DRV5023 heißen die Sensoren 
von Texas!

Autor: Christian Müller (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch die brauchen GND!

Chregu

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja Gnd ist definitiv mit dran! Das Signal von Sensor bis zum Pin des 
Xmega ist auf dem Oszi auch sauber!

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn deine Pull-Up Widerstände 10MΩ hätten oder deine Leitung 20m lang 
wäre, dann hätte ich Dir geschrieben, dass dein Problem kein Wunder ist.

Aber bei 10kΩ und 20cm ist ein kapazitives Übersprechen von einer 
Leitung zur Nächsten so gut wie ausgeschlossen. Es sei denn, der Ausgang 
vom Hall Sensor liefert keine sauberen Pegel.

Bei einer ungültigen Spannung zwischen HIGH und LOW genügen schon 
geringste Schwankungen, um einen Wechsel zwischen 1 und 0 auszulösen.

Mess da mal die Spannung nach. HIGH sollte >2V sein und Low sollte <0,7V 
sein. Wenn nicht, dann sind die Signale, die der Sensor liefert nicht zu 
deinem Mikrocontroller kompatibel. Dann kann man sicher mit einem 
Transistor oder CMOS Gatter nachhelfen.

: Bearbeitet durch User
Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also der Sensor liefert exakt 3,3 Volt High und 0,1V Low. Werde die 
Randbeschaltung vom Sensor ein zweites Mal inkl Kondensator vom Ausgang 
auf Masse ein zweites Mal direkt vor den Controller bringen. Ich hoffe 
das Problem ist dann weg.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Halte uns bitte auf dem laufenden, das ist nämlich schon ein kurioses 
Problem.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr gerne! Da der Fehler so unrägelmäßig kommt muss es von der Hardware 
kommen da bin ich mir sicher. Werde das mit der randbeschaltung hoch an 
die MCU ziehen!

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es würde mich trotzdem interessieren, warum man solche Störungen 
scheinbar nicht auf dem Oszi sieht?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weil sie unregelmäßig sind.

Um unregelmäßige Signale mit einem Oszilloskop zu erfassen brauchen Sie 
ein digitales Gerät mit Speicher und eine Triggerung auf genau diese 
Störung.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.