Во многом правы. Но одна фича без которой я уже не представляю смартфон это зум 0.5х или 0.7х т.е. отдельная широкоугольная камера. Правда это надо вначале попробовать чтобы понять нужно ли оно.
У меня Honda Clarity, это plugin гибрид по тепловозной схеме. За 3 года колодки как новые, все торможение рекуперацией. И да, на спусках сгоры очень хорошо батарею заряжает
Все у вас нормально с технологией пайки, я сам так уже десятки плат собрал и микросхемы там были сильно мельче ваших. Облудили плату, отмойте от флюса хорошо Нанесите минимальное кол-во флюса Расставьте все компаненты включая мелкие микросхемы Грейте феном с широкой насадкой на самой низкой подаче воздуха. Делайте широкие движения чтобы прогреть побольше часть платы. Переодически задерживайте фен на какой-то детали, чтобы увидеть что припой поплыл. Как только это случилось идите медленно от компанента к компаненту, они будут плыть и становиться на свои места. Микросхемы грейте сверху вертикально, они тоже должны сами стать куда нужно.
Как же они умеют освещать такие события. Подробная информация на сайте, хорошо снятые видео и даже инструкции, как самому модель этой ракеты построить.
Стандартный техник из Теслы, проверит провода, передернет пару раз питание. Если бутлоадер живой, проверит версию прошивки, возможно перепрошьет девайс. Если бутлоадер мертвый или перепрошивка не помогла, то он возьмет новый ECU, а этот отдаст инженерам на разбор полетов.
Это все можно, но зачем? CAN уже есть, весь софт для апдейта и отладки по CAN уже есть и это даже отраслевой стандарт. Зачем тут ещё и UART с CLI нужен?
CAN для отладки помогает отлично. Туда выводятся все нужные сигналы, записывают трейсы и анализируют их во времени. Мало того, это все делается ещё и удаленно, когда трейс отправляется на сервер и можно видеть все сигналы в онлайн. Это дело ещё и работает не просто на один блок а сразу на всю машину и на одном графике можно смотреть сигналы от разных блоков.
Эх, ну вот опять, декларируется обязательность UART CLI. Мы уже вроде обсуждали это в другом посте, но я повторюсь.
В той же Tesla S, около 200 ECU, и ни в одном из них нет UART, все делается только по CAN и совсем они там от этого не страдают. Model 3 и Supercharger тоже на CAN. UART в Supercharger прикрутил я в CCS версию т. к. нужно было TCP/IP отлаживать.
В своих проектах я всегда UART первым поднимаю, но индустрия в целом вполне обходится без него и без CLI.
По CAN сильно удобней работать если это много устройств как в автомобиле. Достаточно подключиться в одном месте к шине и можно отлаживать или обновлять прошивку на всех устройствах на этой шине. Ну вот как вы такой трюк с UART провернёте
А помех в случае инвенторов не боитесь? 1-wire интерфейс совсем не помехоустойчивый.
Я как-то делал софт для зарядника EV, там подобный сенсор поставили в саму ручку, которая к машине подключается, ну и кабель метра три до зарядника. Зарядник был 300kw. Когда ток начали качать, этот датчик стал чудеса показывать. В конце концов заменили на обычную термопару.
Мне кажется вы не поняли о чем я пишу. Моя главная мысль, что нет никакой обязательности иметь какой-то определенный протокол для обновления. Этот протокол всегда выбирается под конкретную задачу. Где-то UART зайдёт, а где-то без CAN никуда. Есть устройства где все взаимодействие только по USB происходит.
32KB вам мало чтобы USB device сделать? Интересно как же я USB host запихнул в 16. А на счёт CAN так и вообще смешно, там сложность не сильно больше UART.
Ну а вообще у меня больше претензия к обязательности обновления по UART декларируемой в статье. Возьмите туже Tesla там все блоки обновляются только по CAN, а про UART большинство инженеров даже не знают.
Сам Arduino это всего лишь конструктор, он не является конечным устройством не для промышленного ни для потребительского рынка.
Ответственное применение Arduino запрещено пока оно не пройдет соответствующую сертификацию.
К чипам претензий никаких нет, но чипы это и не Arduino. В любой компании занимающейся профессионально электроникой есть свои электронщики и программисты. Ну вот что там такого в этом Arduino, что его обязательно нужно копировать в свои устройства?
Я тоже видел много практического применения. Отработав 4 года эмбедером в Tesla я видел и Arduino, Raspberry PI и кучу других "конструкторов". Но это все были как-бы проекты на стороне, чтобы облегчить жизнь тестировщикам или электронщикам. Ни о какой серии или ответственном применении даже речь не шла. Да и не понятно зачем.
Вопрос же не в том нужно разрешение или нет. Вопрос в том, зачем фирме производящей электронику использовать Arduino для устройств, которые идут в массовое производство. Какой вообще профит от этого.
И смартфоны тоже: падение рынка худшее за много лет. В чем причина?
Во многом правы.
Но одна фича без которой я уже не представляю смартфон это зум 0.5х или 0.7х т.е. отдельная широкоугольная камера. Правда это надо вначале попробовать чтобы понять нужно ли оно.
Грузовик Tesla Semi смог преодолеть 500 миль с полной загрузкой на одной зарядке, что в Daimler называли невозможным
У меня Honda Clarity, это plugin гибрид по тепловозной схеме. За 3 года колодки как новые, все торможение рекуперацией. И да, на спусках сгоры очень хорошо батарею заряжает
Грузовик Tesla Semi смог преодолеть 500 миль с полной загрузкой на одной зарядке, что в Daimler называли невозможным
Не помню можно ли тут постить ссылки на внешние ресурсы, но вот тут довольно подробно высказано мнение дальнобойщика из США по поводу 500миль теслы и как это применимо к реальности:
https://www.quora.com/What’s-the-average-range-for-a-diesel-semi-truck
Автономный LTE роутер своими руками | Часть 2 – Логистика и сборка платы
Все у вас нормально с технологией пайки, я сам так уже десятки плат собрал и микросхемы там были сильно мельче ваших.
Облудили плату, отмойте от флюса хорошо
Нанесите минимальное кол-во флюса
Расставьте все компаненты включая мелкие микросхемы
Грейте феном с широкой насадкой на самой низкой подаче воздуха. Делайте широкие движения чтобы прогреть побольше часть платы. Переодически задерживайте фен на какой-то детали, чтобы увидеть что припой поплыл.
Как только это случилось идите медленно от компанента к компаненту, они будут плыть и становиться на свои места.
Микросхемы грейте сверху вертикально, они тоже должны сами стать куда нужно.
НАСА запустило «Артемиду-1»
Как же они умеют освещать такие события. Подробная информация на сайте, хорошо снятые видео и даже инструкции, как самому модель этой ракеты построить.
Почему нам нужен UART-Shell? (или 23 новые возможности)
Стандартный техник из Теслы, проверит провода, передернет пару раз питание. Если бутлоадер живой, проверит версию прошивки, возможно перепрошьет девайс. Если бутлоадер мертвый или перепрошивка не помогла, то он возьмет новый ECU, а этот отдаст инженерам на разбор полетов.
Почему нам нужен UART-Shell? (или 23 новые возможности)
Ах да, точно, забыл про него.
Почему нам нужен UART-Shell? (или 23 новые возможности)
Это все можно, но зачем? CAN уже есть, весь софт для апдейта и отладки по CAN уже есть и это даже отраслевой стандарт. Зачем тут ещё и UART с CLI нужен?
Почему нам нужен UART-Shell? (или 23 новые возможности)
Сделаю bisect по изменениям и найду что его сломало.
Почему нам нужен UART-Shell? (или 23 новые возможности)
CAN для отладки помогает отлично. Туда выводятся все нужные сигналы, записывают трейсы и анализируют их во времени. Мало того, это все делается ещё и удаленно, когда трейс отправляется на сервер и можно видеть все сигналы в онлайн. Это дело ещё и работает не просто на один блок а сразу на всю машину и на одном графике можно смотреть сигналы от разных блоков.
Почему нам нужен UART-Shell? (или 23 новые возможности)
Эх, ну вот опять, декларируется обязательность UART CLI. Мы уже вроде обсуждали это в другом посте, но я повторюсь.
В той же Tesla S, около 200 ECU, и ни в одном из них нет UART, все делается только по CAN и совсем они там от этого не страдают. Model 3 и Supercharger тоже на CAN. UART в Supercharger прикрутил я в CCS версию т. к. нужно было TCP/IP отлаживать.
В своих проектах я всегда UART первым поднимаю, но индустрия в целом вполне обходится без него и без CLI.
По CAN сильно удобней работать если это много устройств как в автомобиле. Достаточно подключиться в одном месте к шине и можно отлаживать или обновлять прошивку на всех устройствах на этой шине. Ну вот как вы такой трюк с UART провернёте
Intel и Google Cloud выпустили чип для повышения производительности центров обработки данных
Ёлки палки, так я над этим чипом 2 года в Google работал. Проводил брингап самых первых образцов пришедших от Intel
Google представила смартфоны Pixel 7 и Pixel 7 Pro, а также умные часы Pixel Watch
Трудно сказать есть ли смысл их брать, мне больше хочется узнать, что же в итоге Google выкатил.
Google представила смартфоны Pixel 7 и Pixel 7 Pro, а также умные часы Pixel Watch
А я вот только часы заказал, но седьмая прошка у меня давно уже есть, достойный аппарат
Открытый проект мультизонного термосенсора с логированием и блютусом
А помех в случае инвенторов не боитесь? 1-wire интерфейс совсем не помехоустойчивый.
Я как-то делал софт для зарядника EV, там подобный сенсор поставили в саму ручку, которая к машине подключается, ну и кабель метра три до зарядника. Зарядник был 300kw. Когда ток начали качать, этот датчик стал чудеса показывать. В конце концов заменили на обычную термопару.
Что Должно Быть в Каждом FirmWare Pепозитории
Мне кажется вы не поняли о чем я пишу. Моя главная мысль, что нет никакой обязательности иметь какой-то определенный протокол для обновления. Этот протокол всегда выбирается под конкретную задачу. Где-то UART зайдёт, а где-то без CAN никуда. Есть устройства где все взаимодействие только по USB происходит.
Что Должно Быть в Каждом FirmWare Pепозитории
32KB вам мало чтобы USB device сделать? Интересно как же я USB host запихнул в 16. А на счёт CAN так и вообще смешно, там сложность не сильно больше UART.
Ну а вообще у меня больше претензия к обязательности обновления по UART декларируемой в статье. Возьмите туже Tesla там все блоки обновляются только по CAN, а про UART большинство инженеров даже не знают.
Что Должно Быть в Каждом FirmWare Pепозитории
А почему вдруг загрузчик обязательно надо обновлять по UART?! Например по CAN он тоже отлично обновляется, и даже по, прости господи, USB
Почему недостаточно Arduino, чтобы автоматизировать производство?
Сам Arduino это всего лишь конструктор, он не является конечным устройством не для промышленного ни для потребительского рынка.
Ответственное применение Arduino запрещено пока оно не пройдет соответствующую сертификацию.
К чипам претензий никаких нет, но чипы это и не Arduino. В любой компании занимающейся профессионально электроникой есть свои электронщики и программисты. Ну вот что там такого в этом Arduino, что его обязательно нужно копировать в свои устройства?
Почему недостаточно Arduino, чтобы автоматизировать производство?
Я тоже видел много практического применения. Отработав 4 года эмбедером в Tesla я видел и Arduino, Raspberry PI и кучу других "конструкторов". Но это все были как-бы проекты на стороне, чтобы облегчить жизнь тестировщикам или электронщикам. Ни о какой серии или ответственном применении даже речь не шла. Да и не понятно зачем.
Вопрос же не в том нужно разрешение или нет. Вопрос в том, зачем фирме производящей электронику использовать Arduino для устройств, которые идут в массовое производство. Какой вообще профит от этого.