Хотелось бы заюзать STM32G431RBT6, чтобы трохи сократить обвеса. Но ST, middleware для power delivery распространяет под STM32G исключительно в виде блоба.
Выглядит это как-то диковато, но они на полном серьезе такое педлагают. Тащить себе такое в проект не хочется. Может кто-нибудь уже портировал гугловский стек под семейства STM32G?
Хочется состыковать девайс с FLASH по USB, чтобы легко править конфиги и читать логи.
Все что удалось найти из простого - имплементации USB MSC HOST. Но по-моему они не заморачиваются насчет ресурса флешки, а ставить EEPROM я не хочу, там за вменяемые деньги только 64 килобайта.
Можете посоветовать годные библиотеки, которые можно было бы юзать именно с флешками (мелкими 8-выводными SPI)?
Хочется странного. Экспериментирую со 100-ваттными нагревателями, питаю через дешевый диммер с али за пару баксов. Немного неудобно, что ручка в середине реагирует слишком резко, а в конце совсем никак.
Может бывают диммеры, чтобы на нагреватель выдавали мощу примерно пропорционально ручке? Ну не лепить же свой (еще не настолько пригорело).
PS. Вообще у нагревателя еще сопротивление в 2 раза меняется по мере разогрева, но это можно не учитывать.
После JS, где берем mocha и фигачим тесты, на сшечке не совсем понятно, как добиться такой же простоты:
В общем, хотелось бы как в жыэс, тратить время именно на написание тестов, а не на то чтобы думать как их запустить.
Я видел что в Unity есть вспомогательный скрипт запуска на ruby, но как-то это все странно выглядит… В PlatformIO есть своя встроенная запускалка, которая на ряде проектов меня устраивает, но там многовато гвоздями приколочено и не всем понравится ставить pio только ради запуска тестов.
Подскажите, как сейчас для С/С++ принято тесты организовывать и запускать.
Я в курсе, что большинство просто пишет _write(), и успокаивается что «printf работает». Хотелось бы более полный вариант, с чтением и без блокировок.
Тут нашел такой вариант:
// All credit to Carmine Noviello for this code
// https://github.com/cnoviello/mastering-stm32/blob/master/nucleo-f030R8/system/src/retarget/retarget.c
#include <_ansi.h>
#include <_syslist.h>
#include <errno.h>
#include <sys/time.h>
#include <sys/times.h>
#include <limits.h>
#include <signal.h>
#include <../Inc/retarget.h>
#include <stdint.h>
#include <stdio.h>
#if !defined(OS_USE_SEMIHOSTING)
#define STDIN_FILENO 0
#define STDOUT_FILENO 1
#define STDERR_FILENO 2
UART_HandleTypeDef *gHuart;
void RetargetInit(UART_HandleTypeDef *huart) {
gHuart = huart;
/* Disable I/O buffering for STDOUT stream, so that
* chars are sent out as soon as they are printed. */
setvbuf(stdout, NULL, _IONBF, 0);
}
int _isatty(int fd) {
if (fd >= STDIN_FILENO && fd <= STDERR_FILENO)
return 1;
errno = EBADF;
return 0;
}
int _write(int fd, char* ptr, int len) {
HAL_StatusTypeDef hstatus;
if (fd == STDOUT_FILENO || fd == STDERR_FILENO) {
hstatus = HAL_UART_Transmit(gHuart, (uint8_t *) ptr, len, HAL_MAX_DELAY);
if (hstatus == HAL_OK)
return len;
else
return EIO;
}
errno = EBADF;
return -1;
}
int _close(int fd) {
if (fd >= STDIN_FILENO && fd <= STDERR_FILENO)
return 0;
errno = EBADF;
return -1;
}
int _lseek(int fd, int ptr, int dir) {
(void) fd;
(void) ptr;
(void) dir;
errno = EBADF;
return -1;
}
int _read(int fd, char* ptr, int len) {
HAL_StatusTypeDef hstatus;
if (fd == STDIN_FILENO) {
hstatus = HAL_UART_Receive(gHuart, (uint8_t *) ptr, 1, HAL_MAX_DELAY);
if (hstatus == HAL_OK)
return 1;
else
return EIO;
}
errno = EBADF;
return -1;
}
int _fstat(int fd, struct stat* st) {
if (fd >= STDIN_FILENO && fd <= STDERR_FILENO) {
st->st_mode = S_IFCHR;
return 0;
}
errno = EBADF;
return 0;
}
#endif //#if !defined(OS_USE_SEMIHOSTING)
В нем все замечательно, кроме пары маленьких нюансов:
Минимальный рабочий код, только для printf, выглядит так:
int _write(int fd, char* ptr, int len)
{
CDC_Transmit_FS((uint8_t*)ptr, len);
return len;
}
Интересуют такие вещи:
_read(), конкретно для stm32, того кода что делает куб._read() / _write() или на чахлых эмбедах с newlib больше все равно ничего не дергается? Тот же _is_atty() например._read(), как потом ПРОСТЫМИ способами проверить, что в stdin есть символ (чтобы вызов getchar() не зависал)?Раньше, когда трава была крепче а деревья мягче, во флешках можно было у каждой ячейки «постепенно» затирать битики, чем я активно пользовался для маркировки «многофазных коммитов». Но тут обнаружилось, что на современных контроллерах это не всегда так. Типа, один раз записал, а дальше кури писю до следующего стирания блока. Пишут, что на самом деле в железке битов больше чем видно, за счет кодов коррекции, и в память пишется совсем не то что что видно снаружи. Как-то я отстал от жизни. Это вообще давно и везде так или только в stm32 выпендрились?
Интересует, насколько точно QEMU эмулирует Cortex M0-M4 (или что там есть из простого), и можно ли там считать время выполнения бенчмарка в тактах процессора.
Иногда требуется отслеживать производительность узких мест в библиотеке, а на реальном железе это жутко не практично. Хотелось бы иметь софтовые бенчмарки, но чтобы результат не зависел от машины, на которой это запускается. Подумалось, что это можно попробовать через какой-то эмулятор процессора.
Кто-нибудь решал подобную задачу и возможно ли так вообще? Достаточно простых ядер, без хитровымудренных кешей.
https://github.com/puzrin/dispenser ветки dev и standalone
Скрещиваю stm32cubeMX с PlatformIO. Хочется с одной стороны быстро мышкой валять конфиги, потому что очень много корректировок. А с другой, чтобы с самим проектом было удобно работать, т.к. конфиги - далеко не все.
Ну, в общем, оно работает, но захотелось пойти дальше - отказаться от того stm32cube который идет с pio, и компилять те сорцы которые родит куб. Смысл простой - когда все из одного места, меньше гимора что разъедутся версии инициализаторов и основного кода.
В общем, покопался в сорцах, почитал доку и слепил необходимые скрипты, все в ветке «standalone». И оно даже ок. Но вылезла проблема - видимо я все-таки что-то продолбал, и билд теперь отжирает килобайт оперативки под какую-то пургу «.data.impure_data». Вроде в интернетах народ с таким знаком, и рецепты дает, но я уже сто раз ключики сборки перепроверил, не нашел косяка.
Кто-нибудь может помочь разобраться? Я в сях и Scons совсем жопорук.
Речь о лампах на пантографе, со струбциной. По непонятной мне причине, у светодиодных мощность всего 5-7W (обычно с питанием через USB). Найти мощнее с ходу не получилось. Точнее, нарыл такое, но там уже размер совершенно конский (хотя лампа реально крута).
Хочется компактную, с вращением везде где можно, эдак 20W, c регулировкой яркости. В идеале - еще и с подстройкой цветовой температуры. Цена не критична.
Можете посоветовать какие-то модели?
Хочу совсем мягкие метровый кабель Type-С на 3 ампера. Можно не полноценный, но с поддержкой USB-PD (пины сс0/сс1).
https://ru.aliexpress.com/item/32959147241.html - нашел пока «силиконовые», но они только на 2 ампера, и Type-C только с одного конца.
Можете что-нибудь посоветовать?
Нужно подключить 4-проводной резистивный тачскрин к stm32 (дисплей 320*240 2.4"). Вариантов 2:
Какая-то особая точность не нужна, там интерфейс с большими кнопками, не промажешь.
Если я правильно понимаю, внешний чип позволил бы увеличить точность измерений (за счет дифференциального подключения АЦП), но все равно тайминги надо будет выписывать ручками (задержки после перекоммутации АЦП, фильтрацию). То есть, код проще НЕ станет.
Собсна, вопрос. Если меня устраивает 8 бит точности и не надо мерить силу нажатия, есть ли смысл приворачивать внешний чип? Не то чтобы он мне мешал или денег жалко, просто не могу понять профит.
Ну да, на прямом включении сопротивление ключей GPIO внесет дополнительную погрешность, и пульсации по питанию будут срать. Но вроде это калибровкой и фильтрацией должно порезаться (если на точность 10 бит не замахиваться). Или нет?
Кто-нибудь подрубал мелкие резистивние тачскрины к микроконтроллеру напрямую? Как оно в реальной жизни?
Настало время поплотнее заняться reflow-паялкой. Самый проблемный момент - как примотать керамический нагреватель (MCH 50x50mm 40W) к плате, чтобы она не сильно грелась.
Пробовал всякие китайские аэрогели в качестве прокладок… в общем это фуфломицин. Помимо того что пылит какой-то пудрой, он все-таки нагревается, и потом из-за него керамическая пластина долго остывает.
Решил делать с воздушным зазором. Конвекции вниз особо нет, но остается ИК-излучение. В теории, надо одну сторону нагревателя делать черной, другую зеркальной. Ну из того что я знаю, выбор по материалам не богатый, решил красить.
Верх закатал черной матовой Certa. Низ - Siana HQ зеркальный хром (она единственная в линейке высокотемпературная). Дальше подал напряжение и подносил ладонь на пару сантиметров :). Разница охренеть какая.
Хочется закрепить успех. Что-то этот «зеркальный хром» подозрительный. Поверхность какая угодно, но не зеркальная. И металлическая пыль облетает если пальцем потереть. Может есть какие-то еще способы сделать совсем зеркало, которое бы 300 градусов держало? Меня что угодно устроит, хоть зеркальная пленка на липкой основе, если клей выдержит.
PS. Также буду признателен за совет по клею на 400С. Только не экзотику типа ВК20 который 5 дней сохнет. Надо с алиэкспресса. Хочу панасониковскую графитовую термопленку сверху прилепить, чтобы температуру поверхности выровнять.
Посоветуйте, чем можно обычный float перегнать в строку, с заданной точностью? А то по всяким stackoverflow какие-то васянские снипеты и мутные самоделки с непонятными лицензиями. Сейчас юзаю sprintf, но он помимо жирности кастует float в double, что вызывает дополнтельное распухание зависимостей.
Мне не надо наворотов sprintf, хватило бы просто «распечатать с XX знаками после запятой», можно даже без отрицательных значений. Может есть какие-то известные библиотеки, от которых эмбед не треснет?
PS. Закопипастить 30 строк кода всегда успеется. Сначала хочу попробовать найти и заюзать библиотеку.
https://easyeda.com/puzrin/dispenser
Обнаружил, что накосячил в схеме, и девайс не загнать в режим прошивки по USB. Надо как-то это пофиксить дешево и сердито. Пока задумка такая - поправить джойстик, чтобы вместо земли коротил пины на питание, и подключить boot0 параллельно одному из контактов.
Тогда если воткнуть USB с нажатой кнопкой, то запустится загрузчик. А если просто подать питание, то запустится прошивка и дальше состояние boot0 не должно иметь значения. Но это в теории. А на практике как? Какие-то подобные эффекты? Спрашиваю, потому что ни разу не имел дел с этими чипами.
Ну и минутка рекламы https://github.com/puzrin/dispenser :). Наконец-то покончил с библиотекостроительством, и начал лепить пошивку. С гуями получается довольно бодро. Скриншот в ридми. Фонты генерятся из TTF. Ради этого долго страдал, изобретал новый формат и писал конвертор. Там нормальный кернинг и хинтинг. Если разработчики LVGL осилят, будет еще и субпиксельный рендеринг.
Что приятно - драйверы периферии абстрагированы и все, включая тестирование, делается на десктопе. Очень экономит время. Потом останется только отладить небольшие драйверы железа, и можно пользоваться.
Видел аппноты, на тему «как улучшить точность данных АЦП» для разных микроконтроллеров, но там слишком обще и нет конкретных цифр. Оставим в стороне выключение ядра при работе АЦП и прочие тонкости. Интересует только то, что связано с питанием аналоговой части.
На схемах из интернетов видел такие вещи:
Хотелось бы комментариев:
Хочу разобраться, насколько легко паять LQFP / LGA в хоббийных условиях. Во-первых, потому что акселерометры кроме как в LGA не делают. Во-вторых, некоторые процы доступнее в LQFP, и занимают меньше места.
https://easyeda.com/puzrin/solder-training-board
Накидал плату для тренировок, осталось понять, как паять правильно. Я видел несколько вариантов:
Какие вообще варианты наиболее толерантны к не сильно прямым рукам? И чтобы микроскопа не требовали.
Еще конкретно для LQFP предлагали сначала посадить пузо на висмутовую пасту, а потом по краям паяльником обвести.
И еще есть вопрос насчет центральной площадки под LQFP. Как там лучше расставить отверстия, чтобы излишки припоя стекали?
Нужно подключать к плате ножную педальку, через разъем. Хочется покомпактнее такого.
«просто иголки под 90 градусов» ставить не хочу, т.к. не желательно чтобы торчали открытые, и термоусадку сажать неудобно (чтобы контакты не перекрыла).
Посоветуйте, где еще можно посмотреть, кроме питания и аудио.
https://github.com/puzrin/dispenser
Делаю моторизованный дозатор паяльной пасты. Типа такого. От словацкого будет отличаться тем, что не нужна токарка и возможно не нужен отдельный программатор. От того что выложено на thingiverse - ну там вообще здоровые страховидлы. В общем, цель - сделать мелкую штуку из говна и палок, которую не жалко. Чтобы вместо перестановок шприцов сделать на каждый свой дозатор, и было недорого и просто.
Возник вопрос к пастопаятелям, а какие нужны фичи, чтобы было удобно? Единственный элемент управления - 5-позиционный джойстик-кнопка. Ну и светодиоды.
Пока надумал такое:
- влево-вправо - меняем скорость выдавливания
- вперед - выдавливаем
Под вопросом:
- короткое вперед - выдавливаем фиксированную порцию. Но тут непонятно, можно ли ее менять параллельно со скоростью, т.к. максимум зависит от диаметра иглы и вязкости.
Кто активно юзает хоть какие-нибудь разновидности диспенсеров (ручные, пневмо и т.п.)? Напишите какие у вас типовые задачи.
PS. Я в курсе про трафареты, но на мелких штучных платах дозатором проще. Да и для флюсов тоже удобно.
http://www.opennet.ru/opennews/art.shtml?num=50667
Майкрософт привернул к гитхабу собственные реестры npm, docker, mvn, nuget и gem. Потому что разработкой опенсорсов должны заниматься лохи, а деньги с этого получать те, кто этого достоин :)
https://github.com/littlevgl/lv_font_conv/blob/spec/doc/font_spec.md
Столкнулся с тем, что в эмбедах ну очень стремные шрифты. Векторные на ходу рисовать железки не тянут, а битмапные народ лепит без поддержки кернинга, с убогим сжатием и т.п. В общем, сел писать спецификацию и конвертор. Совсем с нуля колбасить не стал, вытянул ограниченное подмножество из OpenType/TrueType и приспособил под битмапы. Вроде вышло неплохо и достаточно универсально, нохотелось бы чтобы заценили те, кому подобная вещь нужна.
В отличие от u8g2, который точился под совсем чахлые AVR и поддерживает только битональные глифы, данная спека ориентирована больше под ARM и шрифты с анти-алиасингом. Чтобы рисовать красивые интерфейсы вроде Material Design. Но простенькие шрифты для OLED тоже поддерживаются и занимают совсем мало места. Всякие навороты вроде вертикального кернинга для арабского и акцентов, лигатуры и т.п. не поддерживаются «за ненадобностью».
Сам конвертор сделан на node.js и позволяет склеивать несколько шрифтов, менять коды символов, и вырезать только необходимые подмножества глифов. В основном сделано для того, чтобы сливать вместе английский + дополнительные европейские языки + CJK + иконки. Таким образом можно уйти от ада, когда разработчики хранят в репах «шрифты от васяна» с непонятными лицензиями и источником, и заскриптовать генерацию из ttf/woff.
Это все делалось с дальним прицелом под Rust, но поскольку он еще «не совсем готов» для эмбедов, будет использоваться с LittlevGL (надеюсь).
Посмотрите, чего еще не хватает, что не понятно, ну и поиграйтесь с конвертором. Прогресс, прмеры запуска и комментарии по размерам можно посмотреть тут https://github.com/littlevgl/lvgl/issues/995.
| ← назад | следующие → |