Отговори на тема  [ 77 мнения ]  Отиди на страница Предишна  1, 2, 3, 4, 5, 6  Следваща
RTOS 
Автор Съобщение
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 4174
Местоположение: Brussels / Пловдив
Мнение Re: RTOS
Миро, може да има нещо в разните RTOS които търкалят гсм модемите ... то даже като се позамисля, такава функционалност някак си не е присъща за RTOS а по скоро за истински тежък OS.

Гледам, че в L4 кернелите има нещо за мултипроцесорни системи.

_________________
Мразя да мразя ...


Пет Ное 22, 2019 8:59 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: RTOS
FreeRTOS има SMP поддръжка и даже я ползват активно е ESP32, ама не мисля че оттам е почнало - мисля някъде в 8.х се появи, и не се сещам за кой друг многоядрен ще да са я правили в началото, може би за nxp LPC-тата.


Пет Ное 22, 2019 9:37 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: RTOS
Mailbox communication... между RTOS кур
нящо такова https://msreekan.com/tag/mailbox/
azsphere през узер API
https://github.com/Azure/azure-sphere-s ... rcoreComms

при GSM модулите е подобно между апликационния чеп и DSP
Qualcomm MSM/QMI, на Mediatek не му знам името

ама тва не е един RTOS за много чепове

_________________
main[-1u]={1};


Пет Ное 22, 2019 9:39 pm
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: RTOS
Мдам... има разни реализации на SMP за кърнели, има и разни синхронизационни примитиви.

Някой ден ще трябва да отделя малко повече време за проучване, защото на теория е едно, ама на практика има доста подробности, които могат да скапят пейзажа. Интересно как го правят при по-големите, така че да не се стига до ужасен овърхед и множеството курове постоянно да се чакат един друг.
Цялата работа е, че сега си правя порт за H7. Нямам планове да ползвам многокуровите версии на тоя етап, ама те са почти идентични, т.е. същите периферии и т.н. И ще е хубаво да предвидя и едните и другите. А пък и ми стана интересно, понеже ST са се поиграли да интегрират различните курове, така че да са взаимно заменяеми. Видимо е просто, че целта не е да има два отделни контролера на една подложка. Направили са го като истински многокуров чеп и в рекламите им постоянно намекват за SMP...
При всички случаи нещата отива на многокурови истории и трябва да учим нови номера ;-)


Съб Ное 23, 2019 10:44 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 4174
Местоположение: Brussels / Пловдив
Мнение Re: RTOS
А защо ти се налага да ги поддържаш? Намаляване на консумацията докато джаджата работи на батерии? Постигане на максимална производителност? Питам защото много често човек лесно тръгва да прави нещо предизвикателно без да има наистина наболял проблем за решаване. Т.е. ако мога да се перефразирам - струва ли си да правиш SMP, ще ти реши ли някакъв конкретен проблем?

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

_________________
Мразя да мразя ...


Съб Ное 23, 2019 1:38 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: RTOS
palavrov написа:
Преди 10-на години бях започнал да си дялкам RTOS от спортна злоба и колкото и да ми беше кеф установих накрая, че всички задачи които исках да реша се решиха много по бързо и лесно с ембедед линукс ... верно, че на моменти е като да убиеш муха с чук, ама като имаш само чук, удряш по всичко с него.


Това е абсолютно вярно... Особено за нещата, които правя служебно с един линукс щяха да изглеждат много по-добре. Но поради ред други и независещи от мен причини не мога да ползвам линукс. Както се казва пари - нЕма, действайте... И те така вече 15+ години дялкаме собствен ОС. Не че се оплаквам, на мен и това ми доставя удоволствие, но реално погледнато през повечето време се налага да преоткриваме топлата вода ;-)
В случая искам да подкарам H7-ците заради оня проект, който бях заебал с мерачките... Така че не е служебно, няма и нужда от версия с два кура. Но доколкото Н7 са доста различни от останалите STM ще е по-добре да си ги направя наново, вместо да преправям съществуващите драйвери и дефиниции. Цялото това нещо е доста играчка, предполагам само хедърите с хардуерните дефиниции ще ми отнемат повече от седмица, да не говорим после драйвери и т.н. Просто аз не ползвам нищо от ST или който да е друг (крада само идеи).
И тъй като ще е доста голям гърча и тъй като и без друго трябва да огледам всички H7, защото стила на ОС-а е такъв, че не трябва да има дублиране на дефиниции, константи и т.н. та дори и да ползвам само един чеп от серията, сорса трябва да се мисли като за всички. Примерно един драйвер за да го сложа в ОС-а трябва да знам къде да го сложа, дали ще важи само за конкретен чеп (почти няма такива) дали ще важи за серията, дали за фамилията, дали за производителя. Просто такава ни е организацията... и нямам причина да я развалям сега.
С две думи, за да подкарам един чеп оглеждам всички... и в случая всички Н7-ци са много близки (нормално). Някои обаче са с два кура... и така стигам до въпроса как аджеба да предвидя тия с двата кура, ако някога ми се наложи да ги ползвам.
Всъщност може никога да не ми се наложи, но като цяло ми изглеждат много интересни животни и стига да изкочи проект с такива нужди бих лобирал за тях.
Иначе вече имам идеи на тема SMP, то всъщност няма да е 100% както го пишат по книгите. То и в линукс май е така, поне за някои дистрибуции за които четох идеята е през по-голямата част от времето всеки кур си е все едно сам. Търкаля си там нишките и процесите и не се занимава с глупости. През определено време (на 100-200ms) обаче се върти един анализ, който ако прецени може да прехвърли едни нишки от един кур на друг, за да се балансират.
Нещо такова ще направя и аз за кърнела. То другото е немислимо, не може на всяка смяна на контекст да се синхронизраш с останалите курове. Ще е ебати овърхеда...
Та тая идея ми убягваше как хем да има SMP хем пък да не се убива кърнела. Е някои други неща в кърнела също ще се пипнат и ще има лек овърхед, но много лек нядявам се... Като стигна до там ще го мисля.
Сега повече ме притеснява организацията на драйверите, доколкото при мен те са неразривна част от ОС-а и както обясних вече не бих искал да пиша два пъти едни и същи драйвери за една и съща периферия. Хубавото е, че при Н7 версиите с много курове не налага някакви ограничения, въпрос на софтуер е дали ще работи ефективно. Има възможности, които ще гледам да не окипазявам. Примерно може да има асинхронна организация, демек един кур да си работи с едни периферии, друг с други и стига да не се мешат няма нужда от нищо специално. Това разбира се е приложимо само за тясно специализирани драйвери, примерно да кажем етернета е нормално само една нишка да си търкаля стека и само тя си бъбри с MAC/PHY. Така че тоя драйвер спокойно може да се ожени само за един кур и евентуално само ако се пести ток да се предвиди местене, но те и ST не са го предвидили и това май ми е единствената забележка засега към дизайна им. Направили са два независими интеръпт контролера, но са ги обвързали всеки за неговия си кур. А е можело да сложят един мултиплексор преди куровете и интеръпт контролерите да станат виртуални. Така ако искаш да изгасиш единия кур няма да се налага да обхождаш всичките 240 прекъсвания и да ги пренасочваш едно по едно, а само да пипнеш мултиплексора и готово. Ама карай...
По-интересното са драйверите дето трябва да са SMP, щото аз не мога да си представя че предварително ще решавам тоя UART от кой кур ще се ползва и т.н. За щастие обаче при мен всичко е в ОС-а и приложенията не барат директно хардуер. Така че проблем няма, технически подобни драйвери ще са закачени към всеки кур, но една и съща инстанция и който кур докопа първи той ще е майстора и ще има удоволствието да работи по-бързо, а и ако другия иска да я ползва в същото време - няма проблем, но заявките му ще се прехвърлят към майстора, което ще вкарва лек овърхед, но пълно щастие няма ;-)
По същия начин мисля да подходя и с други критични неща като да кажем динамичната памет. Всеки кур ще си има собствен пул с който ще си работи нейтив както се казва. Но нишките няма нужда да се съобразяват с това, а и то няма как. Примерно при нас ползваме много текстообработка и много стрингове. А стринговете ползват динамична памет и както и когато им дойде. Като се присвои един стринг на друг няма копиране и така често заемането е от една нишка а освобождаването в друга. Та няма как да се следи, а и да се следи нищо не можеш да направиш, така или иначе памет от един кур ще се ползва/освобождава от друг. Може би само ще пипна освобождаването да може да става с опашка, т.е. да не се налага кура който иска да освободи памет от пула на комшията да чака. А пък заемането винаги ще си е от собствения пул. Ще помисля и малко как да се балансират пуловете и дали да се балансират...

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


Съб Ное 23, 2019 7:02 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Нед Ное 21, 2004 10:31 pm
Мнения: 9635
Мнение Re: RTOS
за SMP може да се говори сако, ако коровете са еднакви.
в цитирания от теб чЕп ST са успели да забъркат забележителен франкенщайн, буквално. с кончета в модерните шарени цветове на Дъгата.
в този контекст, М4 и М7 си приличат, колкото крокодил и ... тухла.

двата кора си живеят самостоятелен живот, със собстевени бъсове, памети и периферии, които вероятно са и различни (примерно уарта за М4 да е различен от уарта за М7). дори не искам да се заглеждам в такива детайли.

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

кода за М4 ще върви на М7 с някои особености. обратното няма да е възможно. М4 има битбандинг, М7 няма. да, бариерите са същите, но кешовете са различни, атомарните операции (да кажем мютекси) няма как да са такива между домейните, поне не и на ниво инструкция (на ниво кор). двата кора си имат собствени NVIC и подозирам, че съгласуването на двете ще е с потенциала на докторска дисертация (демек - нАучно изследване, без практическа стойност)

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

---
по повод регистровите дефиниции, пробвай да изкрънкаш от ST .xml по схемата CMSIS-SVD
или ще ти кажат "ко? кой? шо?", или ще ти го дадат. в този смисъл шанса е 50%, но усещането ми е по-скоро за първия вариант 8)


Нед Ное 24, 2019 10:19 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: RTOS
MailBox :)

https://www.freertos.org/wp-content/upl ... pology.png

https://www.freertos.org/STM32H7_Dual_C ... _demo.html

_________________
main[-1u]={1};


Нед Ное 24, 2019 11:04 am
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: RTOS
ДедоБоре написа:
между двете вселени има някаква връзка (бридж между бриджовете), но точиците в матриците на свързаност навяват на мисли за по-малко възможности за свързаност, отколкото за невъзможности. примерно, етернета е в М4 домейна, талавизора е в М7. криптото на М7 със сигурност ще е по-производително, но за да прекараш TLS пакет през него, трябва да го прехвърлиш. зирокопи - йок.


Аз не виждам голяма драма... перифериите са навързани към шините не към професорите. Нормално е етернета им да е към AHB щото си ползват съществуващо/старо IP. Новия им телевизор е с AXI и естестверно си е на тая шина.
Ядрата пък имат достъп всяко до всички шини, така че на теория проблем няма. Сега на практика някои комбинации ще са по-ефективни. Ако М7 ползва нета директно ще трябва да заеме две шини, което може и да не е приятно за малкото му братче, ама това е положението.
От към натоварване не се притеснявам за перифериите. Те нямат кой знае какъв трафик. Нета не е гигабит, така че да натовари, да натовари колко да натовари?
Мен ме интересува доколко има смисъл да се местят периферии от кур на кур и трябва ли нещо да предвиждам. На тоя етап не виждам нищо специално, т.е. мога да си правя еднокуровите и в същото време ако се наложи да ползвам двойните се надявам че ще е възможно. Как точно ще ги ползвам - ще го мисля като му дойде времето ;-)

Иначе да, не е точно SMP... аз често бъркам S-a и под SMP все си представям синхронна мултипроцесорна обработка. Така де, за мен синхронизацията е важна. А дали ще е симетрична или не ми е все тая.


Нед Ное 24, 2019 1:22 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: RTOS
BTW: размигах TencentOS със SAMR34 @48MHz ( m0+ )


Прикачени файлове:
10cent.jpg
10cent.jpg [ 321.4 KiB | Прегледано 11611 пъти ]

_________________
main[-1u]={1};


Последна промяна TheWizard на Нед Ное 24, 2019 6:50 pm, променена общо 1 път

Нед Ное 24, 2019 5:49 pm
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 4174
Местоположение: Brussels / Пловдив
Мнение Re: RTOS
miro_atc написа:
... Мен ме интересува доколко има смисъл да се местят периферии от кур на кур и трябва ли нещо да предвиждам. ...


Това местене на периферии колко е тежко?
Ако е да кажем няколко инструкции колкото да преконфигурираш прекъсванията да се обработват от друго ядро не виждам голяма драма да ги гласиш както ти е кеф.

_________________
Мразя да мразя ...


Нед Ное 24, 2019 6:41 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: RTOS
palavrov написа:
Това местене на периферии колко е тежко?


Като код няма да е кой знае какво, въпросът е че има тънки моменти...
Практически само прекъсванията трябва да се оправят, единия да спре, а другия да почне да ги обслужва. Звучи просто, само че понякога 2-3 периферии са навързани, примерно основната (АДЦ, УАРТ и т.н.) ползва ДМА а то ползва таймер. И сега спираш основната и може да я местиш, спираш ДМА канала, обаче прекъсването е общо за всички канали и не може само него да изместиш. Трябва всички канали, което значи че и други периферии ще се засегнат, а е трудно да издебнеш момент в който нито една периферия не бачка и може на спокойствие да си ги местиш.
Все пак има шанс да стане, щото са само прекъсванията. Навремето бях тръгнал да правя динамична смяна на клокове за едни атмели и не ми се получи добре, но с клоците нещата са далеч по-сложни. Перифериите може да ги оставиш за малко без прекъсвания и да не стане проблем, ама оставиш ли ги без клок... кофти ;-)


Нед Ное 24, 2019 7:39 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Нед Ное 21, 2004 10:31 pm
Мнения: 9635
Мнение Re: RTOS
двата кора си имат собствени NVIC. те по принцип са част от самия кор, нищо че ги водят в отделен документ. сглобяват се с кора, също като MPU-то.
та прекъсванията в рамките на кора са хардуерно рутирани. примерно UART0 на INT100. не мисля, че такова прекъсване може да се закара през 2/3 бриджа към другия, особено когато са различни архитектури.

с MPU-то мисля, че също ще има проблем. в М4 има едни дефиниции на зоните, в М7 са разширени, дори и без да се заглеждаме в XIP-а (май в точно в тоя чип не владеят Силата).
отделно поведението на кеша в М7 е малко различно, дори за вътрешния RAM и за външния (външния е само WТ, което може би е обуславено от спецификата на SDRAM).
от там и бариера, изпълнена на единия кор няма да има никаква практическа стойност в памет на другия.

а какво ще правят ексклузивните инструкции в 'чужд' домейн (STREX, примерно), трябва да го съобразявам по обед, след 3-4 кафеварки


Нед Ное 24, 2019 8:15 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: RTOS
Дедо, NVIC-те са съвсем идентични, даже ги преглеждах вектор по вектор дали случайно някоя периферия да не ходи и на двете места или да ходи на различни места. Не видях такава, разликите са само в специализираните неща ама то там е ясно.

За ексклузивните инструкции не съм срещнал каква им е имплементацията. Надявам се обаче да не са следвали философията на АРМ, щото според нея тия достъпи трябва да се следят външно за колкото региона/памети реши конкретния производител. Ако е така то ексклузивния достъп ще си бачка, независи от кое ядро го правиш. От подобно нещо има смисъл за региона с перифериите. Примерно аз го ползвам за GPIO, за да може различни нишки да си конфигурират различни пинове без да стават инфекции (какъвто беше кода на ST навремето).
Та това ще е полезно и между ядрата... Но от друга страна аз използвам ексклузивен достъп на много места и даже на едно и също ядро никите с нисък приоритет често им се налага да циклят, тъй като е реализиран само 1 регион и прекъснат ли те, гориш винаги. А с две ядра ще е кошмар, затова се надявам всяко ядро да си е за него, ама дали е така - не знам.


Нед Ное 24, 2019 8:40 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: RTOS
ох... ние се чудим за синхронизация между куровете, а те още им седи стария код:

Код:
        /* Configure Alternate function mapped with the current IO */
        temp = GPIOx->AFR[position >> 3U];
        temp &= ~(0xFU << ((position & 0x07U) * 4U));
        temp |= ((GPIO_Init->Alternate) << ((position & 0x07U) * 4U));
        GPIOx->AFR[position >> 3U] = temp;
      }

      /* Configure IO Direction mode (Input, Output, Alternate or Analog) */
      temp = GPIOx->MODER;
      temp &= ~(GPIO_MODER_MODE0 << (position * 2U));
      temp |= ((GPIO_Init->Mode & GPIO_MODE) << (position * 2U));
      GPIOx->MODER = temp;

    и т.н. и т.н.


Това не работи и на един кур, какво остана на два... А не е като да не знаят, преди повече от 10 години хората им бяха казали и имаше и няколко теми из форума им.


Пон Ное 25, 2019 10:17 am
Профил
Покажи мненията от миналия:  Сортирай по  
Отговори на тема   [ 77 мнения ]  Отиди на страница Предишна  1, 2, 3, 4, 5, 6  Следваща

Кой е на линия

Потребители разглеждащи този форум: 0 регистрирани и 7 госта


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

Търсене:
Иди на:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.
Хостинг и Домейни