Цецо, само една скоба да отворя - за ембедед система динамично алокиране на памет не е много добра идея. Предполагам си го знаеш де

Абе то ембедед вече е малко относително понятие, системи с по 1ГБ рам ги водят ембедед, та колко да е лоша идея. Но случая не е такъв разбира се.

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

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

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

хмм... зависи дали можеш да ползваш динамична памет надеждно или не

Под С наистина е трудна работа, обаче с Ц++ не сме имали и капка грижа...

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

Това което ми харесва на твоя ОС е, че априори е писан за ARM. Всички други се опитват да подържат 8 до 64 битови контролери, с всевъзможни вътрешни концепции, което просто няма как да стане като хората и сорсовете започват да стават едно голямо мазало....

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

Другото което ме притеснява е C++. Никога не съм го търкалял върху контролер и незнам там какво да очаквам.

От Ц++ може да очакваш само хубави неща, това ти го гарантирам! Без значение дали ще ползваш моя ОС или не, изобщо не се замисляй на тема Ц++.
Един от примерите е точно динамичната памет. Докато бачкахме на чисто Ц постоянно се "ядеше" от някъде, а трябваше да ползваме щото един веб броузър няма как да стане иначе. Откакто сме на Ц++ оставяме нещата в деструкторите и компилатора си се спасява. Не сме имали грижи с течове изобщо!
Отделно Ц++ не е само класове (ООП), сега със шаблоните е просто друг език... естествено иска си малко повече усилия, но категорично си заслужава

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

A за това зависи само колко са ти тежки алгоритмите... Иначе е съвсем нормално една нишка да си отвори някакъв файл, да почне да го обратва и резултът да почне да го мята да кажем на сокет. Пак ти казвам че концепцията ми е стековете и драйверите е да не ползват контекста на клиента и да си работят независимо. Демек ако имаш SD карта, ще имаш някаква файлова система да кажем FAT, тя ще си се врътка в собствена нишка и може да обслужва много клиенти. Ех стига да не искаш да пишеш в един и същ файл едновременно. Но иначе няма проблем 5 нишки да си отворят различни файлове и да си ги четат, която с каквато скорост иска. В съшото време всяка от тях може да ги праща по мрежа/usb/uart...
Нали тва е идеята на един ОС... а не "изчакай да се форматира дискетата и ще ти покажа какво значи многозадачност"

Най-накрая намерих едно проектче дето мяза на подходящо като да закопая из твойта система. Досега беше на STM32F103, сега минава на F401, та реших да го кача върху някакъв ОС. Като цяло е относително просто има 3 SPI (ADC, DAC и едни ключове) и един UART към PC. Има и един I2C дето май ще е мъка.... като му дойде времето. Другата мъка е че ще се ползва FPU-то, а ти май не го взимаш в предвид в конткест суитча, ама може пък да е време да го прибавим.

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

Другото дето ме интересува е как да си натамъня гсс-то за да компилира c++. Нещо ми се мота, че имаше особенности в линкерските скриптове и в стартъп кода, нещо свързано с конструктори и деструктори

Ще търкалям еклипс с нейтив мейк по твоята идеология (с module.mk).

ти да видиш

лошото е, че още нямам поддръжка за М4, не че е кой знае какво... иначе доколкото си спомням F401 е със същите периферии и карантии като на Ф2 така че поне драйверите трябва да бачкат.

Значи, поредността е следната:
1. Пускаш Еклипс и отваряш перспектива SVN repository exploring... Там цъкъш add new... и добавяш url-то на тмос-а. И трябва да можеш да го разглеждаш.. В trunk има две неща - самия tmos и demo_evals (примерчета дето съм се бъзикал). Избираш tmos и му даваш чекоут... и трябва да ти го свали...
Сега аз не качам еклипски файлове, защото няма как да си ги синхронизираме... Затова като се свали е просто "някакъв" проект. Та на еклипса трябва да си го конвертираш до Ц/Ц++ проект. За целта File->New->convert to C/C++ ... и вече трябва да е Ц-проект.
2. Малко настройки на еклипса...
Значи първо е добре да си направиш build конфигурации. Погледни boards директорията и виж какви поддиректории има. Желателно е за всяка поддиректория да си направиш конфигурация. Отиваш в опциите на проекта ->C/C++ build->manage configurations... To ти е направило вероятно default, ти я преименувай до някоя от поддиректориите. Примерно "stm32-p103". След това цъкни таб-а Behaviour (все още си в C/C++ build) и там където са параметрите на мейк сложи съответно
all CFG_BOARD=${ConfigName}
clean CFG_BOARD=${ConfigName}
Като направиш една конфигурация, после като добавяш нови то си ги наследява тия неща. Идеята е че после само даваш име на новите конфигурации и то си знае как да ги компилира.
Ако искаш естествено от команд промпта да компилираш трябва да направиш примерно make all CFG_BOARD=stm32-p103
A от еклипса само избираш от чукчето какво да компилира и то си вика мейка....

Та да си дойдем на думата... В главната директория на tmos или ако ти си направиш проект ще имаш makefile. Той е един и желателно да не го бараш. Мейкфайла търси мк-файл и според неговото съдържание добавя поддиректории. Това би трябвало да ти е ясно. Единствената особеност е, че в boards се добавя $CFG_BOARD, а ти това си го сетнал като параметър при викането на мейка.
Демек идеята е, че всичко е общо за всички проекти, само борд-а е уникален и в неговия мк-файл си указваш кое от общите неща ползваш и трябва да се компилира. Евентуално трябва да си направиш твоя поддиректория с твоя борд... Всъщност там може да набухаш и цялото ти приложение и да укажеш да се компилира до hex/bin. Но не те съветвам.
По-добре си направи отделен проект за приложението, а ОС-а да го ползваш като библиотека. Твоя проект може да има същата структура като tmos. Може да разгледаш demo_evals. Макар че там пак е малко по-универсално... в смисъл там е един проект за мигане на светодиоди и подобни простотии и има няколко конфигурации. Демек мигането си е мигане без значение дали ще мига на лумирари или на ST платка... Просто различните конфигурации на demo_evals генерират фърмуер за различни таргети, като за целта ползват различни конфигурации на tmos-a...

Иначе нямаш грижа за стартъп код... ех всъщност за ST май трябва да направиш LowLevelInit() и вътре да настроиш клоците. Тя е weak функция просто трябва да напишеш твоя версия и тя ще замени кухата лейка...

Нещо не схващам. Имам един makefile в директорията на tmos. Той си е за компилиране на ОС-а. Ама има и един в demo_evals. Дето се предполага че трябва да е моя код. Как се съвместяват двата мейка? Нещо единия ми се чини излишен.

Някъде беше споменал, че main ти е thread, което значи, че някъде в стартъп кода, трябва да пусна шедълера. Отделно си спомням, че когато се компилираше за c++, gcc искаше да имам функции за exit, потоци и т.н. и някакво първоначално иницилизиране на някакви фрагменти от линкер скрипта, свързани с конструкторите и деструкторите дето седеше в стартъп кода. Мога ли да ползвам нещо твое готово като стартъп код и линкер скрипт? Че не ми се търкалят квадратни камъни....

ко? не!

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


Относно кърнела - така е направено, че няма пускане, няма и спиране Не може да излезеш от ОС или да го спреш.... Най-малкото драйверите ми и прекъсванията на ЦПУ-то са едно и също нещо. Не че не може да му изместиш векторите, ама що.... те са си натаманени и няма нужда нищо особено да правиш. Виж в demo_evals... обикновено си правя drivers.h и drivers.cpp. В хедъра описвам пиновете, в срр-то описвам драйверите които искам да имаме. Ти като ги декларираш в DRV_TABLE е достатъчно щото DRV_TABLE е всъщност IRQ таблицата
Там слагаш обаче от IRQ16 нагоре, демек аз се грижа да попълня ексепшъните, ресет вектора и т.н. При ресет вектора си викам драйверите с DCR_RESET, те си се инициализират и всичко си тръгва общо взето.
Нямаш грижа за low level-a... трябва да имаш един main() който аз се грижа да тръгне в контекста на нишка и е малко особена тая нишка щото го играе и idle таск, демек от мейн не може да викаш блокиращи функции. Общо взето там си запускаш другите нишки и в тях си отваряш хендъли към една или друга периферия. В момента в който за първи път дадена нишка отвори да кажем UART5 той си се включва, конфигурира според режима дето си подал на хендъла и тръгва...

Мисля че имам всякакви нужни щуротии за exit, за Ц++ статичните конструктори и т.н. Поне при мен всичко уж си е в ОС-а и в отделните проекти нищо не правя. Има една особеност обаче... Тая версия на ОС-а си остана с един трик че ползва два регистъра на проца, беше за скорост (кърнела не ползва RAM) и така си остана. Страничният проблем е, че трябва да слагаш tmos.h навсякъде, защото иначе компилатора може да се изкуши и той да ползва тия регистри. По-лошото обаче е ако ти се наложи да ползваш чужди библиотеки... Аз затова планирам да разкарам тая оптимизация, ама пусто все няма време...
Та не знам какво ще ползваш, особено на тема математики. Аз по принцип съм направил до 64-бит собствени имплементации и мисля че са по-добри от тия на newlib-a... Ама не съм сигурен дали нещо не липсва. Просто съм правил в движение каквото е трябвало

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

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

Относно стартъп кода, дай ми нещо за F2 и ще го нагаждаме за F4. То какво да е различно, освен FPU-то?

Няма два мейкфайла?

Един е... Имах предвид че е по-добре да имаш два проекта. Един за tmos, втори за приложението ти. Във всеки проект естествено трябва да имаш копие на мейкфайла.

За стартъпа, прикачвам ти нещо съвсем елементарно...

Добре де. И как се билдват тия два проекта в един hex (elf) фаил? Извън еклипса.

Относно стартъп кода, всъщност издирвах това - exceptions.S Намерих го де.