Moin Moin,
Ich stehe hier vor einem kleinen Problem.
Ich habe hier 2 Atmegas 328 die über 2 Enc28j60 mit dem Netzwerk
verbunden sind.
Der eine Misst die Temperatur und gibt dann, wenn ein bestimmter
Sollwert erreicht ist auf seiner Website "Status1" bzw. "Status0" aus,
der 2. Atmega schaltet dann ein Relais. Das ganze funktioniert so weit
auch ganz gut. Nur möchte ich noch 2 weitere Buttons einfügen, die GPIO
Pins am Server High bzw. Low schalten.
Das überschreitet aber anscheinend die Größe der const char "reply" des
Clients.
Bis 3 Buttons geht es gerade so noch, darüber werden die Daten zwar
empfangen, aber das Relais wird nicht mehr geschalten.
Ich habe versucht den Text auch schon maximal zu kürzen, für einen 4.
Button reicht es nicht :-(
Gibt es eine möglichkeit die Buttons oder die "Homepage" noch weiter zu
kürzen, damit der Inhalt der char nicht "überschritten" wird?
Danke und Viele Grüße
Peter
Das sind ungefähr 420 Zeichen zuzüglich die beiden Werte für $D.
Der Mikrocontroller hat insgesamt 2kB RAM. Da kann es durchaus sein,
dass die Grösse deines Pufferspeichers schon überschritten hast. In
diesem Fall wirst du deine Sendung wohl in mehrere Pakete aufteilen
müssen, das ist ja auch der Haupt-Zweck von TCP (verglichen mit UDP).
Wie gross ist denn der Puffer?
Peter H. schrieb:> Danke für die Antwort, meinst Du das hier:> byte Ethernet::buffer[700];
Sieht danach aus. Genaueres kann ich Dir dazu auch nicht sagen, weil ich
deine Software nicht kenne.
Bedenke, dass in die 700 Bytes auch noch der Ethernet Header rein muss.
Hmm ok.
Ich habe auch mal versucht die Zahl nach oben zu setzen, auf 1000,
leider noch ohne Erfolg.
Das komische ist ja eigentlich, dass der Teil "Status1" bzw. "Stauts0"
immernoch beim Client ankommt. Das kann ich im Seriellen Monitor sehen.
Nur ab einem bestimmten Teil wird der Rest abgeschnitten und die "Reply"
irgendiwie nicht mehr durchsucht und somit auch kein "Stauts1" bzw.
"Status0" gefunden.
Der Server:
Manchmal muss man eben eine Nummer größer benutzen.
Gerade im Low-End Arm Bereich gibt es Prozessoren mit mehr Ram, die
nicht viel teurer sind.
ST-Development Boards gibt es bereits ab 10 Euro.
Ein ESP32 hat 512 KByte Ram, Wlan und kostet auch nur 10 Euro. Das
bringt vielleicht mehr, als eine verkrüppelte Webseite, weil man nur
2KByte Ram auf dem Atmel hat.
Liegt das wirklich am Ram?
Ich konnte den Buffer bis auf 1300 erhöhen, aber das Relais mag immer
noch nicht anziehen. Die Antwort kommt "Status1" oder "Status0" kommt ja
auch an.
Da muss sicher mehr angepasst werden, als diese eine Zahl. Ausserdem
bekommst du einen Stack-Überlauf (Absturz) wenn du den Puffer zu gross
machst.
Selbst wenn du den Puffer jetzt grösser machst, wirst du bald wieder an
seine Grenzen stossen. Mehr als 1,4kB ist über gewöhnliche Internet
Anschlüsse sowieso nicht möglich.
Finde einen Weg, mit dem Puffer aufzukommen - also deine HTML Dokumente
in mehreren Stücken zu senden.
Moin, moin,
die 700 Byte waren ja gar nicht mal so schlecht.
Ich würde mir als erstes mit Wireshark ansehen, was hin und her gesendet
wird.
Viele Grüße
Paul
Hau Wech schrieb:> Mehrere Pakete :>> if ( bfill.emit_p(PSTR( "Etwas Text" )) ) {> bfill.emit_p(PSTR( "Mehr Text" )) ) ;> } else {> bfill.emit_p(PSTR( "Fehlercode 1" )) ) ;> return -1;> }>>> Ich bin leider nur "Hacker" , kein Programmierer ..
Hmm irgendwie mag er nicht...
Egal wie ichs drehe, ich bekomms nicht hin, immer wieder andere
Fehlermeldungen...
Solange du die Fehlermeldungen nicht zitierst und nicht deinen gesamten
Quelltext zeigst, können wir Dir kaum helfen. Dann müssen wir genau so
blöd herum raten, wie du.
Fehlermeldung:
could not convert 'bfill.BufferFiller::emit_p(({...}), t, Tsoll,
Status)' from 'void' to 'bool'
Zeile ist: "t, Tsoll, Status)"
Das komische ist ja, dass ich die Website viel größer machen kann. Am PC
wird das auch so dargestellt, nur der 2. Atmega hat Probleme das
auszuwerten oder so.
Wenn du die Definition von emit_p() suchst, wirst du feststellen, dass
dessen Rückgabewert void ist.
Dein Programm erwartet allerdings bool.
Der fatale Fehler ist damit berechtigt.
Du fragst mit if() das Ergebnis von bfill.emit_p() ab, aber diese
Funktion liefert gar kein Ergebnis!
Bist du sicher, dass du sie einfach so mehrmals hintereinander aufrufen
kannst, ohne zu warten, bis der buffer gesendet wurde?
Peter H. schrieb:> could not convert 'bfill.BufferFiller::emit_p(({...}), t, Tsoll,> Status)' from 'void' to 'bool'
Offenbar ist die Funktion emit_p() vom Typ void, gibt also keinen Wert
zurück. Du fragst aber mit "if" den Rückgabewert der Funktion ab.
Was hat das jetzt mit der Größe des RAMs zu tun? Richtig, gar nichts.
> Am PC wird das auch so dargestellt, nur der 2. Atmega hat> Probleme das auszuwerten oder so.
Was wertet der 2. Atmega denn aus? Noch hast du uns gar nicht erklärt,
wie deine Schaltung aussieht und welche Kommunikationsbeziehungen
bestehen. Zudem fehlen immer noch Schaltplan und Quelltext.
Wer Hilfe erbittet, muss die dazu nötigen Infos bereit stellen. Sonst
wird das nichts.
Also die Seite aktualisiert sich ja von selbst, 1 mal die Sekunde.
Dann funktioniert ja die ganze Idee vom "Hacker" nicht...
Quelltext müsste oben sein, einmal vom server, und einmal vom Client.
Also ich denke immernoch dass das an der char "reply" am Empfänger
liegt. Weil am PC lässt sich die seite ja darstellen und alle GPIO Pins
am Server lassen sich ja schalten, Temperatur wird auch dargestellt.
Müsste man dann die Website am Client auf "2 mal einlesen"?
Waren Abblock-Kondensatoren gerade Mangelware?
An die Reset Pins gehören auch Kondensatoren.
Aref gehört nicht mit VCC kurzgeschlossen. Lies die entsprechenden
Hinweise im Datenblatt!
Was funktioniert jetzt nicht, die Darstellung der Webseite im Browser
oder das Schalten des Relais im Empfänger? Wie kommunizieren die beiden
Mikrocontroller miteinander?
Inwiefern weicht die fehlerhafte Kommunikation vom Soll ab? Oder ist die
Kommunikation gar nicht gestört sondern es scheitert an etwas anderem?
Hast du eine Möglichkeit, Debug Meldungen auszugeben? Wenn nicht, dann
solltest du das bei beiden Mikrocontrollern schleunigst hinzufügen. Und
lerne, mit Wireshark umzugehen.
Wir sehen uns dann wieder, wenn du die Fehlerursache mit diesen Mitteln
eingekreist hast. Bis dahin empfehle ich hier eine Sendepause für alle,
denn wilde Vermutungen enden erfahrungsgemäss in wüsten Beschimpfungen.