Jump to content

    

Sergey_Aleksandrovi4

Свой
  • Content Count

    185
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Sergey_Aleksandrovi4

  • Rank
    Частый гость
  • Birthday 11/17/1985

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

3125 profile views
  1. При переходе на новый движок поменялся формат url-адресов (я в вебе не силён, могу использовать неверные термины). Осталась куча ссылок в старом формате на темы как на сторонних ресурсах, так и банально в комментариях к коду. Вот, как пример: http://electronix.ru/forum/lofiversion/index.php/t36933.html https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=36933 При переходе по старой ссылке я попадаю на главную страницу форума. Приходится вручную копировать ID топика и подставлять его в адрес нового формата. Нельзя ли как-то настроить редирект , трансляцию старых url в новые?
  2. Отдельная терминальная программа RTT-Viewer где-то в директории с софтом от Segger (JLink и пр.)
  3. Вы оказались правы, никакой порчи переменной не было. Суточный прогон с отключенными прерываниями это подтвердил. Я неверно истолковал свои отладочные данные. DMA всему виной, но пока не понял где и почему он "погибает". Спасибо всем вам за содействие, дальше я сам. А то сильно ушли от изначальной темы с SREG. Удачи, поменьше багов в коде ;)
  4. Мне кажется, что на таких объёмах данных (400 кБайт) 32-битная контрольная сумма со слабым алгоритмом лишена смысла. Банальный счётчик элементов массива будет где-то рядом по надёжности.
  5. NStorm, аргумент в функция передаётся по значению: явно задано число. Т.е. две команды LDI и следом сразу вызов этой функции. Baser, нет переменной в map-файле. Она фактически существует только на регистрах во время работы функции, ОЗУ под неё не выделяется. Там вообще всё настолько примитивно, что даже смешно. Либо заблудился в 3-х соснах (что в последнее время частенько), либо на какую-то аппаратную аномалию наткнулся. В общем поставил запрет прерываний на функцию целиком и запустил тест.
  6. Помню в IAR подобный атрибут тоже был. Много лет назад тему здесь даже создавал с вопросом, когда в прерывании SPI из-за пролога не успевал предварительно подготовленную порцию данных загрузить. Переменная передаётся в качестве аргумента функции (хм, можно ли называть её "локальной"). Объявлена как uint16_t cnt_16_bit. В ассемблерном коде представлена регистровой парой R22:R23.
  7. Всё намного сложнее: та 16-битная переменная локальная, ни в прерываниях, ни где-либо ещё она не используется. А прописные истины с атомарностью доступа к переменным разрядностью выше нативной я знаю, не первый год на кнопки жму :) В любом случае спасибо Вам за советы. По теме. Проверил все 10 обработчиков прерываний в своём проекте, каждый из них сохраняет содержимое SREG в прологе.
  8. zombi, Вы тут троллингом решили заняться? Понятия не имею что вызвало дефект пайки на этой фотографии. Я её привёл исключительно для того чтобы показать: 1) дефекты подобного рода имеют место быть 2) подобные дефекты обнаруживаются только с применением рентгенологического оборудования 3) осуществляя подобный ремонт ПП на глаз и на коленке надо быть готовым к возникновению чего-то подобного. Тема, на мой взгляд, исчерпана. На Ваш изначальный вопрос "чем опасна установка..." я и другие пользователи дали ответ. Вам остаётся лишь принять решение: допустимо или нет прибегать к такому виду ремонта в Ваших устройствах. Нравятся эти "будульки", готовы работать с рекламациями - паяйте, отговаривать не буду.
  9. Отличаются объёмом припоя. А, возможно, ничем не отличаются. Без рентгена Вам это никто не скажет наверняка (уж точно не я). Человеческий глаз - не самый точный измерительный инструмент. Картинка из интернета.
  10. Спасибо, что ткнули носом, действительно, компилятор следит за сохранением SREG (поэтому мой стрессовый тест и не усугубил проблему). Искал в ассемблерном листинге мнемонику "SREG", а там "голый" адрес регистра 0x003F... ISR(TCE0_OVF_vect) { asm("nop"); // <--- Set breakpoint here TEST_PIN_HIGH(); SREG = 0xFF & ~CPU_I_bp; TEST_PIN_LOW(); } "Эффект утёнка", пока не спросишь, не увидишь очевидной вещи. Сейчас все остальные (штатные) обработчики проверю. На всякий случай. Неделю с этой бедой воюю, не знаю на что ещё грешить.
  11. Шарики для реболлинга всегда калиброванные что обеспечивает равномерный объём припоя на контактных площадках. Ваши "бурульки" только с виду выглядят одинаковыми. После пайки Вы получите что-то подобное Либо большой объём припоя приведёт к распуханию и слипанию смежных шариков. Явное КЗ Вы ещё в состоянии проверить, а вот утечки (если сопротивление такого контакта 1-10 МОм) - вряд ли. Малый объём припоя приведёт к образованию в тонкого "мостика" вместо полноценного шарика. Как он поведёт себя при термоциклировании и вибрациях - никто Вам здесь не скажет. Так что поддержу ранее высказавшихся: для ремонта личных домашних устройств - подойдёт. Для коммерческого использования к тому же, упаси случай, в ответственных узлах - нет
  12. Добрый день. С AVR в последний раз работал 8 лет назад, успел всё позабыть. Надеюсь на форуме остались инженеры кто с этими процессорами работает. Проблема: В проекте в цикле используется 16-битный счётчик значения которого периодически портятся. Ошибка "плавающая", может вылезти через день-два непрерывного прогона. Пока грешу на прерывания. while (cnt_16_bit > 1) { //...do something... cnt_16_bit--; } 334: cnt_16_bit--; 0000AE87 SUBI R22,0x01 Subtract immediate 0000AE88 SBC R23,R1 Subtract with carry 326: while (cnt_16_bit > 1) 0000AE89 CPI R22,0x01 Compare with immediate 0000AE8A CPC R23,R1 Compare with carry Т.е. если прерывание возникнет между двух команд работы с 16-битной переменной и повлияет на флаг C, результат операции окажется неверным. Посмотрел ассемблерный листинг, AtmelStudio (GCC) в прологе/эпилоге обработчика прерывания не сохраняет SREG. При этом процессор сам не умеет на аппаратном уровне этого делать, данная процедура отдана на откуп программисту. Посмотрел свои старые исходники 8-10 летней давности. Проекты на ассемблере: в прологе-эпилоге обработчика прерывания всегда явно сохраняется SREG. Посмотрел проекты на Си в IAR, там явного сохранения SREG нет, но вроде бы помню, что IAR в прологе/эпилоге делал сохранение регистра. Вопросы: 1. К тем, кто пользуется IAR, посмотрите пожалуйста, сохраняется или нет SREG в прерываниях? 2. К тем, кто пользуется GCC. Есть какой-то общий шаблон для написания обработчиков прерываний? Может ключевые слова какие, настройки компилятора и т.п. Или пишете вручную flag_t sreg = SREG; //.... SREG = sreg; 2.1. Или все операции с переменными разрядностью больше нативной 8 бит оборачиваете в критические секции PS Возможно и не в этом дело. Попытался обострил проблему, включил таймер с интервалом 1 мкс и в прерывании (наивысший приоритет в XMEGA) вручную порчу SREG = 0xFF & ~CPU_I_bp; однако на частоту ошибки это не повлияло.
  13. У Вас во время экспериментов ST-Link к проблемной плате подключен? У меня, помню, подключенный по SWD отладчик очень сильно искажал реальную картину потребления устройством тока.
  14. LFN буфер задан статически на этапе компиляции #define FF_USE_LFN 1 Попробовал с опциями 2 (буфер на стеке) и 3 (буфер в куче) - аналогичное поведение. UPD попробовал дебагером посмотреть, что внутри f_stat() происходит. Функция follow_path() генерирует строку с усечённым именем. Дальше не разобрался, слишком там накручено, квалификации не хватает)
  15. Приветствую, форумчане. Ковыряюсь с библиотекой FatFs от ChaN'а. Есть набор файлов в директории диска. Получаю их список с помощью f_readdir(), кэширую в ОЗУ имена короткого (DOS) формата SFN. Контроллер с короткими именами и работает в дальнейшем, здесь проблем нет. Но для вывода на экран GUI нужно длинное имя LFN. Пытаюсь получить его используя функцию f_stat(), но обе строки в структуре FILINFO вопреки ожиданиям содержат короткие SFN имена. Код: FRESULT res; FILINFO file_info; printf("Open <Long filename 1.txt> "); res = f_stat("Dir1/Long filename 1.txt", &file_info); if (res == FR_OK) printf("OK"); else printf("Error!"); printf(".altname==%s", file_info.altname); printf(".fname==%s", file_info.fname); printf("Open <LONGFI~1.TXT> "); res = f_stat("Dir1/LONGFI~1.TXT", &file_info); if (res == FR_OK) printf("OK"); else printf("Error!"); printf(".altname==%s", file_info.altname); printf(".fname==%s", file_info.fname); Вывод: Использую последнюю (ff14) версию библиотеки. Пока придумал лишь одно решение "в лоб": всякий раз при необходимости получить LFN последовательно брать каждый элемент директории с помощью f_readdir() и сравнивать строки исходного SFN и поля FILINFO.altname. При числе файлов 100+ это будет чертовски долго. Два вопроса: 1. Как всё-таки получить LFN строку имея в наличии SFN. 2. Мой подход к сортировке файлов концептуально верен или перемудрил?