Zugriff auf Array

[Simon (Gast)]

Hier soll die Baudrate anhand eines DIp Switches eingestellt werden.


#define DIP_SW ~PINC & 0x3F
(DIP_SW entspspricht 5)


Funktioniert:

const uint16_t UBRR_VAL[] = { 2303,575,287,143,71,47,35,23,17,11,8,5,2 };
UBRRH = UBRR_VAL[5] >> 8;
UBRRL = UBRR_VAL[5] & 0xFF;

Funktioniert nicht:

UBRRH = UBRR_VAL[DIP_SW] >> 8;
UBRRL = UBRR_VAL[DIP_SW] & 0xFF;

Woran liegt das?

[Klaus W. (mfgkw)]

Tja, dann ist DIP_SW vielleicht doch nicht 5?

[Matthias L. (Gast)]

#define DIP_SW ~PINC & 0x3F

Um den DIP-Sw einzulesen brauchst du eine Hilfsvariable:

#define DIP_SW ~PINC & 0x3F

const uint16_t UBRR_VAL[] = { 2303,575,287,143,71,47,35,23,17,11,8,5,2 };

uint8_t u8Dip = DIP_SW;

UBRRH = (uint8_t) ( UBRR_VAL[u8Dip] >> 8    );
UBRRL = (uint8_t) ( UBRR_VAL[u8Dip] &  0xFF );

[Simon (Gast)]

auch die hilfsvariable funzt nicht.

Der DIP schalter hängt an Port C. auf on steht hier PINC0 und PINC2
ergibt somit 5. diese 5 Lese ich auch wunderbar per UART aus.

z.B. direkt im uart init:

void myuart_init(void) {


  UBRRH = UBRR_VAL[5] >> 8;

  UBRRL = UBRR_VAL[5] & 0xFF;

  // Enable receiver and transmitter; enable RX interrupt

  UCSRB = (1 << RXEN) | (1 << TXEN) | (1 << RXCIE);

  UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // Asynchron 8N1

  myuart_putc(DIP_SW);
  <- gibt schön die 5 aus
}

Verwende ich aber:
UBRRH = UBRR_VAL[DIP_SW] >> 8;
UBRRL = UBRR_VAL[DIP_SW] & 0xFF;

oder das Beispiel von lippy wird da eine
240 drauß (0x11110000)

vermutlich weil er da irgendwas falsches einstellt

[Simon (Gast)]

UBRRH = UBRR_VAL[5] >> 8;
  UBRRL = UBRR_VAL[5] & 0xFF;
  myuart_putc(UBRRH);
  myuart_putc(UBRRL);

Schreibt den Richtigen wert aus -> 47

  uint8_t u8Dip = DIP_SW;

  myuart_putc(u8Dip);
  (gibt auch 5 aus)

  uint8_t UBRRHX = UBRR_VAL[u8Dip] >> 8;
  uint8_t UBRRLX = UBRR_VAL[u8Dip] & 0xFF;

  myuart_putc(UBRRHX);
 (gibt 255 aus)


  myuart_putc(UBRRLX);
 (gibt 255 aus)

[Stefan E. (sternst)]

Und die Definition von UBRR_VAL sieht wirklich exakt so aus, wie im 
ersten Posting, oder ist da vielleicht noch ein PROGMEM beteiligt?

[Matthias L. (Gast)]

  myuart_putc(u8Dip);
  (gibt auch 5 aus)

  uint8_t UBRRHX = UBRR_VAL[u8Dip] >> 8;
  uint8_t UBRRLX = UBRR_VAL[u8Dip] & 0xFF;

  myuart_putc(UBRRHX);
 (gibt 255 aus)


  myuart_putc(UBRRLX);
 (gibt 255 aus)

Was mich hier wundert:
Die Veränderung von UBRRHx wirkt sich doch sofort aus. Also ist die 
"empfangene" 255 nicht sicher. Es kann auch ein falsch eingestellter 
Empfänger sein. Ich würde mir das mal mit dem Oszi ansehen.

[Stefan E. (sternst)]

Matthias Lipinsky schrieb:
> Die Veränderung von UBRRHx wirkt sich doch sofort aus.

Nö, das sind doch nur zwei Hilfsvariablen, nicht die UARRT-Register.

[Stefan E. (sternst)]

Und falls meine Frage oben (Definition von UBRR_VAL sieht wirklich exakt 
so aus) mit Ja zu beantworten ist, dann zeige mal die Kommandozeile für 
die HEX-File-Erzeugung. Denn dann dürfe dort die .data-Section fehlen.

[Simon (Gast)]

also ein progmem ist nicht im spiel, irgendwie bin ich bisle ratlos.



Ich werd morgen nochmal schaun ob man das irgendwie debuggen kann.

verwendet wird hier:

avrdude-5.10
avr-libc-1.7.1
gcc-4.6.1

[Matthias L. (Gast)]

Stefan Ernst schrieb:
> Matthias Lipinsky schrieb:
>> Die Veränderung von UBRRHx wirkt sich doch sofort aus.
>
> Nö, das sind doch nur zwei Hilfsvariablen, nicht die UARRT-Register.

Woran erkennst Du das?

[Simon (Gast)]

Makefile:

PROJECT=uart-tester
SOURCES=myuart.c uart-tester.c
CC=avr-gcc
OBJCOPY=avr-objcopy
MMCU=atmega8

# --------------------- CFLAGS
CFLAGS=-mmcu=$(MMCU) -Wall
CFLAGS += -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char 
-funsigned-bitfields -fpack-struct -fshort-enums -DF_CPU=11059200UL

$(PROJECT).hex: $(PROJECT).out
  $(OBJCOPY) -j .text -O ihex $(PROJECT).out $(PROJECT).hex


$(PROJECT).out: $(SOURCES)
  $(CC) $(CFLAGS) -I./ -o $(PROJECT).out $(SOURCES)

[Simon (Gast)]

UBRRHx sind variablen die mit dem UART wirklich nichts zu tun haben, ich 
habe sie einfach nur so genannt

[Klaus W. (mfgkw)]

Simon schrieb:
> also ein progmem ist nicht im spiel, irgendwie bin ich bisle ratlos.

Das sind alle anderen auch, wenn du nur stückweise Infos lieferst.
Wie soll da jemand helfen?

Ist es so schwer, ein vollständiges Programm, einen Schaltplan und 
wenigstens den verwendeten PRozessor zu verraten?

Man hat ja auch noch anderes vor im Leben als nur herumzuraten.

[Stefan E. (sternst)]

Matthias Lipinsky schrieb:
> Stefan Ernst schrieb:
>> Matthias Lipinsky schrieb:
>>> Die Veränderung von UBRRHx wirkt sich doch sofort aus.
>>
>> Nö, das sind doch nur zwei Hilfsvariablen, nicht die UARRT-Register.
>
> Woran erkennst Du das?

uint8_t UBRRHX = UBRR_VAL[u8Dip] >> 8;

Erstens ist das explizit eine Variablendeklaration, und zweitens heißt 
das Register anders (UBRRH nicht UBRRHX).

[Stefan E. (sternst)]

  $(OBJCOPY) -j .text -O ihex $(PROJECT).out $(PROJECT).hex

Da ist dein Problem. Du musst auch die .data-Section ins HEX-File 
exportieren.

[Simon (Gast)]

exakt das wars!!
Danke an alle!

selbst das hier funzt nun:

UBRRH = UBRR_VAL[DIP_SW] >> 8;

UBRRL = UBRR_VAL[DIP_SW] & 0xFF;

$(OBJCOPY) -j .text -j .data -O ihex $(PROJECT).out $(PROJECT).hex

Zum Verständnis.. woher hast du das gewusst das sich das
so äussert?!

Also das es an der Fehlenden .data section lag?

[Stefan E. (sternst)]

Simon schrieb:
> Also das es an der Fehlenden .data section lag?

Hier

  myuart_putc(u8Dip);
  (gibt auch 5 aus)

  uint8_t UBRRHX = UBRR_VAL[u8Dip] >> 8;
  uint8_t UBRRLX = UBRR_VAL[u8Dip] & 0xFF;

  myuart_putc(UBRRHX);
 (gibt 255 aus)

  myuart_putc(UBRRLX);
 (gibt 255 aus)

ist zu sehen, dass das Array nicht mit den korrekten Werten 
initialisiert ist. Und diese Initialisierungswerte liegen nun mal in der 
.data-Section.