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

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

Но помня първите месеци на DPS-а, когато още нямах файлова система а дебъгвах
разните неща именно свързани с нея.

Вече бях направил системите за memory allocate (то това беше естествено баш първото),
разните таск дескриптори бяха готови, както и дескрипторите на програмни модули.
Т.е. за да стартира човек таск му трябваше програмен модул и няколко реда код
за да стартира тоя таск (нямаше шел нямаше нищо).
Имах някакъв интерфейс за load-ване на програмни модули директно от устройство,
т.е. в non-file mode, или поне така би работил сега ако работи още, тогава не
помня баш как беше.
Но мисълта ми е, че ако имаш всичко споменато вече готово би могъл просто
да си направиш някаква такава load-варка на програмни модули и да ги стартираш,
да пишеш и рекомпилираш ще остане само малкото код дето приготвя пакета дето
подаваш на spawn (там аз подавам информацията и кой е програмният модул).
А load-варката може да чете модулите и от собствения си флаш, може просто да
прехвърля показалки и подобни та да не копираш едно нещо два пъти и т.н.

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

Засега концепцията за приложения съм я оставил на заден план. Проблемът е, че нямам MMU съответно приложенията трябва да се компилират като PIC (position independant code). Не е невъзможно само малко сложничко, съвсем ще шашна индийците Освен това, за да стане истинско ще трябва и някаква шел конзола което ще ме затрудни...

По-скоро вместо приложения мисля върху скрипт. Повече ресурси, по-тромаво ама ако е стандартен език, няма да го обяснявам. Освен това интерпретаторните обикновено лесно се свързват и с конзола, така че няма да има нужда да правя шел. Само дето не мога да си харесам скрипт... Искам да е някой скрипт дето се използва и за web, че и браузъра да стане по-добър. Но не мога да намеря читав engine нито интерпретатор. Мога да подкарам лесно Lua, но той пък не е web...

Ако не стане със скрипт сигурно ще обмисля варианта със съобщенията...

Ами ей го, дори не съм разбрал какво питаш .

В моите представи всеки таск има един (основен) асоцииран "програмен модул",
който е описан някъде и може да бъде (всъщност всички са) position independent.
Може и да е reentrant (пак всички всъщност са такива), и т.н.

За скрипт процесор нещата са съвсем отделна губерния. В DPS-а скрипт е каквото
е в DOS, unix и подобни - с друг синтаксис.

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

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

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

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

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

Проблемът e, че това с WML-то ми реши само проблемите с GUI и комуникацията със сървъра. Не е 100% решение на теоретичния проблем. Просто пример как програмирането на езици от ниско или високо ниво може да бъде избегнато, при това много успешно!
Идеята е, че искам да изкарам колкото се може повече функционалност извън фърмуера. Щото функционалността дето се реализира във фърмуера остава фиксирана. Искам колкото се може повече неща да могат да се управляват без фърмъуер. Да кажем перифериите - имам сериен, имам USB. Искаш примерно да закачиш някакъв баркод четец и вместо да префлашваш да може с някакво малко скриптче да се управлява тоя четец. Или пък ако закачиш четец за смарт карти - той си има малък процесор вътре, но му трябва да ползва модема че да се върже със сървъра на банката.

Това са само примери. Иначе не е задължително да е обвързано с конкретен проект. То ако е гъвкаво решение ще може да се ползва за много неща...

Миро, всичките примери които даде все се въртят около комуникационния хадруер (UART, USB, Етхернет...) А какво правим с другия хардуер, който не е комуникационен?
Универсалното решение е в противоречие с ефективното такова ... Относно GUI-to - това дето сте направили с WML е перфектно решение. Поддръжката на Jawa също е добър вариянт и мисля, че може да минеш и без MMU. Но всичко това лапа ресурс и незнам как се вписва в представата за едночипов вариянт на изделие ...

Освен това едва ли някой очаква такива решения работещи в едночипов вариянт... То идеята на едночиповото решение е по-различна (според мен де)... Очаква се от него чисто със софтуерни "врътки" + наличния в него хардуер като периферия да може да се опрости външния хадуер и да се повиши надеждността, цената и габаритите на изделието. Т.е. в него нещата се изстискват максимално (да не говорим за консумацията му ако е батерийно).
Та ако това устройство не е "терминал" - то функционалността му (HW иSW) е скроена според нуждите.

Самото използване на каквато и да е РТОС от самосебе си налага някакви правила на софтуерната архитектура. Така че уточни за какви системи иде реч.
Ако са в едночипов вариянт нещата са доста по-ограничени спрямо тези с външни рам/ром.

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

Значи аз казах, че въпросът е повече теоретичен. Примерите са просто частни случаи на проблеми. Разбира се решението е желателно колкото се може повече проблеми да решава.




Определено става дума за едночипов вариант... То иначе решения от сорта на Линукс има.
Иначе действително като се каже едночипов контролер хората си представят точно това - нещо малко, просто с конкретен софтуер... а ако трябва нещо с повече функционалност, то задължително трябва да е с 100-на MB и няколкостотин MHz.
Отстрани може би изглеждам като беден селянин, който се опитва да направи от нищо нещо. И то не е далеч от истината... но от друга страна аз все пак не говоря за едночипов 8051 с 1кб RAM... Контролерите дето ползвам си имат вграден етернет, USB host/device, един куп серийни и т.н. А като производителност колкото и слаби да изглеждат днешно време, преди 20-30 години щяха да ги наричат суперкомпютри. Е сравни ги примерно с VAX11, ами че аз имам 10-пъти по-голяма производителност

Тъй де, аз съм на мнение, че днешните "едничипови" могат повече от това да мигат лед-чета. Въпросът е, че има толкоз периферия и глупости че да правиш всичко ръчно е голяма хамалогия. Затова се ползват ОС-ве, драйвери, библиотеки, чудеса... Само дето трудно се намират читави работи. Може би щото тоя клас контролери са нови и половината неща идват от малките 8-бит. За мен това да ползваш ОС дето е писан за 8051 и после преправен за АРМ си е много тъпо... А другата половина от нещата идват пък от света на големите компютри. Примерно повечето от библиотеките дето се ползват покрай GCC всъщност са от юникс/линукс и са тромави и ненужно тежки...

Май и аз се отплеснах... значи последно засега мисля да направя скрипт. Идеята е отдолу сравнително прост RTOS, отгоре малко по-сложна драйверна системка (неизбежно). Това е стандартно и достатъчно за Ц/Ц++ частта дето ще имплементира първоначалната функционалност. Към това нещо обаче и един скрипт, чрез който ще може да се управлява почти всичко както и през С/С++.
Така в последствие ще може да се добавя кой каквото иска...

Всъщност не само в последствие. Главната логика на повечето устройства според мен трябва да е на скрипт, за да може лесно да се модифицира. Ще дам един пример щото оня ден инсталирах gps устройство на колегата. Устройството бачка много добре, обаче твърдо набита функционалност. Донякъде има разни настройки, обаче за да промениш нещо трябва да го свалиш от колата, да го закачиш на компютър и да го програмираш. Тъпа работа! Освен това данните ги праща по TCP, а е толкоз просто да му сложат едно HTTP. Разликата е огромна, HTTP може да пуснеш на кой да е сървър и с няколко прости PHP скрипта може да се направи да дъмпва в една табличка, после един експорт към google.earth и готово...
Иначе функционалността като репортва през скрипт, сървърът може да връща нов скрипт когато искаш да промениш нещо. Устройството си има няколко входа, няколко изхода и един WML би паснал перфектно. Входовете могат да генерират събития, събитията задействат задачи, задачите може да са всякакви... съобщение към сървъра, пращане на СМС, абе каквато логика искаш. И всичко става супер лесно с няколко реда, даже скрипта може да се генерира от сървъра.
Както и да е... аз не правя gps-и. Просто пример как бих го направил

Миро, производителност на ALU-то може и да имаш ама вероятно си беден откъм RAM.

За да пусне човек свястно работещо tcp на 10 MbpS, трябват десетки килобайта
за входящ буфер само.
За да станат 100 MbpS, работата отива в стотиците килобайта за такъв буфер.

Примерно целият DPS - без мрежата - за 68к (CPU32) се чувстваше съвсем добре в
1M RAM. И прозорци и т.н., последните естествено нямаха off-screen буфери а
стояха само във framebuffer RAM-а на контролера и се спасяваха по диска като
ги затисне някой.
Това и в 256к със сигурност би работило (мисля, че си играх да опитвам преди
10+ години).

Та мисълта ми е, че MCU-тата са обречени на това, дето Емил вижда в тях именно
заради малкото RAM. Замислени са да бъдат така. В крайна сметка с един чип
DDRAM можеш да добавиш десетки мегабайти, засега поне е по-практично да се върже
външно.
Ти колко RAM имаш всъщност в твоите ARM-ове? Аз не ги знам, може и да остана
изненадан.

96К е рамеца, има опция и за външен DRAM но не смятам да се възползвам. Не се и налага щото засега няма да правим етернет...


За tcp-то много зависи за какво ще се ползва. Ако има трафик си прав, трябва си приличен прозорец. Но за нещо бавно може би ще стане с малко памет. Не знам, не съм го пробвал...

А, за нещо бавно и надребно ще стане, няма съмнение. Колкото по-високи са скоростите,
че и RTT-то, толкова повече буфер отива.

96k е и малко и много, според ситуацията . То въобще тия ARM неща са все
някъде по граничното, ни голямо ни малко, това им е нишата явно, а аз в нея много
не съм се врял. Помня времето, когато целите 64k на 6809 ми се видяха голямо
богатство, ама не се чувствах богат особено дълго тогава .

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

Това е нишата в която аз се мъча... иначе АРМ искат да покрият целия спектър... от джвъчки за по 1$ до напоследък дуал кур куртекс А9 с 15 stage pipeline, 128bit SIMD enignes... 3000+ MIPS...

Защо си налагаш това самоограничение? И то на днешно време ,когато контролерите и по размер, и по цени вече са по-малки от един ОУ. Според мен е по-добре да си гъвкав на хардуерно ниво, а софта да си е оптимизиран за съответния хардуер. Например, цепиш всеки проект на две - фърмуер и интерфейс, всеки с отделен контролер. Интерфейса си го правиш с някакъв "медиен" професор, развиваш си го като модул и си го боцкаш на всеки проект. Фърмуерната част зависи от конкретния проект и я връзваш по някакъв стандартен канал с фейсната част. Така при нов проект ще трябва да се пише само малък "преводач" в интерфейса за конкретния фърмуер и от там нататък по канала- клавиатурки, екранчета, веб, мп3, джиджи-биджи... Инерфейсния модул го бъкаш с всички екстри които се сетиш, а после в зависимост от нуждите, го орязваш до необходимия минимум. Или си правиш няколко различна модула с различна функционалност и/или софтуерна архитектура. Хубавото на този подход е ,че интерфейса може да си го развиваш даже и когато не работиш по конкретен проект и вече направени неща лесно ще ги ъпгрейдваш с нова функционаност.

Не знам какво точно имаш предвид, но аз съм участвал и в малки и по-големи проекти и не съм виждал разумен начин за тяхното смесване

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

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

За съжаление, "големият" хардуер изисква много по-сериозна първоначална инвестиция. Говорим за BGA с 400+ топки, миниум DDR2 и т.н., минумум 6-слойна платка и т.н. Все неща дето затрудняват българските производители и то проблемът не е толкова в трудностите - можем да го направим, само че като го направим получаваме продукт който вече го има на пазара, само че произведен в Китай на мнооооого по-ниска цена.
Поради тия и поради много други причини умишлено избягваме големия хардуер. В заданието ми пише "едночипов" и толкоз. Не става въпрос за самоограничавания
Само че като сложа едночиповия ми излизат тия проблеми с архитектурата на софтуера, който пак подчертавам трябва да работи в рамките на едно единствено и едночипово ядро....

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

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


Както и да е... аз вече казах, че нещата отиват към скрипт. В момента се двуумя само дали да е джабата. Java 2 Micro Edition изглежда подходящо, но проблемът е как да я имплементирам. Документацията е обща, а стандартния едишън е прекалено сложен.... Трябва да преровя цял куп сено, за да намеря иглата дето ми трябва. С две думи плаши ме...
Та затова се двуумя дали да не ползвам нещо друго дето може и да не е по-елементарно, но поне ще е по-изчистено...

Миро, определено ти трябва някакъв скрипт. Jawa-та е вариянт, но мисля, че цялата пара на процесора ще отиде в свирката, вместо за вършене на нещо полезно. Но пък всичко си има цена.
Също трябва да решиш трябва ли да е нещо "стандартно" (като Jawa) или може da e нещо къстъм.

PLC-тата имат нещо подобно на това за което говориш. Имат нещо като интерпретатор на команди. Такова чудо ще ти свърши ли работа?

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

Опитай се да дефинираш и решиш какво точно ти трябва.