Вот эта библиотека работает с целочисленными значениями для построения FFT спектра. На STM32F030, запущенного на 20МГц (пришлось выбирать рабочую частоту так, чтобы можно было управлять через SPI "умными" светодиодами (WS2812 в микро корпусе). Буфер на 512 сэмплов обрабатывает быстро (хотя и не замерял), но его заполнение, обработка, поиск нужной частоты (среднее + сравнение его с пятью "нужными" сэмплами) довольно неоптимальным кодом... спокойно укладывается в 50мс. Да, всё крутится вокруг DMA при этом.
Настроили АЦП, прикрутили к нему DMA. Настроили SPI на отправку буфера для светодиодов, чуть-чуть заполнили его, запустили DMA, пусть он запрашивает следующие 48(24) байт. Начали читать данные через I2C? Ну... а на этом чипе так не получилось. Ну ой.
Традиционно торчащий блок камер. Могли бы сделать "Вровень выпирает" и за одно увеличить ёмкость аккумулятора, т.к. корпус бы стал толщиной с блок камер. Или поставить камеры тоньше. И экран с пулевым ранением в лоб. Мода, чтоб её. :\
Если в массиве состояния уже "2", то "1" туда складывать нет смысла.
А сбросом этого значения будет заниматься основной поток. Так что нет. Ну и мелкие проверки "на идиота" никто не отменял, а расписывать их все без псевдокода сильно долго.
В общем, таким алгоритмом я спокойно пользуюсь в своих проектах и сбоев пока замечено не было. И длительное нажатие (даже слишком длительное, которое ошибка) не считается как "длительное нажатие + короткое".
ИМХО. Конечнный автомат, это, конечно круто, но.. ЗАЧЕМ так сложно? Берём массив кнопок. Каждый квант времени (в случае моих устройств - каждую милисекунду, сразу после обработчика SysTick, возвращаемся в main() и читаем состояния кнопок (либо внутри самого SysTick'а) проверяем состояние пинов.
Если надата - увеличиваем счётчик. Если отпущена - сбрасываем (ееееее, антидребезг!). Если при чтении нуля с пина в соответствующей ячейке массива значение больше порогового для кнопки - в другой массив кладём "1". Если же досчитали до длительного нажатия - "2". Если превышен порог залипания - "3" или "0" - в зависимости от желания. Всё. Особого конечного автомата нет, а код видит нажатие кнопки.
Я засвечиваю китайским УФ фонариком https://aliexpress.ru/item/33043819149.html Хватает 20-30 секунд для платы размерами 10*10 см для равномерной засветки с расстояния около 60см (кладу плату, фотошаблон на неё, выравниваю, вытягиваю руку с фонариком вверх, и засвечиваю плавными круговыми движениями, стараясь держать фонарик в одной точке). Боковых засветов нет. Искажений нет. Результат повторяемый. 0.25/0.3мм - вообще без напряга выходит, а лучше не может обеспечить принтер, который эпизодически засыхает.
Вообще, засветка на малой мощности, как показала практика, малоэффективна и слабо дубит фоторезист. С другой стороны, мощный источник УФ может пробиться через неплотный фотошаблон.
Собрал как раз на SPI. Частота ядра - 20МГц, предделитель SPI - /4 (5МГц). 8 бит-слотов занимают 12.8мкс, 1 бит-слот - 1.6мкс (по какой-то причине светодиоды лучше всего заработали именно с этой скоростью). Данные отправляются по DMA. Используется 48 байт. 0x70 = '1', 0x40 = 0. Буфер кольцевой, 2*24 байта (бита). По прерыванию DMA уже отправленная половина буфера заполняется новыми значениями для передачи. 20 светодиодов вообще без сбоев приёма обновляются.
Диоды работают от того же питания 3.3В и чувствуют себя хорошо, как минимум, не отключаются и даже выходят на полную яркость (но ток потребления в батарейном устройстве для такого режима черезмерен, как и яркость для индикаторов).
Размер доступной памяти был всего 40кБ, что куда как меньше 64кБ у окна. Приходилось изголяться. А для снижения нагрузки на процессорную часть пытался описать подобие Delayed-ACK, но выходила какая-то фигня. В итоге проект так и не заработал как надо из-за сложности и смены потребностей.
У меня когда-то была обратная задача: собрать на минималистичном железе устройство для теста скорости. И из-за ограниченного объёма памяти для буфера приёма (микроконтроллер) мало что получилось. Хотя обмен данными по кабелю между ПК и устройством таки смог выжать почти 90МБит при TCP соединении.
Надеялся найти что-то интересное для железных отладчиков для микроконтроллеров. Ну да, чего я вообще хотел? :) Хотя у некоторых тоже есть интересые штуки типа "шага назад", но такие возможности имеют большое количество ограничений, как раз из-за микроконтроллера.
Так что иногда проще с трассировкой "Лол, мы сюда попали %потому что%".
Частенько в таких блоках питания всего один полноценный преобразователь напряжения. И блок питания, следует одной ему ведомой логике. Обычно - если потребителей больше одного - они сваливаются в режим 5V ?A. Количество доступных ампер - сильно разнится.
Значительно реже - блок выбирает общее напряжение для нагрузок из максимально рабочих для них. Но прямо ОЧЕНЬ редко.
Бывают блоки с парой независимых разъёмов - те могут работать полноценно раздельно.
И у меня всего один вопрос производителям блоков питания и вообще электроники, и вообще, к стандарту USB Type-C.
ЧТО мешало использовать пин(ы) CC(CC1/CC2) для двунаправленного однопроводного интерфейса обмена данными? Не дёргать током через VBUS (Здравствуй PumpExpress), не использует линии D+/D- для магии (привет стандартам QuickCharge), не занимается какой-то дичью, когда уже во всех кабелях имелся дополнительный пин - ID, а теперь ещё и CC.
Да, резистор можно осатвить, и поверх этого же делителя, например, поставить n-канальный полевой транзистор. Самое смешное, что похожая технология используется в... электромобилях. Пин Detect так же используется для двунаправленного(!) обмена данными. Что мешало добавить нечто подобное в стандарт? Ошибки на порту? Переспросим. Постоянные ошибки на линии? Даём только 5В 0.5А. Нет обмена данными? 5В, 0.5А. Нет резистора-подтяжки - нет напряжения. Всё. Остальное - решается протоколом. Да той же разновидностью OneWire на низкой скорости.
Году эдак в 2012 купил читалку PocketBook. Всё было отлично, пока "встроенная" (фактически - вклеенная в разъём) microSD карточка не решила устать - сначала начались странные глюки с перезагрузками, или зависание книжки. Пару раз спасался chkdsk'ом, потом решил таки заменить карточку на свежую, но книжка не загрузилась. Оказалось, прошивка (которая лежит обычными файлами на карте памяти) проверяет ID этой самой карточки, и с помощью этих ID расшифровывает некоторые исполняемые(!) библиотеки (либо восстанавливает указатели на память, в общем, глубоко не лез).
Вот та же фигня. Только мой выбор смартфона как-то сильно не попадает в "трендовые" веянья (написал, а у самого ощущение от этих слов, будто говны понюхал). Собственно, что нужно от телефона? - USB Type-C. Окей. Это не проблема. - Наушники 3.5мм? Сложно, но встречаются. - Аппаратная кнопка "Домой"? Уже сложнее. Довольно редкая вещь. - Экран без пулевых ранений и без "чёлочек"? - Нет, сынок, это фантастика. >_<
Ну почему?! Почему последнее - нет? Где смартфоны свернули не туда?
Ладно, хрен с ним, пусть будут скругления по краям... но чтобы ВСЁ было вместе - такого нет ни у кого сейчас. Раньше чёт было проще. Телефон с прямоугольным экраном без дефектов? Легко. Не хочешь OLED? Вот есть модель с IPS. Наушники? Всегда есть. Хочешь кабель сверху, или снизу? Вот самый распространённый разъём зарядки (на тот момент microUSB). Ну на тебе ещё стилус до кучи! Зачем? Потому что мы смогли! И ёмкую батарею тоже на. И быструю замену аккумулятора держи. Мало? Ну на тебе ещё наушники в комплекте. И провода. И док станцию можешь купить, и телефон в ней может работать вместо компа. (с)
Я с такими же костылями "переезжал" с 751 на 951-й микротик.
Конфиг заливается? Да. Светодиоды работают? Ну как бы да. А что с портами? А они наоборот! eth5 <=> eth1, eth4 <=> eth2. На месте остался только eth3, но он и так посредине.
Естественно, при заливке конфигурации между сериями не поднимается ни PPPoE, ни часть правил фаервола (смотрят на другие порты).
Родная ось Z - какой-то пластик. Паяльником не склеивается, такое чувство, что из него выступает силиконоподобная жидкость. Клей если и схватывает, то на время. Место очень неудачное. Новый - алюминий почти на 100% (валы, рельсы, винты - различные стали).
https://gist.github.com/Tomwi/3842231
Вот эта библиотека работает с целочисленными значениями для построения FFT спектра. На STM32F030, запущенного на 20МГц (пришлось выбирать рабочую частоту так, чтобы можно было управлять через SPI "умными" светодиодами (WS2812 в микро корпусе). Буфер на 512 сэмплов обрабатывает быстро (хотя и не замерял), но его заполнение, обработка, поиск нужной частоты (среднее + сравнение его с пятью "нужными" сэмплами) довольно неоптимальным кодом... спокойно укладывается в 50мс. Да, всё крутится вокруг DMA при этом.
Настроили АЦП, прикрутили к нему DMA.
Настроили SPI на отправку буфера для светодиодов, чуть-чуть заполнили его, запустили DMA, пусть он запрашивает следующие 48(24) байт.
Начали читать данные через I2C? Ну... а на этом чипе так не получилось. Ну ой.
Традиционно торчащий блок камер. Могли бы сделать "Вровень выпирает" и за одно увеличить ёмкость аккумулятора, т.к. корпус бы стал толщиной с блок камер. Или поставить камеры тоньше.
И экран с пулевым ранением в лоб. Мода, чтоб её. :\
Если в массиве состояния уже "2", то "1" туда складывать нет смысла.
А сбросом этого значения будет заниматься основной поток. Так что нет.
Ну и мелкие проверки "на идиота" никто не отменял, а расписывать их все без псевдокода сильно долго.
В общем, таким алгоритмом я спокойно пользуюсь в своих проектах и сбоев пока замечено не было. И длительное нажатие (даже слишком длительное, которое ошибка) не считается как "длительное нажатие + короткое".
Можно. А считая ещё реже можно пропустить нажатие.
ИМХО. Конечнный автомат, это, конечно круто, но.. ЗАЧЕМ так сложно?
Берём массив кнопок. Каждый квант времени (в случае моих устройств - каждую милисекунду, сразу после обработчика SysTick, возвращаемся в main() и читаем состояния кнопок (либо внутри самого SysTick'а) проверяем состояние пинов.
Если надата - увеличиваем счётчик. Если отпущена - сбрасываем (ееееее, антидребезг!). Если при чтении нуля с пина в соответствующей ячейке массива значение больше порогового для кнопки - в другой массив кладём "1". Если же досчитали до длительного нажатия - "2". Если превышен порог залипания - "3" или "0" - в зависимости от желания. Всё. Особого конечного автомата нет, а код видит нажатие кнопки.
Я засвечиваю китайским УФ фонариком https://aliexpress.ru/item/33043819149.html
Хватает 20-30 секунд для платы размерами 10*10 см для равномерной засветки с расстояния около 60см (кладу плату, фотошаблон на неё, выравниваю, вытягиваю руку с фонариком вверх, и засвечиваю плавными круговыми движениями, стараясь держать фонарик в одной точке).
Боковых засветов нет. Искажений нет. Результат повторяемый. 0.25/0.3мм - вообще без напряга выходит, а лучше не может обеспечить принтер, который эпизодически засыхает.
Вообще, засветка на малой мощности, как показала практика, малоэффективна и слабо дубит фоторезист. С другой стороны, мощный источник УФ может пробиться через неплотный фотошаблон.
Собрал как раз на SPI. Частота ядра - 20МГц, предделитель SPI - /4 (5МГц). 8 бит-слотов занимают 12.8мкс, 1 бит-слот - 1.6мкс (по какой-то причине светодиоды лучше всего заработали именно с этой скоростью). Данные отправляются по DMA. Используется 48 байт. 0x70 = '1', 0x40 = 0. Буфер кольцевой, 2*24 байта (бита). По прерыванию DMA уже отправленная половина буфера заполняется новыми значениями для передачи. 20 светодиодов вообще без сбоев приёма обновляются.
Диоды работают от того же питания 3.3В и чувствуют себя хорошо, как минимум, не отключаются и даже выходят на полную яркость (но ток потребления в батарейном устройстве для такого режима черезмерен, как и яркость для индикаторов).
Размер доступной памяти был всего 40кБ, что куда как меньше 64кБ у окна. Приходилось изголяться. А для снижения нагрузки на процессорную часть пытался описать подобие Delayed-ACK, но выходила какая-то фигня. В итоге проект так и не заработал как надо из-за сложности и смены потребностей.
У меня когда-то была обратная задача: собрать на минималистичном железе устройство для теста скорости. И из-за ограниченного объёма памяти для буфера приёма (микроконтроллер) мало что получилось. Хотя обмен данными по кабелю между ПК и устройством таки смог выжать почти 90МБит при TCP соединении.
Надеялся найти что-то интересное для железных отладчиков для микроконтроллеров. Ну да, чего я вообще хотел? :)
Хотя у некоторых тоже есть интересые штуки типа "шага назад", но такие возможности имеют большое количество ограничений, как раз из-за микроконтроллера.
Так что иногда проще с трассировкой "Лол, мы сюда попали %потому что%".
Частенько в таких блоках питания всего один полноценный преобразователь напряжения. И блок питания, следует одной ему ведомой логике. Обычно - если потребителей больше одного - они сваливаются в режим 5V ?A. Количество доступных ампер - сильно разнится.
Значительно реже - блок выбирает общее напряжение для нагрузок из максимально рабочих для них. Но прямо ОЧЕНЬ редко.
Бывают блоки с парой независимых разъёмов - те могут работать полноценно раздельно.
Разобрать PocketBook, вытащить карточку, вставить новую, получить ругань загрузчика, посмотреть серийник на экране. На моей было так.
Как вариант - linux + кард-ридер или ещё несколько вариантов, включая разные уровни извращений от Arduino+USB-TTL и разные другие.
И у меня всего один вопрос производителям блоков питания и вообще электроники, и вообще, к стандарту USB Type-C.
ЧТО мешало использовать пин(ы) CC(CC1/CC2) для двунаправленного однопроводного интерфейса обмена данными? Не дёргать током через VBUS (Здравствуй PumpExpress), не использует линии D+/D- для магии (привет стандартам QuickCharge), не занимается какой-то дичью, когда уже во всех кабелях имелся дополнительный пин - ID, а теперь ещё и CC.
Да, резистор можно осатвить, и поверх этого же делителя, например, поставить n-канальный полевой транзистор. Самое смешное, что похожая технология используется в... электромобилях. Пин Detect так же используется для двунаправленного(!) обмена данными. Что мешало добавить нечто подобное в стандарт? Ошибки на порту? Переспросим. Постоянные ошибки на линии? Даём только 5В 0.5А. Нет обмена данными? 5В, 0.5А. Нет резистора-подтяжки - нет напряжения.
Всё. Остальное - решается протоколом. Да той же разновидностью OneWire на низкой скорости.
А сейчас что?
Году эдак в 2012 купил читалку PocketBook. Всё было отлично, пока "встроенная" (фактически - вклеенная в разъём) microSD карточка не решила устать - сначала начались странные глюки с перезагрузками, или зависание книжки. Пару раз спасался chkdsk'ом, потом решил таки заменить карточку на свежую, но книжка не загрузилась. Оказалось, прошивка (которая лежит обычными файлами на карте памяти) проверяет ID этой самой карточки, и с помощью этих ID расшифровывает некоторые исполняемые(!) библиотеки (либо восстанавливает указатели на память, в общем, глубоко не лез).
Даже описано в видео.
"Чёлочка" - может быть. А как быть с отверстием в матрице?
Придумывание обходных путей вокруг грабель вместо того, чтобы их убрать.
Вот та же фигня. Только мой выбор смартфона как-то сильно не попадает в "трендовые" веянья (написал, а у самого ощущение от этих слов, будто говны понюхал).
Собственно, что нужно от телефона?
- USB Type-C. Окей. Это не проблема.
- Наушники 3.5мм? Сложно, но встречаются.
- Аппаратная кнопка "Домой"? Уже сложнее. Довольно редкая вещь.
- Экран без пулевых ранений и без "чёлочек"? - Нет, сынок, это фантастика.
>_<
Ну почему?! Почему последнее - нет? Где смартфоны свернули не туда?
Ладно, хрен с ним, пусть будут скругления по краям... но чтобы ВСЁ было вместе - такого нет ни у кого сейчас.
Раньше чёт было проще. Телефон с прямоугольным экраном без дефектов? Легко. Не хочешь OLED? Вот есть модель с IPS. Наушники? Всегда есть. Хочешь кабель сверху, или снизу? Вот самый распространённый разъём зарядки (на тот момент microUSB). Ну на тебе ещё стилус до кучи! Зачем? Потому что мы смогли! И ёмкую батарею тоже на. И быструю замену аккумулятора держи. Мало? Ну на тебе ещё наушники в комплекте. И провода. И док станцию можешь купить, и телефон в ней может работать вместо компа. (с)
Я с такими же костылями "переезжал" с 751 на 951-й микротик.
Конфиг заливается? Да. Светодиоды работают? Ну как бы да. А что с портами? А они наоборот! eth5 <=> eth1, eth4 <=> eth2. На месте остался только eth3, но он и так посредине.
Естественно, при заливке конфигурации между сериями не поднимается ни PPPoE, ни часть правил фаервола (смотрят на другие порты).
Тоже пришлось всё чинить лапками.
Родная ось Z - какой-то пластик. Паяльником не склеивается, такое чувство, что из него выступает силиконоподобная жидкость. Клей если и схватывает, то на время. Место очень неудачное.
Новый - алюминий почти на 100% (валы, рельсы, винты - различные стали).
Собственно, если интересно, то ось ломалась вот таким образом.
А вот во что был переделан сам фрезер: