Verwendung einer .h und .c; AVR

Benutzt du AVRStudio oder ein externes makefile?

Für die "send_r_v_2_0.c" habe ich das AVR Studio verwendet. Die "rc5.h" 
und "rc5.c" habe ich mit dem Standard Text Editor erstellt und die 
entsprechenden Endungen (.c und .h) von Hand geändert.

Der Pfad von der .h muss dann halt noch angepasst werden aber das wird 
wahrscheinlich selbstverständlich sein.

Hast du die .h und die .c in den Projektexplorer von AVR Studio 
hinzugefügt?
Wenn nicht findet er die Datein nicht bzw. übersetzt er sie nicht zu 
einer .o

ja, habe ich gemacht

Habe gesehen, dass die rc5.H ein großes H hat. Habe es jetzt in ein 
kleines h geändert. Könnte das vielleicht einer der Gründe sein, 
weswegen es nicht klappt?

Ich hab mal dein Projekt überflogen und mir sind 3 Sachen ins 
Augegesprungen

1. In der rc5.h war ein Prototyp falsch deklariert sie Kommentar.
2. Eigene libs werden mit #include "" eingebunden
3. rc5.h war nicht in der rc5.c eingebunden

(4.) Du verwendest ein goto in einer Schleife was zu schwer finbahren 
Fehlern füren kann

Das habe ich doch vier Beiträge vorher gemacht.

Danke rudi, werde gleich mal nachschauen und erneut testen.

Funktioniert leider immer noch nicht.

Wenn ich die Senderoutine direkt in meinem Programm verwende 
funktionierts. Nur leider nicht als Aufruf aus der lib.

Noch irgendeine Ahnung, woran es liegen könnte?

Hallo ratlos,

kompiliert Dein Projekt nicht? Oder wird das Programm nicht ausgefüht?

Hast Du schon einmal etwas von dem Schlüsselwort "extern" gehört?
Das soll der Quelldatei, die auf eine Funktion einer anderen 
(C-)Quelldatei zugreifen will, mitteilen, dass der Funktionsrumpf extern 
Codedatei erzeugt worden ist.

#ifndef _rc5_H
#define _rc5_H

/* hier noch extern vorschreiben*/
extern void rc5_send(int data);

#endif

Dann sollte es funktionieren.

Viel Erfolg

Hallo cskulkw,

vielen Dank für deien Hinweis. Habe es geändert und getestet aber leider 
hat es auch nicht den gewünschten Effekt gehabt.

Interessanter Weise hat "rc5_receive();" auch mit dem Aufruf aus der lib 
funktioniert und das auch schon mit der Variante ohne den Änderungen von 
rudi.

Für weitere Hinweise bin ich sehr dankbar. Dieses Problem stellt sich 
mir schon etliche Stunden in den Weg.

Kannst du mal bitte die Ausgaben vom Compiler zeigen?

Gerne!

Gesendete_bits in rc5_send ist nicht initialisiert?

Ok, habe "gesendete_bits" mit 0 initialisiert (in der "rc5.c" und in der 
"send_r_v_2_0.c) aber was nun geschieht ist äußerst seltsam. Der Aufruf 
der "rc5_send" aus der bib funktioniert grundsätzlich, jedoch wird das 
Signal nicht gesendet, wenn der Taster an PORTB.2 betätigt ist, sondern 
zufällig, wenn das Board etwas geschüttelt wird. Ich dachte zu erst an 
einen Wackelkontakt oder einen vergessenen PullUp aber wenn ich 
"rc5_send" aus "send_r_v_2_0.c" aufrufe, funktioniert es tadellos und 
ich sehe keinen Unterschied.

Untescheidet sich dieser Aufruf in irgendeiner Weise? Hat irgendjemand 
eine Vermutung für diesen sonderbaren Effekt?

PS: Vielen Dank an ozo. Bin der Problemlösung ein ganzes Stück näher 
gekommen.

Lade den aktuellen Stand des Projektes nochmal zur Durchsicht hoch.

versuch mal, alle sauber zu machen.
Warum gibt es beispielsweise "gesendete_bits" gleich dopplet? Macht das 
Sinn?
Und was meinst du mit "bib" - wie genau rufst du was wann wo auf wenn es 
nicht funktioniert?

Auch könnte http://www.mikrocontroller.net/articles/Entprellung der 
Lektüre wert sein ;)

hallo ratlos,

nachdem ich mir rc5 im Wiki angeschaut hatte, verstehe ich mehr, was Du 
da beabsichtigst.

Du willst also eine Infrarot-Fernbedienung entschlüsseln und ggf. etwas 
damit steuern.

Lt. Wiki sei der RC-5-Code eine Manchestercode. Das heißt er dürfte 
keine Non return to zero-Code sein, wie es beim CAN-Bus der Fall ist.

Daraus schließe ich, dass jedes Bit mindestens 2. Flanken hat. Es geht 
Dir ja nur darum die Frequenz Periodendauer herauszufinden.

Mir fällt das Verstehen Deines Codes schwer. Mein Haupttip ist, dass Du 
das Zähler- und goto-Schleifenkonstrukt durch eine kurze 
Interruptprogrammierung ersetzt.

Ich würde einen Input-Capture-Eingang benutzen. Dabei initialisierst Du 
einen oder nur "den einen" 16-Timer so,  das er ständig inkrementiert. 
Dann nimmst Du den Input und aktivierst die negative Flanke. Wenn das 
Interruptereignis der fallenden Flanke auftritt, dann setzt Du das 
Zählerregister auf Null zurück und änderst die Flankensteuerung auf 
steigende Flanke.
Dieses Ereignis wird dann gemäß rc5-protokoll nach x ms eintretten. Die 
Interrupt-service-routine wird aufgerufen. Jetzt speicherst Du das 
Timerregister in einer globalen Variablen setzt das Timer-Zählregister 
nochmals zurück und schaltest wieder die Flanke, auf die reagiert werden 
soll, auf fallend.
Tritt wieder die fallende Flanke auf, kannst Du den Zählerstand in einer 
weiteren Variablen speichern. Wenn beide Wert ungefähr gleich sind, dann 
hast Du das richtige Bit synchronisiert. Sind Sie unterschiedlich, muß 
etwas schief gegangen sein.
Mit dem Timer kannst Du über den Vorteiler auf eine sinnvoll Taktrate 
herunterteilen. Darüber kannst Du theorestisch ausrechen, ob es sich um 
eine "1" oder eine "0" handelt. Ich gehe mal davon aus, dass Du kein 
Oszi oder Frequenzzähler hast, um messen zu können.

Debuggen kannst Du ja nicht, weil Du "nur" einen Programmer hast.

So für mehr reicht meine Zeit gerade nicht.

Viel Erfolg

@ozo:

Der Grund warum es "gesendete_bits" doppelt gab ist, damit ich den 
Sendevorgang einmal von der "send_r_v_2_0.c" ausführen konnte, indem ich 
die Kommentarzeichen entfernt habe(Da hat es auch ohne Probleme 
funktioniert). Mit "bib" meinte ich meine "eigene Bibliothek" (cr5.c). 
Der Entprellvorgang war natürlich nicht sauber gemacht aber auch nach 
der Abänderung in eine saubere Entprellung und dem entfernen der 
doppelten Initialisierung funktioiert es nicht.

Wenn ich den Sendevorgang mit dem Befehehl "rc5_send(sendefach);" 
auslöse, funktioniert es nur sporadisch, wenn das Board gerüttelt oder 
geschüttelt wird. Ich kann mir das nicht erklären. Da es ja 
funktioniert, wenn ich den Quelltext des Sendevorgans in die 
"send_r_v_2_0.c" einfüge.



@cskulkw

Genau, ich möchte Signale von einer Fernbedienung auslösen, im EEPROM 
abspeichern und wieder senden. Das ganze funktioniert auch einwandfrei, 
solange ich alles in die gleiche .c schreibe, was natürlich sehr 
unübersichtlich ist. Der Empfangsvorgang, der Speichervorgan( welcher 
nicht in diesem Projekt ist) und der Sendevorgang funktionieren, nur 
nicht wenn ich sie aus einer eigenen Bibliothek aufrufen.

Dein Lösungsansatz klingt trotzdem interessant und ist evtl. auch 
einfacher. Evtl. werde ich diese Variante zu einem späteren Zeitpunkt in 
Betracht ziehen.

cskulkw schrieb:
> Mir fällt das Verstehen Deines Codes schwer. Mein Haupttip ist, dass Du

Ich weiß ja nicht wie interessant meine Variante ist aber sollte 
Interesse bestehen, kann ich sie gerne erläutern. Es hörte sich jedoch 
nach einer Hilfestellung für mich an und nicht nach einer Frage, was ich 
mir dabei gedacht habe.

cskulkw schrieb:
> das Zähler- und goto-Schleifenkonstrukt durch eine kurze
> Interruptprogrammierung ersetzt.

Das mit dem goto scheint ja nicht so toll zu sein, wie ich mitbekommen 
habe. Werde das wahrscheinlich auch noch anders lösen

Natürlich vielen Dank, für die Mühe, die du dir gemacht hast.



@all

Woran kann diese Willkürliche Auslösung der Sendevorgans liegen?????

Vor allem: Warum wird gesendet, wenn das Board geschüttelt wird???(Bei 
der Verwendung von "rc5_send(sendefach);")

Habe nochmal das aktuelle Projekt angehängt.

Habe den Fehler gefunden: Das "sendefach", welches der Funktion 
"rc5_send(sendefach)" übergeben wurde, wurde nicht gelöscht. Dadurch 
wurde das "sendefach" permanent gesendet, was dann diesen Effekt 
hervorgerufen hat.