Funksteckdosen HX2262 mit Atmega32 ansteuern

Tobi Spr schrieb:
> Hier ein Auszug vom Programm

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

Oliver

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

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

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

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)

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

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

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.

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.

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

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