ffs2001

Первый вопрос решил так: uint8_t i; uint8_t addr[11] ={0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x10,0x12,0x13,0x14,0x15}; for (i=0; i<11; i++){ NVM_CMD = NVM_CMD_NO_OPERATION_gc; SP_WaitForSPM(); NVM_CMD = NVM_CMD_READ_CALIB_ROW_gc; //int2hexstr(SP_ReadCalibrationByte(addr[i]),guid,i*2); int2hexstr(pgm_read_byte(addr[i]),guid,i*2); NVM_CMD = NVM_CMD_NO_OPERATION_gc; } т.е. заменил код из Атмелевского SP_driver.s на Студиевский из avr/pgmspace.h . Буду благодарен, если кто-то подскажет, в чём принципиальная разница. Хм. Второй глюк тоже ушёл. В CVAVR я использовал не SP_driver.s целиком, а копировал частично код, оформляя в виде функций с ассемблерными вставками. Видимо, где-то накосячил с регистром ожидания. Нефиговые ошибки, однако, прощает компилятор CVAVR.

Коллеги, может, кто сталкивался, перевожу проект из CVAVR в Atmel Studio 7. Код проверенный и 100% рабочий. В Studio заработало, но с нюансами: код, нормально выполняющийся в CVAVR: (читаем уникальный код Атмеги, SP-драйвер родной Атмелевский) uint8_t i; uint8_t addr[11] ={0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x10,0x12,0x13,0x14,0x15}; for (i=0; i<11; i++){ SP_WaitForSPM(); int2hexstr(SP_ReadCalibrationByte(addr[i]),guid,i*2); } код, работающий в Studio uint8_t i; uint8_t addr[11] ={0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x10,0x12,0x13,0x14,0x15}; [b]_delay_ms(2);[/b] for (i=0; i<11; i++){ SP_WaitForSPM(); int2hexstr(SP_ReadCalibrationByte(addr[i]),guid,i*2); [b]_delay_ms(2);[/b] } Без делея выдаёт фуфло. На что ему делей? И ещё непонятный момент. Работа начинается с bootloader'а, в некоторый момент происходит jump 0x00. Иногда в application section пусто (так задумано), и контроллер "по нолям" снова приходит в бутлоадер. void jump_to_0(){ CCP = CCP_IOREG_gc; PMIC.CTRL = 0; asm volatile("jmp 0x00"); } После CVAVR всё происходит без проблем, а после Студии – начинает глючить USART, например. Правильно ли я понимаю, что в Студии нужно делать что-то вроде pmic_set_vector_location(PMIC_VEC_APPLICATION) перед jump 0x00 и, соответственно, принудительный перевод векторов на бутлодер в начале бутлодера?

Это да. Только даташыт говорит, что если CENG=2,0 – то будет выведено ТОЛЬКО +CENG:0,"0111,32,99,250,02,02,4f2f,05,05,1e7f,255" и ничего больше. А вот если CENG=2,1 , то полный список.

Ещё раз благодарю. Возник вопрос по мотивам: кто работал с командой AT+CENG ? Мануал по AT-командам (1.11, скачано с офсайта) гласит, что если в конце команды 0 (AT+CENG=2,0), то модуль должен вернуть информацию только об актуальной БС. На деле, всегда возвращает всё, что видит. Это баг или фича?

Господа, будьте добры, киньте на ffs2001 соббака mail.ru последнюю прошивку для SIM900D .

Артём, кстати, а каким эмулятором контроллера пользуетесь?

Действительно, замена этого куска на такой код: CRC.CTRL=0; if (init_zero) { CRC.CTRL |= CRC_RESET_RESET0_gc; } else { CRC.CTRL |= CRC_RESET_RESET1_gc; } CRC.CTRL |= 1<<CRC_CRC32_bp; СRC.CTRL |= CRC_SOURCE_IO_gc; привела к правильному результату вычислений. Артём, спасибо! P.S. Честно говоря, раньше практически не встречал кода, сформированного таким, как в вашей библиотеке, образом. Удивился, когда CVAVR его переварил даже без warning'ов. Видимо, не зря CVAVR ругают.

Проект для CVAVR 3.1 . Скомпилированные ROM и HEX в Debug. CRC_test.zip

Проверил на двух 64ых, результаты разные для hard и soft в обоих случаях. Правильное значение выдаёт soft. Очень странно.

Так будет использоваться тот же самый хардварный генератор. А он выдаёт не то. Совпадение калькулятора и генератора, похоже, было случайным. Совпадают только значения, генерируемые из массива [32] = {0xFF} Делаю вывод, что хардварный генератор нерабочий. Странно, что этого нет в эррате. При возможности проверю на другом контроллере, отпишусь. Ещё интересный нюанс относительно приведённого в сообщении 6 кода: crc = crc & 1 ? (crc >> 1) ^ 0xEDB88320UL : crc >> 1; Visual studio ругнулась тут на невозможность привести int к bool, и я ничтоже сумняшеся привёл код к виду for (j = 0; j < 8; j++) { if ((crc & 1) == 1) { crc = (crc >> 1) ^ 0xedb88320u; } else { crc = (crc >> }; crc_table[i] = crc; тем более что так это реализовано в библиотеке, которую я использовал для PC. Компилятор для Атмеги (работаю в CVAVR) на эту строку не ругнулся. Но если не привести код к тому же виду, результат получается РАЗНЫЙ.

Результаты работы приведённого кода идентичны результатам библиотеки для PC (собственно, и код идентичен). Крайне смущает совпадение результатов из xmega'вского генератора с другим калькулятором. Хочу использовать hardware генератор, т.к. нужно считать CRC app-table из бутлодера. Буду копать дальше.

Благодарю! В общем, CRC-модуль, похоже, рабочий. Теперь (немного в сторону от темы) ситуация получилась такая: модуль xmega и вот этот калькулятор выдают одинаковое значение; библиотека CRC-32 для VS (PC) и вот этот калькулятор тоже выдают одинаковое значение, но другое! Полином везде один и тот же. Видимо, под конец они как-то хитро XOR-ятся или ещё что... Тестовое значение (hex) 940C. Буду очень рад, если кто-нибудь объяснит, как так происходит.

Так, проблема, похоже, не в контроллере. В этом калькуляторе получается то же значение, что выдаёт мой контроллер. Проблема в том, что в него я скопировал полином из этого калькулятора, где получается другое значение (с этим полиномом). Это, как говорится, какое-то фуфло; но бедная иксмега не при чём. Когда разберусь с полиномами, отпишу, в чём соль. Мда, печально. Расскажите подробнее, если не затруднит. Да, уже обрабатывал этот момент; это единственная ошибка в драйвере?

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

Господа, помогите советом: хочу считать CRC-32 на указанном МК. Аппаратный модуль имеется. Код использовал родной атмелевский отсюда и упрощённый вариант: CRC_CTRL |= CRC_CRC32_bm; CRC.CTRL |= CRC_SOURCE_IO_gc; for (n = 0; n < 32; n++){ CRC.DATAIN = test[n]; // send data } CRC.STATUS |= CRC_BUSY_bm; // finish while (CRC_STATUS & CRC_BUSY_bm == CRC_BUSY_bm); itoa(CRC.CHECKSUM3,str); puts_usf0(str); //и так далее Сам модуль работает, но выдаёт неверные данные. Проверял вот этим калькулятором. Полиномы совпадают, в даташите есть описание. В эррате ничего. Тестовый массив: uint8_t[32] = {0xFF} ЧЯДНТ?