Hi,
Dein Patch ist mir syntaktisch zwar nicht ganz klar, aber wahrscheinlich ist es sinnvoller die Basisinformationen in einem Bitfeld zu vereinen.
Deine Aussage ist mir semantisch nicht ganz klar. Aber ich habe den Patch etwas modifziert, sodass er auch mit C++03 kompiliert und sich nur auf den Scheduler und die Activity beschränkt. RAM-Ersparnis auf dem atmega: 2 Byte pro Aktivität. Bei 25 Aktivitäten und 1KiB RAM ist das nicht unbedeutend.
Nachvollziehen kann ich nicht, dass es weniger Code produziert. Und da
Möglicherweise nur weniger Code auf dem atmega, da dort uint16-Zugriffe generell mehr Code erzeugen als Operationen auf uint8. Enums werden bei C++03 immer auf mindestens 16Bit Datentypen abgebildet, da lohnt sich die Verkleinerung bei 8Bit-Architekturen.
Aber letztlich ist es doch eine Interessante Anforderung, eben Reflex auch für wirklich kleine Plattformen verwenden zu können. Ist das wirklich so ein verlorener Gedanke oder ist der Aufwand es klein und für mehrere Plattformen anbieten zu können abwegig?
Der Aufwand steigt immer dann immens, wenn man dem Perfektionsnismus fröhnt. Ich halte es für ein ehrenwertes Ziel, den REFLEX-Kern modellieren zu wollen, aber wieviel Freizeit würdest Du dafür opfern? Oder siehst Du etwa einen Weg, Deinen Arbeitgeber dafür zu begeistern?
Letztendlich ist REFLEX doch auch ohne modellierten Kern benutzbar. Viel lohenswerter halte ich die Modellierung von Anwendungen. Hat dafür jemand Geld übrig?
Richard
