jcxz

А смысл переходить на давно устаревшие ARM7/ARM9 (которые вы предлагаете) - какой? Если и переходить с AVR на что-то, то скорее всего - на Сortex-M. А не на то старьё, что вы предлагаете.

А вы сопоставьте: и тот факт, что на вопрос, заданный здесь много дней назад: не было ни одного ответа. При том, что за это время здесь на форуме было уже множество сообщений о других МК, например STM32. Т.е. - если следовать логике, получается тогда STM32 должен использоваться ещё больше... миллиарды штук?? в РФ??? что абсурдно. Или какое ещё может быть объяснение этого факта? Что на одном из самых популярных тематических русскоязычных форумов не слышно вообще вопросов/тем по этому Амуру (при том, что по другим МК - полно). Да и на других аналогичных русскоязычных форумах - тоже не видел тем с практическими вопросами по нему. А ведь чтобы что-то делать серийно (ведь миллионы - это явно серийное производство), нужно сперва это что-то разработать, отладить. Т.е. - потратить довольно прилично времени. А значит наверняка столкнуться с вопросами. С которыми обычно куда идут русскоязычные разработчики? Я думаю вы знаете. Т.е. - логично предположить последовательность: 1) Появляется новый МК; 2) выпускаются средства разработки для него; 3) сам он производится пока мелкими сериями; 4) разработчики покупают его понемногу и начинают разработку, по ходу сталкиваясь с кучей проблем и багов (тем в более в новом МК их должно быть довольно много); 5) идут на разные форумы с вопросами; 6) постепенно проблемы решаются, начинаются испытания, опытная эксплуатация; 7) И только после этого всего может начаться массовое производство, миллионами штук. А значит к этому моменту уж наверняка хоть где-то хоть на каком-то форуме хоть одна тема по нему всплывёт. А скорее - даже много. А вот чтобы вдруг, ниоткуда, сразу и миллионы штук с неба упавшей прошивкой и схемой - это похоже на сказку. PS: Может конечно любой амуро-покупатель сразу с чеком подписывает соглашение о молчании. Или ему сразу отключают интернет. Или ещё одно объяснение: этот Амур - это просто перемаркировка какого-то популярного МК (типа STM32F103), совпадающий с ним один-в-один и позволяющий выполнять код предназначенный для того МК. Или Амуры дают только мега-гуру, которые всё заранее знают, и у которых не возникает вопросов и проблем. Верите в сказку? Или же всё прозаично, как обычно: не имеющее ничего общего с реальностью.

Бессмысленный вопрос. Способ будет зависеть от алгоритма обработки этих данных. Можно придумать 100500 разных вариантов, удобных для каждого конкретного случая. Такой же бесмысленный, как вопрос: Каким столовым прибором вы пользуетесь для еды? Вы же, надеюсь, пользуете и вилки и ложки и ножи? - что когда удобнее, а не мешаете сахар в чае вилкой... Так и средств межпоточной синхронизации придумано множество. Если бы был общий универсальный наилучший способ, то какой смысл было бы придумывать такое их многообразие?

Так я же дал ссылки. Там всё есть. Кроме того - есть ещё руководство по использованию (чтению/записи): http://www.libpng.org/pub/png/libpng-1.0.3-manual.html

Есть libpng для работы с .png: http://www.libpng.org/pub/png/libpng.html В исходниках. Которая внутри для сжатия использует zlib: https://www.zlib.net/ Лучше передавать .png, а внутри распаковывать с помощью libpng. .png ничем сжимать не нужно, оно внутри уже сжатое будет (особенно если поставить максимальный уровень сжатия = 9). Не знаю её требований по ОЗУ, но скорее всего надо быть готовым, что потребует довольно много его. Впрочем - уровень сжатия можно настроить в диапазоне: 0...9. Также есть какие-то настройки (дефайнами) разных параметров. Вроде и размер словаря там можно было настроить.

По каким именно "уделывает"??? ОЗУ - почти в 6 раз меньше; скорость - по обзорам в инете у RISC-V на 30% ниже, чем у равного по частоте Cortex-M; АЦП - всего какие-то жалкие 14МГц и 2 преобразователя вместо 36МГц и 4-х преобразователей у XMC. Да и по количеству обсуждаемых в теме таймеров общего назначения CH32 нервно курит в сторонке: 10 шт. у CH32 против 24 шт. XMC4700. Причём периферия XMC позволяет внутренний роутинг различных сигналов от- и к- таймерам. С логическими функциями над ними. Определяемый пользователем. Равного которому нигде больше не видел. А в общем, по богатству и жирности периферии, равных XMC среди МК сравнимого уровня просто нет. PS: Уж не говоря о "китайскости" CH32 по сравнению с немецким Infineon.

Зачем что-то собирать, если есть готовые отладки? Если из России, то например дешёвая: https://aliexpress.ru/item/1005005337709625.html Которая содержит и МК значительно мощнее, чем нужно (с запасом) и встроенный J-Link. PS: Странно - ещё пару дней назад эта же плата в этом же магазине стоила 2400руб, а сейчас уже 2900руб.

Да уж... Видимо вы из тех, кто на каждую минимальную функцию (типа захвата фронта/спада) ставит по отдельному процессору.

Отличаются ВАХ при обратном напряжении. Она совсем не такая крутая, как у стабилитронов. см.даташиты. Ваш ESD-диод нормально откроется только при Uобр. = ~7V. Что несколько многовато. Если у вас существует возможность приложения напряжения, выходящего за допустимый диапазон ко входу, то в качестве ограничителей нужно использовать стабилитроны или пару диодов (на питание и GND). ESD-диод с вашим включением никак не спасёт в случае приложения напряжения немного выходящего за верхний предел. ESD - это только для защиты от эл-статических разрядов (у которых амплитуда многократно больше). См. ВАХ ESD-диода.

Может не будем валить с больной головы на здоровую? Речь шла о фиксации длительности одиночных импульсов. В случае с CCR в STM32 - не только потеря самих событий, но отсутствие информации, что такая потеря произошла. Что делает практически невозможной обработку любых перепадов (даже редких и одиночных) в такой системе. Вот получили вы через DMA в памяти набор значений CCR о событиях. Хотите например декодировать ШИМ-сигнал по ним. Или длительности коротких импульсов померять. Но где гарантия, что в тот момент, когда STM зарегистрировал событие фронта, по настоящему была короткая иголка (в несколько тактов), спад которой был потерян? А значит - весь дальнейший анализ невозможен, так как неизвестно состояние линии после события - 0 или 1? Как предлагаете определять? Поэтому при наличии всякого рода дребезгов, анализ посредством DMA на STM32 очень сложен. (если только нет какого-то способа детектировать факт потери). Только ISR. Ведь в ISR можно прочитать текущее реальное состояние линии после события. Ок. Тогда расскажите - как будете действовать в случае: Вот получили вы событие срабатывания CAPTURE от таймера. Через DMA, в массиве таких событий. Как определите - один там фронт или спад произошёл или 2, 4, ... пересечений? И как определите реальное состояние линии после такого события: 0 или 1? С учётом того, что прерывание от DMA произошло значительно позже этого события. ЗЫ: Или всё-таки в таймерах STM32 есть какой-то способ зарегистрировать факт потери события? Кто знает?

"Здесь играем, здесь не играем, а здесь мы рыбу заворачивали"... И как предлагаете угадывать - что там у вас в действительности в схеме?

Кто? Очевидно программа на этом МК. И в чём именно проблема обработать? Чушь. FIFO не может быть "на один элемент". По определению. И как например хотя бы узнать, что произошло переполнение (была потеря события) с одним CCR? Не говоря уж о полноценной регистрации...

Например - есть у XMC4xxx. У всех МК семейства. Начиная с младших. Глубиной = 4. Может и у более младшего семейства (XMC1xxx) есть - не смотрел. PS: Наличие FIFO гораздо важнее, чем DMA. Позволяет регистрировать импульсы хоть в 1 такт.

Использовать нормальный МК, имеющий FIFO в таймере и DMA. А не пытаться натянуть сову на глобус.

На али вас забанили что-ль? Там полно DC-DC на любой вкус.