Здравейте, на всички.
Един въпрос ме мори от известно време:
Какво става ако различни задачи искат един и същ ресурс?
Нека си представим, че имаме MCU с SPI и на него са закачени различни модули - EEPROM, други MCUта и т.н. Нека имаме различни задачи, който се превключват от прост диспачер, който цъка от таймерната система и задава времеви интервали за изпълнение на всяка една. Ако да речем всяка локва SPI по време на нейното изпълнение и вземе да се прецака, следващата няма да може да използва ресурса. Друг сценарий - текущата работи нормално, обаче става критично събитие, което трябва да се отбележи в EEPROMa ( отпада захранването например), ама в момента друг използва жицата .
Ако се използва нещо като прост драйвер, който да има вход, опашка, където са записани заявките в някаква структура ( имаща и преоритетно поле), той да анализира опашката и според преоритета да извършва операцията, без задачите по нагоре да локват ресурса локално в себе си и ресурса да се контролира единствено и само от драйвера. Зора е че незнам подхода дали е правилен и работещ ( за работещ трябва да го пробвам естаствено ). Ще се радвам да чуя вашето мнение .

добра идея, но си има недостатъци:
1. Ако по SPI е започната "дълга" операция, точно когато ни потрябва бъса, тогава какво правим?
2. Ако се наложи да се облужват и прекъсвания, бозата е пълна.
За критични приложения с прост хардуер няма да стане. Аз ползвам CPLD, което да ми мултиплексира шината. Така нямам проблеми. Ако спешно ми потрябва, устройството, което е било адресирано до момента остава със статични сигнали, докато свърши "критичната" задача.

както виждаме, М$ и със сложен хардуер не могат да го постигнат...................

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

Затова и винаги съм се чудил, как може да се пускат микроконтролери от висок клас с един UART или един SPI (например ARM, BlackFin на Analog Devices). Това си е наказание.

решението на проблема зависи от конкретната платформа която използваш...
Иначе на теория нещата обикновено са разделени на задачи и система от драйвери. Системата от драйвери се прави в някаква йерархия - bus driveres, class drivers, device drivers, virtual drivers и т.н.
Комуникацията между таскове и драйери става със заявки. Конкретно в твоя пример грешката ти е на логическо ниво - казваш че таск ще заключва SPI. Не се прави така... Правиш си драйвер за SPI, правиш си драйвери за различните SPI модули - да речем ЕПРОМ, над него ако искаш слагаш някакъв драйвер за файлова система.
Примерно когато искаш да пишеш по епром, таска ти изпраща заявка към драйвера на епрома съдържаща данните за писане. Драйера на епрома вмъква в завяката ти, или да речем прави още една заявка съдържата командите за запис. Двете заявки се обвързват по някакъв начин и се пращат от епром драйвера към бъс драйвера (който в случая е SPI но може да бъде I2C...)
Аз по принцип избягвам да ползвам заключвания - предпочитам свързани заявки. Всеки драйвер си обработва заявките които са в опашката му (може да ги пренарежда по приоритет, но не може да разкъсва свързани заявки).
В много операционни системи обаче има заключвания - ползват се семафори, но обикновено има различен тип семафори. С нормален семафор се синхронизира момента на подаване на заявка към драйвер, т.е. един таск като почне да подава заявка да не може да бъде прекъсван от друг таск който иска да прави същото нещо. Между драйверите се ползват друг тип системни семафори (при условие че ОС-а ползва вложени прекъсвания, или отложена обработка на прекъсванията).
Но забележи че и в двата случая няма заключване на драйвер от таск. Един таск може да заключи друг таск, но не и драйвер...

миро, то това дето го казваш е много хубаво, ама във въпроса беше вмъкнато MCU - което във 90% от случаите значи 16-тина К рам. За кое по напред - за таск менажер ли, за драйвери ли, за операционна система ли?

А и специално SPI-я е интерфейс който е мислен когато ... абе знаете кога.

Аз затова избягвам да закачам повече от едно устройство на SPI. Или ако ще закачам, то поне да са устройства дето се ползват едно към гьотере, часовници, батерии и пр, или да са устройства изискващи еднотипен достъп - например няколко памети.

Но колкото и драйвери да вложиш, едва ли можеш да пуснеш по един порт ADC семплиращо на 100uS и Ethernet контролер.

Може да изглежда на пръв поглед тъпо, ама ако SPI-а се реализира с просто клатене на PIO-та, много от проблемите за които се споменава просто ще отапднат; Така и SPI интерфейси колкото му на човек душа иска. Реализира се с няколко реда програмен код. Ако функцията по трансфера бъде прекъсната - то тя продължава след малко. Това естествено е възможно само ако устройството дето е закачено не е динамично, т.е. позволява спиране на такта. Това май не важи например за майкрочипския етернет. Според зависи от логиката, софт SPI-а може да бъде скрит в съответния драйвер на устройство.
Недостатък на подхода: Процесора е зает с трансфера.
Предимство: SPI-а може да бъде на които и да e PIO-та.

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



а къде ги закачаш? Щото аз правя точното обратното - закачам колкото се може повече устройства на SPI и го държа поне на 10Мбита. Поне МЦУ-тата дето ползвам нямат по-бърз интерфейс, иначе за бавните периферии като часовниците много по-просто става с I2C/TWI