Aaron

Приветствую! Посмотрел ваши сообщения, вроде как переезд не рассматриваете. Тем не менее, я попробую предложение сделать 🙂 Прошу посмотреть мои древние (2016, 2018г) сообщения о вакансиях в нашей компании, а также можно поискать о нас в интернете, для понимания в целом направления наших работ: Готов с вами пообщаться в личке / по почте / по скайпу / телеграмму / телефону на предмет возможного переезда к нам с трудоустройством full-time на должность ведущего инженера-электроника / заместителя или начальника отдела, уровень з/п от 200к и выше на руки. Если интерес есть - напишите мне контакты в личку, я с вами свяжусь.

ЛА - это хобби? а другие проекты, не связанные с ТАУ, вас интересуют? Зеленоград рассматриваете в качестве места работы? Посмотрите мои старые сообщения, там конечно инфа устарела, но общее представление о нашей работе можно составить: Если интерес есть, можем пообщаться.

1) рассчитать/померить токи потребления системы при записи. 2) оценить необходимое количество энергии для полноценной записи одного кадра и безопасного завершения работы системы. 3) добавить в схему ионисторы из рассчёта п.2 и контроль пропажи первичного электропитания. 4) при пропадании первички уходим в экстренную запись последнего кадра с блокировкой и завершением остальных процессов. С таким подходом можно реализовывать хоть в baremetal, хоть в Linux+FS.

да уж, ну и код... одно и то же условие повторяется 3 раза: при этом в каждой ветке условия if ... else вы не прерываете выполнение обработки, хотя у вас обработка всего одного байта идёт. Обработчик может по одному входящему байту выполнить сразу 2 условия. Добавьте перед каждой закрывающей скобкой в обработчике: А вообще, обработчик написан как каша - всё в одну кучу. Рекомендую изменить подход к написанию кода: 1) отсечь все варианты, которые вам не подходят: 2) обработчик запихнуть в switch (не забывать аналогично про break!!!!!) 3) вы ведь понимаете, что ваш обработчик будет принципиально терять входящие данные в случае их быстрого поступления, т.к. вторая часть кода занимается ретрансляцией данных в ручном режиме без возможности своевременной обработки нового входящего байта?...

barkey, спасибо за развёрнутый ответ! выводы конечно печальные... А вот я вижу, что вы представитель сертифицированного поставщика. У вас в штате есть люди, которые занимаются разбором/пересылкой таких уведомлений? уточнение к п.4) возможных идей - может быть такой вариант сотрудничества, как договор с поставщиком на информационное сопровождение базы данных. Готовы ли поставщики за такое браться? :)

Топик ещё актуален? 5 лет не прошло :) В роли руководителя отдела разработчиков себя рассматриваете, включая личное участие в разработках?

Коллега, а вы не рассматриваете вопрос перехода всем коллективом под крыло крупной компании?

По названию тема больше подходит форуму "Управление проектами", но тот форум совсем дохлый, например вот вопрос Управление жизненным циклом изделия остался без единого комментария. Проблема: Крупное предприятие, номенклатура применяемых ЭРИ более 29000 наименований. Часть ЭРИ снимается с производства периодически, сейчас в производственной БД почти 2400 наименований - это снятые с производства ЭРИ. Сейчас снятие с производства ЭРИ проверяется (хотя зачастую проверяется просто возможность закупки на складах, при этом статус end-of-life EOL неизвестен) на этапе подготовки договора на изготовление изделий. Отсюда - внезапные новости про необходимость подбора замен, коррекции КД или про невозможность изготовления изделий. Вопрос: Кто как решает проблему сопровождения жизненного цикла ЭРИ и самое главное - своевременного получения информации о снятии ЭРИ с производства? Ответы в духе "что сложного-то? взял да поменял ЭРИ на другую" не подходят, т.к. фактически сейчас работа так и строится уже (см. текст выше). А хочется получать информацию более оперативно и заблаговременно, желательно автоматизированно. Возможные идеи: 1) может, есть специализированные сайты с отслеживанием статуса EOL и доступом (в т.ч. платным) через API, а также опыт по их использованию? Пока приходит на ум mouser.com - есть какие-то инструменты "Помощник по вопросам цен и наличия", "Менеджер проектов", отображает статус вида "Срок эксплуатации: Вышло из употребления" 2) доступ к поисковикам типа efind.ru через API - условно, если по запросу ЭРИ предложений не найдено, то считаем, что EOL наступил. Но это работает слишком поздно. 3) регистрация на сайтах производителей ЭРИ и подписка на новости об изменениях условий поставки. Муторно, сильный человеческий фактор, не все производители могут делать такую рассылку. 4) взаимодействие с сертифицированными поставщиками, - они уведомляют о снятии с производства запрашиваемых микросхем? Опять же, это ручная работа через менеджеров по закупке, человеческий фактор.

Файлик готовый прикрепить не могу, уж извините (прокся только на вход), придётся вам самим создать workspace.epf со следующим содержимым: Можете поиграться, потом оставить только нужные вам строки semanticHighlighting. Мою цветовую схему прошу не критиковать, все галстуки на вкус разные ;)

А почему вы считаете, что они определены? Если вы используете GCC в режиме "Си", то он не знает этих ключевых слов - только в режиме "Си++". Вы же говорите, что bool, false, true - это пользовательские слова (из названия темы). Я вас так и понял. Дак а вам получается просто нужно раскрасить ключевые слова языка, уже имеющиеся и распознаваемые Eclipse. Был проект то ли на github, то ли на sourceforge, который позволял собственные темы цветовые создавать для Eclipse, я им один раз воспользовался, для себя тему создал, и с ней живу уже десяток лет, ничего не меняя :) Могу поделиться, если надо. Файлик *.epf настроек C Editor Appearance импортируется в каждый новый workspace.

Я добавлял себе в старые проекты, не заточенные под 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 при работе с такими проектами. Делал такие же файлики для проектов, которые были заточены под кейловский компилятор.

Что-то значит вы делаете не так. Директива KEEP явно обязывает компилятор резервировать секцию в памяти, даже если в проекте ни один объект не ссылается на элементы из этой секции. Именно таким образом выделяются области памяти, которые могут потом хитрым образом использоваться в прошивке. 1) вы уверены, что линкер использует именно тот файл .ld, который вы правите? Проверьте, мб он тянет дефолтный ld из тулчейна. 2) может быть такое, что адрес начала секции .vram явно привязан к ссылке __bss_end__ ? в этом случае также будет наложение. 3) если п.1, п.2 в порядке, имеет смысл выложить сюда ваш ld файл.

в линкер файле секцию (без полезных) данных выделить ключевым словом KEEP(*(.noinit*)), иначе при оптимизации все "пустые" секции вырезаются.

Да, интересный подход, с этой точки зрения я никогда не думал. Позвольте вопрос задать с практической точки зрения. Я всегда рассматривал подобные конденсаторы во-первых как ВЧ-фильтры от стандартных пульсаций питания из-за потребления мк/сх, во-вторых как бочки с запасом энергии для нивелирования больших бросков тока. Условно, 0,01мкф..0,1 мкФ в качестве фильтров, 1..4 мкФ в качестве запаса энергии. И пока что такой подход везде работает. Вы же предлагаете рассматривать полный импеданс - то есть, допустим цифровая мк/сх работает на 400МГц и потребляет 1А @ 3V3 (то есть имеет условно сопротивление 3,3 Ом) - и вы рассчитываете полный импеданс на частоте 400МГц? Подбираете конденсаторы необходимого номинала и с правильными ТТХ на указанной частоте? Или всё же работает принцип "ставим 0,1 мкФ 0603 - это покрывает все требования с головой"?

Голословное и неверное утверждение. Фильтрация сделана вполне правильно. Макароны - это подводы цепей питания. Кондеры и стоят в тч чтобы шумы от этих макарон фильтровать. Еще добавлю, что в вашем случае судя по всему можно будет односторонним монтажом обойтись. Не забывайте, что это также улучшает технологичность. Автоматический монтаж облегчается, регулировка. Меньше сверловки, меньше вероятность брака.