board_setup трябва просто да го имаш в проекта (приложението), за включи някаква честота...

линкерския скрипт трябва да ти е ясен...
mk файла е интересен... Значи пак да обясня в случая се ползва stm_boot1 конфигурация на ОС-а. За нея имаш всичко, тя си компилира. Ако си свалил tmos, в команд промпт пишеш make all CFG_BOARD=stm_boot1 и толкоз. То си прави в out изходните неща..
В случая обаче има и втори проект за приложението (демек буутстрапа). Него не ти го давам... но той не ти и трябва. Та тая проект пак си има главна директория, със същъя мейк файл (1:1). И също може да има различни конфигурации... що, щото може да имаме ревизии на платките, да ползваме различни процесори и т.н. Та за да е гъвково спесифичните неща ги правим на конфигурация. Само че вместо boards по принцип си правим targets директория. Съответно се компилира с make all CFG_TARGET=xxx... Идеята може да я видиш в demo_evals. Ta в един от таргетите е въпросният мк-файл, както и драйверсите дето съм прикачил..

Не знам какво те обърква точно. Има конфигурации, щото така ни се налага. Рядко правим едно нещо само в един вариант. Ти сега ще почнеш с един вариант, т.е. ще имаш само един таргет в приложния проект... и така докато не ти се наложи да пипнеш платката си. Е те тогава и ти ще имаш повече от един. Желателно е още от сега да свикнеш да разделяш специфичните неща дето са обвързани с конкретния ти таргет/платка от приложението дето евентуално целиш да е малко по-универсално...

всички конфигурации на tmos се бюлдват както казах:

make all CFG_BOARD=xxx

където ххх e името на съответната конфигурация. Примерно както казах вече:
make all CFG_BOARD=stm_boot1

това прави в out/xxx разни неща... какво точно прави може да видиш в tmos/boards/stm_boot1/module.mk . Tam указваш къде да го направи (OUT_DIR), с какво име (OUT_NAME) дали да е библиотека/хекс/бин (BUILD_BIN/HEX?LIB) какъв проц, фамилия и т.н. (различните USE_xxx - от тях зависи какво точно ще се компилира от ОС-а).

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

Абе аз май го схванах, ама чакай да видим.... първо си билдвам TMOS-a за даден борд до либ фаил . И после си линквам приложението с тоя либ.

То това хубаво, а как ще го дебъгвам? Ще се оправи ли еклипса (Zylin) като скачам из сорсовете на TMOS-a?

така правя аз...


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

Уф и аз така. Утре ще пробвам.

спомена дебъг та се сетих да ъпдейтна .gdbinit в demo_evals... Вътре има няколко скрипта за GDB дето може да са ти полезни в началото:
tt - показва тасковете дето са активни и тия дето чакат за таймоут. Ако jtag-а ти може да поддържа ОС-ве и най-вече ако може да се конфигурира може да се пробваме да го настроим. В случай че искаш да виждаш тасковете в еклипса де...

mem_info - показва дережето на динамичната памет. Полезно е ако имаш съмнения че си я омазал Общо взето ако мажеш по паметта гърми или динамичната памет или мажеш стек. Стековете на статичните нишки се инициализират с константа, така че като го принтнеш ако започва с шарения значи или си го омазал или си го препълнил. Принтването е просто print (p) и името на променливата знаеш предполагам. В случая стека е масивче дето носи името на таска + "_stack". Примерно ако имаш test_task стекът й е test_task_stack

И скрипта дето ползвам най-често е "cc" - това ти прави ресет, само че ползвам PEEDI команди в него и евентуално трябва да си го портнеш за джейлинк, оцд или каквото ползваш.

По принцип ако стартираш GDB от команд промпта той май си проверяваше дали нямаш .gdbinit и си го зареждаше. В еклипс обаче ти трябва да му го укажеш (в настройките на zylin-a)

Още умувам дали да се захващам, тоест дали ще ми стигнат силите... бая нещо има да се промени заради F4. Айде перифериите ще ги вземем почти наготово от F2, ама нещата около ядрото ме притесняват, основно в частта с FPU-то. Притесняват ме и тези 2 регистъра с които си прибрал за кърнела. Като цяло математики ползвам... "math.h" - sqrt, float аритметики, тук таме sin и т.н. Общо взето неща които нямам нерви да пиша от 0 и да оптимизирам. Затова и ръгам процесор с FPU, да не се занимавам аз с тях. Планирах да ползвам и CMSIS библиотеките за математика....

Отделно, че има доста код в ports, който трябва да се прибави за cortex-m4. А там ти си маал на асемблер, пък аз там плувам малко като в катран, хич не съм убеден, че мога да се справя...

ports не е проблем, то всичко което е там е валидно и за М4. Може би трябваше да го кръстя cortex-m само без 3-ката..

FPU-то се надявам да стане лесно, то и няма никакво отношение към ОС-а щото той не го ползва. Просто при смяна на контекст ще трябва да се спасяват и fpu регистрите, мисля че по оня метод с мързеливия алгоритъм ще е най-добре..

За 2-та регистъра трябва да намеря малко време да ги направя опционални, тва така или иначе трябва да го направя, просто на мен не ми е трябвало досега

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

Миро,

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

Как ще забранявам прекъсванията преди всяка math функция... то ще стане ебати риал тайма-а...

спомням си, ама това е грозно

ще ги оправя тия регистри...

май ги оправих...
ос-а няма да ползва регистри, ако в brd_cfg.h има:

Желателно е след промяна на тази стойност да се направи clean, че направих някои промени с хедърите и dependancy-тата може да не се усетят...

Да не цапаме другата тема, ще пиша тук

Защо лиценза е GLP3 ?
Принципно за RTOS е вързващо ръцете ако някой иска да го ползва комерсиално - т.е. или добави и комерсиален лиценз или пък го смени на LGPL, BSD, MIT и т.н. разрешаващи. Като, че ли LGPL пасва най добре в случая - хората са длъжни да публикуват промените които правят по твоите файлове, но няма проблем да линкват компилиран ОС-а в комерсиални продукти.

Яд ме е, че толкова труд не може да полути по-широко разпространение. Проблема е в документацията. Повечето потребители на подобни творения по дефиниция сме тъпи - искаме API-та. Мразим да ровим сорса... Аз като я погледнах първия път и се облещих... От тогава през ръцете ми са минали FreeRTOS, ChibiOS, MQX, в момента Nuttx. И чак сега почвам да разбирам идеологията на твойта. А без документация, човек трябва да разбира из основи как се търкаля, иначе просто няма как да го ползва. На теб ти се струва, че всичко е еднотипно... ама е еднотипно в твойта глава, защото ти си го писал. Човек отвън го гледа като индианец пишеща машина.... поне аз де.

Реално повечето хора които търсят free ОС, първото нещо, което гледат е дали има добра документация. Следващото нещо е какви примитиви има - на твойта и липсват опашки, мутекси и семафори, ама да кажем това не е проблем да се добави.

Ценното на твойта е, че е максимално оптимизирана за АРМ и седи като концепция някъде междъ бързината на FreeRTOS и функционалноста на по сериозните. Защото нута и MQX са наистина сериозни, ама няма да ти казвам за колко време превключват контекста. Трагедията е толкова голяма, че изрично пишат системния тик да не се пуска на по-малко от 10ms и то на процесори по 150+ MHz. А прекъсванията са ги навряли всичките в един вектор и забравяш за вложени прекъсвания, преоритети и т.н. И двете нямат възможност за прекъсвания над ОС-а. Тоест имат, ама с толкова условности, че все едно нямат. Предполага всичко това е защото се опитват да подържат много платформи....

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

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

Мисля, че и по-горе в тая тема го обяснявах.... Тоя ос не го пиша за кеф, нито пък за продажба нито за чест и слава. Пише се щото ни трябва за комерсиални продукти и то не мои продукти.
И ще изпадна в малко деликатна ситуация ако почне да се ползва от конкуренти на моите клиенти/работодатели. Принципно не би трябвало и това да е проблем, ама аз предпочитам да си вържа гащите. С две думи ако някой иска да го ползва за фискални устройства, POS терминали и неща от тоя дух имаме проблем, пак може да се ползва ама по реда на GPL
За друг тип приложения, няма грижи. В крайна сметка идеята не е да се ползва от милиони хора, а от малко и сериозни разработчици, така че те да са част от екипа, съответно носители на правата. И за да няма конфликти, най-добре е да не сме преки конкуренти и естествено те да нямат нищо против ние да си ползваме техните промени в нашия бизнес, така както и ние нямаме нищо против обратното. Аз и на Цецо казах, няма проблем това да се оформи и документално... поне доколкото разбирам от право, едно нещо може да е с повече от един тип лицензи.