krufter, наличие ошибок (в особенности в первых ревизиях чипа) — это вполне естественная вещь. Очевидно, что этот факт не отменяет нужности того или иного чипа.
Что касается Мультиклета. У меня 1 вопрос: какова ниша применения?
Все вычислители я для удобства поделю на 3 вида:
1. ЦОС.
В области радиолокации и связи оборонкой широко и почти безальтернативно применяется DSP процессор TigerShark. Его система команд хорошо известна разработчикам, базирована на комплексной алгебре, и имеется груда кода под этот процессор. Бескровное импортозамещение, понятно, возможно только на аналог. Поэтому вне зависимости от перечня ошибок, оборонка будет использовать 1967ВЦ2Ф и 1967ВЦ3Т фирмы Миландр. Первые обкатки этих чипов уже успешно пройдены. Ниша занята.
2. Микроконтроллеры
Тут, пожалуй, мультиклет способен о себе заявить в части отказоустойчевых систем управления (радиационная стойкость?). Но будет сложно, т.к. разработчиков придётся заставить перебераться с полюбленных ARM-ов. К тому же в производстве уже есть отечественные аналоги STM и отладки для них. Так что ниша в 95% применения уже занята. Согласны?
3. Производительные процессоры общего назначения (графика, мультимедиа)
Тут только Эльбрус. Хоть его можно и недолюбливать из-за вполне объективных недостатков, но другого нет. К тому же для него портирован Linux и QNX. Мультиклет, очевидно, по производительности и развитости не претендует на эту нишу.
По всему изложенному повторю вопрос: где мне следует встроить мультиклет и почему? Или так: в каких применениях мультиклет объективно выгоднее чем имеющиеся аналоги?
Дорогие друзья, я искренне поддерживаю исследования в предметной области. НО. Если мы уже заговорили об отечественном заказчике в лице оборонки и прочих стратегических областях… То: хватит предлагать изотерику и оригинальщину. Если кто-либо думает, что у разработчика на предприятии ВПК много свободного времени и желания для изучения «клеток процессора» и способов их настроить «на успех» — сильно ошибается. Дайте разработчикам процессоры «общего назначения», это то что нужно в 99% случаев. Научитесь копировать имеющееся, берите пример с Миландра в части аналогов STM и TS, что, действительно, востребовано. Хотите предложить высокий параллелизм вычислений? Дайте отечественный SoC с ARM-ом и FPGA на борту! Или просто FPGA.
Я очень надеюсь что ошибаюсь, но на мой взгляд Мультиклет — это попытка на хромой козе объехать прогресс. А озвученные архитектурные идеи — скорее предмет исследований, чем коммерческое предложение.
Спасибо за интересную статью!
Действительно, содержать аппаратно-выгребаемый framebuffer — это правильный и во многих случаях удобный способ.
Было бы замечательно увидеть в статье видео с демонстрацией плавных цветовых переходов!
Ой, прошу прощения, ответил комментарием ниже, а перенести никак.
Как говорил, распространённое выражение звучит как Ethernet over USB.
Тоже с ним не очень согласен, но дословный и, на мой взгляд, понятный перевод звучит как в теме.
Не измерял, но обязательно этим займусь и сообщу.
На вскидку могу сказать, что скорость CDC, ранее мной полученная на full speed-е, 8 МБит/с. Хоть она и сильно отличается на разных хостах. Учитывая приключения пакета в стеке и RNDIS драйвере — то можно, думаю, рассчитывать на 4 МБит/с после оптимизации.
Добрый день. Раньше я подключал SIM900. Отправка СМС через него — совсем тривиальная задача.
Если же подключать USB 3G/4G модем к stm32 — это представляется не простым делом. Нужно прикрутить USB-хаб, а контроллеру одновременно работать в режиме хоста (для модема) и устройства (для ПК).
В такой схеме я бы предпочёл использовать одноплатник и Linux.
Дело не в чипе, он тот же. Есть причины по которым не всегда можно использовать Eth PHY. В моём случае — отсутствие соответствующего разъёма в корпусе устройства и возможности внести аппаратные изменения.
В другом случае, почему Ethernet поверх USB актуален — доступно изготовление устройства в форм-факторе usb-stick-а.
Ну а для экспериментаторов с discovery библиотека может быть полезна отсутствием необходимости докупать расширения и подготавливать соответствующий BSP.
Однако, факт санкционирования данных средств «по предназначению» тоже нигде не отмечен. И вряд ли может быть отмечен «по умолчанию», ибо это нарушает принцип неприкосновенности частной жизни.
Так или иначе, спорить не буду, потому что не юрист.
Касательно неприкосновенности, кстати, похоже даже больше подходит: Статья 137 (УК РФ). Нарушение неприкосновенности частной жизни.
Незаконное собирание или распространение сведений о частной жизни лица, составляющих его личную или семейную тайну, без его согласия либо распространение этих сведений в публичном выступлении, публично демонстрирующемся произведении или средствах массовой информации.
Статья-то как раз подходит, дело в другом. С точки зрения прибыли, imaker — чистое добро. Ну а консолидированного противоположного мнения на сцене не присутствует. Так что сидят их юристы без дела…
Статья 273 УК РФ
1. Создание, распространение или использование компьютерных программ либо иной компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты компьютерной информации, — наказываются ограничением свободы на срок до четырех лет, либо принудительными работами на срок до четырех лет, либо лишением свободы на тот же срок со штрафом в размере до двухсот тысяч рублей или в размере заработной платы или иного дохода осужденного за период до восемнадцати месяцев.
В п.2 говорится об отягощении вины, если деяние произвела группа людей.
По существу, «отзеркаливание» трафика — это копирование информации. Вопрос в том, кто это санкционировал.
Здравствуйте. Раньше не задавался вопросом лицензий, т.к. ничего не публиковал.
Я так понял, что LGPL не заставляет открывать производные исходники? Если так, то это, действительно, больше подходит.
Публикация под LGPL не требует получения соответствующего разрешения?
Да, смотрел с самого начала в сторону MTP. Увы, он очень накручен и позволяет работать только с медиа-файлами (картинки, аудио, видео). Бинарник гонять по USB уже нельзя. Хотя сам концепт файл-обмена с «интеллектуальным» устройством — это, казалось бы, то что нужно.
Так же, как аналог F5 в проводнике или Ctrl+R в TotalCommander. Эти действия же не сбрасывают кеш всей системы ) Но перечитать текущий каталог соответствующий драйвер операционки, как правило, заставляют
Заставляют. Только перечитать не физически с диска, а из кеша ФС. Этот кеш содержит набор ранее прочитанных с устройства кластеров. Перечитывать эти кластеры с носителя повторно ОС объективно считает накладным.
Повторно она прочитает кластер с носителя, только если он был исключён из кеша в целях экономия памяти, а пользователю снова понадобятся эти данные. При чём, что интересно, на этом уровне ОС не делает различий между кластерами относящимися к файлу или же к структуре каталога.
Есть такое наблюдение: первое копирование достаточно большого файла/каталога с носителя происходит за минуту, повторное копирование — уже за еденицы секунд при отсутствии на устройстве запросов чтения. Секрет кроется в подсосе из кеша и хитром драйвере :)
Вообще, если получится ОС заставить перечитывать физически кластеры файла (и его содержащего каталога) каждый раз при обращении — это будет полезно для нас. Если у Вас получится — буду рад опыту ;)
Если вкратце, то нет пути засинхронизировать наше устройство с кешем ОС. Поэтому о динамике речи не идёт. Изменения ФС возможны только перед перед её монтированием.
Но в API со стороны хоста же есть обычно команды сброса файлового кеша?
Сброс файлового кеша (flush) заставит вылить на носитель отложенные для записи данные. Что нам не интересно.
Если же сбрасывать кеш всей файловой системы (если это возможно) — то это равносильно перемонтированию ФС или передёргиванию USB, что приведёт к гигантскому накладному расходу, т.к. драйвер ФС тот час же перечитает несколько кластеров (FAT таблица и корень). В этом случае — да, мы можем менять ФС на устройстве в динамике. Но это путь злодея.
как файловые менеджеры в риалтайме(или почти) могут видеть изменения размеров файлов
Двумя способами:
1. Специфическое API нотификации файловой системы.
2. Периодическое чтение файлового каталога с мониторингом изменений.
В обоих случаях работа программы происходит с драйвером ФС и его кешем, и лишь редкий вызов будет транслироваться в реальное чтение носителя.
решить проблему превращением устройства в независимое сетевое
Увы, красивого способа это сделать нет. По причине кеширования ФС операционной системой. Даже если мы изменим ФС на устройстве, вряд ли есть способ сообщить об этом хосту. Повторное чтение файла с устройства с большой вероятностью будет происходить уже из кеша ФС, а не с нашего устройства.
Напрашивающийся выход — это, действительно, CDC интерфейс (COM-порт).
Если Вам понадобится стабильный CDC (или MSC+CDC) для stm32f4 — обращайтесь, было дело, переписывал stm-ый драйвер как раз по причине той самой кривости (отсутствие flow-контроля, гигантизм roll-back буффера, отсутствие обработки кратности bulk-пакета).
Что касается Мультиклета. У меня 1 вопрос: какова ниша применения?
Все вычислители я для удобства поделю на 3 вида:
1. ЦОС.
В области радиолокации и связи оборонкой широко и почти безальтернативно применяется DSP процессор TigerShark. Его система команд хорошо известна разработчикам, базирована на комплексной алгебре, и имеется груда кода под этот процессор. Бескровное импортозамещение, понятно, возможно только на аналог. Поэтому вне зависимости от перечня ошибок, оборонка будет использовать 1967ВЦ2Ф и 1967ВЦ3Т фирмы Миландр. Первые обкатки этих чипов уже успешно пройдены. Ниша занята.
2. Микроконтроллеры
Тут, пожалуй, мультиклет способен о себе заявить в части отказоустойчевых систем управления (радиационная стойкость?). Но будет сложно, т.к. разработчиков придётся заставить перебераться с полюбленных ARM-ов. К тому же в производстве уже есть отечественные аналоги STM и отладки для них. Так что ниша в 95% применения уже занята. Согласны?
3. Производительные процессоры общего назначения (графика, мультимедиа)
Тут только Эльбрус. Хоть его можно и недолюбливать из-за вполне объективных недостатков, но другого нет. К тому же для него портирован Linux и QNX. Мультиклет, очевидно, по производительности и развитости не претендует на эту нишу.
По всему изложенному повторю вопрос: где мне следует встроить мультиклет и почему? Или так: в каких применениях мультиклет объективно выгоднее чем имеющиеся аналоги?
Дорогие друзья, я искренне поддерживаю исследования в предметной области. НО. Если мы уже заговорили об отечественном заказчике в лице оборонки и прочих стратегических областях… То: хватит предлагать изотерику и оригинальщину. Если кто-либо думает, что у разработчика на предприятии ВПК много свободного времени и желания для изучения «клеток процессора» и способов их настроить «на успех» — сильно ошибается. Дайте разработчикам процессоры «общего назначения», это то что нужно в 99% случаев. Научитесь копировать имеющееся, берите пример с Миландра в части аналогов STM и TS, что, действительно, востребовано. Хотите предложить высокий параллелизм вычислений? Дайте отечественный SoC с ARM-ом и FPGA на борту! Или просто FPGA.
Я очень надеюсь что ошибаюсь, но на мой взгляд Мультиклет — это попытка на хромой козе объехать прогресс. А озвученные архитектурные идеи — скорее предмет исследований, чем коммерческое предложение.
Действительно, содержать аппаратно-выгребаемый framebuffer — это правильный и во многих случаях удобный способ.
Было бы замечательно увидеть в статье видео с демонстрацией плавных цветовых переходов!
Как говорил, распространённое выражение звучит как Ethernet over USB.
Тоже с ним не очень согласен, но дословный и, на мой взгляд, понятный перевод звучит как в теме.
На вскидку могу сказать, что скорость CDC, ранее мной полученная на full speed-е, 8 МБит/с. Хоть она и сильно отличается на разных хостах. Учитывая приключения пакета в стеке и RNDIS драйвере — то можно, думаю, рассчитывать на 4 МБит/с после оптимизации.
Если же подключать USB 3G/4G модем к stm32 — это представляется не простым делом. Нужно прикрутить USB-хаб, а контроллеру одновременно работать в режиме хоста (для модема) и устройства (для ПК).
В такой схеме я бы предпочёл использовать одноплатник и Linux.
В другом случае, почему Ethernet поверх USB актуален — доступно изготовление устройства в форм-факторе usb-stick-а.
Ну а для экспериментаторов с discovery библиотека может быть полезна отсутствием необходимости докупать расширения и подготавливать соответствующий BSP.
Так или иначе, спорить не буду, потому что не юрист.
Касательно неприкосновенности, кстати, похоже даже больше подходит:
Статья 137 (УК РФ). Нарушение неприкосновенности частной жизни.
Незаконное собирание или распространение сведений о частной жизни лица, составляющих его личную или семейную тайну, без его согласия либо распространение этих сведений в публичном выступлении, публично демонстрирующемся произведении или средствах массовой информации.
1. Создание, распространение или использование компьютерных программ либо иной компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты компьютерной информации, — наказываются ограничением свободы на срок до четырех лет, либо принудительными работами на срок до четырех лет, либо лишением свободы на тот же срок со штрафом в размере до двухсот тысяч рублей или в размере заработной платы или иного дохода осужденного за период до восемнадцати месяцев.
В п.2 говорится об отягощении вины, если деяние произвела группа людей.
По существу, «отзеркаливание» трафика — это копирование информации. Вопрос в том, кто это санкционировал.
Обновил шапку, большое спасибо за информацию!
Я так понял, что LGPL не заставляет открывать производные исходники? Если так, то это, действительно, больше подходит.
Публикация под LGPL не требует получения соответствующего разрешения?
Собственно хорошо, что напомнили сей факт отметить в шапке исходников, было упущено из виду.
Заставляют. Только перечитать не физически с диска, а из кеша ФС. Этот кеш содержит набор ранее прочитанных с устройства кластеров. Перечитывать эти кластеры с носителя повторно ОС объективно считает накладным.
Повторно она прочитает кластер с носителя, только если он был исключён из кеша в целях экономия памяти, а пользователю снова понадобятся эти данные. При чём, что интересно, на этом уровне ОС не делает различий между кластерами относящимися к файлу или же к структуре каталога.
Есть такое наблюдение: первое копирование достаточно большого файла/каталога с носителя происходит за минуту, повторное копирование — уже за еденицы секунд при отсутствии на устройстве запросов чтения. Секрет кроется в подсосе из кеша и хитром драйвере :)
Вообще, если получится ОС заставить перечитывать физически кластеры файла (и его содержащего каталога) каждый раз при обращении — это будет полезно для нас. Если у Вас получится — буду рад опыту ;)
Сброс файлового кеша (flush) заставит вылить на носитель отложенные для записи данные. Что нам не интересно.
Если же сбрасывать кеш всей файловой системы (если это возможно) — то это равносильно перемонтированию ФС или передёргиванию USB, что приведёт к гигантскому накладному расходу, т.к. драйвер ФС тот час же перечитает несколько кластеров (FAT таблица и корень). В этом случае — да, мы можем менять ФС на устройстве в динамике. Но это путь злодея.
Двумя способами:
1. Специфическое API нотификации файловой системы.
2. Периодическое чтение файлового каталога с мониторингом изменений.
В обоих случаях работа программы происходит с драйвером ФС и его кешем, и лишь редкий вызов будет транслироваться в реальное чтение носителя.
А вот это красиво и современно )
Напрашивающийся выход — это, действительно, CDC интерфейс (COM-порт).
Если Вам понадобится стабильный CDC (или MSC+CDC) для stm32f4 — обращайтесь, было дело, переписывал stm-ый драйвер как раз по причине той самой кривости (отсутствие flow-контроля, гигантизм roll-back буффера, отсутствие обработки кратности bulk-пакета).