И то и другое, но ни то ни другое не звучит так же оскорбительно, как "хуй" в русском.
К тому же оба эти слова контексте могут означать и не "член". Допустим, "dick" может звучать как сокращение от имени Richard (очевидная мишень для тупых шуток); cock может означать петуха (или самца птицы вообще), затвор.
В британском вполне допустимо сказать человеку "you are a cock", имея в виду не "ты хуй", а "ты понторез"; это вполне себе по ВВС говорят без запикиваний.
"Being a dick" — это, скорее, "быть мудаком", но тоже умеренно-допустимо.
Но опять же, в контексте, скажем, полового акта, оба эти слова будут означать "половой член".
Если же вы ищете какое-нибудь иносказание, то в британском можно воспользоваться целым набором слов — "prick", "bell end", "pork sword", "meat rocket" и т.д.
Можно и на лету эскапировать и не потребуется двойной буфер, если уж память жалко.
Чтобы эскапировать на лету, придется руками каждый байт перекладывать в UART, не получится ни выделить работу с UART'ом в отдельный модуль, ни использовать DMA, например.
Вы читали мой код, в частности функцию tx_cb? Всё кодирование при отправке реализуется средствами конечного автомата, при этом его алгоритм проще некуда. Так-же и при приеме. В буфере лежат только полезные данные.
Окей, тут согласен, сплоховал. Эта проблема была лично у меня, потому что я вынужден был пользоваться существующим интерфейсом для доступа к UART'у, который принимал массив и размер (т.е. массив должен быть эскапирован).
Сложность в объеме и скорости выполнения кода. На стороне ПК это рабочий вариант, но не в МК.
Как вы поняли, что для МК это не рабочий вариант?
Мы ведь с вами говорим про Cortex-M, а не про PIC восьмибитный; тут и памяти вполне достаточно и скорости.
Мой опыт показывает у кортекса вполне хватит сил сделать еще пару циклов, а разницу в сотни микросекунд вы вряд ли заметите. Я ведь такой подход предлагаю не из теоретических соображений, а потому что сам им вполне успешно пользуюсь.
А уж STM32F7 тактовые за 200 МГц! Это ж почти Пентиум 2 :)
С эскейп-кодированием нужно эскейп кодирование и контрольная сумма тоже! А так — только контрольная сумма.
Код проще? Спорный вопрос.
Для эскейп-кодирования отправляемого сообщения мне в худшем случае нужен буфер удвоенного размера, ведь я заранее не знаю, сколько байт нужно будет эскапировать.
Так — только фиксированный запас на CRC.
Да и в чем сложность? Crc не сошлось — цикл для поиска старта, сдвиг массива (один вызов std::rotate), запускаем основной автомат набора пакета.
Это патологический случай. Если он возможен и вероятен, то нужно стартовую последовательность выбирать другую.
При эскейп-кодировании тоже не сахар будет, ведь такой пакет раздуется в полтора раза, а это увеличит вероятность некорректной передачи...
Про ограничить размер пакета, что вы имели ввиду?
Это и имел — сказать, что пакеты могут быть не более Х байт.
Лично мое мнение: эскейп-кодирование — это устаревшая, неудобная и ненужная штука. Огромное количество протоколов (в т.ч. Ethernet и TCP) живет без него и отлично себя чувствует.
в середине данных найден фиктивный start, size, пошло накопление пакета
пакет набран по фиктивному размеру, crc не сошлось.
в уже набранном наборе байт ищется следующий start — он настоящий, синхронизация восстановлена
Т.е. если crc не сходится, не нужно выбрасывать все накопленное.
Конечно, если пакеты могут быть очень длинными и в них очень часто встречается фиктивный стартовый байт, то это может затянуться. В таком случае можно сделать несколько стартовых байт или ограничить размер пакета.
Но, как и в прошлый раз, позволю себе немного поворчать:
0хАА 0xFF — Start of frame
0xAA 0x00 — End of frame
0xAA 0xA5 — Interrupt
0xAA 0xAA — Заменяется на 0xAA
На мой взгляд, протокол странный. Никакого контроля ошибок, зато есть escape-кодирование.
Может быть, хотя бы чексумму добавить?
А если использовать CRC, то можно и без escape-кодирования обойтись...
типичные структуры данных, которые хранятся в куче — это глобальные переменные
А я думал, что глобальные переменные выделяются в статической области… Или это только в С/С++ так?
Вообще немного странно называть глобальные переменные "структурами данных".
Зачем armcc, когда его поддержка прекращена в пользу armclang? :)
А, пардон. Боюсь, что с этим не помогу.
Может быть, баг в компиляторе.
Это вы намекаете, что я тупанул, отвечая так подробно? :)
Как насчет слова "minger"? Оно более или менее оскоробительно, чем munter?
И то и другое, но ни то ни другое не звучит так же оскорбительно, как "хуй" в русском.
К тому же оба эти слова контексте могут означать и не "член". Допустим, "dick" может звучать как сокращение от имени Richard (очевидная мишень для тупых шуток); cock может означать петуха (или самца птицы вообще), затвор.
В британском вполне допустимо сказать человеку "you are a cock", имея в виду не "ты хуй", а "ты понторез"; это вполне себе по ВВС говорят без запикиваний.
"Being a dick" — это, скорее, "быть мудаком", но тоже умеренно-допустимо.
Но опять же, в контексте, скажем, полового акта, оба эти слова будут означать "половой член".
Если же вы ищете какое-нибудь иносказание, то в британском можно воспользоваться целым набором слов — "prick", "bell end", "pork sword", "meat rocket" и т.д.
Вообще, это целая тема для исследования :)
https://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at-everything.html
Это довод.
Чтобы эскапировать на лету, придется руками каждый байт перекладывать в UART, не получится ни выделить работу с UART'ом в отдельный модуль, ни использовать DMA, например.
Можно, конечно, но не очень удобно.
Окей, тут согласен, сплоховал. Эта проблема была лично у меня, потому что я вынужден был пользоваться существующим интерфейсом для доступа к UART'у, который принимал массив и размер (т.е. массив должен быть эскапирован).
Как вы поняли, что для МК это не рабочий вариант?
Мы ведь с вами говорим про Cortex-M, а не про PIC восьмибитный; тут и памяти вполне достаточно и скорости.
Мой опыт показывает у кортекса вполне хватит сил сделать еще пару циклов, а разницу в сотни микросекунд вы вряд ли заметите. Я ведь такой подход предлагаю не из теоретических соображений, а потому что сам им вполне успешно пользуюсь.
А уж STM32F7 тактовые за 200 МГц! Это ж почти Пентиум 2 :)
С эскейп-кодированием нужно эскейп кодирование и контрольная сумма тоже! А так — только контрольная сумма.
Код проще? Спорный вопрос.
Для эскейп-кодирования отправляемого сообщения мне в худшем случае нужен буфер удвоенного размера, ведь я заранее не знаю, сколько байт нужно будет эскапировать.
Так — только фиксированный запас на CRC.
Да и в чем сложность? Crc не сошлось — цикл для поиска старта, сдвиг массива (один вызов std::rotate), запускаем основной автомат набора пакета.
Это патологический случай. Если он возможен и вероятен, то нужно стартовую последовательность выбирать другую.
При эскейп-кодировании тоже не сахар будет, ведь такой пакет раздуется в полтора раза, а это увеличит вероятность некорректной передачи...
Это и имел — сказать, что пакеты могут быть не более Х байт.
Лично мое мнение: эскейп-кодирование — это устаревшая, неудобная и ненужная штука. Огромное количество протоколов (в т.ч. Ethernet и TCP) живет без него и отлично себя чувствует.
Если сделать правильно, то будет так:
Т.е. если crc не сходится, не нужно выбрасывать все накопленное.
Конечно, если пакеты могут быть очень длинными и в них очень часто встречается фиктивный стартовый байт, то это может затянуться. В таком случае можно сделать несколько стартовых байт или ограничить размер пакета.
UPD: Вроде как это называется https://en.wikipedia.org/wiki/CRC-based_framing
А вот это круто! Спасибо!
На мой взгляд, протокол странный. Никакого контроля ошибок, зато есть escape-кодирование.
Может быть, хотя бы чексумму добавить?
А если использовать CRC, то можно и без escape-кодирования обойтись...
В каком-то смысле — да, наверное. Но это уже вопрос не языка программирования, а ОСи, которой может и не быть в общем случае.
Странно. Я подозреваю, что автор привык к ссылочным типам, для которых сам объект всегда в куче создается — даже если ссылка глобальная.
Только стандарт С не оговаривает, где выделяются VLA; некоторые компиляторы просто подставляют вызовы malloc и free в соответствующие места.
А я думал, что глобальные переменные выделяются в статической области… Или это только в С/С++ так?
Вообще немного странно называть глобальные переменные "структурами данных".
Понятно, спасибо.
А почему псевдонимы не используете?