Не надо проще. Если вы (а судя по всему именно вы то в теме) не понимаете терминов из статьи, значит вы сильно начинающий инженер. Не будете же вы предлагать программистские статьи излагать настолько же подробно и рафинированно?
Автор молодец! Подобного ликбеза должно быть больше! И именно таким языком :)
Не согласен только с пунктом про "Выберите оптимальный тип упаковки компонентов".
Если у меня нет собственного завода, то мне, как разработчику устройства, глубоко безразлично, в какой по ширине катушке будут закуплены пассивные компоненты или те же микросхемы. Да хоть россыпью, если контрактору так будет удобно собирать и при этом он с меня лишних денег не возьмет. Из-за этого, у себя всегда исключаю из наименования упаковку. Если только она не одна единственная вообще и при этом производитель не указал в явном виде в документации, что в артикуле отвечает за обозначение упаковки.
Я вам уже писал, не стоит распространять свой опыт на всю индустрию целиком. Если вам по работе попадались только гнилые места, это не означает, что все места такие.
Карась плавает. Карась — рыба. Но это не означает, что все рыбы плавают. А вы продолжаете это упорно утверждать из раза в раз.
Схемотехники для RS2058 взяли для Э3 распиновку от корпуса MSOP10, а на PCB поставили корпус QFN.
А это системная ошибка. При грамотно построенной разработке такого не должно быть в принципе. Если такое случается, то это означает, что процесс проектирования электроники построен неверно.
что дальше то с ней делать? Ведь поток данных с камеры серьезный и это нужно как-то сжать и передать.
В описываемом случае ничего не жалось, передавалось как есть, благо всего 640х480 и где-то 12-15 фпс было. За сеть, если не забыл, отвечал lwIP.
Или там аппаратные декодеры какие-то?
Насколько понимаю, аппаратные кодеки.
И никогда не пробовали ябловскую технику ковырять?
Нет. Максимум, который у меня есть в этом плане — дисплей от второго айпада, который через доп. плату можно воткнуть по eDP.
Как считаете, есть ли шанс завести дисплей, например от 6S Plus или от 7 Plus/8 Plus яблока? Или там может инициализацию дисплея на криптографию ставят и без ключа не инициализируешь?
Не знаю. Я бы для начала попробовал бы опознать дисплей, потом нашел бы на него документацию. Ну а что примерно делать дальше — описано в статье ;)
Эх, знали бы вы, сколько инженерОв проектируют платы вообще слабо представляя, что там в них реально происходит. Наслушался тут всякого разного на собеседованиях. Особенно повеселил товарищ, на словах делавший 10 гигабит и не знающий, где в дифпаре выравнивание надо бы делать.
То есть, если вы накрутите китовыи объектив по моему линку на любую камеру, больше 9 реальных мегапикселей она не выдаст.
Вот сразу вопрос: каких именно мегапикселей? 9 мегапикселей с размером пикселя в 1, 3, 9, еще сколько-то микрон? То, что вы написали — слишком расплывчато. Не знаю, как там у DxO с определением мегапикселей, не интересовался. Если не совсем плохо, то, очевидно, нужно приводить не только количество пикселей, но и их размер. Иначе это разговор ни о чем.
Это из-за использования схемы Грену. Надо расслабить глаза как при разглядывании стереокартинок. И обязательно индивидуально подстроить межзрачковое расстояние. МБСы проигрывают просветлением и хроматизмом, но построены по схеме Аббе, поэтому в них комфортнее смотреть. По крайней мере для меня это работает.
Что заставляет вас думать, что их симуляция далека от реальности? Я не смог быстро найти шестую ссылку в открытом доступе. Если у вас есть этот документ, не сочтите за труд, пожалуйста, положить его куда-нибудь и маякнуть мне в лс. Мне любопытно было бы почитать.
Да, 1,6 процента на реальном железе не очень существенный выигрыш, но мне искренне представляется, что в тех применениях, где необходимо аккуратное и точное управление моментом, векторное управление вне конкуренции. Поправьте меня, если я не прав.
Преимущества FOC, как следует из документа, довольно призрачны.
Крайне смелое утверждение, если внимательно посмотреть на вот эту картинку
и внимательно почитать
выводы документа.
5 Summary Hardware, software and test results of BLDC block commutation with Hall sensors and sensorless FOC for three-phase BLDC motors in power tool applications have been compared. Compared with BLDC block commutation with Hall sensors, sensorless FOC results in lower power losses and higher efficiency for the power board. To further reduce MOSFET power loss, for BLDC block commutation with Hall sensors it is desirable to choose MOSFETs with body-diode or low forward voltage (e.g. Infineon 40 V MOSFETs with integrated monolithic Schottky-like diode) as the body-diode conduction loss of MOSFETs is significant, while for sensorless FOC choosing faster switching silicon MOSFETs or gallium nitride (GaN) FETs will help to reduce the dominant switching loss. The motor current of sensorless FOC is sinusoidal or close to sinusoidal depending on motor design. This will result in smoother motor output torque, which is beneficial to applications such as sanders and grinders for better polishing. It will also achiever quieter (acoustic) motor operation and fewer EMI problems than BLDC block commutation with Hall sensors. The robust motor start-up of sensorless FOC is especially valuable, as load torque is often unknown or changing rapidly in power tool applications. By eliminating rotor sensors and their cables, connectors and PCBs, sensorless FOC is well-suited to power tool applications in harsh environments due to severe moisture, humidity, temperature or vibrations, or where conventional rotor sensors cannot be accommodated due to reliability concerns, cost or physical constraints.
I know that all agile consultants write books narrating their key role in the history of agile, but I expect to get something useful for putting up with the self promotion. Here long travelogues are interspersed with basic information that is available on the websites of the other consultants mentioned. I feel I wasted my money on this, I got no insights into hardware agile.
иначе git попросит разрезолвить конфликт вручную (это можно сделать, но гиморно)
Если возник конфликт в трассировке
и развести заново недостающий кусок.
Это-то как раз и нужно, автоматом. Всё остальное просто мишура. Так что "космических преимуществ", которые "дарует" связка KiCAD+git просто нет, есть обычное ведение проекта с периодическими коммитами.
Блоком может быть как целый лист, так и какая-то логическая часть схемы на листе
Сильно зависит от плотности компоновки. Не всегда такой подход реализуем на практике.
В общем, понятно. На мой взгляд, вы не смогли привести никаких веских аргументов, кроме как "о-ло-ло, кикад лучше вашего богомерзкого альтиума и кейденса, потому что опенсорс". Ну ок, переубеждать вас не буду, ваша статья про СКИФ была очень интересной, но с вашим взглядом на разработку я категорически не согласен :) Расходимся.
там коллектив минимально достаточный для постановки задач и контроля подрядчиков
Инфа 100%, да? Какой вы, простите, бред пишете. Да, часть работ этих компаний действительно отдается на аутсорс. Но у них есть свой штат разработчиков железа и он весьма обширен. В общем всё с вами понятно.
Прошу назвать все эти три фирмы которые удовлетворяют таким требованиям. Ах, да, их в России просто нет!
Яндекс, Ядро, Сбер. Это из того, что сходу вспомнилось.
Ядро Linux разрабатывает несколько сотен тысяч человек
Это программирование, а не разработка электроники, конструирование механики или процесс производства. Не вводите в заблуждение, приравнивая все эти виды работы. Они разные, с разными особенностями.
KiCAD легко интегрируется с Git. P-CAD, Altium и Cadence — нет!
Пикад действительно нет, альтиум с кейденсом умеют. Правда, не так, как вы привыкли, но это уже часть ответа на другой ваш комментарий.
Вы можете в любой момент посмотреть историю изменений, откатиться в любую точку, мерджить изменения выполненные другими разработчиками или из другой ветки проекта, отправлять изменения на review или проводить такие review в команде.
Да-да-да, скажите это инженеру-конструктору или технологу на производстве: посмотри там коммит такой-то, там было то-то. Вы что, не понимаете, как устроены взрослые MCAD?
По моим наблюдениям, в каждом конкретном случае проблемы в первую очередь связаны с людьми, а не с ECAD. Не хотят разбираться, не хотят думать. А сложности с САПР это уже десятое дело. И будь вы семи пядей во лбу, если вам не показать приемы эффективной работы в любом ECAD и не объяснить на берегу, как правильно выстроить процесс разработки от и до, то сами вы до этого можете доходить годами.
Не надо проще. Если вы (а судя по всему именно вы то в теме) не понимаете терминов из статьи, значит вы сильно начинающий инженер. Не будете же вы предлагать программистские статьи излагать настолько же подробно и рафинированно?
Автор молодец! Подобного ликбеза должно быть больше! И именно таким языком :)
Спасибо, любопытное резюме.
Не согласен только с пунктом про "Выберите оптимальный тип упаковки компонентов".
Если у меня нет собственного завода, то мне, как разработчику устройства, глубоко безразлично, в какой по ширине катушке будут закуплены пассивные компоненты или те же микросхемы. Да хоть россыпью, если контрактору так будет удобно собирать и при этом он с меня лишних денег не возьмет. Из-за этого, у себя всегда исключаю из наименования упаковку. Если только она не одна единственная вообще и при этом производитель не указал в явном виде в документации, что в артикуле отвечает за обозначение упаковки.
Я вам уже писал, не стоит распространять свой опыт на всю индустрию целиком. Если вам по работе попадались только гнилые места, это не означает, что все места такие.
Карась плавает. Карась — рыба. Но это не означает, что все рыбы плавают. А вы продолжаете это упорно утверждать из раза в раз.
Для этого есть JTAG.
А это системная ошибка. При грамотно построенной разработке такого не должно быть в принципе. Если такое случается, то это означает, что процесс проектирования электроники построен неверно.
Бегите из этого места как можно скорее. :)
Спасибо :)
В описываемом случае ничего не жалось, передавалось как есть, благо всего 640х480 и где-то 12-15 фпс было. За сеть, если не забыл, отвечал lwIP.
Насколько понимаю, аппаратные кодеки.
Нет. Максимум, который у меня есть в этом плане — дисплей от второго айпада, который через доп. плату можно воткнуть по eDP.
Не знаю. Я бы для начала попробовал бы опознать дисплей, потом нашел бы на него документацию. Ну а что примерно делать дальше — описано в статье ;)
Эх, знали бы вы, сколько инженерОв проектируют платы вообще слабо представляя, что там в них реально происходит. Наслушался тут всякого разного на собеседованиях. Особенно повеселил товарищ, на словах делавший 10 гигабит и не знающий, где в дифпаре выравнивание надо бы делать.
Вот сразу вопрос: каких именно мегапикселей? 9 мегапикселей с размером пикселя в 1, 3, 9, еще сколько-то микрон? То, что вы написали — слишком расплывчато. Не знаю, как там у DxO с определением мегапикселей, не интересовался. Если не совсем плохо, то, очевидно, нужно приводить не только количество пикселей, но и их размер. Иначе это разговор ни о чем.
Факультет, кафедра? Как там Кудж и товарищи?
Это из-за использования схемы Грену. Надо расслабить глаза как при разглядывании стереокартинок. И обязательно индивидуально подстроить межзрачковое расстояние. МБСы проигрывают просветлением и хроматизмом, но построены по схеме Аббе, поэтому в них комфортнее смотреть. По крайней мере для меня это работает.
Кроме люфта.
Что заставляет вас думать, что их симуляция далека от реальности? Я не смог быстро найти шестую ссылку в открытом доступе. Если у вас есть этот документ, не сочтите за труд, пожалуйста, положить его куда-нибудь и маякнуть мне в лс. Мне любопытно было бы почитать.
Да, 1,6 процента на реальном железе не очень существенный выигрыш, но мне искренне представляется, что в тех применениях, где необходимо аккуратное и точное управление моментом, векторное управление вне конкуренции. Поправьте меня, если я не прав.
Крайне смелое утверждение, если внимательно посмотреть на вот эту картинку
и внимательно почитать
выводы документа.
5 Summary Hardware, software and test results of BLDC block commutation with Hall sensors and sensorless FOC for three-phase BLDC motors in power tool applications have been compared. Compared with BLDC block commutation with Hall sensors, sensorless FOC results in lower power losses and higher efficiency for the power board. To further reduce MOSFET power loss, for BLDC block commutation with Hall sensors it is desirable to choose MOSFETs with body-diode or low forward voltage (e.g. Infineon 40 V MOSFETs with integrated monolithic Schottky-like diode) as the body-diode conduction loss of MOSFETs is significant, while for sensorless FOC choosing faster switching silicon MOSFETs or gallium nitride (GaN) FETs will help to reduce the dominant switching loss. The motor current of sensorless FOC is sinusoidal or close to sinusoidal depending on motor design. This will result in smoother motor output torque, which is beneficial to applications such as sanders and grinders for better polishing. It will also achiever quieter (acoustic) motor operation and fewer EMI problems than BLDC block commutation with Hall sensors. The robust motor start-up of sensorless FOC is especially valuable, as load torque is often unknown or changing rapidly in power tool applications. By eliminating rotor sensors and their cables, connectors and PCBs, sensorless FOC is well-suited to power tool applications in harsh environments due to severe moisture, humidity, temperature or vibrations, or where conventional rotor sensors cannot be accommodated due to reliability concerns, cost or physical constraints.
Отзывы на амазоне воодушевляют:
I know that all agile consultants write books narrating their key role in the history of agile, but I expect to get something useful for putting up with the self promotion. Here long travelogues are interspersed with basic information that is available on the websites of the other consultants mentioned. I feel I wasted my money on this, I got no insights into hardware agile.
Кому верить? :)
Конденсатор вольтодобавки. Bootstrap capacitor.
Имеет. Напишите, пожалуйста, будет очень любопытно почитать.
Это-то как раз и нужно, автоматом. Всё остальное просто мишура. Так что "космических преимуществ", которые "дарует" связка KiCAD+git просто нет, есть обычное ведение проекта с периодическими коммитами.
Сильно зависит от плотности компоновки. Не всегда такой подход реализуем на практике.
В общем, понятно. На мой взгляд, вы не смогли привести никаких веских аргументов, кроме как "о-ло-ло, кикад лучше вашего богомерзкого альтиума и кейденса, потому что опенсорс". Ну ок, переубеждать вас не буду, ваша статья про СКИФ была очень интересной, но с вашим взглядом на разработку я категорически не согласен :) Расходимся.
Инфа 100%, да? Какой вы, простите, бред пишете. Да, часть работ этих компаний действительно отдается на аутсорс. Но у них есть свой штат разработчиков железа и он весьма обширен. В общем всё с вами понятно.
Яндекс, Ядро, Сбер. Это из того, что сходу вспомнилось.
Это программирование, а не разработка электроники, конструирование механики или процесс производства. Не вводите в заблуждение, приравнивая все эти виды работы. Они разные, с разными особенностями.
Пикад действительно нет, альтиум с кейденсом умеют. Правда, не так, как вы привыкли, но это уже часть ответа на другой ваш комментарий.
Да-да-да, скажите это инженеру-конструктору или технологу на производстве: посмотри там коммит такой-то, там было то-то. Вы что, не понимаете, как устроены взрослые MCAD?
По моим наблюдениям, в каждом конкретном случае проблемы в первую очередь связаны с людьми, а не с ECAD. Не хотят разбираться, не хотят думать. А сложности с САПР это уже десятое дело. И будь вы семи пядей во лбу, если вам не показать приемы эффективной работы в любом ECAD и не объяснить на берегу, как правильно выстроить процесс разработки от и до, то сами вы до этого можете доходить годами.