Forum: Compiler & IDEs 2x 74HC595 + 7-Segment-Display + GCC -> merkwürdiges Verhalten


von Jonas F. (wuschelkuchen)


Lesenswert?

Hallo,
ich bin dabei, vier 7-Segment-Displays über zwei kaskadierte 
Schieberegister HC595 anzusteuern. An dem ersten hängen die Segmente 
a-dp, das zweite steuert die Transistoren (BC548C) für die 4 Anzeigen 
(niedrigste 4 Bit) an und zwei LED-Punkte zwischen den Anzeigen (höchste 
2 Bit). Um das erste nicht zu überlasten, habe ich für die Segmente 
jeweils einen BC558C zur Ansteuerung, dadurch ist alles auf dem 1. SRG 
active low und auf dem 2. SRG alles active high. RCK und SCK sind 
zusammengeschaltet.

Nur leider haut es mit der Ansteuerung nicht ganz hin. Ich habe mal ein 
kleines Testprogramm für einen Tiny2313 geschrieben und poste auch hier, 
weil ich vermute, dass es an der Software liegt.
1
#define F_CPU 8000000UL
2
3
#include <avr/io.h>
4
#include <portbits.h>
5
#include <util/delay.h>
6
7
#define D_SDATA DDRD_0
8
#define D_SSCLK DDRD_1
9
#define P_SDATA PORTD_0
10
#define P_SSCLK PORTD_1
11
12
#define NOP asm volatile("nop")
13
14
void ShiftByte(uint8_t byte);
15
void ClearSRGs();
16
17
int main()
18
{
19
  D_SDATA = 1;
20
  D_SSCLK = 1;
21
  P_SSCLK = 0;
22
  P_SDATA = 0;
23
24
  ClearSRGs();
25
26
  while(1)
27
  {
28
    //ClearSRGs();
29
    ShiftByte(0b11111111);
30
    ShiftByte(0b00000000);
31
    _delay_ms(30);
32
  }
33
34
  while(1)
35
  {
36
    NOP;
37
  }
38
}
39
40
void ShiftByte(uint8_t byte)
41
{
42
  P_SDATA = 0;
43
  for(uint8_t i = 0; i < 8; i++)
44
  {
45
    if(byte & 1)
46
    {
47
      P_SDATA = 1;
48
    }else{
49
      P_SDATA = 0;
50
    }
51
    P_SSCLK = 1;
52
    P_SSCLK = 0;
53
    byte >>= 1;
54
  }
55
}
56
57
void ClearSRGs()
58
{
59
  P_SDATA = 0;
60
  for(uint8_t i = 0; i < 16; i++)
61
  {
62
    
63
    P_SSCLK = 1;
64
    P_SSCLK = 0;
65
  }
66
}

Ich verwende Benedikts portbits.h (hier gleich mal ein kräftiges Danke 
an Benedikt, die Datei erspart einem einiges an Arbeit).

Die zweite while-Schleife ist nur dazu da, falls ich die erste 
auskommentiere...

Nun zum Verhalten: Eigentlich sollte mit dem Code alles leuchten, jedoch 
bleiben das "dp-Segment" (höchstes Bit des 1. SRGs) und die erste 
Anzeige (höchstes Bit des 2. SRGs) dunkel.

Ersetze ich aber
1
ShiftByte(0b11111111);
2
ShiftByte(0b00000000);

durch
1
ShiftByte(0b01111111);
2
ShiftByte(0b10000000);

leuchtet alles wunderbar. Es sieht also so aus, als würden die beiden 
Schieberegister ihr 7. Bit untereinander tauschen? Wie kann das sein? 
Liegt es wirklich an der Software oder kann es nur ein Hardwareproblem 
sein?

Ich hoffe, dass ich nicht im komplett falschen Forum bin...


grüssse
w.

von Karl H. (kbuchegg)


Lesenswert?

Wo steuerst du RCK aktiv an?

von Jonas F. (wuschelkuchen)


Lesenswert?

Nirgends. RCK und SCK sind zusammengeschaltet (steht oben :D), da mir 
sonst später die Pins knapp werden.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> Es sieht also so aus, als würden die beiden
> Schieberegister ihr 7. Bit untereinander tauschen?
Es sieht eher so aus, als ob dein Protokoll um 1 Bit verschoben ist...

von Karl H. (kbuchegg)


Lesenswert?

J. R. schrieb:
> Nirgends. RCK und SCK sind zusammengeschaltet (steht oben :D), da mir
> sonst später die Pins knapp werden.

Ah. Noch mal nachgelesen. Stimmt.
Hmm. Keine gute Idee.
Trenn das mal auf und steuere RCK extra an.

Die Frage ist: wenn beide Pulse gleichzeitig kommen, was macht dann der 
595? Welcher Zustand der Schiebekette wird ins Augangsregister 
übernommen? Der der vorlag, ehe er gleichzeitig stattfindende SCK Puls 
weiterschiebt oder der der danach vorliegt oder überhaupt eine 
Mischform?

Müsste man jetzt im Datenblatt nachlesen, was in so einem Fall passiert 
bzw. ob das überhaupt erlaubt ist.
Normal benutzt man das Ding so:
Mit SCK wird die Schiebekette befüllt. Ist jedes Bit an seinem Platz, 
schaltet ein RCK den Inhalt der Schiebekette auf die Ausgänge durch. Das 
hat dann auch den Vorteil, dass alle Ausgänge gleichzeitig auf einen 
neuen Zustand wechseln und man den Vorgang des Reintaktens in die 
Schiebekette an den Ausgängen nicht sieht.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

>> Es sieht eher so aus, als ob dein Protokoll um 1 Bit verschoben ist...
Und da haben wir auch schon den Grund dafür:
> RCK und SCK sind zusammengeschaltet
Darusch wird erst einen Takt später das eingetaktete Bitmuster in den 
Ausgangsregistern gespeichert   :-o

von Jonas F. (wuschelkuchen)


Lesenswert?

Gut. Ich werds mal auftrennen, mal schaun, obs dann besser wird.

von Jonas F. (wuschelkuchen)


Lesenswert?

Jetzt läuft alles perfekt!
Hätte nicht gedacht, dass es daran liegt.

Danke!

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.