Колеги, с какво може да се похвали един хардуерен инженер ? А-ми например с готови и тествани схемни решения за решаването на различни хадуерни проблеми и готови решения. Може да се похвали също и с добре направена и поддържана библиотека за КАД продукта с които работи и т.н. Т.е това са все неща които говорят за неговият опит като специалист, а също така косвено подсказват колко време би му отнело да синтезира и проектира хардуер по задание, който решава даден проблем ... (т.е. колко би бил ефективен по време на работата си) При добра КАД библиотека той ще трябва да направи и въведе само "новите екзотични" компоненти в нея и напълно да реюзва останалите ...

За мен нещата изглеждат по подобен начин и за ембедед програмиста. С какви собственни библиотеки разполага, с какви средства борави (като РТОС, развойни средства и т.н.). Т.е в крайна сметка - колко той би бил ефективен при подхващането на нов проект и с колко "бакграунда му" би му спестил време. Т.е. става въпрос за познаване на развойните си средства (ртос, GUI, стек и т.н.). В крайна сметка - целта според мен е "реюзването на код". Т.е. до колко това което е правил през годините е организирано и направено по начин позволяващ използването му (ако не без модифициране- то с минимално такова) в нови проекти.

Както Миро казва - "много са важни основите върху които ще стъпи даден проект".
Да - определено има много различни РАБОТЕЩИ вариянти и решения с които да се направи даден проект. Освен това напълно приемам подхода на Пирев за постепенната модификация и къстъмизация (еволюция) на използваният софтуер, но в крайна сметка в един момент натрупването на знания и опит води до момента в който като че ли е по-добре всичко да се направи отначало. Еволюцията се прави малко или много с "кръпки" и преправяния. При едно евентуално пренаписване - всичко това би било изчистено и рационалните елементи биха били заложени в идеологията на софтуера.

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

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

Та мисленето в момента ми е насочено по-скоро от гледна точка на това как да повиша "ефективността" си в работата, за да мога по-бързо да завършвам проектите и то с по-малко бъгове в тях (реюзването на код е добра стъпка в тази посока).

А иначе РАБОТЕЩИ решения и вариянти - колкото искаш.

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

Кое е сложното на забраняване/разрешаване на прекъсванията - има си по един бит за IRQ и FIQ за ядрото. Това че не е отделена специална инструкция само олекотява декодера. Отделно самият interrupt контролер в конкретния чип може да има глобален бит, а всеки interrupt почти задължително си има собствена маска. Говорим за ARM7TDMI ядрото а не перифериите накачвани от разните производители, нали?

А диспачването на IRQ е решено много елегантно (IMHO) във SAM7 на Atmel - една инструкция.

Кривини в ARM7 има естествено, но къде ли няма? От аргументите досега които съм чувал за това че Кортекс е "по-микроконтролерен", мога да приема само един - наличието на битови операции. Никой не повдига тема за недостатъците му, а би трябвало да има.

Ами пробвай да ги пипнеш тия битове в thumb instruction set или user mode и ще си говорим пак

1) BLX? Thumb е компромис. Повечете MCU-та нарочно имат 32-битова бърза статична RAM за такива (системни) фрагменти.

2) манипулации на прекъсванията нямат работа в user mode, нали? [/b]

blx се поддържа от версия 5 и нагоре; арм7т е версия 4т

както каза шопов няма такова животно в ARM7


компромис при който ти прави по-кратък код (хабиш по-малко флаш) и в чипове като SAM7 имаше и повече MIPS щото над 30MHz флаша иска wait states и за ARM set не можеш да извличаш инстрункциите с такава скорост.


Не мерси! имам достатъчно големи нужди за RAM та да я прахосвам като качвам код.



Според мен мястото на юзер тасковете си е в юзер моде, а забраната на прекъсванията се налагат ако правиш критични секции/семафори, а такива се ползват често от юзер таскове


Както и да е, мен тая работа ми е през оная работа... аз прекъсвания не забранявам, който иска да забранява

Стига бе, какво забраняване на прекъсвания в user mode. Още не съм видял процесор,
дето да го прави. Нали смисълът на тоя режим е да не може кодът ти да обсеби или срути
системата, като забраниш прекъсванията и влезеш в цикъл например. Кодът, който
маскира прекъсвания, си работи в supervisor mode и толкова - ако и да е user task.
Повечето embedded програмисти, дето не щат и да чуят за RTOS, просто карат
непрекъснато само в supervisor mode... за малки системи това си е ОК.
В power механизмът, дето го споменах преди, позволява "atomic" операции да се правят и
в user mode, ама то там много работи са както трябва .

Колеги,

Благодаря много за участието Ви в дискусията.

Със сигурност ше се допитвам отново до вас за мнение и съвет, когато имам нужда от това.

Уф.. ама разбира се че това е смисълът, ама това го знаем аз и ти дето работим на такава архитектура!
Аз говоря че повечето от наличните ОС-ки са разработени оригинално за 8 или в най-добрия случай 16-бит *контролер* без режими и т.н... И когато са ги портвали за АРМ никой не си е поиграл да оправи организацията. Блъскат всичко в един режим, пускат системните функции в юзер стека и контекст. И забележи забраняват прекъсвания когато влизат в критични секции, щото на тях такива са им оригиналните сорсове... За тях важното е да кажат "ето нашия ОС работи за АРМ7, за Кортекс и т.н."
А пък как работи - на кой му пука? Представи си как би изглеждал ОС писан за 8051 и портнат за PPC .... Ай сега си представи, че freescale пуснат едночипови PPC (без външна шина) и само с 8К или 16К RAM. Долу-горе така стоят нещата при АРМ7... има истински ОС-ве, обаче те не се побират в едночиповите. А тия които се побират са 8-битова боза...

Предимно @miro_atc:

BLX - няма го, да. Мой пропуск (и най-вече на арм-атуристите). Малко повече игра с "BX".

Thumb - точно това е компромисът. 16-битова шина, по-малко кодец - за сметка на известни неудобства.

А малко кодец в бързата 32-битова RAM си е неизбежен за системни нужди. Не бих му казал "прахосване", просто оптимално използване.

За "user mode" явно сте ми схванали хумора. Чак след последния пост разбрах Миро - той всъщност недоволства от морето от RTOS бозици (ей, ама сегмент има там) а не от самия ARM.

Ми те отдавна пускат (но не съм ги ползвал, де). Напоследък даже изкараха малко
по-едрички едночипови, http://www.freescale.com/webapp/sps/sit ... dG06C1427E

Гледах ги веднъж, малко са прекалено автомобилно ориентирани - те за такива ги и правят
и рекламират, де - ама стават за доста работи. RAM-ът стига до 384k - ама това май не беше
на най-удобно изглеждащия, не помня.

Но то на едночипови много място за ОС няма, аз обикновено скалъпвам някакъв кернел
според случая и присаждам каквото ми потрябва от библиотеките за по-големите.
Такива "големи" едночипови не съм ползвал, де. В 384k бих могъл да подкарам
доста, е, tcp/ip стекът ще го посвия, сега по подразбиране отваря до 512 едновременни
връзки (лудост, разбира се, никога не съм го напълвал дотам дори и за проба),
ама пак доста нещо ще се събере.

ARM v4 не е лоша, но писачите на ОС-ве не се възползваха, даже напротив... Предполагам това е причината "арм-атуристите" да се върнат към обикновената контролерска архитектура. За мен това ще е стъпка назад, но пък малките ОС-ве ще работят по-добре на куртекс...


@tqi, аз ако имам 384к ще се оженя пак бе

Очаквах да ти се види така, затова и постнах линка .

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

после ще почнеш да мрънкаш за кофти архитектурата.
що не можели (двете жени) да са в симетрична архитектура, как не можеш да вкараш поне едната в supspend mode, колко ресурс ти отнема превключването на контекста, колко мразиш в критична секция да получаваш интеръпт и от двете места едновременно. и всичко опира до разделянето на еднобитовия ресурс, дето не може да се шерва.