Arduino: "digitalWrite" geht. "PORTD/PORB" ist un zuverlässig?

Suche im Forum nach "Pin Mapping", oder gleich unter Tutorials|Hacking.

Beim Uno liegt Port D auf Pin 0-7, und Port B (untere Bits) auf 8-13.

DoDi

Display-Controller bis zur Datenfreigabe lassen muss. Ein Oszi ist da

etwas eigenwillige Vorstellung davon wie er den Code optimiert.

Gerald

Am 02.04.2017 um 17:32 schrieb Marte Schwarz:

Gerald

Zumindest werden die in der Funktion digitalWrite gespeichert und nach dem Schreiben wieder hergestellt:

void digitalWrite(uint8_t pin, uint8_t val) { uint8_t timer = digitalPinToTimer(pin); uint8_t bit = digitalPinToBitMask(pin); uint8_t port = digitalPinToPort(pin); volatile uint8_t *out;

if (port == NOT_A_PIN) return;

// If the pin that support PWM output, we need to turn it off // before doing a digital write. if (timer != NOT_ON_TIMER) turnOffPWM(timer);

out = portOutputRegister(port);

uint8_t oldSREG = SREG; cli();

if (val == LOW) { *out &= ~bit; } else { *out |= bit; }

SREG = oldSREG; }

Hallo,

jetzt falle ich aber wirklich vom Glauben ab. Fix ist oben eingebaut. Aber warum????

Wenn ich diese Bitfolge zuerst auf "PORTD" "unde", dann funktioniert

Manuel

Manuel Reimer schrieb:

Da auch.

Marc

Marc Santhoff schrieb:

Christian

Ist das Resultat davon nicht ein Boolean? Habe ich aber nun probiert. Dann kommt garnichts mehr am LCD an.

Ich habe weiter getestet. Man kann auch folgendes als "Fix" verwenden:

PORTD &= B11011111;

"LOW" gezogen.

digitalWrite(5, LOW);

Geht auch damit noch.

muss dieses eine Bit im Voraus low ziehen?

Eigentlich sollte es dem LCD (T6963C) ja egal sein wie ich die Bits setze. Ich ziehe CE, WR und CD ja erst "High" wenn die Bits anliegen. Ich hatte auch schon ein Delay zwischen "Bits setzen" und "Statusleitungen hochziehen" eingebaut. Auch das hilft nicht. Dann wird

Manuel

Manuel Reimer schrieb:

Mir ist nicht ganz klar, wie Du auf diese Bitfolge gekommen bist. Warum ausgerechnet B10000011? Abgesehen davon ist sowas immer ein Grund, sich

Christian

Manuel Reimer schrieb:

Laut Datenblatt darfst Du CD ja nicht gleichzeitig mit /CE und /WR

Christian

PORTD &= B11011111

reicht. Damit wird nur ein einziges Bit "low" gezogen. Auch damit

wirklich.

da rankomme... Was muss ich tun um diese Funktion in Assembler zu wandeln?

Manuel

Manuel Reimer schrieb:

Du kannst auch ein mit Debugginginformationen ("gcc -g") compiliertes Objekt-File (.o) mit "objdump -S" wieder ausgeben lassen:

Allerdings liest sich das nach Deinem Posting von 11:01 Uhr doch eher nach einem Problem mit der Ansteuerung des LCD-Controllers als mit dem generierten Code.

Christian

void SendData(unsigned char aData) { digitalWrite(PIN_CD, LOW); // CD down (data) __asm__ __volatile__ ("nop\n\t"); digitalWrite(PIN_WR, LOW); // CD & WR down digitalWrite(PIN_CE, LOW); ParportWriteData(aData); digitalWrite(PIN_CE, HIGH); // CE & WR up again digitalWrite(PIN_WR, HIGH); __asm__ __volatile__ ("nop\n\t"); digitalWrite(PIN_CD, HIGH); // CD up again }

zuerst mit B11011111 "verunde".

Manuel

Manuel Reimer schrieb:

Christian

Klar ist da wirklich nichts, daher vermute ich irgendwelche Seiteneffekte mit den alternativen Portfunktionen. Dein Programm

von Port D.

(und/oder PIND) nach jedem Schritt in ein Array zu schreiben, und das

Code vorgegeben, dann spuckt irgendwas (Interrupt-Handler, PWM...) dazwischen.

Und die Masken sollten als "const" deklariert werden.

DoDi

Wie geht das?

Manuel

Wahrscheinlich.

besonders stark wo "nur Nullen" auf das Display sollen. Also keine Pixel gesetzt werden.

In dem Fall scheinen Null-Bits verschluckt zu werden, was das

Manuel

Du solltest Dir mal die Signale mit einem OSZI anschauen, eventuell sind die Signalflanken zu flach. Das hatte ich gerade bei der Senderichtungsumschaltung an einer RS485.

Schutzbeschaltung?

Gerald