hallo !

ich meine auch dass man so viel wie möglich an aufgaben in einer autarken e2000-net-io abbilden sollte und das ist ja auch die stärke des designs

er ist eine parametrisierte zustandsmaschine (m.a.w. ein intelligenter regler) der autonom und in echtzeit agiert
aber er eignet sich nicht zum speichern grosser datenmengen

er kann nur relativ wenige (akkumulierte) registerwerte halten die einen momentanen zustand auf der t-achse widerspiegeln aber er muss diese momentanwerte auch ganz schnell und zuverlässig wieder vergessen können da einfach nicht soviel platz da ist bzw. die kostbare cpu-zeit zu was anderem verwendet werden muss als vllt. nachträglich gigabyte von messwerten (batchmässig) übers netz loszuwerden

relative komplexe aufgaben die sinnvollerweise auch noch woanders stattfinden sollten sind :

- mails & sms versenden d.h. die ganze benachrichtigungdinge
- messergebnisse zur weiteren verarbeitung aufbewahren
- korrelationen, regressionen und visualisierungen
- statistiken und auswerten

dazu muss eben ein "backing server" existieren der diese ko-aufgaben wahrnimmt und von wo man auch (wie ein mensch über das webinterface) script- und programmgesteuert langsam und bedächtig was vorgeben, umstellen und auslesen kann

ich möchte nochmals betonen : natürlich sollte der e2000 wenn es der user wünscht vollkommen autonom und OHNE jeglichen "co-server" arbeiten können -
ich kann aber aus meiner erfahrung aber nur sagen : wenn man den e2000 wirklich toll einsetzen will in der messtechnik oder als alarmanlage oder als ECHTES GOODIE das nicht im autistischen bereich verbleibt -
der muss dann auch

DAS KOMMUNUKATIONSDESIGN ist also :

1) von zeit zu zeit setzen der parametrierung & abfrage aller inneren zustände (blocking & nonblocking ; externes polling)
2) OPTIONAL : schnelles verlässliches "loswerden" von daten & kritischen zustandsmeldungen in richtung "backing server"
(fire & forget)

wobei 2) nicht ganz so einfach ist, denn das "forget" muss gewisse kriterien erfüllen :
2a) es muss eine schnelle interaktion sein die
2b) wenig protokoll-overhead hat und wo man
2c) sich möglichst wenig um fehler in der kommunikation kümmern muss : solange kein fehler zurückkommt ist das ding gesendet und alles ok

genau für diese sachen gibt es einen terminus : "message passing"

weder tcp noch udp taugen für sowas und diese funktionalität muss daher folgendermassen konstruiert werden :

A) ein neues protokoll ;-))
d.h. wenn man gut drauf ist lautet das zauberwort : sctp

windows : http://www.bluestop.org/SctpDrv/doc/index.html
linux : sowieso ;-))
mega644-toolchain : nunja ich nehme nicht an dass ihr mit der naked gnu-toolchain arbeitet sondern mit einem avr-studio 4 oder eher 5 ;-)) was in source vorhanden ist (d.h. in linux) geht auch da rein - keine frage

B) ein "lightweight message-passing"-framework :

das macht all das zerhacken & zusammenbauen & der resend & die fehler & ....
(ironischerweise basieren etliche auf sctp *gg* ...)

B1) 0MQ (zeromq)
http://www.cs.cmu.edu/~srini/15-441/F11/lectures/r13-0mq.pdf
http://zguide.zeromq.org/page:all
https://lwn.net/Articles/370307/

gibts für windows,linux,...

hoffe das sind mal ein paar anstösse einer soll-architektur
die ist-architektur & -implementierung ist ja meist etwas anderes
aber schlechte implementierungen gibt es schon zu viele

lgwp