Трябва ми да вкарам гъвкавост в софтуера. Гъвкавост във възможно най-много аспекти, т.е. принципно решение, а не решение за конкретен проблем.

Стандартното С/С++ & RTOS е мощно, когато знам какво правя предварително. Но когато трябва динамична функционалност не става. Примерно имам някакво изделие с някакви интерфейси, но различните клиенти имат различни изисквания. Някой казва аз искам като закача това на тоя куплунг да става това и това. Друг иска друго.
Най-добре ако може самия клиент да си намери програмист и той да може да си прави промените сам. Да му давам сорса на С/С++ първо не е добре, втори и да го дам той е огромен, искат подробни документации, искат SDK-та глупости... и накрая често се омотоват щото то се искат месеци на един програмист да навлезе, а не всеки успява...

Скриптът като че ли може да реши подобни проблеми (надявам се). Джабата макар да не е точно скрипт също би било интересно решение. Предимствата е, че е що-годе стандартна. Има готови SDK-та, среди. На теория има много добра производителност, съизмерима с С/С++.
Недостатъците са:
1) много време ще изгубя за да направя читав енджин
2) Джабата си е език за програмиране, демек за програмисти щото се пише с класове и т.н. Докато един обикновен скрипт е контекстно независим, пише се по-лесно и от повече хора.
3) Самата джаба е стандарт, обаче за да има смисъл от тоя стандарт трябва да поддържам и стандартните модули и клас библиотеки. С други думи един гол енджин е нищо. Но пък за модулите ще се изгърча още повече а и повечето от тях са твърде обемисти и лакоми за ресурси. Демек от стандарта ще ми остане само джаба синтаксиса, а точно той най-малко ми харесва от самата джаба.

От друга страна имам идея как да подкарам прост скрипт, с възможност за паралено изпълнение, няма да има нужда и от много ресурси.... Но ще е моя измишльотина, а това не е предимство за клиентите

Ами на това му викат LADDER. И аз от доста време обмислям нещо такова, ама и аз не съм го измислил. Но освен, че опираме до: 1), струва ми се че и хардуера ще се усложни доста, и тогава тея дето искат да си качат което където си искат, ще решат че не искат да е точно така, щото вероятно цената няма да им се понрави. Та, не ме разбирай погрешно, и аз си падам по универсалните неща...

uCLinux става ли за нещо? Пише че е портвано за арм7, ама кое-как...

Е точно на това не му викат ladder.

Луната я споменах мисля... както и да е, това е една от опциите.

Ладдер - не ми харесва
uCLinux - не става

То и на мен не ми харесва LADDER, ама то сигурно е щото сме програмисти. Питай обаче един потребител. Пък и тук не става въпрос ти да пишеш на това, ти трябва да направиш компилатор за него.

Не го познавам тоя ладдер, но не ми звучи като подходящо средство... Не правя автоматика

Miro,
Каква е тази луна за която говориш? Дай някакво инфо или линк.

www.lua.org

www.eluaproject.net

http://developer.berlios.de/projects/elua/

Аз виждам няколко варианта, LUA е подходящо за такива места, доказано бърз процесор е, ползва малко ресурси, що годе лесен за интегриране и ползване. Като чета, проблема не е толкова във производителността...която така и така ще падне след вграждането на такъв процесор, проблема е в абстрахиране на работещия код от основата (RTOS)...това не виждам как ще стане еднакво добре на 8051 и ARM, ще трябва да се спреш на нещо конкретно. Напоследък Python доста сериозно се налага като скриптов език - http://wiki.python.org/moin/PyMite например, малко ограничена версия, но човека го е тикнал в 8 бита архитектура.

За мен дилемата е между Java2 Micro или скрипт, но това ще го умуваме с колегите, демек не зависи само от мен..,

Ако е джаба е ясно, там ще се гони стандарта, иначе няма много смисъл от нея... Ако е скрипт обаче не е толкова важно какъв ще е. Естествено, синтаксис и основните неща ще ги откраднем от някъде, я от Луната, я от джабаскрипт. Няма смисъл да се открива топлата вода.

По всяка вероятност обаче няма да ползваме готова имплементация, а ще си спретнем нещо наше. Причините са две.
Първо многозадачността в скриптовете не ми харесва много. Всъщност има различни идеи, но са пръснати. Примерно PHP има интересен подход (лесен), но само при някои неща. Луната е с coroutine-и, което по принцип става, има и интерфейс към С/С++ и той става, абе като цяло нещата "стават", ама може и много по-добре
Другата причина е начинът по който са направени. За да постигнат универсалност, те ползват едва ли не само чисто С, не разчитат на РТОС и т.н. Аз обаче имам РТОС и искам той да се грижи за многозадочността, вместо да пусна в една нишка интерпретатора и той да симулира многозадачност. Въпросът не само в ефективност и в предпочитания. Аз имам драйверна система която е предвидена да работи с клиенти от различни нишки. В една нишка ще имам проблем да вкарам всичко. Освен това имам класове като CString, който е предвиден да бъде threadsafe и с него много лесно ще направя общи променливи между скриптове в различни нишки.
С две думи за да ползвам това което имам ще трябва сам да си напиша интерпретатора.... И тъй като вече неща като парсване и лексикален анализ сякаш ще ми е по-лесно да го направя от нула, отколкото да тръгна да преправям нещо готово като eLua.