Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: STM32F1->MCO качество сигнала
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Tahoe
STM32F100, пин PA8, с альтернативными функциями USART1_CK / MCO / TIM1_CH1. Таймер1 отключен. USART1 включен, работает в асинхронном режиме. Включил MCO ( вывод клока для внешнего использования ), в качестве источника клока HSI. Наблюдаю такую картину, в моменты передачи по USART1:

Нажмите для просмотра прикрепленного файлаНажмите для просмотра прикрепленного файла

Круто. Сам сигнал с MCO выводится для тактирования ПЛИС.

Кто-нить уже сталкивался с подобным?

С инициализацией проблем нет, там всего две строчки:
Код
void    BspPldInit( void )
{
    McuPinConfig(        MCU_PIN_PA08,        MCU_PIN_MODE_OUT_PP_AF_10MHz    );
    McuClkOutConfig(    MCU_CLK_OUT_SRC_HSI                                 );
}
diwil
подтверждаю.
когда работает уарт на передачу, то он создает массу помех.
В некоторых случаях становится даже невозможным использования АЦП.
У меня еще и таймер генерит 400кГц - на этом выходе тоже жуткая наводка.
Правда это наблюдается на f405.
DASM
А можно посмотреть код инициализации на уровне ассемблера, а не дурацких макросах от стм?
DASM
Очередной "бэгрипорт" не состоялся ?
ViKo
Цитата(Tahoe @ May 28 2013, 18:15) *
Круто. Сам сигнал с MCO выводится для тактирования ПЛИС.

Не могу в это поверить. С печатными проводниками всё нормально, ничто ни за что не зацепилось?
Tahoe
Цитата(ViKo @ May 30 2013, 15:01) *
Не могу в это поверить. С печатными проводниками всё нормально, ничто ни за что не зацепилось?

На PCB напортачить практически не реально, всего один короткий проводник.

Нажмите для просмотра прикрепленного файла



Цитата(DASM @ May 30 2013, 12:49) *
Очередной "бэгрипорт" не состоялся ?

Пока просто интересует опыт тех, кто _реально_ работал с сабж.
Цитата(DASM @ May 29 2013, 09:05) *
а не дурацких макросах от стм?

- они не дурацкие, а единообразные на всех используемых мной архитектурах МК, что для ARM, что для AVR, что для MSP
- не макросы
- не от ST
Genadi Zawidowski
Ну пять-то вольт откуда в процессоре вообще? Это не из ПЛИС идёт? Я использовал выход для контроля в целиком работающей системе (STM32F105) - ничего необъяснимого не наблюдал.
Tahoe
Цитата(Genadi Zawidowski @ May 30 2013, 23:08) *
Ну пять-то вольт откуда в процессоре вообще? Это не из ПЛИС идёт?

Нет. На плате всего одно питание 3,3В. Масштаб каритнки 0,5В в клетке.

Цитата(Genadi Zawidowski @ May 30 2013, 23:08) *
Я использовал выход для контроля в целиком работающей системе (STM32F105) - ничего необъяснимого не наблюдал.

С работающим UART1?
ViKo
А вы посмотрите, что делается на разных концах 100 Ом резистора. Частота MCO у вас меньше частоты паразитных тактов (больше похоже на такты, чем на данные, очень уж регулярные). Может, из ПЛИС что-то лезет? Амплитуда MCO меньше 2В - тоже странно.

MCO использую для тактирования контроллера ЖКИ. Работает. Правда, бывают некие редкие пропадания картинки. Думал, программые косяки. Гляну внимательнее на такты.
Genadi Zawidowski
Цитата(Tahoe @ May 31 2013, 01:10) *
Нет. На плате всего одно питание 3,3В. Масштаб каритнки 0,5В в клетке.


С работающим UART1?


Во всяком случае, с проинициализированным. 57600 при тактовой процессора 72 МГц, внешний 8 МГц кварц.
khach
Цитата(Tahoe @ May 28 2013, 17:15) *
Кто-нить уже сталкивался с подобным?

С инициализацией проблем нет, там всего две строчки:

С чем сталкивались? С кривой инициализацией многфункционального пина? Постоянно. Обычно по причине криворукости программистов при использвании стандарных библиотек. Инициализацию USART1 еще покажите (вернее его ножек)- очень вероятно что USART1_CK активен и подключен к ноге.
Зы. Иногда это глюки самого кристалла инжинерных ревизий- попробуте поменять порядок инициализации периферии в стартапе программы.
DASM
Абсолютно поддерживаю. Если Вы видели эти стмовские полумакросы-полуфункции (иногда и не понять что есть что, где он начинается, от чего перекрестно зависит и главное - зачем он нужен для выставления одного бита при старте проца) то все поймете.
koyodza
Использовал МСО для тактирования внешнего АЦП частотой 12МГц (выход HSE), был задействован USART1, всё отлично работало. Правда, на F103, но это скорее всего не важно.
Проверьте, не установлен ли бит CLKEN в USART1->CR2
Если на пин выведены альтернативные функции от нескольких модулей, нужно быть внимательным и не допускать одновременной работы таких модулей либо блокировать работу альтернативной функции в одном из модулей. В Вашем случае выход CLK у USART1 должен быть запрещен.

Цитата(DASM @ Jun 1 2013, 16:59) *
Если Вы видели эти стмовские полумакросы-полуфункции (иногда и не понять что есть что

Чтобы так говорить, нужно вначале самому их видеть. В приведенном топикстартером фрагменте использованы не стандартные библиотечные функции, а свои.
Как раз при отказе от библиотечных функций часто и возникают ошибки, связанные с неправильной инициализацией периферии. Поэтому прежде, чем писать свои функции, напрямую работающие с регистрами, лучше вначале взять и разобраться со стандартными, понять где и что не нравится, и только потом уже писать свои
DASM
Да никто не против, а еще лучше - привести кусок дизасма, но автор убежал.
scifi
Цитата(koyodza @ Jun 1 2013, 18:29) *
Поэтому прежде, чем писать свои функции, напрямую работающие с регистрами, лучше вначале взять и разобраться со стандартными, понять где и что не нравится, и только потом уже писать свои

Это уже пошёл оффтопик, но я, тем не менее, вставлю свои 5 копеек. Всегда манипулировал регистрами, опираясь только на Reference Manual. Всё получалось. Библиотеку не использовал из-за неприязни (кривой она показалась). Сейчас, однако, мог бы и потерпеть неприязнь, если библиотека реально ускоряет разработку: жизнь слишком коротка. Старею, наверное :-)
ViKo
Цитата(scifi @ Jun 1 2013, 22:22) *
Всегда манипулировал регистрами, опираясь только на Reference Manual. Всё получалось. Библиотеку не использовал из-за неприязни (кривой она показалась)...

Аналогично. Но вот, подбираюсь к USB, и, поскольку дело новое и, говорят, тяжелое, не знаю, что лучше - разбираться самому с битами или 05.gif разбираться с функциями (и потом все равно с битами).
Golikov A.
2 раза на 2 разных процах написал без библиотек по мануалу.
В обоих случаях нашел несколько ошибок в предложенных примерах реализации, и пару неточностей...
Фиг знает, может это старость и консерватизм, но так я и не научился доверять чужому бесплатному коду без проверки...
ViKo
Цитата(Golikov A. @ Jun 3 2013, 14:32) *
2 раза на 2 разных процах написал без библиотек по мануалу.

Вы говорите об USB или, вообще, о программе для микроконтроллера?
Tahoe
Цитата(koyodza @ Jun 1 2013, 18:29) *
Проверьте, не установлен ли бит CLKEN в USART1->CR2

Сначала как раз так и было. И на выходе наблюдал клок от USART. Но на момент создания топика, режим USART был изменен на асинхронный.

Цитата(koyodza @ Jun 1 2013, 18:29) *
Как раз при отказе от библиотечных функций часто и возникают ошибки, связанные с неправильной инициализацией периферии.

Именно потому и спросил, сталкивался кто-либо с подобным.

Цитата(koyodza @ Jun 1 2013, 18:29) *
Поэтому прежде, чем писать свои функции, напрямую работающие с регистрами, лучше вначале взять и разобраться со стандартными, понять где и что не нравится, и только потом уже писать свои

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

Код
...
typedef    enum    STM32_USART_SR_e
{
    STM32_USART_SR_PE                            =     0,
    STM32_USART_SR_FE                            =     1,
    STM32_USART_SR_NE                            =     2,
    STM32_USART_SR_ORE                            =     3,
    STM32_USART_SR_IDLE                            =     4,
    STM32_USART_SR_RXNE                            =     5,
    STM32_USART_SR_TC                            =     6,
    STM32_USART_SR_TXE                            =     7,
    STM32_USART_SR_LBD                            =     8,
    STM32_USART_SR_CTS                            =     9
}    STM32_USART_SR;

typedef    enum    STM32_USART_CR1_e
{
    STM32_USART_CR1_SBK                            =     0,
    STM32_USART_CR1_RWU                            =     1,
    STM32_USART_CR1_RE                            =     2,
    STM32_USART_CR1_TE                            =     3,
    STM32_USART_CR1_IDLEIE                        =     4,
    STM32_USART_CR1_RXNEIE                        =     5,
    STM32_USART_CR1_TCIE                        =     6,
    STM32_USART_CR1_TXEIE                        =     7,
    STM32_USART_CR1_PEIE                        =     8,
    STM32_USART_CR1_PS                            =     9,
    STM32_USART_CR1_PCE                            =    10,
    STM32_USART_CR1_WAKE                        =    11,
    STM32_USART_CR1_M                            =    12,
    STM32_USART_CR1_UE                            =    13,
    STM32_USART_CR1_OVER8                        =    15
}    STM32_USART_CR1;

...


В реальности, с учетом нехватки времени, процесс выглядит немного иначе.при необходимости задействовать в очередном проекте ту или иную периферию, под нее создается библиотека. В общем, конечно, она проверяется на предмет всех режимов, но понятно дело, что проблемы вылезают только в тех режимах, которые используются в данном проекте. На примере того же USART - если на момент создания библиотеки, в проекте использовался асинхронный режим, по понятным причинам именно он протестирован наиболее тщательно.
С другой стороны, единообразие, при кодировании, позволяет свести потенциальные ошибки к минимуму.



Цитата(scifi @ Jun 1 2013, 23:22) *
Всегда манипулировал регистрами, опираясь только на Reference Manual. Всё получалось. Библиотеку не использовал из-за неприязни (кривой она показалась). Сейчас, однако, мог бы и потерпеть неприязнь, если библиотека реально ускоряет разработку: жизнь слишком коротка. Старею, наверное :-)

Подход, конечно, правильный. Но я, например, последнее время, постоянно сталкиваюсь с невысоким качеством кода. Собсно, последний раз, когда я видел/использовал пристойный код от производителей микроконтроллеров, это был USB-стек от Атмел - хорошо типизированый, с вменяемой структурой.
Что касается библиотек, то помнится напарывался у того же Атмел, в ней же была проблема при работе с SPI, что-то касательно SS. А про ST даже говорить не хочу.

Цитата(DASM @ Jun 1 2013, 19:28) *
Да никто не против, а еще лучше - привести кусок дизасма, но автор убежал.

Нет, .... Никто, никуда не убежал. Все банальнее:

2. ... нахожусь в сильном цейтноте.
Golikov A.
Цитата(ViKo @ Jun 3 2013, 23:51) *
Вы говорите об USB или, вообще, о программе для микроконтроллера?


про УСБ конечноsm.gif)), если бы я всего 2 программы написал, я бы постеснялся вообще говоритьsm.gif на армах и на 51 ядре на двух разных контроллерах с подержкой усб. Причем на 51 ядре было очень низкоуровневая поддержка, там очень много чего надо было руками делать, в армах намного проще сейчас. В первом случае ушло около 2 месяцев, но я там еще и стандарт усб изучал, во втором случае около месяца с отладкой.

jcxz
Цитата(ViKo @ Jun 3 2013, 14:20) *
Аналогично. Но вот, подбираюсь к USB, и, поскольку дело новое и, говорят, тяжелое, не знаю, что лучше - разбираться самому с битами или 05.gif разбираться с функциями (и потом все равно с битами).

Если на LPC (ARM7 и Cortex-M3) - я использовал стек из примеров NXP. Что-то в нём переделал/оптимизировал, на что-то закрыл глаза. Но можно его юзать и как есть - вполне работоспособный хоть и не оптимальный.
Использовал control- и изохронные передачи, с DMA и без.
На OMAP-L137 пришлось писать свой стек, так как варианты были - или брать готового кота в мешке со встроенной непонятной ОС и в бинарниках (а по объёму занимаемых ресурсов - не кота, а слона), или из-за стека тащить в нормально работающую реалтайм-систему линух.
Использовал и на 51-ядре, но это отдельная песня.
На написание стека на ARM-ядро OMAP у меня примерно так же как и у уважаемого Golikov A. ушло около месяца (на базе знаний полученных ранее при использовании стеков от NXP).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.