Можно подробнее, а если еще и примерчик что вабще гуд.

Да, 01 участвует.

Вообще, алгоритм-то универсальный, любые дивайсы, любое кво байтов катят.

да ни каких особо ухищрений не нужно просто определяешь область озу в тиньке
если 2313 то там 128 байт всего
для 1820 нужно (процесс чтения после конвертации - в смысле когда температуа измерилась)
в такой последовательности ты их (байты)будешь получать от 1820
первым идет:
(1 байт температура младший байт)
2- температура старший байт
3- юзерский байт 1
4- юзерский байт 2
5 байт конфигурации
6- не используется
7- не используется
8 - не используется
9 - контрольная сумма (ради чего весь сыр бор)
- 9й можешь не писать в буфер тогда буфер будет 8 байт всего
но по началу лучше пиши
;---------
вообщем берешь каждый считанный байт и кидаешь его в буфер
буфер определяешь нну например от начала памяти (начало у тиньки есть адрес $60)
поэтому буфер будет от $60... $68 - всего 9 байт (вместе с контр суммой)
все это хозяйство а имеено начало буфера
LDI XL,low($0060)
LDI XH,high($0060) ; определяешь начало буфера
и 8 байт всего
кстати для тини старший байт не используется(т.к 128 байт всего) поэтому LDI r16,high(xxxx) можно
неписать после прогона процедуры в темп 5 получается контр сумма
она должна быть равна 9 байту буфера если равна то все ок можно сказать что чтение с 1820 произошло успешно если не ровна то извините....

Вот еще один вариант реализации на языке С.
Характерная особенность-подсчитывает частичную контрольную сумму--т.е. с приходом каждого байта обновляется контрольная сумма. Переведено на С из контрольного примера в даташите на языке ассемблера Z80. Почему частичная--так удобнее, получил байт -- обновил контрольную сумму. Общая метода такова--перед началом приема информационного пакета контрольная сумма обнуляется. Потом принимаются все байты информационного пакета, включая контрольную сумму, каждый байт проходит через данную подпрограмму, обновляя контрольную сумму. Если пакет принят без ошибок, то вычисленная контрольная сумма равна нулю.

#define POLY8 (0x8c) //x^8+x^5+x^4+x^0 position bits are mirrored
// because register is shifted right


unsigned char partdowcrc(unsigned int oldcrc,unsigned char val)
{
register char i;
oldcrc ^= val;
for(i=0;i<8;i++)
{
if((oldcrc &1 )!=0)oldcrc ^= (POLY8 << 1);
oldcrc >>=1;
}
return oldcrc;
}

Kovrov

Разве неправильно я расписал для 1990? При правильности считывания в LoCRC разве не должны быть нули?

;*******************************************************************************

; Вычисление CRC (Х8+X5+X4+1) блока памяти
; в XH:XL надо загрузить начальный адрес блока памяти
; в count количество байт
;
; Данныее должны находится в блоке памяти в следующем порядке:
; начальный адрес памяти - Family Code
; следующие шесть - HEX чисела в обратном порядке, написанному на ключе
; последний адрес - СRС
;
; В результате успешных действий в регистре LoCRC должны находится нули
;*******************************************************************************

че уже считаем для 1990? недавно тока температуру читали ;-)
нет нулей быть не должно за исключением если сумма равна нулю...
кстати мне попадался экземпляр 1990 у которого реально крк = 00!
можешь выложить суда содержимое буфера
кстати для 1990 ( а если точнее результат команды "read rom"$33 - это 7байт +crc

Сообщение отредактировал Kovrov - Feb 3 2006, 10:43

01 1E 06 CA 0C 00 00 70

Это конкретный ключ, проверил еще пяток, нули в LoCRC

01 код семейства, лежит в $60, остальное по порядку.
70 - CRC

Сообщение отредактировал Pyku_He_oTTyda - Feb 3 2006, 11:40

только что прогнал через приведенную процедуру все совпало в смысле контро сумма = $70.

посмотрел на твой исходник
ты в твоем случае 8ой байт (крк) подставляешь в процедуру проверки и естественно если сумма совпала то
LOCRC = 0
только зачем лишний цикл?
проще поставить в count=7 а после сравнить $70и $70.
Твой вариант тоже верен.
а в чем проблема то? :-)

Проблемы нет, просто хотелось уточнить все до конца. Тем более Ваш пример мне очень помог! Большое спасибо!

А как вручную посчитать crc для этого ключа?

И вопрос в догонку:
Если на шине присутствует подчиненный, то он должен в течение 60 мкс после освобождения ведущим шины установить низкий уровень длительностью не менее 60 мкс.

Как правильнее поступить:
1. Отследить наличие установки низкого уровня, по истечении 60мкс после освобождения линии ведущим?
2.Отследить не только наличие низкого уровня, но и измерить его длительнось?

По мне более правильным кажется второй вариант, но к примеру в AVR318 алгоритм такой:
Установка "0" мастером на 480мкс - освобождение шины - ждем 70мкс - чтение шины - ждем 410мкс - работаем дальше.
Вот как раз момент "чтение шины" не очень понятен, если не измерять длительность ответа, разве помехоустойчивость на высоте будет? Или с этим мирится и всю надежду возлажить на последующее чтение номера и подсчет CRC?

Можно "читать шину" несколько раз(как в UARTе) в интервале ответа (60-240мкс) набирая статистику, обеспечивая тем самым высокий процент достоверности. Окно (имп.сбр+ожид60мкс+240мкс ответ)правда всеравно придется выдерживать.

конечно! берешь таймер с тиком например мкс и зекаешь когда мастер сброс даст
сразу онулируешь тимер и следишь пока не кончиться ресет мастера
как кончился - смотришь че тамер на мерил если укладываешься в рамки то ок...
а вообще очень красиво и экономно засунуть его под EXT int и работать с его прерыванием
я так и делал очень приличная экономия!!
на счет 60 мкс - я не понял - речь идет о presence pulse?

да, подчиненный должен ответить, что он на линии, низким уровнем не менее 60мкс

можно принцип немного подробнее?

Presence pulsе делай по максимуму возможному а то у меня домофоны плохо открывались ;-)
насчет Ext int
заводишь это хохяйство на ногу внешнего прерывания
и настраиваешь прерывание на перепад 1-0
а пока ждешь прерывание контроллер переводишь в слип (холостой ход)
тоже самое делаешь когда принимаешь данные

Сообщение отредактировал Kovrov - Feb 8 2006, 10:03