uint32_t avr gcc Problem

- Wie schaut denn send_32_bits() aus?

- sind alle 595 korrekt verkettet?
- bekommen alle einen Clock und einen Strobe?
- alle Reset-Pins inaktiv?

Alexander schrieb:
> Hey,
> zur Zeit spiele ich mit 4x74HC595 an einem Atmega 168 rum. Soweit so
> gut, die Pins 1 bis 16 leuchten nacheinander auf, so wie ich mir das
> vorstelle. Doch 16 leuchtet dann alleine genauso lange wie der gesamte
> Durchlauf, 17 bis 32 leuchten nie auf.

Alexander schrieb:
> Wie gesagt die Ausgänge 17-32 leuchten nacheinander auf (das sind die
> letzten beiden 74HC595 die in der Reihe hängen), bei den vorderen beiden
> passiert nichts. Q0 vom 3ten 74hc595 (also Anschluss 17 oder Bit 16 von
> old_value) leuchtet nach dem Durchlauf von 32 bis 17 noch einmal genauso
> lang, wie der Durchlauf gedauert hat.

Du willst hier aber niemand verarschen ?

Solang du nicht ein anständiges (authentisches) Schaltbild und
eine Routine send_32_bits() lieferst hörst du von mir nichts mehr.

Ausser vielleicht dass ein Latch- und ein Clock-Impuls nicht
"durchgeschleift" werden können, die 595 haben keine Ausgänge dafür.
Wäre auch voll der Käse da sonst wild Laufzeiten dazukommen.

Alexander schrieb:
> if (old_data & (1 << i))

Hier ist dein Problem. Per Standard rechnet der avg-gcc nur mit 16 Bit!. 
(1<<16) ist null. Setze hier doch einmal 1UL ein.

Vermutlich macht in der Zeile

if (old_data & (1 << i))

der Shift einen Cast auf einen signed int16
sodass das Ergebnis nur für die ersten 16 Bit true sein kann.

Vergleiche old_data mit einer uint32_t bitmask dann sollte
es funktionieren.

also

(uint32_t)bitmask = (1 << i);
if (old_data & bitmask ) .....


(war jemand schneller als ich)

chris schrieb:
> auch das hilft nicht.

Ich habe mich ungenau ausgedrückt. Natürlich muss man die
Variable als uint32 definieren.

Das Aufrufen von reset_register() ist übrigens unnötig.

Eberhard F. schrieb:
> chris schrieb:
>> auch das hilft nicht.
>
> Ich habe mich ungenau ausgedrückt. Natürlich muss man die
> Variable als uint32 definieren.
>
> Das Aufrufen von reset_register() ist übrigens unnötig.

unnötig würde ich nicht sagen.
Eher: Die Funktion ist falsch benannt.
Der RCLK Pin eines 595 hat nichts mit einem Reset zu tun.

Im übrigen würde ich nach dem Muster 'Teile zund Herrsche' vorgehen.
Eine Funktion, die nur 8 Bit rausschiftet ist trivial. Sowohl für den C 
Programmierer als auch für den AVR. 8 Bit kann er wunderbar durch die 
Gegend shiften, ohne dass er Stress kriegt.
Diese Funktion 4 mal mit je einem anderen Byte aus dem uint32_t 
aufzurufen ist ebenfalls trivial.

1

void clock_8_bits( uint8_t value )

2

{

3

  for (uint8_t i = 0; i < 8; i++) {

4

    if (value & 0x01) {          // immer das LSB prüfen

5

      PORTB |= ( 1 << SER_PIN);

6

    } else {

7

      PORTB &= ~( 1 << SER_PIN);

8

    }

9

    value >>= 1;

10

    generate_clock();

11

  }

12

}

13

14

void send_32_bits( uint32_t value )

15

{

16

  clock_8_bits(   value         & 0xFF );

17

  clock_8_bits( ( value >>  8 ) & 0xFF );

18

  clock_8_bits( ( value >> 16 ) & 0xFF );

19

  clock_8_bits( ( value >> 24 ) & 0xFF );

20

21

  reset_register();

22

}

Karl Heinz schrieb:
> unnötig würde ich nicht sagen.
> Eher: Die Funktion ist falsch benannt.
> Der RCLK Pin eines 595 hat nichts mit einem Reset zu tun.

In der Tat ... ich nahm in der Eile an er führt nach jedem
32-Bit Write einen Reset aus, aber das ist ja der Latch-Puls,
der auf jeden Fall kommen muss .....