Соответственно тогда нужна и прога (для ж-линка или ст-линка), которая отображает то что валится из контрошки по SWO.
Сеггеровский SWO Viewer, наскока я вижу, хочет сначала прицепиться к таргету зачем-то, а потом наверное начнёт работать.
А зачем это надо, если SWO всё равно однонаправленный?
Казалось бы, лови всё что валится, как по UARTу, и всё.
Полная версия этой страницы: Вывод через SWO без установления "соединения"
не могу утверждать что дело не в моих руках но у меня при выводе через SWO без программатора контроллер стопорится
Цитата(Dr.Alex @ Nov 4 2016, 02:24) 
Сеггеровский SWO Viewer, наскока я вижу, хочет сначала прицепиться к таргету зачем-то, а потом наверное начнёт работать.
Разве? А я и не заметил - подцеплял вживую (LPC1788), ничего не стопорилось, вывод был. Главное, частоту правильную указать.
Правда, гуишный падал постоянно, консольный, вроде, дольше жил.
Если что - вот из CMSIS функция выдачи символа
Код
/**
\brief ITM Send Character
\details Transmits a character via the ITM channel 0, and
\li Just returns when no debugger is connected that has booked the output.
\li Is blocking when a debugger is connected, but the previous character sent has not been transmitted.
\param [in] ch Character to transmit.
\returns Character to transmit.
*/
__STATIC_INLINE uint32_t ITM_SendChar (uint32_t ch)
{
if (((ITM->TCR & ITM_TCR_ITMENA_Msk) != 0UL) && /* ITM enabled */
((ITM->TER & 1UL ) != 0UL) ) /* ITM Port #0 enabled */
{
while (ITM->PORT[0U].u32 == 0UL)
{
__NOP();
}
ITM->PORT[0U].u8 = (uint8_t)ch;
}
return (ch);
}
\brief ITM Send Character
\details Transmits a character via the ITM channel 0, and
\li Just returns when no debugger is connected that has booked the output.
\li Is blocking when a debugger is connected, but the previous character sent has not been transmitted.
\param [in] ch Character to transmit.
\returns Character to transmit.
*/
__STATIC_INLINE uint32_t ITM_SendChar (uint32_t ch)
{
if (((ITM->TCR & ITM_TCR_ITMENA_Msk) != 0UL) && /* ITM enabled */
((ITM->TER & 1UL ) != 0UL) ) /* ITM Port #0 enabled */
{
while (ITM->PORT[0U].u32 == 0UL)
{
__NOP();
}
ITM->PORT[0U].u8 = (uint8_t)ch;
}
return (ch);
}
Цитата(Dr.Alex @ Nov 4 2016, 04:24)
Сеггеровский SWO Viewer, наскока я вижу, хочет сначала прицепиться к таргету зачем-то, а потом наверное начнёт работать.
Чтобы задействовать тактирование, и вписаться в 5% допуска. Иначе частота может получится любой, и детект на приёмной стороне будет намного сложнее.
Мне просто интересно, зачем внезапно понадобился SWO в автономном режиме? На чипе просто дофига аппаратных интерфейсов, нет - будем ногодрыгать через swo.
Цитата(AVI-crak @ Nov 4 2016, 15:55)
Мне просто интересно, зачем внезапно понадобился SWO в автономном режиме? На чипе просто дофига аппаратных интерфейсов, нет - будем ногодрыгать через swo.
чтобы не разводить отдельно. SWO часто уже разведен на разъем программатора. да и иногда интересно в терминале понаблюдать как ведет себя железка
И убить статикой нормально работающий дорогой девайс? увольте.
Если хочется снимать логи, для этого есть куча возможностей. Начиная от варта с оптической развязкой, заканчивая запаянным на пузо чипом esp8266, без платки он занимает минимальное пространство. А мой последний логгер общался через вч пищалку, потому как висел на шине в десятки киловольт (буквально).
Тут прикол в том что девайс может управлять массивной железякой, которая при наличии движения/вращения - может натворить не мало бед в случае сбоя основного чипа. Сломанные резцы, отключившийся насос, вентиляция не вовремя, или даже просто внезапно сработавшее силовое реле может стоить чей-то жизни.
Когда ваша печатка с мк начинает реально управлять внешним оборудованием, доступ к ней должен быть ограничен.
Это как замок на трансформаторной будке, все знают что может убить - но без замка идиоты всё-же находятся.
Если хочется снимать логи, для этого есть куча возможностей. Начиная от варта с оптической развязкой, заканчивая запаянным на пузо чипом esp8266, без платки он занимает минимальное пространство. А мой последний логгер общался через вч пищалку, потому как висел на шине в десятки киловольт (буквально).
Тут прикол в том что девайс может управлять массивной железякой, которая при наличии движения/вращения - может натворить не мало бед в случае сбоя основного чипа. Сломанные резцы, отключившийся насос, вентиляция не вовремя, или даже просто внезапно сработавшее силовое реле может стоить чей-то жизни.
Когда ваша печатка с мк начинает реально управлять внешним оборудованием, доступ к ней должен быть ограничен.
Это как замок на трансформаторной будке, все знают что может убить - но без замка идиоты всё-же находятся.
Цитата(AVI-crak @ Nov 4 2016, 15:55)
На чипе просто дофига аппаратных интерфейсов, нет - будем ногодрыгать через swo.
Вам нужно ногодрыгать, вы и ногодрыгайте, и не надо приписывать своих глупостей мне.
ITM это и есть стандартизованный аппаратный интерфейс, и мой вопрос именно об его использовании по назначению.
Он уже выведен на разъём, а на столе уже лежит ж-линк. Почему я должен изобретать велосипед?
Для остальных пишу по существу:
Некоторое изучение темы показало, что ARM немного облажались и не предусмотрели возможности ПРОГРАММНО переключить ITM из режима JTAG в режим SWD/SWO, для этого якобы надо немножко подёргать лапами JTAG извне.
Пруфлинки:
https://my.st.com/public/STe2ecommunities/m...urrentviews=114
https://community.arm.com/thread/2519
Но и с этим полной ясности нет.
Вообще же вопрос проистекает из желания выводить отладочные сообщения стандартными средствАми в случае когда контроллер бОльшую часть времени выключен вообще, и лишь изредка включается на считанные миллисекунды.
В моём понимании "выключен" - снято питание.
Режим сон - есть питание, выключена периферия и остановлено ядро. Если отключить ещё и память (нет смысла) - то для отладочного интерфейса остаются регистры ядра.
Режим стоп - остановлено ядро (потребление почти ноль), работает необходимая периферия. Из этого режима можно отладочным интерфейсом читать память. Насколько я верно понял - вам именно это и нужно.
Есть выход, http://www.emblocks.com/forum/viewtopic.ph...89282df567ec09e
Там всё просто. Есть буфер - который заполняется сообщениями от системы, есно когда она работает. Отладочный интерфейс читает этот буфер с максимальной скоростью без остановки ядра, как обычную память. Общаться можно в обе стороны. Этот режим отладки идеально подходит для систем реального времени.
Хотя мне проще задействовать четыре контакта для варта, и через оптику.
Насчёт ногодрыга, отправка сообщений через SWO - лишь частично аппаратная, проверку условий необходимо выполнять ручным способом. Это означает что таск работающий с отправкой сообщений - будет выполняться со скоростью физического порта.
Тот-же варт можно пнуть через дма, и заняться другими делами.
Режим сон - есть питание, выключена периферия и остановлено ядро. Если отключить ещё и память (нет смысла) - то для отладочного интерфейса остаются регистры ядра.
Режим стоп - остановлено ядро (потребление почти ноль), работает необходимая периферия. Из этого режима можно отладочным интерфейсом читать память. Насколько я верно понял - вам именно это и нужно.
Есть выход, http://www.emblocks.com/forum/viewtopic.ph...89282df567ec09e
Там всё просто. Есть буфер - который заполняется сообщениями от системы, есно когда она работает. Отладочный интерфейс читает этот буфер с максимальной скоростью без остановки ядра, как обычную память. Общаться можно в обе стороны. Этот режим отладки идеально подходит для систем реального времени.
Хотя мне проще задействовать четыре контакта для варта, и через оптику.
Насчёт ногодрыга, отправка сообщений через SWO - лишь частично аппаратная, проверку условий необходимо выполнять ручным способом. Это означает что таск работающий с отправкой сообщений - будет выполняться со скоростью физического порта.
Тот-же варт можно пнуть через дма, и заняться другими делами.
Цитата(AVI-crak @ Nov 5 2016, 18:24)
Насчёт ногодрыга, отправка сообщений через SWO - лишь частично аппаратная, проверку условий необходимо выполнять ручным способом. Это означает что таск работающий с отправкой сообщений - будет выполняться со скоростью физического порта.
Тот-же варт можно пнуть через дма, и заняться другими делами.
Тот-же варт можно пнуть через дма, и заняться другими делами.
1. Скорость SWO, как правило, выше чем скорость UART.
2. Бывает так, что все UARTы заняты...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.