Jump to content

    

Aaron

Свой
  • Content Count

    274
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Aaron

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

Старые поля

  • Vkontakte
    Array

Контакты

  • Сайт
    Array

Информация

  • Город
    Array

Recent Profile Visitors

3002 profile views
  1. Файлик готовый прикрепить не могу, уж извините (прокся только на вход), придётся вам самим создать workspace.epf со следующим содержимым: Можете поиграться, потом оставить только нужные вам строки semanticHighlighting. Мою цветовую схему прошу не критиковать, все галстуки на вкус разные ;)
  2. А почему вы считаете, что они определены? Если вы используете GCC в режиме "Си", то он не знает этих ключевых слов - только в режиме "Си++". Вы же говорите, что bool, false, true - это пользовательские слова (из названия темы). Я вас так и понял. Дак а вам получается просто нужно раскрасить ключевые слова языка, уже имеющиеся и распознаваемые Eclipse. Был проект то ли на github, то ли на sourceforge, который позволял собственные темы цветовые создавать для Eclipse, я им один раз воспользовался, для себя тему создал, и с ней живу уже десяток лет, ничего не меняя :) Могу поделиться, если надо. Файлик *.epf настроек C Editor Appearance импортируется в каждый новый workspace.
  3. Я добавлял себе в старые проекты, не заточенные под 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 при работе с такими проектами. Делал такие же файлики для проектов, которые были заточены под кейловский компилятор.
  4. Что-то значит вы делаете не так. Директива KEEP явно обязывает компилятор резервировать секцию в памяти, даже если в проекте ни один объект не ссылается на элементы из этой секции. Именно таким образом выделяются области памяти, которые могут потом хитрым образом использоваться в прошивке. 1) вы уверены, что линкер использует именно тот файл .ld, который вы правите? Проверьте, мб он тянет дефолтный ld из тулчейна. 2) может быть такое, что адрес начала секции .vram явно привязан к ссылке __bss_end__ ? в этом случае также будет наложение. 3) если п.1, п.2 в порядке, имеет смысл выложить сюда ваш ld файл.
  5. в линкер файле секцию (без полезных) данных выделить ключевым словом KEEP(*(.noinit*)), иначе при оптимизации все "пустые" секции вырезаются.
  6. Да, интересный подход, с этой точки зрения я никогда не думал. Позвольте вопрос задать с практической точки зрения. Я всегда рассматривал подобные конденсаторы во-первых как ВЧ-фильтры от стандартных пульсаций питания из-за потребления мк/сх, во-вторых как бочки с запасом энергии для нивелирования больших бросков тока. Условно, 0,01мкф..0,1 мкФ в качестве фильтров, 1..4 мкФ в качестве запаса энергии. И пока что такой подход везде работает. Вы же предлагаете рассматривать полный импеданс - то есть, допустим цифровая мк/сх работает на 400МГц и потребляет 1А @ 3V3 (то есть имеет условно сопротивление 3,3 Ом) - и вы рассчитываете полный импеданс на частоте 400МГц? Подбираете конденсаторы необходимого номинала и с правильными ТТХ на указанной частоте? Или всё же работает принцип "ставим 0,1 мкФ 0603 - это покрывает все требования с головой"?
  7. Голословное и неверное утверждение. Фильтрация сделана вполне правильно. Макароны - это подводы цепей питания. Кондеры и стоят в тч чтобы шумы от этих макарон фильтровать. Еще добавлю, что в вашем случае судя по всему можно будет односторонним монтажом обойтись. Не забывайте, что это также улучшает технологичность. Автоматический монтаж облегчается, регулировка. Меньше сверловки, меньше вероятность брака.
  8. Почему зря? Вы получите очень хороший опыт по согласованию методик тестирования. Вам надо отстаивать свою позицию - если испытания в составе холодильного оборудования, то: 1) там есть ножки, демпферы. Нагрузка, которая будет передаваться на плату конкретно, существенно будет отличаться от заявленных вами 0,35мм @ 50Гц. 2) вы должны разработать и согласовать методики испытаний на основе ТЗ. В методиках надо учитывать модель (математическую, физическую и т.п.) холодильного оборудования, и для вас должны предъявляться требования уже сниженные. Либо в методиках испытаний должно быть прописано что-то такое: испытаниям подвергаются платы установочной серии (или каждые Х плат из партии) в составе холодильного оборудования. 3) если платы проверять отдельно, то как минимум их надо проверять в оснастке, которая будет имитировать нахождение в составе холодильного оборудования. Корпус устройства - обязательно! Прямая аналогия для наглядности - ракеты должны выдерживать условную температуру 600С. Электроника внутри ракет тем не менее на эту температуру отдельно от ракеты не проверяется ;)
  9. Mplata абсолютно прав. С другой стороны, если ТЗ на плату и вы под этим подписались и исправить никак, то придется выполнять. Проблема 100% в изгибе платы, с одной точкой крепления конечно на вибрациях всё ходуном ходит. Увеличивайте жесткость платы в первую очередь. Если есть возможность, наращивайте толщину. Металлизация тут не поможет, мягкая медь никакой жесткости не даст имхо. Крупные эри поменять на более мелкие, придвинуть ближе к крепежу, приклеивать перед установаой. Комплекс мер должен помочь. По поводу саботажа - не ищите сложностей там где их нет. Механические повреждения от вибраций, а пайка - на стороне делалась? Профиль пайки неверный подобрать - эри не пропаяются, особенно крупные. Их после печи могли вручную допаивать.
  10. Коллега, и всё же предлагаю отмести железобетонно аппаратные проблемы. Я вижу, что на приведённой картинке линии имеют разный цвет ;) Как предположение (надо смотреть код touchGFX) - у вас обмен с SDRAM проводится в виде транзакций. Одна строчка изображения - одна транзакция. В промежутках между транзакциями шина может не использоваться. При проблемах в топологии из-за нарушения целостности сигналов могут быть всякие чудеса. Например, при появлении данных на линии первые биты могут портиться, и потом при окончании транзакции последние биты портиться. Может, у вас на линии идёт какая-то наводка извне? При этом, если данные передавать непрерывно, то проблема может не проявляться визуально.
  11. если на аппаратные проблемы думать, то тогда напишите, какая длина трасс? какой разброс длин? пробовали паттерны какие-то выводить - может у вас проблема по конкретным линиям данных?
  12. век живи - век учись! Так и параноиком стать можно...
  13. А переезд в РФ так и не рассматривается?
  14. Можно ликбез провести по поводу srec_cat? bin файлы же не обладают встроенной информацией о секциях адресов. Проводится подготовка промежуточных файлов .srec и из них далее из одного файла могут генерироваться несколько bin?
  15. По поводу KEEP ещё раз: вы создаёте ld-файл с секцией BANK2. Далее в цели сборки перечисляете только те зависимости, которые должны попасть в BANK2. Типа такого: bank2.bin: graphics.o constans.o bank2_script.ld $(LD) graphics.o constans.o $(LDFLAGS) -Tbank2_script.ld -o "bank2.bin" Поскольку переменные/константы в привязываемых объектниках из этих же файлов не вызываются никак, то для них в ld-файле должно быть слово KEEP. SECTIONS { .bank2_data : { KEEP(*(.bank2)) KEEP(*(.bank2.*)) } >BANK2