Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Gerald Oppen <Gerald.Oppen@web.de>
Newsgroups: de.sci.electronics
Subject: =?UTF-8?Q?Re:_Arduino:_=22digitalWrite=22_geht._=22PORTD/PORB=22_is?= =?UTF-8?Q?t_unzuverl=c3=a4ssig=3f?=
Date: Sat, 8 Apr 2017 18:07:21 +0200
Lines: 35
Message-ID: <eksg5pFiafaU1@mid.individual.net>
References: <obqham$2sr$1@dont-email.me> <oc974m$gvh$1@dont-email.me> <20170408020929.6714bb7a@puma.das.netz> <oca8og$p5n$1@dont-email.me> <ekrnv9Fdj8pU1@mid.individual.net> <ocaa3p$svk$1@dont-email.me> <ekrpcnFds8oU1@mid.individual.net> <ocalkr$vdb$2@dont-email.me> <eksesvFi3cpU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net 3vHbDuN3rUyGM63O8LdJIwreFqqO43sZT2ZjGGUGK/+7cABiM=
Cancel-Lock: sha1:JHdsoLJcAl8A85tqjS85L6lO6cU=
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
In-Reply-To: <eksesvFi3cpU1@mid.individual.net>
Xref: csiph.com de.sci.electronics: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
---