XMEGA verliert Pin Status

Gib mal Code bitte...

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.

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 }

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?

Deine Schlussfolgerungen sind Quark. Zeige das ganze Programm.

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.

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?

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

Hi

>Also am Code kann es nicht liegen.

Standardspruch unfähiger Softwerker.

MfG Spess

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.

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?

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!

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

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?

> 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.

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!

1

 #define F_CPU 32000000UL

2

3

 #include <avr/io.h>

4

 #include <avr/interrupt.h>

5

 #include <util/delay.h>

6

7

volatile uint8_t Null = 0;

8

9

 ISR(PORTD_INT0_vect)

10

 {

11

   Null = 1;

12

 }

13

14

 void main()

15

 {

16

        // Takt auf extern 16 MHZ und PLL so dass 32 MHZ aktiv sind

17

18

  OSC_XOSCCTRL = OSC_XOSCSEL_XTAL_16KCLK_gc | OSC_FRQRANGE_12TO16_gc;

19

  OSC.CTRL = OSC_XOSCEN_bm;

20

  while(!(OSC.STATUS & OSC_XOSCRDY_bm));

21

  OSC.PLLCTRL = OSC_PLLSRC_XOSC_gc | 2;

22

  OSC.CTRL |= OSC_PLLEN_bm;

23

  while(!(OSC.STATUS & OSC_PLLRDY_bm));

24

  CCP = CCP_IOREG_gc;

25

  CLK.CTRL = CLK_SCLKSEL_PLL_gc;

26

27

  /*

28

  Ein und Ausgänge konfigurieren

29

  */

30

  PORTE.DIRSET = PIN4_bm;

31

32

  PORTF.DIRCLR = PIN2_bm;

33

34

  PMIC.CTRL = PMIC_HILVLEN_bm | PMIC_MEDLVLEN_bm |PMIC_LOLVLEN_bm;

35

36

  sei();

37

  while(1)

38

  {

39

40

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

41

   {

42

                 // Interrupt für Nulldurchgänge

43

     PORTD.INTCTRL = PORT_INT0LVL_HI_gc;

44

     PORTD.INT0MASK = 0b00000001;

45

     PORTD.PIN0CTRL = PORT_ISC_BOTHEDGES_gc;

46

47

     while (!(PORTF.IN & 0b00000100))

48

     {

49

      if (Null == 1)

50

      {

51

        Null = 0;

52

        _delay_ms(6);

53

        PORTE.OUTSET = PIN4_bm;

54

        _delay_ms(1);

55

        PORTE.OUTCLR = PIN4_bm;

56

      }

57

58

     }

59

60

     _delay_ms(1000);

61

     PORTE.OUTCLR = PIN4_bm;

62

     TCE0.CTRLA = TC_CLKSEL_OFF_gc;

63

     counter = 0;

64

     PORTD.INTCTRL = 0x00;

65

     PORTD.INT0MASK = 0b00000000;

66

   }

67

   if (PORTF.IN & 0b00000100)

68

   {

69

     update = 0;

70

71

     PORTE.OUTCLR = PIN4_bm;

72

     TCE0.CTRLA = TC_CLKSEL_OFF_gc;

73

     //TCF0.CTRLA = TC_CLKSEL_OFF_gc;

74

     counter = 0;

75

     PORTD.INTCTRL = 0x00;

76

     PORTD.INT0MASK = 0b00000000;

77

   }

78

   }

79

 }

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.

>  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!

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!

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

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.

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

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.

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.

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

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

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.

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?

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

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

Hi

>div 5023

Was soll das sein?

MfG Spess

Sorry Dvc 5023. das sind die Sensoren von TI.

Hi

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

Verarschen kann ich mich selber.

MfG Spess

Peter schrieb:
> image.jpeg

GND an DVC angeschlossen?

Chregu

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

Auch die brauchen GND!

Chregu

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

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.

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.

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

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!

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

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.