Отговори на тема  [ 49 мнения ]  Отиди на страница Предишна  1, 2, 3, 4  Следваща
Въпрос относно собствена библиотека за pic32mx 
Автор Съобщение
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Май 29, 2007 1:23 pm
Мнения: 3545
Местоположение: Високо в планината
Мнение Re: Въпрос относно собствена библиотека за pic32mx
miro_atc написа:
...Иначе става като вица с флопито ;-)
....

Кой виц :)

_________________
Хайде де!


Пет Яну 31, 2020 5:53 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: Въпрос относно собствена библиотека за pic32mx
gicho написа:
Независимо от с/без ОС новата версия на драйвера може да запази същия интерфейс


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


Пет Яну 31, 2020 5:55 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: Въпрос относно собствена библиотека за pic32mx
dan написа:
miro_atc написа:
...Иначе става като вица с флопито ;-)
....

Кой виц :)


Сина на Бил Гейтс го попитал "тате какво значи многозадачност?". При което той отговорил - изчакай да се форматира дискетата и ще ти покажа.


Пет Яну 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
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Въпрос относно собствена библиотека за pic32mx
Миро, точно с тази дефиниция на ОС съм готов да се съглася - всяко нещо, което преизползваш правейки следващия проект/устройство. Т.е. дори да е съвсем глупав superloop дори без прекъсвания (а-ла-ардуино), пак си е "ардуино-ОС" защото дава готови услуги под формата на библиотеки и предоставя документиран начин да правиш определени неща.
Драйверът сам по себе си не може да стане реентрант без помощна на разни синхронизационни примитиви, които дори да не са от някой известен ОС, пак са библиотечни, преизползваеми услуги / функции. Може да са просто прекъсвания и/или софтуерни прекъсвания, които да дадат аналогията на таск.

Моето виждане е че интерфейсите на драйверите (и каквото и да е друго) трябва да бъдат определени (разработени), гледайки "другата" страна - т.е. не да гледаме какво искат клиентите (т.е. протоколите), а да гледаме за какво е тая периферия. В смисъл драйвера за уарт не се дизайн-ва според протоколите ("имам един модбъс стек, направи драйвера за уарт-а на пикчето да му пасва"), които ще го ползват (модбъс, АТ, ....), а според периферията. Имайки спецификация на уарт или кан правим драйвер, който скривайки специфичните регистри "показва" общоизвестни за тая периферия услуги - пращане, бодрейт, формат на фрейма, приемане, или индентификатор, арбитрация, ...
Това е известно като single resposibility принцип - трябва да има само един документ/спецификация, която да може да накара кода да се смени - ако не се появи нова версия на КАН спецификацията няма нужда да се сменя кода, защото само тоя документ присъства в кода - няма posix, няма други "абстракции" и интерфейси, които някой е приел за нужни. Промяната в модбъс протокола не може да бъде причина за смяна на уарт драйвера - по принцип, макар че може да ни задвижи да оптимизираме нещо или да добавим друго, което досега не ни е било нужно.
По този начин следващия клиент (протокол) не променя драйвера, щото той по начало не е правен мислейки за даден протокол - така се избягват обърквания. В другата посока обикновено се разчита на опита на писача, който вече е правил 20 протокола последните 10 години, съответно се предполага че ще направи драйвер, който е съобразен с всичките - заради опита си. Само че в другата посока не е нужно да се мисли за това - както споменах там абстракцията е истинския физически модул (уарт, спи, кан), т.е. онова което инженерите са опитали да имплементират в чипа/IP-то, който няма как да не е специфициран. Приложението има нужда да прати CAN съобщение - не му пука за ОС, стриймове (няма ги в КАН) и няма нужда приложника да мисли за тях - те не са му основната работа. API-то на драйвера изглежда познато ако си чел КАН спецификацията и борави с термини, налични в тия документи.
Т.е. как ще изглежда интерфейса се определя независимо от специфичната имплементация на КАН контролера, или на уарт-а. Остава да се мисли дали тоя интерфейс да е синхронен или асинхронен - ако търсим асинхронен може да се наложи да добавим фифо-та, таскове и други такива, но това само ако няма подходящи прекъсвания и периферията е дизайнвана от аматьори - ако тя (периферията) си има фифо-та, прекъсвания по ниво на фифото и т.н. цялата верига може да "цъка" в тия контексти.


Пет Яну 31, 2020 10:22 pm
Профил
Ранг: Минаващ
Ранг: Минаващ

Регистриран на: Сря Яну 09, 2019 8:13 pm
Мнения: 19
Мнение Re: Въпрос относно собствена библиотека за pic32mx
Реших да си поиграя малко и да пробвам това, което е написал gicho още в началото на темата. Но има нещо, което не разбирам как трябва да стане. В дейфаните са базовите адреси на регистрите "UxMODE" на всеки един UART модул (общо 6 на брой). Извадил съм ги от майкрочипския хедер файл. Доколкото разбирам в скобите се извършва тайпкастване, защото пойнтърите трябва да сочат към структури. Обаче, в този случай, какво трябва да се подаде във функцията uartInit().
По - долу прилагам и част от кода във майкрочипския хедер файл за дадения микроконтролер. Никога не съм се ровил във фабричните хедер файлове и сега виждам, че регистрите са реализирани с bitfields.

Код:
#define UART_1      (__U1MODEbits_t*)0xBF806800
#define UART_2      (__U2MODEbits_t*)0xBF806800
#define UART_3      (__U3MODEbits_t*)0xBF806400
#define UART_4      (__U4MODEbits_t*)0xBF806200
#define UART_5      (__U5MODEbits_t*)0xBF806A00
#define UART_6      (__U6MODEbits_t*)0xBF806600           


void uartInit( ???????? * uartModule, ........);

void main(void) {
   
    uartInit(UART_1, .........);
    while(1);

    return;
}
void uartInit(?????????* uartModule, .........)
{
    uartModue -> ctrl1 = 1;
    .............
}



Код:
#define U1MODE U1MODE
extern volatile uint32_t   U1MODE __attribute__((section("sfrs"), address(0xBF806000)));
typedef union {
  struct {
    uint32_t STSEL:1;
    uint32_t PDSEL:2;
    uint32_t BRGH:1;
    uint32_t RXINV:1;
    uint32_t ABAUD:1;
    uint32_t LPBACK:1;
    uint32_t WAKE:1;
    uint32_t UEN:2;
    uint32_t :1;
    uint32_t RTSMD:1;
    uint32_t IREN:1;
    uint32_t SIDL:1;
    uint32_t :1;
    uint32_t ON:1;
  };
  struct {
    uint32_t :1;
    uint32_t PDSEL0:1;
    uint32_t PDSEL1:1;
    uint32_t :5;
    uint32_t UEN0:1;
    uint32_t UEN1:1;
  };
  struct {
    uint32_t :13;
    uint32_t USIDL:1;
    uint32_t :1;
    uint32_t UARTEN:1;
  };
  struct {
    uint32_t w:32;
  };
} __U1MODEbits_t;
extern volatile __U1MODEbits_t U1MODEbits __asm__ ("U1MODE") __attribute__((section("sfrs"), address(0xBF806000)));
extern volatile uint32_t        U1AMODECLR __attribute__((section("sfrs"),address(0xBF806004)));
extern volatile uint32_t        U1MODECLR __attribute__((section("sfrs"),address(0xBF806004)));
extern volatile uint32_t        U1AMODESET __attribute__((section("sfrs"),address(0xBF806008)));
extern volatile uint32_t        U1MODESET __attribute__((section("sfrs"),address(0xBF806008)));
extern volatile uint32_t        U1AMODEINV __attribute__((section("sfrs"),address(0xBF80600C)));
extern volatile uint32_t        U1MODEINV __attribute__((section("sfrs"),address(0xBF80600C)));


Прикачени файлове:
PIC32MX795F512H.txt [1.7 MiB]
140 пъти
Пет Яну 31, 2020 11:23 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 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
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Чет Фев 10, 2005 2:25 pm
Мнения: 4975
Местоположение: София
Мнение Re: Въпрос относно собствена библиотека за pic32mx
Колко време е необходимо да се напишат няколкото реда за инициализация на уартите, сравнено с времето за написване на останалия код за този PIC? Гледам, че няма ремапване на периферията, така че уарта или се използва или не в зависимост от конкретната схема. Що трябва инициализацията на уартите да се смесва с писането на драйвер. Ако имаше ремапване на уартите и пика има да речем 3 хардуерни, а трябват повече, тогава има смисъл драйвера да се направи така, че да може да му се укаже какво и къде да предаде или какво и от къде да се приеме, а самия драйвер да прецени кой уарт е свободен в дадения момент и да го настрои.


Съб Фев 01, 2020 1:46 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: Въпрос относно собствена библиотека за pic32mx
Desert Leo написа:
Колко време е необходимо да се напишат няколкото реда за инициализация на уартите, сравнено с времето за написване на останалия код за този PIC?


Това няма никакво значение. За да ползваш УАРТ трябва да напишеш малко код за него. Въпросът е само как точно ще го напишеш. Това беше и въпроса в темата и май само вълшебникът дава смислени отговори ;-)


Съб Фев 01, 2020 3:02 pm
Профил
Ранг: Минаващ
Ранг: Минаващ

Регистриран на: Сря Яну 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
Профил
Ранг: Минаващ
Ранг: Минаващ

Регистриран на: Сря Яну 09, 2019 8:13 pm
Мнения: 19
Мнение Re: Въпрос относно собствена библиотека за pic32mx
ДедоБоре написа:
дай да я видим таз книжка.
не обичам да чета код във вид на jpeg картинки с голяма компресия


Заповядай,
Към книгата имаше и прикачени файлове с примери от кода в книгата, но останаха на другия компютър. По-късно ще
кача и тях.


Прикачени файлове:
r17082112.pdf [7.51 MiB]
172 пъти
Сря Фев 05, 2020 7:48 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: Въпрос относно собствена библиотека за pic32mx
lubo_88 написа:
И все пак, ако вие знаете още ресурси, от където може да се учи относно писане на драйвери и библиотеки, както и добри практики при програмиране на микроконтролери, моля, споделете ги.


За съжаление няма по-по-най-добри... Има различни подходи. За някои въпроси един ще ти каже едно, друг точно обратното. Изобщо мненията са в целия спектър и може би са толкова много понеже приложенията на контролерите са много различни. Някои гонят супер надеждност, други гонят консумация, трети са real time, четвърти функционалност и сложност и т.н.
От друга страна за всеки детайл има изписани хиляди книги. Примерно как си менажираш проектите, как се мейкват, как се документират, как се тестват, как се поддържат. Все неща, които не са пряко свързани със самия код, но са свързани...
Затова аз постоянно повтарям за всеки, който ще си вади хляба в тоя бизнес, че е добре да види *различни* подходи. А после си идва от само себе си, защото едни неща харесваш и се опитваш да следваш, други не. Но едва ли ще намериш всичко на едно място, та затова трябва да се гледа на доста места.
В тоя ред на мисли, тук също имаме "различни" гледни точки и едно бързо представяне/запознаване може да е полезно. Аз примерно за моите "опорни" точки си мисля, че най-добрият вариант да ги представя е един скайп с тимвю и да покажа реални проекти, кое как е направено, как работи, какви подходи съм избрал и защо. Надявам се и други колеги биха споделили по един или друг начин (знам че на бира си казват всичко ;-) ). С други думи така може да се направи едно бързо запознаване с различни техники. Повърхностно ще да е, ама след това човекът сам ще си реши кое му пасва и иска да задълбава...


Сря Фев 05, 2020 10:39 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Яну 26, 2005 1:01 pm
Мнения: 1952
Местоположение: Варна
Мнение Re: Въпрос относно собствена библиотека за pic32mx
Има едно залитане, да се фокусирате върху драйвери и ОС. Ако центъра е поставен там резултата ще бъде, че работата винаги ще има ексцентритет.
Доколкото писането на софтуер следва процеса на моделиране на реално съществуващи обекти и тяхното поведение, ако се фокусирате върху моделиране на апаратната част на МЦУ-тата, това не винаги ще даде необходимата абстракция за да се опише цалостната фунционалност на устройството или системата която се разработва. Но пък един ден може и да стигнете до идеалното описване на едно МЦУ.
Апратната част на МЦУ-тата е несъвършена, не добре обмислена и най-често проектирана да бъде пенкилер - GeneralPurpose. Ако отгоре и направите един HAL, накрая тоя който ще го ползва тоя HAL ще му се иска да ви го навре... сещате се къде.
По продуктивно е да се фокусирате върху примитиви като опашки, FIFO-та, кръгови буфери, проксита, диспатчъри, арбитри, синхронизирани времеви бази и прочие. Те са по-близо до реалните задачи, и ще вършат по-добра работа вместо един HAL, в който A-то не става и за чеп за зеле.

_________________
Най-опасният враг на истината и свободата е мнозинството.


Нед Фев 09, 2020 4:22 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: Въпрос относно собствена библиотека за pic32mx
Zdrav написа:
...


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

Истината е, че при добре обмислен проект кодът на ОС-а отнема не повече от 1% процесорно време. Като само 1% от тоя 1% е "излишен".
С други думи драйверите примерно работят със същите периферни регистри с които трябва да се работи. "Излишъкът" обикновено се създава, когато се ползват излишни синхронизационни примитиви. По-горе стана дума за пример 1 драйвер и 1 клиент. Изглежда ненужно на пръв поглед драйвера да се синхронизира с повече от 1 клиент, ако никога няма да се появи такъв в проекта. Работата е там, че клиентите по принцип са нишки и драйверите работят в друг контекст. Това е неизбежно, ако в системата има някаква многозадачност. Трябва да имаш приоритети и няма как една нишка да е с еднакъв приоритет като прекъсване. Всъщност може, но е много частен и извратен случай. Така че синхронизация драйвер-клиент трябва да има. А разликата между 1 и повече клиенти както описвах вече обикновено се свежда до мястото на една проверка. Демек проверката винаги си я има, просто се прави в ралични моменти. Така че да се говори за "излишен" овърхед е малко пресилено... Не че няма изобщо, просто точно тоя овърхед е последната грижа.

Zdrav написа:
По продуктивно е да се фокусирате върху примитиви като опашки, FIFO-та, кръгови буфери, проксита, диспатчъри, арбитри, синхронизирани времеви бази и прочие

Ами то това е ОС-а - набор от примитиви ;-)


Пон Фев 10, 2020 9:05 am
Профил
Покажи мненията от миналия:  Сортирай по  
Отговори на тема   [ 49 мнения ]  Отиди на страница Предишна  1, 2, 3, 4  Следваща

Кой е на линия

Потребители разглеждащи този форум: 0 регистрирани и 2 госта


Вие не можете да пускате нови теми
Вие не можете да отговаряте на теми
Вие не можете да променяте собственото си мнение
Вие не можете да изтривате собствените си мнения
Вие не можете да прикачвате файл

Търсене:
Иди на:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.
Хостинг и Домейни