ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
28 марта
1279985
Adept (30.01.2023 13:48, просмотров: 9799)
Есть интересная задачка, пока решение видится "в лоб", но оно "на грани фола" :( 

пришлось в проекте ставить иксмегу 64 (их была сотня в загашнике) вместо 128-й, в итоге UART-буфер сократился с 3кило до 500 байт :(

По логике работы программы, буфер нужен для повторных транзакций (если была ошибка обмена). Длина пакета переменная от 20-30 байт до 3 кило, длина отправляемого на сервер пакета указывается в заголовке, т.е. заголовок формировать нужно сразу, а потом (если данных будет много - кеорректировать)

И вот до 500 байт, логика прежняя - заполняем буфер (формируем заголовок, размещаем данные и CRC в конце пакета, передаём его и храним на случай повторных транзакций. А вот если входящий UART вектор длинный (а программа узнает об этом только под конец заполнения буфера), то нужно корректировать байт длины в заголовке (ставить, к примеру длину в 3 кило) начинать передачу того, что накопилось в буфере, попутно сдвигая массив в нём по мере поступления новых данных по UART, в реальном времени, а по окончании поступления данных, добивать пакет до заявленной в заголовке длины, например, нулями, и в конце передавать CRC, подсчитанную "на лету". Повторных транзакций тогда конечно не будет, но однократная передача пройдёт. Как некие "костыли" это приемлемо, но вот на скорости 115200, побайтовый сдвиг массива в 500+ байт на такте 32МГц как раз укладывается в что-то около 10 кб/сек, что примерно соответствует скорости поступления данных по UART на 115200. В общем всё "впритык" :(( Есть риск, что какие-нибудь прерывания (а их дохрена), приведут к тому, что какие-то входящие по UART байты я пропущу :( Может есть какие-то неочевидные финты, чтобы обойти эту проблему ? (DMA не юзал, но как бы вроде оно тут и не поможет) есть у кого-то дельные мысли как это обойти?? (железо менять нельзя, т.е.. буферное ОЗУ не довесить)

...делать нужно так, как нужно. А как ненужно - делать не нужно (С) Винни-Пух :)