Есть забавная библиотека, генерирующая сетку для сортировки. В примере предается размер массива, но не предается тип элементов. Никак не могу понять, как оно тип элементов определяет?
Нужно линковать в проект библиотеку с кривым именем, без префикса lib* (ну так получилось). Это без проблем делается, если к -l добавить двоеточее. Но почему-то не получается найти в документации официальное описание этой фичи.
Надо печатать этикетки на вот такие пипирки, куда ссыпаются SMD-компоненты. Размер стикера ~ 12*22мм, 2-3 строки.
Есть Epson LW-400 и Brother PT-H105, но с ними некоторые нюансы…
Стандартные расходники от круглой поверхности постепенно отклеиваются. А продвинутый выбор есть только для Brother.
С выбором размера шрифтов и выравниванием у эпсона немного жопа, а у бразера жопа размером с дом.
Я уже раскатал губень купить новый Brother PT-P300BT, на котором можно с мобильника печатать, но к счастью сначала поставил андроидовское приложение поиграться. За такие интерфейсы надо отрывать руки и выдавливать глаза.
Пока заказал D11 поиграться (не жалко, если что), но там выбор расходников не очень.
Посоветуйте, что мелкое можно взять под мою задачу, с подходящим расходниками (которые будут намертво клеиться). Желательно без возни с линуксовыми драйверами и т.п. Мне вполне подойдет с мобильника 3 строки текста набить. И покомпактнее, т.к. этикетки надо печатать раз в пол года, и заводить офисный принтер мне нафик не вперлось.
Есть P-регулятор для моторчика, и датчик скорости. Надо примерно на средних оборотах автоматически подбирать максимально возможное значение P «пока не задергается».
Ну то то половинным делением подбираем - понятно. Однако вопрос, как проверить наличие колебаний, желательно без магических констант, и максимально быстро.
Существуют ли какие-то проверенные алгоритмы? (налисапедить-то можно, но хотелось бы разобраться, и не гулять по граблям).
Я часто топлю за PlatformIO для кодинга под эмбеды. Оказывается они те еще затейники. Реестр пакетов отдает только последние 30 версий. То есть, зашпилили версии зависимостей, поставили тег, зарелизили фирмварь. А через пол годика хренак - и какая-нибудь зависимость перестала подтягиваться.
Правда весело :) ?
Вообще они ребята хорошие, и ответы дают внятные. Тут тоже сказали, что через месяцок разберутся, гы :).
На Nexus 6P в декабре официально перестали приходить апдейты. Что весьма досадно, специально ведь выбирал с прошивкой «от самого гугла». Посоветуйте аналогичную лопату на замену, только с камерой получше. А то как начинаю погружаться в обзоры, голова пухнет.
Мне НЕ нужна какая-то особая производительность, 2000 герц рефреш экрана и т.п. Интересует:
Чтобы security updates приходили долго
NFC
Камера
В идеале, чтобы умела делать снимки вблизи (макро) и в темноте, но можно и без этого.
Есть тиристорный регулятор для коллекторника переменного тока (с последовательным возбуждением). В настойщий момент там PI-регулятор, работающий от ошибки скорости, плюс колхозная линеаризация параметров мотора. Все это работает, но… so-so…
Теоретически, если взять стенд, и для всех нагрузок/скоростей построить функцию
F(скорость, момент) => фаза симистора
то можно по такой табличке рулить с очень хорошей стабильностью.
скорость и момент мы опредлять умеем, оставим это за скобками
Но поскольку стенда нет, то хочется взять корявый тормозной PID, и на ходу подстраивать табличку. Если в табличке есть подходящие параметры - берем напрямую, минуя пид. Если нет - тогда на основе пида, и по мере подстройки запоминаем к чему стремиться, чтобы в следующий раз не ждать пока пид устаканится.
Я не знаю, как это описать красивыми и правильными словами, но по-моему должны быть готовые решения для таких адаптивных систем. Подскажите пожалуйста, куда копать.
PS. Речь о регуле бормашинки. По задумке, когда ей начнут бормашинить, она постепенно начнет держать обороты все лучше и лучше. Как-то так.
Сориентируйте пожалуйста, на какого класса задачах используют watchdog и типовые паттерны его приворачивания. Я в общих чертах понимаю что это такое, но не знаю критериев целесообразности.
Проекты хоббийные, на stm32, не медицина-космос. Но может в 2020 уже стало правилом хорошего тона обязательно whatchdog втыкать? Вам приходилось сталкиваться в реальной жизни, когда наличие whatchdog действительно помогало?
Есть актуальная задача - запитываться от USB зарядника, выбрав нужную мощность. Бывают конечно «триггеры», но во-первых они не всегда удобны, во-вторых не поддерживают PPS. Короче, готовые триггеры для встраивания - не очень. Интересно было бы поставить FUSB302 или юзать STM32G071 со встроенным интерфейсом.
К сожалению, с готовыми библиотеками проблема - либо блобы, как у ST, либо кривая лицензия как у ON, Microchip и т.п. Либо нужна операционка как у Google. И т.п. То есть такого, чтобы просто взять опенсорсную библиотеку и воткнуть ее в проект - нет. А хочется.
Кто-нибудь может взяться сделать свой лисапед, объяв разумом текущие наработки? Полноценной поддержки всех фич USB-PD не надо. Только 1 порт, и только потребитель (sink). С возможностью выбора PPS профиля. Если остального не делать, объем кода сильно уменьшается.
Нужна именно библиотека, чтобы ее могли юзать все желающие. То есть, без привязки к конкретной оси и приложению. Хотя, если что-то совсем микроскопическое вроде прототредов, то можно.
Стандартная задача на мелких эмбедах - из прерываний стугать сообщения, чтобы их потом уже в main loop разгребали по мере возможности (но без фатальных залипов). Многозадачку тащить не хочется.
Естественно, у каждой очереди на концах по одному отправителю и получателю, чтобы не искать приключений. Вместо «collision resolution» => «collision avoidance», ценой небольшого резервирования памяти (на «щели» в очереди). Объясните пожалуйста на примере stm32:
в какой момент с queue начнутся проблемы, и понадобится заморачиваться с более серьезными блокировками?
На M0-M4 для пересылки структур обычная очередь проканает, или там тоже out of order на запись в память лезет?
зачем надо было городить queue_spsc_locked, которому надо просовывать блокировщики, если queue_spsc_atomiс вроде и так работает?
Мне нужно написать функцию с длинной логикой, которая иногда «примораживается» до следующего тика таймера. Фактически - генератор, без необходимости заботиться о локальных переменных. Через switch получается уродски.
Нашел вот такой пример https://gist.github.com/mfoliveira/957805, он хорош, но работает только с GCC. Можно ли вместо указателей на метки использовать setjmp/longjmp? Вот так:
#define yield_start() if (YIELD_ENV != NULL) longjmp(YIELD_ENV, 1);
#define yield(val) if (!setjmp(YIELD_ENV)) return val;
#define yield_end() YIELD_ENV = NULL;
В спеке сказано, что если функция, вызвавшая setjmp() завершилась, то поведение longjmp() не определено. А мне как раз надо чтобы после следующего вызова выполнение продолжилось с места yield().
Тут возможны какие-то косяки кроме потери локальных переменных (меня это устраивает)? Меня и оригинальный вариант устраивает, но интересно разобраться.
static jump_buf YIELD_ENV = NULL;
bool tick() {
yield_begin();
while (!wait_knob_dial.tick()) { yield(false); }
while (!calibrate_static.tick()) { yield(true); }
while (!calibrate_speed.tick()) { yield(true); }
while (!calibrate_pid.tick()) { yield(true); }
yield_end();
return false;
}
PS. Мне нужна очень простая функциональность, не надо предлагать корутины из буста и прототреды. Не хочу лишние зависимости тащить вместо десятка строк кода.
Я активно использую sdl2 чтобы писать прошивки на PC, без реального железа. Все работает, но хотелось бы использовать 32-битный билд чтобы монитор памяти показывал значения более близкие к реальному железу (stm32). Это из-за того, что много структур с указателями, и если они разного размера, то набегает разница в полтора раза. Проблема в том, что все собирается, но при запуске падает с ошибкой
dbus[30505]: arguments to dbus_message_new_method_call() were incorrect, assertion "path != NULL" failed in file ../../../dbus/dbus-message.c line 1362.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
По ссылке - инструкция как воспроизвести в vscode (при открытии проекта все зависимости поставятся автоматически).
Всем привет из криокамеры. Сегодня на одном из компов переставлял линукс, и обнаружил что дропбокс окончательно всё. В 2018 они покоцали синхронизацию шифрованных файлов. А в 2019 - симлинки. Плюс бесплатные аккаунты ограничили 3 девайсами.
Как-то это совсем грустно. Чем можно заменить? В идеале, чтобы на удаленке не надо было сервер разворачивать, а хватало чего-нибудь вроде гуглодиска. Ну или какой-нибудь готовый образ для digitaloсean и т.п.
Вроде подобия дропбокса делали очень активно, но я не отслеживал, как они продвинулись и что лучше смотреть. Посоветуйте что-нибудь.
Хотелось бы заюзать STM32G431RBT6, чтобы трохи сократить обвеса. Но ST, middleware для power delivery распространяет под STM32G исключительно в виде блоба.
Выглядит это как-то диковато, но они на полном серьезе такое педлагают. Тащить себе такое в проект не хочется. Может кто-нибудь уже портировал гугловский стек под семейства STM32G?
Хочется состыковать девайс с FLASH по USB, чтобы легко править конфиги и читать логи.
Все что удалось найти из простого - имплементации USB MSC HOST. Но по-моему они не заморачиваются насчет ресурса флешки, а ставить EEPROM я не хочу, там за вменяемые деньги только 64 килобайта.
Можете посоветовать годные библиотеки, которые можно было бы юзать именно с флешками (мелкими 8-выводными SPI)?
Хочется странного. Экспериментирую со 100-ваттными нагревателями, питаю через дешевый диммер с али за пару баксов. Немного неудобно, что ручка в середине реагирует слишком резко, а в конце совсем никак.
Может бывают диммеры, чтобы на нагреватель выдавали мощу примерно пропорционально ручке? Ну не лепить же свой (еще не настолько пригорело).
PS. Вообще у нагревателя еще сопротивление в 2 раза меняется по мере разогрева, но это можно не учитывать.
После JS, где берем mocha и фигачим тесты, на сшечке не совсем понятно, как добиться такой же простоты:
Написать функции с тестами не сложно, но потом вписывать каждую в main и следить что ничего не забыл как-то напряжно.
Иногда хочется напилить тесты на несколько файлов (как минимум для разных конфигов), но при этом иметь единый отчет.
Инструкции сборки надо как-то описывать, и не хотелось бы для каждого теста с этим уродоваться.
Coverage reports надо.
В общем, хотелось бы как в жыэс, тратить время именно на написание тестов, а не на то чтобы думать как их запустить.
Я видел что в Unity есть вспомогательный скрипт запуска на ruby, но как-то это все странно выглядит… В PlatformIO есть своя встроенная запускалка, которая на ряде проектов меня устраивает, но там многовато гвоздями приколочено и не всем понравится ставить pio только ради запуска тестов.
Подскажите, как сейчас для С/С++ принято тесты организовывать и запускать.
// 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)
В нем все замечательно, кроме пары маленьких нюансов:
Он не работает :). Там везде проверки, чтобы отличать дескрипторы 0, 1, 2 от реальных файлов, а на практике в функции прилетают другие значения (ну то есть без проверки ок, а с ней не пашет). Мне конечно файлы без надобности, но просто интересно понять, почему так.
Тот пример для UART, а мне надо для USB CDC Middleware из stm32cube. Особенно интересует, как делать не блокирующее чтение с автоматическим echo в терминале.
Минимальный рабочий код, только для 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() не зависал)?
Есть ли альтернативные реализации USB CDC поверх HAL/LL? Та что в кубе - не нравится, жрет како-то дикое количество памяти под конфигурацию ендпоинтов. Может я чего-то не понимаю, но по-моему выделять память под 15 параметров для каждого EP обычного COM-порта это перебор. В итоге при буфере 512 байт оно жрет еще 2К под какую-то хрень. Не то чтобы мне критично… так… слегка обидно :)
Раньше, когда трава была крепче а деревья мягче, во флешках можно было у каждой ячейки «постепенно» затирать битики, чем я активно пользовался для маркировки «многофазных коммитов». Но тут обнаружилось, что на современных контроллерах это не всегда так. Типа, один раз записал, а дальше кури писю до следующего стирания блока. Пишут, что на самом деле в железке битов больше чем видно, за счет кодов коррекции, и в память пишется совсем не то что что видно снаружи. Как-то я отстал от жизни. Это вообще давно и везде так или только в stm32 выпендрились?