Problem mit TM1637 mit Atmega32

Wenn du keinen Inverter in der DIO Leitung hat, ist das hier falsch:

1

  if (byte & 0x01)

2

  PORTB &= ~(1 << DIO_PIN); // Set DIO low if the least significant bit of byte is 1

3

  else

4

  PORTB |= (1 << DIO_PIN); // Set DIO high if the least significant bit of byte is 0

denn du sendest das Byte invertiert an TM1637. Ausserdem fragst du Bit 0 ab, das sollte aber Bit 7 sein, also

1

if (byte & 0x80)  

2

3

// und dann 

4

 byte >>= 1;

hab es schon versucht aber leider funktioniert noch nicht.

Invertierung wurde bereits angesprochen. Es fehlt der 9. Takt für das ACK. Zu Beginn muss wohl auch die Helligkeit gesetzt werden.

Und ganz zu Beginn würde ich die Leitungen auf high setzen:

1

int main(void) {

2

PORTB |= (1 << CLK_PIN) | (1 << DIO_PIN); // Set CLK and DIO pins high

3

DDRB |= (1 << CLK_PIN) | (1 << DIO_PIN); // Set CLK and DIO pins as output

Fadel schrieb:

hab es schon versucht aber leider funktioniert noch nicht.

Ja nee, so kommen wir nicht weiter. Was funktioniert nicht und hast du mal die Signale angeguckt? Mach das mal mit viel delay und mit LEDs an den Leitungen, wenn du kein Oszi oder Logikanalyzer hast. So ein Logikanalyzer gibts übrigens günstig.

Also hiermit ist zumindest irgendwas-irgendwie zu sehen.

PS: soll heißen: "0123", manchmal etwas flackernd mit undefinierter Helligkeit.

Matthias S. schrieb:

// und dann byte >>= 1;

Ist ja Unsinn. Du musst in die andere Richtung schieben. MSB zuerst und dann die nachfolgenden. Ausserdem hast du die Bitmaske immer noch falsch.

PPS: in der Datenleitung habe ich 270 Ohm - der TM1637 müsste sonst beim ACK den maximalen Strom des ATmega32 verkraften (keine Ahnung, ob er das kann), DDRB.1 wird beim 9. Takt ja nicht umgeschaltet.

Warum benutzt Du nicht eine fertige Bibliothek?

https://github.com/lpodkalicki/attiny-tm1637-library

Die ist zwar für einen Tiny13 gemacht aber leicht anpassbar an Deinen Controller oder erweiterbar.

TM1637, 4-stellige LED 7-Segmentanzeige mit AVR-GCC

Auch wenn das nicht explizit für einen ATmega32 (ich habe nie einen solchigen gehabt) gemacht war, sollte das dennoch sofort darauf funktionieren.

Gruß Ralph

Ralph S. schrieb:

sollte das dennoch sofort darauf funktionieren.

Woher diese Sicherheit? Es ist doch gar nichts über den Aufbau bekannt -> Spannungsversorgung, Verkabelung, Leitungsführung, Komponentenauswahl, Hardware, Programmer etc...

S. L. schrieb:

Also hiermit ist zumindest irgendwas-irgendwie zu sehen.

Soll das eine Hilfestellung werden oder hast du selbst auch ein Problem mit der gleichen Kombi?

Thorsten S. schrieb:

Es ist doch gar nichts über den Aufbau bekannt

Es ist noch nicht mal bekannt, was denn überhaupt das Problem ist.

Das ist wie wenn wer zum Arzt rennt und sagt: "Immer wenn ich Kaffee trinke, spüre ich ein schmerzhaftes Stechen im Auge. Was kann ich dagegen tun?"

Und nach langwierigen Untersuchungen bis hin zum Neurologen kommt heraus, dass er einfach den Kaffelöffel aus der Tasse nehmen muss, dessen Griff ins Auge geht.

Lothar M. schrieb:

dass er einfach den Kaffelöffel aus der Tasse nehmen muss, dessen Griff ins Auge geht.

Alt... aber gut ! :-)

Irgendwie war ich wohl zu dämlich, den Link korrekt zu kopieren:

Beitrag "TM1637, 4-stellige LED 7-Segmentanzeige mit AVR-GCC"

Thorsten S. schrieb:

Woher diese Sicherheit? Es ist doch gar nichts über den Aufbau bekannt -> Spannungsversorgung, Verkabelung, Leitungsführung, Komponentenauswahl, Hardware, Programmer etc...

Okay, sooooooo sicher bin ich mir dann nicht! Andererseits hat er Clock an PB0 und Data an PB1 angeschlossen und nach seinen Aussagen sieht er ab und an etwas, aber flackernd (was wohl auch daran liegen kann, dass er in einer Endlosschleife den TM1637 permanent befeuert, was er nicht tun muß. Wenn dieser einmal seine Daten hat, wird er das solange anzeigen, bis etwas geändert wird).

Von daher sollte er in der Lage sein vom verlinkten Thread die Dataleitung von PB2 auf PB0 zu ändern!

Wie auch immer ... gehabts euch wohl und schlaft gut !

Thorsten S. fragte:

Soll das eine Hilfestellung werden oder hast du selbst auch ein Problem mit der gleichen Kombi?

Ersteres, denn nein, bei mir läuft diese Kombination; allerdings in Assembler, was ich natürlich keinem, schon gar nicht /Fadel/, zumuten kann. Folglich habe ich sein C-Programm soweit hingebogen, dass er etwas halbwegs Vernünftiges auf seinem TM1637 sehen bzw. ein eventuelles Hardwareproblem klären kann; und, vergleichend, Fehler in seinem ursprünglichen Programm erkennt. Da er sich aber nicht mehr meldet, scheint jetzt alles in Ordnung zu sein.