Sketch zu groß

Hi,

hab hier einen (ungetesteten) Sketch, mit dem ich gerne einen ATtiny85 beschreiben würde.

Leider erscheint beim Kompilieren folgende Fehlermeldung:

Der Sketch verwendet 3.096 Bytes (151%) des Programmspeicherplatzes. Das Maximum sind 2.048 Bytes.
Globale Variablen verwenden 379 Bytes (296%) des dynamischen Speichers, -251 Bytes für lokale Variablen verbleiben. Das Maximum sind 128 Bytes.
processing.app.debug.RunnerException: Der Sketch ist zu groß; unter http://www.arduino.cc/en/Guide/Troubleshooting#size finden sich Hinweise, um die Größe zu verringern.
** at cc.arduino.Compiler.size(Compiler.java:336)**
** at cc.arduino.Compiler.build(Compiler.java:159)**
** at processing.app.SketchController.build(SketchController.java:643)**
** at processing.app.Editor$BuildHandler.run(Editor.java:1795)**
** at java.lang.Thread.run(Thread.java:745)**
Der Sketch ist zu groß; unter http://www.arduino.cc/en/Guide/Troubleshooting#size finden sich Hinweise, um die Größe zu verringern.

Die myTx.send()-Funktionen scheinen das Hauptproblem zu sein.

Besteht aus Eurer Sicht die Möglichkeit, dass dieser Sketch in abgewandelter Form seinen Weg auf den o.a. Prozessor finden können wird und falls ja, wie?

Gruß Chris

/* ATtiny85 as an I2C Slave
   ATtiny I2C slave receiving data
   Gets data from master
   SETUP:
   ATtiny Pin 1 = (RESET) N/U                      ATtiny Pin 2 = (D3) N/U
   ATtiny Pin 3 = (D4) to LED1                     ATtiny Pin 4 = GND
   ATtiny Pin 5 = I2C SDA on DS1621  & GPIO        ATtiny Pin 6 = (D1) to LED2
   ATtiny Pin 7 = I2C SCK on DS1621  & GPIO        ATtiny Pin 8 = VCC (2.7-5.5V)
   NOTE! - It's very important to use pullups on the SDA & SCL lines!
   Current Rx & Tx buffers set at 32 bytes - see usiTwiSlave.h
*/

#include "TinyWireS.h"                  // wrapper class for I2C slave routines
#include <RCSwitch.h>

#define I2C_SLAVE_ADDR  0x26            // i2c slave address (38)

#define FIFOSIZE 16                     // Einmalig festgelegte Puffergröße
char fifo[FIFOSIZE];                    // Der Puffer an sich (in diesem Fall ein char-Array)
byte fifoWriteIndex = 0;                // Schreibindex
byte fifoReadIndex = 0;                 // Leseindex

// 433MHz Modul

RCSwitch myTx = RCSwitch();

const byte txPin =    4;                 // Ausgang Sender-Daten (IC-Pin 3)
const byte sendCnt = 3;                 // max. Anzahl der Aussendungen

void setup()
{
  TinyWireS.begin(I2C_SLAVE_ADDR);      // init I2C Slave mode
  pinMode (txPin, OUTPUT);              // 433MHz Modul
  myTx.enableTransmit(txPin);
  myTx.setPulseLength(375);             // Pulsweite
  myTx.setRepeatTransmit(10);           // Anzahl der Wiederholungen beim Senden innerhalb der Library
}

void loop()
{
  i2cToFifo();                            // I2C nach Fifo
  fifoToTx();                             // Fifo nach 433MHz Sender
}

void i2cToFifo()
{
  if (TinyWireS.available()) fifoWrite(TinyWireS.receive());     // Vom Mega angekommenes Zeichen in den Puffer schreiben
}

void fifoWrite(char c)                                                              // Schreibfunktion
{
  fifo[fifoWriteIndex] = c;                                                         // Schreiben des eingehenden Zeichens an die aktuelle Indexposition
  c = fifoWriteIndex;                                                               // Aktuelle Indexposition zwischenspeichern (in diesem Fall im c char um Speicherplatz zu sparen)
  fifoWriteIndex++;                                                                 // Indexposition inkrementieren
  if (fifoWriteIndex >= FIFOSIZE) fifoWriteIndex = 0;                               // Wenn das Ende des Puffers erreicht wird, die Schreibposition auf den ersten Index setzen
  if (fifoReadIndex == fifoWriteIndex) fifoWriteIndex = c;                          // Schutzfunktion, wenn mehr Zeichen in den Puffer geschrieben werden sollen, als dieser fassen kann
}

void fifoToTx()
{
  char c;
  if (fifoAvailable())                  // Sobald sich mind. ein Zeichen im Puffer befindet, diesen auslesen
  {
    c = fifoRead();                     // Befehl aus Puffer lesen
    for (int i = 0; i < sendCnt - 1; i++)
    {
      switch (c)
      {
        case 'A': // Funksteckdose 1 an // Heizkörper Bad OG
          myTx.send("000101010001010101010111");
          break;
        case 'a': // Funksteckdose 1 aus
          myTx.send("000101010001010101010100");
          break;
        case 'B': // Funksteckdose 2 an // Wlan Bad EG
          myTx.send("000101010100010101010111");
          break;
        case 'b': // Funksteckdose 2 aus
          myTx.send("000101010100010101010100");
          break;
        case 'C': // Funksteckdose 3 an // Leselampe
          myTx.send("000101010101000101010111");
          break;
        case 'c': // Funksteckdose 3 aus
          myTx.send("000101010101000101010100");
          break;
      }
    }
  }
}

boolean fifoAvailable()  // Diese Funktion prüft, ob sich ein neues Zeichen im Ringbuffer befindet
{
  return (fifoReadIndex != fifoWriteIndex); // Ein neues Zeichen befindet sich im Ringbuffer wenn (fifoReadIndex != fifoWriteIndex)
}

char fifoRead()                                                                     // Lesefunktion
{
  char c;                                                                           // Zeichen initialisieren
  c = fifo[fifoReadIndex];                                                       // Zeichen aus Ringbuffer lesen
  fifoReadIndex++;                                                                  // Leseindex um eine Stelle erhöhen
  if (fifoReadIndex >= FIFOSIZE) fifoReadIndex = 0;                                 // Beim erreichen des Arrayendes den Leseindex auf null zurücksetzen
  return c;                                                                         // Zeichen zum Abschluss aus der Funktion übergeben
}

Ähm - ATtiny85? Ich glaube dass die Board-Einstellung falsch gewählt ist. Der ATtiny85 hat 8 kByte Flash und 512 Byte SRAM und müsste demnach einen 3 kByte Sketch mit 379 Bytes SRAM-Verbrauch aufnehmen können.

Ein attiny85 hat 8kB Flash und 512 Byte RAM.

Als digispark blieben dir neben dem Bootloader 6.012 Bytes frei. Nackt ohne Bootloader reichliche 8 kByte

Mit 2048 byte Flash und 128 Byte RAM hast du evtl. einen attiny2313 oder so ausgewählt?

myTx.send("000101010001010101010111");

ist natürlich fette RAM-Verschwendung

RudiDL5:
Ich glaube dass die Board-Einstellung falsch gewählt ist.

Ja, cool! So ist es. Nun sieht's etwas besser aus. :slight_smile:

michael_x:
myTx.send("000101010001010101010111"); ist natürlich fette RAM-Verschwendung

Wie geht es denn weniger verschwenderisch?

Gruß Chris

hi,

sende es als drei bytes...

gruß stefan

Chris72622:
Wie geht es denn weniger verschwenderisch?

Nur frage ich mich, warum du Binäcode sendest und nicht als dezimal ?

Beispiel:

myTx.send(5393, 24);

Das sieht doch auch übersichtlicher aus und braucht auch deutlich weniger Ram.
Dann das Ganze schön in ein Array und alles ist perfekt. :wink:

long TXCode_ein[ ] = { 5261000, 5261001, 5261002 };     // Funksetckdosen einschalten

HotSystems:
Nur frage ich mich, warum du Binäcode sendest und nicht als dezimal ?

Weil der Beispielsketch "ReceiveDemo_Advanced" aus der rc-switch Library mir Folgendes angezeigt hat, als ich z.B. eine der Tasten meiner Fernbedienung gedrückt habe:

Decimal: 1381719 (24Bit) Binary: 000101010001010101010111 Tri-State: 0FFF0FFFFFF1 PulseLength: 375 microseconds Protocol: 1

Ich dachte, es wäre lediglich eine Sache der Darstellung.

Gruß Chris

Chris72622:
Weil der Beispielsketch “ReceiveDemo_Advanced” aus der rc-switch Library mir Folgendes angezeigt hat, als ich z.B. eine der Tasten meiner Fernbedienung gedrückt habe:

Decimal: 1381719 (24Bit) Binary: 000101010001010101010111 Tri-State: 0FFF0FFFFFF1 PulseLength: 375 microseconds Protocol: 1

Ich dachte, es wäre lediglich eine Sache der Darstellung.

Wie du siehst, nicht nur der Darstellung, auch der Speicherverschwendung. :wink:

Beispiel:

2 mal senden auf dezimal = 204 Byte für kompletten Sketch und in Binary 254 Byte !
Das solltest du mal prüfen.

Nimm Dezimal !

Alles klar, danke!

Gruß Chris

Chris72622:
Alles klar, danke!

Nur mal zum Vergleich.
Dein obiger Sketch brauch 394 Byte Ram.
Als Dezimal nur 244 Byte.

Es gibt zig Anwendungen für die solche Prozessoren völlig ausreichen. Vor allem wenn man direkt sie direkt in C programmiert. Die Arduino Software geht leider etwas verschwenderisch mit dem Speicher um. Das ist auf dem UNO zwar bemerkbar, aber keine Katastrophe.

Und im Hobby-Bereich spielen ein paar Euro für einen Prozessor keine große Rolle, aber bei Produkten die in Massen gefertigt werden kommt es auf Cents an.

kulturbereicherer:
Eigentlich eine Schande für die Hardware-Entwickler das diese Bausteine immer noch auf C64 Stand arbeiten wo es die Speicherkarten mit zig Gigabyte für wenig Euro gibt.

6 setzen!

Wer solche Sachen abläßt, frisst auch kleine Kinder!

combie:
6 setzen!

Wer solche Sachen abläßt, frisst auch kleine Kinder!

Zusätzlich hat er auch nichts verstanden und sieht seine begrenzte Sicht als den Nabel der Welt..

In Österreich

Bist du so einer?

kulturbereicherer:
Eigentlich eine Schande für die Hardware-Entwickler das diese Bausteine immer noch auf C64 Stand arbeiten wo es die Speicherkarten mit zig Gigabyte für wenig Euro gibt.

Das versteh ich nicht.
Das sollte doch eine Herausforderung für uns sein, auch darauf saubere Projekte zu fertigen.

Dann frage ich, auf welcher Seite die “Schande” sitzt ? :wink:

Das versteh ich nicht.

Ich auch nicht.
Die Hardware-Entwickler haben doch längst was anderes entwickelt bisher.
Ich finde es einen großen Vorteil, dass es immer noch bedrahtete Widerstände und Transistoren zu kaufen gibt, und 8bit-Controller die wahnsinnig leistungsfähig sind, wenn man nicht gerade Bildbearbeitung machen möchte.

Schande gilt höchstens dem Programmierer, der nicht merkt, was er mit "000101010001010101010111"hinschreibt.

Aber 0b000101010001010101010111 oder 0x151557 oder gar dezimal 1381719 ist in C übrigens wirklich kein Unterschied.

michael_x:
Schande gilt höchstens dem Programmierer, der nicht merkt, was er mit "000101010001010101010111"hinschreibt.

Halt den Ball flach. Auch Du bist, wie wir alle, nicht allwissend, mein Freund.

Gruß Chris

Chris72622:
Halt den Ball flach

Einverstanden. Genaugenommen finde ich den Ausdruck "Schande", den Kulturbereicherer eingeworfen hat, daneben. Entschuldige bitte, dass ich ihn weiterverwendet habe.
Die Nachfrage nach der "fetten Verschwendung" ist ja beantwortet.

Schande gilt höchstens dem Programmierer, der nicht merkt, was er mit "000101010001010101010111" hinschreibt.

Och, das kann man auch als "Versagen" bezeichnen.

Wie das immer so ist ... Das Wort Versagen, oder Schande, möchte man nicht hören.
Darum wird dann erstmal der Bote getötet.
Hat den Vorteil, dass es etwas ablenkt.
Und man nicht sofort am eigenen Versagen arbeiten muss, solange der Schuldige/Überbringer noch zuckt.

Typisch Außenpolitik, halt ...