Pull to refresh
22
0
Александр @AlanDrakes

Пользователь

Send message

Традиционно торчащий блок камер. Могли бы сделать "Вровень выпирает" и за одно увеличить ёмкость аккумулятора, т.к. корпус бы стал толщиной с блок камер. Или поставить камеры тоньше.
И экран с пулевым ранением в лоб. Мода, чтоб её. :\

Если в массиве состояния уже "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% (валы, рельсы, винты - различные стали).

Трещина в оси Z - место посадки подшиприков
Трещина в оси Z - место посадки подшиприков

Собственно, если интересно, то ось ломалась вот таким образом.

А вот во что был переделан сам фрезер:

Собирал я относительно недавно контроллер котла (управляет моторами подачи масла и воздуха (12V), плюс мотор обдува от ~230V). И проблема возникла на низковольтной стороне.
При расчётах и проверке хватало скоростного диода между стоком транзистора и шиной +12V - всплеск напряжения на катушке мотора от закрытия транзистора возвращался в ёмкости на цепи питания. Всплеск вроди бы был небольшим.
А при включении драйвер Mosfet'ов, сказал что ему что-то плохо и пустил дым менее чем за секунду. :\

В итоге переделал плату, добавил емкостей везде, добавил RC-снаббер на стоке, сталибитрон, напихал емкостей где только смог, и всё запустилось без единого намёка на нагрев.

То есть, при первом пуске выжили транзисторы, защитный диод, источник питания, наверное, вообще не понял, что произошло что-то нештатное, но вот драйвер транзисторов выбило мгновенно.

Из подозрений у меня осталась только паразитная ёмкость затвор-сток, через которую могло "надуть" немного выше 15В на этот самый затвор. Но как-то не очень верится.

Information

Rating
Does not participate
Location
Омск, Омская обл., Россия
Date of birth
Registered
Activity