Здравейте на всички,
първо да се представя -казвам се Наско от Плодвив съм. Интересите ми са основно свързани с ОС и по-специално с РТОС. В тая наскока реших да пиша и дисертация ( то се почна на майтап) и се вече съм 2 година докторант обаче я закърших - срещам големи проблеми......затова ще пиша по-долу и моля ако някой има някакви идеи или мнения да ги сподели.
Така, значи става въпрос за следното нещо: хардуерен ускорител за реално-времева операционна система, конценпцията вклчючва SoC = HW-RTOS-8 + i8051 + RAM/ROM --> имплементация и верификация в Xilinx Spartan3 200k.
По принцип, след 2 годишен литературен обзор, може да се направи обобщението, че ТРИ са основните подхода за ускорение на реално-времеви задачи /има се предвид реално-времевата система/:
1. подход с копроцесор;
2. подход с добавяне на функционалност имплементираща основни функции на ОС -таймери, семафори, управление за процеси и т.н. /пример Транспутер с хардуерен планоровчик или Сименс 80199/
3. Оптимизация на набора инструкции /или добавяне на нови такива, пример REFLIX - реактивен PIC/
Моята идея е смесица от 2 и 3 т.е. имам ускорител (до 4 процеса на 4 приоритетни нива) + IP core 8051 на Орегано ( за да може да се внесе корекция в ISA set-a) - за бенчмарк ще се ползва Rhealstone.
Въпросите са ми следните:
1. Удачнен ли е изборът ми на платформа - 8 бита и по-специано 8051. За по-големи 16 и 32 има разработени (например Sierra RTOS www.realfast.se - Lenard Lindht е един от пионерите в тая област, заедно с Винсънт Мууни). Питам защото е доказано, че при използването на подобе род ускорител се постига значилено увеличение на произодителността, заото се увеличава времето на процесора за потребителските задачи. Предизвикателството за 8 битови платформи идва от ограничените ресурси. Прочетох из форума вашите мнения за и против използването на РТОС при микроконтролерите, но всичко се свежда до софтуерна реализация, а как би било ако всичко се върши паралелно с MCU-to. Какви са вашите очаквания? Има ли смисъл от тази "'гимнастика". Все пак тренда показва, че 8-битовите платформи ще се изполват още дълго и пазарният им дял не е никак лош. С появата на евтина програмируема логика и множесто IP ядра, концепцията за система-върху-чипа все по-масово се развива и по всикчо личи ще така ще бъде и занапред...Т.е на вас като специалисти ако ви се предложи подобна 8-битова система от 8051+Hw-RTOS+RAM/ROM как оптимизирана за реално-времеви задачи, как бихте я приели, за нещо екзотично или пък ненужно? Моля споделете, важно е за мен да разбера мненията на истинските специалисти, за да си направя нужните изводи относно актуалност и концепция. Искам да отбележа, че има множесто опити правени за реализацията на реално-времеви процесори (както се казва from scratch), но не намират реализация защото нямат поддръжка за тях, нито развойна нито приложна. Аз затова се спирам, на 8051 архитектура.
2. Тъй като концепцията е псевдопаралелна, само един процесорен елемет, според вас по-добре ли е да се имплементира true parallel например 2x8051 или ??? Какви ще бъдат предимствата и недостатъците ( има една подобна разработка с 2ь 8048, но доста се усложняват нещата). Аз сум избрал псевдопаралелна, тъй като афинитета на процесите в реално-времевите системи е с входно-изходен характер, не толкова с изчислителен. В тоя смисъл за мен е по-важно например оптимизация в схемата за прекъсвания или използване на бързо контексно превключване, отколкото например бързо умножение или делене. И не на последно място предсказуемост.
3. Не знам кой термин да използвам - ускорител или копроцесор. Прочетох на доста места, че е по-правилно да се нарича ускорител, защото копроцесора изпълнява допулнителни инструкции към основния набор. А тук идеята е МЦУ да адресира вътрешни регистри на HW_RTOS, а управлението да става чрез прекъсване.
4. Да предположим, че модула HW-RTOS e горе-долу готов. Не знам обаче как да го вържа с MCU-то. Проблем със синхронизацията няма, тъй като всичко е в Xilinx-a. Но как да адресирам регистрите и да чета и пиша даните, нямам си и идея. Сигурно всичко звучи много объркано , затова ще се опитам да дам пример:

-- *** Test Bench - User Defined Section ***
-- process to generate the clock pulse
clk_in:process
begin
iClk_top <= '1';
wait for 50 ns;
iClk_top <= '0';
wait for 50 ns;
end process clk_in;

--process to assign the simulate value
tb : PROCESS
BEGIN
iReset <= '0';
iWr <= '0';
iRd <= '0';
iCs <= '0';
iAdr <= (others => '0');
idb <= (others => '0');
--reset all modules
wait for 100 ns;
iReset <= '1';
wait for 100 ns;
iReset <= '0';

--create the idle task(task_id="00" priority="11")
wait for 300 ns;
iAdr <= "00000000";--Tr0
iWr <= '1';
iDb <= "00001100";
wait for 100 ns;
iWr <= '0';

значи ето част от тестбенча- създаване на idle процеса - адресирам Tr0 (Task registrer 0), после разрешавам запис, после
пиша в регистъра 00001100 - битове 0 и 1 са идентификатор на процеса, битове 3 и4 приритета на процеса. След това завършвам писането във вътрешните регистри на HW-RTOS...... и по-надолу е аналогично
--create a new task(task_id="01" priority="01")
wait for 300 ns;
iAdr <= "00000010";--Tr1
iWr <= '1';
iDb <= "00000101";
wait for 100 ns;
iWr <= '0';

--create a new task(task_id="10" priority="10")
wait for 300 ns;
iAdr <= "00000100";--Tr2
iWr <= '1';
iDb <= "00001010";
wait for 100 ns;
iWr <= '0';

--create a new task(task_id="11" priority="11")
wait for 300 ns;
iAdr <= "00000110";--Tr3
iWr <= '1';
iDb <= "00001111";
wait for 100 ns;
iWr <= '0';
...........................................................

На тестбенч е лесно задавам си поведение и следя, но как да накарам MCU да върши тая работа. Накакво софтуерно кърнълче ли (така е направена Sierra - memory mapping на регистрите) или пък направо да се въведат нови команди, например CRTSK (create task), DLTSK ...TSS (task switch) и т.н. като поведението на тези конади се разпише дирекно на VHDL и се свърже с модула - например ART 805 1 има две нови команди ABORT и CABORT. За целта се създават нови SFR и им се разписва поведението.
И накрая се чудя как трябва да изглежда API-то все пак приложните програмисти трябва да се възползват от ускорителя по някакъв начин...в смисъл как се реализира изобщо. Например базовия 8051 няма АЦП, но да кажем някакъв дериват има, следователно има и съответен SFR и инсртукции за манипулиране. Това пак ли е заложено хардуено или може чрез накакъв софтуерен модул или макрос да се реализира.
Съжелявам, ако поста ви се струва безмислен или объркан, надявам се в процес да се изясни за какво става върпос и аз да успея да си задам правилно въпросите. А пък, ако на някой му се хареса темата чисто теоретично или по-скоро академично да пита или ако иска да ми пише - имам много материал и прочетени стотици статии и дисертации. Ще пратя на всеки каквото го интересува. Надявам се, да предизвикам интерес и пак ви моля всякакви менния са ми от изключителна полза, защото за съжаление не мога да намеря подходящи консултанти и специалисти и почва да се отчайвам.

Благодаря предварително на всички[/img][/url]

Здравей и добре дошъл,
ако добре разбирам това е ОС която обаче се изпълнява от хардуер така ли, и е за IP ядра?
Моето мнение, но трябва да отбележа че нмам голям опит с RTOS, някога бях мъчил тази .... един русенски проверор го е писал, за 51 ядро, но не много сериозно, а след това .. аз съм си писал разни неща но е силно казано RTOS , та на въпроса.
За 8 битов процесор, идеята не е лоша, обаче наистина опира до функционалност и приложение. В момента 8/16/32 битови процесори са на доста сходни цени. Какво е предимството на RTOS ..... всъщност какво точно поддържа тази RTOS. Освен семафори, таймери, превключване на задачи .. това малко или много се прави и без него. Файлова система, това е първото полезно нещо, после стек TCP/IP, USB, и всякакви други, ако има за нея драйвери писани от производители идеално според мен, въпреки че май всичко тябва малко или много да се бутне. Та това са нещата които много изуават в една RTOS, верно менажирането на паметта и задачите само по себе си никак не е малко. И така, да си родължа мисълта, всички тия неща са хубави, обаче като ги погледнеш в повечето случаи са свързани с обработка и предаване на данни. Тук идва момента с това дали е удачно изпозлване на 8 битов процесор за подобни задачи. Аз както виждам нещата 8 битовите ще останат в сегмента където се иска скорост при работа с И/О, не много математика, общо вето контролери. Значи някога правих един шприц, и верно RTOS щеше да ми дойде идеално ... е писах си нещо ама .... колкото да върши работа .... има приложения, но не знам до колко ще е изпозлваем този RTOS.
От друга страна говорим за логика, нали така, значи дали ще сложиш ядро на 51-ца или на нещо друго 16 /32 битово ...... цената малко ще мръдне, и пак опираме, ако някой качва RTOS дали ще избере 8 битовото ядро или 32 битовото, верно, иа разлика в ресурсите но .....
По въпроса за периферията, това което можеш да обслужват от тая логика според мен, т.е. от твойта ОС са само вътрешните модули, тймери, броячи ОК, но ADC ... някак няма как да го набуташ вътре, от там и най големия проблем, за какво АДЦ ще направиш команди,колко битаво, на кой проиводител .... това според мен може да се поеме от софтуера, или нека пак да е хардуер, но да го пише тои който прави логиката, едва ли вътре ще има само едно ядро. Друг вариант .. да имаш интерфей за достъп, команда за семпъл, за здавне на честота на семплиране, избор на вхд и т.н. и отделно да имаш драйвери за различни ADC, така че твойта програма, ОС тоест, посредством драйвера да обслужва външно ADC, нали тък говорим за хардеурно обслужване, драйвера ще е VHDL за логиката, нали така, за да не губим процесорно време. Нещо такова го виждам .. знам ли .... примерно хардуерни стекове, което обаче ще гълт ресурси ....
Това е една гледна точка .....сигурно има доста други ......

@desev,
на мен малко ми се мътна самата идея на този ускорител. Нямам много опит с RTOS... Опитвам се да разбера какво се очаква от HW+RTOS събрани в Xilinx, ниска цена, висока производителност, по-бърз 8 битов процесор или процесор, предназначен специално за и поддържащ всичко нужно за по-ефективна работа на RTOS. От поста доколкото разбирам става въпрос за последното... каква обаче е идеята на такъв контролер и къде според теб ще намери приложение, как можеш да ме накараш да сложа Xilinx(Intel) вместо ARM или DSP например?

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

Според мен това е правилния избор, както сам казваш се говори за HW+RTOS, в няколкото RTOS които съм пробвал (+ едната която опитах да напиша преди време) проблема винаги е бил в Context Switch-а, хардуера на това място е незаменим, а за бързи аритметики предполагам че ще ти остане малко място в Spartan-а за допълнителен хардуер.

Темата е интересна, но ще се радвам ако дадеш някакво приерно приложение на такъв контролер, все пак за Embedded ли говорим?

Моето мнение е, че това, дето го правиш за 8051 не е излишно и определено има смисъл. Но има едно 'ако'.
Има смисъл ако не остане на ниво 'превключване на задачи' а се доразвие - имам предвид, както писа ToHu да му се добавят стекове и други такива дреболийки, които ще повишат интереса към една такава ОС. Всъщност комерсиално погледнато това е нещото, което може да направи една ОС търсена или не, така че е добре да се помисли по този въпрос.
Другият фактор, за който се сещам е отношението цена/производителност. Добре е да се прецени дали твоят вариант е по-ефективен от една система със същите възможности на същата цена.
Иначе от програмистка гледна точка, аз лично предпочитам да работя с ОС (ако ресурсите на проца го позволяват ).

До колкото разбрах става въпрос за добавяне в апаратната част на всички функции които трябва да реализира една RTOS. Много процесори поддържат част от тези неща апаратно (превключване на контекста например), но за някои фукнции за първи път чувам идея да се реализират хардуерно (примерно диспечера на задачи). Явно не съм чел достатъчно в тази област . Не знам дали 8 битов процесор е подходящ за такава реализация (може би като за начало). Мисля си че в един момент самата хардуерна ОС ще струва повече и ще глътне повече ресурси от колкото самия процесор, а и от 8-те бита просто просто си мисля ще се замаже ефекта от хардуерното ускорение. Това разбирасе ако има много сметки. Но ако няма сметки, дали не е по-добре всичко да се реализира хардуерно. А и още нещо, дали не се намалява гъвкавостта на процесора по-този начин, примерно направен е за максимум 4-задачи, а пък в конкретния проект ти трябват 5. Но това сигурно си зависи от начина на реализация.

Първо искам да благодаря на отзовалите се,
сега знам че всичко звуяи някак си no sense, но аз затова съм писал че това е част от дисертационен труд, т.е тук е по-важно да се проведе някакво изследване, след което да се изведат резултати, които от своя страна водят до съответните изводи. Затова говорим за концепции и т.н., не е толкова комерсиално ориентирано и изобщо не е съобразено с пазарните дадености. Аз затова съм писал, че има разработки на реално-времеви процесори, но си остават само в университетските лаборатории.... Наистина тук идеята е да се пренесат основните функции на една РТОС от софтуерна кум хардуерна реализация, естествено доколкото е възможно. Затова се използва т.нар. hardware/software codesign...Защо 8 бита - просто 32 битовите платформи, особено RISC, са с достатъчно ресурси за една ефективна софтуерна реализация, най-често имат MMU и други такива благинки. Там дори и да се въведе един такъв ускорител, разликата няма да бъде фрапираща...пък и да не забравяме, че има и 8051 корове който достигат 70-80 MIPS-а, а и нагоре..Cygnal и т.н. В СРВ най-важно е спазване на дедлайна и предсказуемост на системата, на мене не ми требе жокер /изчислителна мощ/. Ако искам обаче мога да си направя хардуерни умножители и други оптимизации - все пак това е SoC на базата на Spartan-3, а в него има доста бъзикни, на този етап за мен е по-важно реал-тиме прозводителността. Ако за оригиналния 8051 му трябват 3-9 цикъла за обработка на прекъсване, аз се стремя да го направя < и т.н...
Да дадем пример - долу в PDF-a е мануъла на Sierra, прочетете го и надявам се да стане ясно, това е за 32бит вързана с Microblaze, има портове и за други платформи. Даже ако на някой му се занимава, сега шведите пуснаха и демо, така че можете да го друпнете и да бъзикате, но ви трябва EDK 6.3 или 7.1. Та мойто е нещо подобно, но за 8051, при това оптимизиран 8051 (имам предвид ISA set), долу ви пускам и един проект, в който има и сравнение с комерсиална MIcroC/OS../мисля, че това е една от най-добрите РТОС за малките устройства , иначе QNX rules/. Това е една добра отправна точка изобщо в тематиката. Шведите много дълбаят в тая област и имат и много постижения. Покрай разработката на Ленард Линдт, колко човека ако знаете са си направили дисертациите...
След всичко казано /и най-вече документите долу/ - мнението ви за реализация с 8051, какво остава - виждам, че повечето от вас не биха заложили на подобна платформа или поне не 8-битова. За мен е много добре да чуя повече мнения, защото ми оставят само две години и ако трябва да се преориентирам трябва да се действа....иначе лошо. Но све пак за мен 8051 си остава жива платформа и то по-жива отвсякога / single cycle instruction, RISC, multicore и т.н/, няма как да кача всички документи, но все пак едни много интересен проект - за да се аргументирам /долу/....

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

p.s.
забравих - защо само 4 процеса? Ми това по принцип не би трябвало да е проблем, но се ограничавам от каайните ресурси на матрицата все пак, иначе по-голяма матрица - повече процеси. Най-много да се смени някой параметър в кода /не че е малко де../. Например в кора на Орегано за 8051 със смяната на един параметър манупулирам броя на таймерите например, удобно нали?
p.ps.
май се олях с тия атачмънти, в някой друг пост тогава ще пусна оптимизирания 8051...

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