кстати здесь как раз используется пиковская косвенная адресация

т.е. с помощью этого блока можем смело работать с регистрами пика как с линейным массивом

просто пришлось большую дату загонять и как то выкручиваться из положения

как ты думаешь для чего мне это было нужно?

Не знаю. И не хочу знать. Мне все равно

Поздравляю, вы только что проипали почти 10мксек)))
На 16 пике вам не реализовать 3 уарта, господин Котельников не позволит😆
Чтобы держать трафик, нужно в пределах периода появляться раз 10. Даже если задать счетчик в прерывании на 10мксек, вы неизбежно много просидите в обработчике. Один уарт на этих пиках можно аппаратно поднять, но вам это не поможет, мы же надеюсь не верим в синхронный прием?)
Вам нужно чуть больше времени на слово в программе или дма.

а я все же скажу:
задача была такая: нужно было перехватить UDPдатаграмму по пути из компа в модем
датаграмма шла в сыром PPP пакете

задачы была простой- подменить UDP порт адресата

но влекла за собой пересчет контрольной суммы в заголовке пакета и crc16 в конце пакета

кроме того в самой дтаграме были т..н. эскейп сиквесы - это замена одного байта - двумя

нахер оно там там было задумано я не знаю

видимо флаги 7E не должны были повторяться

это был кадр пакета

размер самой датаграмы был порядка 130 байт

так вот
мой пик принимал датаграму из рукотворного софт уарта на скорости 115200
сжимал ее - т.е. выкидывал эскейпы - пересчитывал их в нормальные байты
затем заменял порт назначения UDP пересчитывал контролную сумму заголовка датаграммы, снова расширял ее по эскейпу и считал crc 32 в конце пакета

потом отправлял во второй софт-уарт - в модем

по получению ответа из модема все производилось в обратной последовательности за исключением того, что порт адресата теперь заменялся на реальный порт приемника

иначе комп отверг бы такую левую датаграму

у него все ж свой планировщик пакетов

получился некий мост