eddy_em | Entries tagged with stm32

Редко так бывает, чтобы сначала код написал, а потом нарисовал плату, но сейчас почти так. Почти — потому как я все же решил еще добавить USART для возможности прямого подключения к контроллеру SidServo (пусть будет эдакая универсальная плата). Заодно можно будет проверить: действительно ли нужно слать туда данные не больше 20 раз в секунду, или можно почаще.
( Картинки )
Теперь можно обратно вернуться к завершению разработки СУ монтировкой. Две недели уже прошло с последнего коммита… Там, правда, еще и БТА, но, как обычно: "мелкие" — по вечерам, "большие" — днем.

На прошлой неделе я на макетке спаял модуль для снятия данных с 26-разрядных абсолютных угловых энкодеров по протоколу BISS-C. Отладил в четверг вечером код, чтобы уж точно оба SPI работали (поначалу не мог понять, что за дичь со вторым SPI, но тут заметил, что я оставил от USB-шаблона работу с USART1, который тот же самый канал DMA использует, что и SPI2); в пятницу установил этот блок (но, судя по всему, опять оторвал один из тонких проводков от энкодера; как только кончатся эти долбаные дожди, надо будет смотаться и перепаять все нормально, чтобы уж точно не рвалось). Напомню, что решение напрямую в USB считывать показания датчиков возникло из-за того, что родная астросибовская "коробочка" читает лишь каждые 50мс, а мне минимум 100 раз в секунду надо (а, может, и тысячу — это уж как покажут эксперименты после соединения всего воедино).
В понедельник честно воспользовался выходным, а вчера и сегодня дорабатывал прошивку для работы с энкодерами.
( Дальше )
Завтра еще подумаю, что нужно, чтобы "добить" код до хотя бы пре-релиза, а потом сяду очередную плату нарисовать. Многоканальный (7 каналов) преобразователь USB-serial с гальваноразвязками на каждый канал уже нарисовал, теперь надо вот это сделать (тоже с гальваноразвязками на энкодеры, чтобы не спалить их в случае чего). Ну и останется еще нарисовать платку для работы с ИК-датчиками (простой преобразователь I2C в RS-485 с развязкой) и датчиками грозы (там развязка не нужна, взял бы "стандартный" преобразователь I2C-USB, но в случае зависания датчика надо сбрасывать питание; удобней это по протоколу делать, а не отрубая USB — тем паче, не у всех компьютеров питание USB можно отключить).

Собственно, вот: "новый подход" к USB. Вынес базовую часть, общую для "всего на свете" в usb_lib.c; дескрипторы с функцией их выдачи — usb_descr.c (функции записи пришлось туда пихать, т.к. sizeof() не хочет между файлами работать); базовый функционал — usb_dev.c.
Реализовал HID, CDC, PL2303 и 7 CDC "в одном флаконе". С последним хотел буфер максимально использовать, однако, в отладке увидел, что ни хрена хост не хочет по 22 байта присылать/отправлять, а упорно присылает лишь по 16 (а когда пытаешься ему 22 отправить, вообще считает этой ошибкой, несмотря на то, что в дескрипторах конечных точек указано 22 и lsusb это отображает). Баг какой-то в libusb, наверное (а то и в ядре).
Теперь остается это дело испытать на F0x2 и F303, и можно будет в "snippets" переместить.

Еще, возможно, полезно было бы MSD сделать (чтобы вообще по-максимуму настройки упростить: тупо открываешь файл, да читаешь/пишешь, а как файл с новыми записями сохранил, МК это во флеш-памяти обновит). Но пока что-то не хочется лезть в дебри блочных устройств и, тем более, файловых систем. На гитхабе есть проект littlefs (вроде как вообще достаточно компактная штука), и она вроде как через FUSE в линуксе работает. Но интересней было бы, конечно, выдрать из какого-нибудь ядра v1.0.0 модуль ext2 и портировать на микроконтроллеры — уж эта ФС однозначно "из коробки" в любом линуксе будет работать.

Решил я еще в прошлом году "унифицировать" USB, чтобы проще было, если вдруг надумаю какое-то "эдакое" устройство сделать. Выкладываю на гитхаб помаленьку (HID, CDC и эмуляция PL2303). Пока только на F103. Если сегодня допишу составное устройство (7 USB-CDC в одном флаконе), то как-нибудь опробую всю четверку на F072 и F303.
Пока только один непонятный косяк: сразу после подключения неизменно вылезает:

string descriptor 0 read error: -75

и иногда

clear tt 2 (82a0) error -32

Но в дальнейшем проблем нет. ХЗ, что за причина этих ошибок. В отладочном выхлопе вообще проблем нет: пришел запрос — тут же на него ответ ушел. Правда, почему-то дескрипторы запрашиваются хостом по 2-3 раза. И в ответах на строковые дескрипторы wireshark иной раз ZLP показывает, хотя в отладке никаких ZLP не вижу, там что запросили, то и отправилось.

А еще, какой-то другой лютый косяк, который я отметил еще на CDC: хоть я и даю текстовый дескриптор интерфейса, в /dev/ udev не создает симлинк с этим дескриптором (чтобы различать интерфейсы составного устройства). Вижу, что udev мой скрипт проходит, т.к. появляется переменная, а вот симлинк - хрен!

Вот такой скрипт (может, кому пригодится):

ACTION=="add", DRIVERS=="usb", ENV{USB_IDS}="%s{idVendor}:%s{idProduct}"
ACTION=="add", ENV{USB_IDS}=="067b:2303", ATTRS{interface}=="?*", PROGRAM="/bin/bash -c \"ls /dev | grep $attr{interface} | wc -l \"", SYMLINK+="$attr{interface}%c", MODE="0666", GROUP="tty"
ACTION=="add", ENV{USB_IDS}=="0483:5740", ATTRS{interface}=="?*", PROGRAM="/bin/bash -c \"ls /dev | grep $attr{interface} | wc -l \"", SYMLINK+="$attr{interface}%c", MODE="0666", GROUP="tty"

(правда, ХЗ, зачем я вообще этот USB_IDS делаю, если есть готовый ID_SERIAL).
Пытаюсь глянуть этот "interface" в

udevadm info --attribute-walk --name=/dev/ttyACM0

- нет ничего…

Покуда автогидом заняться не могу (его элементарно все никак не соберут до окончательного варианта, чтобы я мог уже заняться управлением моторчиками и отладкой алгоритмов на стенде), разработал очередную железяку для СУ БТА: контроллер микрометра на основе холловского датчика "Novotechnik TFD-4000". Нужны эти железки для того, чтобы измерять толщину масляной пленки в азимутальном подшипнике БТА (минимум нужно в трех опорах измерять, но лучше во всех шести).
( Подробней )

Пока с заглушками, ковыряюсь. Читаю исходник модуля ядра и не понимаю: функция usb_xfer принимает массив структур i2c_msg. У каждой структуры есть поле адреса, соответственно, подразумевается, что каждая такая посылка должна начинаться со START, потом отправка адреса, а заканчиваться выставлением STOP. По крайней мере, именно так я и реализовывал все функции работы с I2C на STM32. А тут — в начале выставляют START, потом пишут/читают все N сообщений, и лишь затем STOP! Неужели оно так будет работать? Что-то сомневаюсь… Посмотрел исходники "robotfuzz" — там та же бодяга, только, похоже, START выставляют на каждое сообщение, а вот STOP — только в самом конце.
Полезу ка, почитаю мануал на МК: вдруг так правда можно?
( tl;dr )
В общем, ближе к выходным еще повожусь с железякой. Основная задумка — попытаться на ее VID/PID поднять CDC. Понятно, что эмуляцию PL2303, увы, уже так не сделать, но вот "обычный унылый" /dev/ttyACMx, возможно, получится. Вот тогда все будет замечательно. А если нет, то хорошо бы поискать, существуют ли вообще среди простых STM32 МК, которые не приколачивают гвоздями в регистры USB номер, полученный при энумерации — чтобы можно было на них эмулировать USB hub.

P.S. Кстати, слышал обидную новость: нацик выкинул из ядра поддержку reiserfs. Уныло, однако. Теперь уж точно придется до определенной версии ядро заморозить. А когда уже HDD или SDD с корнем помрут — ставить систему почти с нуля, но уже на другую ФС. Правда, я понятия не имею, какую ФС сейчас для корня использовать. Не ублюдскую же ext4! Да и где гарантии, что с той же ZFS не поступят аналогично, как с reiserfs?

Ковыряю помаленьку. Собрал модуль ядра для i2c-tiny-usb, проверю на "заглушке". Потом добавлю оставшийся функционал, чтобы работало и I2C. Зачем-то там инициировали interrupt endpoing, но она вообще не используется.
Однако, как-то не нравится мне эта побайтовая работа. В исходниках нашел еще и модуль robotfuzz-osif — здесь все более вменяемо, можно читать-писать + есть вызов установки скорости. Правда, автор модуля ядра тоже тяп-ляп навалял: большие объемы не прочитаешь (хотя, судя по командам железки, там есть такая возможность: читать-читать, а потом отправить STOP), да еще и гвоздями прибита скорость: в самом модуле выставляется только 100кГц — и больше ничего (а могли бы параметром модуля выделить; я, конечно, могу модуль переделать, как надо, но кто его поддерживать будет? Ну, а т.к. Линус оказался нациком, то никаких коммитов от российских разработчиков он принимать не будет).
Ладно, пока что tiny добью, а потом, если будет желание, попробую и этот robotfuzz реализовать.

Правда, меня ждало охрененное разочарование: STM32 жестко привязывает номер после энумерации, поэтому играть роль виртуального хаба (чтобы на борту было несколько устройств с разными VID/PID) не может. Потом, конечно, можно будет попробовать - а не выйдет ли просто сделать составное устройство. Правда, ХЗ, каким чертом привязать к этому VID/PID еще и модуль pl2303, чтобы помимо интерфейса I2C было и всякое разное.

А тем временем на алике обнаружил cp2112. Полистал исходник модуля ядра — оно точно так же создает устройство /dev/i2c-xxx, с которым можно работать, как и с прочими шинами I2C. Купил, пощупаю. Думаю, это будет самым простым вариантом аппаратно что-нибудь I2C'шное к компьютеру подключить. Ну, а с составным устройством когда-нибудь потом поиграюсь, хоть и надежды особой нет.

Я уже писал о сложностях с одноплатниками: то флешка сдохнет ни с того, ни с сего, то еще какая беда… А надо I2C'шные устройства обслуживать: те же ИК-детекторы и датчики грозы. Понятно, что в случае с ИК нужно будет городить на STM32 переходник I2C-RS232 или RS485, да выдумывать протокол. А вот датчик грозы можно прямо рядом с компьютером прилепить: купол из пластика не должен электромагнитным волнам мешать. И тут-то подумалось: наверняка ведь есть аппаратные преобразователи, имеющие готовые модули ядра, чтобы ОС их видела как "стандартные I2C", и работать можно было бы при помощи того же самого кода, что и на одноплатниках. И, казалось бы, таких устройств гора должна быть, ан нет: нашел лишь I2C tiny USB. На убогой аврке. Ну, думаю: уж за полдня-то я, наверное, на STM32 реализую нужное USB устройство, был бы протокол! А вот хрен: нет описания протокола в репозитории. А ковыряться в тонне чужих исходников (в т.ч. и кернельного модуля) мне откровенно лень.
В общем, будет у меня очередная поделка с самописным протоколом, одинаковым и для USB, и для 232/485 (чтобы хоть здесь как-то попроще было). Вот здесь даже описан протокол еще одного переходника I2C-USB на основе FTDI. А здесь есть модуль ядра для какого-то преобразователя на основе CH341A тоже с интерфейсом CDC.
В принципе, в /usr/src/linux/drivers/i2c/busses/ достаточно много чего. Лень просто ковыряться, но, возможно, тоже какой-нибудь вполне себе преобразователь поверх CDC поддерживается. В принципе, можно даже убогий HID реализовать, просто уж больно это медленно. А вот что-то посложней я еще ни разу не делал, боюсь, с чтением исходников модуля и попытками наваять, угроблю слишком много времени. Поэтому, пусть будет CDC, только с протоколом, под который уже готовый модуль ядра есть.

Дорисовал-таки. Из не вошедшего в схему лишь три резистора-перемычки. И если смысл перемычек формата 0603 мне вообще непонятен (под ними нет дорожек, а замена их на резисторы с сопротивлением ничего не даст, наверное — сдувать их с платы уж совсем нафиг-нафиг), то перемычка перемычка 1210 между земляным полигоном и землей аналоговых выходов, наверное, должна была быть мини-дросселем или ферритовой бусиной.
В остальном — косяк на косяке и косяком погоняет. Под катом приведу картинки (целиком картинку схемы не выйдет, дюже огромная, придется бить на функциональные узлы).
( Веселые картинки )
Ну, вроде высказался. В своей прошивке я не касался ЦАП, но если понадобится, и этот блок добавлю. Все остальное, как уже раньше писал, реализовал. И из вообще никчемного куска дерьма хоть нечто более-менее полезное получилось: любой может запрограммировать МК на С под свои нужды, особенно имея базовый код. А вот изучать быдло-недо-ЯП и пытаться мышкой надрочить из-под маздая в какой-то сугубо проприетарной и фашисткой среде… Нет уж, это не для людей!

Отвечал в комментарии, но решил отдельным постом сделать. А то некоторые упорно продолжают твердить, что для хранения настроек нужно обязательно внешнюю EEPROM подцеплять, как будто бы "родной" флеш МК чем-то хуже.

У STM32F103VCT6 аж 256кБ флеша (а у меня из трех в одной вообще VET6!). Отнимаем менее 16кБ прошивки, получаем 240 страниц по 1кБ, доступных в качестве хранилища. ST обещают не меньше 10000 циклов перезаписи флеша, а т.к. для записи его сначала стереть надо, получаем 5000. Пусть у нас огромнейший конфиг, которому аж 256Б надо. В этом случае "за один присест" мы можем во флеш вогнать 959 записей (минус один, т.к. в самую последнюю ячейку я не пишу, чтобы всегда был свободный "хвост"). Как место кончилось, стираем, и пишем по-новой. Итого: 5000·959=4795000 записей. Как я говорил, для наихудших условий предположим, что в сутки надо 100 записей делать. ОК, делим, получаем 47950, т.е. 131 год!!!
Человек столько не проживет, куда уж железке? Железку максимум на 15 лет рассчитываем. В этом случае 4795000/5479=875 записей в сутки!!!
Вот с STM32F103C6T6 чутка похуже. Но там у меня обычно и конфиги от силы 64 байт. И переписываются они крайне редко. Выходит, что даже если умудриться накатать мегажирную прошивку аж на 30кБ (т.е. шрифты туда разные впихнуть и адову портянку текста), то все равно вполне себе за жизненный цикл изделия его флеш-память даже на 50% не износится.

Разница в цене между теми же, скажем, C6T6 и C4T6 практически нулевая (на алике вообще они за одну цену продаются: как F103, так и F072), поэтому если даже прошивка влезает в 15кБ, а настройки нужно хранить, можно взять МК "классом повыше", чтобы там уж точно не 1кБ свободной памяти был, а поболее.
А вот вместо VCT6, когда у тебя прошивка со свистом в 20кБ влезает, брать жирнючий VET6 стоит лишь в том случае, если у них по периферии есть какая-то принципиальная разница (скажем, как в F303, где даже USB различаются в одной линейке, но с разной "dencity").

Вчера вечером начал понемножку рисовать, сегодня еще неплохо дорисовал (репа на ГХ). Осталось добавить совсем немного: CAN с обвязкой, батарейку с обвязкой (там еще и диоды какие-то стоят), да АЦП/ЦАП с обвязкой. Ну и разъемы нарисовать, да красиво все распределить на схеме (пока тупо туда-сюда разбросано как попало).
Чем больше рисую, тем большее непонимание "китайской схемотехники". Входы опторазвязок шунтируют резисторами для защиты от помех, но в параллель кондеры не ставят. Зачем-то на входе по питанию воткнули уйму диодов: сначала предохранитель, за ним двойной дроссель, потом диод, за ним TVS на 30В, а потом от этой точки питание идет на входы Xn, оттуда же через диод — на импульсник (5В — и это только ради преобразователей 485 и CAN, хотя они тоже на 3.3В бывают — можно было бы импульсник на 3.3В ставить и не париться с "кренкой"), а через другой диод — на питание релюшек. То-то я удивлялся, когда прозванивал, что где-то 24В, где-то 23.5, а где-то — 23… Полюс одного кондера в обвязке ULN2003 не подключен к земле (тупо вообще ничего не отходит от этой лапы!). 485 защищен TVS, а 232 и CAN — нет (даже CESD не воткнули, а еще лучше — сделали бы все интерфейсы с гальваноразвязкой).
Про использование внешней EEPROM, когда в МК флеша — хоть отбавляй, я уже писал. Еще больший идиотизм — использовать софтовый I2C (хотя, я так понял, что когда-то давно один из китайцев наткнулся на проблему с I2C в F103, и вместо того, чтобы по errata понять, как ее решить, наговнял софтовый — это они любят). Распределение ног МК — вообще дичь какая-то. Понятно, что входы-выходы удобней по близости. Но использовать SWDIO как DE для 485!.. Да и батарейку хрен пойми, зачем воткнули: в F103 RTC считай, что и нет, плюс убогое оно совершенно в нем (ЕМНИП, даже регистров "тонкого тюнинга" нет).
Зато мне понравился очередной "клоп" — частотник XL1509. Ему вообще суперминимальная обвязка нужна (если брать на фиксированное напряжение).
Если завтра будет настроение, закончу. Но трассировку конкретно этой платы делать не буду (нафиг-нафиг, нужно рисовать вменяемую, а потом уже разводить). Правда, изготовление подобной штуки даже в не-единичных экземплярах в России обойдется куда дороже, чем купить за примерно 3000р на алике! Одна только печатная плата такого размера минимум в 500р обойдется. Кстати, таки оказалось, что плата двухслойная. Поначалу я думал, что четырехслойка.

Как уже писал, код закончил утром, а только что закончил Readme.md дописывать. Вот и сделал пуш во все свои кодохранилища.
Издевался над парочкой из более свежей партии:

Самый первый почему-то перестал "общаться" по RS-232 (однако, по модбасу и кэну работает - видимо, преобразователь уровней помер).
Получилось очень даже приличное устройство (в отличие от оригинала, который вообще хрен запрограммируешь нормально). Если нужно кастомизировать, а базовых возможностей не хватает, любой может открыть исходники и добавить нужный ему код. Быстро, удобно и не требует изучать всякие левые недоЯПы (а то и вообще мышей надрачивать дичь какую-нибудь).
Более-менее подробно документация изложена по ссылке, поэтому здесь лишь немного прокомментирую.
( tl;dr )

В общем, я доволен. И еще больше буду доволен, если таки нарисую полную схему в кикаде.
Единственным недостатком при переделке этих недорогих модулей является то, что для прошивки нужно подпаять проводок к резистору на BOOT0 и при подаче питания подцепить его на +3.3В. Затем при помощи stm32flash отключается защита, стирается флеш, и можно записывать свою прошивку. Под CAN я просто два проводка припаял, но хорошо бы туда впаять такой же разъем, как соседний - где 485 и аналоговые входы/выходы.
Разъем SWD в своей версии я бы сделал, как и в прочих железяках - нераспаянная гребенка с шагом 1.27мм, куда очень удобно вставляются контакты "прищепки".
Ну и, понятное дело, в своей версии сделал бы независимыми оба полюса каждого входа и каждого выхода. Иначе получается уж больно узкий круг задач, которые можно решить этой фиговиной. Ну или если оставлять входы с общим, то хотя бы биполярные опторазвязки воткнуть…

Код на вражеском гитхабе.
Позже выложу описание протокола. Пока вкратце, что умеет:
- работа с RS-232 (текстовый протокол), RS-485 (modbus-rtu) и CAN (мой "стандартный" протокол);
- возможность при изменении состояния дискретных входов отправлять по CAN текущее состояние;
- возможность связать несколько устройств так, что одно будет по CAN и/или modbus (но лишь в случае если оно — господин шины) слать команду с нужным идентификатором (или 0 - широковещательную), чтобы в соответствии с изменением входов щелкали релюшки.
В остальном все как и было раньше.
Код еще не совсем закончен, т.к. обнаружилась странная ошибка с CAN (кстати, она есть и на USB-CAN устройствах, но там проявляется лишь на очень больших скоростях): если выводить данные во время приема, то как только выведен заполненный до конца буфер, происходит зависание и watchdog через 2 секунды перезагружает МК. Я уже даже в обработчики прерываний ошибок CAN-шины воткнул отключение CAN — бесполезно! Т.е. нужно подключать отладчик, отключать watchdog и, когда МК перейдет в hardfault_handler, посмотреть в стеке адрес возврата и по нему попытаться определить, на какой последней инструкции возник косяк. Но вот проблема: здесь нога отладчика используется для управления DE преобразователя уровней RS-485. Похоже, придется отключить на время отладки 485 и попытаться таки понять, что за НËХ!

Повесили же, сволочи, управление DE/!RE преобразователя 485-го на пин PA14 (который SWCLK). Вот уже второй час мучаюсь (заодно нашел несколько опечаток у себя в коде): хоть и делаю AFIO_MAPR_SWJ_CFG_DISABLE, и настраиваю пин в режим PPOUT, и пишу ему в ODR нуль, все равно на этой ноге 4.5В! При подтяжке резистором к 3.3В получаю 0.2 — явно преобразователь уровней чудит и подтягивает, чтобы в воздухе не болтались. Однако, взял другую плату (с еще нестертой прошивкой), и там — о чудо — нуль (и, соответственно, режим Rx)!
В итоге передавать данные получается, а чтобы принимать, нужно закоротить PA14 на землю.
Думал, прокосячил с полярностью — ан нет, все проверил, как надо: в единичку устанавливаю для передачи, сбрасываю в нуль для приема. Подключил к PA14 осциллограф — вообще никакого шевеления, когда передаю. Однако, отладка работает! Вот только, к сожалению, в режиме отладки через SWD невозможно отключить эти пины (да и если отключишь, что будешь дальше делать?)…
Хрен знает что творится! Как вот у китайцев работает, а у меня - нет?

Код на гитхабе.
Пока не тестировал. Убил на это полтора рабочих дня (включая "чаегоняние" часа на 3-4).
Постарался учесть спецификации из интернетов + что в вики написано.
В режиме господина будет тупо посылать все, что вводишь в терминал аргументами соответствующей команды (как посылка чего угодно в CAN), а при приеме пакета-ответа - расшифровывать его в терминале (без CRC).
В режиме раба будет принимать лишь пакеты, направленные на соответствующий идентификатор (а также широковещательные, но не отвечать на них), с выполнением нужных действий и отправкой ответа (или сообщения об ошибке).

Недавно начал глючить один из контроллеров термодатчиков на зеркале БТА: поработает минут 5, а потом начинает засорять шину (буквально флудит, не давая никому влезть) широковещательными командами "начать измерение температуры" (непонятно, с чего вообще эта дичь возникла). Вот, сел вчера радикально так заменил код USB на новый (о котором недавно писал), выкинул поддержку UART (ну его нафиг: больно тормозной). Сегодня поменял немного протокол, заменил базовый адрес идентификаторов на 0x680 (чтобы не пересечься случайно с какой-нибудь железкой на CANopen). Пока отлаживал, придумал еще несколько команд для удобства (в т.ч. "заткнись!" — чтобы контроллер ничего в шину не писал, пока разрешения не получит). Сам по себе USB-протокол оставил тем же, что и был (только запретил уже "широковещательные" команды). Как и раньше, если контроллер не находится в режиме "сниффера", реагирует лишь на посылки по его ID (а идентификатор равен 0x680 + номер, который перемычками на плате установили — от 0 до 15). Мастер (с номером 0) по умолчанию в роли "сниффера" выступает (чтобы и с другими устройствами в шине через него можно было общаться).
Поеду завтра на гору, перепрошью все шесть контроллеров. Заодно попытаюсь "глюкавого" найти — если он физически глючит, нужно будет заменить. Хотя, странно это: работает себе несколько минут, а потом вдруг начинается…
Репозиторий с кодом.

Собрал в одну кучу для разных линеек, чтобы можно было, не парясь особо (разве что для F2/F3 чуть руками надо будет подправить, т.к. там внутри одной линейки черт-те что творится), быстренько CDC поднимать — сниппет. А началось с того, что неделю назад, ковыряясь с multistepper, наткнулся на косяк с выводом справки (а там она жутко длинная). Оказалось — проблема гонки: пока из суперлупа в буфер пишут, внезапно может возникнуть прерывание и попытаться этот буфер прочитать. Ввел блокировки — получилось. Правда, как я уже писал, пришлось таки использовать поллинг.
Скорость — почти 6Мбит/с. Выше — только если использовать двойную буферизацию. Но сел я эти три странички даташита читать, и понял, что нафиг оно мне не нужно. Разве что если вдруг когда-нибудь упрусь в то, что 6Мбод не хватает… А то ведь получается, что памяти надо в 2 раза больше выделять!
Кстати, насчет памяти: чуть застрял на своем сниппете, когда пытался на F103 запустить. Там дескрипторы отдавались, а вот только начнешь туда что-то писать, ошибка. Отладчик показал, что точки EP2/EP3 не инициализировались. И тут-то до меня дошло: ведь раньше я явно размер в байтах проверял, а сейчас этот размер указан для буфера, а потом он делится на 1 или 2 (в зависимости от того, выравнивание на 16 или на 32 бита используется). И несчастные 512 байт у F103 еще и надвое поделились, так что места элементарно не хватило. Очень уж кривой USB у STM32. Да и буфер какой-то дико мелкий: в том же Seven_CDCs (7 CDC устройств в одном микроконтроллере) используются все 8 конечных точек. И по-хорошему, даже с эмуляцией interrupt-EP на 7 CDC нужно минимум 640 байт. При том, что зачастую 256 байт буфера обобщены с CAN. И зачастую выравнивание идет на 32 бита, т.е. даже буфер 1кБ без использования CAN превращается в несчастные 512 байт. Ну и какая ж тут двойная буферизация еще?..

Выложил окончательный код на гитхаб. Входы/выходы работают, АЦП опрашивает. ЦАП за ненадобностью не задействовал, аналогично с RS-485 (т.к. когда на борту есть CAN, 485 может понадобиться разве что какое-нибудь УГ модбасовое в качестве раба подключить). Дальнейшую модификацию кода каждый по своим надобностям может делать (или мне небольшую денежку заплатить).
В итоге из неюзабельного куска говна получился кусок говна юзабельный (увы, все-таки там все так плохо с защитами, что лучше в серьезные места не ставить).
( Read more... )
Почему сразу не выложили нечто подобное - не понимаю. Ведь только теперь этот "ПЛК" стал настоящим ПЛК, т.к. его стало возможным программировать по-человечески — на любимой сишечке. Без ограничений, накладываемых "языками ПЛК".

Постепенно приближаюсь. CAN работает, RS-232 работает. Релюшки щелкают, входы опрашиваются. Правда, оказалось, что я как-то криво прозвонил, в итоге у меня пара релюшек и добрая треть входов "не тудым". ОК, завтра пощупаю мультиметром еще раз. Только теперь под "микроскопом", а то даже в плюсовых очках как-то хреново ножки LQFP100 идентифицируются.
Жаль, китайцы схему не выложили. Заодно было бы понятно, что за бред они там нагородили с "аналоговой" частью. Да и диоды какие-то (или стабилитроны) по пути торчат непонятные (ладно бы, их было по числу аналоговых входов - можно было бы ожидать, что это - какая-никакая защита, а их два всего). И "лишний" оптрон (то ли определяет наличие подключения внешнего "плюса" к общему оптронов, то ли еще что; кажется мне, что он нужен, чтобы если нет внешнего, кидать на оптроны "плюс" питания).
git push делать не забываю.

Сегодня вечером ковырялся с CAN. Таки по Rx увидел нечто, в итоге запаял имеющийся у меня TJA1050 и стал проверять.
Поначалу какие-то косяки постоянно были, но потом таки все заработало.
( Read more... )

Надо думать: переходить таки на это, либо же сделать свое, но нормальное (с защитой и опторазвязками).
Но таки спортивный интерес во мне разгорелся, поэтому я как минимум реализую работу через RS-232 и CAN с минимальной обвязкой: входы X.., выходы Y.. и, возможно, аналоговые входы (хотя, т.к. они не защищены вообще никак, смысла от этого особого нет). Аналоговые выходы - вообще бред какой-то в конкретно этой реализации.