Autor Thema: Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini  (Gelesen 3344 mal)

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1573
Hat aber den Nachteil, das die EEPROM Emulation 16 Bit Werte schreibt und liest, ich möchte aber 8 Bit Werte schreiben und lesen.
Ich habe noch keine Idee wie ich das hinbekomme. 

Vielleicht hift der Code aus der AskSin++ https://github.com/pa-pa/AskSinPP/blob/master/Storage.h
Die InternalEprom-Klasse nutzt für den STM32 1k des Speichern zum Spiegeln der letzten FlashPage. Gelesen wird das ganze im Konstruktor und gespeichert mit store(). Die selbe Klasse kann auch mit einem AVR verwendet werden und nutzt dann die "normale" Arduino-API.

Im Radio.h ist auch die Anbindung des CC1101 über die SPI-Library drin. Könnte auch interessant sein.
« Letzte Änderung: 13 Januar 2020, 09:03:20 von papa »
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2817
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
SIGNALduino promini (LAN cc1101 + WLAN RXB6), WH3080,  Hideki, Id 7

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1573
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

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2817
Zitat
Eigentlich 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
SIGNALduino promini (LAN cc1101 + WLAN RXB6), WH3080,  Hideki, Id 7

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1573
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
  }

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

Offline Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 880
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.

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1573
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

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2817
Zitat
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).
Danke damit funktionierts.

Zitat
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.
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
SIGNALduino promini (LAN cc1101 + WLAN RXB6), WH3080,  Hideki, Id 7

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1573
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2817
Zitat
Hilft 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
SIGNALduino promini (LAN cc1101 + WLAN RXB6), WH3080,  Hideki, Id 7

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2817
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
SIGNALduino promini (LAN cc1101 + WLAN RXB6), WH3080,  Hideki, Id 7

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2817
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
SIGNALduino promini (LAN cc1101 + WLAN RXB6), WH3080,  Hideki, Id 7

Offline RaspiLED

  • Hero Member
  • *****
  • Beiträge: 2340
  • Es begann alles so klein ;-)
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, ...

Offline Ranseyer

  • Hero Member
  • *****
  • Beiträge: 1630
    • Homepage
Zitat
Kann 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)
« Letzte Änderung: 16 Januar 2020, 20:27:50 von Ranseyer »
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!

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2817
Zitat
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".

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
SIGNALduino promini (LAN cc1101 + WLAN RXB6), WH3080,  Hideki, Id 7