| |
 Быстрое вычисление CRC-8, Потенциальные возможности не табличных методов |
|
|
|
|
 Sep 4 2006, 12:33
|
Местный
Группа: Участник
Сообщений: 416
Регистрация: 18-04-06
Из: Челябинск
Пользователь №: 16 219
|
Цитата(aaarrr @ Sep 4 2006, 14:31)  Как это не зависят? Одно дело, когда таблица выровнена по границе 256 байт, и не пересекает следующую: Код ldi ZH, high(table * 2)
mov ZL, offset
lpm
... другое, когда таблица не выровнена по границе 256 байт: Код ldi ZH, high(table * 2)
ldi ZL, low(table * 2)
add ZL, offset
lpm
... и совсем другое, когда не выровнена по границе 256 байт, и пересекает следующую: Код ldi ZH, high(table * 2)
ldi ZL, low(table * 2)
add ZL, offset
brcc PC+0x02
inc ZH
lpm
... Разница по скорости почти в 2 раза: 5 и 8 тактов. "Расход" стека случается только при использовании вложенных подпрограмм. Как правило, программы уровня PIC16 позволяют обойтись минимальным количеством вложений. Если расчитывать на определенное размещение таблицы в памяти, тогда согласен. Но в случае использования линкера, расположение таблицы обычно заранее неизвестно, и расчитывать на это не стоит. Поэтому нужно использовать наиболее общий случай, только я бы сделал код для этого чуточку проще: Код mov ZL, offset ; offset, offset+1 - регистры для смещения (индекса)
mov ZH, offset+1 ;
sbi ZL, -low(table*2) ; Вычислить точку входа в таблицу.
sbci ZH, -high(table*2) ;
lpm R16 ; Выбрать байт Необходимо только 4 такта накладных расходов. Но доступ по индексу требует больше накладных расходов и, соответственно времени. Поэтому при последовательном доступе к элементам таблицы лучше воспользоваться методом доступа по указателю, чего в PIC16 вообще нет: Код ldi ZH, high(table*2) ; Установить указатель таблицы
ldi ZL. low(table*2) ;
............
lpm R16, Z+ ; Выбрать очередной элемент таблицы
|
|
|
|
|
|
|
|
Sep 4 2006, 13:13
|
Местный
Группа: Участник
Сообщений: 416
Регистрация: 18-04-06
Из: Челябинск
Пользователь №: 16 219
|
Цитата(aaarrr @ Sep 4 2006, 16:06) Цитата(_Bill @ Sep 4 2006, 16:33)
Поэтому при последовательном доступе к элементам таблицы лучше воспользоваться методом доступа по указателю, чего в PIC16 вообще нет
Как нет и в AVR времен PIC16  Само собой. Они там (в AVR) немного меньше.
|
|
|
|
|
|
|
|
Jul 1 2013, 13:37
|
Местный
Группа: Участник
Сообщений: 211
Регистрация: 18-03-13
Из: Питер
Пользователь №: 76 081
|
Дяденьки, подскажите, плиз!  Если у меня принимаются байты (по UART, если что), в которых, только семь младших битов информационные, а старший - служебный (определяет начало посылки), то какой алгоритм брать, CRC-8, или CRC-7? Нашёл тут расчёт CRC-7, но там всё-равно "обрабатываются" все восемь битов, а затем старший бит принудительно обнуляется.
|
|
|
|
|
|
|
|
Jul 1 2013, 19:01
|
Гуру
Группа: Свой
Сообщений: 2 076
Регистрация: 10-09-08
Пользователь №: 40 106
|
Цитата(Smen @ Jul 1 2013, 16:37) какой алгоритм брать, CRC-8, или CRC-7? Считайте CRC-8 и не морочьте себе голову. Но учтите что : Цитата(plombir @ Feb 18 2009, 09:11) Назначение CRC это гарантированное обнаружение одинарных, двойных, тройных и нечетных ошибок при максимальной длине блока: 15, 4095, 268435455 байт, соответственно для CRC 8, 16, 32.
|
|
|
|
|
|
|
|
Jul 2 2013, 06:02
|
Местный
Группа: Участник
Сообщений: 211
Регистрация: 18-03-13
Из: Питер
Пользователь №: 76 081
|
Цитата(zombi @ Jul 1 2013, 23:01) Считайте CRC-8 и не морочьте себе голову. Так, а будет ли CRC-8, у которого обрезан старший бит выполнять свои функции? Цитата(zombi @ Jul 1 2013, 23:01) Назначение CRC это гарантированное обнаружение одинарных, двойных, тройных и нечетных ошибок при максимальной длине блока: 15, 4095, 268435455 байт, соответственно для CRC 8, 16, 32. А разве это не от полинома зависит? Я правильно понял, что для CRC-8 максимальная длинна блока 8 байт (что б все ошибки гарантированно обнаруживались)?
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
