Jump to content

    

Rst7

Модераторы
  • Content Count

    4478
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Rst7

  • Rank
    Йа моск ;)
  • Birthday 12/08/1973

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Kharkiv-city

Recent Profile Visitors

24676 profile views
  1. Верно описывает результат только для Cortex-M. Потому что объяснение неверное. А зачем писать в переменную, к которой Вы организуете эксклюзивный доступ, обычным способом? Только менее универсальный. Например, взять элемент из списка на ARM выглядит так: #define ExAddr(VAL) ((volatile unsigned int *)(&(VAL))) typedef struct LLITEM { struct LLITEM *next; unsigned char data[100]; }LLITEM; volatile LLITEM *FreeBlocks; LLITEM *AllocBlock(void) { LLITEM *p; LLITEM *next; do { p=(LLITEM*)__LDREX(ExAddr(FreeBlocks)); if (!p) {__CLREX(); return p;} next=p->next; }while(__STREX((unsigned long)next,ExAddr(FreeBlocks))); return p; } А на x86 с его единственным lock'ом надо извращаться.
  2. Кстати, это только к Cortex-M относится, всякие -А вроде не сбрасывают.
  3. Я не об этом. Обычная запись в память (или чтение) между LDREX/STREX не сбрасывает флаг. volatile unsigned int testvar; volatile unsigned int testvar2; void TestEX(void) { unsigned int tv; tv=__LDREX(&testvar); __no_operation(); __no_operation(); __no_operation(); testvar2=1; testvar2; __no_operation(); __no_operation(); __no_operation(); tv=__STREX(tv,&testvar); DEBUG_PRINTF("__STREX result %d\r\n",tv); } Такой код печатает "__STREX result 0", несмотря на наличие LDR/STR между LDREX/STREX. То, что заход в прерывания сбрасывают флаг- это какой-то отдельный тонкий момент, с ним надо разбираться, потому что в теории так быть не должно. Ага, вот в чем дело (из мануала на CM4) Т.к. прерывания - это тоже эксепшн, то вот и ответ.
  4. Например непонимание работы exclusive monitor'а ядра тут:
  5. Какие-то очень сложные у вас всех TFTP. У меня от LPC1768 загрузчик весит Из которых 1132 байта - это библиотечный printf, который можно выбросить, если сильно прижмет. Кстати, я его где-то выкладывал тут.
  6. USB-стек в МК

    *facepalm.jpg*
  7. USB-стек в МК

    Там все хуже, там просто не работает. Виснет намертво сразу.
  8. Очень жаль, что участник нашего форума оказался таким провальным. Если бы он это все высказывал тут в дискуссиях - то пофиг. А вот то, что он это несет в неокрепшие умы (я же не просто так цитату принес) - вот за это нет прощения.
  9. USB-стек в МК

    Давайте, кстати, проверим на вшивость Ваш прекрасный дорогой софт. Что у Вас в заголовочнике с регистрами от RT1020 описано для USB_USBCMD_ATDTW_MASK и USB_USBCMD_ATDTW_SHIFT?
  10. USB-стек в МК

    А причем тут "слабый софт"? Это зачем мне чужой код осваивать? Я за свое могу нести ответственность, а за чужое - пардон. Чтобы за чужое нести ответственность - надо его досконально изучить, а это сравнимо с написанием своего.
  11. Там еще и дичь про LDREX/STREX написана. Я бы вообще дал этому дьяволу по лицу. Именно за вот это:
  12. USB-стек в МК

    Вот прям могу с пылу с жару рассказать про борьбу с USB-стеком. Камень - iMX RT1020. Имею принцип в жизни - писать самому, готовое не использовать, максимум - подглядеть в примеры какие-то опущенные в даташитах подробности. Я не особо часто бодался с USB, последний раз лет эдак 15 назад делал эмулятор FT232 на AT90USB162. А теперь пришлось сделать ECM/RNDIS устройство. Официальные примеры для этих iMX RT есть, но со страшным нагромождением уровней абстракции, разбросано по куче файлов, местами - плюсы на Си врукопашную, в общем - все прелести. Довольно быстро все поехало в простом варианте типа суперцикла, без всяких прерываний, просто с проверкой флагов. Затем начал переделывать на вменяемую работу, т.е. прерывания, обеспечение zero copy, минимальные простои и так далее. И в конце концов наступил на мертвое зависание алгоритма добавления нового буфера в цепочку буферов USB DMA на ходу. Алгоритм описан в даташите, более того, именно его реализацию (не без индусских делов) я обнаружил при изучении примеров (после того, как моя реализация не заработала). Убито было несколько дней. Оказалось, что в заголовочном файле с регистрами периферии был неверно описан один из битов в регистрах (не 1<<14, а 1<<12). Обнаружил это совершенно случайно, когда уже начал проверять совсем все. Заголовочный файл с регистрами был взят именно из официальных примеров. Так что официальные примеры, конечно, компилируются, но вот никто их на таргете никогда не запускал и не проверял. Вообще оказалось, что во всей этой iMX-линейке вроде бы и один и тот же USB, но этот бит пляшет произвольно от типа к типу, в каких-то - 12й, в каких-то - 14й, в некоторых это считалось ошибкой и описано в errata, в некоторых нет, в общем - полный хаос. Это в общем я к тому, что взяв "готовый" можно влететь крепко с точки зрения "я возьму готовый, сэкономлю дофига времени". Ну и да, по итогу весь этот RNDIS у меня - один сишный файл вполне обозримых размеров. С минимумом оверхэда, как я люблю.
  13. Я - никак не делаю, живу жизнь без ассертов. Конкретно в данном случае это всего лишь пример, там можете строить что хотите сами. Но если бы конкретно мне понадобилась такая конструкция, то я бы сгенерировал исключение каким-то образом, а потом разбирался уже исключительно по PC (например, напечатав его в обработчике исключения). Немногим труднее, чем имя функции и номер строки, но зато куда меньше попутных приколов, например, совершенно не нужной в обычной жизни работе со стеком.
  14. Конкретно в данном случае - без использования CMSIS. Теперь о рукопашности этого ассерта и вообще кривости конкретно данного кода. Правильно писать вот так, если не отключать ассерты: if (portNum>=8) return LPC_GPIO_PORT->PIN[portNum]; else Abort(); Потому что ветка true - это более частая ветка, скорее всего с вероятностью 100%.