Виж темите без отговор | Виж активните теми
Дата и час: Пет Мар 29, 2024 11:53 am
Въпрос относно собствена библиотека за pic32mx
Автор |
Съобщение |
dan
Ранг: Форумен бог
Регистриран на: Вто Май 29, 2007 1:23 pm Мнения: 3545 Местоположение: Високо в планината
|
Re: Въпрос относно собствена библиотека за pic32mx
Кой виц
_________________ Хайде де!
|
Пет Яну 31, 2020 5:53 pm |
|
|
miro_atc
Ранг: Форумен бог
Регистриран на: Нед Фев 26, 2006 5:52 pm Мнения: 10356 Местоположение: Добрич
|
Re: Въпрос относно собствена библиотека за pic32mx
gicho много пъти съм споменавал, че под ОС се разбира набор от техники и концепции. Техниките и концепциите може да се различават доста, но в основата винаги има един набор от проблеми, които всеки ОС се опитва да реши. Това е характерното за понятието ОС. Ти може да решиш по различен начин тия проблеми. Но това решение само по себе си ще бъде ОС, без значение как ще го кръстиш. Ако искаш го кръсти "боза" или "ракия", но в същината си ще бъде ОС. Затова винаги се заяждам като кажете "аз без ОС мога"... не можете без ОС, защото или решавате проблема или не, но ако го решите значи сте направили собствен ОС. И винаги препоръчвам преди да правите собствен ОС да разгледате как другите решават тия проблеми. И ако не ви кефи нито едно от решенията, ОК - хващайте лопата и се окопавайте
|
Пет Яну 31, 2020 5:55 pm |
|
|
miro_atc
Ранг: Форумен бог
Регистриран на: Нед Фев 26, 2006 5:52 pm Мнения: 10356 Местоположение: Добрич
|
Re: Въпрос относно собствена библиотека за pic32mx
Сина на Бил Гейтс го попитал "тате какво значи многозадачност?". При което той отговорил - изчакай да се форматира дискетата и ще ти покажа.
|
Пет Яну 31, 2020 6:01 pm |
|
|
ДедоБоре
Ранг: Форумен бог
Регистриран на: Нед Ное 21, 2004 10:31 pm Мнения: 9635
|
Re: Въпрос относно собствена библиотека за pic32mx
идеята на 'драверите' е да използваш един и същи код за работа с аналогичен хардуер. примерно - 'драйвера' за UART е един за всички налични аналогични хардуери (вътре или вън от чипа), примерно UART0..UART10. викаш един и същ набор функции с различни 'дескриптори'
другата идея е 'юзер спейса', или клиента на драйвера да е относително независим от конкретната реализация на 'драйвера'. т.е. една и съща програма да можеш да я скомпилираш за различни архитектури/чипове, без значение какъв е конкретния хардуер (за UART-a)
малко по-високо ниво на абстракция са псевдо-драйверите (примерно протоколни) или драйвери на няколко етажа (UART over SPI/I2C). има случки, при които вътрешните UART-ове са със същата архитектура и регистров сет като външен SPI такъв, и в този случай е логично външния чип да се обслужва от същия драйвер като вътрешния. тука на помощ идва псевдо-драйвер от вида 'бъс-бридж'.
в този контекст, 'драйвера' не само може, но и трябва да е реентрантен, като гарантирано си пази контекста извън себе си (най-често в дескриптор).
|
Пет Яну 31, 2020 6:36 pm |
|
|
gicho
Ранг: Форумен бог
Регистриран на: Пон Мар 13, 2006 12:59 pm Мнения: 3855 Местоположение: Габрово
|
Re: Въпрос относно собствена библиотека за pic32mx
Миро, точно с тази дефиниция на ОС съм готов да се съглася - всяко нещо, което преизползваш правейки следващия проект/устройство. Т.е. дори да е съвсем глупав superloop дори без прекъсвания (а-ла-ардуино), пак си е "ардуино-ОС" защото дава готови услуги под формата на библиотеки и предоставя документиран начин да правиш определени неща. Драйверът сам по себе си не може да стане реентрант без помощна на разни синхронизационни примитиви, които дори да не са от някой известен ОС, пак са библиотечни, преизползваеми услуги / функции. Може да са просто прекъсвания и/или софтуерни прекъсвания, които да дадат аналогията на таск.
Моето виждане е че интерфейсите на драйверите (и каквото и да е друго) трябва да бъдат определени (разработени), гледайки "другата" страна - т.е. не да гледаме какво искат клиентите (т.е. протоколите), а да гледаме за какво е тая периферия. В смисъл драйвера за уарт не се дизайн-ва според протоколите ("имам един модбъс стек, направи драйвера за уарт-а на пикчето да му пасва"), които ще го ползват (модбъс, АТ, ....), а според периферията. Имайки спецификация на уарт или кан правим драйвер, който скривайки специфичните регистри "показва" общоизвестни за тая периферия услуги - пращане, бодрейт, формат на фрейма, приемане, или индентификатор, арбитрация, ... Това е известно като single resposibility принцип - трябва да има само един документ/спецификация, която да може да накара кода да се смени - ако не се появи нова версия на КАН спецификацията няма нужда да се сменя кода, защото само тоя документ присъства в кода - няма posix, няма други "абстракции" и интерфейси, които някой е приел за нужни. Промяната в модбъс протокола не може да бъде причина за смяна на уарт драйвера - по принцип, макар че може да ни задвижи да оптимизираме нещо или да добавим друго, което досега не ни е било нужно. По този начин следващия клиент (протокол) не променя драйвера, щото той по начало не е правен мислейки за даден протокол - така се избягват обърквания. В другата посока обикновено се разчита на опита на писача, който вече е правил 20 протокола последните 10 години, съответно се предполага че ще направи драйвер, който е съобразен с всичките - заради опита си. Само че в другата посока не е нужно да се мисли за това - както споменах там абстракцията е истинския физически модул (уарт, спи, кан), т.е. онова което инженерите са опитали да имплементират в чипа/IP-то, който няма как да не е специфициран. Приложението има нужда да прати CAN съобщение - не му пука за ОС, стриймове (няма ги в КАН) и няма нужда приложника да мисли за тях - те не са му основната работа. API-то на драйвера изглежда познато ако си чел КАН спецификацията и борави с термини, налични в тия документи. Т.е. как ще изглежда интерфейса се определя независимо от специфичната имплементация на КАН контролера, или на уарт-а. Остава да се мисли дали тоя интерфейс да е синхронен или асинхронен - ако търсим асинхронен може да се наложи да добавим фифо-та, таскове и други такива, но това само ако няма подходящи прекъсвания и периферията е дизайнвана от аматьори - ако тя (периферията) си има фифо-та, прекъсвания по ниво на фифото и т.н. цялата верига може да "цъка" в тия контексти.
|
Пет Яну 31, 2020 10:22 pm |
|
|
lubo_88
Ранг: Минаващ
Регистриран на: Сря Яну 09, 2019 8:13 pm Мнения: 19
|
Re: Въпрос относно собствена библиотека за pic32mx
Реших да си поиграя малко и да пробвам това, което е написал gicho още в началото на темата. Но има нещо, което не разбирам как трябва да стане. В дейфаните са базовите адреси на регистрите "UxMODE" на всеки един UART модул (общо 6 на брой). Извадил съм ги от майкрочипския хедер файл. Доколкото разбирам в скобите се извършва тайпкастване, защото пойнтърите трябва да сочат към структури. Обаче, в този случай, какво трябва да се подаде във функцията uartInit(). По - долу прилагам и част от кода във майкрочипския хедер файл за дадения микроконтролер. Никога не съм се ровил във фабричните хедер файлове и сега виждам, че регистрите са реализирани с bitfields.
|
Пет Яну 31, 2020 11:23 pm |
|
|
TheWizard
Ранг: Форумен бог
Регистриран на: Сря Апр 27, 2005 11:48 am Мнения: 4671
|
Re: Въпрос относно собствена библиотека за pic32mx
https://github.com/chipKIT32/chipKIT-co ... efs.h#L334(p32_uart *)_SER0_BASE uart_0; uart_0.brg = 12345; void uart_open(p32_uart * ctx, int speed) { .... } uart_open(uart_0, 115200); ако uart_n[4] и ако имаш файлова система, сокети .... ги индексираш в масив за използвани/отворени устройства, функцията int open_джаджа() ще върне index file_descriptor, който сочи указателя на джаджата и после ако успееш да портнеш NewLib, получаваш базов POSIX.... int fd = uart_open(uart_0, 115200); .... fd = open("file", 0) ..... fd = socket(....) connect( fd, ....) read(fd, buffer, size); <----- работа с "драйвер" printf("ала бала");
_________________ main[-1u]={1};
|
Съб Фев 01, 2020 9:57 am |
|
|
Desert Leo
Ранг: Форумен бог
Регистриран на: Чет Фев 10, 2005 2:25 pm Мнения: 4975 Местоположение: София
|
Re: Въпрос относно собствена библиотека за pic32mx
Колко време е необходимо да се напишат няколкото реда за инициализация на уартите, сравнено с времето за написване на останалия код за този PIC? Гледам, че няма ремапване на периферията, така че уарта или се използва или не в зависимост от конкретната схема. Що трябва инициализацията на уартите да се смесва с писането на драйвер. Ако имаше ремапване на уартите и пика има да речем 3 хардуерни, а трябват повече, тогава има смисъл драйвера да се направи така, че да може да му се укаже какво и къде да предаде или какво и от къде да се приеме, а самия драйвер да прецени кой уарт е свободен в дадения момент и да го настрои.
|
Съб Фев 01, 2020 1:46 pm |
|
|
miro_atc
Ранг: Форумен бог
Регистриран на: Нед Фев 26, 2006 5:52 pm Мнения: 10356 Местоположение: Добрич
|
Re: Въпрос относно собствена библиотека за pic32mx
Това няма никакво значение. За да ползваш УАРТ трябва да напишеш малко код за него. Въпросът е само как точно ще го напишеш. Това беше и въпроса в темата и май само вълшебникът дава смислени отговори
|
Съб Фев 01, 2020 3:02 pm |
|
|
lubo_88
Ранг: Минаващ
Регистриран на: Сря Яну 09, 2019 8:13 pm Мнения: 19
|
Re: Въпрос относно собствена библиотека за pic32mx
Тъй като ми стана интересно, след малко ровене в нета, попаднах на ето тази статия: https://www.edn.com/developing-reusable-device-drivers-for-mcus/В нея, авторът описва подход за писане на код, който да бъде reusable към различни микроконтролери от дадена серия. Като недостатък посочва, че този подход използва малко повече ресурси от MCU-то. След още ровене се оказа, че има книга писана от него, в която разисква по-подробно темата. Ако на някой му е интересно и има интерес мога да я шерна. И все пак, ако вие знаете още ресурси, от където може да се учи относно писане на драйвери и библиотеки, както и добри практики при програмиране на микроконтролери, моля, споделете ги.
|
Сря Фев 05, 2020 7:23 am |
|
|
ДедоБоре
Ранг: Форумен бог
Регистриран на: Нед Ное 21, 2004 10:31 pm Мнения: 9635
|
Re: Въпрос относно собствена библиотека за pic32mx
дай да я видим таз книжка. не обичам да чета код във вид на jpeg картинки с голяма компресия
|
Сря Фев 05, 2020 7:37 am |
|
|
lubo_88
Ранг: Минаващ
Регистриран на: Сря Яну 09, 2019 8:13 pm Мнения: 19
|
Re: Въпрос относно собствена библиотека за pic32mx
Заповядай, Към книгата имаше и прикачени файлове с примери от кода в книгата, но останаха на другия компютър. По-късно ще кача и тях.
|
Сря Фев 05, 2020 7:48 am |
|
|
miro_atc
Ранг: Форумен бог
Регистриран на: Нед Фев 26, 2006 5:52 pm Мнения: 10356 Местоположение: Добрич
|
Re: Въпрос относно собствена библиотека за pic32mx
За съжаление няма по-по-най-добри... Има различни подходи. За някои въпроси един ще ти каже едно, друг точно обратното. Изобщо мненията са в целия спектър и може би са толкова много понеже приложенията на контролерите са много различни. Някои гонят супер надеждност, други гонят консумация, трети са real time, четвърти функционалност и сложност и т.н. От друга страна за всеки детайл има изписани хиляди книги. Примерно как си менажираш проектите, как се мейкват, как се документират, как се тестват, как се поддържат. Все неща, които не са пряко свързани със самия код, но са свързани... Затова аз постоянно повтарям за всеки, който ще си вади хляба в тоя бизнес, че е добре да види *различни* подходи. А после си идва от само себе си, защото едни неща харесваш и се опитваш да следваш, други не. Но едва ли ще намериш всичко на едно място, та затова трябва да се гледа на доста места. В тоя ред на мисли, тук също имаме "различни" гледни точки и едно бързо представяне/запознаване може да е полезно. Аз примерно за моите "опорни" точки си мисля, че най-добрият вариант да ги представя е един скайп с тимвю и да покажа реални проекти, кое как е направено, как работи, какви подходи съм избрал и защо. Надявам се и други колеги биха споделили по един или друг начин (знам че на бира си казват всичко ). С други думи така може да се направи едно бързо запознаване с различни техники. Повърхностно ще да е, ама след това човекът сам ще си реши кое му пасва и иска да задълбава...
|
Сря Фев 05, 2020 10:39 am |
|
|
Zdrav
Ранг: Форумен бог
Регистриран на: Сря Яну 26, 2005 1:01 pm Мнения: 1952 Местоположение: Варна
|
Re: Въпрос относно собствена библиотека за pic32mx
Има едно залитане, да се фокусирате върху драйвери и ОС. Ако центъра е поставен там резултата ще бъде, че работата винаги ще има ексцентритет. Доколкото писането на софтуер следва процеса на моделиране на реално съществуващи обекти и тяхното поведение, ако се фокусирате върху моделиране на апаратната част на МЦУ-тата, това не винаги ще даде необходимата абстракция за да се опише цалостната фунционалност на устройството или системата която се разработва. Но пък един ден може и да стигнете до идеалното описване на едно МЦУ. Апратната част на МЦУ-тата е несъвършена, не добре обмислена и най-често проектирана да бъде пенкилер - GeneralPurpose. Ако отгоре и направите един HAL, накрая тоя който ще го ползва тоя HAL ще му се иска да ви го навре... сещате се къде. По продуктивно е да се фокусирате върху примитиви като опашки, FIFO-та, кръгови буфери, проксита, диспатчъри, арбитри, синхронизирани времеви бази и прочие. Те са по-близо до реалните задачи, и ще вършат по-добра работа вместо един HAL, в който A-то не става и за чеп за зеле.
_________________ Най-опасният враг на истината и свободата е мнозинството.
|
Нед Фев 09, 2020 4:22 pm |
|
|
miro_atc
Ранг: Форумен бог
Регистриран на: Нед Фев 26, 2006 5:52 pm Мнения: 10356 Местоположение: Добрич
|
Re: Въпрос относно собствена библиотека за pic32mx
Между редовете ти се чете, че ОС-ът и неговите драйвери внасят неефективност. Демек внасят код, който иначе би могъл да бъде избегнат или пък заменен с нещо по-ефективно. Истината е, че при добре обмислен проект кодът на ОС-а отнема не повече от 1% процесорно време. Като само 1% от тоя 1% е "излишен". С други думи драйверите примерно работят със същите периферни регистри с които трябва да се работи. "Излишъкът" обикновено се създава, когато се ползват излишни синхронизационни примитиви. По-горе стана дума за пример 1 драйвер и 1 клиент. Изглежда ненужно на пръв поглед драйвера да се синхронизира с повече от 1 клиент, ако никога няма да се появи такъв в проекта. Работата е там, че клиентите по принцип са нишки и драйверите работят в друг контекст. Това е неизбежно, ако в системата има някаква многозадачност. Трябва да имаш приоритети и няма как една нишка да е с еднакъв приоритет като прекъсване. Всъщност може, но е много частен и извратен случай. Така че синхронизация драйвер-клиент трябва да има. А разликата между 1 и повече клиенти както описвах вече обикновено се свежда до мястото на една проверка. Демек проверката винаги си я има, просто се прави в ралични моменти. Така че да се говори за "излишен" овърхед е малко пресилено... Не че няма изобщо, просто точно тоя овърхед е последната грижа. Ами то това е ОС-а - набор от примитиви
|
Пон Фев 10, 2020 9:05 am |
|
|
Кой е на линия |
Потребители разглеждащи този форум: 0 регистрирани и 2 госта |
|
Вие не можете да пускате нови теми Вие не можете да отговаряте на теми Вие не можете да променяте собственото си мнение Вие не можете да изтривате собствените си мнения Вие не можете да прикачвате файл
|
|