Comments 16
появилась шальная мысль, установить кварц на 24 МГц разогнать SYSCLK до 96 МГц (очень близко к пределу в 100 МГц).
Вероятно, вполне годное решение. Я когда-то пробовал разгонять пожилые(~2012 года) stm32f407 - для на коленке сбацанного рефлектометра. Разгон (при питании 3.3v) с 168 до ~210 два имевшихся экземпляра переживали абсолютно безболезненно, при разгоне >~230 начинала забавно отваливаться периферия - таймеры, FSMC, DMA с их логикой и триггерами.
Вероятно, вполне годное решение
На подобные слова я и рассчитывал, когда писал это).
Я слышал о проблемах с таймингами при доступе к памяти (как RAM, так и Flash) и видел на работе как периферия начинает чудить при повышении частот (но один опытный человек быстро привел всё в норму), а могла даже не запускаться. Это настораживает, но я попробую разогнаться когда у меня появится кварц в 24 МГц (текущие 8 считаю не очень надёжными).
Где-то в районе написания части 0, я, интереса ради, пробовал установить SYSCLK в 96 МГц, но они выводились из максимально неудобных 25 МГц или от внутреннего источника. В итоге контроллер не всегда проходил инициализацию :D
Если полученные тайминги действительно следствие оверхеда прерываний (а не, например, приоритета), то надо повышать производительность в 1.5-2 раза, т.к. оптимизировать бесконечно у меня не выйдет, единственным выходом остаётся повышение частот. Где-то в даташите должны быть описаны тонкости при повышении частот.
на коленке сбацанного рефлектометра
Это та штука, которая подключается к спутниковой тарелке чтобы найти спутник?
Не проще просто взять H7 на 480мгц и не мучаться? По человеко часам это будет точно дешевле
Не то что бы я мучался, проект идёт не торопясь, в свободное от работы время, и в своё удовольствие)
Причина, по которой я взял F411RE проста - она лежала у меня в ящике. Не было уверенности что получится продвинуться хоть сколько-нибудь, поэтому покупать навороченную плату было бы пустой тратой денег. Я думаю, что если единственной задачей будет только то что описано в статье (без RTOS, без остальной логики), то даже F103 может оказаться достаточно (в теории), а они стоят дешевле пачки семечек на Aliexpress и, тем более, Arduino Nano (до сих пор удивляет что они не вытеснили их).
Не проще просто взять H7 на 480мгц и не мучаться?
Взять более мощный процессор проще и я согласен что это упростит работу, но не факт что это целесообразно по финансовым затратам. Да, для более-менее человеческой разработки надо брать Nucleo-H753ZI/Nucleo-H563ZI или что-то около: на борту будет ETH (который в будущем может пригодиться), да и возможностей для подключения периферии раза в 2 больше (наделаем модулей расширения, работающих по CAN). Во всех отношениях лучше чем моя Nulcleo-411RE.
Мне ещё понравилась плата на H750: сразу есть слот для SD карты (скорее всего SDIO, что большой плюс) и небольшой дисплей (как подключён - неизвестно), но, по беглому взгляду, часть контактов не вывели на плате.
Пока программа умещается в ресурсы F411, разработке логики это не мешает. Есть нюансы, но их тоже можно попытаться преодолеть с помощью оптимизации и более разумных решений (пока что всё тяп-ляп, но и это прототип) - дабы не спрятать за производительным железом плохо написанный софт. Однако, если то, что показывает анализатор, действительно предел F411, а не недочёты софта (всё таки маленький тестовый паттерн давал ожидаемые тайминги, а значит дело может быть в подготовке паттерна), то очень скоро я перейду на что-то посерьёзнее (H5 или H7), тем более что проект набирает обороты и теперь уже начинает казаться возможным к завершению.
Если F4 окажется хотя бы минимально жизнеспособна для запуска релизного проекта, то это окажется не таким уж высоким требованием, а лишние деньги можно будет вложить в хорошие шаговые двигатели и драйверы к ним.
Интересная статья, жду продолжения!
По скорости F103-то может и справится. Но вам в перспективе желательно иметь объëм ОЗУ, достаточный для хранения хотя-бы одной страницы, пока она печатается. А 128кБ у F411 - это всего лишь 1024х1024 бит.
Или для непрерывного движения головы достаточно будет помнить растр одного горизонтального прохода?
Если я собираюсь рендерить картинку на контроллере (например, печатать с флешки), то в RAM должна поместится картинка + рендер. Можно схитрить и использовать дополнительную внешнюю память (даже не обязательно RAM), но работать это будет медленнее.
Или для непрерывного движения головы достаточно будет помнить растр одного горизонтального прохода?
Можно и меньше. Думаю, для непрерывной печати, лучше иметь одну строку в работе и одну строку в запасе. В теории, можно даже дробить одну строку. Если картинку рендерит ПК, то, как показал опыт предыдущей части, при подключении по USB, МК может получать буфер такого размера, какого ему удобно:
Хотя RxBuffer имеет размер PRNT_RX_DATA_SIZE = 512, я использовал PRNT_DATA_FS_OUT_PACKET_SIZE = 64
Пока это догадки. На сегодняшний момент принтер получать только текст и выводит его в uart. Всё будет зависеть от того, какую подготовку будет выполнять драйвер и как с ней справиться МК.
И есть нюанс у USB. Вроде, он работает на прерываниях - без DMA и интеграции модулем в RTOS. Боюсь может получится так, что запрос следующей порции данных может повлиять на процесс печати.
F411, кажется, уже подошла к своему пределу и не может выдать требуемых таймингов на GPIO, до упора в RAM или Flash ещё далеко. Нужно иметь порядка 100 нс (на это рассчитана библиотека для формирования сигналов), а сейчас, в лучшем случае, получается выдать 250-275 нс даже при увеличении частоты татирования до 72 и 96 МГц. Так что переезд на H753 уже выглядит не как не далёкая перспектива, а необходимость для продолжения развития проекта
Мне просто показалось, что желательно двигать головой без остановок, пока печатается строка. Так точнее. А когда строка напечаталась, можно и подождать следующую порцию растра от драйвера.
Кроме GPIO ещё интерфейсы QSPI, SDIO и LCD могут достаточно чёткие тайминги выдать, кстати.
Могут, но для одного картриджа надо контролировать 12 ног одновременно, мне не хватит интерфейсов :D поэтому я остановился на связку GPIO->BSRR + TIM + DMA. Насколько понял, Spritetm использовал I2S, но я не разбирался подробно с его кодом
У LCD ног достаточно. Причём можно воспользоваться его штатными сигналами синхронизации.
Я сам пробовал работать с такой связкой, только через GPIO->ODR - для текстового ЖК аппаратный экранный буфер, например, делал. Но с такими жёсткими таймингами не встречался. И, кстати, не во всех STM эта связка у меня заработала, до конца не разобрался.
Про DMA можно ещё углубиться в описание, и разобраться с настройкой приоритета и буферизации. Это может улучшить тайминги. Ещё не забыть, что DCLK - это сам таймер, его паттерн не нужно в DMA пихать. И таймеры в STM32 умеют синхронизироваться по-разному для генерации паттернов. Ну и при преобразовании уровней к 9-16 В вполне можно какую-то дискретную логику прикрутить, чтобы где-то паттерн упростить.
Так потихоньку программно и FPGAшку можно во многих задачах заменить)))
У LCD ног достаточно. Причём можно воспользоваться его штатными сигналами синхронизации
С LCD я пока не знаком так близко (как, в принципе, с большей частью embedded). У STM32H7 есть аппаратный LСD контроллер. Если действительно завязаться на него, то 24-битной версии хватит на два картриджа сразу)
Так потихоньку программно и FPGAшку можно во многих задачах заменить)))
Никогда не cвязывался c FPGA и ПЛИС в целом. Но мне приходилось слышать как программную логику переносили на ПЛИС, так что было бы круто запрограммировать какую-нибудь ту же FPGA на управление принтером) или хотя бы картриджем) передавая ему RGB пиксель, который сразу преобразуется в необходимую последовательность сигналов).
GPIO->ODR - для текстового ЖК аппаратный экранный буфер, например, делал
Насколько я знаю, BSRR работает быстрее и атомарен, в отличие от ODR.
С ODR работать проще - в него сразу помещается нужное значение для всего порта. Мне кажется, я когда-то использовал ODR для управления матрицей на адресных светодиодах
Я пока всё таки на стороне BSSR с синхронизацией по таймеру. Он более гибок и даёт возможность "прямой" реализации любого интерфейса.
Про DMA можно ещё углубиться в описание, и разобраться с настройкой приоритета и буферизации
Даже выдавая высший приоритет DMA и устанавливая самую высокую скорость на GPIO - анализатор не отображает никакого влияния. В данный момент упор, видимо в таймер - его тактирование очень близко к шине APB и SYSCLK, а значит callback таймера вызывается довольно часто и, вероятно, его количество тактов > количества тактов, необходимых таймеру.
Ещё не забыть, что DCLK - это сам таймер, его паттерн не нужно в DMA пихать
Не могу полностью согласиться. В диаграмме из статьи на Hackaday с реального принтера можно увидеть смещение S1-S5 относительно DCLK, так что нет полной уверенности он эквивалентен таймеру. Возможно это артефакты в работе принтера или анализатора - нет уверенности. И библиотека от Spritem и PrintSpider_Arduino генерирует с дублированием 0 и 1 (надо анализировать зачем, для меня это немного странно), поэтому пока что таймер должен быть в 2 раза быстрее DCLK.
Тут в новостях проскочило https://www.crowdsupply.com/open-tools/open-printer
В принтере могут использоваться картриджи HP 63 (US) и HP 302 (Europe), без DRM, привязок к производителю и ограничений на перезаправку. Допускается установка одного чёрно-белого или одного цветного картриджа, а также обоих картриджей (чёрно-белый + цветной). Поддерживается печать как на 27-миллимертровой рулонной бумаге, так и на отдельных листах A4 и A3. В черно-белом режиме обеспечивается печать с разрешением 600 dpi, а в цветном - 1200 dpi.
Для управления работой устройства задействована плата Raspberry Pi Zero W c выводом на 1.47-дюймовый TFT-экран (172 x 320) и переключением режимов при помощи вращающегося регулятора. Для управления картриджем применяется микроконтроллер STM32. Для взаимодействия с внешними устройствами заявлена поддержка USB Type-C (для подключения к компьютеру), USB Type-A (для устройств хранения), Wi-Fi 802.11ac и Bluetooth 4.1.
Интересно, на фотографиях выглядит вполне неплохо (правда вид на стене заставляет задуматься повесить это в туалете). Классно что, по сути, они делают компактный плоттер. Хорошая идея разделить коммуникацию и контроль печати по двум контроллерам. В своей первой статье я тоже рассматривал такую возможность как способ не упираться в производительность STM32.
Однако, к сожалению, я не нашёл ссылок к исходникам и подробностям железа, в репозиториях участников тоже. И тут уже приходится гадать: проект завершён и ждёт своего часа у кого-то в гараже; проект на стадии закрытой разработки; проект даже не начали. Без финансовой поддержки они могут не дать больше никакой информации. С другой стороны, это бы полностью убило смысл моего проекта, так что я даже немного рад.
Всем привет, есть такая вот статья может чем то поможет, https://www.techspot.com/news/109674-open-printer-fully-open-source-inkjet-drm-free.html .
Привет! Выше был комментарий по этому поводу
DIY Open Source принтер. Часть 2. Логика управления печатающей головой HP123