No problem. Сделайте модель рельефа лучше, чем у NASA, придумайте алгоритм фильтрации, который подходит всем (не только в абсолютно плоской Мещере, но в Альпах с Гималаями), и смело продавайте. Хоть в страву, хоть в оллтрейлс.
Принудиловка-то зачем?!
По факту, если ты реально заморачиваешься, и у тебя есть деньги - купи девайс подороже, с приличным приёмом спутников и барометром. Оно работает достаточно хорошо (на порядок точнее цифровой модели). Данные по высоте из трека умеют использовать и показывать все сервисы (если принудительно их оттуда не вырезать, вооружившись бубном).
На самом деле, всё полностью наоборот: барометр - благо.
Из карты, наверное, ни одно из устройств высоту в трек не пишет (это уже пост-обработка в спец-софте или в разнообразных "соцсетях для спортсменов"), только по показаниям GPS. И показания GPS имеют свойство "дрожать" из-за неидельного приёма. Там, конечно, есть фильтры, но помогают они плохо - только от совсем резких скачков.
А вот если добавить к высоте от спутников показания барометра, и правильно завести оба сигнала на фильтр, получается довольно красиво - медленные изменения давления игнорируются по среднему значению высоты со спутников, быстрые "иголки" от выбросов GPS - игнорируются по медленно меняющимся данным барометра.
Возможно, edge на паузе выключает приёмник (я не настолько спортсмен, у меня edge нету), и потом заново инициализирует фильтр. Во всяком случае, Garmin GPSmap62 / 64 с барометром рисует высотный график ГОРАЗДО лучше, чем такой же прибор без барометра.
Велосипедом можно повредить колени, если постоянно прикладывать слишком большое усилие к педалям. Решение - крутить быстрее (до сотни об/мин) с пропорциональным снижением усилия. Если интересно - скорость вращения называется "каденс", можно погуглить. Ну и неудачной встречей с препяствиями можно много чего повредить, к сожалению...
В порядке неконструктивной критики: - буковки (полезные) - маленькие, картинки (бесполезные, но иногда прикольные) - большие. Хочу наоборот. Иначе при листании остаются один картинки, буквы визуально искать надо. - возможно, хочу больше буков. Т.е. не одно слово на карточку, а сразу несколько. Но получается неканонично (одно слово - одна карточка, так надо?). - идея "приткнуть дза/дже хоть куда-нибудь" - плохая. Мне б сначала основные буквы выучить... - телеграм для подобной штуки в принципе плохо подходит. Сюда б веб или приложеньице какое, да с адекватной вёрсткой... Но это я совсем наглею - веб с вёрсткой несовместим с главной идеей "сделал по фану на коленке за два вечера".
Впрочем, кажется мне, действенный способ изучения языка - поднять попу и целенаправленно заниматься, а не телеграм-каналы листать :-)
Подскажите пожалуйста, как приглашение выглядело? У меня есть реальное приглашение от реального армянского работодателя, с подписями-печатями, но это приглашение, а не контракт. Стрёмно это, оказаться запертым на границе с семьей и кучей барахла...
(сразу скажу, что нашёл только даташит на китайском языке и поленился переводить, только картинки посмотрел)
Я не понял, о чём вы говорите. Никаких намёков на индуктивность не видно - ни в этом поделии, ни в даташите. Здравый смысл требует ограничивать ток через диоды, не скважность шима. Даташит тоже рисует графики стабилизации тока.
Кроме того, мы видим параллельное соединение драйверов, что для импульсников требует хитроумных средств синхронизации.
Там у гугля чуть дальше более интересная ссылка есть: https://ura.news/articles/1036267241 (внезапно, 6 лет назад ura.ru было совсем не таким изданием, как сегодня). Фееричная барышня.
Это я пытался (несмешно) каламбурить над созвучностью слов "топ" и "фгуп". Перспективы людей, которые занимались всеми этими верилогами, довольно туманны. Если при этом не хочется связываться с организациями, в которых важную роль играет первый отдел - так вообще ОЧЕНЬ туманны...
У меня со времен битвы Жарова с Дуровым есть личная виртуалка с shadowsocks (и да, это работает), но с такой активностью она легко может превратиться в тыкву...
Кажется мне, на фотке в посте дорожки от чипа влево-вниз (с резисторами R57, R58, ...) и на "изнанку" платы - это джитаг и есть. По крайней мере, пины джитага в этом углу чипа находятся. Так что остался только вопрос нужного адаптера и софтины для этих МИПСов (ну и провода в нужном порядке припаять...).
Из прочтения кода стало даже чуть понятнее, что происходит. Заодно прочитал, что такое posix cksum, без этого знания понять исходник невозможно (вы где-то укра.. позаимствовали реализацию? Не знаю, насколько большим оригиналом надо быть, чтобы использовать восьмеричную!!! константу 0o377).
Сравнил вашу картинку с гидрой и карту памяти похожего чипа (стр.13). Там что получается, загрузчик тоже использует MMU ? Вы и таблицу трансляции расковырять успели? UPD. Нашёл правильный документ, в нём таблица адресов совпадает с вашей.
Экскурс в психологию занятный. В смежной теме наблюдал что-то похожее. Подход "моя прелесссть", и нежелание делиться со всякими там халявщиками хоть какой-то полезной информацией.
Собственно, ближе к теме. Мне что-то не нравится, как гидра разобрала вызовы функций. Выложите бинарник, пожалуйста, охота посмотреть, как там что в MIPS устроено.
PS в качестве второго введения могли бы написать, чем эти роутеры так замечательны. Неочевидно, чем оно лучше какого-нибудь тп-линка. Чем хуже (официально продаётся в комплекте с подключением билайна) - понятно.
у меня понимание такого низкого уровня уже сломалось.
Удивительно. Человек, который пишет приличный (имхо) шаблонный код и умеет пользоваться IDA - и такая странная дырка в знаниях. Наверное, это от их избытка - было б поменьше, просто б не задумывались, оно б "само" работало :-)
доступ к flash-памяти из программы прозрачен и не отличается от доступа к участку RAM?
В случае кортексов - да, абсолютно прозрачен и никак не отличается от доступа к ОЗУ (ну, если не писать туда ничего и не заниматься тщательными измерениями "сколько тактов занимает чтение"). На уровне ассемблера это одни и те же инструкции, только разные адреса. На уровне Си/Си++ - во всех заготовках стартового кода (стартап, скрипт линкера) сделано так, чтобы RW переменные ложились в ОЗУ, RO - только во флеш.
Если чуть подробнее, то для переменных Си/С++ есть возможны три варианта - неинициализированные не-const переменные кладутся в секцию BSS, инициализированные не-const переменные кладутся в секцию DATA, const перменные (они, очевидно, все инициализированы) кладутся в секцию RODATA.
В промежутке между стартом контроллера и началом main() выполняется маленький кусочек кода (в случае gcc он обычно весь в одном исходном файле), который обнуляет BSS (ассемблерной вставкой или вызовом memset) и копирует DATA из флеша в ОЗУ (также ассемблерной вставкой или обычным memcpy). В случае RODATA никаких копирований нет, код сразу работает с данными во флеш.
Это не совсем так. Если мы говорим о STM32F1xx (не F7 и более быстрых процессорах) и о внутренней SRAM (а не о внешней SDRAM, про которую статья по вашей ссылке), там нет никаких задержек, память работает на частоте ядра.
Но, с другой стороны, скорость работы внутренней флеш - максимум 24 МГц, при больших скоростях ядра надо конфигурировать контроллер, чтобы он вставлял циклы ожидания при обращении к ней. Чтобы эта конструкция не ОЧЕНЬ тормозила, есть микро-кэш: два 64-битных буфера. Каждое чтение флеш заполняет один из них (все 64 бита за раз). Для линейного кода, который не читает никаких констант, оно работает нормально. Но это сферический код в вакууме, и на хаотичные прыжки по коду эта конструкция отреагирует плохо.
можно ли статический массив разместить во Flash, а доступ к нему получать в runtime?
Или я не понял вопрос, или у вас компилятор (скрипт линкера) сломался. Потому что на мелких армах банальный `const int arr[42] = {1,2,3}` с настройками компилятора по умолчанию ляжет во флешку.
Вот, например, в ATMega это не так - там гарвардская архитектура, и "память по умолчанию" - это ОЗУ. Чтобы переменная легла в ПЗУ, нужны магические заклинания.
Также по-другому могут работать "большие" армы - всякие cortex-a. Там, слава фон-Нейману, адресное пространство единое, но программа зачастую копируется целиком из ПЗУ в ОЗУ при старте и уже оттуда исполняется.
Ну, написать threadsafe код, который будет работать на любой, заранее неизвестной, ОС (у нас же baremetal, RTOS у каждого своя любимая), задача нетривиальная. Т.е. штуки, которые не трогают глобальные объекты (тот же memcpy и strlen), по умолчанию работают хорошо. printf тоже по идее должен быть без глобального буфера (ну да, будет putchar по каждому поводу дёргать). Вот malloc и free придётся самому делать, чтоб они знали, как именно в данной ОС принято делать критические секции и прочие мютексы.
PS полез почитать, чем всё-таки отличается newlib-nano из gcc none-aebi с arm.com. И не нашёл. В исходниках есть общее описание, но что конкретно выложено на arm.com, надо отдельно разбираться...
Какие альтернативы? Вы предлагаете делать свой велосипед? Так он будет наверняка кривее и наверняка больше.
К слову, в embedded компиляторах (точнее, линкерах) есть способы "обезжиривания" stdlib. Для gcc, который во флиппере, есть ключик -specs=nano.specs, который подключает меньшую библиотеку (особым образом собранная gcc'шная newlib, список отличий сейчас сходу не найду). Для IAR и Keil также есть отдельные переключатели в настройках проекта, которые указывают, какие библиотеки использовать.
Кстати, @Andrey2008, вы в курсе, что не всякий embedded printf/scanf умеет все возможные опции форматирования? Если вы умеете вытягивать из среды настройки линкера, можно проверять ещё и это. Я один раз на это наступил (правда, там был самодельный sprintf, вы про такой точно не знаете :-) ).
Какое-то странное желание ходить строем.
No problem. Сделайте модель рельефа лучше, чем у NASA, придумайте алгоритм фильтрации, который подходит всем (не только в абсолютно плоской Мещере, но в Альпах с Гималаями), и смело продавайте. Хоть в страву, хоть в оллтрейлс.
Принудиловка-то зачем?!
По факту, если ты реально заморачиваешься, и у тебя есть деньги - купи девайс подороже, с приличным приёмом спутников и барометром. Оно работает достаточно хорошо (на порядок точнее цифровой модели). Данные по высоте из трека умеют использовать и показывать все сервисы (если принудительно их оттуда не вырезать, вооружившись бубном).
На самом деле, всё полностью наоборот: барометр - благо.
Из карты, наверное, ни одно из устройств высоту в трек не пишет (это уже пост-обработка в спец-софте или в разнообразных "соцсетях для спортсменов"), только по показаниям GPS. И показания GPS имеют свойство "дрожать" из-за неидельного приёма. Там, конечно, есть фильтры, но помогают они плохо - только от совсем резких скачков.
А вот если добавить к высоте от спутников показания барометра, и правильно завести оба сигнала на фильтр, получается довольно красиво - медленные изменения давления игнорируются по среднему значению высоты со спутников, быстрые "иголки" от выбросов GPS - игнорируются по медленно меняющимся данным барометра.
Возможно, edge на паузе выключает приёмник (я не настолько спортсмен, у меня edge нету), и потом заново инициализирует фильтр. Во всяком случае, Garmin GPSmap62 / 64 с барометром рисует высотный график ГОРАЗДО лучше, чем такой же прибор без барометра.
Велосипедом можно повредить колени, если постоянно прикладывать слишком большое усилие к педалям. Решение - крутить быстрее (до сотни об/мин) с пропорциональным снижением усилия. Если интересно - скорость вращения называется "каденс", можно погуглить.
Ну и неудачной встречей с препяствиями можно много чего повредить, к сожалению...
Мерси шат! Прикольная штука получилась.
В порядке неконструктивной критики:
- буковки (полезные) - маленькие, картинки (бесполезные, но иногда прикольные) - большие. Хочу наоборот. Иначе при листании остаются один картинки, буквы визуально искать надо.
- возможно, хочу больше буков. Т.е. не одно слово на карточку, а сразу несколько. Но получается неканонично (одно слово - одна карточка, так надо?).
- идея "приткнуть дза/дже хоть куда-нибудь" - плохая. Мне б сначала основные буквы выучить...
- телеграм для подобной штуки в принципе плохо подходит. Сюда б веб или приложеньице какое, да с адекватной вёрсткой... Но это я совсем наглею - веб с вёрсткой несовместим с главной идеей "сделал по фану на коленке за два вечера".
Впрочем, кажется мне, действенный способ изучения языка - поднять попу и целенаправленно заниматься, а не телеграм-каналы листать :-)
Подскажите пожалуйста, как приглашение выглядело? У меня есть реальное приглашение от реального армянского работодателя, с подписями-печатями, но это приглашение, а не контракт. Стрёмно это, оказаться запертым на границе с семьей и кучей барахла...
Вот вам смешно, а мне в наследство достался реальный проект, в котором
typedef enum { BOOL_FALSE = 0, BOOL_TRUE = 1, BOOL_ERROR = 2,}BOOLEAN;
(сразу скажу, что нашёл только даташит на китайском языке и поленился переводить, только картинки посмотрел)
Я не понял, о чём вы говорите. Никаких намёков на индуктивность не видно - ни в этом поделии, ни в даташите. Здравый смысл требует ограничивать ток через диоды, не скважность шима. Даташит тоже рисует графики стабилизации тока.
Кроме того, мы видим параллельное соединение драйверов, что для импульсников требует хитроумных средств синхронизации.
Линейник это, без вариантов.
Там у гугля чуть дальше более интересная ссылка есть: https://ura.news/articles/1036267241 (внезапно, 6 лет назад ura.ru было совсем не таким изданием, как сегодня). Фееричная барышня.
Это я пытался (несмешно) каламбурить над созвучностью слов "топ" и "фгуп". Перспективы людей, которые занимались всеми этими верилогами, довольно туманны. Если при этом не хочется связываться с организациями, в которых важную роль играет первый отдел - так вообще ОЧЕНЬ туманны...
Боюсь, куда бОльшая вероятность увидеть VHDL в ФГУПе...
Коллеги, напишите пожалуйста актуальный обзор впнов.
У меня со времен битвы Жарова с Дуровым есть личная виртуалка с shadowsocks (и да, это работает), но с такой активностью она легко может превратиться в тыкву...
Кажется мне, на фотке в посте дорожки от чипа влево-вниз (с резисторами R57, R58, ...) и на "изнанку" платы - это джитаг и есть. По крайней мере, пины джитага в этом углу чипа находятся. Так что остался только вопрос нужного адаптера и софтины для этих МИПСов (ну и провода в нужном порядке припаять...).
О, спасибо. Вместо тысячи слов, так сказать :-)
Из прочтения кода стало даже чуть понятнее, что происходит. Заодно прочитал, что такое posix cksum, без этого знания понять исходник невозможно (вы где-то укра.. позаимствовали реализацию? Не знаю, насколько большим оригиналом надо быть, чтобы использовать восьмеричную!!! константу 0o377).
Сравнил вашу картинку с гидрой и карту памяти похожего чипа (стр.13). Там что получается, загрузчик тоже использует MMU ? Вы и таблицу трансляции расковырять успели? UPD. Нашёл правильный документ, в нём таблица адресов совпадает с вашей.
Экскурс в психологию занятный. В смежной теме наблюдал что-то похожее. Подход "моя прелесссть", и нежелание делиться со всякими там халявщиками хоть какой-то полезной информацией.
Собственно, ближе к теме. Мне что-то не нравится, как гидра разобрала вызовы функций. Выложите бинарник, пожалуйста, охота посмотреть, как там что в MIPS устроено.
PS в качестве второго введения могли бы написать, чем эти роутеры так замечательны. Неочевидно, чем оно лучше какого-нибудь тп-линка. Чем хуже (официально продаётся в комплекте с подключением билайна) - понятно.
Я правильно нагуглил https://sk.skolkovo.ru/storage/file_storage/4b954252-7c3d-4975-94e3-910612e77464/SKOLKOVO_SEDeC_Atlas_2.0.pdf ?
Или ещё более трешовое издание существует?
Удивительно. Человек, который пишет приличный (имхо) шаблонный код и умеет пользоваться IDA - и такая странная дырка в знаниях. Наверное, это от их избытка - было б поменьше, просто б не задумывались, оно б "само" работало :-)
В случае кортексов - да, абсолютно прозрачен и никак не отличается от доступа к ОЗУ (ну, если не писать туда ничего и не заниматься тщательными измерениями "сколько тактов занимает чтение"). На уровне ассемблера это одни и те же инструкции, только разные адреса. На уровне Си/Си++ - во всех заготовках стартового кода (стартап, скрипт линкера) сделано так, чтобы RW переменные ложились в ОЗУ, RO - только во флеш.
Если чуть подробнее, то для переменных Си/С++ есть возможны три варианта - неинициализированные не-const переменные кладутся в секцию BSS, инициализированные не-const переменные кладутся в секцию DATA, const перменные (они, очевидно, все инициализированы) кладутся в секцию RODATA.
В промежутке между стартом контроллера и началом main() выполняется маленький кусочек кода (в случае gcc он обычно весь в одном исходном файле), который обнуляет BSS (ассемблерной вставкой или вызовом memset) и копирует DATA из флеша в ОЗУ (также ассемблерной вставкой или обычным memcpy). В случае RODATA никаких копирований нет, код сразу работает с данными во флеш.
Это не совсем так. Если мы говорим о STM32F1xx (не F7 и более быстрых процессорах) и о внутренней SRAM (а не о внешней SDRAM, про которую статья по вашей ссылке), там нет никаких задержек, память работает на частоте ядра.
Но, с другой стороны, скорость работы внутренней флеш - максимум 24 МГц, при больших скоростях ядра надо конфигурировать контроллер, чтобы он вставлял циклы ожидания при обращении к ней. Чтобы эта конструкция не ОЧЕНЬ тормозила, есть микро-кэш: два 64-битных буфера. Каждое чтение флеш заполняет один из них (все 64 бита за раз). Для линейного кода, который не читает никаких констант, оно работает нормально. Но это сферический код в вакууме, и на хаотичные прыжки по коду эта конструкция отреагирует плохо.
Или я не понял вопрос, или у вас компилятор (скрипт линкера) сломался. Потому что на мелких армах банальный `const int arr[42] = {1,2,3}` с настройками компилятора по умолчанию ляжет во флешку.
Вот, например, в ATMega это не так - там гарвардская архитектура, и "память по умолчанию" - это ОЗУ. Чтобы переменная легла в ПЗУ, нужны магические заклинания.
Также по-другому могут работать "большие" армы - всякие cortex-a. Там, слава фон-Нейману, адресное пространство единое, но программа зачастую копируется целиком из ПЗУ в ОЗУ при старте и уже оттуда исполняется.
Ну, написать threadsafe код, который будет работать на любой, заранее неизвестной, ОС (у нас же baremetal, RTOS у каждого своя любимая), задача нетривиальная.
Т.е. штуки, которые не трогают глобальные объекты (тот же memcpy и strlen), по умолчанию работают хорошо. printf тоже по идее должен быть без глобального буфера (ну да, будет putchar по каждому поводу дёргать). Вот malloc и free придётся самому делать, чтоб они знали, как именно в данной ОС принято делать критические секции и прочие мютексы.
PS полез почитать, чем всё-таки отличается newlib-nano из gcc none-aebi с arm.com. И не нашёл. В исходниках есть общее описание, но что конкретно выложено на arm.com, надо отдельно разбираться...
Какие альтернативы? Вы предлагаете делать свой велосипед? Так он будет наверняка кривее и наверняка больше.
К слову, в embedded компиляторах (точнее, линкерах) есть способы "обезжиривания" stdlib. Для gcc, который во флиппере, есть ключик
-specs=nano.specs, который подключает меньшую библиотеку (особым образом собранная gcc'шная newlib, список отличий сейчас сходу не найду). Для IAR и Keil также есть отдельные переключатели в настройках проекта, которые указывают, какие библиотеки использовать.Кстати, @Andrey2008, вы в курсе, что не всякий embedded printf/scanf умеет все возможные опции форматирования? Если вы умеете вытягивать из среды настройки линкера, можно проверять ещё и это. Я один раз на это наступил (правда, там был самодельный sprintf, вы про такой точно не знаете :-) ).