Чарлиплексинг я упомянул, как один из возможных вариантов, вовсе не подразумевая, что он негоден. Не упомянул его преимущество (теоретически, проверять все же надо) возможности отказаться от токоограничивающих резисторов для LED, т.к. их питание пойдет в импульсном режиме. И подрастет код (сейчас 96% кристалла), задача уместить не выглядит невозможной, но это будет уже иная конструкция.
Дефайны PERIOD_0 — PERIOD_7 используются только при инициализации массива состояний traffic_signals[], и я счел более важным их наименованием подчеркнуть небесспорный и неочевидный момент: номера в массиве используются в коде. Перемещение их на другие места не допускается. Переименовывание их в предложенный вариант — потеря информации. Конечно, можно сохранить отсылку к нумерации и добавить информацию о цветах режима.
#define PERIOD_0_RED_GREEN ONE_SECOND * 10 //R G R G (10 сек)
Но нормальная IDE при наведении курсора на дефайн показывает и его значение, и комментарий рядом.
Только что проверил: при компиляции с флагом -O0 (без оптимизации) размер прошивки с глобальной переменной 78 байт, с локальной 58.
При оптимизации по размеру (-Os) 60 байт и 40 соответственно.
Дизассемблирование показывает — куда уходит память, слева — вариант с глобальной переменной.
Верно, не акцентировал внимания, исправляюсь.
Квалификатор volatile не только компилятору запрещает кешировать переменную в регистре, но и накладывает обязательство на автора программы — рассмотреть последствия возможных изменений.
Здесь volatile только переменная глобального таймера, основной цикл выполняется за время многократно меньшее промежутка её инкремента от переполнения, а выполнение цикла инициируется её изменением от старта прерывания переполнения счетчика.
А вот при просыпании из POWER_DOWN_MODE, хотя она обнуляется, но таймер не реинициализируется, и, естественно, её значение может скакнуть в любой момент.
Последствиями будет возможное изменение периода самого первого после просыпания сигнала на дельту времени до 1/37 секунды. (Или до 1/64, если выполняется на МК с частотой 16МГц).
Критической проблема может стать, если случится переполнение целого беззнакового, uint16_t из 65535 превратится в 0: вся логика сравнений превратится в тыкву. Для недопущения этого при достижении безопасного порога в половину максимально возможного значения типа переменной в самом начале основного цикла идет корректировка глобального таймера и значений, которые с ним сравниваются.
#define MAX_GLOBAL_TIMER_VALUE (USHRT_MAX / 2) // uint16_t globalTimer - защита от переполнения. 65535 /2
// любой период должен быть меньше, чем MAX_GLOBAL_TIMER_VALUE - 1
...
// переполнение глобального таймера?
if(globalTimer > MAX_GLOBAL_TIMER_VALUE){
globalTimer -= MAX_GLOBAL_TIMER_VALUE; // откатить глобальный таймер
...
Так и есть.
В процессе заводских испытаний было принято к устранению замечание Представителя Заказчика о недостаточной частоте моргания.
Обоснование отступления от ГОСТа и внесения изменений в программный код программно-аппаратного комплекса железобетонное: "Папа, я так хочу".
Косяк. Обидно, что давно исправленный, в "./schematic/traffic light ver0.dch" схема верная, вот такая.
А в скриншотах к статье пропустил давнюю, неисправленную.
Предположу, Вы о ремарке Утащить внутрь функции main глобальные переменные — каждая глобальная переменная в С — примерно +50 байт требуемого ROM..
Очень подозреваю, что результат AtmelStudio вряд ли сильно будет отличаться от GCC, рост расхода памяти с глобальными переменными в сравнении с локальными не обусловлен конкретным тулчейном.
Самому любопытно, и буду благодарен, если кто-то проведет эксперимент по компиляции под AtmelStudio и в комментарии расскажет результаты.
Сдвиговый регистр?
Для иллюстративной самодельной игрушки, занимательной головоломки, как видите, он не требуется.
Для (предположим) схемы серийного производства игрушки, не то что добавлять регистр, а от 6 токоограничивающих резисторов избавлялся бы — при импульсной схеме питания светодиодов они не необходимы, а каждая точка пайки, не говоря о стоимости самого элемента, это постоянные расходы.
Пневмопривод, годный к распечатке на бытовом 3D принтере.
Причем, двунаправленный — и как перевод давления во вращательный момент, и, как нагнетатель давления от вала отбора мощности.
Для микро-роботов пневматические приводы интересны — пневмоманипуляторы обеспечивают и гибкость, и регулируемую силу захвата, но требуют наличия пневмосистемы.
Просто на шасси компрессор не воткнешь. И электропневмоклапана — это и громоздко, и тяжело, и амперы кушает только в путь
А в этом варианте давление в пневмосистеме легко регулируется — банальный ШИМ на моторчике. На алибабе полно дешевых и маленьких датчиков давления.
И вместо отдельных клапанов — можно легко делать отдельные пневмосистемы, каждая со своим регулируемым по проводам «компрессором».
И сами клапана — или даже газовые редукторы с управляемым оборотами давлением — на том же принципе — так же возможны.
В ЕС действуют универсальные ограничения на длину седельного автопоезда (тягач + полуприцеп) — 16.5 м, а также на габариты полуприцепа — 12 м от оси седельного сцепного устройства (ССУ) до задней части и не более 2.04 м до любой точки передней части.
Поэтому капотники не прижились.
Проецирование подсказок на стекло как в фантастических фильмах.
Попробовал перечислить возможные технологии.
1. Отражение в лобовом стекле зеркального изображения на экране планшета/телефона.
Уже есть во многих навигационных программах на андроиде — положив телефон на торпеду, в стекле видно его отображение.
(+) всегда в фокусе;
(+) не требует приобретения отдельного hw;
(-) размер проецируемой области — примерно равен размеру экрана;
(-) есть искажения — отражающая поверхность имеет кривизну, но не сильно большие, из-за небольших размеров экранов носимых устройств.
2. Использование HUD.
«Как в истребителях», есть предложения на рынке.
(+) плоская поверхность отражателя не дает искажений;
(+) большой диапазон регулировки по яркости;
(-) необходимо специальное дополнительное довольно громоздкое устройство, на торпеду не любого автомобиля подойдет.
3. Проектор.
Проецирование видеосигнала, как в настенном проекторе.
(-) крайне сложная поверхность линз оптической схемы объектива, компенсирующее отражения от криволинейного лобового стекла и обеспечивающее изображения «в фокусе» по всему полю.
4. Изображение, формируемое лазером.
Тема статьи. Можно использовать поляризованную пленку — чтобы лазер не улетал через стекло. Не используя — всего лишь потеряется яркость.
(+) изображение в фокусе по всему полю и оптические искажения несложно компенсировать программным способом;
(+) небольшие габариты устройства;
(+) возможность использования и с существующими или с штатными системами автонавигации, как VDO Dayton, у которых рекомендации по перестроению выводятся в фиксированную область экрана при вождении;
(+) высокая яркость (естественно она может регулироваться)
(-) монохромность;
5. MEMS лазерное сканирование — проецирование.
Только одну фирму нашел, которая делает такие чипы — MicroVision. Два продукта: лазерный проектор для iPhone «MicroVision SHOWWX» (б/у $200) и лазерный проектор Сони на той же технологии «Sony MP-CL1» — на технологии PicoP.
Все плюсы четвертого пункта и в полноцвете.
Но MicroVision хотят пойти гораздо дальше.
Их решение навигации для авто обещает работать в дополненной реальности.
Вариант когда само лобовое стекло является экраном — не стал добавлять. Теоретически — возможно, однако технологичность выступает за рамки разумного.
Т.о. получаем, что очень близки к прорыву лазерные проецирующие технологии.
Слой на стекле, который отражает лазер — т.е. либо фильтр по конкретному цвету, либо по поляризации — необходим для удобства дневной видимости — чтобы не наращивать мощность лазера для обеспечения контраста.
Нигде пока что не видел упоминаний о технологии напыления поляризованной пленки на стекло.
А жаль, брызнул из баллончика — и у тебя экран поляризованный сразу есть.
Как реализовано в исходниках — сие мне не известно.
Формат закрытый, нигде не описываемый, инструментарий для работы с данными есть только у производителя.
Именно поэтому карты для этой навигации практически все только официальные, по платной ежегодной подписке.
Сами же данные карт и навигации — один сплошной файл, по структуре разбит на 2к блоки. Логический блок — несколько 2к блоков после первого, в заголовке которого явно указывается их число. Сами данные атомарно хранятся в невыровненном виде. Например, самые первые 3 байта в первом логическом 2к блоке — его адрес-смещение, следующий байт — размер логического блока. Далее насколько помню байт признака-ключа шифрования данных, байт типа блока и т.д.
00 00 02 03 — блок со смещением 2*2048, размером 3*2048 байт.
Структура данных 2к внутри зависит от типа блока, но сделана явно в полиморфных наследуемых структурах. Матрешки, в которых так же описывается размер содержимого.
Если ставить задачу чтения такого, без описываемых динамических неоднородных контейнеров обойтись можно и несложно.
Если поставить задачу компиляции таких данных, из OSM, например, то мне предлагаемый подход нравится настолько, что я статью себе в избранное занес.
Мне кажется, рассматривать человеческий мозг, как цифровую эвм — это допущение, по вольности выходящее за рамки здравого смысла.
Сводя задачи позиционирования к дифференцированию, интегрированию, интегральным уравнениям — и отнеся их решение с заданной точностью на аналоговые части вычислителя, управление в такой системе будет требовать минимальной цифровой логики. В аналоговой ЭВМ решение появляется «сразу» — не требуется тактов, итераций и шагов алгоритмов.
Автору — большое спасибо. Отличная статья, из тех что идут «в закладки» как справочник.
Отработал в одном из трёх больших братьев 10 лет. Из них 4 последних — занимался планированием радиопокрытия сотовой связи 2G/3G по одной из областей РФ, мониторингом качества, переоборудованями и т.п.
Простите, но надо понимать, что данное приложение собирает данные по уровню принимаемого телефоном сигнала.
И наличию/отсутствию сигнала 2g/3g/4g.
И больше ничего.
Качество же связи с уровнем коррелирует минимально. В случае когда единственная базовая станция на 100 км — то корреляция близка к 1. Чем выше уровень, тем ближе к идеальному качество до какого то достаточного уроня (связь — цифровая, поэтому при уровне -40dBm — у антенны — и при уровне -70dBm — в 3-5 километрах качество будет совершенно одинаковым в этом случае).
В городе, где на километр улицы может стоять до двух десятков разных сот одного оператора (и то же самое на этой же улице — у других), качество к уровню сигнала относится совершенно никак.
При совершенно одинаковых показателях уровня качество может быть у разных операторов в одном и том же месте совершенно различным.
Нередко в городе для обеспечения надлежащего качества, уровень на сотах БС специально занижается, уменьшая влияние на соседей.
Более того, важно понимать, что желаете принять за качество.
Громкость, внятность разговора без разрывов и пропаданий?
Скорость интернета?
Отсутствие выпаданий телефона из сети?
Я порекомендовал бы тем, кто хочет получить представление о качестве в его районе www.netmonitor.ru. Хороший ресурс, где любители подходят профессионально к вопросам покрытия и качества.
Важно понимать, что это приложение — дает представление именно о наличии диапазона / уровне сигнала, не придумывать завышенных ожиданий.
Дефайны PERIOD_0 — PERIOD_7 используются только при инициализации массива состояний traffic_signals[], и я счел более важным их наименованием подчеркнуть небесспорный и неочевидный момент: номера в массиве используются в коде. Перемещение их на другие места не допускается. Переименовывание их в предложенный вариант — потеря информации. Конечно, можно сохранить отсылку к нумерации и добавить информацию о цветах режима.
Но нормальная IDE при наведении курсора на дефайн показывает и его значение, и комментарий рядом.
Глобальная переменная gcc инициализируется, локальная нет — накладные расходы в .bss.
Только что проверил: при компиляции с флагом -O0 (без оптимизации) размер прошивки с глобальной переменной 78 байт, с локальной 58.
При оптимизации по размеру (-Os) 60 байт и 40 соответственно.
Дизассемблирование показывает — куда уходит память, слева — вариант с глобальной переменной.
Квалификатор volatile не только компилятору запрещает кешировать переменную в регистре, но и накладывает обязательство на автора программы — рассмотреть последствия возможных изменений.
Здесь volatile только переменная глобального таймера, основной цикл выполняется за время многократно меньшее промежутка её инкремента от переполнения, а выполнение цикла инициируется её изменением от старта прерывания переполнения счетчика.
А вот при просыпании из POWER_DOWN_MODE, хотя она обнуляется, но таймер не реинициализируется, и, естественно, её значение может скакнуть в любой момент.
Последствиями будет возможное изменение периода самого первого после просыпания сигнала на дельту времени до 1/37 секунды. (Или до 1/64, если выполняется на МК с частотой 16МГц).
Критической проблема может стать, если случится переполнение целого беззнакового, uint16_t из 65535 превратится в 0: вся логика сравнений превратится в тыкву. Для недопущения этого при достижении безопасного порога в половину максимально возможного значения типа переменной в самом начале основного цикла идет корректировка глобального таймера и значений, которые с ним сравниваются.
Так и есть.
В процессе заводских испытаний было принято к устранению замечание Представителя Заказчика о недостаточной частоте моргания.
Обоснование отступления от ГОСТа и внесения изменений в программный код программно-аппаратного комплекса железобетонное: "Папа, я так хочу".
Косяк. Обидно, что давно исправленный, в "./schematic/traffic light ver0.dch" схема верная, вот такая.
А в скриншотах к статье пропустил давнюю, неисправленную.
Очень подозреваю, что результат AtmelStudio вряд ли сильно будет отличаться от GCC, рост расхода памяти с глобальными переменными в сравнении с локальными не обусловлен конкретным тулчейном.
Самому любопытно, и буду благодарен, если кто-то проведет эксперимент по компиляции под AtmelStudio и в комментарии расскажет результаты.
Сдвиговый регистр?
Для иллюстративной самодельной игрушки, занимательной головоломки, как видите, он не требуется.
Для (предположим) схемы серийного производства игрушки, не то что добавлять регистр, а от 6 токоограничивающих резисторов избавлялся бы — при импульсной схеме питания светодиодов они не необходимы, а каждая точка пайки, не говоря о стоимости самого элемента, это постоянные расходы.
Причем, двунаправленный — и как перевод давления во вращательный момент, и, как нагнетатель давления от вала отбора мощности.
Для микро-роботов пневматические приводы интересны — пневмоманипуляторы обеспечивают и гибкость, и регулируемую силу захвата, но требуют наличия пневмосистемы.
Просто на шасси компрессор не воткнешь. И электропневмоклапана — это и громоздко, и тяжело, и амперы кушает только в путь
А в этом варианте давление в пневмосистеме легко регулируется — банальный ШИМ на моторчике. На алибабе полно дешевых и маленьких датчиков давления.
И вместо отдельных клапанов — можно легко делать отдельные пневмосистемы, каждая со своим регулируемым по проводам «компрессором».
И сами клапана — или даже газовые редукторы с управляемым оборотами давлением — на том же принципе — так же возможны.
Поэтому капотники не прижились.
Попробовал перечислить возможные технологии.
1. Отражение в лобовом стекле зеркального изображения на экране планшета/телефона.
Уже есть во многих навигационных программах на андроиде — положив телефон на торпеду, в стекле видно его отображение.
(+) всегда в фокусе;
(+) не требует приобретения отдельного hw;
(-) размер проецируемой области — примерно равен размеру экрана;
(-) есть искажения — отражающая поверхность имеет кривизну, но не сильно большие, из-за небольших размеров экранов носимых устройств.
2. Использование HUD.
«Как в истребителях», есть предложения на рынке.
(+) плоская поверхность отражателя не дает искажений;
(+) большой диапазон регулировки по яркости;
(-) необходимо специальное дополнительное довольно громоздкое устройство, на торпеду не любого автомобиля подойдет.
3. Проектор.
Проецирование видеосигнала, как в настенном проекторе.
(-) крайне сложная поверхность линз оптической схемы объектива, компенсирующее отражения от криволинейного лобового стекла и обеспечивающее изображения «в фокусе» по всему полю.
4. Изображение, формируемое лазером.
Тема статьи. Можно использовать поляризованную пленку — чтобы лазер не улетал через стекло. Не используя — всего лишь потеряется яркость.
(+) изображение в фокусе по всему полю и оптические искажения несложно компенсировать программным способом;
(+) небольшие габариты устройства;
(+) возможность использования и с существующими или с штатными системами автонавигации, как VDO Dayton, у которых рекомендации по перестроению выводятся в фиксированную область экрана при вождении;
(+) высокая яркость (естественно она может регулироваться)
(-) монохромность;
5. MEMS лазерное сканирование — проецирование.
Только одну фирму нашел, которая делает такие чипы — MicroVision. Два продукта: лазерный проектор для iPhone «MicroVision SHOWWX» (б/у $200) и лазерный проектор Сони на той же технологии «Sony MP-CL1» — на технологии PicoP.
Все плюсы четвертого пункта и в полноцвете.
Но MicroVision хотят пойти гораздо дальше.
Их решение навигации для авто обещает работать в дополненной реальности.
Вариант когда само лобовое стекло является экраном — не стал добавлять. Теоретически — возможно, однако технологичность выступает за рамки разумного.
Т.о. получаем, что очень близки к прорыву лазерные проецирующие технологии.
Слой на стекле, который отражает лазер — т.е. либо фильтр по конкретному цвету, либо по поляризации — необходим для удобства дневной видимости — чтобы не наращивать мощность лазера для обеспечения контраста.
Нигде пока что не видел упоминаний о технологии напыления поляризованной пленки на стекло.
А жаль, брызнул из баллончика — и у тебя экран поляризованный сразу есть.
Формат закрытый, нигде не описываемый, инструментарий для работы с данными есть только у производителя.
Именно поэтому карты для этой навигации практически все только официальные, по платной ежегодной подписке.
Сами же данные карт и навигации — один сплошной файл, по структуре разбит на 2к блоки. Логический блок — несколько 2к блоков после первого, в заголовке которого явно указывается их число. Сами данные атомарно хранятся в невыровненном виде. Например, самые первые 3 байта в первом логическом 2к блоке — его адрес-смещение, следующий байт — размер логического блока. Далее насколько помню байт признака-ключа шифрования данных, байт типа блока и т.д.
00 00 02 03 — блок со смещением 2*2048, размером 3*2048 байт.
Структура данных 2к внутри зависит от типа блока, но сделана явно в полиморфных наследуемых структурах. Матрешки, в которых так же описывается размер содержимого.
Если ставить задачу чтения такого, без описываемых динамических неоднородных контейнеров обойтись можно и несложно.
Если поставить задачу компиляции таких данных, из OSM, например, то мне предлагаемый подход нравится настолько, что я статью себе в избранное занес.
Автонавигация VDO Dayton — именно таким образом хранятся данные карт и навигации.
Сводя задачи позиционирования к дифференцированию, интегрированию, интегральным уравнениям — и отнеся их решение с заданной точностью на аналоговые части вычислителя, управление в такой системе будет требовать минимальной цифровой логики. В аналоговой ЭВМ решение появляется «сразу» — не требуется тактов, итераций и шагов алгоритмов.
Автору — большое спасибо. Отличная статья, из тех что идут «в закладки» как справочник.
Простите, но надо понимать, что данное приложение собирает данные по уровню принимаемого телефоном сигнала.
И наличию/отсутствию сигнала 2g/3g/4g.
И больше ничего.
Качество же связи с уровнем коррелирует минимально. В случае когда единственная базовая станция на 100 км — то корреляция близка к 1. Чем выше уровень, тем ближе к идеальному качество до какого то достаточного уроня (связь — цифровая, поэтому при уровне -40dBm — у антенны — и при уровне -70dBm — в 3-5 километрах качество будет совершенно одинаковым в этом случае).
В городе, где на километр улицы может стоять до двух десятков разных сот одного оператора (и то же самое на этой же улице — у других), качество к уровню сигнала относится совершенно никак.
При совершенно одинаковых показателях уровня качество может быть у разных операторов в одном и том же месте совершенно различным.
Нередко в городе для обеспечения надлежащего качества, уровень на сотах БС специально занижается, уменьшая влияние на соседей.
Более того, важно понимать, что желаете принять за качество.
Громкость, внятность разговора без разрывов и пропаданий?
Скорость интернета?
Отсутствие выпаданий телефона из сети?
Я порекомендовал бы тем, кто хочет получить представление о качестве в его районе www.netmonitor.ru. Хороший ресурс, где любители подходят профессионально к вопросам покрытия и качества.
Важно понимать, что это приложение — дает представление именно о наличии диапазона / уровне сигнала, не придумывать завышенных ожиданий.