ATmega168 ist schlecht da er noch weniger RAM hat als der 328
Bei network.print("text"); wird der String ins RAM geladen und füllt so ziemlich schnell den RAM
Versuchs mit der F() Funktion:
network.print(F("text")); So wird der String im Flash gespeichert und blockiert kein RAM.
Grüße Uwe
Zusätzlich zum RAM-Problem hat der ENC28J60 das "Problem", das er anders als der WIZNET5100 des Ethernet-Shields, nicht selbst den TCP/IP Stack zur Verfügung stellt. Darum muss sich die Lib auf dem Arduino kümmern.
Das hat zur Folge das bei den meisten Libs bei einer TCP-Verbindung nur ein einziges Antwort-Paket geschickt werden kann und das hat eine begrenzte Größe für die zu sendenden Daten.
Sobald es mehr als ein Antwortpaket gibt, wird es bei TCP schon recht komplex: Transmission Control Protocol – Wikipedia
Leider kenne ich zur Zeit keine Lib für die ENC-Chips, die sich diese Arbeit machen.
ATmega168 ist schlecht da er noch weniger RAM hat als der 328
Bei network.print("text"); wird der String ins RAM geladen und füllt so ziemlich schnell den RAM
Versuchs mit der F() Funktion:
network.print(F("text")); So wird der String im Flash gespeichert und blockiert kein RAM.
Grüße Uwe
Vielen Dank erst mal für den Tipp.
Leider kommt ein Fehler:
network.print(F("This string will be stored in flash memory"));
ethernet1:47: error: invalid conversion from ‘const __FlashStringHelper*’ to ‘int’
ethernet1:47: error: initializing argument 1 of ‘void ETHER_28J60::print(int)’
Mit der enc28j60 library kann man nur ein Paket mit maximal 500 Zeichen (mit anpassung des Buffers 1500 aber nicht mit dem ATmega 168) senden. Es besteht aber die Möglichkeit über ajax weitere Pakete durch den Webbrowser nachladen zu lassen. ich habe das entsprechend umgesetzt. Wenn du willst kann ich den Sketch hier mal Posten.
und wenn network auch print geerbt hat wie Serial, sollte es auch mit network kompilieren.
` warning: only initialized variables can be placed into program memory area` kann man übrigens ignorieren.
Hallo,
Mit Serial.print geht das ganze, jedoch sobald ich network.print nehme geht es nicht mehr.
Leider ist diese Bibliothek nicht sehr clever gebaut. Hier ein Auszug aus der
ETHER_28J60.h:
class ETHER_28J60
{
public:
void setup(uint8_t macAddress[], uint8_t ipAddress[], uint16_t port);
char* serviceRequest(); // returns a char* containing the requestString
// or NULL if no request to service
void print(char* text); // append the text to the response
void print(int value); // append the number to the response
Die Methode "print" ist also fest auf "char*" und "int" verdrahtet. Man könnte evtl. versuchen die Methoden um die Methode "size_t print(const __FlashStringHelper *);" zu erweitern.
Was den Ansatz mit dem
const char a[] PROGMEM = "WebServer";
angeht.
Versuch mal den String beim übergeben auf "char*" zu casten. Das ist zwar kein gutes C, könnte aber klappen.
Also statt "e.print(a)" einfach "e.print((char*)a);"
Hatte leider bei der const char a[] PROGMEM = "WebServer"; Methode nur das Überprüfen gemacht und dachte somit Serial.print(a); würde gehen aber es zeigt nichts in der Konsole an und network.print((char*)a); geht zwar auch ohne Fehlermeldung aber wird ebenfalls nicht angezeigt.
Der Fehler liegt wohl irgendwo in der Definition von const char a[] PROGMEM = "<title>WebServer</title>";
Nein, der Fehler liegt leider in der Ethernet-Lib, die Du verwendest. Diese erweitert nicht, wie die originale Ethernet-Lib die Klasse "Client" und verwendet die Klasse Print für die Ausgabe, sondern implementiert das Ganze leider sehr simple selbst. Damit kann Deine Lib nicht von Hause aus mit Daten aus dem Flashspeicher umgehen.