Алексей, вы просто немного ошиблись: в ролике говорится, что у них единственное в России производство электролампового стекла, то есть просто сырого материала для изделий. А по колбам они являются лидером.
Было бы ещё неплохо, если бы софт можно было запустить на чём-то кроме MS Windows. Вот например если бы работала связка ubuntu/rhel+gcc/clang, то можно было бы говорить о поддержке.
То что через специфический SDK/NDK можно собирать ELF бинарники для Android конечно неплохо, но явно маловато. Я подозреваю, что кучей хаков можно и под десктопный Linux провернуть сборку, раз уж под Android поддержка есть, но всё равно нужно это делать на MS Windows.
Я думаю, что фраза «плавающие в пару» там просто в качестве гиперболы.
Впрочем если там прорвало горячую трубу, то пары часов в такой обстановке гитарам хватит чтобы стать мусором, даже не соприкасаясь с водой напрямую — дерево быстро впитывает влагу из горячего пара.
ПЛИС, в которую можно зашить нормальный микроконтроллер(зачем, кстати) обойдётся слишком дорого для хобби
Т.е. чтобы разработчик решил использовать что-то нетрадиционное, для этого нужны очень веские причины. Собственно я и хотел узнать эти причины.
Есть всего 2 основные причины:
Стандартное решение не справляется с поставленной задачей
Шило в заднице
Ну и иногда бывают особые случаи вроде окончания срока жизни компонентов, торговых эмбарго и прочее, но тут обычно выбирают другое, но тоже стандартное решение.
На вопрос «зачем» ответить не готов, наоборот — мне было бы интересно какие преимущества могли бы повлиять на решение выбора микроконтроллера. Или хотя бы узнать с какими проблемами Вы столкнулись при использовании STM32.
Микроконтроллеры дешевые и работают, а линейки на ядрах ARM Cortex Mx(STM32 — лишь одна линейка от одной компании) — дают огромный выбор периферии, скорости и цен. А проблемы у каждой задачи свои.
В «стандартном» G-code реагировать на события нельзя, реакцию должен обрабатывать софт, который выполняет G-code.
Опасаюсь показаться назойливым, а нет ли другого аналогичного протокола, который реализует поддержку внешних событий? Т.е для станка обратная связь не обязательна, а вот для манипулятора, который мог бы поместить болванку в станок и извлечь готовую деталь, обратная связь необходима.
G-code — это даже не протокол, это просто некий, относительно универсальный, язык. На этом языке описано что нужно сделать, а вот как именно это сделать в реальном мире решает софт, в том числе реагирует на внешние сигналы. В контроллере автора софта например заявлена коррекция перемещений на основе данных с энкодеров.
Ну а протоколы в ЧПУ бывают самые разные, начиная от банального StepDir для перемещений и RS485 для управления шпинделем в хоббийных станках и заканчивая специальной реализацией Ethernet и промышленными протоколами в обрабатывающих центрах.
Универсального протокола нет, но под вашу задачу решения точно существуют. Вопрос лишь в том, есть ли они в свободном доступе. Но тут уже Google в помощь.
И всё же меня больше всего волнует вопрос — насколько сильно Вы привзяаны к STM32? Что могло бы Вас заставить использовать MIPS-совместимый контроллер или какой-либо экзотический, но со сравнивыми возможностями.
Для хобби проще всего брать что-то популярное, чтобы было у кого спросить совета или самому найти ответ в интернете. Для бизнеса необходима техподдержка решения.
Поясню свой интерес — как раз для таких (и более сложных решений) планирую предложить ни с чем несовместимый микроконтроллер в ПЛИС. Поэтому Ваше мнение очень важно чтобы хотя бы оценить шансы своего проекта.
ПЛИС, в которую можно зашить нормальный микроконтроллер(зачем, кстати) обойдётся слишком дорого для хобби, а для бизнеса — нужен кто-то за проектом, чтобы ему доверяли.
И попутный вопрос — а как быть с обратной связью? Поддерживает ли синтаксис G-code реагирование на сигналы с датчиков?
В «стандартном» G-code реагировать на события нельзя, реакцию должен обрабатывать софт, который выполняет G-code.
Всё гораздо банальнее — обычное «прозрачное» стекло поглощает свет с длиной волны 10.6мкм(CO2 лазер). В этом диапазоне стекло практически «чёрное».
Ну то есть фокусировка конечно важна, иначе будет не гравировка или резка, а порча материала, но если бы материал отражал или пропускал эту длину волны, то никакая фокусировка бы не спасла.
MSP430F5xxx/MSP430FRxxxx тогда только-только появлялись, и было ещё не понятно взлетит ли серия
Ну а в остальных сериях IMHO нет ничего достаточно интересного или уникального, чтобы брать архитектуру, которая у нас совсем не популярна. Проще взять 32х битные cortex-m, например от stm и радоваться жизни.
То есть btrfs начали разрабатывать за несколько лет до появления docker, а там он оказался не нужен? И Oracle теперь просто по привычке тратит деньги на оплату труда тех, кто разрабатывает btrfs? Мне кажется, что не стоит говорить за всех.
Как вариант, могу сказать что ФС со сжатием может использоваться, например, под хранение Whisper базы от Graphite.
Думаю, что тут дело в том, что используются достаточно узкие определения пар, из-за чего получается, что при покупке, скажем, сушеных кальмаров, вероятность покупки пива около 0.7 (70%), а вот обратное неверно, ибо вместе с пивом многие покупают не кальмаров, а тараньку/чипсы/сухарики/орешки, в результате чего вероятность покупки именно кальмаров уменьшается до неприличных размеров (скажем 0.2-0.4).
С одной стороны, всю закуску можно попробовать загнать в один кластер товаров, и использовать такой кластер в парном анализе, а с другой стороны таранька и кальмары популярны в основном с пивом, а вот чипсы и сухарики популярны ещё и с газировками.
Можно попробовать сделать пересекающиеся кластеры вроде «закуски к пиву» и «закуски к газировкам», но во-первых тогда нужен «эксперт» для подготовки данных(можно и без эксперта, просто по порогу отобрать «перевернутые пары») и обучения машины, а во-вторых придётся менять многие алгоритмы.
В общем, для составления выкладки товара первичность в паре не критична(всё равно рядом класть, да и после парного анализа как раз оптимально прогнать кластеризацию пар, которая и стянет всю закуску к полкам с пивом), а попытка её «починить», может сломать другие пары.
Полагаю, что у Google на валидность SSL-сертификатов есть мониторинг и полностью автоматическая система доставки этих сертификатов на балансировщики, ибо ручками управлять подобными системами нереально.
Собственно говоря, есть вероятность, что и в jQuery не забыли, а просто оттянули замену сертификата на последний момент.
Ну во первых сертификаты подписываются в любое время дня и ночи, там поле позволяет вводить время, а не только дату. Использовать UTC — настоятельная рекомендация. А по поводу времени, кажется рекомендуется использовать гранулярность в одну минуту.
Ну а по поводу почему «в полночь по московскому» — скорее всего просто совпадение.
А вообще именно поэтому рекомендуется обновлять сертификаты заранее, хотя бы за 48 часов, чтобы точно не попасть на проблемы с таймзонами.
Не всё так просто, если брать Win/Mac, то там всё относительно просто, и всё вполне сносно работало ещё со времён появления Python Egg. Проблемы начинаются при попытках собрать что-то под 100500 дистров Linux/*BSD/etc, ибо бинарные пакеты зависят от установленных в систему библиотек.
Если интересно, то вот мой древнющий пост на эту тему, где всё расписано несколько подробнее.
http://video.lmgtfy.com/?q=%D1%80%D1%8B%D0%B1%D0%B0%D0%BB%D0%BA%D0%B0+%D0%BD%D0%B0+%D0%B0%D0%BA%D1%83%D0%BB%D1%83
Бумагу в наше время резать приходится несколько чаще, чем кромсать врагов огромным мачете.
То что через специфический SDK/NDK можно собирать ELF бинарники для Android конечно неплохо, но явно маловато. Я подозреваю, что кучей хаков можно и под десктопный Linux провернуть сборку, раз уж под Android поддержка есть, но всё равно нужно это делать на MS Windows.
Впрочем если там прорвало горячую трубу, то пары часов в такой обстановке гитарам хватит чтобы стать мусором, даже не соприкасаясь с водой напрямую — дерево быстро впитывает влагу из горячего пара.
Есть всего 2 основные причины:
Ну и иногда бывают особые случаи вроде окончания срока жизни компонентов, торговых эмбарго и прочее, но тут обычно выбирают другое, но тоже стандартное решение.
Микроконтроллеры дешевые и работают, а линейки на ядрах ARM Cortex Mx(STM32 — лишь одна линейка от одной компании) — дают огромный выбор периферии, скорости и цен. А проблемы у каждой задачи свои.
G-code — это даже не протокол, это просто некий, относительно универсальный, язык. На этом языке описано что нужно сделать, а вот как именно это сделать в реальном мире решает софт, в том числе реагирует на внешние сигналы. В контроллере автора софта например заявлена коррекция перемещений на основе данных с энкодеров.
Ну а протоколы в ЧПУ бывают самые разные, начиная от банального StepDir для перемещений и RS485 для управления шпинделем в хоббийных станках и заканчивая специальной реализацией Ethernet и промышленными протоколами в обрабатывающих центрах.
Универсального протокола нет, но под вашу задачу решения точно существуют. Вопрос лишь в том, есть ли они в свободном доступе. Но тут уже Google в помощь.
Для хобби проще всего брать что-то популярное, чтобы было у кого спросить совета или самому найти ответ в интернете. Для бизнеса необходима техподдержка решения.
ПЛИС, в которую можно зашить нормальный микроконтроллер(зачем, кстати) обойдётся слишком дорого для хобби, а для бизнеса — нужен кто-то за проектом, чтобы ему доверяли.
В «стандартном» G-code реагировать на события нельзя, реакцию должен обрабатывать софт, который выполняет G-code.
Ну то есть фокусировка конечно важна, иначе будет не гравировка или резка, а порча материала, но если бы материал отражал или пропускал эту длину волны, то никакая фокусировка бы не спасла.
Ну а в остальных сериях IMHO нет ничего достаточно интересного или уникального, чтобы брать архитектуру, которая у нас совсем не популярна. Проще взять 32х битные cortex-m, например от stm и радоваться жизни.
Как вариант, могу сказать что ФС со сжатием может использоваться, например, под хранение Whisper базы от Graphite.
Впрочем лично я не знаю, есть ли там btrfs.
С одной стороны, всю закуску можно попробовать загнать в один кластер товаров, и использовать такой кластер в парном анализе, а с другой стороны таранька и кальмары популярны в основном с пивом, а вот чипсы и сухарики популярны ещё и с газировками.
Можно попробовать сделать пересекающиеся кластеры вроде «закуски к пиву» и «закуски к газировкам», но во-первых тогда нужен «эксперт» для подготовки данных(можно и без эксперта, просто по порогу отобрать «перевернутые пары») и обучения машины, а во-вторых придётся менять многие алгоритмы.
В общем, для составления выкладки товара первичность в паре не критична(всё равно рядом класть, да и после парного анализа как раз оптимально прогнать кластеризацию пар, которая и стянет всю закуску к полкам с пивом), а попытка её «починить», может сломать другие пары.
Собственно говоря, есть вероятность, что и в jQuery не забыли, а просто оттянули замену сертификата на последний момент.
Ну а по поводу почему «в полночь по московскому» — скорее всего просто совпадение.
А вообще именно поэтому рекомендуется обновлять сертификаты заранее, хотя бы за 48 часов, чтобы точно не попасть на проблемы с таймзонами.
Если интересно, то вот мой древнющий пост на эту тему, где всё расписано несколько подробнее.