Как го мериш това? Много тромаво ми се вижда... затова проверих при мен с два таска, единия с нисък приоритет само праща сигнали, а другия отгоре чака сигнал и клати пин...


тва е F2 на 120MHz и за един период има 2 свича, демек средно около 1.9us на свитч + сигнализациите му...

Всъщност, числото което дадох е може би не съвсем коректно - по-скоро е завишено нагоре.
Това го мерих, за да определя от какво закъснение нататък (по-малко от един тик) има смисъл да сменям контекста.
Постановката е следната - функцията за закъснение инициализира таймер и започва да чака на семафор - т.е управлението се предава на друга задача. Освен това, тъй като заявка за такова закъснение може да дойде от различни задачи горе долу по едно време, се поддържат 4 канала и се определя кой е свободен в момента. При прекъсване от таймера се поства семафора и управлението се връща към задачата, която е извикала фунцията за закъснение. По аналогичен начин клатих пин и установих, че минималното закъснение е около 20 us (точното число не го помня), затова и сложих граница от 24 микросекунди, под която закъснението се прави без смяна на контекста.

За ARM използвах CoOS, нямам забележки, кода е прилично написан, ако нямате скрупули, че е китайска, може да я използвате. Почти не се налага да се разучава, може да се използва out of the box, както казват наглосаксонците .

Task switch 1.5us, STM32F103RB CPU with the system clock setting to 72 MHz, code execution from internal flash, with Flash Latency 2 wait states and the Prefetch Buffer enabled.

Миро, почвам да те разбирам що псуваш толкова периферията на STM32. Като гледам как са описали HAL-а в ChibiOS... страшна боза. Ама наистина страшна. Ама то тоя контролер просто не е правен за да го вкарваш в някакви такива тесни релси.

ахъ... и то като имаш предвид, че чибито не се стараят да унифицират HAL нивото.
При мен се усеща повече, защото като има примерно 15 ДМА канала аз не правя 15 ISR функции, а само една защото драйверът е един, а инстанциите му може да са колкото искаш

Всъщност в момента се боря с това тъпо DMA, че ми дава fifo error и що ми го дава не мога да разбера, то и документацията е толкова пръсната, пък аз ме мързи да чета... Ама ще го разбера де

Иначе скоро ще имам работещ порт за STM, няма да се откажа... Всъщност повечето вече работи gpio-та, uart-и, spi... остана да ги подкараме и ДМА-та, а USB и етернет, ама за тях не се притеснявам (уж съм ги гледал).
Кодът всъщност за ST изглежда значително по-прост, ама това е защото и перифериите са прости. Примерно при Луминари там има 16 байта ФИФО дето се шерва обикновено и за приемане и получаване и си иска логика. При SPI примерно смятам колко да натъпча, тъй че да не се препълни при получаване и т.н. Докато STM-а няма таквиз чудеса и особено без ДМА логиката е малко и кодът изглежда даже прилично.
Искам да кажа, че с бозата се оправям, единственият проблем засега е, че някои функции на перифериите просто ги няма. Примерно 9-бит SPI... поне за F4 да бяха го сложили, а то само на F0 и F3...

Това ChibiOS и то простее... Може ли message queue - тата му да търкалят само на ниво байт??? Баси, поне на 32 битова дума да го бяха отпушили... То така един пиклив пойтер не можеш да предадеш, ебати queue-то! Това пък въобще не съм го очаквал, докато не ми потрябва. То така освен да стримва серийни данни, за нищо друго не може да се ползва.

Егати, а аз си мислех, че FreeRTOS бил орязан...

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

Цецо, в началото на темата казах, че не си наясно какво търсиш... и като гледам още е така

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

Смисълът да имаш операционна система е да можеш да правиш много неща паралелно. При това да работи безотказно. Ако се дъни файдата от паралелната работа е много малка, но вредата повярвай ми може да е огромна. Чакам просто да стигнеш до положение с 20-30 таска и да се появи проблем, да те видя как ще го гониш и как ще дебъгваш.
А той ще се появи гарантирано, защото без драйверна система трябва да си софтуерен гений за да не сгафиш. За да ме разбереш ще ти дам пример - да речем пускаш някакво GUI, там клатиш пинове за ресет на LCD и т.н. Тръгва и си щастлив. После пускаш някакво твое АЦП дето и за него клатиш пинове от същия порт. Но и то тръгва... О, чудо! После добавяш някаква обработка дето няма нищо общо с пинове, но изведнъж АЦП или LCD-то почват да се дънят.

Кво праиш, а?

Дали ще се сетиш, че се дъни щото си изместил тайминга на иначе "работещи" таскове и те по едно и също време тръгват да конфигурират пин, което в Чибито не е thread safe операция? Или ще си кажеш, че стария ти код е работил и нещо в новия код си омазал я памет я нещо друго и ще тръгнеш да търсиш Лукавия на грешното място? Още повече че като почнеш да дебъгваш или добавяш трейсове таймингите се променят и проблемите се появяват и изчезват мистериозно...

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

Каквото такова... друго дето да търкаля USB CDC върху STM засега не съм открил.

http://embeddedsoftwarestore.com

Тука има листнати цени на разни RTOS, libraries, etc. ... Micrium избиват рибата - $54к

Edit:
Micrium TCP/IP - $74k
разни аудио кодеци по $70к ...

тая цена не е толкова за продукта, колкото за поддръжката му предполагам....

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

Луда работа, ама евала им. На това се вика добавена стойност...

П.С. Ти докъде стигна с УСБ-то? Планираш ли подръжка на профили за Mass Storage и CDC. Как решаваш проблемите с VID, PID и драйверите бод боза, или те не са твоя грижа?

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

Иначе класовете ми са нещо като мини-драйвери, демек не зависят от платформата. На теория има поддръжка за повече от една функция на девайс, ма на практика никога не съм го тествал, чакам да ми се наложи. Това не ме притеснява колкото това, че нямам хост (само гол скелет е)...

PID-те не са моя грижа
Лузера трябва да даде дескриптори с PID, VID и т.н. от там насетне каквото даде такова...

Мда. Принципно е така, работа на лузъра е....

А не разбрах, за кое нямаш достатъчно документация? За USB-то на STM-a ли? Не, че съм я чел де, аз съм лузър.

Съдейки от досегашните включвания SD карта драйвер ще имплементираш, нали?

На чибито, CDC-то върху F1 работи стабилно... като че ли. В смисъл пуснах прост UART <-> USB бридж и работи. Ама колко е бърз не съм тествал.

Документацията на STM-a е меко казано постна. Изброяват фючърите, после регистрите и от там нататък всеки да се спасява както може. Даже дефиниции на регистрите няма в периферната библиотека, ами са изнесени в usb библиотеката, дето очевидно е писана от други хора. Съвсем различен стил и пълна каша навсякъде. Не ми е за пръв път да си правя собствени дефиниции, но за сефте не мога да го направя по дейташит. Един и същ регистър има 4 (четири) различни имена в различните чаршафи. И при най-добро желание просто няма как да направя дефинициите да съответстват на чаршафите.
Но по-големият проблем е липсата на описание кое как работи. Примерно не описано как се правят трансфери, още повече че усб-то им е доста различно. При всички останали първо тъпчеш данни във фифото и после потвърждаваш, за да почне да ги праща. Тук първо казваш колко ще пращаш, после гледам всички чакат прекъсвания и накрая дават данните. Няма никаква логика или поне аз не я схващам. За сметка на това има много неясноти. Както и да е.... ще се борим

За SD картите при мен са мини драйвери. Имам един файлов драйвер нещо като роот. Драйвер е понеже се грижи за синхронизация между клиентите (таскове). После са мини драйверчета за устройства - като SD, серийни флашове (29-а и 45-а серии) и накрая са файловите системи (няколко къстъм + FatFs). Всичко това е готово, в смисъл не зависи от марката на професора... Но не го публикуваме като опън сорс най-вече заради къстъм файловите системи. Макар че би могло да се отделят sd-картите и fatfs. Просто не ми се ще да разделям файловите истории на публични и непублични. Знайш кво хубаво са си събрани на едно място

Между другото като спомена mass storage и sd-карти, за нас по-голяма файда би имало тоя медия файл класа дето може да се мапва диск на високо ниво. Така хем устройствто може да продължи да си бачка, хем да се виждат файловете от усб хост. Може да се пробвам да го направя, ама първо трябва да приключа с усб стека...

@miro_atc

човек, стана ми интересно какво пишеш, но почти нищо не разбрах... най-напред - ти 'host' ли си, или 'device'? а какво имаш впредвид под 'медия файл класа дето може да се мапва диск на високо ниво'?

занимавам се от известно време с usb device неща за stm32f103; миналата седмица прецених, че ми трябва като си включа устройството, което дялкам - хем компютъра да го вижда като mass-storage, хем с моята пц-програма и аз да го управлявам (по отделни канали - 'endpoints'), но по едно и също време; за целта нагодих chan's fatfs (http://elm-chan.org/fsw/ff/00index_e.html) към моя фирмуер, предекларирах устройството като съставно (composite), преработих device дескриптора да обявява общо два интерфейса (единият за mass-storage, другият custom - за да мога да контролирам същинската част от устройството), в конфигурационния дескриптор (да кажа пак - става дума за 'composite usb device' - т.е. съставно устройство - с една конфигурация, но с повече от един интерфейс, а не за usb-multi-function-device - устройство с повече от една конфигурация), добавих дескриптори за интерфейса за моето custom устройство, и, доколкото помня, код почти не написах; така, като включа устройството - компютърът (пробвах го и на виндовс, и на линукс), открива mass-storage частта от устройството безпроблемно (и вече може човек да работи с него свободно - просто още едно usb-flash-drive устройство), а за custom частта виндовсът пита за драйвери, линуксът не пита; ползвам winusb под виндовс, libusb под линукс; по този начин вече имам възможност през пц-то (напр. през windows explorer) да променям файловете върху устройството, а с custom пц-програмата да упражнявам контрол кога промените се вземат под внимание, и да получавам информация за състоянието, и евентуални грешки, в устройството; един вид - две устройства накуп (composite usb device); фирмуеърът осъществява достъп до файловете с помощта на chan's fatfs библиотеката - много добра и удобна се оказа за мен

нещо такова ли правиш, или тотално не мога да те разбера? интересно ми стана с какво се занимаваш...