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?

Started byManuel Reimer <manuel.nulldevice@nurfuerspam.de>
First post2017-04-02 11:50 +0200
Last post2017-04-08 18:45 +0200
Articles 10 on this page of 50 — 12 participants

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

#225946

FromChristian Zietz <newsgroup.1001@chz.xyz>
Date2017-04-09 14:49 +0200
Message-ID<ekuov2F19pdU1@mid.individual.net>
In reply to#225943
Manuel Reimer schrieb:

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

Dann musst Du das zum Laufen bekommen. Wie Du im Datenblatt nachlesen
kannst, funktioniert der Controller nicht korrekt, wenn Du nicht an den
vorgeschriebenen Stellen auch Status-Read machst: "When using the MSB=0
command, a Status Read must be performed. If a status check is not
carried out, the T6963C cannot operate normally, even after a delay
time. [...] If a status check is not carried out [...] before the next
command is sent, there is the possibility that the command or data will
not be received."
MSB=0 commands sind z.B. "Register Setting" oder "Set Control Word".

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

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

#225961

FromManuel Reimer <manuel.nulldevice@nurfuerspam.de>
Date2017-04-09 16:46 +0200
Message-ID<ocdhas$6mn$1@dont-email.me>
In reply to#225946
On 04/09/2017 02:49 PM, Christian Zietz wrote:
> Dann musst Du das zum Laufen bekommen. Wie Du im Datenblatt nachlesen
> kannst, funktioniert der Controller nicht korrekt, wenn Du nicht an den
> vorgeschriebenen Stellen auch Status-Read machst: "When using the MSB=0
> command, a Status Read must be performed. If a status check is not
> carried out, the T6963C cannot operate normally, even after a delay
> time. [...] If a status check is not carried out [...] before the next
> command is sent, there is the possibility that the command or data will
> not be received."
> MSB=0 commands sind z.B. "Register Setting" oder "Set Control Word".

Komischerweise funktioniert der Controller aber ohne Probleme mit den 
Arduino-Funktionen alleine.

Ich habe jetzt nochmal versucht und mit den mir zur Verfügung stehenden 
Mitteln komme ich nicht drauf warum ich die Status-Infos nicht bekomme. 
Wenn ich versuche das zum Laufen zu bekommen werden die Ausgaben nur 
noch konfuser. Wenn ich die gesetzten Bits auf dem seriellen Port 
rausgebe, dann bekomme ich für eine gewisse Zeit scheinbar Infos vom LCD 
zurück und ab einem gewissen Punkt nurnoch Nullen.

Ich glaube ich gebe mich mit der geringen Geschwindigkeit erstmal 
zufrieden. Das ganze wird eh Open-Source und vielleicht hat jemand die 
Mittel, die Zeit und die Lust das mit den Registern doch noch zum Laufen 
zu bringen. Mir fehlt es aktuell vor allem an der nötigen Zeit dafür. 
Ganz davon abgesehen, dass ich Mittel, wie z.B. einen Logik-Analyser 
nicht habe.

Gruß

Manuel

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

#225889

FromChristian Zietz <newsgroup.1001@chz.xyz>
Date2017-04-08 11:03 +0200
Message-ID<ekrna3Fdf5sU1@mid.individual.net>
In reply to#225877
Manuel Reimer 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);
>>    unsigned char maskB = B00000011;
>>    unsigned char bitsB = aData >> 6;
>>    PORTB = (PORTB & ~maskB) | (bitsB & maskB);
>> }

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

Mir ist nicht ganz klar, wie Du auf diese Bitfolge gekommen bist. Warum
ausgerechnet B10000011? Abgesehen davon ist sowas immer ein Grund, sich
den generierten Assembler-Code anzugucken. Poste ihn doch mal für beide
Fälle, ohne und mit "Fix".

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

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

#225892

FromManuel Reimer <manuel.nulldevice@nurfuerspam.de>
Date2017-04-08 11:18 +0200
Message-ID<oca9mn$rda$1@dont-email.me>
In reply to#225889
On 04/08/2017 11:03 AM, Christian Zietz wrote:
> Mir ist nicht ganz klar, wie Du auf diese Bitfolge gekommen bist.

Ausprobieren. Genauso wie ich nun weiß, dass auch ein

PORTD &= B11011111

reicht. Damit wird nur ein einziges Bit "low" gezogen. Auch damit 
funktioniert plötzlich alles. Nur den Sinn dahinter finde ich nicht 
wirklich.

> Warum
> ausgerechnet B10000011? Abgesehen davon ist sowas immer ein Grund, sich
> den generierten Assembler-Code anzugucken. Poste ihn doch mal für beide
> Fälle, ohne und mit "Fix".

Ich kann kein Assembler lesen und weiß ehrlich gesagt auch nicht wie ich 
da rankomme... Was muss ich tun um diese Funktion in Assembler zu wandeln?

Gruß

Manuel

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

#225893

FromChristian Zietz <newsgroup.1001@chz.xyz>
Date2017-04-08 11:23 +0200
Message-ID<ekroglFdmf4U1@mid.individual.net>
In reply to#225892
Manuel Reimer schrieb:

> Ich kann kein Assembler lesen und weiß ehrlich gesagt auch nicht wie ich 
> da rankomme... Was muss ich tun um diese Funktion in Assembler zu wandeln?

Du bittest Deinen Compiler darum. Für gcc:
<https://www.systutorials.com/240/generate-a-mixed-source-and-assembly-listing-using-gcc/>
Du kannst auch ein mit Debugginginformationen ("gcc -g") compiliertes
Objekt-File (.o) mit "objdump -S" wieder ausgeben lassen:
<http://stackoverflow.com/questions/19189897/using-gcc-to-output-commented-annotated-intermediate-files>

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
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

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

#225940

FromManuel Reimer <manuel.nulldevice@nurfuerspam.de>
Date2017-04-09 13:27 +0200
Message-ID<ocd5kg$1s0$1@dont-email.me>
In reply to#225893
On 04/08/2017 11:23 AM, Christian Zietz wrote:
> Du bittest Deinen Compiler darum. Für gcc:
> <https://www.systutorials.com/240/generate-a-mixed-source-and-assembly-listing-using-gcc/>

Fehlerhafte Funktion (ohne Hack):
https://pastebin.com/6Keu75yQ

Und die mit Hack, die funktioniert:
https://pastebin.com/CXDLe9gN

Keine Ahnung ob man da überhaupt etwas mit anfangen kann.

Gruß

Manuel

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

#225942

FromChristian Zietz <newsgroup.1001@chz.xyz>
Date2017-04-09 13:51 +0200
Message-ID<ekulitFl3cU1@mid.individual.net>
In reply to#225940
Manuel Reimer schrieb:

> Fehlerhafte Funktion (ohne Hack):
> https://pastebin.com/6Keu75yQ
> 
> Und die mit Hack, die funktioniert:
> https://pastebin.com/CXDLe9gN
> 
> Keine Ahnung ob man da überhaupt etwas mit anfangen kann.

Da ist zwar allerhand komisches Zeug drin, aber nicht der
Assembler-Quelltext Deiner Funktion. Aber wie gesagt, mittlerweile
glaube ich auch eher an ein Ansteuerproblem des LCD.

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

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

#225898

FromHans-Peter Diettrich <DrDiettrich1@aol.com>
Date2017-04-08 12:47 +0200
Message-ID<ekrucvFer6gU1@mid.individual.net>
In reply to#225877
Am 08.04.2017 um 01:28 schrieb Manuel Reimer:
> 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.

Klar ist da wirklich nichts, daher vermute ich irgendwelche 
Seiteneffekte mit den alternativen Portfunktionen. Dein Programm 
verwendet ja mindestens Serial, und das hängt an den unteren beiden Bits 
von Port D.

Es wäre vielleicht hilfreich, die tatsächlichen Stände von PORTD 
(und/oder PIND) nach jedem Schritt in ein Array zu schreiben, und das 
hinterher anzuschauen. Wenn darin Bits anders geändert werden als im 
Code vorgegeben, dann spuckt irgendwas (Interrupt-Handler, PWM...) 
dazwischen.

Um Interrupt Einflüsse auszuschließen, könntest Du auch testhalber die 
Interrupts während Deiner Datenübergabe abschalten. Wenn das dann läuft, 
ist der Übeltäter schon mal eingegrenzt.

Und die Masken sollten als "const" deklariert werden.

DoDi

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

#225901

FromManuel Reimer <manuel.nulldevice@nurfuerspam.de>
Date2017-04-08 14:38 +0200
Message-ID<ocalf8$vdb$1@dont-email.me>
In reply to#225898
On 04/08/2017 12:47 PM, Hans-Peter Diettrich wrote:
> Um Interrupt Einflüsse auszuschließen, könntest Du auch testhalber die 
> Interrupts während Deiner Datenübergabe abschalten. Wenn das dann läuft, 
> ist der Übeltäter schon mal eingegrenzt.

Wie geht das?

> Und die Masken sollten als "const" deklariert werden.

OK. Macht Sinn. Danke für den Tipp.

Gruß

Manuel

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

#225908

FromHans-Peter Diettrich <DrDiettrich1@aol.com>
Date2017-04-08 18:45 +0200
Message-ID<eksij1Firb4U1@mid.individual.net>
In reply to#225901
Am 08.04.2017 um 14:38 schrieb Manuel Reimer:
> On 04/08/2017 12:47 PM, Hans-Peter Diettrich wrote:
>> Um Interrupt Einflüsse auszuschließen, könntest Du auch testhalber die
>> Interrupts während Deiner Datenübergabe abschalten. Wenn das dann
>> läuft, ist der Übeltäter schon mal eingegrenzt.
>
> Wie geht das?

Mit noInterrupts(), anschließend wieder interrupts().

DoDi

[toc] | [prev] | [standalone]

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

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

csiph-web