искам да вкарам малко разнообразие, че напоследък само бира се коментира тук

Значи къв ми е проблема... с две думи: отесня ми архитектурката и ми трябват свежи идеи

Нека поясня що е туй "архитектура" а пък вие ще ми кажете има ли почва у нас... Под архитектура разбирам "калъп". Всеки софтуер се шие по някакъв калъп, особено когато се прави от няколко човека и е по-обемист както е в моя случай. Калъпът позволява да се ориентираш в чуждия код или в добре забравения твой код. Когато калъпът е добър, лесно може да се ориентираш. Само гледаш "абе туй като онуй, ахъ значи ясно какво прави тоя код"... Улеснява се и писането, щото заданието го вкараш в някакъв "калъп" и после програмирането става занаятчийска дейност както казваше един колега.
Тва е накратко... не знам дали съм го обяснил добре, щото повечето колеги с гордост твърдят "аз не бачкам по калъп, всяка задача я правя според изискванията". Да, ама като им погледнеш работата веднага се вижда някакъв стил (ако са добри) и често срещани примитиви. Те тва за мен пак си е "калъп"...

Сега ще изброя някои често срещани архитектури/калъпи.

Първо "дребните" дето се ползват в малки контролери.... Примерно един main цикъл дето върти една или повече стейт машинки. Тоя сорт калъпи на мен са ми прекалено "тесни", затова и не искам да ги коментирам сега.

Втората по известност архитектура е използването на малък кърнел, т.е. вкарана е някаква многозадачност. Като трябва да направиш нещо, пускаш някаква нишка, тя върти някакво цикълче и прави нещо. Тук най-важното за калъпа е дали има драйвери или няма. Когато няма драйвери калъпът става много размит, тъй като могат да се ползват много и различни начини за да се свърши едно и също нещо. Примерно контролера трябва да си приказва със сървър или просто с компютър по някакъв протокол. Има хиляди начини как да стане това. В общия случай да кажем ще има някаква нишка дето ще поема протоколните приказки, но дали пред нея или зад нея ще има опашки, дали ще има семафори, дали ще са критични секции - всичко опира до въображението на конкретния програмист.

Следващата архитектурка е като горната, само че плюс драйверна система. Идеята тук е да се предпазим от "развинтеното въображение" на програмистите и нещата да се вкарат в един по-ясен калъп. В Целта не е да се ограничават, значи ако без драйвери има 100 варианта да направиш едно нещо, то и с драйвери пак имаш почти толкова. Разликата е в статистиката, защото колкото по-добра е една ОС, толкова по-малко варианта се използват. Стандартният пример е Линукс, там има една концепция и това е файл. Всичко е файл. Аз също ползвам тая концепция, всичко при мен е файл. Няма UART, няма SPI, няма GPIO, няма GUI, всичко е файл или по-точно изглежда като файл. Само трябва да го отвориш и после може да четеш и пишеш.
Ако се върна пак с примера с комуникацията, то пак имаме нишка, тя отваря някакъв файл или по-точно стрийм към хоста, обработва си пакетчетата и на изхода пак може да изглежда като файл, който други нишки да отварят... Тоя калъп поне се "препоръчва" от операционната система. Казвам "препоръчва", защото е най-мързелив и лесен. Операционната система се грижи за повечето подробности, а и всичко е заучено положение. В смисъл няма нужда да обясняваш как и какво си направил Казваш тва е файла и толкоз. От своя страна клиентът няма нужда да се чуди дали да слага семафори и чудесии. Той просто се пробва да отвори файла, другото не е негова грижа.
Като цяло тая архитектурка е доста благодатна. Много по-лесно се бачка с нея, а и е доста гъвкава. Примерно като се направи нишката за комуникация, после лесно може да смениш комуникацията от сериен канал към TCP/IP сокет или обратно. Просто само името на файла/стрийма към сокета е различно. Ех и таймоутите, но това са дребни проблеми.

Следващата стъпка в архитектурите вече е истински ОС. Две са ключовите разлики с горната. Първо концепцията за "приложение" или по-точно възможността да се използва различен набор от приложения едновременно, като и да се променя. Повечето от вас предполагам не са се сблъсквали с тоя проблем, но тъй като правя терминали за мен е сериозен проблем. Някой клиент казва "абе искам да добавиш това", друг иска друго. Трети казва аз искам това, обаче махни това... В крайна сметка стигам поне 5-6 варианта, обаче комбинациите от тях са фактуриел... То с условно компилиране не е проблем да бълваш колкото си искаш комбинации, обаче си е гърч да тестваш всички комбинации. Да не говорим, че като се появи проблем на полето не знаеш каква точно версия/комбинация се е издънила. Абе който не се е сблъсквал с тия проблем е щастливец
Другото готино на големия ОС е, че има голям набор от протоколи и интерфейси на високо ниво, както и евентуално конзола. Тия неща позволяват да пипаш и настройваш неща в последствие. Логваш се във вече работещо устройство, пипаш това-онова и скриваш от шефа/клиента някоя недомислица. Не знам дали ставя ясно, но представете си една Линукс машина и едно устройство с някакъв фърмуер. При линукса само да имам конзолка и мога да го преконфигурирам както си искам. Докато при устройството каквото е заложено във фърмуера - това е! Наложи се нещо непредвидено и работата става дебела, трябва да правиш нов фърмуер, да препрограмираш... А то по закона на мърфи винаги се налага...


Сега една друга архитектура... Тя е малко известна, ползва се при системи с разпределена обработка, изобщо при мрежи. Има няколко модификации в зависимост дали е с многозадачност или без. Идеята е да се използват съобщения вместо API функции или вместо драйвери и адреси вместо указатели. Отделно се прави нещо дето се грижи да препраща съобщенията до точния получател.
Примерно ако има UART то той си има някаква входна опашка в която си получава съобщенията, след това ги обработва едно по едно...Когато клиент иска да прати нещо по UART просто изготвя съобщения, адресира го до UART и го праща в общия кюп. Смисълът на цялата история е, че вече няма значение дали UART е на локалния процесор или някъде на майната си...
Предимствата са, че ако имаш едно устройство с няколко UART-a, USB и т.н. оставаш единия интерфейс отворен за съобщения и така отвън може да влезеш под кожата на устройството. Да ползваш дистанционно всичките му периферии и да правиш куп неща, без да се налага да пипаш фърмуер или специални конфигурации.
Обикновено се ползва доволно прост формат на съобщения, така че подобна архитектура може да се имплементира даже на прост 8051 контролер. И той да е гъвкав "почти" колкото Линукс машина.

И последната архитектура дето ще спомена е... използването на скрипт интерпретатор. Има различни скриптове, даже прекалено много щото досега не съм успял да избера и тая концепция досега не съм я ползвал. Но идеята естествено е гъвкавост... Скриптовете обикновено позволяват да се зареждат динамично, така че все едно имаш различни "приложения". Някой скриптове имат и конзоли, така че може дистанционно да се подават нови неща.

===========================
Не знам дали стана ясно между редовете, но аз имам варианта RTOS с драйвери. Всичко е готино, мога да напиша сравнително лесно всичко. Проблемът ми обаче е, че трябва да го пиша под формата на фърмуер и то "затворен" фърмъер. Демек нямам нито протоколи от високо ниво, нито конзоли. Имам доста драйвери дето изглеждат като файл, но са си локални файлове с изключение на TCP сокети. Сокетите са дистанционни и се отварят лесно, ама като ги отворя пак стигам до фърмъер, т.е. за да отворя отвън сокет трябва преди това да съм сложил във фърмуера нишка дето да слухти. То хубаво че слухти, ама пак ще е за нещо фиксирано. Ще ми се да мога да сменям "поведение" без да се налага да сменям фърмуер... Да добавям нова функционалност като се наложи. Не ме питайте какво ще ми се наложи - НЕ ЗНАМ, аз ако знаех щях да я заложа още сега във фърмуера...
Евентуално бих могъл да сложа някакъв скрипт интерпретатор, още повече че имам локална файлова система. Ще оставя вратичка да се ъплоадват скриптове и т.н., но като почна да заглеждам скриптове все не мога да избера... Другия вариант е номера със съобщенията, така поне онлайн ще мога да използвам всички възможности на устройството, но трябва или да сменя "калъпа" или да ги дублирам.

Тъй де това са ми главоблъсканиците...

Няма ли готови решения, та трябва да мислиш твое ? Когато стигнеш на един такъв етап не е ли по-лесно да сложиш нещо готово - тествано, евтино, с поддръжка, готови различни приложения и т.н. .

Ами то почти за всичко има готови решения, ама "this is what we do", както казват по вашия край .

Нали все някой някога ги пише и тия готови решения.

Значи хич не горя от желание да откривам топлата вода

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

Остава варианта да правя собствен калъп или да пригодя някой полуфабрикат. Имам предвид някой скрипт интерпретатор/енджин. Гледам сега Java 2 Micro Edition Connected Limited Device Configuration (J2ME CLDC).... Има и други скрипчета Lua дето сигурно ще подкарам и по-лесно, но джабата има повече предимства. Принципно енджините са екмак-нещо си базирани демек поддържат няколко чешита скриптове. Тъй че мен самата джаба не ме интересува толкова колкото възможността да ползвам JavaScript и по-специално WMLScript щото и без друго поддържам WML...

В краен случай ще измисля нещо собствено дето да е още по-просто... Не знам... то ако знаех, нямаше да пиша тук

Миро, не си струва загубеното време да се бъзикаш с това и онова чуждо нещо.

Знаеш какво правиш, имаш нещо дотук дето го знаеш 100% щото е твое, просто давай
нататък според мене. Не е гаранция за успех, но отказването е гаранция за неуспех.

tgi, зависи за какво точно става въпрос. Ако са някакви уникални и бутикови устройства като твоите подхода може би е добър, но ако си говорим за например много бройки от най-различни устройства е глупаво (от гледна точка на клиента) да поверява една такава комплексна система в ръцете и главата на само един човек. Прекалено голям риск за клиента е . Разбира се, това са си само мои спекулации - идея си нямам Миро какво точно прави и в какви мащаби .

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

Всяко парче сериозен софтуер е писано от един човек.

[edit] Що на Миро RTOS-a да е кофти идея а на Дейвид FreeRtos-а да не е? Ако няма технически
причини за това или онова предпочитание, другото е въпрос на търговско предлагане
от страна на Дейвид или Миро, но и в двата случая си при _един_ човек. [/edit]

Номера не е само в написването - това е най-лесното нещо в случая .

Далеч не е най-лесното. Освен Миро оттук знам и Дейвид (поства в comp.arch.embedded,
дето и аз живея чат-пат), които са написали нещо такова и дотам.

Тук обсъждаме техническата страна на нещата, а не "ама как да стана Бил Гейтс" и подобни
простотии, към които за жалост почти винаги отиват подобни разговори - пак по същата
причина, просто няма достатъчно хора тук които да могат да коментират технически
тия неща. Миро току прави някой опит, аз знам достатъчно та хич и да не опитвам

Ако всичко опираше само до техническата реализация нещата щяха да са много прости. За съжаление или пък не, нещата почти винаги не опират само до техническата страна на въпроса .
Сори за офтопика, дето ви вкарвам - няма повече .

Точно за това иде реч... 100 пъти ще предпочета аз да го напиша, ама не става. Точно в момента обучавам един индиец, такива въпроси ми задава че ми иде да се гръмна
Аз му обяснявам, че фърмуера е написан на С, ползвам GNU GCC, а той "мога ли да ползвам ASP.NET?" После ме пита откъде да си намерил книга за GCC.
Мнооого се съмнявам че тоя човек ще свърши работа. Но нищо не мога да направя, казах на клиента дай ние да ти направим всичко, обаче те искат да ползват терминалите с някакъв индийски софтуер за разплащания. А пък индийците искат да качат нещо в терминала, но не искат да кажат какво... те щели да си го направят сами.

Та затова @tqi хич, ама хич не искам да правя собствени неща и после да трябва да ги документирам като за малоумници и да ги съпортвам после. Пък и няма нищо лошо да се ползват чужди решения.
Аз така или иначе сигурно ще го пренаписвам, ама важна е идеята щото се гони съвместимост. Примерно ти сигурно може да направиш по-добър протокол от TCP, обаче няма смисъл... Щеш не щеш трябва да ползваш това което пише в IEEE 802.x...
В случая аз просто търся идея върху какво да стъпя като концепция, че хем да стане гъвкаво, хем да не се налага някой да ми пипа фърмуера....

В интерес на истината не са чак толкова големи нещата. Един човек няма как да направи големи неща. Може да има добра идея, но тя не струва нищо, ако не се споделя.
Ето ти тук едно филмче затова как идеите трябва да се оплождат

Хммм, не съм сигурен, че мога да го направя по-хубав от tcp. То е _много_ добре премислено,
докато писах моя стек и четях разните RFC-та преди това съм научил доста неща, покрай
другото и това, че хората, които съчиняват нещо ново са единици .

Това с индиеца си е загубена кауза не защото е индиец, а защото е неправилният такъв.
При тоя въпрос от негова страна аз бих опитал да кажа на шефовете му, че за да правят
каквото искат им трябва човек с опит 5+ години в програмиране на C, за предпочитане
познаващ GCC. Тоя тип хора разбират такъв вид приказки, те не знаят за каква огромна
пропаст иде реч - колкото и очевидна да е за тебе тая пропаст.

За документирането знам едно - прави се, докато се програмира. Част от коментарите,
най-вече заглавните пасажи, трябва да са готови за копиране в упътването .
Но за DPS-а и аз нямам готово упътване като за даване на индийци (ставащи, за неставащи
не бих почвал да го пиша ), но не е потрябвало не съм го направил.

А и не е толкова много работа. Аз последно писах упътването за netmca-2 -то,
http://tgi-sci.com/tgi/nmcrman.pdf , ми ползвайки и стари неща ми отне два-три дни
барабар с openoffice-ченето (оттам стават хубави pdf-и).

Ако става дума за самия RTOS kernel и някаква система за device independent I/O, нещата не са
особено обемисти наистина (първото си такова нещо правих за 6809 преди 25 години... отне ми
два-три месеца, ако не броим годините учене и разбиране кое как и защо преди това ).

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

А приказката за "mating of ideas" е просто "stating the obvious", разбира се, че човешкото _знание_
се гради през поколенията и в рамките на поколенията на базата на направеното от други.
И някои от тия "други" копаят дупки, други садят чушки, трети пишат операционни системи... така
върви светът, нищо ново в това .

За мое съжаление наистина малко хора се занимават с операционни системи. Ако бяха повече, сигурно аз нямаше да се занимавам а щях да ползвам нещо наготово

Но да се върна към темата... проблемът е как да се направи една ембедед система по-гъвкава? Типичният подход С-кодиране + някакъв RTOS не ми е достатъчно гъвкав. А стандартното решение да сложа по-як хардуер и голяма ОС не ми харесва.