?

Log in

No account? Create an account
Костерок

eddy_em


Емельянов Эдуард Владимирович


[sticky post]Содержание
Костерок
eddy_em
Здесь - краткое содержание моего графоманстваCollapse )

promo eddy_em january 20, 18:17 Leave a comment
Buy for 10 tokens
Пока проводил опыты с чиллером (графики позже выложу), почти закончил свою часть документации. Табличку с настройками драйверов ШД сделаю, когда буду в очередной раз разбирать прибор (забыл сразу эти данные куда-нибудь схоронить). Можно сразу скачать PDF, чтобы не клонировать себе всю репу.

Вундервафля
Костерок
eddy_em
Меня долго душила жаба, но таки удушил ее я и купил за 11 баксов на али переходник LQFP48 на DIP. Давно хотел сделать простую приспособу, при помощи которой можно было бы без пайки работать с микроконтроллерами в этом корпусе. STM32F0x2 и STM32F103 по ногам практически совпадают (как впоследствии оказалось, не на столько, на сколько бы хотелось ☹).
Железяка за работой

Ну и, конечно, файлы на гитхабе: схема и трассировка самой платы, код для STM32F0x2 (полностью рабочий) и зачатки кода для STM32F103.
Read more...Collapse )

Проблема с пинами PA13..PA15 на STM32F103
Костерок
eddy_em
Бьюсь-бьюсь, да что-то не выходит! Сделал "вундервафлю" (про нее позже напишу) для работы с STM32F0x2 и STM32F103 в LQFP48 без пайки. Проверил все 10 STM32F072, купленных на али — все работают (как ни странно), да еще и dfu-util почему-то 128кБ флеша у них показал вместо положенных 64...
Стал модифицировать прошивку для работы с STM32F103. И тут-то выползла засада: у него на PA13..PA15 висит нафиг не нужный SWD/JTAG, а я на "вундервафле" на PA13 повесил внешнюю подтяжку USBDP (т.к. у F103 внутренняя отсутствует), а на PA14/15 — кнопки! Вот такой код
static void gpio_setup(void){
    // Enable clocks to the GPIO subsystems, turn on AFIO clocking to disable SWD/JTAG
    RCC->APB2ENR |= RCC_APB2ENR_IOPAEN | RCC_APB2ENR_AFIOEN;
    // turn off SWJ/JTAG
    AFIO->MAPR = AFIO_MAPR_SWJ_CFG_DISABLE;
    // turn off USB pullup
    pin_set(GPIOA, 1<<13);
    // Set leds (PA0/PA4) as opendrain output
    GPIOA->CRL = CRL(0, CNF_ODOUTPUT|MODE_SLOW) | CRL(4, CNF_ODOUTPUT|MODE_SLOW);
    // Set buttons (PA14/15) as inputs with weak pullups, USB pullup (PA13) - opendrain output
    GPIOA->ODR = (1<<14)|(1<<15); // pullups
    GPIOA->CRH = CRH(13, CNF_ODOUTPUT|MODE_SLOW) | CRH(14, CNF_PUDINPUT|MODE_INPUT) | CRH(15, CNF_PUDINPUT|MODE_INPUT);
}

не спасает: почему-то ни кнопки не работают, ни подтяжка... Буду гуглить дальше, хотя, вроде бы, требовалось всего лишь отключить ненужные интерфейсы, предварительно затактировав шину AFIO.

UPD: отбой, это я нарукожопил в инициализации uart:
GPIOA->CRH = CRH(9, CNF_AFPP|MODE_NORMAL) | CRH(10, CNF_FLINPUT|MODE_INPUT);

(вместо |= поставил =, в итоге настройки "слетали" в дефолт).

Теперь ковыряюсь с STM32F103. Оказалось, что у него на PA4 нет вывода TIM14CH1, пришлось просто мыргать вторым светодиодом тоже. До USB пока далеко — пытаюсь с АЦП разобраться, что-то не выходит пока.
Код под STM32F103.

Мини-ремонт
Костерок
eddy_em
Празднички что-то подзатянулись. И решили мы купленные еще в январе обои наклеить на ободранную кошаками стенку. Еще одной проблемой было то, что современные обои — какой-то прозрачный мрак! А уж тот флизелин, что мы брали в зал, вообще кошмарен! И вот самую видную стенку было решено оклеить виниловыми обоями.
Изначальный вид стены после снятия обоев.

Еще фотографииCollapse )

libmmpp
Костерок
eddy_em
Так как мы с Тимуром решили, что управление MMPP надо в корне переделать на основе "настоящей" клиент-серверной архитектуры, для облегчения жизни Тимуру я написал библиотеку, которая сочетает в себе все возможности HSFW_management и MMPP_control (в дву примерах к библиотеке).
Опакетил ее, но с этим, конечно, намучился: все не мог понять, чего оно у меня примеры не ставит по emerge libmmpp при активном флаге examples. Косяк был в CMakeLists.txt: я там проверял флаг на равенство 1, а на самом деле он равен "yes". Просто выкинул проверку (все равно либо флаг установлен, либо нет).
Теперь можно будет заняться чем-нибудь другим. Например, написать уже библиотеку для веб-морд (на основе вебсокетов и БД в sqlite): полуметровые робото-телескопы сгниют скоро, а так не роботизированы до сих пор...

USB мышь + клавиатура на STM32F0x2
Костерок
eddy_em
С рядом проблем, но таки удалось победить USB HID на STM32. С оптимизацией -O2 прошивка занимает 4.8кБ, оптимизация -Os уменьшает ее до 4.1кБ (но -Os лучше не пользоваться).
Как и в старом примере под STM32F103 с использованием opencm3 просто эмулируется составное HID-устройство: мышь + клавиатура. Командой 'M' в терминале можно сдвинуть курсор мыши, а командой 'K' — вывести на печать фразу "Hello!". Теперь-то моя душенька довольна и можно заняться написанием libMMPP — библиотеки для управления фотометром (Тимур все-таки согласился с тем, что нужно реализовать клиент-серверную архитектуру управления прибором, а чтобы не дергать постоянно внешние утилиты, нужно реализовать все функции MMPP_control и HSFW_manage в отдельной библиотеке).
UPD. Разобрался с косяками и устранил их. Дескрипторы пока не менял — и так нормально работает, но можно при желании заменить на дескрипторы реального устройства такого типа (хотел из дома взять радиоприемник от пары мыша+клавиатура, но забыл).
В прошлой реализации после каждого кода клавиши я посылал код ее отпускания, но теперь сделал продвинутую версию: код отпускания посылается лишь если повторно ту же клавишу нужно нажать, а также в конце строки. Получилось 950 символов в секунду — почти предел для такого способа (с учетом, что каждый пакет идет с интервалом в 1мс). Можно было бы еще круче сделать: забивать все 6 символов поочередно, а затем сдвигать (как будто бы отпускать кнопки начинают лишь когда уже кнопок нажато, и отпуская первую нажимают очередную), очищая буфер лишь в конце, а также при повторе символа. Но это ж думать надо...

Допиливание "эмулятора" PL2303
Костерок
eddy_em
Почти добил нормальный USB CDC на STM32F0x2. Решил проблему с отправкой слишком большого потока данных, "причесал" код (заменил уйму if/else if на switch). Вот только вылезла непонятная ошибка: если в обработчике linecoding_handler сразу выводить show_new_lc() (отображение новых параметров), то появляется ругань на vendor_write:
pl2303 ttyUSB1: pl2303_vendor_write - failed to write [0000]: -32

но если же я делаю, как сейчас (т.е. вывожу эти данные вне прерывания USB), появляется другая ругань:
pl2303 ttyUSB1: pl2303_set_line_request - failed: -32

Однако, ioctl на смену режима работы не возвращает ошибку. Долго втыкал в код модуля pl2303.c, но так и не понял, каким образом небольшая задержка может в одном случае возвращать ошибку на vendor_write, а в другом случае — на set_line_request!
Ну да ладно, если кто подскажет, как это исправить — хорошо. Нет — все равно оно превосходно работает, и занимает сравнительно немного места. Остается лишь на STM32F103 портировать.
На игровых приставках не проверял, все равно я с их прошивками не работаю. Возможно, будет даже на них работать.

Вот это поворот...
Костерок
eddy_em
Помаленьку делаю рефакторинг эмулятора PL2303 на STM32F042. Для начала пофиксил баг с отправлением большого буфера. И наткнулся на непонятную штуку: если собрать после make clean, получаю:
   text    data     bss     dec     hex filename
   5548      16    1560    7124    1bd4 mk/pl2303.elf

Теперь просто делаем touch на какой-нибудь сишный файл и опять запускаем make:
   text    data     bss     dec     hex filename
   5548      16    1556    7120    1bd0 mk/pl2303.elf

Что за чудеса в решете? (до этого у меня еще и менялись размеры elf'а и выходного hex'а!)
qt-creator что ли шутит так? (пришлось, кстати, откатиться на 4.6.2, т.к. в 4.8.0. ничего не работает).
P.S. Вот, просто сохранил, поменяв константу, потом поменял обратно и получил:
   text    data     bss     dec     hex filename
   6148      16    1556    7720    1e28 mk/pl2303.elf

UPD Такое впечатление, что у gcc какой-то ccache не обновляется... (хотя, по идее, ccache должно только с emerge работать). Черт подери! Оба бинарника, если прошивать в МК, работают! Несмотря на разницу в размере!!! Да откуда ж эта чертовщина берется-то???

Адрес буфера CAN на STM32F0x2 - где?
Костерок
eddy_em
Уже час копаюсь в RM. Пытаюсь найти, где же определяется, откуда в буфере USB_PMAADDR будет находиться буфер CAN (хочу в инициализацию USB проверить, не пересекаются ли они, если CAN активен). И фигвам! Вообще ничего не вижу, что этот буфер делится между CAN и USB (хотя где-то уже читал, что с 768 байта начинается буфер CAN, судя по комментариям в коде; но теперь не могу найти этому подтверждения в RM!).

Еще упаковочка...
Костерок
eddy_em
На сей раз противоположный эффект. Микроконтроллеры (которые, вообще-то, статики боятся) просто приклеили скотчем к картонке:

(купил на пробу STM32F072C8T6, продавец даже трек прислал, а вот упаковать по-человечески не смог; как-нибудь надо нарисовать и изготовить девборду для них и уже переносить свои поделки с 030 на эти, дороже они всего лишь на 20-25 рублей, зато нет геморроя с ch340 или другими конвертерами USB<>UART)