Jump to content

    

Aaron

Свой
  • Content Count

    278
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Aaron

  • Rank
    Местный
  • Birthday 08/05/1984

Старые поля

  • Vkontakte
    Array

Контакты

  • Сайт
    Array

Информация

  • Город
    Array

Recent Profile Visitors

3054 profile views
  1. barkey, спасибо за развёрнутый ответ! выводы конечно печальные... А вот я вижу, что вы представитель сертифицированного поставщика. У вас в штате есть люди, которые занимаются разбором/пересылкой таких уведомлений? уточнение к п.4) возможных идей - может быть такой вариант сотрудничества, как договор с поставщиком на информационное сопровождение базы данных. Готовы ли поставщики за такое браться? :)
  2. Топик ещё актуален? 5 лет не прошло :) В роли руководителя отдела разработчиков себя рассматриваете, включая личное участие в разработках?
  3. Коллега, а вы не рассматриваете вопрос перехода всем коллективом под крыло крупной компании?
  4. По названию тема больше подходит форуму "Управление проектами", но тот форум совсем дохлый, например вот вопрос Управление жизненным циклом изделия остался без единого комментария. Проблема: Крупное предприятие, номенклатура применяемых ЭРИ более 29000 наименований. Часть ЭРИ снимается с производства периодически, сейчас в производственной БД почти 2400 наименований - это снятые с производства ЭРИ. Сейчас снятие с производства ЭРИ проверяется (хотя зачастую проверяется просто возможность закупки на складах, при этом статус end-of-life EOL неизвестен) на этапе подготовки договора на изготовление изделий. Отсюда - внезапные новости про необходимость подбора замен, коррекции КД или про невозможность изготовления изделий. Вопрос: Кто как решает проблему сопровождения жизненного цикла ЭРИ и самое главное - своевременного получения информации о снятии ЭРИ с производства? Ответы в духе "что сложного-то? взял да поменял ЭРИ на другую" не подходят, т.к. фактически сейчас работа так и строится уже (см. текст выше). А хочется получать информацию более оперативно и заблаговременно, желательно автоматизированно. Возможные идеи: 1) может, есть специализированные сайты с отслеживанием статуса EOL и доступом (в т.ч. платным) через API, а также опыт по их использованию? Пока приходит на ум mouser.com - есть какие-то инструменты "Помощник по вопросам цен и наличия", "Менеджер проектов", отображает статус вида "Срок эксплуатации: Вышло из употребления" 2) доступ к поисковикам типа efind.ru через API - условно, если по запросу ЭРИ предложений не найдено, то считаем, что EOL наступил. Но это работает слишком поздно. 3) регистрация на сайтах производителей ЭРИ и подписка на новости об изменениях условий поставки. Муторно, сильный человеческий фактор, не все производители могут делать такую рассылку. 4) взаимодействие с сертифицированными поставщиками, - они уведомляют о снятии с производства запрашиваемых микросхем? Опять же, это ручная работа через менеджеров по закупке, человеческий фактор.
  5. Файлик готовый прикрепить не могу, уж извините (прокся только на вход), придётся вам самим создать workspace.epf со следующим содержимым: Можете поиграться, потом оставить только нужные вам строки semanticHighlighting. Мою цветовую схему прошу не критиковать, все галстуки на вкус разные ;)
  6. А почему вы считаете, что они определены? Если вы используете GCC в режиме "Си", то он не знает этих ключевых слов - только в режиме "Си++". Вы же говорите, что bool, false, true - это пользовательские слова (из названия темы). Я вас так и понял. Дак а вам получается просто нужно раскрасить ключевые слова языка, уже имеющиеся и распознаваемые Eclipse. Был проект то ли на github, то ли на sourceforge, который позволял собственные темы цветовые создавать для Eclipse, я им один раз воспользовался, для себя тему создал, и с ней живу уже десяток лет, ничего не меняя :) Могу поделиться, если надо. Файлик *.epf настроек C Editor Appearance импортируется в каждый новый workspace.
  7. Я добавлял себе в старые проекты, не заточенные под GCC компилятор, файлик eclipse-pic-compat.h следующего вида: #ifndef ECLIPSE_PIC_COMPAT_H_ #define ECLIPSE_PIC_COMPAT_H_ // define macro "ECLIPSE_MPLAB_PROJECT" to avoid eclipse parser errors #ifdef ECLIPSE_MPLAB_PROJECT #define interrupt #define low_priority // interrupt #define high_priority // interrupt #define __bit char #define __nonreentrant #define intrinsic(X) "void" // NOTE: добавлять сюда extern-заглушки для всех использующихся определений вида extern volatile TXSTA1bits_t TXSTA1bits @ 0xFAC из файла описания МК библиотеки xc8\...\include extern PORTAbits_t PORTAbits; extern PORTBbits_t PORTBbits; extern PORTCbits_t PORTCbits; extern OSCCONbits_t OSCCONbits; extern INTCONbits_t INTCONbits; #endif // ECLIPSE_MPLAB_PROJECT #endif /* ECLIPSE_PIC_COMPAT_H_ */ Ну и в проекте в начале main.h его подключал. В свойствах проекта прописывал определение ECLIPSE_MPLAB_PROJECT Убивает двух зайцев - подсветка пользовательских слов и исключение ошибок встроенного парсера GCC при работе с такими проектами. Делал такие же файлики для проектов, которые были заточены под кейловский компилятор.
  8. Что-то значит вы делаете не так. Директива KEEP явно обязывает компилятор резервировать секцию в памяти, даже если в проекте ни один объект не ссылается на элементы из этой секции. Именно таким образом выделяются области памяти, которые могут потом хитрым образом использоваться в прошивке. 1) вы уверены, что линкер использует именно тот файл .ld, который вы правите? Проверьте, мб он тянет дефолтный ld из тулчейна. 2) может быть такое, что адрес начала секции .vram явно привязан к ссылке __bss_end__ ? в этом случае также будет наложение. 3) если п.1, п.2 в порядке, имеет смысл выложить сюда ваш ld файл.
  9. в линкер файле секцию (без полезных) данных выделить ключевым словом KEEP(*(.noinit*)), иначе при оптимизации все "пустые" секции вырезаются.
  10. Да, интересный подход, с этой точки зрения я никогда не думал. Позвольте вопрос задать с практической точки зрения. Я всегда рассматривал подобные конденсаторы во-первых как ВЧ-фильтры от стандартных пульсаций питания из-за потребления мк/сх, во-вторых как бочки с запасом энергии для нивелирования больших бросков тока. Условно, 0,01мкф..0,1 мкФ в качестве фильтров, 1..4 мкФ в качестве запаса энергии. И пока что такой подход везде работает. Вы же предлагаете рассматривать полный импеданс - то есть, допустим цифровая мк/сх работает на 400МГц и потребляет 1А @ 3V3 (то есть имеет условно сопротивление 3,3 Ом) - и вы рассчитываете полный импеданс на частоте 400МГц? Подбираете конденсаторы необходимого номинала и с правильными ТТХ на указанной частоте? Или всё же работает принцип "ставим 0,1 мкФ 0603 - это покрывает все требования с головой"?
  11. Голословное и неверное утверждение. Фильтрация сделана вполне правильно. Макароны - это подводы цепей питания. Кондеры и стоят в тч чтобы шумы от этих макарон фильтровать. Еще добавлю, что в вашем случае судя по всему можно будет односторонним монтажом обойтись. Не забывайте, что это также улучшает технологичность. Автоматический монтаж облегчается, регулировка. Меньше сверловки, меньше вероятность брака.
  12. Почему зря? Вы получите очень хороший опыт по согласованию методик тестирования. Вам надо отстаивать свою позицию - если испытания в составе холодильного оборудования, то: 1) там есть ножки, демпферы. Нагрузка, которая будет передаваться на плату конкретно, существенно будет отличаться от заявленных вами 0,35мм @ 50Гц. 2) вы должны разработать и согласовать методики испытаний на основе ТЗ. В методиках надо учитывать модель (математическую, физическую и т.п.) холодильного оборудования, и для вас должны предъявляться требования уже сниженные. Либо в методиках испытаний должно быть прописано что-то такое: испытаниям подвергаются платы установочной серии (или каждые Х плат из партии) в составе холодильного оборудования. 3) если платы проверять отдельно, то как минимум их надо проверять в оснастке, которая будет имитировать нахождение в составе холодильного оборудования. Корпус устройства - обязательно! Прямая аналогия для наглядности - ракеты должны выдерживать условную температуру 600С. Электроника внутри ракет тем не менее на эту температуру отдельно от ракеты не проверяется ;)
  13. Mplata абсолютно прав. С другой стороны, если ТЗ на плату и вы под этим подписались и исправить никак, то придется выполнять. Проблема 100% в изгибе платы, с одной точкой крепления конечно на вибрациях всё ходуном ходит. Увеличивайте жесткость платы в первую очередь. Если есть возможность, наращивайте толщину. Металлизация тут не поможет, мягкая медь никакой жесткости не даст имхо. Крупные эри поменять на более мелкие, придвинуть ближе к крепежу, приклеивать перед установаой. Комплекс мер должен помочь. По поводу саботажа - не ищите сложностей там где их нет. Механические повреждения от вибраций, а пайка - на стороне делалась? Профиль пайки неверный подобрать - эри не пропаяются, особенно крупные. Их после печи могли вручную допаивать.
  14. Коллега, и всё же предлагаю отмести железобетонно аппаратные проблемы. Я вижу, что на приведённой картинке линии имеют разный цвет ;) Как предположение (надо смотреть код touchGFX) - у вас обмен с SDRAM проводится в виде транзакций. Одна строчка изображения - одна транзакция. В промежутках между транзакциями шина может не использоваться. При проблемах в топологии из-за нарушения целостности сигналов могут быть всякие чудеса. Например, при появлении данных на линии первые биты могут портиться, и потом при окончании транзакции последние биты портиться. Может, у вас на линии идёт какая-то наводка извне? При этом, если данные передавать непрерывно, то проблема может не проявляться визуально.
  15. если на аппаратные проблемы думать, то тогда напишите, какая длина трасс? какой разброс длин? пробовали паттерны какие-то выводить - может у вас проблема по конкретным линиям данных?