FB Betty in FHEM einbinden

[pc1246]

Wenn's da was brauchbares gibt, wäre ich über einen Wiki-Eintrag sehr dankbar, bin kein Programmierer 

Moin
Einen Wiki-Eintrag kann man auch als Nichtprogrammierer schreiben.
Ich habe mich auch schon mal fuer eine Modulbeschreibung geopfert, hat gar nicht weh getan! Und hilft auch immens beim Verstaendnis!
Gruss Christoph

[szoller]

Ja, ist mir schon klar, allerdings sollte man dazu die Thematik selbst auch verstehen.

Mein konkretes Problem ist die Flut an Informationen in diesem Thema, weiß gar nicht wo ich anfangen soll 

Brauch ich jetzt zB. Boop oder muss ich doch was anderes flashen... da fängts bei mir schon an

[KölnSolar]

Brauch ich jetzt zB. Boop oder muss ich doch was anderes flashen...

Na das ist (fast) einfach 
BBoooopppp

In den ersten Posts sind beschrieben: Flashhardware, Betty-Heaven(flashsoftware unter Win), Lokation des Boop-Sourcecodes, Toolchain f. Compile.

und zu meinen Problemen: versteht jemand, warum der Precompiler die simplen Makros nicht mag

Code Auswählen Erweitern

error: expected expression before ')' token
#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))

Verwendung:    SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN );
   
sollte eigentlich dann das:   CC1100_CS_DDR |= (1<<CC1100_CS_PIN)
ergeben.

Mit avr-gcc und makefiles der aculfw klappt das problemlos. Irgendeine Option ins makefile ? Nur welche ?

Versuche ich mich im Vergleich dem Problem anzunähern, scheitere ich beim make einer CUL_433 bereits daran, dass die option -mmcu=... abgewiesen wird. Geht arm-none-eabi-gcc also eben nur für arm-Prozessoren und nicht avr, oder ?

[Telekatz]

Versuche ich mich im Vergleich dem Problem anzunähern, scheitere ich beim make einer CUL_433 bereits daran, dass die option -mmcu=... abgewiesen wird. Geht arm-none-eabi-gcc also eben nur für arm-Prozessoren und nicht avr, oder ?

Das sagt doch der Name arm-none-eabi-gcc schon aus, dass das für ARM ist. AVR ist nicht ARM.

[KölnSolar]

Die Antwort hatte ich ja fast erwartet  Hätte ja sein können, dass die Toolchain beide kann, schade 

Auch noch ne Idee zu den Makros ? Wird das generell im arm-none-eabi-gcc nicht unterstützt ? Bliebe ja noch die Möglichkeit eine Funktion für zu bauen.

[Telekatz]

Poste mal etwas mehr vom Code. Das was davor und danach kommt. Und auch etwas mehr von der Compilerausgabe beim Fehler.

[KölnSolar]

mehr ist es leider nicht  das define des makros und dann die Fehlermeldung des Precompilers. Davor und danach ist unerheblich. Hab die Makros schon an x verschiedenen Stellen eingebaut.
Ok, hab gerade noch gesehen, dass beim cut&paste der Unterstrich nicht transportiert wurde, welche ")" der Precompiler meint. Es ist die hinter dem ersten PORT.
Der Meldung folgend hab ich dann mal getan, was der Precompiler will und einfach PORT+1 in die Klammer geschrieben, Dann lautet die Meldung:
error: lvalue required as left operand of assignment. Markiert ist dann nicht die Klammer sondern das "|" vom "|=". Deshalb gehe ich ja davon aus, dass der Compiler entweder ein generelles Problem mit solchen Makros hat oder er aber (hoffentlich) mit einer option zu überlisten ist. Nur wo könnte man das nachlesen 

[Telekatz]

Der Compiler hat kein Problem mit solchen Makros. Das Problem sitzt so gut wie immer vor der Tastatur und tippt darauf herum.
Ist CC1100_CS_DDR und CC1100_CS_PIN überhaupt definiert?

[KölnSolar]

wie gerne würde ich Dir zustimmen, aber

Code Auswählen Erweitern

#define CC1100_CS_port      1
#define CC1100_CS_PIN 2
#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))
#define CLEAR_BIT(PORT, BITNUM) ((PORT) &= ~(1<<(BITNUM)))

int main(void)
{
  SET_BIT( CC1100_CS_port, CC1100_CS_PIN ); 
  CLEAR_BIT( CC1100_CS_port, CC1100_CS_PIN );
} // main
sollte dann funktionieren und nicht

Code Auswählen Erweitern

main.c: In function 'main':
main.c:3:39: error: lvalue required as left operand of assignment
#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))
                                       ^
main.c:8:3: note: in expansion of macro 'SET_BIT'
   SET_BIT( CC1100_CS_port, CC1100_CS_PIN );
   ^~~~~~~
main.c:4:41: error: lvalue required as left operand of assignment
#define CLEAR_BIT(PORT, BITNUM) ((PORT) &= ~(1<<(BITNUM)))
                                         ^
main.c:9:3: note: in expansion of macro 'CLEAR_BIT'
   CLEAR_BIT( CC1100_CS_port, CC1100_CS_PIN );
   ^~~~~~~~~
Makefile:129: recipe for target 'main.o' failed
make: *** [main.o] Error 1

ergeben, oder ?
edit: und so

Code Auswählen Erweitern

#include <avr/iom32u4.h>

#define CC1100_CS_DDR DDRB
#define CC1100_CS_PIN PB3

#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))
#define CLEAR_BIT(PORT, BITNUM) ((PORT) &= ~(1<<(BITNUM)))

int main(void)
{
  SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN ); 
  CLEAR_BIT( CC1100_CS_DDR, CC1100_CS_PIN );
} // main
kommt dann wieder

Code Auswählen Erweitern

In file included from main.c:1:0:
./avr/iom32u4.h:39:4: error: #error "Include <avr/io.h> instead of this file."
#  error "Include <avr/io.h> instead of this file."
    ^~~~~
main.c: In function 'main':
main.c:6:37: error: expected expression before ')' token
#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))
                                     ^
main.c:11:3: note: in expansion of macro 'SET_BIT'
   SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN );
   ^~~~~~~
main.c:7:39: error: expected expression before ')' token
#define CLEAR_BIT(PORT, BITNUM) ((PORT) &= ~(1<<(BITNUM)))
                                       ^
main.c:12:3: note: in expansion of macro 'CLEAR_BIT'
   CLEAR_BIT( CC1100_CS_DDR, CC1100_CS_PIN );
   ^~~~~~~~~
Makefile:129: recipe for target 'main.o' failed
make: *** [main.o] Error 1

[papa]

Das liegt daran, das CC1100_CS_port eine Konstante ist und dieser kann der Compiler keinen Wert zuweisen. Du musst im Macro auf eine Adresse casten.

Code Auswählen Erweitern


#define CC1100_CS_port      1
#define CC1100_CS_PIN 2

#define SET_BIT(PORT, BITNUM) (*(char*)(PORT) |= (1<<(BITNUM)))
#define CLEAR_BIT(PORT, BITNUM) (*(char*)(PORT) &= ~(1<<(BITNUM)))

int main(void)
{
  SET_BIT( CC1100_CS_port, CC1100_CS_PIN );
  CLEAR_BIT( CC1100_CS_port, CC1100_CS_PIN );
  return 0;
}


So geht es zum Beispiel. Du musst char* entsprechend der Addressbreite noch austauschen.

[Telekatz]

Besser wäre es bereits mit dem define für CC1100_CS_port einen Pointer zu definieren.

Und mach erst mal das, was der Compiler sagt:

Code Auswählen Erweitern

./avr/iom32u4.h:39:4: error: #error "Include <avr/io.h> instead of this file."
#  error "Include <avr/io.h> instead of this file."

[KölnSolar]

@papa: ok, glaube ich Dir jetzt mal so. Entscheidend ist aber der 2. Test.
edit: neugierig hab ich es ausprobiert. Stimmt. Aber leider ist das 2. Bsp. das Entscheidende 

@telekatz: ist ja einfach nur ein Extrakt aus der culfw. avr-gcc kanns, arm-none-eabi-gcc nicht. Und ich will ja gerade nichts an der culfw ändern, sonst hätt ich mir schon längst anders beholfen. Nicht vielleicht doch ne einfache option ?
edit:

Und mach erst mal das, was der Compiler sagt:
Code: [Auswählen]
./avr/iom32u4.h:39:4: error: #error "Include <avr/io.h> instead of this file."
#  error "Include <avr/io.h> instead of this file."

Prinzipiell schon klar hat aber mit dem Beispiel nix zu tun(und arm-none-eabi-gcc  kann ja kein -mmcu=atmega32u4, was der Grund für die Fehlermeldung istweshalb ein include io.h nicht funktioniert)

[Telekatz]

DDRB ist in iom32u4.h so definiert:

Code Auswählen Erweitern

#define DDRB _SFR_IO8(0x04)

Da macht der Präprozessor dann daraus:

Code Auswählen Erweitern

int main(void)
{
  ((_SFR_IO8(0x04)) |= (1<<(2)));
  ((_SFR_IO8(0x04)) &= ~(1<<(2)));
  return 0;
}


Da du das File, in dem das AVR Makro _SFR_IO8 definiert ist nicht inkludierst, wird es nicht aufgelöst und der Compiler sagt dir, dass in der linken Klammer Unsinn steht.

Und deshalb sitzt das Problem vor der Tastatur.

[KölnSolar]

DAS klingt schlüssig. Muss ich suchen, ob das noch in der culfw steckt....

[KölnSolar]

es war es (fast). Fast deshalb, weil ich es sogar aus meiner iom32u4.h rausgenommen hatte, als ich noch kein Verständnis für Makros hatte 

Danke, da wär ich im Leben nicht drauf gekommen. Die Fehlermeldung ist auch nicht wirklich umfangreich...

Nun muss ich die geglaubt behoben zu habenden Fehler wieder suchen...