Jump to content

    

Sergey_Aleksandrovi4

Свой
  • Content Count

    198
  • Joined

  • Last visited

Everything posted by Sergey_Aleksandrovi4


  1. Владимир, спасибо за консультацию. Шаблон брал от предыдущего разработчика, 19 версия (не точно). Создал чистую плату, добавил компоненты из состава встроенной библиотеки - то же поведение. Все настройки перерыл, чего-то близкого по смыслу к "Check clearance by component boundary" не нашёл. Записал это в разряд "глюков", буду помнить, что в 21 версии добавили настройку.
  2. peshkoff, огромное спасибо. Воспользовался первым способом с назначением горячих клавиш по Ctr+клик. Назначил на незанятые Num0, 1, 4, 7: стало очень удобно по стеку переключаться (радуюсь как ребёнок). Второй способ тоже взял на заметку. Спасибо за помощь. Включил все слои и выяснил, что зазор вычислялся по прямоугольные областям courtyard в Mechanical 15. Сделал тестовый футпринт без лишних элементов: только контактные площадки и 3D модель (она точно подключилась, проверял в 3D просмотре по клавише "3"). Теперь вычисление дистанции идёт по самым крайним точкам (слой Mask). Альтиум упорно игнорирует 3D модели. Может в настройках слоёв ошибка? Принудительно создал пару слоёв где явно указал слой Mechanical 1 как 3D Body. Не пойму где собака порылась.
  3. Есть подозрения, что настройки интерактивного размещения компонентов задаются где-то в другом месте. Отключил его (Preferences -> PCB Editor вкладка Interactive Routing -> опция Component Pushing установил в Ignore), вручную сблизил два SMD компонента и именно на дистанции 0.1 мм по границам выскочила ошибка. При интерактивном размещении ближе 0,467 мм подвести один к другому не получается. Прошерстил уже все настройки, не пойму никак. upd Или что-то с библиотечными компонентами не так? Развернул два элемента на 45 градусов. Каждый из них очерчивается ортогональным прямоугольником и подвести один к другому сколь-нибудь близко вообще не представляется возможным. Т.е. в моём случае альтиум берёт габариты не из файла 3D модели, а как-то вычисляет по по линиям графики футпринта.
  4. Здравствуйте all. Два вопроса от новичка. 1. Можно ли задать горячие клавиши для пользовательских наборов слоёв как в P-CAD? Постоянно лазить мышкой в угол и целится в маленький переключатель очень утомляет. Есть желание назначить клавиши F5-F8 для этого. 2. Как определяется зазор при при интерактивном размещении компонентов на плате (перетаскивание мышью)? Реалистичная 3D модель подключена к каждому компоненту проекта. Она, как я понял, и используется для определения его габаритов при интерактивном размещении и трассировке. В настройках установил зазор ComponentClearance в 0,1 мм, однако минимальное расстояние на которое альтиум позволяет подвести один компонент к другому ~0.467 мм. Между "контейнерами" выделенных компонентов 0,048мм. Можно, конечно, отключить интерактивное размещение и размещать элементы сколь-угодно близко, но это приходится делать "на глазок" с постоянным ручным контролем расстояния. Хочется автоматизации, но никак не разберусь. Altium Designer 19.
  5. ATxmega256A3, 16 кБайт RAM. Я подразумевал, что ОЗУ нет больше свободного, там помимо ФС ещё много чего крутится. На данный момент свободно байт 200. Байт 400 ещё можно сэкономить ("привет" от предыдущего программиста засунувшего RO данные в RAM вместо flash). Но так или иначе замена МК, как и иное вмешательство в аппаратку - табу, устройство в серийном производстве. Так что не стоит ломать голову. Сейчас мысль родилась, пока Вам отвечал, вместо моих двух линейных буферов (ping-pong) сделать один кольцевой (FIFO). В критических режимах когда SD карта "тупит" пул памяти будет более эффективно утилизироватья.
  6. AlexRayne Вы, наверное, использовали команду записи одиночного блока (CMD24)? Автор FatFS Чан писал, что не советует использовать эту команду, сильно просаживает производительность и деструктивно влияет на саму память. В случае использования SPI интерфейса это не так ярко выражено, как в случае SDIO, т.к. даже при использовании мультиблочной записи приходится дожидаться готовности карты после каждого блока. PS Поэкспериментировал тут с размером кластера для карт 4 класса, ничего не изменилось. Частота возникновения "провалов" осталась прежней. На карте 10 класса пока всё стабильно (т-т-т). Считаю, что вопрос мой исчерпан, сердечно благодарю всех за советы и помощь.
  7. Ну будь моя воля, повторюсь, я бы переделал плату на современном контроллере с интерфейсом SDIO. Начальство: ни разу не глупые люди, как и я и Вы понимают разницу между "работать на столе" и "работать в полевых условиях". Было принято решение оставить как есть до первых рекламаций. Да, некрасиво. Но это - не оборонка, не авиакосмос. Клиент не привередливый, до моего реинжиниринга там вообще мрак был со стабильностью. Намёк понял(
  8. aaarrr, действительно "ой", именно 45DB. Конечно, если понадобится, и на проводках распаяют (даже Siemens этим в своих ПЛК не гнушается). Но пока вроде бы всё нормально. Сижу уже второй час тесты гоняю на карте 10-го класса. Снизил битрейт до ~20 кБайт/с, увеличил буфер до 3 кБайт (250 мс задержка потребует буфера 5 кБайт) пишется пока без потерь. Закупим карты SanDisk, будем ими устройства комплектовать, с производства пока снимать не будем) Джеймс, спасибо за помощь, но мимо, с 45DB они распиновкой различаются. Я этим чипы от OnSemi и Microchp как-раз и смотрел. Вообще интересную проблему "всковырнул". Хоть с картами приходится работать крайне редко, но про такие нюансы как-то не доводилось слышать (как и упомянутые на прошлой странице разработчики диктофонов).
  9. Нашёл в документе "Physical Layer Simplified Specification Version 6.00" Задержка завершения любой операции записи на SD HC может составить 250 мс вне зависимости от режима и скоростной характеристики карты (а для SD XC может быть увеличен до 500 мс). Т.е. у меня даже не предельный случай, всё согласно спецификации. 2AlexandrY, Вы задержки измеряли используя SDIO интерфейс, с ним контроллер карты быстрее работает, чем при использовании SPI. Размер блока для SD HC всегда жёстко задан размером 512 байт. Размер кластера наверное побольше надо сделать, чтобы драйвер Fat пореже move_window() вызывал? Без буфера адекватного размера, как выяснилось коллективным разумом, весь мой проект - балансирование на шесте: ветер дунул и акробат свалился. Концептуальный просчёт на этапе проектирования. Поискал бегло последовательную RAM в SOIC8 корпусе взамен имеющейся dataflash, по цоколёвке ничего совместимого не нашёл.
  10. 2jcxz Устройство серийное, уже давно в производстве, поэтому в схемотехнику вмешиваться нельзя. Так бы поставил stm32, задействовал SDIO и не морочил себе голову) На плате есть неиспользуемая микросхема dataflash (NOR SPI), можно на худой конец её под буфер попробовать приспособить. Там хотя бы все задержки детерминированы. Случай с зависанием на 2 секунды - предельный. Мне только на одной из карт по счастливой (не счастливой) случайности удалось это получить: наложились скоростные характеристика карты, размер кластера ФС, размер внутренних секторов/страниц самой карты. На других образцах повторить не смог. Уже решили с руководством использовать карты исключительно 10-го класса. Если у кого-то из пользователей получится вогнать карту в ступор на время превышающее период WDT, тогда и продолжу изыскания. И так уже этот кейс съел уйму времени. Это справедливо только для SPI режима? От класса карты время как-либо зависит? Коль так, то этот факт много объясняет из моих вопросов. Полезу мануал на физический уровень почитаю.
  11. Спасибо за советы, Все мои догадки и мысли подтвердили, значит двигался в верном направлении. Размер буфера могу максимум до 3 кБ увеличить, нет больше ОЗУ в этом контроллере. Ну и как-то размер не кратный двум меня смущает. Ещё могу битрейт аудио данных снизить чтобы бОльшие по времени объёмы информации буферизировать (чтение аудио данных я сделал асинхронным относительно записи на карту). Программный ватчдог - первое что написал когда обнаружилась проблема. Однако когда понял что локализована она внутри библиотеки FatFS - отказался. Хоть её код и открыт, я придерживаюсь правила не лезть внутрь сторонних библиотек. При необходимости обновления помимо банальной замены файлов придётся ещё и собственные костыли переносить. И не факт, что этим придётся занимать мне, а не другому бедолаге-программисту. Изоляция кода, вроде бы так это называется. Возможно, что и заблуждаюсь... Воспользуюсь самым простым советом к чему и склонялся, пропишу в инструкции использование карт 10 класса и переложу ответственность на конечного пользователя. У этих карт тоже производительность падает при случайно записи (как там конвейр и буферизация внутри устроены), но не так катастрофически.
  12. Приветствую коллег по цеху. Столкнулся с некоторыми проблемами при работе с SD-картой, буду рад помощи. Дано: ущербная 8-битная AVR по SPI шине пишет на карту поток аудио-данных. Скорость потока всего лишь 250-450 кбит/с (0.03-0.05 МБ/с). Данные буферизируются по 2 кБайт и командой мульти-блочной записи отправляются на карту (по 512 байт согласно спецификации SD HC). Проблема: На тестовых картах 4 класса (класс 10 почти никогда) наблюдаются сильные провалы производительности на 2-3 порядка через равные промежутки времени (период зависит от карты). По спецификации карты кл4 должны обеспечивать скорость записи до 4 МБ/с. Неоднократно обсуждали, что это операции внутреннего контроллера SD-карты: очистка страниц и выравнивание износа. Также нашёл недавнюю похожую тему (только про чтение с карты), где упоминалось, что в SPI-режиме SD-контроллер по-другому (более медленно) работает с массивом flash-памяти Может-быть кто-то реализовывал подобные схемы обмена и поделится опытом? Меня интересует скорость потока данных который удалось без потерь записать на карту в SPI режиме и объём буфера. Мои 2 кБайт явно недостаточно, хотя и скорости на 2 порядка ниже предельных (пусть и заявленных для SDIO). PS На одной из конфигураций дарйвер FatFS (последняя версия v14) забирает управление на 2 секунды - срабатывает аппаратный watchdog. Потеря фреймов аудио - очень неприятно, но отказ системы - это уже через чур.
  13. Попробуйте поменять USB-кабель на более качественный. До недавнего времени пользовался китайским клоном Saleae16 и проблема с постоянными "отвалами" со снижением частоты захвата побудила меня приобрести новый анализатор (невозможно было им пользоваться). Каково же было моё удивление, когда подключив старый глючащий анализатор новым кабелем я избавился от проблем. С виду старый кабель выглядел вполне неплохо: позолоченные контакты, ферритовые фильтры, нормальная толщина.
  14. При переходе на новый движок поменялся формат 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 в новые?
  15. Отдельная терминальная программа RTT-Viewer где-то в директории с софтом от Segger (JLink и пр.)
  16. Вы оказались правы, никакой порчи переменной не было. Суточный прогон с отключенными прерываниями это подтвердил. Я неверно истолковал свои отладочные данные. DMA всему виной, но пока не понял где и почему он "погибает". Спасибо всем вам за содействие, дальше я сам. А то сильно ушли от изначальной темы с SREG. Удачи, поменьше багов в коде ;)
  17. Мне кажется, что на таких объёмах данных (400 кБайт) 32-битная контрольная сумма со слабым алгоритмом лишена смысла. Банальный счётчик элементов массива будет где-то рядом по надёжности.
  18. NStorm, аргумент в функция передаётся по значению: явно задано число. Т.е. две команды LDI и следом сразу вызов этой функции. Baser, нет переменной в map-файле. Она фактически существует только на регистрах во время работы функции, ОЗУ под неё не выделяется. Там вообще всё настолько примитивно, что даже смешно. Либо заблудился в 3-х соснах (что в последнее время частенько), либо на какую-то аппаратную аномалию наткнулся. В общем поставил запрет прерываний на функцию целиком и запустил тест.
  19. Помню в IAR подобный атрибут тоже был. Много лет назад тему здесь даже создавал с вопросом, когда в прерывании SPI из-за пролога не успевал предварительно подготовленную порцию данных загрузить. Переменная передаётся в качестве аргумента функции (хм, можно ли называть её "локальной"). Объявлена как uint16_t cnt_16_bit. В ассемблерном коде представлена регистровой парой R22:R23.
  20. Всё намного сложнее: та 16-битная переменная локальная, ни в прерываниях, ни где-либо ещё она не используется. А прописные истины с атомарностью доступа к переменным разрядностью выше нативной я знаю, не первый год на кнопки жму :) В любом случае спасибо Вам за советы. По теме. Проверил все 10 обработчиков прерываний в своём проекте, каждый из них сохраняет содержимое SREG в прологе.
  21. zombi, Вы тут троллингом решили заняться? Понятия не имею что вызвало дефект пайки на этой фотографии. Я её привёл исключительно для того чтобы показать: 1) дефекты подобного рода имеют место быть 2) подобные дефекты обнаруживаются только с применением рентгенологического оборудования 3) осуществляя подобный ремонт ПП на глаз и на коленке надо быть готовым к возникновению чего-то подобного. Тема, на мой взгляд, исчерпана. На Ваш изначальный вопрос "чем опасна установка..." я и другие пользователи дали ответ. Вам остаётся лишь принять решение: допустимо или нет прибегать к такому виду ремонта в Ваших устройствах. Нравятся эти "будульки", готовы работать с рекламациями - паяйте, отговаривать не буду.
  22. Отличаются объёмом припоя. А, возможно, ничем не отличаются. Без рентгена Вам это никто не скажет наверняка (уж точно не я). Человеческий глаз - не самый точный измерительный инструмент. Картинка из интернета.
  23. Спасибо, что ткнули носом, действительно, компилятор следит за сохранением SREG (поэтому мой стрессовый тест и не усугубил проблему). Искал в ассемблерном листинге мнемонику "SREG", а там "голый" адрес регистра 0x003F... ISR(TCE0_OVF_vect) { asm("nop"); // <--- Set breakpoint here TEST_PIN_HIGH(); SREG = 0xFF & ~CPU_I_bp; TEST_PIN_LOW(); } "Эффект утёнка", пока не спросишь, не увидишь очевидной вещи. Сейчас все остальные (штатные) обработчики проверю. На всякий случай. Неделю с этой бедой воюю, не знаю на что ещё грешить.
  24. Шарики для реболлинга всегда калиброванные что обеспечивает равномерный объём припоя на контактных площадках. Ваши "бурульки" только с виду выглядят одинаковыми. После пайки Вы получите что-то подобное Либо большой объём припоя приведёт к распуханию и слипанию смежных шариков. Явное КЗ Вы ещё в состоянии проверить, а вот утечки (если сопротивление такого контакта 1-10 МОм) - вряд ли. Малый объём припоя приведёт к образованию в тонкого "мостика" вместо полноценного шарика. Как он поведёт себя при термоциклировании и вибрациях - никто Вам здесь не скажет. Так что поддержу ранее высказавшихся: для ремонта личных домашних устройств - подойдёт. Для коммерческого использования к тому же, упаси случай, в ответственных узлах - нет
  25. Добрый день. С 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; однако на частоту ошибки это не повлияло.