Hi,

ich habs aber genau anders herum:

Code:

#include <SPI.h>
#include <Ethernet.h>
#include <EthernetUdp.h>
#include <EEPROM.h>

#define UDP_TX_PACKET_MAX_SIZE 30

Und so erscheint es mir auch logischer. Denn so ist die (für mich richtige) define-Anweisung die letzte.

Die Frage ist nur, ob man define mit define übeschreiben darf.

Hmm ich hab jetzt mal die #define Zeile spasseshalber im Programm ganz am Anfang noch mal deklariert.

Code:

#define UDP_TX_PACKET_MAX_SIZE 30

Und es geht.......

Sollte es so einfach sein?

Hi,

gibt es eine Möglichkeit eine #define-Zuordnung aus einer lib im Anwenderprogramm zu überschreiben, oder muss ich da die Lib abändern.

Grund der Frage:
In der Ethernet-Bibliothek wird die Maximale Framegröße mit 24 byte definiert. Ich bräuchte aber 26 

Code:

#define UDP_TX_PACKET_MAX_SIZE 24

Wenn ich es in der lib abändere, dann hab ich halt jedesmal das Problem, dass ich bei einer neuen Version das wieder nachziehen mus. Und wenn ich es vergesse, dann mault der Compiler nicht, und ich such mir dann den A... ab, wieso das Programm so seltsam reagiert.

Ich glaube, wir beenden den Thread an dieser Stelle.

Udo !!!!!!!!!!!!!!!!!

17 (siebzehn) x ! (wenn ich richtig gezählt habe)

Code:

for (byte n = 0; n < 12; n++) {
  ?
}

Und wer schreibt den Compiler für den Threadtitel ?(??)

es gibt ja die kurzschreibweise : 12x?   

Aber das sieht eher nach Platzhalter aus...

[is]

Hi,

There is a well-known bootloader bug with using "!!!" with certain early versions of the Mega.

Gibts da ein Update ohne das Problem?
Bei der version 1.0.4 soll ja der Bootloader des Mega verbessert worden sein.

Remove the "!!!" and the problem may go away.

It is away.

An die anderen:
Mir war halt nach 12 Fragezeichen. Das entspricht vom Gefühl her der Zeit, die ich nach dem Fehler gesucht habe.
Könnt froh sein, dass ich nicht länger gesucht habe     

Gut zu wissen, dass es solch einen Bug gibt.

Multiple exclamation marks are a sure sign of a diseased mind

Na dankeschön.

Hi,

mir ist jetzt gerade Folgendes aufgefallen:

Ich habe in einem Sketch folgenden Zeile verwendet:

Code:

      Serial.println("Eeprom Schreibvorgang!!!");

Damit konnte ich keinen Upload mehr auf den Arduino machen. Ist ewig bei uploaden hängen geblieben.
Wenn man bei Einstellungen die Ausführliche Ausgabe während Upload aktiviert hat, kam im Debug-Fenster immer was von ....huh bootloader....

Schuld daran sind definitiv die 3 Ausrufezeichen.
Sobald ich eines der 3 Ausrufezeichen entfernt habe, konnte man den Sketch wieder runterladen.

Kompilieren ging mit beiden Varianten!
Probierts mal einer aus, ob er den selben "Erfolg" hat????
Ich verwende IDE 1.01 auf Arduino Mega2560

Hi,

hab schnell mal einen CrashCurs zu Pointern durchgezogen. Internet sei Dank

Ich hab mir jetzt folgende Funktion gestickt:

Code:

unsigned long Eeprom_Read_LongInt (unsigned int addr)
{
      unsigned long result;
      byte *ptr = (byte *)&result;
      byte i;

      for (i=0;i<4;i++)
          *(ptr++)=EEPROM.read(addr++);
      return result;
}

Gefällt mir ganz gut.
Hab damit aber ein Low-Byte/High-Byte Problem, da die Daten über meine erste Funktion genau andersrum abgespeichert werden.

Ok. Das ist jetzt Definitionssache, wie rum man das jetzt speichert.
Irgendwie schreit ja alles danach, die Zahl so im Eeprom abzulegen, wie es auch im RAM erfolgt. Also das höchste Byte auch in der höchsten Adresse des Eeprom.
Allerdings hab ich eine Funktion, die mir einen HexDump des Eeprom (immer 8 Byte nebeneinander, viele Zeilen untereinander) ausgibt. Da liest es sich natürlich schöner, wenn die LongInt genau andersrum abgespeichert wird.

Was meint ihr dazu?

In diesen beiden Zeilen:
byteArray[0] = (int)((longInt >> 24) & 0xFF) ;
byteArray[1] = (int)((longInt >> 16) & 0xFF) ;
müßtest Du natürlich auf (long) typecasten statt auf einen vom Typ her zu kurz gegriffenen (int).

Bist du dir da sicher? Dieser Teil funktioniert ja. Ich sehe im Eeprom die richtigen Werte.
Was nicht klappt ist das Zurückwandeln von dem bytearray ins longinteger Format

Wenn es auf Geschwindigkeit ankommen würde (was in dem Fall natürlich nicht zutrifft, das langsamste ist sowieso das Schreiben ins Eeprom), dann würde ich direkt per Pointer auf die vier einzelnen Bytes zugreifen.

Oh ja die Pointer.....
Hab auch schon in die Richtung gedacht. Der LongInteger Wert steht ja bereits im 4 Byte-Format irgendwo im RAM
Wenn man den dann irgendwie mit longInt.byte(0) etc. lesen bzw. schreiben könnte.
Also irgendwie so:

                  unsigned long int longInt;
             for (int i = 0; i < 4; i++){
             longInt.Byte(i) = EEPROM.read(i);
         }

Aber dazu kenn ich mich leider mit Pointern auf C zu wenig aus 
(Das in Rot ist nur eine Denkweise)

Hi,

ich möchte unsigned long int Werte so in 4 Bytes zerlegen, dass ich diese direkt ins Eeprom schreiben kann.
Im Inet habe ich dazu folgenden Code gefunden:

Code:

         unsigned long int longInt = 1234567890;
         unsigned char byteArray[4];
                     
         // convert from an unsigned long int to a 4-byte array
         byteArray[0] = (int)((longInt >> 24) & 0xFF) ;
         byteArray[1] = (int)((longInt >> 16) & 0xFF) ;
         byteArray[2] = (int)((longInt >> 8) & 0XFF);
         byteArray[3] = (int)((longInt & 0XFF));

          for (int i = 0; i < 4; i++){
          EEPROM.write(i,byteArray[i]);
          }

Das funktioniert auch. Als Ergebnis erhalte ich: "49 96 02 D2" (als hex-Werte)


Wenn ich die Werte wieder auslesen will und in ein long-Integer wandle:

Code:

         unsigned long int longInt;
         unsigned char byteArray[4];
         
         for (int i = 0; i < 4; i++){
             byteArray[i] = EEPROM.read(i);
         }
         // convert from a 4-byte array to an unsigned long int
         longInt = ( (byteArray[0] << 24)
                   + (byteArray[1] << 16)
                   + (byteArray[2] << 8)
                   + (byteArray[3] ) );

        Serial.println(longInt);

Da bekomme ich dann als Resultat den Dezimalwert 722. Dies ist in HEX: "02 D2". Also die beiden letzten Byte.

Was mach ich da falsch?
Oder habt Ihr evtl. noch eine bessere Methode für meine Aufgabenstellung?

Geuß/hk007

???
Kann man was?

Ja, hab ich auch nicht so verstanden was ich in dem Link finden soll 

Hi,

ich habs jetzt so gemacht wie von michael_x vorgeschlagen:

Code:

R<0000,1024>

Über das "R" erkenne ich die Funktion, und die beiden Werte stecken dann in den Zeichen 2-5, sowie 7-10.
Also Protokoll mit fester Länge.

Danke an alle/hk007