Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #225459 > unrolled thread

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

Back to article view | Back to de.sci.electronics

Contents

  Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-02 11:50 +0200
    Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Peter Thoms <dl6lat@darc.de> - 2017-04-02 12:15 +0200
      Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-02 12:59 +0200
        Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-04-02 16:32 +0200
          Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-02 16:41 +0200
    Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? "MaWin" <me@private.net> - 2017-04-02 12:50 +0200
      Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-02 12:56 +0200
    Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-02 13:12 +0200
      Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-02 13:23 +0200
        Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2017-04-02 16:06 +0200
          Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-02 16:27 +0200
            Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-04-02 16:42 +0200
            Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2017-04-02 20:24 +0200
        Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Edzard Egberts <news@edzeg.net> - 2017-04-03 09:17 +0200
    Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Marc Santhoff <m.santhoff@t-online.de> - 2017-04-02 14:22 +0200
      Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-02 14:49 +0200
        Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Marc Santhoff <m.santhoff@t-online.de> - 2017-04-02 15:00 +0200
    Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-02 16:46 +0200
    Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2017-04-02 17:32 +0200
      Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-02 18:31 +0200
        Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2017-04-02 18:45 +0200
        Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-04-02 19:44 +0200
        Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-03 08:49 +0200
      Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Michael Bäuerle <michael.baeuerle@gmx.net> - 2017-04-02 18:38 +0200
      Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2017-04-02 20:37 +0200
    Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-04-02 18:48 +0200
    Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-08 01:28 +0200
      Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Marc Santhoff <m.santhoff@t-online.de> - 2017-04-08 02:09 +0200
        Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-08 10:56 +0200
        Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-08 11:01 +0200
          Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-08 11:14 +0200
            Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-08 11:25 +0200
              Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-08 11:38 +0200
                Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-08 14:41 +0200
                  Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2017-04-08 17:45 +0200
                    Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2017-04-08 18:07 +0200
                      Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-09 11:59 +0200
                        Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2017-04-09 13:11 +0200
                          Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-09 14:06 +0200
                            Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-04-09 14:23 +0200
                            Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-09 14:49 +0200
                              Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-09 16:46 +0200
      Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-08 11:03 +0200
        Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-08 11:18 +0200
          Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-08 11:23 +0200
            Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-09 13:27 +0200
              Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-09 13:51 +0200
      Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-04-08 12:47 +0200
        Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-04-08 14:38 +0200
          Re: Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-04-08 18:45 +0200

Page 1 of 3  [1] 2 3  Next page →

#225459 — Arduino: "digitalWrite" geht. "PORTD/PORB" ist unzuverlässig?

Hallo,

ich möchte ein grafisches LCD mit einem Arduino ansteuern.

Das geht im wesentlichen auch bereits, ist aber noch etwas langsam.

Um den Aufbau zu beschleunigen dachte ich mir, es könnte interessant 
sein, mal mit den Port-Registern zu probieren.

Ich habe zwei Funktionen:

// Set one byte to the parallel interface
void ParportWriteDataDW(unsigned char aData) {
   digitalWrite(PIN_D0, aData & (1<<0));
   digitalWrite(PIN_D1, aData & (1<<1));
   digitalWrite(PIN_D2, aData & (1<<2));
   digitalWrite(PIN_D3, aData & (1<<3));
   digitalWrite(PIN_D4, aData & (1<<4));
   digitalWrite(PIN_D5, aData & (1<<5));
   digitalWrite(PIN_D6, aData & (1<<6));
   digitalWrite(PIN_D7, aData & (1<<7));
}

// Set one byte to the parallel interface
void ParportWriteData(unsigned char aData) {
   unsigned char maskD = B11111100;
   unsigned char bitsD = aData << 2;
   PORTD = (PORTD & ~maskD) | (bitsD & maskD);
   unsigned char maskB = B00000011;
   unsigned char bitsB = aData >> 6;
   PORTB = (PORTB & ~maskB) | (bitsB & maskB);
}


Von der Idee her hätte ich gedacht, dass die eigentlich das gleiche tun 
sollten.

Im Wesentlichen bekomme ich auch das auf's LCD was ich erwarten würde. 
Allerdings verschoben.

Ich habe die "Register-Variante" schon mit zahlreichen "nops" extrem 
verlangsamt aber sauber werden die Ausgaben nie...

Jemand einen Tipp was falsch läuft?

Danke im Voraus

Gruß

Manuel

[toc] | [next] | [standalone]

#225460

Am 02.04.2017 um 11:50 schrieb Manuel Reimer:
> Hallo,
>
> ich möchte ein grafisches LCD mit einem Arduino ansteuern.
>
> Das geht im wesentlichen auch bereits, ist aber noch etwas langsam.
>
> Um den Aufbau zu beschleunigen dachte ich mir, es könnte interessant
> sein, mal mit den Port-Registern zu probieren.
>
> Ich habe zwei Funktionen:
>
> // Set one byte to the parallel interface
> void ParportWriteDataDW(unsigned char aData) {
>   digitalWrite(PIN_D0, aData & (1<<0));
>   digitalWrite(PIN_D1, aData & (1<<1));
>   digitalWrite(PIN_D2, aData & (1<<2));
>   digitalWrite(PIN_D3, aData & (1<<3));
>   digitalWrite(PIN_D4, aData & (1<<4));
>   digitalWrite(PIN_D5, aData & (1<<5));
>   digitalWrite(PIN_D6, aData & (1<<6));
>   digitalWrite(PIN_D7, aData & (1<<7));
> }
>
> // Set one byte to the parallel interface
> void ParportWriteData(unsigned char aData) {
>   unsigned char maskD = B11111100;
>   unsigned char bitsD = aData << 2;
>   PORTD = (PORTD & ~maskD) | (bitsD & maskD);
>   unsigned char maskB = B00000011;
>   unsigned char bitsB = aData >> 6;
>   PORTB = (PORTB & ~maskB) | (bitsB & maskB);
> }
>
>
> Von der Idee her hätte ich gedacht, dass die eigentlich das gleiche tun
> sollten.
>
> Im Wesentlichen bekomme ich auch das auf's LCD was ich erwarten würde.
> Allerdings verschoben.
>
> Ich habe die "Register-Variante" schon mit zahlreichen "nops" extrem
> verlangsamt aber sauber werden die Ausgaben nie...
>
> Jemand einen Tipp was falsch läuft?
>
> Danke im Voraus
Hallo,

"Arduino", das ist wohl vertarntes C, oder?

Versuche es eventuell mit echtem C
http://homepage.hispeed.ch/peterfleury/avr-software.html
und hier LCD via i2c
http://www.computerheld.de/i2clcd/doc/index.html
-> AVR Dragon an ISP und JTAG


Peter

[toc] | [prev] | [next] | [standalone]

#225468

On 04/02/2017 12:15 PM, Peter Thoms wrote:
> "Arduino", das ist wohl vertarntes C, oder?

C++ mit einer Library die das Ansteuern des Atmel vereinfachen soll.

> Versuche es eventuell mit echtem C
> http://homepage.hispeed.ch/peterfleury/avr-software.html

Ich werde mal schauen ob ich da etwas verwenden kann. Danke für den Tipp.

> http://www.computerheld.de/i2clcd/doc/index.html
> -> AVR Dragon an ISP und JTAG

Ich verwende ein paralleles LCD mit T6963C Controller.

Und nein, fertige Libraries helfen mir hier nicht. Ich will die Pixel 
selber steuern. Zeichenfunktionen oder gar einache Textausgabe bringt 
mir nichts.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#225491

Am 02.04.2017 um 12:59 schrieb Manuel Reimer:

> Ich verwende ein paralleles LCD mit T6963C Controller.
>
> Und nein, fertige Libraries helfen mir hier nicht. Ich will die Pixel
> selber steuern. Zeichenfunktionen oder gar einache Textausgabe bringt
> mir nichts.

Stimmt Dein Handshake (STA0/1)? Der Controller kann nur 1 
Byte/Maschinenzyklus verarbeiten.

Laß Dich nicht von den vielen unsinnigen Kommentaren verwirren, der 
Zugriff auf PORTB/D ist schon in Ordnung. Du kannst ja mit LEDs selbst 
kontrollieren, was tatsächlich rausgeht.

DoDi

[toc] | [prev] | [next] | [standalone]

#225493

On 04/02/2017 04:32 PM, Hans-Peter Diettrich wrote:
> Stimmt Dein Handshake (STA0/1)? Der Controller kann nur 1
> Byte/Maschinenzyklus verarbeiten.

Statusbits Lesen vom LCD? Habe ich bisher nicht hinbekommen. Die sind 
bei mir immer murks. Und zwar unabhängig davon ob ich mit "digitalRead" 
oder über's Register gehe. Irgendwas mache ich wohl beim Lesen falsch. 
Komme aber nicht darauf was es sein könnte. Da mein Code dann, mangels 
sauberem Status, immer bis ins Timeout in einer Schleife rennt habe ich 
das mit dem Statusbits aufgegeben.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#225465

"Manuel Reimer" <manuel.nulldevice@nurfuerspam.de> schrieb im Newsbeitrag 
news:obqham$2sr$1@dont-email.me...

> Von der Idee her hätte ich gedacht, dass die eigentlich das gleiche tun 
> sollten.

Nö, du hättest schon schreiben müssen

digitalWrite(PIN_D2, aData & (1<<0));
digitalWrite(PIN_D3, aData & (1<<1));
digitalWrite(PIN_D4, aData & (1<<2));
digitalWrite(PIN_D5, aData & (1<<3));
digitalWrite(PIN_D6, aData & (1<<4));
digitalWrite(PIN_D7, aData & (1<<5));
digitalWrite(PIN_B0, aData & (1<<6));
digitalWrite(PIN_B1, aData & (1<<7));

-- 
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

[toc] | [prev] | [next] | [standalone]

#225467

On 04/02/2017 12:50 PM, MaWin wrote:
> Nö, du hättest schon schreiben müssen
>
> digitalWrite(PIN_D2, aData & (1<<0));
> digitalWrite(PIN_D3, aData & (1<<1));
> digitalWrite(PIN_D4, aData & (1<<2));
> digitalWrite(PIN_D5, aData & (1<<3));
> digitalWrite(PIN_D6, aData & (1<<4));
> digitalWrite(PIN_D7, aData & (1<<5));
> digitalWrite(PIN_B0, aData & (1<<6));
> digitalWrite(PIN_B1, aData & (1<<7));

Die Variante mit "DigitalWrite" ist die, die funktioniert. Und die 
Pin-Bezeichnungen sind eigene Defines:

#define PIN_D0 2
#define PIN_D1 3
#define PIN_D2 4
#define PIN_D3 5
#define PIN_D4 6
#define PIN_D5 7
#define PIN_D6 8
#define PIN_D7 9

Was nicht geht ist das Schreiben auf die Register. Ich bekomme damit 
Zufallsergebnisse auf's LCD. Bei jedem Reset sind die Pixel etwas anders 
verschoben.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#225469

Nachtrag: Auch das hier geht nicht:


// Set one byte to the parallel interface
void ParportWriteData(unsigned char aData) {
     unsigned char maskD = B11111100;
   unsigned char bitsD = aData << 2;
   PORTD = (PORTD & ~maskD) | (bitsD & maskD);
   unsigned char maskB = B00000011;
   unsigned char bitsB = aData >> 6;
   PORTB = (PORTB & ~maskB) | (bitsB & maskB);
   digitalWrite(PIN_D0, aData & (1<<0));
   digitalWrite(PIN_D1, aData & (1<<1));
   digitalWrite(PIN_D2, aData & (1<<2));
   digitalWrite(PIN_D3, aData & (1<<3));
   digitalWrite(PIN_D4, aData & (1<<4));
   digitalWrite(PIN_D5, aData & (1<<5));
   digitalWrite(PIN_D6, aData & (1<<6));
   digitalWrite(PIN_D7, aData & (1<<7));
}

Also erst über die Register und dann zusätzlich über "digitalWrite" 
genau die gleichen Ports setzen (sofern meine Registerzugriffe überhaupt 
passen).

Was auch immer in an den Registern verstelle: "digitalWrite" kann das 
nicht mehr fixen. Nur die "digitalWrite"-Zeilen und das Display 
funktioniert...

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#225470

On 04/02/2017 01:12 PM, Manuel Reimer wrote:
> Was auch immer in an den Registern verstelle: "digitalWrite" kann das
> nicht mehr fixen. Nur die "digitalWrite"-Zeilen und das Display
> funktioniert...

Ich werde den Gedanken nicht los, dass ich vielleicht die Status-Bits 
mit verändere.

Ich habe die Digital-Pins vom LCD auf "PORTD" und "PORTB". Hauptsächlich 
weil der Arduino auf "PORTD" die unteren zwei Pins für den seriellen 
Port reserviert hat. Sonst wäre es eleganter gewesen die 8 Bits alle auf 
PORTD zu fahren.

Die Status-Bits vom LCD liegen auf PORTB und zwar die 4 Bits über den 
zweien die ich für den parallelen Port nutze.

Allerdings kann ich mir nicht erklären wie sowas sein könnte. Ich lese 
doch den aktuellen Wert von "PORTB" und ändere nur die Bits die ich 
maskiere. Oder nicht?

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#225485

Am 02.04.2017 um 13:23 schrieb Manuel Reimer:
> On 04/02/2017 01:12 PM, Manuel Reimer wrote:
>> Was auch immer in an den Registern verstelle: "digitalWrite" kann das
>> nicht mehr fixen. Nur die "digitalWrite"-Zeilen und das Display
>> funktioniert...
>
> Ich werde den Gedanken nicht los, dass ich vielleicht die Status-Bits
> mit verändere.
>
> Ich habe die Digital-Pins vom LCD auf "PORTD" und "PORTB". Hauptsächlich
> weil der Arduino auf "PORTD" die unteren zwei Pins für den seriellen
> Port reserviert hat. Sonst wäre es eleganter gewesen die 8 Bits alle auf
> PORTD zu fahren.
>
> Die Status-Bits vom LCD liegen auf PORTB und zwar die 4 Bits über den
> zweien die ich für den parallelen Port nutze.
>
> Allerdings kann ich mir nicht erklären wie sowas sein könnte. Ich lese
> doch den aktuellen Wert von "PORTB" und ändere nur die Bits die ich
> maskiere. Oder nicht?

Nochmal zum Verständnis:
Du betreibst das Display an einer 8-Bit Datenschnittstelle wobei Du die 
8 Datenbits auf 2 Ports aufgeteilt hast?

Wo liegen die Steuerleitungen?
Hast Du sichergestellt dass die Daten erst übernommen werden wenn alle 
Datenleitungen fertig gesetzte sind?

Gerald

[toc] | [prev] | [next] | [standalone]

#225489

On 04/02/2017 04:06 PM, Gerald Oppen wrote:
> Nochmal zum Verständnis:
> Du betreibst das Display an einer 8-Bit Datenschnittstelle wobei Du die
> 8 Datenbits auf 2 Ports aufgeteilt hast?

Ja. Weil es eben nicht anders geht. Die Arduino-Platinen sind fest so 
verdrahtet...

> Wo liegen die Steuerleitungen?

Aktuell auf "PORTB". Also "oberhalb" von zwei der Datenbits.

> Hast Du sichergestellt dass die Daten erst übernommen werden wenn alle
> Datenleitungen fertig gesetzte sind?

Eigentlich schon. Erst werden die Daten gesetzt und dann über die 
Steuerleitungen "fertig gemeldet".

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#225494

Am 02.04.2017 um 16:27 schrieb Manuel Reimer:
> On 04/02/2017 04:06 PM, Gerald Oppen wrote:
>> Nochmal zum Verständnis:
>> Du betreibst das Display an einer 8-Bit Datenschnittstelle wobei Du die
>> 8 Datenbits auf 2 Ports aufgeteilt hast?
>
> Ja. Weil es eben nicht anders geht. Die Arduino-Platinen sind fest so
> verdrahtet...

Das liegt nicht an den Platinen, die Controller führen nicht alle 
Port-Bits nach außen :-(

Beim Mega (2560) sind mehr Ports komplett rausgeführt, der ATmega169 hat 
neben den Ports auch noch die Logik und Taktgeber für LCD Multiplex 
eingebaut.

DoDi

[toc] | [prev] | [next] | [standalone]

#225526

Am 02.04.2017 um 16:27 schrieb Manuel Reimer:
> On 04/02/2017 04:06 PM, Gerald Oppen wrote:
>> Nochmal zum Verständnis:
>> Du betreibst das Display an einer 8-Bit Datenschnittstelle wobei Du die
>> 8 Datenbits auf 2 Ports aufgeteilt hast?
>
> Ja. Weil es eben nicht anders geht. Die Arduino-Platinen sind fest so
> verdrahtet...
>
>> Wo liegen die Steuerleitungen?
>
> Aktuell auf "PORTB". Also "oberhalb" von zwei der Datenbits.
>
>> Hast Du sichergestellt dass die Daten erst übernommen werden wenn alle
>> Datenleitungen fertig gesetzte sind?
>
> Eigentlich schon. Erst werden die Daten gesetzt und dann über die
> Steuerleitungen "fertig gemeldet".

Dann würde ich da mal in das Datenblatt schauen wie viel Zeit man dem 
Display-Controller bis zur Datenfreigabe lassen muss. Ein Oszi ist da 
sehr hilfreich um das nachzuprüfen. Manchmal hat ein Compiler auch eine 
etwas eigenwillige Vorstellung davon wie er den Code optimiert.

Gerald

[toc] | [prev] | [next] | [standalone]

#225551

Manuel Reimer wrote:
> On 04/02/2017 01:12 PM, Manuel Reimer wrote:
>> Was auch immer in an den Registern verstelle: "digitalWrite" kann das
>> nicht mehr fixen. Nur die "digitalWrite"-Zeilen und das Display
>> funktioniert...
> 
> Ich werde den Gedanken nicht los, dass ich vielleicht die Status-Bits
> mit verändere.

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;
}

[toc] | [prev] | [next] | [standalone]

#225471

Manuel Reimer <manuel.nulldevice@nurfuerspam.de> schrieb:

> Hallo,
> 
> ich möchte ein grafisches LCD mit einem Arduino ansteuern.


> // Set one byte to the parallel interface
> void ParportWriteData(unsigned char aData) {
>    unsigned char maskD = B11111100;
>    unsigned char bitsD = aData << 2;
>    PORTD = (PORTD & ~maskD) | (bitsD & maskD);
>    unsigned char maskB = B00000011;
>    unsigned char bitsB = aData >> 6;
>    PORTB = (PORTB & ~maskB) | (bitsB & maskB);
> }

Bist Du sicher, daß lesen von PORTx durch Ansprechen als
Variable funktioniert?
Und daß (PORTx & ~maskX) nicht auf den Port schreibt?

Kenne Arduino nur flüchtig, dewegen HTH,
Marc

[toc] | [prev] | [next] | [standalone]

#225473

On 04/02/2017 02:22 PM, Marc Santhoff wrote:
> Bist Du sicher, daß lesen von PORTx durch Ansprechen als
> Variable funktioniert?
> Und daß (PORTx & ~maskX) nicht auf den Port schreibt?
>
> Kenne Arduino nur flüchtig, dewegen HTH,

Wie schon erwähnt ist das eigentlich "Standard-C++".

Aus der Arduino-Library:
| out = portOutputRegister(port);
|  if (val == LOW) *out &= ~bit;
|  else *out |= bit;

"&=" schreibt direkt, was auch Sinn macht.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#225474

Manuel Reimer <manuel.nulldevice@nurfuerspam.de> schrieb:

> On 04/02/2017 02:22 PM, Marc Santhoff wrote:
> > Bist Du sicher, daß lesen von PORTx durch Ansprechen als
> > Variable funktioniert?
> > Und daß (PORTx & ~maskX) nicht auf den Port schreibt?
> >
> > Kenne Arduino nur flüchtig, dewegen HTH,
> 
> Wie schon erwähnt ist das eigentlich "Standard-C++".
> 
> Aus der Arduino-Library:
> | out = portOutputRegister(port);
> |  if (val == LOW) *out &= ~bit;
> |  else *out |= bit;
> 
> "&=" schreibt direkt, was auch Sinn macht.

Wenn Du sicher bist, daß in den 0-maskierten Bits nix mehr drin steht,
das noch gebraucht wird...

Marc

[toc] | [prev] | [next] | [standalone]

#225496

Ich habe mal zusätzlich im Arduino-Forum gefragt.

https://forum.arduino.cc/index.php?topic=467534.0

Komme aber wohl erst nächstes Wochenende dazu mich weiter damit zu befassen.

[toc] | [prev] | [next] | [standalone]

#225501

Hallo Manuel,

> ich möchte ein grafisches LCD mit einem Arduino ansteuern.

> // Set one byte to the parallel interface
> void ParportWriteData(unsigned char aData) {
>   unsigned char maskD = B11111100;
>   unsigned char bitsD = aData << 2;
>   PORTD = (PORTD & ~maskD) | (bitsD & maskD);
>   unsigned char maskB = B00000011;
>   unsigned char bitsB = aData >> 6;
>   PORTB = (PORTB & ~maskB) | (bitsB & maskB);

Zuerst dachte ich mir: Warum legst Du die 8 Datenleitungen nicht auf 
einen Port? Dann argwöhnte ich, dass da wieder Arduinos Philosophie der 
Vereinfachung durch Verstecken dahinter stünde... Aber nein...

Die Port-Pin-Zuordnung dieser ATMega328 sind ja tatsächlich so kaputt, 
dass man, sofern man irgendwas am Analogeingang machen will, einen UART 
nutzen will, und deswegen einen externen Quarz anschließen mag, wirklich 
keinen Port am Stück mehr zur Verfügung hat...
Wer hat sich solch eine Pinbelegung ausgedacht?

Wie war das mit dem Burggraben und tunken?

Das Problem dürfte sein, dass Deine Pinzuordnung nicht übereinstimmt. 
Die PortB-Pins liegen ja mittendrin, nicht am Rand.


Marte

[toc] | [prev] | [next] | [standalone]

#225510

On 04/02/2017 05:32 PM, Marte Schwarz wrote:
> Das Problem dürfte sein, dass Deine Pinzuordnung nicht übereinstimmt.
> Die PortB-Pins liegen ja mittendrin, nicht am Rand.

Keine Ahnung wie sie sein müsste. Ich komme nicht drauf. Wird wohl 
darauf hinauslaufen, dass ich irgendwann durch die Arduino-Libraries 
suchen muss um rauszufinden wo genau die dort beschrifteten Pins im 
Register liegen...

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | de.sci.electronics

csiph-web