ATXmega - Pin Eingang oder Ausgang

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Hallo Leute,

ich habe mal ne recht einfach frage. Wie stelle ich fest, durch eine 
Messung, ob ein Pin eines Mikrocontrollers als Eingang oder Ausgang 
definiert wurde?

Es geht genauer um folgendes.
Ich habe mir das Xminilab von Gabotronics besorgt. 
http://www.gabotronics.com/development-boards/xmega-xminilab.htm
Nun versuchte ich, das Oszilloskop über USART anzusteuern und 
auszulesen.
Dies wollte mir nicht so recht gelingen, also habe ich den Support dort 
angeschrieben und die haben mir gesagt, dass sie die USB Pins PD6 und 
PD7 als nutzen und nicht PE2 und PE3 wie im Schaltplan vorgesehen.
Ich könne aber die Pins von Port D mit den Pins von Port E verbinden.

I recently changed the firmware so that the serial port is on pins PD6, PD7 (Micro USB connector) instead of PE2, PE3 (External Port). 
This was done because the USB stack is not ready and most users will buy the USB to UART cable to connect to the PC.
 
[...]
 
But if you wish to try now, you could solder the TX and RX to the little vias that are close to the micro USB connector.

Leider wurde mir noch nicht verraten, welche Pins mit welchen zu 
verbinden sind.
Tx->D-;
Rx->D+;
oder umgekehrt?
Auf mein Nachfragen wurde bisher noch nicht geantwortet.

Da ich bisher noch nie nen ATXmega programmiert habe, sondern nur die 
8-Bit-Varianten, werde ich leider auch aus dem Source Code so schnell 
nicht schlau.

Habt Ihr eine Idee ob und wie man messen kann, ob ein Pin als Eingang 
oder Ausgang fungiert?

Oder kann jemand den Source lesen:

    // PORTS CONFIGURATION
    // Initial value PORTA.DIR       = 0x00; // CH2, CH1, 1V, K1, K2, K3, K4, REF
//    PORTCFG.MPCMASK   = 0b00011110;   // // Pull up on pin PA4, PA3, PA2, PA1
    PORTA.PIN7CTRL  = 0x07; // Input Disable on pin PA7
    PORTA.PIN6CTRL  = 0x07; // Input Disable on pin PA6
    PORTA.PIN5CTRL  = 0x07; // Input Disable on pin PA5
    PORTA.PIN4CTRL  = 0x18; // Pull up on pin PA4
    PORTA.PIN3CTRL  = 0x18; // Pull up on pin PA3
    PORTA.PIN2CTRL  = 0x18; // Pull up on pin PA2
    PORTA.PIN1CTRL  = 0x18; // Pull up on pin PA1
    PORTA.INTCTRL   = 0x02; // PORTA will generate medium level interrupts
    PORTA.INT0MASK  = 0x1E; // PA4, PA3, PA2, PA1 will be the interrupt 0 sources
    PORTB.DIR       = 0x0B; // RES, AWG, D/C, R/W
    // Initial Value PORTB.OUT       = 0x00; //
    // Initial Value PORTC.DIR       = 0x00; // LOGIC
    PORTC.INT0MASK  = 0x01; // PC0 (SDA) will be the interrupt 0 source
    PORTC.INT1MASK  = 0x80; // PC7 (SCK) will be the interrupt 1 source
    PORTD.DIR       = 0x1F; // USB, EXT, GREEN, TX, RX, CLK, RED
    PORTD.OUT       = 0x04; // LCD voltage off
    PORTE.DIR       = 0x08; // TX, RX, RTS, CTS
    // Initial Value PORTE.OUT       = 0x00; //
    PORTCFG.VPCTRLA = 0x41; // VP1 Map to PORTE, VP0 Map to PORTB
    PORTCFG.VPCTRLB = 0x32; // VP3 Map to PORTD, VP2 Map to PORTC
    key = 0;

Vielen Dank
Fabian

[Nico (nico123)]

Laut dem Code sind nur die unteren 5 Portausgänge von Port D auf Ausgang 
gesetzt (PORTD.DIR = 0x1F;)!
Schau dir mal den Code der seriellen Schnittstelle an, da müßten 
irgendwo noch Port D6 und D7 definiert sein.

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Das habe ich jetzt so nicht gefunden.

Das einzige was ich jetzt noch so in der Main dazu fand war:

    // Initialize USARTE0 for External Interface Port
    USARTE0.BAUDCTRLA = 0x17;   // BSCALE = -6, BSEL = 1047
    USARTE0.BAUDCTRLB = 0xA4;   // ==> 115211 bps (~115.2kbps)
    USARTE0.CTRLC = 0x03;       // Async, No Parity, 1 stop bit, 8 data bits
    USARTE0.CTRLB = 0x18;       // Enable RX and TX
  USARTE0.CTRLA = 0x20;       // Enable RX interrupt

    // Event System
    EVSYS.CH0MUX = 0xE0;    // Event CH0 = TCE0 overflow used for ADC
    EVSYS.CH1MUX = 0x20;    // Event CH1 = ADCA CH0 conversion complete
    EVSYS.CH3MUX = 0xD0;    // Event CH3 = TCD0 overflow used for DAC

Aber wo PD6 und PD7 explizit neu gesetzt wurden, fand ich jetzt nicht.

Ich habe mal auch noch die main.h in den Anhang als Ergänzung zur main.c 
gepackt. Vll gibt das Aufschluss.

Ich würde auch gern den ganzen Code in den Anhang packen. Aber ich frage 
mich, wie sinnvoll das ist, zumal man es sich über den Link im ersten 
Post auch ziehen kann.

Gruß
Fabian

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Also, Messtechnisch gibt es da keinen Lösungsansatz?

[STK500-Besitzer (Gast)]

Fabian Hoemcke schrieb:
> Also, Messtechnisch gibt es da keinen Lösungsansatz?

Wenn er Ausgang ist, sollte er auch entweder bei einer gewissen 
Belastung noch nicht zusammenbrechen, oder GND-Pegel haben.
Eingänge haben i.d.R. eine relativ hohen Pull-Up-Widerstand, dessen 
Ausgangsspannung bei Belastung zusammenbrechen müsste, wenn man ihn 
stark genug belastet.
Der Ausgangswiderstand der Pins sollte aus dem Datenblatt hervorgehen.

[Wolfgang (Gast)]

Fabian Hoemcke schrieb:
> Also, Messtechnisch gibt es da keinen Lösungsansatz?
Du kannst dir immer eine Serienschaltung aus 2 x 4k7 Widerständen bauen, 
die Enden mit VCC bzw. Gnd verbinden und an der Mittelanzapfung die 
Spannung messen (vorzugsweise mit einem Oszi) und damit an den µC-Pins 
rumstochern. Solange du in der Luft oder an einem Eingang bist (und da 
niemand anderes dran zieht) mißt du VCC/2, wenn du an einen Ausgang 
gerätst, geht die Spannung näherungsweise auf VCC bzw. Gnd.

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Wolfgang schrieb:
> Fabian Hoemcke schrieb:
>> Also, Messtechnisch gibt es da keinen Lösungsansatz?
> Du kannst dir immer eine Serienschaltung aus 2 x 4k7 Widerständen bauen,
> die Enden mit VCC bzw. Gnd verbinden und an der Mittelanzapfung die
> Spannung messen (vorzugsweise mit einem Oszi) und damit an den µC-Pins
> rumstochern. Solange du in der Luft oder an einem Eingang bist (und da
> niemand anderes dran zieht) mißt du VCC/2, wenn du an einen Ausgang
> gerätst, geht die Spannung näherungsweise auf VCC bzw. Gnd.

Hi, das hört sich gut an. Wie muss ich mir das vorstellen?

In etwa so:

xxxxxxxxx            Vcc
        xxx           |
        x            xxx
        xxx          x x 4k7
   µC   x            x x
        xxx          xxx
        x             |
        xxx-----------+---------------
        x             |              |
        xxx          xxx           xxxxx
        x            x x 4k7       x V x
        xxx          x x           xxxxx
        x            xxx             |
        xxx           |              | 
xxxxxxxxx            GND            GND

Gruß
Fabian

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Fabian Hoemcke schrieb:
> // Initialize USARTE0 for External Interface Port
>     USARTE0.BAUDCTRLA = 0x17;   // BSCALE = -6, BSEL = 1047
>     USARTE0.BAUDCTRLB = 0xA4;   // ==> 115211 bps (~115.2kbps)

Wer soll das lesen können ? Richte dich doch bitte nach der für alle 
AVRs üblichen Syntax:

// serial port setup
#define USART USARTF0
/* Set baud rate */
static void USARTInit(void)
{
  USART_PORT.DIRSET   = PIN3_bm;   // Pin 3 (TXD0) as output.
  USART_PORT.DIRCLR   = PIN2_bm;   // Pin 2 (RXD0) as input.
  // USARTD0, 8 Data bits, No Parity, 1 Stop bit
  USART.CTRLC = (uint8_t) USART_CHSIZE_8BIT_gc | USART_PMODE_DISABLED_gc | false;
   /* Target: Internal RC 32MHz (default) 
    * Example (9600bps)  :   - I/O clock = 16MHz
   *                        - 9600bps can be acheived by 9600bps / 2^0
   *                        - UBRR = 16MHz/(16*19200)-1 = 51
   *                        - ScaleFactor = 0
  */  
  USART.BAUDCTRLA = BSEL_VALUE;
  // Enable both RX and TX
  USART.CTRLB |= USART_RXEN_bm;
  USART.CTRLB |= USART_TXEN_bm;
}

Ist doch gleich viel besser zu lesen, oder ?

Fabian Hoemcke schrieb:
> nie nen ATXmega programmiert habe, sondern nur die
> 8-Bit-Varianten

XMegas sind 8-bit Controller, nur mal nebenbei :P

[Wolfgang (Gast)]

Fabian Hoemcke schrieb:
> Hi, das hört sich gut an. Wie muss ich mir das vorstellen?

Genau so. Wenn der µC die Datenrichtung im Programm wild ändert, muß man 
natürlich schon mit dem Oszi genau hinsehen.

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Wolfgang schrieb:
> Fabian Hoemcke schrieb:
>> Hi, das hört sich gut an. Wie muss ich mir das vorstellen?
>
> Genau so. Wenn der µC die Datenrichtung im Programm wild ändert, muß man
> natürlich schon mit dem Oszi genau hinsehen.

Oh, vielen Dank! Das werde ich ausprobieren.

Gruß
Fabian

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Matthias Sch. schrieb:
> Wer soll das lesen können ? Richte dich doch bitte nach der für alle
> AVRs üblichen Syntax:

Ich hatte ja bereits geschrieben, von wem der Source stammt.
Und wenn Du schon auf für alle üblichen Syntax wert legst, dann lass das 
Plenken sein. ;)

Danke für das Aufdröseln, des Sources, jedoch müsste demzufolge ganz 
normal PE2 und PE3 Rx und Tx sein. Sind sie aber nicht. Laut der Firma 
sind es PD6 und PD7. Die Zuordnung aber brauche ich. Und die finde ich 
nicht im Source Code.


______

Matthias Sch. schrieb:
> XMegas sind 8-bit Controller, nur mal nebenbei :P

Ja, hatte irgendwie gedacht, dass das schon die 32-Variante sein.
Wofür hat denn diese Serie das "X" bekommen?

Gruß
Fabian

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Mich würde mal generell interessieren, wenn ich auf gut Glück die 
jeweiligen Leitungen verbinden würde und ich bei der fifty-fifty Chance 
die falschen Verbindungen ziehen würde, ob dass schlecht für den/die 
Controller wäre?.

Ich vermute mal, bei den Pins, die beide als Eingänge fungieren, 
entsteht kein Problem. Aber bei den beiden Ausgängen. Wenn der eine 
gerade HIGH ausgibt und der andere ein LOW, dann habe ich doch einen 
harten Kurzschluss oder?

Oder ist es gar unbedenklich, wenn ich es auf diese Art und Weise 
ausprobieren würde?

Gruß
Fabian