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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#225515

Hi Manuel,

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

nimm https://www.arduino.cc/en/Hacking/PinMapping da stehts recht 
übersichtlich.
PB6 und PB7 liegen zwischen PD4 und PD5. Du legst sie aber an den Rand.
Marte

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

#225522

Am 02.04.2017 um 18:31 schrieb Manuel Reimer:
> 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...

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

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

#225548

Am 02.04.2017 um 18:31 schrieb Manuel Reimer:
> 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...


Vielleicht wäre das genau der Moment, sich einen AVR Dragon zu zulegen 
und Arduino den Rücken zu kehren?

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

#225517

Marte Schwarz wrote:
> 
> [...]
> 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?

Meistens sind das historische Altlasten. Der Chip soll zu irgendwas
Altem pinkompatibel bleiben.
Das geht bei z.B. dem ATmega8515 so weit, dass das "Original" gar
kein AVR war, sondern ein 8051.

Da mag heute manches verkorkst aussehen, dafür passen einige der
modernen Teile noch auf jahrzehntealte Layouts. Es war immer die
Atmel-Stategie die AVRs ggf. schnell abzukündigen, dafür aber
einen kompatiblen Nachfolger zu bieten. Die Microchip-Strategie war
dagegen PICs weiterzubauen, so dass man sie teils nach Jahrzehnten
noch unverändert (nicht geshrinkt) kaufen konnte bzw. sie einem bei
Stückzahl nochmal aufgelegt wurden. Es wird interessant, wie sie da
in Zukunft verfahren werden.

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

#225528

Am 02.04.2017 um 17:32 schrieb Marte Schwarz:
> 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?
Volle 8Bit benötigt man ja vergleichsweise selten als dass man auf einem 
"Wenigpinner" unbedingt die Sonderfunktionen danach ausrichten müßte. 
Für solche Fälle hilft dann ein IO-Portexpander oder man greift auf eine 
größere Bauform zurück.

Gerald

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

#225516

On 04/02/2017 11:50 AM, Manuel Reimer wrote:
>
> Im Wesentlichen bekomme ich auch das auf's LCD was ich erwarten würde.
> Allerdings verschoben.

Erinnert mich an ein Problem welches ich vor Jahren mit einem solchen 
graphischen Display hatte. Da kamen die Daten auch nicht da an wo sie 
laut Datenblatt ankommen sollten. Also habe ich einfach ausprobiert 
welchen Offset ich brauche damit es passt und den genommen. Ab da lief 
alles.

  Gerrit

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

#225877

On 04/02/2017 11:50 AM, Manuel Reimer wrote:
> // Set one byte to the parallel interface
> void ParportWriteData(unsigned char aData) {
>    unsigned char maskD = B11111100;
>    unsigned char bitsD = aData << 2;
    PORTD &= B10000011;
>    PORTD = (PORTD & ~maskD) | (bitsD & maskD);
>    unsigned char maskB = B00000011;
>    unsigned char bitsB = aData >> 6;
>    PORTB = (PORTB & ~maskB) | (bitsB & maskB);
> }

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 
alles wie gewünscht. Der Unterschied ist mir aber nicht klar.

Gruß

Manuel

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

#225878

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

> On 04/02/2017 11:50 AM, Manuel Reimer wrote:
> > // Set one byte to the parallel interface
> > void ParportWriteData(unsigned char aData) {
> >    unsigned char maskD = B11111100;
> >    unsigned char bitsD = aData << 2;
>     PORTD &= B10000011;
> >    PORTD = (PORTD & ~maskD) | (bitsD & maskD);

Vielleicht möchtest Du hier doch zweimal "&&" verwenden statt "&".

> >    unsigned char maskB = B00000011;
> >    unsigned char bitsB = aData >> 6;
> >    PORTB = (PORTB & ~maskB) | (bitsB & maskB);

Da auch.

Marc

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

#225887

Marc Santhoff schrieb:

> Manuel Reimer <manuel.nulldevice@nurfuerspam.de> schrieb
>> >    PORTD = (PORTD & ~maskD) | (bitsD & maskD);
> 
> Vielleicht möchtest Du hier doch zweimal "&&" verwenden statt "&".
> 
>> >    unsigned char maskB = B00000011;
>> >    unsigned char bitsB = aData >> 6;
>> >    PORTB = (PORTB & ~maskB) | (bitsB & maskB);
> 
> Da auch.

Bestimmt nicht! Logisches Und ("&&") wäre an der Stelle komplett falsch,
bitweises Und ("&") wie in Manuels Code ist natürlich richtig.

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

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

#225888

On 04/08/2017 02:09 AM, Marc Santhoff wrote:
>> On 04/02/2017 11:50 AM, Manuel Reimer wrote:
>>> // Set one byte to the parallel interface
>>> void ParportWriteData(unsigned char aData) {
>>>     unsigned char maskD = B11111100;
>>>     unsigned char bitsD = aData << 2;
>>      PORTD &= B10000011;
>>>     PORTD = (PORTD & ~maskD) | (bitsD & maskD);
> 
> Vielleicht möchtest Du hier doch zweimal "&&" verwenden statt "&".

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;

Bevor ich also meine eigentlichen Änderungen mache wird Bit 5 immer 
"LOW" gezogen.

Das kann ich sogar in Arduino-Slang übersetzen:

digitalWrite(5, LOW);

Geht auch damit noch.

Warum das aber so ist, erschließt sich mir leider überhaupt nicht. Warum 
kann ich meine gewünscht Bitfolge nicht direkt rausschreiben sondern 
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 
der zufällige Murks nur langsamer gezeichnet...

Gruß

Manuel

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

#225891

Manuel Reimer schrieb:

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

Laut Datenblatt darfst Du CD ja nicht gleichzeitig mit /CE und /WR
umschalten. Da muss eine Hold-Zeit für CD sein. Ist das in Deinem Code
gewährleistet? Auch wenn mir nicht ganz klar ist, wie das mit Deinem
derzeitigen Problem zusammenhänge sollte.

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

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

#225894

On 04/08/2017 11:14 AM, Christian Zietz wrote:
> Laut Datenblatt darfst Du CD ja nicht gleichzeitig mit /CE und /WR
> umschalten. Da muss eine Hold-Zeit für CD sein. Ist das in Deinem Code
> gewährleistet? Auch wenn mir nicht ganz klar ist, wie das mit Deinem
> derzeitigen Problem zusammenhänge sollte.

Hatte ich nicht. Meine neue "SendData" ("SendCommand" analog geändert):

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
}

Ändert aber nichts. Ausgabe immer noch kaputt wenn ich "PORTD" nicht 
zuerst mit B11011111 "verunde".

Gruß

Manuel

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

#225896

Manuel Reimer schrieb:

> Hatte ich nicht. Meine neue "SendData" ("SendCommand" analog geändert):
> 
> 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
> }
> 
> Ändert aber nichts. 

Wenn SendData vorher auch schon so aussah, bloß ohne "nop", dann war die
Hold-Zeit gewährleistet. Der ganze Arduino-Overhead von digitalPinWrite
dauert mit Sicherheit länger als die Holdzeit für CD ist.

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

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

#225902

On 04/08/2017 11:38 AM, Christian Zietz wrote:
> Wenn SendData vorher auch schon so aussah, bloß ohne "nop", dann war die
> Hold-Zeit gewährleistet. Der ganze Arduino-Overhead von digitalPinWrite
> dauert mit Sicherheit länger als die Holdzeit für CD ist.

Wahrscheinlich.

Mir scheint es so als wäre das Problem besonders in den Regionen 
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 
"Verschieben" aller Zeilen am LCD erklären würde.

Gruß

Manuel

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

#225905

Am 08.04.2017 um 14:41 schrieb Manuel Reimer:
> On 04/08/2017 11:38 AM, Christian Zietz wrote:
>> Wenn SendData vorher auch schon so aussah, bloß ohne "nop", dann war die
>> Hold-Zeit gewährleistet. Der ganze Arduino-Overhead von digitalPinWrite
>> dauert mit Sicherheit länger als die Holdzeit für CD ist.
>
> Wahrscheinlich.
>
> Mir scheint es so als wäre das Problem besonders in den Regionen
> 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
> "Verschieben" aller Zeilen am LCD erklären würde.

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.
Hängt da noch was anderes an den Busleitungen, eventuell eine 
Schutzbeschaltung?

Gerald

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

#225906

Am 08.04.2017 um 17:45 schrieb Gerald Oppen:
> Am 08.04.2017 um 14:41 schrieb Manuel Reimer:
>> On 04/08/2017 11:38 AM, Christian Zietz wrote:
>>> Wenn SendData vorher auch schon so aussah, bloß ohne "nop", dann war die
>>> Hold-Zeit gewährleistet. Der ganze Arduino-Overhead von digitalPinWrite
>>> dauert mit Sicherheit länger als die Holdzeit für CD ist.
>>
>> Wahrscheinlich.
>>
>> Mir scheint es so als wäre das Problem besonders in den Regionen
>> 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
>> "Verschieben" aller Zeilen am LCD erklären würde.
>
> 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.
> Hängt da noch was anderes an den Busleitungen, eventuell eine
> Schutzbeschaltung?
>
> Gerald

P.S.:
Und das hier beachtet:
---
Ensure  that  data  is  not  being  transmitted  too  fast  to  the 
T6963C.  Always  pole  the  BUSY
flags STA0 and STA1 before sending instructions (section 9.2). If MPU is 
not set up to read
the  BUSY  flag  before  writing  instructions  allow  an  adequate 
delay  between  instructions
---

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

#225935

On 04/08/2017 06:07 PM, Gerald Oppen wrote:
>> Du solltest Dir mal die Signale mit einem OSZI anschauen, eventuell sind
>> die Signalflanken zu flach.

Habe ich nicht zur Verfügung.

>> Das hatte ich gerade bei der
>> Senderichtungsumschaltung an einer RS485.
>> Hängt da noch was anderes an den Busleitungen, eventuell eine
>> Schutzbeschaltung?
>>
>> Gerald
> 
> P.S.:
> Und das hier beachtet:
> ---
> Ensure  that  data  is  not  being  transmitted  too  fast  to  the 
> T6963C.  Always  pole  the  BUSY
> flags STA0 and STA1 before sending instructions (section 9.2). If MPU is 
> not set up to read
> the  BUSY  flag  before  writing  instructions  allow  an  adequate 
> delay  between  instructions
> ---

Ich habe schon an allmöglichen Stellen "nops" verbaut gehabt und 
gebremst bis man jede Zeile einzeln sieht, die aufgebaut wird.

Das einzige, das sich ändert, ist, dass der "Murks" dann langsamer auf 
dem LCD landet.

Gruß

Manuel

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

#225939

Am 09.04.2017 um 11:59 schrieb Manuel Reimer:
> On 04/08/2017 06:07 PM, Gerald Oppen wrote:

>> Und das hier beachtet:
>> ---
>> Ensure  that  data  is  not  being  transmitted  too  fast  to  the
>> T6963C.  Always  pole  the  BUSY
>> flags STA0 and STA1 before sending instructions (section 9.2). If MPU
>> is not set up to read
>> the  BUSY  flag  before  writing  instructions  allow  an  adequate
>> delay  between  instructions
>> ---
>
> Ich habe schon an allmöglichen Stellen "nops" verbaut gehabt und
> gebremst bis man jede Zeile einzeln sieht, die aufgebaut wird.
>
> Das einzige, das sich ändert, ist, dass der "Murks" dann langsamer auf
> dem LCD landet.

Wieviele Nops hattest Du den verbaut? Mit 2-3 Nops ist es nicht getan 
wenn der uC mit 8 oder gar 16Mhz läuft und das Display 
Verarbeitungszeiten von einigen Millisekunden hat.
Um das herauszufinden solltest Du das Busy-flag abfragen und in eine 
Varibale hochzählen lassen, wie lange das dauert bis es "habe fertig" 
meldet...

Gerald

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

#225943

On 04/09/2017 01:11 PM, Gerald Oppen wrote:
> Wieviele Nops hattest Du den verbaut? Mit 2-3 Nops ist es nicht getan 
> wenn der uC mit 8 oder gar 16Mhz läuft und das Display 
> Verarbeitungszeiten von einigen Millisekunden hat.
> Um das herauszufinden solltest Du das Busy-flag abfragen und in eine 
> Varibale hochzählen lassen, wie lange das dauert bis es "habe fertig" 
> meldet...

Das hatte ich, wie erwähnt, schon versucht. Ich bekomme keine Daten vom 
LCD. Meine Funktion zum Lesen war:


// Blocks until LCD reports DSP to be ready
void WaitDSPReady(bool aAutoWrite = false) {
   ParportSetDirection(INPUT);
   for (int i = 0; i < 3000; i++) {
     digitalWrite(PIN_CD, HIGH);
     digitalWrite(PIN_RD, LOW);
     digitalWrite(PIN_WR, HIGH);
     digitalWrite(PIN_CE, LOW);

     // In "Non-Auto-Mode" check STA0 and STA1
     bool last = false;
     if (!aAutoWrite && digitalRead(PIN_D0) && digitalRead(PIN_D1))
       last = true;
     // In "Auto-Mode" check STA3
     if (aAutoWrite && digitalRead(PIN_D3))
       last = true;
     digitalWrite(PIN_CE, HIGH);
     digitalWrite(PIN_RD, HIGH);
     if (last)
       break;
   }
   ParportSetDirection(OUTPUT);
}


Die Schleife läuft *immer* bis zu ihrem Maximum. Es findet kein 
"Abbruch" durch Status-Bits statt.

Gruß

Manuel

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

#225944

On 04/09/2017 02:06 PM, Manuel Reimer wrote:
> On 04/09/2017 01:11 PM, Gerald Oppen wrote:
>> Wieviele Nops hattest Du den verbaut? Mit 2-3 Nops ist es nicht getan
>> wenn der uC mit 8 oder gar 16Mhz läuft und das Display
>> Verarbeitungszeiten von einigen Millisekunden hat.
>> Um das herauszufinden solltest Du das Busy-flag abfragen und in eine
>> Varibale hochzählen lassen, wie lange das dauert bis es "habe fertig"
>> meldet...
>
> Das hatte ich, wie erwähnt, schon versucht. Ich bekomme keine Daten vom
> LCD.

Dann stimmt was mit deiner Schaltung nicht, ich hab bisher bei diversen 
LCDs immer die Statusbits auslesen können. Das beinhaltet eines bei dem 
ich aus dem Code (68000) schliesse, daß es zumindest einen SEHR 
ähnlichen Controller zu deinem LCD verwendet.

Wo in deinem Code schaltest du eigentlich die Adressleitung für das LCD 
um? Das Statusregister ist nicht das Datenregister ausgelesen sondern 
eins weiter. Oder ist das dein 'digitalWrite(PIN_CD, HIGH);'?

Hier ist mein 68000-Code der problemlos funktionierte:



check:                                  ; Verwendete Register:
                                         ; d2 : Statusregister LCD

                 move.b  adr_lcd+1, d2   ; Statusregister lesen */
                 andi.b  #$03, d2        ; Bit 0 und 1 maskieren */
                 cmpi.b  #$03, d2
                 bne.s   check           ; Wenn nicht BEIDE Bits gesetzt
                 rts


check2:         btst    #$03, adr_lcd+1
                 beq     check2          ; wiederholen solange Bit 3 = 0
                 rts

Ich hatte das LCD allerdings im Adressraum eingeblendet, ging schneller 
als via I/O-Baustein. :)

  Gerrit

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web