Jump to content

    

Hiehachi

Участник
  • Content Count

    65
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Hiehachi

  • Rank
    Участник
  • Birthday 07/16/1976

Старые поля

  • skype
    Array

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array
  1. Берете два драйвера нижних плечей для управления затворами мощных транзисторов - включаете пьезик по схеме полного моста (у каждого драйвера полумост на выходе (пуш-пул)). Ставите ограничение тока подбором сопротивления чтоб драйверы не спалить. Единственно на один драйвер нужно подавать инверсный сигнал (можно транзистором проинвертировать). Я по такой схеме эхолот делал 3-метрового измерения дистанции.
  2. Все правильно делаешь. Читай только постов 20 перед последним, будешь в теме. ;)
  3. Делал USB на LPC и STM. Этот код очень похож на LPC реализации, простой. Дескрипторы опрашиваются только на этапе конекта, когда хост ( PC ) учуял сопротивление резисторной подтяжки на входе. Прием данных на точку разрешался предварительно на каждый ендпоинт и после обработки принятого пакета должен быть снова разрешен/сброшен - в общем должен нахотится в нужном состоянии зависящего от квитирования (либо в ожидании приёма , либо в ожидании завершения передачи (когда хост заберёт, заранее размещенный в буфер передачи устройства пакет, по маркеру IN )). Важный момент !!! Обмен СИМПЛЕКСНЫЙ - жесткие требования на правильность и соответствие квитированию. CDC драйвера и правила квитирования они могут быть индивидуальны для каждой пары реализации (ХОСТ-ДЕВАЙС). Не будет правильной очередности квитирования с двух сторон - работы не будет (это из-за симплексной линии обмена в основном). Должно быть полное соответствие производителей ПАРЫ реализации. Почему в текстовых дискрипторах нет текста ? Насколько я помню там определенный формат и поле размера строки тоже, он точно правильный, другие примеры смотрели ? Драйвер может запрашивать и проверять - там соответствие с конкретным драйвером со стороны хоста (PID и VID это не достаточно !) . Берите LIBUSB32 со стороны хоста и налаживайте работу с ним - по вашим правилам обмена. Потом когда будете профи - уже будете "фрикерскими" методами адаптировать разные алгоритмы реализаций квитирований ;).
  4. Работал с HAL_UART_Receive_IT(). Хал включил не спрося обработку по EIE (так ему захотелось) и упетлял кудато, не выполнив банальную очистку (два простых безусловных действия, без петляния)- вышел из интерупта - на этом всё и закончилось ;(. В общем эта проблема + куча кода по проверке своих статусов- видимо для RTOS-ов, много кода в контексте прерывания. В общем не чувствовалась рука профи. Если честно не хочется ставать на грабли дважды. Товарищи "разрабы" с банальным уартом еще не та "ты", а ведь это самый простой периферийный блок. Потом подзабыл ту проблемку с уартом, лет через 5 взял попробовать ETHERNET на STM32F429, на своём боарде. Создал проэкт на кубе со всеми настройками, после в Кейле поменял на свой код инициализацию внешнего PHY-RMII (под KSZ8041 вроде, там другие биты были в автоопределении 10/100), думал всё. По дефайнам настроил количество буферов и режимы. Ну и начались траблы то иногда пакеты тупо дублировались при передачи то приёма не было (по дефайнам установил 1 буфер на приём и 1 на передачу - в этом и была проблема, код кала оптимизирован на минимум двойную буферизацию - коряво, на 4 буфера - лучше двойной, но не идеал). У меня проэкт не позволял транжировать память 4-мя буферами на приём и на передачу... собственно когда эта периферия используется опционально по необходимости. (реализовывал код под ARP, IP/UDP - код старый обкатаный еще на RTL8019, LPC1768, STM32F207). Провозился дня два - под вечер снёс этот кал; за два часа поставил пример сервера на lwIp (или как он там называется) - для того чтобы выудить две базовые функции на RX и TX, выудил, сервер снёс так-же. Пересоздал новый проэкт на базе SPL и по екзамплах юзания езернета с lwIp - за 3-5 часа и всё работало как надо. У товарищей которые создают кал - проблемы с чем-то, причём непонятно на каком уровне, но они есть. А оттягивать время разработки на игры в бирюльки - это очень дорогое удовольствие.
  5. Думаю, если вы используете микроконтроллер - значит используете периферию. Если периферию - значит возможно прерывания. Если прерывания - то не забывайте VOLATILE ставить где надо.
  6. А с чего грузить то хотите: c USB флешки как файл, прямым кабелем по USB, считыванием записи из внешней флеш памяти помещенной туда разными методами, с SD карты ? Что бут должен делать откуда грузить ?
  7. STM32F207 Это по поводу источников прерываний. Они есть - просто в API кала их нет, но он их включает, ну и путается с правильностью аппаратных сбросов. При обработке EIE - который был без разрешения включен, произошла "петляющая ошибка". Чтение регистра статуса БЫЛО, а другого важного действия ВТОРОГО ШАГА - не было. Вот и всё собственно. The FE bit is reset by a USART_SR register read operation followed by a USART_DR register read operation. EIE: Error interrupt enable - при разрешенном прерывании оно срабатывает от 3 источников FE, NOISE, ORE. Сброс каждой причины хоть индивидуален - но одинаков ;) - просто очень тупо был пропущен. Шо для технарей читающих мануалы просто - не приемлемо. Искать корявости или выкорчёвывание ненужных действий - занимает раз в 5 больше времени чем написание правильного кода с нуля.
  8. Вы что на STM работаете, склалось такое впечатление ;). ГДЕ В ФУНКЦИИ void HAL_UART_IRQHandler(UART_HandleTypeDef *huart) -- Выполняется ЖЕЛЕЗНОЕ ПРАВИЛО СБРОСА БЛОКИРОВКИ UARTА в случае ошибки ????????????????????? 0-0 . Хдееееее ?! Код похожий очень на тот что я правил, только меньше раз в 10. НО ошибки похоже те же. Тыкать не буду - тут просто банальная практика выявляет очень быстро эти огрехи. Здесь нет строки где есть ошибка - ТУТ строк НЕТ и Правильной последовательности сброса. Должен быть линейный код который без ВЕТВЛЕНИЙ делающий две базовые вещи о которых говорит мануал по UARTу. Просто понять что чтение регистра флагов не сбрасывает некоторые ошибки - понять нельзя - нужно ЧИТАТЬ . Я устал спорить на эту тему, если Вы считаете что там нету ошибок приводящих к фатальным зависаниям системы - ваше право ! Они там есть, потому что код хала ДЕТСКИЙ и технически неграмотный. Просто сделайте генератор помех на линию UART - и результат не заставит себя ждать.
  9. С 2009 на SPL писал. На грабли хала напоролся где-то 2011-2012, не помню. Сходу выбрал что мне больше подходит малыми кровями вот этот режим работы: Когда отлавливался тот глюк о котором я говорил. Никакой callBack по Error HAL_UART_ErrorCallback() - не вызывался вообще. Всё висло намертво, путём выхода из прерывания по uart и моментального туда захода, так как эфиопы не смогли его сбросить. Дебагер работал, отловил что не отработали сначала FE а потом NOISE попадалось в таком состоянии висячем. Позже напарник отловил (через пару месяцев) с I2C траблы. В общем больше на нём не пишем. Когда я фиксил код по UARTу то выкинул более 90 процентов того хлама который там был, ну еще и опасения были по неправильной кастрации кала, так как он со своими статусами постоянно манипулирует. ;), но обошлось . Такие дни никому не желаю ;), особенно когда что-то по срокам сдачи. Делали тогда устройства для диагностики автомобильной "периферии", по линии K-LINE. Там протокол основан на синхронизации пакета по фреймэрору, далее всё как обычно. На SPL без проблем можно было быстренько на лету перепрограмировать режими UARTA, хоть после каждого байта. А из-за тормознутости HALA пришлось использовать аппаратный режим детектировани K-LINE старта, хорошо что там он был на STMке. Не во всех уартах есть примочки, НО ВСЕМИ уартами можно прекрасно работать и без них, если не использовать "мегабайты" в прерывании ;). По приему K-LINE пробуждения, надо было замерить интервалы старта, паузы и вымерять длительность бита на линии который присутствовал в синхробайте 0x55, чтобы не потерять ни одного байта в посылке, запрограмировать нужную скорость и включить аппаратно прием в конце синхробайта - на его стоповом бите. И всё это прекрасно работало на SPL, кое-что конечно переделал на CMSIS. На хале - нет, такое не сделаешь.
  10. Сказал же - что в прерывании и не раз ! Тут же чистый SOFTWARE "Hello India !". ПРОБЛЕМЫ с HALL были у меня В ОБРАБОТЧИКЕ ПРЕРЫВАНИЙ а не в бредовом с архитектурной точки зрения софтваре коде. Не думал что програмисты вообще такое используют - это же детский сад. Мда, когда-то лет так 25 назад я мог еще "додуматься" встраивать Delay-ки в программу или код с непрогнозируемыми или динамическими задержками . А ну да - RTOS нам поможет ;) - создаст за нас архитектуру что не надо будет вставлять __HAL_LOCK(huart); , он ВСЁ может :rolleyes:. Это бредовый код, НЕ АРХИТЕКТУРНЫЙ. Ожидать прием данных с тормозами - это ЖЕСТЬ. Все делается по прерываниям и желательно с DMA настроенным, если конечно не лампочками моргать. А по поводу СРАНИ в реализации прерываний - это правда, виснет из-за неправильной реализации обработки.
  11. Какого еще таймаута ? Вы что рассказывали мне все время не за работу HAL в прерываниях, а какую-то софт реализацию "hello world" на uarte ? Конкретно я писал код на stm32f207 еще в 2009. Такой корявой обработки с флагами и нелинейного кода как там я даже в интернет хламе примеров не обнаруживал никогда. Вместо того чтобы просто когда пришел байт данных прочитать регистр USART_SR (не ISR !!!), а потом прочитать USART_DR, просто без каких либо условий и ветвлений - сделать два простых действия. 1. Там сразу по условиям внутренних своих флагов программа упетляла куда-то и не сбросивши прерывание по NOISE - вышло из обработчика. 2. Причём я ни NOISE ни FRAME реакции не заказывал для обработки в прерываниях. 3. Кроме того что оно их установило - оно их еще и не отработало. 4. Если бы там просто сделано было два шага по чтению регистров - БЕЗУСЛОВНО как положено для нормальной работы периферии - то я бы не возмущался и не предостерегал - что писал это человек далекого континента. 5. Один из крупный недостатков - это откат прогресса системы прерываний который появился в Кортексах - откачен корявостью и ленностью архитектуры - до уровня обработки прерываний ядра 7TDMI. Там индусы понасоздавали куча программных флагов вместо того чтобы использовать отдельные прерывания для каждой периферии - у них один общий обработчик для 6 уартов например, который потом разруливает програмно что кому надо. 6. Использование HAL - это необходимость использования вложенных прерываний, так как обработка очень медленная. Писать килобайты в контексте прерываний - это еще один ярлык. Мне не обсолютно пофиг, если есть траблы - я сказал в чём, разжевывать разжеванное я не буду.
  12. В части где нелинейно укрюченый код отловил FE или NOISE Interrupt - ТАМ. Возможно и подправили со временем, но когда обычно такой код пишут , он много говорит о том кто его писал. Это не XMEGA и не STM, не MSP и не LPC. Это класика AVR ;) . Интересно, а к чему тогда мануалы: ну например что такое 240 mka / 1 Mhz. Сейчас полно автономных устройств на своем питании, где время выполнения кода играет первостепенную роль. Дык, волшебство превращения контроллера в кирпичеподобную субстанцию за день работы - вот, это точно не выход. Надо вообще разбить ветку форума на две, в одной высказывания программистов "которым еще кажется" в другой "которые уже открестились" ;)
  13. Кроме банальных и грубых ошибок в API поддержек микроконтроллеров, существует еще и простые политики - зарабатывание денег. API периферии, а ТАКЖЕ ПЕРИФЕРИЙНЫЕ УЗЛЫ между производителями - ранее, ныне и всегда будут уникальными, это способ затормозить юзеров на переход или смену "периферийного железа" на другого производителя, это по крайней мере должны понимать не наивные люди. И как вследствие этого НИКОГДА НЕ БУДЕТ безболезненного перехода. Время чтения документации + поиск багов + нереальные трудности по изменению "специально написанного" кода - делают своё дело, причём это делается скорее всего целенаправленно, чем случайно. Сколько продержалась STM_SPL уступив STM_HAL, кому мешала быстро переносимая API архитектура ?
  14. Похоже для STM и ATMEL библиотечный код пишет один и тот же индус. При принятии данных заставить прочитать регистр статуса перед регистром данных - ни в какую не хочет. На STM UARTe такой ленивый подход просто аппаратно блокирует прием данных вообще, если закрался FE при приеме. Для I2C по атмелу весь код - сплошные прерывания, зачем ? Эти функции например нельзя использовать в контексте другого прерывания ! Система API таймеров для ATMEL оперирует 4 байтными значениями задержек в микросекундах, при использовании подсчета не атомарных величин - запрещают прерывания, длительность расчета превышает десятки микросекунд, при использовании например UART на скорости выше или равно 115200 - задержка для вычисления времени API TIMER калбэков по таймерам превышает время трансляции байта, а так как у atmel нет FIFO - данные просто теряются. При задержке в калбек функции по премени вычисления больше чем запрограммировано время следующего калбека - вылет и неопределенное значение внутреннего программного состояния Timer API - ну и т.д. И это что считается нормальным поиск багов ? Такие API не годятся вообще никуда, они только показательны и только когда работают одни в системе, или таймера или UART или I2C. А вот в связке функционирования - полная Ж... . Вообще халява она для особенных людей, когда ее кто-то ищет - это очень яркий ярлык отсутствия шишек.
  15. Может чуть не в тему, где-то есть настройки задержки линии CS# ? Обычно нужно небольшое время выждать когда slave периферия выйдет из сна.