Хоть ниже уже довольно подробно объяснили суть принципа, дополню:
Для такой задачи нужен не 1 адрес в условных США, а в идеале несколько и в разных географических точках (например Северная Америка+Южная Америка+Япония уже дадут отличный буст к точности), ибо один адрес даст некоторую область (условно можно принять ее за окружность, но в действительности ее форма будет зависеть от инфраструктуры сетей и поставщиков услуг). Поэтому увеличивается количество адресов и их география, что позволит сузить эту область если не до масштабов города, то до масштабов страны - запросто. Принцип схож с навигацией по ГНСС или радиомаякам. ВПН в этом контексте может сделать ситуацию даже плачевнее, увеличив пинг в разы и сместив/расширив область в "запретные зоны". Так же никто не запрещает зашивать в запрос метку времени, системные локали, раскладки клавиатуры либо другую полезную для сужения зоны поиска информацию.
Ну и самое приятное в этом: вам даже не нужно изгаляться с самим железом, достаточно реализовать это в драйвере (или вспомогательном софте типа Nvidia APP, CUDA и т.п.).
А если вы работаете от батарейки? Есть подозрение, что уводить в сон/будить такой процессор с запущенным Linux энергетически дороже, чем stm с rtos/проприетарным кодом.
Смотрите даташит на количество циклов записи, считаете для своей пиковой нагрузки реальный ресурс. Если ресурса не хватает, а памяти с избытком, то реализуете (или берете готовый, благо реализаций уже много под разные архитектуры написано) механизм выравнивания износа. Самый простой: пишете данные в виде пары "токен-значение", держите таблицу токенов и состояния страниц (активная, заполнена, пустая) для инициализации отдельно в памяти. Пишете данные в одну страницу, при считывании для получения актуальных данных ищете последнюю запись искомого токена в активной странице. После заполнения страницы переносите актуальные пары на другую страницу и продолжаете запись в нее, стираете старую страницу (желательно делать это не сразу, а когда израсходуете текущую, может помочь в случаях когда по какой-либо причине дропнулась запись в активной странице). Таким образом жонглируете несколькими страницами памяти, выравнивая износ и увеличивая общий ресурс. Как и любой другой вариант записи данных чувствителен к падениям питания в моменты записи, но тут если нужно, можно дублировать данные/пытаться прочитать с прошлой записанной страницы.
Кажется ребята из Яндекса (или кто-то вдохновившийся идеей) даже тут на Хабре писали про то как организована загрузка параметров сети на Яндекс станциях с помощью звукового сигнала.
Самое простое приходящее в голову: автомат по продаже пакетов с перчатками (и совком?) для уборки за выгуливаемыми животными. Можно хоть у каждого дома и парка поставить, да и людей с собаками/кошками всегда будет хватать.
Речь-то немного не про то. Просто заявление «дуина медленная» не совсем корректно, ибо медленным является именно код с использованием дуиновских средств разработки. И это нужно держать в уме. Ну и если не хочется отказываться от удобства дуины — паяльник в помощь =)
Ну насчёт лучше, это скорее всего нет, а вот то, что 90+% кода совпадет по итогу — реально. Просто мне, как инженеру АСМ ближе. Естественно речь не об ARM, там С и только местами АСМ.
Я вот честно вообще не понимаю таких заявлений, что дуина медленная. Там те же самые AVR и т.п. и естественно, если хотите выжать максимум, то все упирается в: тактирующий резонатор — это раз, в необходимое количество тактов на команду — это два и минимум мусора в коде — три. Берете АСМ и выжимаете максимум. Просто надо понимать, что есть задачи которые решаются на 51-й серии, а есть требующие серьезных ARM.
З.ы. да я тот динозавр 25 Голиков пишушиший на АСМ(
На мой взгляд у Майков было интереснее решение на win10 mobile, по крайней мере в плане юзабельности. Ну и от задач зависит, Android хоть и достаточно гибок, но для такого сценария предпочту использовать все же полноценные ОС, чем дроид, прикидывающийся таковой.
Если полноценно поддерживает Miracast, то это не очень большая проблема (для меня по крайней мере). Давно взял майковский свисток miracast с HDMI. Единственное ему нужно питание от USB, тут уже либо на самом монике есть, либо любую зарядку можно использовать.
Ему бы полноценный USB, цены б не было. Часто занимаюсь прошивкой МК, обзавелся Win планшетом 10" с 2 полноценными USB в паре с программатором и адаптером на rs-232 вполне удобно использовать, но крупноват. А так путем докупки хаба с внешним питанием и ряда полезных приблуд получается вполне полноценный офисный ПК, плюс при необходимости цепляю полноценный FHD моник по Miracast. Из минусов это конечно атом и тянущиеся за ним ограничения: 2 ГБ ОЗУ, eMMC 16 ГБ (благо хоть microSD карточки на 256 ГБ кушает на ура).
При последовательности: затёр память кода, затёр ПЗУ, залил прошивку, запустил устройство — дамп не снять, если добавить к этому заливку в ПЗУ пустого массива дамп снимается. На форуме производителя тоже нашел человека с такой проблемой, правда комментария от производителя нет.
Переполнения нет, это первым делом и проверил, чтобы началось переполнение надо писать 240+ записей, но на этот случай заранее ограничение написано. Ещё наткнулся на неприятный костыль: что бы считать дамп EEPROM ПЗУ фитоновским программатором приходиться после заливки прошивки принудительно писать в нее пустой массив ( OxFF ) иначе не снимает дамп (отображает как пустой).
На 115200 bps проблем быть не должно, там где кварц позволяет сам использую, правда был один пациент Атмеловский, который с любым кварцем выше 9600 bps не прыгал. На отечественном 1882ВЕ53У столкнулся с другой белой: стояла задача хранить n записей (по 8 байт каждая) в EEPROM ПЗУ с использованием сдвига при получении новой записи. При постраничной записи возникла проблема, начиная с 4-й записи в последний байт каждой записи пишется ересь (причем везде одинаковая). Использовать побайтовую запись желания нет, ибо время на "перетасовку" и длинна кода вырастает до неприличного. Пробовал просто писать по тем же адресам как страницы заранее заготовленные, так и побайтово — все корректно отрабатывается. Есть мысли с чем это может быть связано?
Хоть ниже уже довольно подробно объяснили суть принципа, дополню:
Для такой задачи нужен не 1 адрес в условных США, а в идеале несколько и в разных географических точках (например Северная Америка+Южная Америка+Япония уже дадут отличный буст к точности), ибо один адрес даст некоторую область (условно можно принять ее за окружность, но в действительности ее форма будет зависеть от инфраструктуры сетей и поставщиков услуг). Поэтому увеличивается количество адресов и их география, что позволит сузить эту область если не до масштабов города, то до масштабов страны - запросто. Принцип схож с навигацией по ГНСС или радиомаякам. ВПН в этом контексте может сделать ситуацию даже плачевнее, увеличив пинг в разы и сместив/расширив область в "запретные зоны". Так же никто не запрещает зашивать в запрос метку времени, системные локали, раскладки клавиатуры либо другую полезную для сужения зоны поиска информацию.
Ну и самое приятное в этом: вам даже не нужно изгаляться с самим железом, достаточно реализовать это в драйвере (или вспомогательном софте типа Nvidia APP, CUDA и т.п.).
По величине пинга до известных адресов вполне с допустимой погрешностью можно оценить местоположение железки и никакие ВПН не помогут.
А если вы работаете от батарейки? Есть подозрение, что уводить в сон/будить такой процессор с запущенным Linux энергетически дороже, чем stm с rtos/проприетарным кодом.
Смотрите даташит на количество циклов записи, считаете для своей пиковой нагрузки реальный ресурс. Если ресурса не хватает, а памяти с избытком, то реализуете (или берете готовый, благо реализаций уже много под разные архитектуры написано) механизм выравнивания износа. Самый простой: пишете данные в виде пары "токен-значение", держите таблицу токенов и состояния страниц (активная, заполнена, пустая) для инициализации отдельно в памяти. Пишете данные в одну страницу, при считывании для получения актуальных данных ищете последнюю запись искомого токена в активной странице. После заполнения страницы переносите актуальные пары на другую страницу и продолжаете запись в нее, стираете старую страницу (желательно делать это не сразу, а когда израсходуете текущую, может помочь в случаях когда по какой-либо причине дропнулась запись в активной странице). Таким образом жонглируете несколькими страницами памяти, выравнивая износ и увеличивая общий ресурс. Как и любой другой вариант записи данных чувствителен к падениям питания в моменты записи, но тут если нужно, можно дублировать данные/пытаться прочитать с прошлой записанной страницы.
Ничего та статья не проясняет. Там попытка юристов натянуть сову на глобус.
Кажется ребята из Яндекса (или кто-то вдохновившийся идеей) даже тут на Хабре писали про то как организована загрузка параметров сети на Яндекс станциях с помощью звукового сигнала.
EDIT: нашел ссылку, надеюсь пригодится
https://habr.com/ru/articles/470293/
Самое простое приходящее в голову: автомат по продаже пакетов с перчатками (и совком?) для уборки за выгуливаемыми животными. Можно хоть у каждого дома и парка поставить, да и людей с собаками/кошками всегда будет хватать.
P.S. если выстрелит хоть спасибо скажите :)
З.ы. да я тот динозавр 25 Голиков пишушиший на АСМ(
На мой взгляд у Майков было интереснее решение на win10 mobile, по крайней мере в плане юзабельности. Ну и от задач зависит, Android хоть и достаточно гибок, но для такого сценария предпочту использовать все же полноценные ОС, чем дроид, прикидывающийся таковой.
Если полноценно поддерживает Miracast, то это не очень большая проблема (для меня по крайней мере). Давно взял майковский свисток miracast с HDMI. Единственное ему нужно питание от USB, тут уже либо на самом монике есть, либо любую зарядку можно использовать.
Ему бы полноценный USB, цены б не было. Часто занимаюсь прошивкой МК, обзавелся Win планшетом 10" с 2 полноценными USB в паре с программатором и адаптером на rs-232 вполне удобно использовать, но крупноват. А так путем докупки хаба с внешним питанием и ряда полезных приблуд получается вполне полноценный офисный ПК, плюс при необходимости цепляю полноценный FHD моник по Miracast. Из минусов это конечно атом и тянущиеся за ним ограничения: 2 ГБ ОЗУ, eMMC 16 ГБ (благо хоть microSD карточки на 256 ГБ кушает на ура).
При последовательности: затёр память кода, затёр ПЗУ, залил прошивку, запустил устройство — дамп не снять, если добавить к этому заливку в ПЗУ пустого массива дамп снимается. На форуме производителя тоже нашел человека с такой проблемой, правда комментария от производителя нет.
Переполнения нет, это первым делом и проверил, чтобы началось переполнение надо писать 240+ записей, но на этот случай заранее ограничение написано. Ещё наткнулся на неприятный костыль: что бы считать дамп EEPROM ПЗУ фитоновским программатором приходиться после заливки прошивки принудительно писать в нее пустой массив ( OxFF ) иначе не снимает дамп (отображает как пустой).
На 115200 bps проблем быть не должно, там где кварц позволяет сам использую, правда был один пациент Атмеловский, который с любым кварцем выше 9600 bps не прыгал. На отечественном 1882ВЕ53У столкнулся с другой белой: стояла задача хранить n записей (по 8 байт каждая) в EEPROM ПЗУ с использованием сдвига при получении новой записи. При постраничной записи возникла проблема, начиная с 4-й записи в последний байт каждой записи пишется ересь (причем везде одинаковая). Использовать побайтовую запись желания нет, ибо время на "перетасовку" и длинна кода вырастает до неприличного. Пробовал просто писать по тем же адресам как страницы заранее заготовленные, так и побайтово — все корректно отрабатывается. Есть мысли с чем это может быть связано?