Перейти к содержанию

Hiehachi

Участник
  • Публикаций

    65
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Hiehachi

  • Звание
    Участник
  • День рождения 16.07.1976

Контакты

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

Информация

  • Город
    Odessa

Старые поля

  • skype
    aldoshinmax
  1. Берете два драйвера нижних плечей для управления затворами мощных транзисторов - включаете пьезик по схеме полного моста (у каждого драйвера полумост на выходе (пуш-пул)). Ставите ограничение тока подбором сопротивления чтоб драйверы не спалить. Единственно на один драйвер нужно подавать инверсный сигнал (можно транзистором проинвертировать). Я по такой схеме эхолот делал 3-метрового измерения дистанции.
  2. STM32СubeMX и подобные

    Цитата(serglg @ Mar 16 2018, 16:52) У меня в нескольких проектах постоянно используется HAL_UART_Receive_IT(). И что я делаю не так? Все правильно делаешь. Читай только постов 20 перед последним, будешь в теме.
  3. прерывание от USB

    Делал USB на LPC и STM. Этот код очень похож на LPC реализации, простой. Дескрипторы опрашиваются только на этапе конекта, когда хост ( PC ) учуял сопротивление резисторной подтяжки на входе. Прием данных на точку разрешался предварительно на каждый ендпоинт и после обработки принятого пакета должен быть снова разрешен/сброшен - в общем должен нахотится в нужном состоянии зависящего от квитирования (либо в ожидании приёма , либо в ожидании завершения передачи (когда хост заберёт, заранее размещенный в буфер передачи устройства пакет, по маркеру IN )). Важный момент !!! Обмен СИМПЛЕКСНЫЙ - жесткие требования на правильность и соответствие квитированию. CDC драйвера и правила квитирования они могут быть индивидуальны для каждой пары реализации (ХОСТ-ДЕВАЙС). Не будет правильной очередности квитирования с двух сторон - работы не будет (это из-за симплексной линии обмена в основном). Должно быть полное соответствие производителей ПАРЫ реализации. Почему в текстовых дискрипторах нет текста ? Насколько я помню там определенный формат и поле размера строки тоже, он точно правильный, другие примеры смотрели ? Драйвер может запрашивать и проверять - там соответствие с конкретным драйвером со стороны хоста (PID и VID это не достаточно !) . Берите LIBUSB32 со стороны хоста и налаживайте работу с ним - по вашим правилам обмена. Потом когда будете профи - уже будете "фрикерскими" методами адаптировать разные алгоритмы реализаций квитирований .
  4. STM32СubeMX и подобные

    Работал с 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. Keil uVision ARM v 5.16a странное поведение

    Думаю, если вы используете микроконтроллер - значит используете периферию. Если периферию - значит возможно прерывания. Если прерывания - то не забывайте VOLATILE ставить где надо.
  6. бутлодырь lpc24xx

    А с чего грузить то хотите: c USB флешки как файл, прямым кабелем по USB, считыванием записи из внешней флеш памяти помещенной туда разными методами, с SD карты ? Что бут должен делать откуда грузить ?
  7. STM32СubeMX и подобные

    STM32F207 ЦитатаTen interrupt sources with flags: – CTS changes – LIN break detection – Transmit data register empty – Transmission complete – Receive data register full – Idle line received – Overrun error – Framing error == EIE – Noise error == EIE – Parity error == EIE Это по поводу источников прерываний. Они есть - просто в API кала их нет, но он их включает, ну и путается с правильностью аппаратных сбросов. ЦитатаWhen the framing error is detected: • The FE bit is set by hardware • The invalid data is transferred from the Shift register to the USART_DR register. • No interrupt is generated in case of single byte communication. However this bit rises at the same time as the RXNE bit which itself generates an interrupt. In case of multibuffer communication an interrupt will be issued if the EIE bit is set in the USART_CR3 register. - при использовании API - этого прерывания я не заказывал, ну и естественно неадекватную реакцию на него. ЦитатаIn case of multibuffer communication if any error occurs during the transaction the error flag will be asserted after the current byte. An interrupt will be generated if the interrupt enable flag is set. For framing error, overrun error and noise flag which are asserted with RXNE in case of single byte reception, there will be separate error flag interrupt enable bit (EIE bit in the USART_CR3 register), which if set will issue an interrupt after the current byte with either of these errors. При обработке 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. STM32СubeMX и подобные

    Вы что на STM работаете, склалось такое впечатление . ГДЕ В ФУНКЦИИ void HAL_UART_IRQHandler(UART_HandleTypeDef *huart) -- Выполняется ЖЕЛЕЗНОЕ ПРАВИЛО СБРОСА БЛОКИРОВКИ UARTА в случае ошибки ????????????????????? 0-0 . Хдееееее ?! Код похожий очень на тот что я правил, только меньше раз в 10. НО ошибки похоже те же. Тыкать не буду - тут просто банальная практика выявляет очень быстро эти огрехи. Здесь нет строки где есть ошибка - ТУТ строк НЕТ и Правильной последовательности сброса. Должен быть линейный код который без ВЕТВЛЕНИЙ делающий две базовые вещи о которых говорит мануал по UARTу. Просто понять что чтение регистра флагов не сбрасывает некоторые ошибки - понять нельзя - нужно ЧИТАТЬ . Я устал спорить на эту тему, если Вы считаете что там нету ошибок приводящих к фатальным зависаниям системы - ваше право ! Они там есть, потому что код хала ДЕТСКИЙ и технически неграмотный. Просто сделайте генератор помех на линию UART - и результат не заставит себя ждать.
  9. STM32СubeMX и подобные

    С 2009 на SPL писал. На грабли хала напоролся где-то 2011-2012, не помню. Сходу выбрал что мне больше подходит малыми кровями вот этот режим работы: Цитата(#) A set of Transfer Complete Callbacks are provided in non blocking mode: (++) HAL_UART_TxCpltCallback() (++) HAL_UART_RxCpltCallback() (++) HAL_UART_ErrorCallback() Когда отлавливался тот глюк о котором я говорил. Никакой 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. STM32СubeMX и подобные

    Сказал же - что в прерывании и не раз ! Тут же чистый SOFTWARE "Hello India !". ПРОБЛЕМЫ с HALL были у меня В ОБРАБОТЧИКЕ ПРЕРЫВАНИЙ а не в бредовом с архитектурной точки зрения софтваре коде. Не думал что програмисты вообще такое используют - это же детский сад. Мда, когда-то лет так 25 назад я мог еще "додуматься" встраивать Delay-ки в программу или код с непрогнозируемыми или динамическими задержками . А ну да - RTOS нам поможет - создаст за нас архитектуру что не надо будет вставлять __HAL_LOCK(huart); , он ВСЁ может . Это бредовый код, НЕ АРХИТЕКТУРНЫЙ. Ожидать прием данных с тормозами - это ЖЕСТЬ. Все делается по прерываниям и желательно с DMA настроенным, если конечно не лампочками моргать. А по поводу СРАНИ в реализации прерываний - это правда, виснет из-за неправильной реализации обработки.
  11. STM32СubeMX и подобные

    ЦитатаПри приеме вычитывается статусный регистр в течении таймаута, если пришел RXNE, то читаем RDR Какого еще таймаута ? Вы что рассказывали мне все время не за работу HAL в прерываниях, а какую-то софт реализацию "hello world" на uarte ? Конкретно я писал код на stm32f207 еще в 2009. Такой корявой обработки с флагами и нелинейного кода как там я даже в интернет хламе примеров не обнаруживал никогда. Вместо того чтобы просто когда пришел байт данных прочитать регистр USART_SR (не ISR !!!), а потом прочитать USART_DR, просто без каких либо условий и ветвлений - сделать два простых действия. 1. Там сразу по условиям внутренних своих флагов программа упетляла куда-то и не сбросивши прерывание по NOISE - вышло из обработчика. 2. Причём я ни NOISE ни FRAME реакции не заказывал для обработки в прерываниях. 3. Кроме того что оно их установило - оно их еще и не отработало. 4. Если бы там просто сделано было два шага по чтению регистров - БЕЗУСЛОВНО как положено для нормальной работы периферии - то я бы не возмущался и не предостерегал - что писал это человек далекого континента. 5. Один из крупный недостатков - это откат прогресса системы прерываний который появился в Кортексах - откачен корявостью и ленностью архитектуры - до уровня обработки прерываний ядра 7TDMI. Там индусы понасоздавали куча программных флагов вместо того чтобы использовать отдельные прерывания для каждой периферии - у них один общий обработчик для 6 уартов например, который потом разруливает програмно что кому надо. 6. Использование HAL - это необходимость использования вложенных прерываний, так как обработка очень медленная. Писать килобайты в контексте прерываний - это еще один ярлык. ЦитатаЕсли не можете, то с вашими выводами всё понятно. Мне не обсолютно пофиг, если есть траблы - я сказал в чём, разжевывать разжеванное я не буду.
  12. STM32СubeMX и подобные

    ЦитатаА в каком конкретно месте этот баг? Глянул на вскидку хал для stm32l0 функцию HAL_UART_Receive(), сначало читается ISR, потом RDR. В части где нелинейно укрюченый код отловил FE или NOISE Interrupt - ТАМ. Возможно и подправили со временем, но когда обычно такой код пишут , он много говорит о том кто его писал. Цитатадма нет? Это не XMEGA и не STM, не MSP и не LPC. Это класика AVR . Цитатадовод ни о чем. все ваши высказывания в двух словах - "хал грамоздкий". вы свой код соптимизируте на 48МГц Интересно, а к чему тогда мануалы: ну например что такое 240 mka / 1 Mhz. Сейчас полно автономных устройств на своем питании, где время выполнения кода играет первостепенную роль. Дык, волшебство превращения контроллера в кирпичеподобную субстанцию за день работы - вот, это точно не выход. Надо вообще разбить ветку форума на две, в одной высказывания программистов "которым еще кажется" в другой "которые уже открестились"
  13. STM32СubeMX и подобные

    Кроме банальных и грубых ошибок в API поддержек микроконтроллеров, существует еще и простые политики - зарабатывание денег. API периферии, а ТАКЖЕ ПЕРИФЕРИЙНЫЕ УЗЛЫ между производителями - ранее, ныне и всегда будут уникальными, это способ затормозить юзеров на переход или смену "периферийного железа" на другого производителя, это по крайней мере должны понимать не наивные люди. И как вследствие этого НИКОГДА НЕ БУДЕТ безболезненного перехода. Время чтения документации + поиск багов + нереальные трудности по изменению "специально написанного" кода - делают своё дело, причём это делается скорее всего целенаправленно, чем случайно. Сколько продержалась STM_SPL уступив STM_HAL, кому мешала быстро переносимая API архитектура ?
  14. STM32СubeMX и подобные

    Похоже для STM и ATMEL библиотечный код пишет один и тот же индус. При принятии данных заставить прочитать регистр статуса перед регистром данных - ни в какую не хочет. На STM UARTe такой ленивый подход просто аппаратно блокирует прием данных вообще, если закрался FE при приеме. Для I2C по атмелу весь код - сплошные прерывания, зачем ? Эти функции например нельзя использовать в контексте другого прерывания ! Система API таймеров для ATMEL оперирует 4 байтными значениями задержек в микросекундах, при использовании подсчета не атомарных величин - запрещают прерывания, длительность расчета превышает десятки микросекунд, при использовании например UART на скорости выше или равно 115200 - задержка для вычисления времени API TIMER калбэков по таймерам превышает время трансляции байта, а так как у atmel нет FIFO - данные просто теряются. При задержке в калбек функции по премени вычисления больше чем запрограммировано время следующего калбека - вылет и неопределенное значение внутреннего программного состояния Timer API - ну и т.д. И это что считается нормальным поиск багов ? Такие API не годятся вообще никуда, они только показательны и только когда работают одни в системе, или таймера или UART или I2C. А вот в связке функционирования - полная Ж... . Вообще халява она для особенных людей, когда ее кто-то ищет - это очень яркий ярлык отсутствия шишек.
  15. Может чуть не в тему, где-то есть настройки задержки линии CS# ? Обычно нужно небольшое время выждать когда slave периферия выйдет из сна.