s
@winged_pegasus аэротакси, тут тебя вспоминают!
Size: a a a
2020 December 18
OK
y
не, я не про jlink, я про black magic.
а, извиняюсь не заметил, у него же встроенный сервер.
И еще такой вопрос: может кто знает. Если ставлю breakpoint то Clion останавливает отладку, или правильнее сказать JLinkserver. это когда отладка запущена... как этого избежать, а то BT стек такой реалтаймовый :(
И еще такой вопрос: может кто знает. Если ставлю breakpoint то Clion останавливает отладку, или правильнее сказать JLinkserver. это когда отладка запущена... как этого избежать, а то BT стек такой реалтаймовый :(
y
а, извиняюсь не заметил, у него же встроенный сервер.
И еще такой вопрос: может кто знает. Если ставлю breakpoint то Clion останавливает отладку, или правильнее сказать JLinkserver. это когда отладка запущена... как этого избежать, а то BT стек такой реалтаймовый :(
И еще такой вопрос: может кто знает. Если ставлю breakpoint то Clion останавливает отладку, или правильнее сказать JLinkserver. это когда отладка запущена... как этого избежать, а то BT стек такой реалтаймовый :(
Ну либо подизэйблить, либо убрать бряк.
P
Справедливости ради - я не реинитил SPI после изменения частот на RCC и видимо ничего не глючило.
Но не исключаю, что я So special, а реинит никогда не помешает.
Но не исключаю, что я So special, а реинит никогда не помешает.
там дело даже не в реинитах, а в том, что при переходе сигнала из одного клокового домена в другой он по сути приходит на входные триггеры асинхронно. может попасть в момент времени, когда триггер войдет в метастабильность и долго (или почти никогда по меркам процессорных скоростей) из нее не выйдет. Ну а это рэндомный крэш рэндомного блока
КП
@winged_pegasus аэротакси, тут тебя вспоминают!
Слыыыш
OK
y
Ну либо подизэйблить, либо убрать бряк.
не я не про сам бряк, я про то что во время работы программы в режиме отладки, когда ставишь новый бряк, то приостанавливает отладку на том моменте где сейчас програма. Выход нашел только один - ставить бряки до запуска отладки... но это так. проявилось только с JLinkServer. Сами бряки понятно только на критичных моментах чтобы посмотреть что да как и перезапустить программу
jp
Я вот долго думал - и не придумал :)
Там выше моей ссылки с чего все началось - кинули ссыль на протокольчик min-чего-то там. Так он такой же по сути, чутка наворотов ток добавлено. И тп
Там выше моей ссылки с чего все началось - кинули ссыль на протокольчик min-чего-то там. Так он такой же по сути, чутка наворотов ток добавлено. И тп
Кстати, вот второй протокол чик, вроде мне зайдёт в один проект, завтра буду курить, но по переписке похоже на нужную вещь.
Я не совсем понял зачем твоё шаманство нужно с изменением первых 2х байт посылки и как это прокуривает приёмник?
Я не совсем понял зачем твоё шаманство нужно с изменением первых 2х байт посылки и как это прокуривает приёмник?
y
не я не про сам бряк, я про то что во время работы программы в режиме отладки, когда ставишь новый бряк, то приостанавливает отладку на том моменте где сейчас програма. Выход нашел только один - ставить бряки до запуска отладки... но это так. проявилось только с JLinkServer. Сами бряки понятно только на критичных моментах чтобы посмотреть что да как и перезапустить программу
А, это вот. Есть мнение, давно надо на этот счет тикет кинуть. Я если что из JB, но сам так и не собрался :)
jp
Как я понял, ты мониторишь то, какие байты встречаются. Получается приёмник на ходу проверяет посылки, и по сообщениям определяет какие стартовые байты и тут мне видится проблема. Если ты получил 100 сообщений, например, то как понять где начало сообщения если у тебя стартовые байты меняются
A
Как я понял, ты мониторишь то, какие байты встречаются. Получается приёмник на ходу проверяет посылки, и по сообщениям определяет какие стартовые байты и тут мне видится проблема. Если ты получил 100 сообщений, например, то как понять где начало сообщения если у тебя стартовые байты меняются
0xAA55 (или что-то похожее) в качестве заголовка ставь, а в конце пакета фиксированного размера контрольную сумму. )
P
я обычно (не стоит задача энергосбережения) поступаю точно также: шлю пакеты один-за-другим с признаком начала пакета (уникальный символ, выбранный из соображений еще улучшения синхронизации UART, в теле пакета он меняется на комбинацию других символов - несколько дней назад как раз обсуждали этот простецкий протокол), фиксированной длной пакета - ну это вариабельно, просто мне не нужжно было усложнять, в конце CRC. С малой (но ненулевой) вероятностью CRC конечно не заметит повреждения пакета - вот именно для этого шлю их непрерывно - как раз примерно 1к посылок в сек и получается. Для целей управления и мониторинга всегда хватало. Для особо критичных параметров управления, если таковые есть в пакете, чтобы исключить даже случай единичного пропуска ошибки на то малое время, пока не пришел новый пакет с верным значением - прогоняю через фильтр этот параметр - мне критично важно отсутствие резких всплесков в этих вещах. Собсна все отлично работает даже тогда, когда длинная, неграмотно сделанная на соплях линия (правда везде гальва как де-факто) и пакеты не проходят CRC до 50+ % от общего числа. Ща скину обсуждение протокола если интересно.
Кароче кратко: все норм, делайте! :)
Кароче кратко: все норм, делайте! :)
@Bahoo08 вот что еще вспомнил: нужна была длинная линия: ниче длиннее 305м бухты говеной витой пары, сложенной бухтой (индуктивность!) не нашлось. уж не вспомню, какие там были приемо-передатчки и была ли гальва - но никаких мер типа терминаторов и пр. на концах не применялось, но факт фактом: корректно проходило лишь несколько % пакетов (скорость 9600, RS-422). Ну, лишь задержки возросли. Связь возможна, работа выполнена. Интересно, что простое разматывание бухты в линию увеличило долю годных пакетов до овер 50%
P
Пчёлы улетели :) И фиг с ними...
главное, чтобы мёд был правильным)
A
@Bahoo08 вот что еще вспомнил: нужна была длинная линия: ниче длиннее 305м бухты говеной витой пары, сложенной бухтой (индуктивность!) не нашлось. уж не вспомню, какие там были приемо-передатчки и была ли гальва - но никаких мер типа терминаторов и пр. на концах не применялось, но факт фактом: корректно проходило лишь несколько % пакетов (скорость 9600, RS-422). Ну, лишь задержки возросли. Связь возможна, работа выполнена. Интересно, что простое разматывание бухты в линию увеличило долю годных пакетов до овер 50%
"продажная девка - индуктивность" :D
jp
0xAA55 (или что-то похожее) в качестве заголовка ставь, а в конце пакета фиксированного размера контрольную сумму. )
Ну контрольную сумму я решил не считать, не так важно пока это кмк, поскольку это просто для мониторинга процессом. Вроде пока уверенно себя ведёт. Просто создал со стороны приёмника очередь, в неё добавляю данные, потом оттуда с некой частотой парсю данные в нужном мне формате
jp
@Bahoo08 вот что еще вспомнил: нужна была длинная линия: ниче длиннее 305м бухты говеной витой пары, сложенной бухтой (индуктивность!) не нашлось. уж не вспомню, какие там были приемо-передатчки и была ли гальва - но никаких мер типа терминаторов и пр. на концах не применялось, но факт фактом: корректно проходило лишь несколько % пакетов (скорость 9600, RS-422). Ну, лишь задержки возросли. Связь возможна, работа выполнена. Интересно, что простое разматывание бухты в линию увеличило долю годных пакетов до овер 50%
Так я так и не понял, как влияет изменение первых двух байт от содержания. Как ты определял, что вот тут те самые данные должны появиться. Эти значения у тебя получаются исходя из n+2 байт
P
собирающие редкоземельное с развалов вторсырья и откладывающие танталовые кондеры в сотах... збс!
s
уу
P
сегодня прошелся по закромам родины, чем-то зелененькие приглянулись на память. раньше именно таких не видел. прецезионные, термостабильные, ромбик)
P
Кстати, вот второй протокол чик, вроде мне зайдёт в один проект, завтра буду курить, но по переписке похоже на нужную вещь.
Я не совсем понял зачем твоё шаманство нужно с изменением первых 2х байт посылки и как это прокуривает приёмник?
Я не совсем понял зачем твоё шаманство нужно с изменением первых 2х байт посылки и как это прокуривает приёмник?
я юзаю один уникальный символ как стартовый + синхронизирующий. до того обсуждения юзал 0xFF (все единицы, потом гарантированно один стоповый бит вставляется аппаратно - есть за что зацепиться). сейчас понял, что нужно его изменить на биточередующийся, например 0xAA - будет надежней. Но не суть.
Идея в том, что стартовый байт - уникальный, в теле пакета встретиться не имеет права. А как это обеспечить, если бинарные данные? А тогда вводим еще один, другой, служебный символ. Если в теле пакета встретился совпадач со стартовым, то он заменяется на пару служебный + любой другой. Если встретился совпадающий со служебным - то шлется два служебных. Примерно как сделано форматирование с обработке строк в си: '\0' = 0x00, '\\' = \
Идея в том, что стартовый байт - уникальный, в теле пакета встретиться не имеет права. А как это обеспечить, если бинарные данные? А тогда вводим еще один, другой, служебный символ. Если в теле пакета встретился совпадач со стартовым, то он заменяется на пару служебный + любой другой. Если встретился совпадающий со служебным - то шлется два служебных. Примерно как сделано форматирование с обработке строк в си: '\0' = 0x00, '\\' = \
P
Как я понял, ты мониторишь то, какие байты встречаются. Получается приёмник на ходу проверяет посылки, и по сообщениям определяет какие стартовые байты и тут мне видится проблема. Если ты получил 100 сообщений, например, то как понять где начало сообщения если у тебя стартовые байты меняются
стартовый байт всегда один и тот же.
конечно, на любителя, но разбор буфера из 100 сообщений - это не ко мне. Это пусть всякие сетевики и TCP/IP'шники занимаются. У меня все просто: обработка в прерывании (конечный автомат на switch/case - проц. времени занимает чуть) - принят стартовый - ок, пишем в буфер весь хвост, попутно вырезая службеный символ (выше описал, зачем они вставлены) и восстанавливая пакет. Отсчитали фиксированную длину - значит, следующие два байтика будет CRC. Приняли, проверили - если ОК, функция обратного вызова - кому нужен пакет ее нам дает - она себе скопировала пакетик (прерывания уже разрешены), а пока пишем во второй буфер. И так и чередуем ровно два буфера длиной в пакет каждый. Все.
конечно, на любителя, но разбор буфера из 100 сообщений - это не ко мне. Это пусть всякие сетевики и TCP/IP'шники занимаются. У меня все просто: обработка в прерывании (конечный автомат на switch/case - проц. времени занимает чуть) - принят стартовый - ок, пишем в буфер весь хвост, попутно вырезая службеный символ (выше описал, зачем они вставлены) и восстанавливая пакет. Отсчитали фиксированную длину - значит, следующие два байтика будет CRC. Приняли, проверили - если ОК, функция обратного вызова - кому нужен пакет ее нам дает - она себе скопировала пакетик (прерывания уже разрешены), а пока пишем во второй буфер. И так и чередуем ровно два буфера длиной в пакет каждый. Все.