Forum: Compiler & IDEs Funksteckdosen HX2262 mit Atmega32 ansteuern


von Tobi S. (alanblack)


Angehängte Dateien:

Lesenswert?

Hallo Zusammen,

Da ich neu hier bin, weiß nicht ob das hier das richtige Forum für mein 
Problem/meiner Frage ist. Wenn nein bitte ich um Verzeihung.

Ich habe versucht folgende Anleitung nachzubauen.
http://www.tnotes.de/FunkSteckdosen

Dabei habe ich wie beschrieben die 3 Litzen an den Kontakten angelötet. 
(siehe Foto) Die Datenlitze ist an einem 1K Widerstand verbunden. Am 
Atmega32 ist diese direkt am PORTD (Pin 6) -> LED Pollin Board 
verbunden.

Als Entwicklungsumgebung verwende ich das Pollin Evaluierungsboard mit 
einem Atmega32

Leider funktioniert dies nicht. Die Steckdose hat zwar die richtige 
Adresse, wird aber nicht vom Atmega geschaltet.

Das Testprogramm ist mit WinAvr in C geschrieben.
Mein Problem ist dass ich nicht weiß, ob es ein Hardware (sprich am FB 
Modul) oder an der Software liegt. Vielleicht kann mir jemand dabei 
helfen um das Ding in Gang zu bekommen. :-)


Hier ein Auszug vom Programm welches in einer for-Schleife mehrmals 
ausgeführt wird:
1
  //ff000f0fff0fs
2
  
3
  //float
4
  PORTD |= (1 << 6);    
5
  sleep_us(1688);      
6
  PORTD &= ~(1 << 6);
7
  sleep_us(5064);    
8
  PORTD |= (1 << 6);  
9
  sleep_us(5064);      
10
  PORTD &= ~(1 << 6);
11
  sleep_us(1688);
12
  
13
  //float
14
  PORTD |= (1 << 6);    
15
  sleep_us(1688);      
16
  PORTD &= ~(1 << 6);
17
  sleep_us(5064);    
18
  PORTD |= (1 << 6);  
19
  sleep_us(5064);      
20
  PORTD &= ~(1 << 6);
21
  sleep_us(1688);
22
  
23
  //low
24
  PORTD |= (1 << 6);
25
  sleep_us(1688);
26
  PORTD &= ~(1 << 6);
27
  sleep_us(5064);
28
  PORTD |= (1 << 6);
29
  sleep_us(1688);
30
  PORTD &= ~(1 << 6);
31
  sleep_us(5064);
32
  
33
  //low
34
  PORTD |= (1 << 6);
35
  sleep_us(1688);
36
  PORTD &= ~(1 << 6);
37
  sleep_us(5064);
38
  PORTD |= (1 << 6);
39
  sleep_us(1688);
40
  PORTD &= ~(1 << 6);
41
  sleep_us(5064);
42
  
43
  //low
44
  PORTD |= (1 << 6);
45
  sleep_us(1688);
46
  PORTD &= ~(1 << 6);
47
  sleep_us(5064);
48
  PORTD |= (1 << 6);
49
  sleep_us(1688);
50
  PORTD &= ~(1 << 6);
51
  sleep_us(5064);
52
  
53
  //float
54
  PORTD |= (1 << 6);    
55
  sleep_us(1688);      
56
  PORTD &= ~(1 << 6);
57
  sleep_us(5064);    
58
  PORTD |= (1 << 6);  
59
  sleep_us(5064);      
60
  PORTD &= ~(1 << 6);
61
  sleep_us(1688);
62
  
63
  //low
64
  PORTD |= (1 << 6);
65
  sleep_us(1688);
66
  PORTD &= ~(1 << 6);
67
  sleep_us(5064);
68
  PORTD |= (1 << 6);
69
  sleep_us(1688);
70
  PORTD &= ~(1 << 6);
71
  sleep_us(5064);
72
  
73
  //float
74
  PORTD |= (1 << 6);    
75
  sleep_us(1688);      
76
  PORTD &= ~(1 << 6);
77
  sleep_us(5064);    
78
  PORTD |= (1 << 6);  
79
  sleep_us(5064);      
80
  PORTD &= ~(1 << 6);
81
  sleep_us(1688);
82
  
83
  //float
84
  PORTD |= (1 << 6);    
85
  sleep_us(1688);      
86
  PORTD &= ~(1 << 6);
87
  sleep_us(5064);    
88
  PORTD |= (1 << 6);  
89
  sleep_us(5064);      
90
  PORTD &= ~(1 << 6);
91
  sleep_us(1688);
92
  
93
  //float
94
  PORTD |= (1 << 6);    
95
  sleep_us(1688);      
96
  PORTD &= ~(1 << 6);
97
  sleep_us(5064);    
98
  PORTD |= (1 << 6);  
99
  sleep_us(5064);      
100
  PORTD &= ~(1 << 6);
101
  sleep_us(1688);
102
  
103
  //low
104
  PORTD |= (1 << 6);
105
  sleep_us(1688);
106
  PORTD &= ~(1 << 6);
107
  sleep_us(5064);
108
  PORTD |= (1 << 6);
109
  sleep_us(1688);
110
  PORTD &= ~(1 << 6);
111
  sleep_us(5064);
112
  
113
  //float
114
  PORTD |= (1 << 6);    
115
  sleep_us(1688);      
116
  PORTD &= ~(1 << 6);
117
  sleep_us(5064);    
118
  PORTD |= (1 << 6);  
119
  sleep_us(5064);      
120
  PORTD &= ~(1 << 6);
121
  sleep_us(1688);
122
  
123
  //sync
124
  PORTD |= (1 << 6);
125
  sleep_us(1688);
126
  PORTD &= ~(1 << 6);
127
  sleep_us(52328);

von Oliver S. (oliverso)


Lesenswert?

Tobi Spr schrieb:
> Hier ein Auszug vom Programm

Hier ein Auszug aus der Antwort, die dein Problem löst:
>...42...

Oliver

von Tobi S. (alanblack)


Angehängte Dateien:

Lesenswert?

Hallo Oliver,

ich gebe zu dass ich ein wenig gebraucht habe um die Ironie zu 
verstehen! :-)
Darum habe ich mal die main.c und das makefile angehängt. Mehr wird in 
diesem Testprogramm nicht verwendet.

Die Software wird mit WinAvr compiliert und mit avrdude (direkt ausn 
Programmer's Notepad heraus) auf den Atmega geflasht.

Wenn noch mehr Infos benötigt werden, einfach melden (geht sogar ohne 
Ironie ;-))

Viele Grüße

Tobi

von Der Michel (Gast)


Lesenswert?

Tobi Spr schrieb:
> IMG_20121106_201813.jpg
> 2,6 MB
Was haben die 2,6 MB hochaufgelöste Holzmaserung jetzt mit dem Problem 
zu tun? Ein Schaltplan wäre deutlich zweckdienlicher.

von Tobi S. (alanblack)


Lesenswert?

Hallo,

Das bild hat nicht direkt was mit dem problem zu tun. Es sollte nur zur 
Visualisierung dienen. Einen Schaltplan habe ich leider nicht. Habe nur 
wie gesagt die Anleitung befolgt.

Grüße Tobi

von Oliver S. (oliverso)


Lesenswert?

Nun ja, das Problem ist aus der Ferne so nicht zu lösen. Von dem 
Programm bekommt man zwar Augenkrebs, wenn aber am Controller alles 
richtig angeschlossen ist, müsste der damit an PD6 Impulsfolgen 
ausgeben. Ob die richtig sind, musst du allerdinsg selber rausfinden.

Vermutlich hast du kein Oszi verfügbar, um zu überprüfen, was an dem Pin 
passiert.

Ich würde noch folgendes machen:
Eine LED an den Port hängen, dazu ein kleines Blinkprogramm schreiben, 
und damit die prinzipielle Funktion und auch das richtige Timimg zu 
überprüfen. BIst du sicher, daß dein Controller mit 16Mhz läuft?

Das Prgramm würde etwas übersichtlicher, wenn du die Befehlsflogne für 
low, high, ..., in Unterprogramme auslagern würdest.

Oliver

von Tobi S. (alanblack)


Lesenswert?

Guten morgen,

das mit der LED habe ich ja bereits gemacht (vielleicht habe ich mich 
undeutlich ausgedrückt) Am Pollin AVR Evaluierungsboard ist der PD6 mit 
einer LED verbunden 
(http://www.pollin.de/shop/dt/MTY5OTgxOTk-/Bausaetze_Module/Bausaetze/ATMEL_Evaluations_Board_Version_2_0_1_Bausatz.html)

Diese blinkt auch. Ob das Timing stimmt kann ich in diesem fall nicht so 
genau sagen, da es aufgrund der Zeit rasend schnell blinkt (optisch 
gesehen ist es nur ein Flimmern)

Zu den 16Mhz: Ich bin mir nicht sicher. Aber ich dachte wenn am Atmega 
ein 16Mhz Quarz angeschlossen ist, und ich es im makefile so definiere 
müsste er ja auf 16Mhz laufen oder? Ich habe im Makefile auch schon 
andere #F_CPU Werte versucht, leider ohne Erfolg.

Zu dem Programm: Da hast du recht, dass man da Augenkrebs bekommen 
könnte! :D Ich wollte aber mit diesem Testprogramm weitere Fallen (zb 
Timingprobleme) vermeiden. Eigentlich sind die low, high Folgen in 
Methoden strukturiert. Sogar die Tristate Folgen sind unterteilt 
(hx_2262_set_float, usw)

von Karl H. (kbuchegg)


Lesenswert?

Tobi Spr schrieb:

> Diese blinkt auch. Ob das Timing stimmt kann ich in diesem fall nicht so
> genau sagen, da es aufgrund der Zeit rasend schnell blinkt (optisch
> gesehen ist es nur ein Flimmern)

Dann nimm alle Zeiten zum Testen mal 100, dann kannst du auch mit der 
Eieruhr ausmessen ob die Zeiten stimmen.

> Zu den 16Mhz: Ich bin mir nicht sicher. Aber ich dachte wenn am Atmega
> ein 16Mhz Quarz angeschlossen ist, und ich es im makefile so definiere
> müsste er ja auf 16Mhz laufen oder?

Du hast falsch gedacht. Du musst die Fuses umstellen.

> Zu dem Programm: Da hast du recht, dass man da Augenkrebs bekommen
> könnte! :D Ich wollte aber mit diesem Testprogramm weitere Fallen (zb
> Timingprobleme) vermeiden.

Es geht doch nicht um Timingprobleme
1
void sendZero()
2
{
3
  ...
4
}
5
6
void sendOne()
7
{
8
  ...
9
}
10
11
void sendFloat()
12
{
13
  ...
14
}

und das was du senden willst realisierst du durch entsprechende Aufrufe 
der Funktionen in der richtigen Reihenfolge.


Edit:
Das hier
1
void sleep_us(uint16_t us)
2
{
3
    for(; us > 0; us--)
4
    {
5
        _delay_us(1);   
6
    }
7
}
wird sowieso nicht genau. Benutze in den send.... Funktionen _delay_us 
(fürs erste) und gut ists. Du hast deine 'Timingprobleme' an der völlig 
falschen Stelle vermeiden wollen.

1
#define OUT_DDR  DDRD
2
#define OUT_PORT PORTD
3
#define OUT_BIT  6
4
5
#define LONG_TIME  5064
6
#define SHORT_TIME 1688
7
8
void sendZero()
9
{
10
  // Pegel am Ausgang  1    0    1    0
11
  // Dauer             kurz lang kurz lang
12
13
  OUT_PORT |= (1 << OUT_BIT);
14
  _delay_us( SHORT_TIME );
15
16
  OUT_PORT &= ~(1 << OUT_BIT);
17
  _delay_us( LONG_TIME );
18
19
  OUT_PORT |= (1 << OUT_BIT);
20
  _delay_us( SHORT_TIME );
21
22
  OUT_PORT &= ~(1 << OUT_BIT);
23
  _delay_ms( LONG_TIME );
24
}

dann kriegt man auch keinen Augenkrebs und kann Änderungen leicht 
durchführen.
Und wenn du dann noch den Mega auf Quarzverwendung umfust, dann stimmen 
auch die Zeiten (aber teste das unbedingt einzeln! Der Mega muss auch 
auf 16Mhz laufen, wenn du darauf aufbauend die _delay_us dimensionierst! 
Sich das einfach nur wünschen ist zu wenig).

von Tobi S. (alanblack)


Angehängte Dateien:

Lesenswert?

Hallo kbuchegg,

Danke für deine umfangreiche Antwort. Ich habe das Programm nun nach 
deinem Vorbild aufgeräumt.

Allerdings werd ich es wohl erst testen können, wenn ich einen neuen 
Atmega aufgetrieben habe. Die Fusebits waren mit PonyProg nach dem 
Pollin Beispiel eingestellt. Als ich diese verändert habe (CKSEL1-3 
aktiviert) ist der µc nicht mehr ansprechbar. :-(

Habe leider keine Möglichkeit mit einem externen Quarz oder sowas den 
Controller wieder zum Leben zu erwecken.

Ich melde mich dann einfach wieder wenn ich einen neuen habe.

Vielen Dank und Beste Grüße

Tobi

von Karl H. (kbuchegg)


Lesenswert?

Das hier
1
void sendZero()
2
{
3
  // Pegel am Ausgang  1    0    1    0
4
  // Dauer             kurz lang kurz lang
5
6
  setPinHigh();
7
  _delay_us( SHORT_TIME );
8
9
  setPinLow();
10
  _delay_us( LONG_TIME );
11
12
  setPinHigh();
13
  _delay_us( SHORT_TIME );
14
15
  setPinLow();
16
  _delay_ms( LONG_TIME );
17
}
18
19
void sendOne()
20
{
21
  // Pegel am Ausgang  1    0    1    0
22
  // Dauer             kurz lang kurz lang
23
  
24
  setPinHigh();
25
  _delay_us( SHORT_TIME );
26
  
27
  setPinLow();
28
  _delay_us( LONG_TIME );
29
  
30
  setPinHigh();
31
  _delay_us( SHORT_TIME );
32
  
33
  setPinLow();
34
  _delay_us( LONG_TIME );
35
}

kann nicht stimmen. 0 und 1 haben laut deinem Programm exakt die gleiche 
Sequenz.

von Tobi S. (alanblack)


Lesenswert?

Sorry muss natürlich
1
void sendOne()
2
{
3
  //Pegel am Ausgang  1    0    1    0
4
  //Dauer        lang  kurz  lang  kurz
5
  
6
  setPinHigh();
7
  _delay_us( LONG_TIME );
8
  
9
  setPinLow();
10
  _delay_us( SHORT_TIME );
11
  
12
  setPinHigh();
13
  _delay_us( LONG_TIME );
14
  
15
  setPinLow();
16
  _delay_us( SHORT_TIME );
17
}

sein.

von Tobi S. (alanblack)


Angehängte Dateien:

Lesenswert?

Hallo,

da ich nun einen neuen Atmega32 habe, den ich diesmal sogar richtig auf 
den externen Quarz (External Crystal High-Frequency, Startup: 16K + 
64ms, CKOPT Enabled) fusen konnte, wollte ich nun den Code ausprobieren. 
Leider tut sich an der Funksteckdose nicht.

Um verifizieren dass der Quarz richtig schwingt, habe ich mir zusätzlich 
ein kleines Programm geschrieben welches die LED (PD6) jeweils für 
1Sekunde an und 1 Sekunde ausschaltet.

Mit einem Software-Osziloskop über die Soundkarte habe ich den Pin 
gemessen. Ein Ausschnitt davon befindet sich im Anhang. Für mich sieht 
das eigentlich korrekt aus. Was meint ihr?

Habt ihr noch Ideen was schief laufen könnte, warum die Steckdose nicht 
schaltet?

Viele Grüße und Besten Dank für die Hilfe

Tobi

von Tobi S. (alanblack)


Angehängte Dateien:

Lesenswert?

Nachtrag:

Ich habe gerade das Signal mit dem Soundkarten-Oszi von einer 
Fernbedienung gemessen (die ich noch nicht auseinander gesägt habe) 
siehe scope_tasteBON_bw.jpg

Anschließend habe ich das eigene generierte Signal gemessen. Siehe 
scope_Atmega32_bw.jpg

Das sieht ja von der Struktur sehr ähnlich aus, allerdings kann man an 
der X-Achse erkennen dass das eigene Signal deutlich länger dauert als 
das von der FB.

Bedeutet dies dass die Taktlängen der o.g. Anleitung nicht mit dieser FB 
zusammenpassen? Habt ihr Tipps wie man richtig die sog. 
"Oszillationsperiode" ablesen kann (falls das der Fehler sein könnte)

Vielen Dank für die Hilfe
--Tobi

von Fred (Gast)


Lesenswert?

Was ist denn da so schwierig?
ändern das Timing so ab, das beide Diagramme gleich sind.
Dann schaltet auch deine Steckdose.

von Fred (Gast)


Lesenswert?

Immer die schmoggos, die als pseudoexperten auflaufen... TS TS TS Depp 
Ey

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.