Einwurf: Das mit der Network-Order ist solange eine Sache der oberen Fuzzies, solange wir da unten eh nur Bytes handeln. Gibt es aber Bestandteile , die mehr als 8 Bits haben (Adressen) müssen wir uns darum kümmern, bzw. eben einfach festlegen.
Das mit der Länge ist praktisch, wenn man beim Empfang einfach sagen könnte, in den nächsten x-Bytes kann kein Steuerzeichen sein.
ABER grad beim µC wird es vorkommen, daß er dieses oder jenes Zeichen einfach nicht mitkriegt. Es muß also trotzdem aufpassen, ob nicht mitten in seinem Frame vielleicht doch ein neues Frame beginnt.
D.h. IMHO, drüber gelegt muß auf jeden Fall eine STX /ETX Kontrolle sein. Ein Längenbyte könnt' aber durchaus das BCC ersetzen, da ja Länge & ETX zusammenpassen müssen.
Ein Länge vorne würde aber a priori einen Frame-build on-the-fly unmöglich machen.
Paketlänge: Die Zeit ist u berücksichtigen. Bei 9600 brauch er für hundert Byte ~0.1 SEKUNDEN. Das ist lange genug, wenn zwischendurch ein Alert auftritt.
Denkt an die Möglichkeit Flag:MORE, d.h. es wird gesagt, daß die Daten des nächsten Pakets zu diesem bei gleicher Adresse dazugehören. Das macht ja IP auch so.
Und für Bildbearbeitung ist UART sowieso eher sub-optimal.
Also eine Restriktion auf Framesize 127 scheint sinnvoll und eigentlich zumutbar.
Ein Atmega32 kann damit in 16 Frames seinen kompletten SRAM schicken. (samt dem Stack)

EDIT: DIe maximale Framesize ist aber typischerweise eines der Dinge, die bei den Negotiations auszuhandeln sind