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

firstvald

Свой
 Профиль  Обзор контента

  • Публикаций

    580

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Знающий
  • День рождения 12.08.1970

Контакты

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

  1. индикатор MC14489B.pdf

    firstvald ответил addi II в теме Программирование

    я бы добавил: char str[16];//пусть больше - у нас не будет проблем с вылезанием за границы массива memset(str,0,sizeof(str)); sprintf(str, "% 5u", data);// ну и можно поиграться sprintf(str, "% -5u", data); и посмотреть как будет удобнее отображаться а вопрос стоял: что потом делать с получившейся строкой? и какой индикатор? сегментный/ графический? если сегментный, то вполне возможно сделать своей функцией которая числа (0 1 2 3....), а не символы (0x30 0x31 0x32 0x33 ....) переводит в сочетания сегментов.

  2. Ошибка в цепочке заголовков. В конце: cmsis_armcc.h

    firstvald опубликовал тема в ARM, 32bit

    Одновременно получил две загадки. В начале программных модулей, в поле слева, помечено красным крестиком строчка #include "stm32l4xx_hal.h" Если идти по цепочке файлов, то попадаем в файл cmsis_armcc.h в котором красным выделены несколько строчек с пояснением expected identifier or '('. Место, которое не нравится, прыгает. Был момент, когда не нравилась одна строка. Начиная с какого-то момента не нравится несколько других. В данный момент, не нравится: #ifndef __NO_EMBEDDED_ASM __attribute__((section(".rev16_text"))) __STATIC_INLINE __ASM uint32_t __REV16(uint32_t value) { rev16 r0, r0 bx lr } #endif не нравящееся слово выделено цветом. В файле ничего не трогал. Не думаю, что в этом какая-то ошибка - это что-то наведенное. Но что ? Мювижн 5 14 00 . Файл к которому приводит цепочка помечен как: @file cmsis_armcc.h * @brief CMSIS Cortex-M Core Function/Instruction Header File * @version V4.30 * @date 20. October 2015 и беда на приходит одна: в окне хода компиляции получаю вот это: Error: L6218E: Undefined symbol HAL_SPI_IRQHandler (referred from stm32l4xx_it.o). при этом, видно, что файл, в котором определен обработчик HAL_SPI_IRQHandler, компилируется. И в самом файле он есть: Вот упоминание нечто похожего. Решение было перейти на другой CMSIS

  3. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    Цитата(SasaVitebsk @ Mar 9 2016, 10:17) Странно, вам не кажется? Во всём разобрался, а не работает. да у меня- то работает. а вы уверены, что у вас работет? описал фичу, написал как обойти, а "пронициательные читатели" так видно ничего не поняли. ну эта скрепа в порядке вещщей.

  4. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    Цитата(ViKo @ Mar 7 2016, 15:02) Я принимаю и передаю и никаких проблем не имею. Все согласно документации. Первый байт посылаете не в прерывании. Разрешаете прерывания от TXE. Остальные байты посылаете по прерыванию. Сбрасывать флаг не нужно. Перед передачей последнего байта ('\n'), запрещаете прерывания. кстати говоря, если бы я не стал придираться и смотреть осциллограмму, то после первой посылки у меня все работает безо всяких вопросов. и я был бы уверен что все в порядке. Цитата(ViKo @ Mar 7 2016, 18:19) Вы не разобрались, как работает rc_w0. Такой бит можно прочитать, или сбросить, записав 0. А записать 1 в него невозможно. И поэтому можно смело записывать единицы, они не повредят. я -то как раз прекрасно разобрался в rc_w0

  5. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    Цитата(AHTOXA @ Mar 7 2016, 17:32) Ну какой же вы тупой! (с) Вам уже и пример привели, и на словах объяснили. Вы прочитали, там ещё несколько нулей. И все эти биты вы сбросили записью. А между тем моментом, когда вы прочитали, и записью, могли взвестись ещё флаги. И вы их таким образом потеряете. Именно для того, чтобы избежать таких ситуаций, делают rc_w0. Чтобы можно было смело писать единичку в остальные биты, и от этого их состояние не менялось. это надумано. тогда подумайте что будет в момент между чтением флагов когда мы решили что они нули и записью туда 0 прямой командой записи. не повторяйте чужие мантры, учитесь думать сами и внимательно слушать, когда до вашего сведения аккуратно доводят, что тут что-то не так. а как научитесь, милости просим на форум. Цитата(ViKo @ Mar 7 2016, 17:49) А когда (зачем) это нужно знать? А, ну если приемопередатчики RS-485 переключать со входа на выход... ну двухпроводной уарт в промышленности практически не используется (если только диагностический порт с морды или какой прибор с несетевым обменом). если только при общении с беспроводными модулями - у них еще отдельные TX RX. А так, поголовно RS485 (там где не TCP).

  6. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    сразу не сообразил. чтение модификация запись - как раз точно то, что надо и делает. флаг помечен как rc_w0 - т е его можно прочитать и он сбрасывается записью нуля. ну так, чтение модификация запись собственно это и делает. мы прочитали (да, этого можно было и не делать) , сбросили нужный бит и записали . все в стандартной, принятой для битовой работе манере. и то, что нужно по описанию регистру

  7. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    TC поднимается когда TXE выставлен -> записывая в буферный регистр по TC мы имеем двойную гарантию что делаем это вовремя: и из буферного регистра в сдвиговый переписались и уже и из сдвигового выдвинули. да , флаги помечены как сбрасываются записью нуля (кстати, хорошее замечание). но отладчиком я вижу , что чтение модификация работают (да если посмотреть примеры кода в сети , то народ чтением модификацией стирает).

  8. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    вот на самом деле именно обратно! чтобы понять, что мы окончили передачу, нужно использовать TC, иначе сразу начинается геморрой с выдержкой времени после TXE, да еще перестраиваемая в зависимости от скорости. это, кстати, на одноплатках народ попадается - там тяп ляп сделано и когда используют RS485 и аппаратное управление направлением передачи, то в конце посылки 485 переключается на прием в момент, когда последний байт переписывается в сдвиговый регистр и еще не передался (но прерывание возникло, что в уарт можно писать следующее!), а его обкусили т к посчитали, что все уже передали. TXE я, наверное, посмотрю, как он себя ведет. но дело не в них.

  9. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    мне не нужно TXE , мне нужно TC. фокусы с \n не пройдут (да где вы все работаете что у вас символьные строки бегают до сих пор ?!). все что происходит я описал подробнейшим образом. и как лечится тоже.

  10. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    а что значит проверить? скорости обмена соответствуют для линейки от 1200 до 115200. для шин 1 и 2 выбрано 1:1. и это как-то может объяснить, что приемопередатчик умудряется переставить два байта местами? кстати, это означает, что унутре у него вовсе все не так устроено, как на блок схеме нарисовано.

  11. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    вот что удалось понять. не зря обратил внимание, что байт уходит на передачу вовсе не сразу. получается , что после инициирования приемопередатчика , несмотря на то, что он был явно сброшен вначале, он еще не готов к работе. ему необходим один (а может два) формальных циклов передачи, прежде чем он будет работать правильно. после того, как будут переданы пара байт, дальше приемопередатчик будет работать без пропусков и перестановок. это объясняет, почему не всегда на это поведение обращают внимание. в готовом приборе после первой битой посылки обмен будет происходить без замечаний. т е, в инициализации приемопередатчика нужно предусмотреть формальную передачу одного двух байт. если критично появление посылок на ножках - переключение ножек на альтернативные функции нужно перенести после окончания посылки. Код    USART3->SR&=~USART_SR_TC;     USART3->DR=0xff;     while((USART3->SR&USART_SR_TC)==0){ ;                                          }               USART3->SR&=~USART_SR_TC; после инициализации и вот такого кусочка кода, дальше посылки уходят правильно. отмечу, что этот кусочек для скорости 115200 выполнятся порядка 100 микросекунд. т е десятикратно от длительности передачи одного байта. посмотрю еще как все это себя ведет , может засада эшелонированная.

  12. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    да сбросятся, но они мне тут не нужны . не в приеме дело - ту эффект вот какой: я вижу вот что. пробую передать строку из 3 символов (0x30 0x31 0x32 ). что происходит: по записи (я все поотключал - таймеры и уарты- оставил только этот уарт) я сейчас с 3 работаю - там код одинаковый USART3->DR=tx_buf3[tx_ptr3]; на ножку вовсе ничего не передается, но возникает прерывание с выставлением TC . у меня в прерывании честно указатель буфера инкрементируется и в регистр DR записывается следующий байт т е 1. и вот он появляется на ножке. а после выхода из прерывания на передачу отправляется 0 байт из буфера! т е в линии оказывается что нулевой и первый байты оказываются переставленными местами! а вот начиная со следующего прерывания последовательность передачи - правильная. и я вижу что уходит 0x31 0x30 0x32 вот что происходит в начале - почему переставляется 0 и первый байт местами я понять не могу. и спасибо огромное за внимание!

  13. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    да нет. по флагу от передатчика сбрасывается флаг передатчика и по флагу приемника сбрасывается флаг приемника. а если кто остался несброшеным - сбросится перед выходом из прерывания. я нигде не встречал указания, чтобы для сброса битов регистра SR требовался особый синтаксис, нигде больше не применяемый.

  14. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    Цитата(Genadi Zawidowski @ Mar 6 2016, 22:57) бит в регистре во все времена сбрасывался именно так: регистр &=~ (слово размером с регистр с единичным выставленным битом); хотя действительно предлагаемая функция USART_ClearFlag (из STM32F10X_USART.C)для сброса использует конструкцию USARTx->SR = (uint16_t)~USART_FLAG; но это скорее исключение(довольно безграмотное), которое вероятно работает благодаря особенностям регистра SR. При поочередной передаче флаг приема не может появится после попадания в тело прерывания, иначе как бы мы туда попали? и что вообще бы вызвало прерывание? это могло бы быть теоретически в случает одновременной передачи и приема, но обычный обмен с приборами такого не предполагает, идет запрос ответная работа. и при запросно -ответной работе появление прерывания от приема в момент передачи считается мусором и такие символы должны игнорироваться. аналогично появление прерывания от передачи в момент приема является мусором и его нужно игнорировать и выключить если оно по каким то причинам включилось. на практике при передаче в приемник действительно может попадать мусор и в некоторых вариантах обмена передаваемая строка. во всех случаях эти символы должны игнорироваться. посмотрел конструкцию USART3->SR=~USART_SR_RXNE;//**сбросим флаг тоже работает. но рекомендовать использовать это я бы никому не стал

  15. stm32f100 USART задержка передачи и потеря символов

    firstvald ответил firstvald в теме ARM

    это если передаем символы. последний раз у меня это было году так в 99. а дальше модбас RTU. там в пределах строки все что угодно может быть.