Jump to content

    

Hiehachi

Участник
  • Content Count

    65
  • Joined

  • Last visited

Everything posted by Hiehachi


  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 периферия выйдет из сна.
  16. Запись во FLASH

    Думаю что в тему. Чтоб не парится с прагмапаками, прагмапушами и прагмапопами или аналогичными вещами - нужно усвоить архизнаниё ! . Все базовые (интежер) типы данных компиляторы размещают по адресам кратным их размерности (это для 16 битных и 32 битных компиляторов). При создании структур желательно не микшировать подряд и в праполую char, short и long. Настоятельно рекомендую сортировать в типовом порядке от 4 байтных - до 1 байтных, Причём при переходе типов самостоятельно дополнять нужными полями нужной размерности. Пример создания структуры состоящей из фиксированного набора параметров, например три 4 байтных, два 2 байтных и одного однобайтного: Хорошо:------------------Не хорошо------------------------------------Не хорошо long------------------------char------------------------------------------- short long------------------------short (впереди выравнивание + 1)-------- long (впереди выравнивание + 2) long------------------------long------------------------------------------- short short-----------------------long-------------------------------------------- long (впереди выравнивание + 2) short-----------------------long-------------------------------------------- char char------------------------short------------------------------------------- long (впереди выравнивание + 3) ----------------------------------------------------------------------------------------------------------------------------- 17 байт--------------------18 байт-----------------------------------------24 байт В случае примеров "не хорошо" - дополнять руками какими нибудь типовыми полями по нужной размерности , чтоб компилятор не делал это за вас.
  17. А адреса строк по физическому ROW не дробятся длиной тестового пакета в первой половине таблицы тестируемых адресов ?
  18. STM32СubeMX и подобные

    Цитата(sadat @ Feb 14 2018, 18:30) Использую куб как визуализацию ... Затем не оптимальные процедуры переписываю так, как мне удобнее. Да и там этого кода совсем немного, чтобы изучить самостоятельно. Это шо шутка какая-то ? Собственное неглючное написание процедур кхала (со всеми реализациями прототипов) займёт куда меньше времени чем время и аккуратность выкорчёвывания килобайтов ненужного и глючного кода в КОНТЕКСТЕ ПРЕРЫВАНИЙ еще и завязанного с ихними статусными состояниями ?! Или вы не знаете что там по UART, I2C всё написано ногами. Ничего себе "немного кода". Следующую версию кхалла когда они выпустят, снова будете искать что ненужно и выкорчёвывать ? Детский сад.
  19. I2C на плате STM32F4Discovery

    Цитата(op3op3 @ Feb 9 2018, 05:23) HAL stm-овский проект, который активно развивается и его вылизывают на сотнях, тысячах проектов. а ваши самопальные библиотеки, заточенные под ваши личные проекты, используете только вы и сколько там косяков вам еще предстоит узнать. RTOS, файловую систему, .... вы видимо тоже свои пишете, по ночам, в свободное от основной работы время.. Косяки не пишу уже лет так 15, из 20 ... к примеру. Кто его развивает ? Специалисты ?! Кто будет вылаживать нормальный код, труд обкатанный годами во всеобщее пользование ?, это мягко говоря - антисоциально по отношению к проффесионалам. Для всех этих hardware опен сорсе - есть много общего: очень сложно выкорчевать, нереально дописать, присел - раб (трать время = деньги) - так как читать не умеешь документацию. Из всех неудобных мест по применению "универсального" кода - микроконтроллеры занимают первое место, так как постоянно приходится иметь дело с компромиссами (размер + скорость + оптимальная архитектура задачи + оптимальная работа с периферией). Применение языковых подходов для оптимизации кода, требует знания возможности и методов адресации процессорного ядра применяемого микроконтроллера. Всё это лучшее в существующей реализации кхала - отсутствует. А когда она будет допилена - то превратится в обычный код разработчика, с которым спорите по целесобразности применения кхала. Имел в виду разработчика со стажем, а не студента мечтателя. 1. Выгода применения аппаратной системы прерывания CORTEX - убита в корне. (ленивой программной реализацией - откатили до уровня 7TDMI). 2. Килобайты кода к контексте прерываний. (благо дело можно настроить приоритеты и разрешить вложенные, но это уже извращения на ровном месте). 3. Включаются прерывания, которые не разрешал. Корявая обработка. (неожиданные отработки прерываний, которые принципиально по архитектуре задачи не планировал и не разрешал) 4. Разработчики теряются и неправильно реализуют состояния программных статусов. (непонятный блуд с программными флагами и состояниями, невозможность гибкости в плане быстрого реагирования ) 5. Неумение работать даже с банальным UART, документацию не читают !!! (I2C) 6. Доведение до ума требует гарантированного выкорчевывания - 98 % кода, с куда более большими затратами по вниманию и времени. Любое из этого для меня лично критически - не приемлемо. STDLIB на stm32f7 - уже не поддерживается - жаль.
  20. Два варианта. HAL писали или немцы или индусы. Первые живут в идеальном мире, вторые к нему стремятся. Совет - выбросьте это Кхалл. Чтение документации по периферии + написание даже на CMSIS (лучше STDLIB) + отладка = займет в 100 раз меньше времени, чем написание костылей и сложного обхода граблей Кхалла. Извините за скромность - не выдержал. Из-за массовой рекламы и политики STM, этот кхалл разбросан по всему интернету, очень сложно не вступить.
  21. проблемы с SDHC

    Цитата(adnega @ Feb 20 2018, 15:46) В копилку статистики: я не использую. Извиняюсь за оскорбление Вашего трудового стажа .
  22. STM32F407 и USB с BULK

    LibUSB32 под винду. И полная кастрация MSC реализации (как toweroff советовал)с STM32 Stdlib, чтоб осталось только 3 usb функции . Собственно один раз чик и на долгое время хватит.
  23. проблемы с SDHC

    Цитата(alexey123_45 @ Feb 20 2018, 09:36) Сделал драйвер для работы с SDHC картой на STM32F407. Просто для статистики. Используете HAL или StdLib ??? Была такая проблема с определенными секторами. По моему с секурити областями связано. Так и не решил. Использовал другую карту где отсутствует такая вещь. Было еще пару проблем с делай тимингами CS линии, когда привинчивал FAT через SPI.
  24. STM32СubeMX и подобные

    STDlib для STM32 более менее приемлемое решение и понятное, к тому же не глючное. У HAL хорошая задумка и архитектура - но использовать эту индусскую реализацию просто не советую. Всё позже накроется медным тазом и потеряете лицо. Два выхода: тщательное изучение периферии внутренних модулей или выдергивание волос из носа, когда начинаются проблемы. Из опыта: у atmel и stm похоже одни и те же индусы на поддержке сидят. Самый простой внешний интерфейс как UART и с тем не умеют правильно работать (не могут сбрасывать флаги ошибок периферии, то есть не читают документацию). HAL от идус-STM это килобайты кода в контексте прерывания и понаставленные собственные грабли, с которыми сами авторы не могут разобраться. Разрешают срабатывания прерывания когда их об этом не просишь ну и т.д. Подход к прерываниям обусловлен старой архитектурой, когда она проэктировалась еще для 7-9 армы. Вместо выгоды в применении нового NVIC контроллера, который встроен в систему в CORTEX ядрах - HALL делает доунгрейт этой системы до скоростей уровня 7DMPI ядра + немеряно ненужного кода и времени нахождения в прерывании. С atmelом то же самое сейчас, непонятно кто пишет поддержку. Банальный uart, нет даже правильного чтения данных, который НАСТОЯТЕЛЬНО рекомендован производителями микросхем.
  25. Всем привет. При бифилярной безиндукционной намотке медного провода (сложенный в два), на куске феррита с магнитной проницаемостью 2000, увеличится ли ВОЛНОВАЯ ЗАДЕРЖКА пропускаемых через этот провод сигналов, от входа к выходу ? Есть соображения что увеличится, если пользоваться формулой V = 1 / корень квадратный (e*m) ; где e - электрическая , а v магнитная проницаемость среды. Принять так же во внимание то что медь осталась медью, но находится практически в прямом контакте с ферритом. Хочется знать действительно ли увеличится волновая задержка прохождения сигнала и примерно на сколько, по формуле (если принять что медь со своей проницаемостью равной 1 - стала ферритом с проницаемостью 2000) - выходит порядка 40 раз ! Будет ли волновое замедление хотя бы в раз 10 ?