Entwicklung SIGNALDuino Empfänger Firm- und Hardware V4 für Maple Mini und ESP32

Begonnen von Ralf9, 13 Dezember 2019, 12:48:26

Vorheriges Thema - Nächstes Thema

Ralf9

Hallo papa,

Danke für Deine Hilfe, mir ist noch nicht klar wie die InternalEprom-Klasse initialsiert wird und wie das lesen mit getByte und das Schreiben mit setByte aussieht.

Ich habe die Hoffnung, daß mit dem aktuellen Arduino package das SerialUSB demnächst funktionieren wird.
Da gibt es dann auch ein gepufferten EEPROM zugriff
https://github.com/stm32duino/STM32Examples/blob/master/examples/NonReg/BufferedEEPROM/BufferedEEPROM.ino
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

papa

Zitat von: Ralf9 am 13 Januar 2020, 23:41:12
Danke für Deine Hilfe, mir ist noch nicht klar wie die InternalEprom-Klasse initialsiert wird und wie das lesen mit getByte und das Schreiben mit setByte aussieht.
Eigentlich alles ganz einfach.
#include <Arduino.h>
#include <EEPROM.h> // the EEPROM library contains Flash Access Methods
#include "Storage.h"

as::InternalEprom eeprom;

void setup() {
  Serial.begin(57600);
}

void loop() {
  // read single byte
  for( int address=0; address<256; ++address ) {
    Serial.print(eeprom.getByte(address),HEX);
    Serial.print(" ");
  }
  Serial.println();

  // write single byte
  for( int address=0; address<256; ++address ) {
    eeprom.setByte(address,address);
  }
  // write RAM to FLASH
  eeprom.store();

  // read 256 byte to buffer
  uint8_t buffer[256];
  eeprom.getData(0, buffer, 256);
  for( int address=0; address<256; ++address ) {
    Serial.print(buffer[address],HEX);
    Serial.print(" ");
  }
  Serial.println();

  // stop program
  while(1) ;
}
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Ralf9

ZitatEigentlich alles ganz einfach.
Danke damit funktioniert es. Ich musste in der Storage.h ein paar Debugzeilen löschen damit ich das "include debug.h" nicht benötige.

Bei der Radio.h ist mir nicht klar warum Ihr bei der waitMiso nur ein delay macht
  void waitMiso () {
    _delay_us(10);
  }

und nicht wie beim Arduino
   void waitMiso () {
    while(PINTYPE::getState(MISO));
  }



Ich habe noch ein Problem mit dieser Routine, diese funktioniert nur mit dem Arduino, beim Maple Mini wird nur Müll ausgegeben.
Damit sollen die string_0 bis string_7 ausgegeben werden.
void cmd_help_S() // get help configvariables
{
char buffer[12];
for (uint8_t i = 0; i < CSetAnz; i++) {
    strcpy_P(buffer, (char*)pgm_read_word(&(CSetCmd[i])));
    MSG_PRINT(F("CS"));
    MSG_PRINT(buffer);
    MSG_PRINT(F("= "));
}
MSG_PRINTLN("");
}



#define CSetAnz 8

const char string_0[] PROGMEM = "fifolimit";
const char string_1[] PROGMEM = "mcmbl";
const char string_2[] PROGMEM = "mscnt";
const char string_3[] PROGMEM = "muoverflmax";
const char string_4[] PROGMEM = "maxnumpat";
const char string_5[] PROGMEM = "ccmode";
const char string_6[] PROGMEM = "muthresh";
const char string_7[] PROGMEM = "maxpulse";

const char * const CSetCmd[] PROGMEM = { string_0, string_1, string_2, string_3, string_4, string_5, string_6, string_7};

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

papa

Zitat von: Ralf9 am 14 Januar 2020, 22:59:33
Bei der Radio.h ist mir nicht klar warum Ihr bei der waitMiso nur ein delay macht
Oh - da hast Du noch eine alte Leiche entdeckt. Die LibSPI Klasse ist auf einem AVR entstanden. Dort hat die SPI Library keine API, um die Pins abzufragen. Da das waitMiso() "nur" für die CC1101-Reset-Routine gedraucht wurde, habe ich mal eben schnell nur ein delay eingebaut. Das hat auch bisher scheinbar gut funktioniert :-) Die SPI Library für den STM32 kann aber die Pins zurückgeben. Du kannst ja mal die folgende Implementierung testen (habe gerade keine Hardware da).
  void waitMiso () {
#ifdef ARDUINO_ARCH_STM32F1
    while(digitalRead(SPI.misoPin()));
#elif defined (PIN_SPI_MISO)
    while(digitalRead(PIN_SPI_MISO));
#else
    _delay_us(10);
#endif
  }


Zitat von: Ralf9 am 14 Januar 2020, 22:59:33
Ich habe noch ein Problem mit dieser Routine, diese funktioniert nur mit dem Arduino, beim Maple Mini wird nur Müll ausgegeben.
Damit sollen die string_0 bis string_7 ausgegeben werden.
void cmd_help_S() // get help configvariables
{
char buffer[12];
for (uint8_t i = 0; i < CSetAnz; i++) {
    strcpy_P(buffer, (char*)pgm_read_word(&(CSetCmd[i])));
    MSG_PRINT(F("CS"));
    MSG_PRINT(buffer);
    MSG_PRINT(F("= "));
}
MSG_PRINTLN("");
}

Ich denke das Problem ist pgm_read_word. Das verarbeitet nur 16 Bit - was für Addressen auf dem AVR auch OK ist. Beim STM32 sind die Addressen aber 32 Bit. Deshalb sollte da besser pgm_read_ptr verwendet werden. Das müsste für beide Architekturen das richtige machen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Telekatz

Die Makros  pgm_read_word und PROGMEM sind für dem STM32 nicht notwendig, da die ARM Architektur nicht über getrennte Speicherbereiche für Daten und Programm verfügt.

Wenn der gleiche Code für AVR und ARM compilierbar sein soll, musst du die Makros per Postprozessor für ARM entfernen. Ansonsten gleich weglassen.

papa

Die Macros sind für den STM32 richtig definiert. Es muss halt nur auch das richtige Macro für Addressen verwendet werden.
#define pgm_read_word(addr) ({ \
  typeof(addr) _addr = (addr); \
  *(const unsigned short *)(_addr); \
})

Das schneidet halt eiskalt 2 Byte ab.
#define pgm_read_ptr(addr) ({ \
  typeof(addr) _addr = (addr); \
  *(void * const *)(_addr); \
})

Dieses gibt die vollen 4 Byte zurück.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Ralf9

ZitatOh - da hast Du noch eine alte Leiche entdeckt. Die LibSPI Klasse ist auf einem AVR entstanden. Dort hat die SPI Library keine API, um die Pins abzufragen. Da das waitMiso() "nur" für die CC1101-Reset-Routine gedraucht wurde, habe ich mal eben schnell nur ein delay eingebaut. Das hat auch bisher scheinbar gut funktioniert :-) Die SPI Library für den STM32 kann aber die Pins zurückgeben. Du kannst ja mal die folgende Implementierung testen (habe gerade keine Hardware da).
Danke damit funktionierts.

ZitatIch denke das Problem ist pgm_read_word. Das verarbeitet nur 16 Bit - was für Addressen auf dem AVR auch OK ist. Beim STM32 sind die Addressen aber 32 Bit. Deshalb sollte da besser pgm_read_ptr verwendet werden. Das müsste für beide Architekturen das richtige machen.
Mit dem pgm_read_ptr funktionierts.


Mir ist noch nicht klar, in welchen Fällen vor den const Definitionen ein static kommt.

Gibt es beim Maple Mini auch eine Möglichkeit das freeram zu ermitteln?
Beim Arduino geht dies z.B. so:
uint16_t freeRam () {
{
  extern int __heap_start, *__brkval;
  int v;
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
}

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

papa

BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Ralf9

ZitatHilft das hier weiter
Ja, das freeram müsste dann dies hier sein:
  Serial.print("Estimated Free RAM: ");
  Serial.println(((stack_ptr < minSP) ? stack_ptr : minSP) - heapend + mi.fordblks);
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

mittlerweile funktioniert es soweit, daß ich den TX29TDH-IT mit FSK empfangen und über SerialUSB ausgeben kann.
Beim OOK/ASK  Empfang (SLOWRF beim Cul) muss ich an der Signaldecoder class noch einiges umbauen.
Mit der Arduino IDE wird das Ethernet nur an der SPI 1 funktionieren, ich habe in der Ethernet Lib keine Möglichkeit gefunden wie ich angeben kann, daß ich die SPI 2 verwenden will.
Der OOK/ASK Empfang wird vorerst nur beim ersten cc1101 Modul funktionieren, ein gleichzeitiger OOK/ASK auf 2 cc1101 Modulen ist mir momentan zu aufwändig.
Über FSK werden nur die unidirektionalen Protokolle funktionieren.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

Lesen hier auch HF- und Antennenspezialisten mit?

Beim HW-MAPLE-Small ist der Abstand zwischen der Antennen sehr klein, gibt es da keine gegenseitige Beeinflussungen der Antennen?
Kann z.B. die 868MHz Antenne die direkt neben der 433MHz Antenne ist, den 433MHz Empfang beeinträchtigen?
https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Small/Small_9056.JPG
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

RaspiLED

Hi,
ich nutze die Small u d auch die Locutus 4er Platine aufgrund des Abstands der SMA Buchsen nur mit Antennenkabel.
Bisher ist mir ein übersprechen noch nicht aufgefallen. Die Diskussion gab es ja schon bei den Boardversionen und bei den LaCrosseGW soweit ich mich erinnere.
Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Ranseyer

ZitatKann z.B. die 868MHz Antenne die direkt neben der 433MHz Antenne ist, den 433MHz Empfang beeinträchtigen?

Natürlich. Lambda/2  oder lieber Lambda Abstand wäre absolut zu empfehlen. Das ist die Theorie.
Aber: Reicht das nur im entferntesten wenn eine der Antennen auf einer beliebigen Frequenz sendet ?
Ich gehe davon aus: Wenn auch nur eine der Antennen auf knapp 434 oder 868 MHz sendet, sind mit Sicherheit alle Receiver in 1 Meter Entfernung "zugestopft".

Die Praxis ist so dass die meisten genervt waren vom besseren HF-Design z.B. hier: https://raw.githubusercontent.com/ranseyer/CUN-STM32/master/HW-MAPLE-Large/Archiv/Charge5-V1.5/Board-V102.png (geht mir auch so)

Beim Maple-Cul Small von mir ist es ja noch gut. Ich würde empfehlen den nur mit zwei Antennen zu bestücken, dann kann eine nach rechts und die andere nach links zeigen. (Beispiel Polarisation: eine 90 Grad verdrehte Antenne zwischen Sender und Empfänger sollte 3dB kosten = 50% Verlust)
...man sieht das alles ist nur ein Kompromiss. Bei meinem wichtigsten Maple-Cul sind die Antennen alle irgendwie komisch gedreht damit ich ein besseres Gefühl bei den Abständen habe.

Mein Fazit:
-Wer es ordentlich will aus dieser Sicht muss wohl bei fast jedem Design Pigtails anlöten (bringt auch Dämpfung) und die Antennen weiter absetzen...
-Wichtige Empfänger (wo kein Byte verloren gehen darf) sollten auf keinen Fall bei einem Sender in der Nähe sein

Oder halt die Kirch im Dorf lassen... 8)
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Ralf9

ZitatNatürlich. Lambda/2  oder lieber Lambda Abstand wäre absolut zu empfehlen. Das ist die Theorie.
Aber: Reicht das nur im entferntesten wenn eine der Antennen auf einer beliebigen Frequenz sendet ?
Ich gehe davon aus: Wenn auch nur eine der Antennen auf knapp 434 oder 868 MHz sendet, sind mit Sicherheit alle Receiver in 1 Meter Entfernung "zugestopft".

Mir gehts dabei nur um den Empfang, bei unidirektionalen Protokollen wird normalerweise nicht so oft gesendet.

Ich habe mir mal darüber Gedanken gemacht, welche Wünsche ich habe.
Der Maple-Cul sollte kleiner sein als der Maple-Cul Small. Er sollte als Nachfolger des Nano Cul verwendbar sein, optional das Lan Modul.
Außerdem noch eine 4er Stiftleiste für einen optimalen Huckepak minicul.

Am Ende des Maple Mini eine Doppel cc1101 Platine, ungefähr so wie in der Anlage.
Wer nur 433 MHz möchte, kann das 868 MHz Modul unbestückt lassen.

Am anderen Ende (bei der USB Buchse) eine optionale Huckepak Platine für einen 868 cc1101.
Für diejenigen die noch einen dritten cc1101 wollen,
oder für diejenigen denen bei der Doppel cc1101 Platine der Abstand zwischen den beiden Antennen zu gering ist,
der Abstand zwischen den Antennen ist dann ca 7-8 cm. Ist dieser Abstand gross genug, damit beim Empfang die Beeinträchtigungen zwischen den beiden Antennen weniger werden?

LAN Modul auf SPI 1
cc1101 auf SPI 2

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ranseyer

Hi, der Vorschlag das gefällt mir ehrlich gesagt recht gut, nur denke ich sollte man ein paar mm mehr an der Antennenseite spendieren...

Grund: Denke mal der Cc1101 sollte max. halb unter dem Maple verschwinden. (Ansonsten sollte man ggf. mal Probieren ob/wie die Verschlechterung ist)

Zweite Sache ist die Frage nach der Prio von 433 oder 868 Mhz... Falls diese gleich ist sollte man lieber die 433Mhz Antenne per Default schlechter anbinden.

ZitatAm anderen Ende (bei der USB Buchse) eine optionale Huckepak Platine für einen 868 cc1101.
Für diejenigen die noch einen dritten cc1101 wollen,
oder für diejenigen denen bei der Doppel cc1101 Platine der Abstand zwischen den beiden Antennen zu gering ist,
der Abstand zwischen den Antennen ist dann ca 7-8 cm. Ist dieser Abstand gross genug, damit beim Empfang die Beeinträchtigungen zwischen den beiden Antennen weniger werden?
Davon gehe ich aus. Aber wenn du mehr Abstand willst kannst du ja auch einfach die beiden nebeneinander liegende um 180 grad drehen. Denke das ist ebenfalls gut  genug. (Ich gehe da von abgewinkelten Antennen aus)
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!