Лидеры

Ловите: //Расчёт CRC32 полином == 0xEDB88320 //buf - данные, len - длина, crc - init value u32 CRC32(void const *buf, int len, u32 crc) { static u32 const t[] = { 0x00000000, 0x77073096, 0xEE0E612C, 0x990951BA, 0x076DC419, 0x706AF48F, 0xE963A535, 0x9E6495A3, 0x0EDB8832, 0x79DCB8A4, 0xE0D5E91E, 0x97D2D988, 0x09B64C2B, 0x7EB17CBD, 0xE7B82D07, 0x90BF1D91, 0x00000000, 0x1DB71064, 0x3B6E20C8, 0x26D930AC, 0x76DC4190, 0x6B6B51F4, 0x4DB26158, 0x5005713C, 0xEDB88320, 0xF00F9344, 0xD6D6A3E8, 0xCB61B38C, 0x9B64C2B0, 0x86D3D2D4, 0xA00AE278, 0xBDBDF21C}; u8 const *p = (u8 const *)buf; while (--len >= 0) { u32 c = crc ^ *p++; crc = t[c & 15] ^ t[(c >> 4 & 15) + 16] ^ crc >> 8; } return crc; } Здесь расчёт потетрадный, соответственно - таблица намного короче. С IAR-ом спаривается так: Полином - тот же самый, что у Вас, просто повернутый битами в обратную сторону. Чтобы работала ваша функция, наверное нужно в настройках (выше) порядок бит/байт поменять. Но (имхо) - потетрадная таблица лучше. if (~CRC32(__checksum_begin, __checksum_end - __checksum_begin + 1, 0xDEBB20E3) != __checksum) trap(TRAP_PRG_IMAGE); где: содержимое __checksum генерит IAR_ARM_7.80.4 самостоятельно.

CRC это изначально потоковая побитная функция. И вычисляется она именно на потоке битов. У вас же (равно как и у всех) поток не битов, а слов (по 32 бита). Тут возникает вопрос - как битовый поток наложить на поток слов. С нарезкой групп по 32 бита вопросов не возникает, а вот внутри есть разночтения. Можно биты вдвигать с LSB в MSB, а можно с другой стороны. Оба варианта используются, и это как раз ваш случай - певый код двигает с MSB к LSB, второй в другую сторону. Отличаются они направлением сдвига в цикле вычисления (как для варианта с одним битом, так и с байтом). Полиномы для них очевидно совпадают с точностью до побитового разворота, равно как и результаты, которые они вычисляют - так же побитово развёрнуты. Превратить версию LSB в MSB простым изменение полинома нельзя - нужно изменить направление сдвига внутри цикла вычисления

Нет. Я не в начале, а уже в самом конце своей профессиональной карьеры. Мне о деньгах думать незачем, потому что больше чем есть уже не будет.

Сисадминов полно потому, что это должность, а не профессия. То есть, сисадмином может работать вообще кто угодно, если его на эту должность возьмут.

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

Коллеги, всем большое искреннее спасибо! Не ожидал такой поддержки в этом для меня непонятном вопросе! @jcxz, Вам отдельное спасибище)))) За подробные скриншоты с настройками!!!

Код, который привел я в полный рост используется при рассчете CRC ZIP-файлов. Он рабочий. Рассчет CRC и таблица совпадают с тем, что нужно вам, соответственно рассчет таблицы тоже совпадает. Таблица у меня считается по полиному 0xEDB88320. 0xEDB88320 - это инвертированный полином 0x04C11DB7. Т.ч. вашему IARу подойдет или полином 0x04C11DB7 (если он сам умеет его инвертировать), или 0xEDB88320 (если не умеет). Код из первого поста и тот, что привел я - это полином 0x04C11DB7, преобразованный в 0xEDB88320, и, соответственно, рассчет CRC адаптирован под это преобразование. Тот код, где сдвиги не в ту сторону - это полином 0x04C11DB7, преобразованный в 0x82608EDB, и, соответственно, рассчет CRC адаптирован под это преобразование. В преобразованиях полиномов я не разбираюсь, поэтому подробнее не расскажу.

Белорусские металлофольговые ДН-ХХ, производства "Аякс". И микропроволочные НРМП-ХХ Не рассматривали?

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

схема на картинке. подробных схем на такую технику в открытом доступе не существует