Как минимум, люди хотели бы остаться на прежнем месте работы. Наверное хотели бы развивать продукт, в который вложили столько сил. А людей натурально кинули.
Я не Ванга, но прям вижу, что этим же людям рассказывали про "мы одна семья", и что "сейчас надо потерпеть, зато потом заживем по-королевски" когда оправдывали бесплатные овертаймы и отстающую от инфляции ЗП.
Спасибо за список. Allwinner и Rockchip довольно нишевые, кмк, я раньше в эту сторону не смотрел. Теперь буду иметь в виду.
Всем чипам из списка нужна внешняя NAND, большинству – DDR. Было бы честно плюсовать их к стоимости процессоров. В целом решение получается намного круче "голого" STM32F7xx, это очевидно.
Но иногда такие объемы памяти просто не нужны. А нужен deep sleep с потреблением в несколько мкА и сохранением состояния системы.
Что было в моем случае: если упрощенно - приемник и ретранслятор. Слушал несколько каналов (цифровой поток порядка 1 Mbps); демодуляция, декодирование и разбор протокола – в софте. Снаружи там чисто аналоговая часть, выход компаратора с детектора огибающей смотрел прямо в чип.
Сохранял услышанное на SD карту. Что-то должен был передать дальше. Собственно, большую часть SRAM съели буферы, сам код и логика были достаточно простые. Батарейное питание. Конфигурация – через файл на той же SD карте.
Точную модель контроллера уже не вспомню, простите. Что-то из F7хх серии в корпусе LQFP-144.
Из личного опыта: не больше 10% в виде разных бонусов (премии, повышения, небольшой процент с продаж конкретно этих девайсов и пр). Но собственный опыт – слишком маленькая выборка )
Я-то этот пример приводил с другой целью. Показать ситуацию, когда дополнительные затраты на оптимизацию экономически выгодны для организации в целом.
Предвидя возражения, уточню: это не про затягивание разработки (сроки и TTM никто не отменял), а про окупаемость затрат на "мозги" и на "сделать хорошо".
Не соглашусь с формулировкой. Иногда дешевле, но не зачастую.
Если не трудно, приведите конкретный пример недорого SoC и задачи, которую мы решаем, работая под Linux. Чтобы понимать, какие в этом случае есть альтернативы.
Инструмент выбирается под задачу. Где-то линукс в самый раз, где-то RTOS, и там тоже есть драйвера периферии и различные стеки "из коробки". А иногда приходится отказываться не только от ОС, но и от HAL библиотек, и делать закат солнца вручную. Глазами отсматривать, какой ассемблерный код сгенерил компилятор и бороться, без преувеличения, за несколько тактов на самых горячих участках. Задачи разные бывают, как и железо.
Что выгоднее: влить деньги в "железо подороже + Linux" или "железо подешевле + bare metal + ФОТ", тоже зависит от вводных. Это если по уму. А если жить по принципу "пофиг на себестоимость, за все платит пользователь", то мы с этого и начали ветку )
Например, ужался и в STM32F7xx серии влез в младшую модель на $1.4 дешевле (там цены в районе $10). А тот чип еще и в корпусе LQFP-144 вместо LQFP-208 (допустим линий I/O нам хватает там и там). Это 64 точки пайки, примерно по $0.01 каждая. Чуть меньше надо места на плате, чуть проще трассировка, чуть выше ремонтопригодность...
Мелочи. И все-таки на крупных сериях из них набегает заметная дельта по стоимости производства и обслуживания.
Борьба за проценты все еще выгодна, только уже в другой области – где используют слабые однокристаллки (SoC). Там "влез" по памяти и быстродействию в более дешевый чип – сэкономил, например, $2 на каждом устройстве. А серия в 10 тыс. штук. Как правило профит в $20k окупает содержание программистов, умеющих в оптимизацию.
Потому что в любом варианте транскрипцией адекватно звучание все равно не передать. На слух его кто-то мог бы записать и как Хван Ен-Шин.
Здесь же сначала китайское имя подстроили под привычно звучащий для англоязычных вариант, а потом по буквам скопировали на русский. И получилось то, что получилось.
Иллюстрации к статье рисовала нейронка. На "фото" странный коннектор слева на плате, несуществующий корпус LQFP-40, корявые резисторы рядом со светодиодами, RGB светодиоды - не WS2812 (у них 4 пина, а не 6), и светятся у них не кристаллы, а блики на линзах.
Про схему и говорить нечего: это просто сюр. Кроме абсурдных подключений еще гуляет размер шрифта в маркировке STM и символ "С" задвоился.
Если оставить иллюстрации за скобками, то по существу можно добавить:
- полноценный преобразователь уровней не нужен, достаточно 1-gate инвертора с 5-вольтовым питанием. Например NC7SZ04, он же послужит буфером и защитой пина контроллера от эксцессов при подключении ленты.
- а если у нас есть инвертор, то вместо SPI или GPIO эффективнее использовать UART в режиме 7N1. Имеем "бесплатные" два бита: Start "1" и Stop "0", так что одной посылкой UART кодируем ровно три бита протокола WS2812.
- есть смысл завести DOUT с последнего светодиода на вход контроллера: можно через буфер, можно через защитный резистор - у STM довольно много five-tolerant входов, которые нормально работают с 5-вольтовыми уровнями. Тогда делая лишнюю запись в несуществующий светодиод мы увидим её на входе MCU и сможем контролировать стабильность линии связи.
- использовать классы в low-end линейке Cortex-M? На мой взгляд, оверхед не оправдывает себя. То же самое можно красиво и читабельно сделать чисто процедурно. Но это мои заморочки, тут не настаиваю.
Хотя на самом деле и чистить/тестить память и остальное не обязательно и можно было сделать эти фичи опциональными.
Если я правильно помню, то в старых IBM PC регенерация памяти была завязана на таймер + DMA. И аппаратный Reset транслировался на шину (RESET DRV).
То есть почти всё глохло или переходило в начальное состояние. И поэтому BIOS приходилось делать заново полную инициализацию.
А начиная с 286 стало возможно отдельно дернуть сброс на CPU через контроллер клавиатуры. Такой аппаратный костыль, чтобы возвращаться в real mode. И логика работы внешнего сигнала сброса несколько изменилась.
Простите, что торможу с ответами.Я пробую запихнуть в программу все, что вы написали.
Пока что вводные такие: дистанция до источника света, дистанция до линзирующей массы, угловое смещение линзирующей массы относительно оси 'наблюдатель-источник света' и, собственно, масса линзирующего обекта.
Дальше как вы говорите искать в евклидовой плоскости лучи, которые спроецировались от источника и дошли до наблюдателя. Но честная трассировка лучей -- это очень медленно.
Знаете, у меня всегда было плохо с чистой математикой. Я электронщик и немного электромеханик. В профессиональной деятельности для меня весь матан сводится к логарифмам в графике АЧХ и экспоненте в переходных процессах R-L и R-C.
Но я стараюсь искать сложные для себя вещи, чтобы мозги не закисали. Вот как эта проблема. Но с абстракциями все равно беда. Мне бы формулировку вида: "Наблюдатель и источник света находятся на одной прямой, считаем её нулем в полярной системе координат. Можно задать дальность до источника. Есть массивное тело между источником света и наблюдателем. Можно задать его смещение в сторону относительно прямой 'наблюдатель-источник света' и расстояние до него. Считаем, что источник света и наблюдатель достаточно удалены от массивного тела, чтобы пренебречь релятивистскими эффектами в точке излучения и наблюдения".
И вот тебе, Алексей, формула, описывающая максимумы яркости в поле зрения наблюдателя. Я искал, даже читал англоязычные статьи, к которым есть доступ без платной подписки. Не нашёл. Если вам где-то попадалась, поделитесь ссылкой, буду очень благодарен.
Спасибо! Собственно, смущает эта дискретность. Пространство вблизи массивного объекта искажено, но все же непрерывно.Яркий объект тоже испускает свет во всех направлениях, а не несколько лучей выборочно, как на иллюстрациях. Тогда откуда дискретные копии?
Скрытый текст
Я посмотрел симуляции, какие нашел. Где-то видно, как ободок распадается на две половинки разной степени сплюснутости, если объект чуть в стороне от оси. Но чтобы 3+ штук, не попадалось.
Скрытый текст
И отчего зависит это количество? Скорее всего от взаимного расположения источника света, наблюдателя и массивного объекта.
Мысленно начнем плавно смещать что-нибудь из перечисленного. Плавно и непрерывно. Наблюдаемая картина так же плавно должна изменяться. В голове не укладывается, как 3 штуки плавно превращаются в четыре )
Требовать, чтобы человек как заклинание мог выдохнуть "...канальный-сетевой-транспортный..." по-моему нет никакого смысла. Зато есть смысл послушать, как кандидат станет рассказывать про эту матрёшку: какие данные заворачивают внутрь других пакетов и кадров, и зачем так делать.
Скрытый текст
• Вот тут у нас есть поток сознания импульсов с линии связи, по определенным правилам они демодулируются и превращаются в биты. А еще можем отловить ошибку, когда передачи от разных узлов накладываются друг на друга.
• А здесь биты собрали в кадр. Добавили проверку на ошибки. И еще научились отличать узлы друг от друга на аппаратном уровне - можем указать, в какую железку должны попасть отправленные данные.
• Тут придумали как достучаться до узла, который находится где-то в гребенях и не может нас слышать напрямую. Как оптимальнее всего использовать промежуточные узлы. Кстати, когда нужный узел не в нашей локальной сети, его аппаратный (MAC) адрес для нас бесполезен, поэтому добавили логические IP адреса.
• А здесь решили проблему, когда на одном узле живут web сервер, файлопомойка, и почта до кучи. Чтобы сервисы не передрались между собой за входящий сетевой пакет, добавили в него специальное поле, однозначно указывающее адресата/протокол. Кстати, о протоколах: можем либо снизить накладные расходы на обмен данными, либо гарантировать их доставку.
• Здесь мы уже можем передавать нужные пользователю данные. Иногда как есть, прямо текстом или бинарными блоками. Иногда внутри более сложных протоколов. Почему этот уровень абстракции решили разбить именно на три слоя, я никогда не понимал. Скорее всего потому что число 7 красивое.
Но это понимание нужно для работы далеко не всем. Если интервьюер спрашивает про OSI не к месту, то хз, может быть он сам когда-то с трудом выучил все семь названий, и теперь ему хочется всем это показать.
А про люки как раз хорошие вопросы, люблю такие - они были актукальны в то время, когда нужны были абстрактно умные
А что сейчас модно отвечать на вопрос про люки?
Просто у меня в голове самый скучный ответ из сопромата – обеспечивают самую равномерную нагрузку и одинаковые линейные деформации. Наименьший шанс заклинить в рамке. Поэтому такие же в бункерах и на подводных лодках. Иногда их делают немного выпуклыми в ту сторону, откуда идёт нагрузка.
Можно катать без помощника? Ну возможно. А ко всем, которые не должны проваливаться в проем, просто приваривают петли. Чердачные люки не дадут соврать )
Как минимум, люди хотели бы остаться на прежнем месте работы. Наверное хотели бы развивать продукт, в который вложили столько сил. А людей натурально кинули.
Я не Ванга, но прям вижу, что этим же людям рассказывали про "мы одна семья", и что "сейчас надо потерпеть, зато потом заживем по-королевски" когда оправдывали бесплатные овертаймы и отстающую от инфляции ЗП.
Спасибо за список. Allwinner и Rockchip довольно нишевые, кмк, я раньше в эту сторону не смотрел. Теперь буду иметь в виду.
Всем чипам из списка нужна внешняя NAND, большинству – DDR. Было бы честно плюсовать их к стоимости процессоров. В целом решение получается намного круче "голого" STM32F7xx, это очевидно.
Но иногда такие объемы памяти просто не нужны. А нужен deep sleep с потреблением в несколько мкА и сохранением состояния системы.
Что было в моем случае: если упрощенно - приемник и ретранслятор. Слушал несколько каналов (цифровой поток порядка 1 Mbps); демодуляция, декодирование и разбор протокола – в софте. Снаружи там чисто аналоговая часть, выход компаратора с детектора огибающей смотрел прямо в чип.
Сохранял услышанное на SD карту. Что-то должен был передать дальше. Собственно, большую часть SRAM съели буферы, сам код и логика были достаточно простые. Батарейное питание. Конфигурация – через файл на той же SD карте.
Точную модель контроллера уже не вспомню, простите. Что-то из F7хх серии в корпусе LQFP-144.
Из личного опыта: не больше 10% в виде разных бонусов (премии, повышения, небольшой процент с продаж конкретно этих девайсов и пр). Но собственный опыт – слишком маленькая выборка )
Я-то этот пример приводил с другой целью. Показать ситуацию, когда дополнительные затраты на оптимизацию экономически выгодны для организации в целом.
Предвидя возражения, уточню: это не про затягивание разработки (сроки и TTM никто не отменял), а про окупаемость затрат на "мозги" и на "сделать хорошо".
Не соглашусь с формулировкой. Иногда дешевле, но не зачастую.
Если не трудно, приведите конкретный пример недорого SoC и задачи, которую мы решаем, работая под Linux. Чтобы понимать, какие в этом случае есть альтернативы.
Инструмент выбирается под задачу. Где-то линукс в самый раз, где-то RTOS, и там тоже есть драйвера периферии и различные стеки "из коробки". А иногда приходится отказываться не только от ОС, но и от HAL библиотек, и делать закат солнца вручную. Глазами отсматривать, какой ассемблерный код сгенерил компилятор и бороться, без преувеличения, за несколько тактов на самых горячих участках. Задачи разные бывают, как и железо.
Что выгоднее: влить деньги в "железо подороже + Linux" или "железо подешевле + bare metal + ФОТ", тоже зависит от вводных. Это если по уму. А если жить по принципу "пофиг на себестоимость, за все платит пользователь", то мы с этого и начали ветку )
Почти :)
Например, ужался и в STM32F7xx серии влез в младшую модель на $1.4 дешевле (там цены в районе $10). А тот чип еще и в корпусе LQFP-144 вместо LQFP-208 (допустим линий I/O нам хватает там и там). Это 64 точки пайки, примерно по $0.01 каждая. Чуть меньше надо места на плате, чуть проще трассировка, чуть выше ремонтопригодность...
Мелочи. И все-таки на крупных сериях из них набегает заметная дельта по стоимости производства и обслуживания.
Борьба за проценты все еще выгодна, только уже в другой области – где используют слабые однокристаллки (SoC). Там "влез" по памяти и быстродействию в более дешевый чип – сэкономил, например, $2 на каждом устройстве. А серия в 10 тыс. штук. Как правило профит в $20k окупает содержание программистов, умеющих в оптимизацию.
Потому что в любом варианте транскрипцией адекватно звучание все равно не передать.
На слух его кто-то мог бы записать и как Хван Ен-Шин.
Здесь же сначала китайское имя подстроили под привычно звучащий для англоязычных вариант, а потом по буквам скопировали на русский. И получилось то, что получилось.
Иллюстрации к статье рисовала нейронка. На "фото" странный коннектор слева на плате, несуществующий корпус LQFP-40, корявые резисторы рядом со светодиодами, RGB светодиоды - не WS2812 (у них 4 пина, а не 6), и светятся у них не кристаллы, а блики на линзах.
Про схему и говорить нечего: это просто сюр. Кроме абсурдных подключений еще гуляет размер шрифта в маркировке STM и символ "С" задвоился.
Если оставить иллюстрации за скобками, то по существу можно добавить:
- полноценный преобразователь уровней не нужен, достаточно 1-gate инвертора с 5-вольтовым питанием. Например NC7SZ04, он же послужит буфером и защитой пина контроллера от эксцессов при подключении ленты.
- а если у нас есть инвертор, то вместо SPI или GPIO эффективнее использовать UART в режиме 7N1. Имеем "бесплатные" два бита: Start "1" и Stop "0", так что одной посылкой UART кодируем ровно три бита протокола WS2812.
- есть смысл завести DOUT с последнего светодиода на вход контроллера: можно через буфер, можно через защитный резистор - у STM довольно много five-tolerant входов, которые нормально работают с 5-вольтовыми уровнями. Тогда делая лишнюю запись в несуществующий светодиод мы увидим её на входе MCU и сможем контролировать стабильность линии связи.
- использовать классы в low-end линейке Cortex-M? На мой взгляд, оверхед не оправдывает себя. То же самое можно красиво и читабельно сделать чисто процедурно. Но это мои заморочки, тут не настаиваю.
Имелись в виду совсем старые клавиатуры, времён первых IBM PC/XT и AT
Вот такие
Если я правильно помню, то в старых IBM PC регенерация памяти была завязана на таймер + DMA. И аппаратный Reset транслировался на шину (RESET DRV).
То есть почти всё глохло или переходило в начальное состояние. И поэтому BIOS приходилось делать заново полную инициализацию.
А начиная с 286 стало возможно отдельно дернуть сброс на CPU через контроллер клавиатуры. Такой аппаратный костыль, чтобы возвращаться в real mode. И логика работы внешнего сигнала сброса несколько изменилась.
Кроликовы? )
"Прости меня, Васенька, дуру грешную"
Спасибо!
Простите, что торможу с ответами.Я пробую запихнуть в программу все, что вы написали.
Пока что вводные такие: дистанция до источника света, дистанция до линзирующей массы, угловое смещение линзирующей массы относительно оси 'наблюдатель-источник света' и, собственно, масса линзирующего обекта.
Дальше как вы говорите искать в евклидовой плоскости лучи, которые спроецировались от источника и дошли до наблюдателя. Но честная трассировка лучей -- это очень медленно.
Знаете, у меня всегда было плохо с чистой математикой. Я электронщик и немного электромеханик. В профессиональной деятельности для меня весь матан сводится к логарифмам в графике АЧХ и экспоненте в переходных процессах R-L и R-C.
Но я стараюсь искать сложные для себя вещи, чтобы мозги не закисали. Вот как эта проблема. Но с абстракциями все равно беда. Мне бы формулировку вида: "Наблюдатель и источник света находятся на одной прямой, считаем её нулем в полярной системе координат. Можно задать дальность до источника. Есть массивное тело между источником света и наблюдателем. Можно задать его смещение в сторону относительно прямой 'наблюдатель-источник света' и расстояние до него. Считаем, что источник света и наблюдатель достаточно удалены от массивного тела, чтобы пренебречь релятивистскими эффектами в точке излучения и наблюдения".
И вот тебе, Алексей, формула, описывающая максимумы яркости в поле зрения наблюдателя. Я искал, даже читал англоязычные статьи, к которым есть доступ без платной подписки. Не нашёл. Если вам где-то попадалась, поделитесь ссылкой, буду очень благодарен.
Спасибо! Собственно, смущает эта дискретность. Пространство вблизи массивного объекта искажено, но все же непрерывно.Яркий объект тоже испускает свет во всех направлениях, а не несколько лучей выборочно, как на иллюстрациях. Тогда откуда дискретные копии?
Скрытый текст
Я посмотрел симуляции, какие нашел. Где-то видно, как ободок распадается на две половинки разной степени сплюснутости, если объект чуть в стороне от оси. Но чтобы 3+ штук, не попадалось.
Скрытый текст
И отчего зависит это количество? Скорее всего от взаимного расположения источника света, наблюдателя и массивного объекта.
Мысленно начнем плавно смещать что-нибудь из перечисленного. Плавно и непрерывно. Наблюдаемая картина так же плавно должна изменяться. В голове не укладывается, как 3 штуки плавно превращаются в четыре )
Эхх... Пойду искать хороший симулятор. Потому что вот это (https://foothillastrosims.github.io/gravitational-lensing/) – вообще несерьезно.
PS: Я ни в коем случае не спорю с физикой, я правда хочу понять. И спасибо вам, что доступно объясняете очень сложные вещи.
Александра, вопрос не совсем по теме статьи, но когда еще доведется спросить? )
Почему при гравитационном линзировании иногда объект "размножается", как например Крест Эйнштейна? Почему не светящийся ободок или полумесяц?
В тех объяснениях, которые я видел, чаще всего встречается предположение что "Несколько линз на оси наблюдения, неравномерности, так совпало".
Требовать, чтобы человек как заклинание мог выдохнуть "...канальный-сетевой-транспортный..." по-моему нет никакого смысла. Зато есть смысл послушать, как кандидат станет рассказывать про эту матрёшку: какие данные заворачивают внутрь других пакетов и кадров, и зачем так делать.
Скрытый текст
• Вот тут у нас есть поток
сознанияимпульсов с линии связи, по определенным правилам они демодулируются и превращаются в биты. А еще можем отловить ошибку, когда передачи от разных узлов накладываются друг на друга.• А здесь биты собрали в кадр. Добавили проверку на ошибки. И еще научились отличать узлы друг от друга на аппаратном уровне - можем указать, в какую железку должны попасть отправленные данные.
• Тут придумали как достучаться до узла, который находится где-то в гребенях и не может нас слышать напрямую. Как оптимальнее всего использовать промежуточные узлы. Кстати, когда нужный узел не в нашей локальной сети, его аппаратный (MAC) адрес для нас бесполезен, поэтому добавили логические IP адреса.
• А здесь решили проблему, когда на одном узле живут web сервер, файлопомойка, и почта до кучи. Чтобы сервисы не передрались между собой за входящий сетевой пакет, добавили в него специальное поле, однозначно указывающее адресата/протокол.
Кстати, о протоколах: можем либо снизить накладные расходы на обмен данными, либо гарантировать их доставку.
• Здесь мы уже можем передавать нужные пользователю данные. Иногда как есть, прямо текстом или бинарными блоками. Иногда внутри более сложных протоколов.
Почему этот уровень абстракции решили разбить именно на три слоя, я никогда не понимал. Скорее всего потому что число 7 красивое.
Но это понимание нужно для работы далеко не всем. Если интервьюер спрашивает про OSI не к месту, то хз, может быть он сам когда-то с трудом выучил все семь названий, и теперь ему хочется всем это показать.
А что сейчас модно отвечать на вопрос про люки?
Просто у меня в голове самый скучный ответ из сопромата – обеспечивают самую равномерную нагрузку и одинаковые линейные деформации. Наименьший шанс заклинить в рамке. Поэтому такие же в бункерах и на подводных лодках. Иногда их делают немного выпуклыми в ту сторону, откуда идёт нагрузка.
Можно катать без помощника? Ну возможно. А ко всем, которые не должны проваливаться в проем, просто приваривают петли. Чердачные люки не дадут соврать )
На Шпицберген?
Да, вряд ли плата работала с перемкнутыми адресными линиями. Получается, просто фото неудачно зашакалилось.