Pull to refresh
11
0
Игорь @r6l-025

Embedded разработчик

Send message

Можно и так, но у нас PDU только питанием самой платы рулит. А usb устройства - чтоб не вырубить программаторы соседнего стенда нужно либо на каждый стенд по своему хабу вешать (и управлять только его питанием), либо точечно управлять питанием портов. У нас второй вариант сложился исторически. Хотя, конечно, можно и первым идти

Вам тогда надо наоборот, людей автоматизировать)

Мы остановились на MOXA, на модели UPORT 407, если не ошибаюсь. Ей можно управлять через uhubctl, что тоже удобно т.к. не требует какого-то проприетарного софта. Да и железо в хабах себя довольно хорошо зарекомендовало, у нас с ними стало гораздо меньше "отвалов" usb устройств, чем с обычными, офисными хабами.

Кстати, можно посмотреть на странице uhubctl, на github, там есть перечисление моделей разных хабов с которыми uhubctl умеет работать, ну и у которых есть поддержка ppps

К обсуждению выше про ЛУТ - хорошо и стабильно получается на ламинаторе при печати на глянцевой стороне подложки от самоклейки. Гораздо лучше чем на глянцевых журналах. Дорожки 0.15-0.2 вполне выходят. Единственное, сложно позиционировать слои на двухслойной плате, вот тут уже очень нестабильно получается. На станке, как в статье, попроще должно быть

Eembedded есть, в основном FPGA, МК, DSP процессоры. Занимаемся и встраиваемыми ОСями, хотя (как могу видеть) больше просто bare metall. В основном это задачи либо управления конкретным железом, либо DSP полученных данных.
C/C++ на седьмом месте и далеко не факт, что все отметившие эти языки занимаются встраиваемыми устройствами
У нас много софта пишется на С/C++ не только embedded, весь ЦОС и системное программирование тоже на них.
ребята оттуда редко приходят в IT-сообщество и делятся знаниями
У нас сложилась исторически довольно консервативная и закрытая структура. С одной стороны режим, с другой стороны я бы сказал некоторая оторванность от остального IT сообщества по стеку технологий. Хотя опытом поделится было бы безусловно интересно друг с другом.

malloc в linux при запросе достаточно большого объема памяти (128 КБ по дефолту) как раз использует mmap. При этом используется анонимное отбражение памяти из адресного пространства самого процесса. Такая выделенная память при завершении процесса умрет вместе с ним. Описано в т.ч. тут: https://habr.com/ru/company/smart_soft/blog/185226/

На прошлой работе не то чтоб сильно методы отличались. Уже второй год прошел как уволился, до сих пор ровно каждый месяц просмотр аккаунта на Hh у всех уволившися за крайние несколько лет сотрудников отделом кадров, после чего передают нач отдела. Если кто-то еще успел поменять место, то он тут же рассказывает всему отделу как товарища N выперли в такой то компании на бесполезность (по его достоверным источникам), мол, можете сами на hh посмотреть что он там уже не рабтоает, как видел другую половину уволившихся в "быстроденьги", как все живут на шее у жен на мат пособия и т.п. Мониторят соц сети жен и родственников сотрудников, если увидят общие фотки с "предателями" потом делают бубличные выговоры тем кто общается с недостоиными

Я это и подразумеваю, что у всех могут быть совершенно различные причины для повышенного потребления. Я к тому что если верить сказанному, то энергопотребление "выше среднего" может быть причиной для того чтоб кто-то решил устроить проверку на тему майнинга. Но, так то всегда можно съехать что много обогревателей, чайников, эл плита и т.п. Так что сам по себе факт повышенного потребления довольно безобиден. Специфический профиль энергопотребления уже более подозрителен. Но и тут можно обойти при желании

Да, согласен, написано что еще анализируется потребление относительно среднего по квартирам. Но это лишь признак для проверки. Предъявить по этому признаку сложнее чем по специфичному профилю потребления. Хотя, конечно, да, надо еще как-то обосновать свое повышенное потребление

Сдается, что как стали появлятся контроллеры на FPGA, так появятся и адаптированные под майнинг UPS'ы которые будут сглаживать колебания потребляемого тока

Сама концепция то ни разу не новая, тут скорее упор что сделали относительно чувствительный приемник. Хотя 20 дБ выглядит не так уж и круто с учетом что полосу сильно широкой не сделать

А я и не говорю что это здача "на вечер". Но для людей занимающихся трассировкой ПП с скоростными интерфейсами это не то чтоб выдающаяся задача. DDR3 не так уж и сложна в разводке. hdmi, ethernet, usb аналогично

Как-то смысл затеи не ясен. Плата сама по себе весьма простая,собенно учивая обилие открытых референсных схем, и что в ней особенного... как pet проект да, штука хорошая. Но как проект о котором СМИ говорит - очень странно

Так не байка же, вроде. Он это как-то в интервью сказал, когда в прошлый раз решил перейти с 4.x версии на 5.0

А чем вам не понравились классы в ядре? Их там не много, и они весьма в удачных местах. Например, класс с файловыми операциями. А на счет производительности... нужны бенчмарки. Как-то интуитивно выглядит как раз наоборот. В Си это просто разыменование указателей для вызова функций. А в плюсах?

Я подозреваю что когда пишет не C++, а C/C++ - то хотят видеть человека умеющего работать с обоими парадигмами. Хотя, иногда попадаются очень забавные объявление от HR котрые их не всегда различают: " Хотим знание Си и boost". А вот на счет наколеночного embedded я бы поспорил (иначе Linux kernel, Postgresqsl, etc. превращаются в наколеночный embedded)

Радиолюбители вполне даже используют. В школе даже на соревнования ездил по ней

Кстати, в начале приводился пример согласования на стороне источника через дополнение сопротивления источника до нужного сопротивления канала. А как измеряется полное сопротивление источника? Я так понимаю там должно быть именно полное сопротивление, а не чисто активное?

Еще есть неплохие по описанию, и весьма дешевые (50$ у производителя) платки от Cypress
ron.terraelectronica.ru/news/4496
Предоставляют мост USB3.0 — fifo с которым может работать FPGA без спец корок и отдельного USB PHY
К вопросу о разбиении кода на минимальные по размеру функции/методы. Возможно кто-то прояснит. Я начинал свою практику программирования с системного программирования на Си. И когда сейчас в коде на плюсах вижу подобное дробление меня постоянно мучает сомнение о накладных расходах, и о балансе между читабельностью и производительностью кода. Разве не приходится производить кучу подготовительной работы чтоб предоставить стек для создаваемой функции, сохранить все нужные состояния регистров и т.п.? И все для того чтоб сделать простое действие и вызвать новую функцию/метод насилуя память сохранением состояний предыдущих фреймов. Я понимаю что есть куча компиляторных оптимизаций, да и далеко не везде нужно смотреть на подобные расходы, но все же
Сдается что это что-то вроде импортозамещения в области комплектующих: забугровые использовать нельзя, но если нужно — то можно. Не во всех случаях, но нередко попросту пишется бумажка где обосновывается что на отечественной элементной базе условия поставленные в ТЗ выполнить не возможно. Так и с ПО
1

Information

Rating
Does not participate
Works in
Registered
Activity

Specialization

Embedded Software Engineer
Linux
C
FPGA
SystemVerilog
PCB design
RISC-V
AXI
Electronics Development