eddy_em | Entries tagged with stm32

Таки оно у меня заработало!
Проблему с "остановкой" I2C во время чтения DMA нашел: я сам накосячил в одном месте и просто отключал I2C… Остальное - дальше.
( Read more... )
Остается еще дописать управление питанием, отсылку по RS-485, да промакетировать. Ну и сэмулировать проблемы на шине или временное отключение какого-либо датчика (пока что они у меня гроздью спаяны, нужно будет обжать их "штекерами" и на беспаечной макетке в кучу собрать). А потом - нарисовать печатную плату и корпус, ну и изготовить… И, конечно, нудная калибровка - чтобы сшить пять картинок воедино.
Ах, забыл: ведь еще нужно добавить BME280 + один-два NTC + управление подогревом.

Итак, теперь код заработал и на микроконтроллере STM32F303CBT6. Тесты занимают достаточно много места во флеше (да там еще и математическую библиотеку линковать пришлось ради sqrtf), так что вот:

Memory region         Used Size  Region Size  %age Used
             rom:         30 KB       128 KB     23.44%
             ram:        5616 B        40 KB     13.71%
          ccmram:          0 GB         8 KB      0.00%

Чуть меньше четырех кБ флеша и 1кБ ОЗУ занимает USB.
В принципе, пока что ОЗУ со свистом хватает для пяти датчиков. Еще и на буферы для передачи по USART останется, и на какие-нибудь дополнительные нужды.
Цикл обработки одной "подстраницы" занимает примерно 4.2мс, т.е. целиком обработка страницы уложится в 8.5мс. Одна "подстраница" данных (при том, что там половина - ненужные! Уж не знаю, зачем melexis так нарукожопил…) по I2C на скорости 1МГц передается около 14мс. Следовательно, обработка предыдущей "подстраницы" выполнится быстрей, чем прием следующей (!!!). Вот уж не ожидал… Теперь понятно, как китайцы на экранчике "видосики" рисуют. Самое интересное, что в настройках датчика предельная скорость обновления - 64Гц. Даже если это - для одной "субстраницы", а не полного кадра, период обновления около 16мс выходит - лишь немногим больше времени, за которое это обновление будет выдано в I2C. Интересно, как чип умудряется с такими скоростями справляться.
Нам же все равно нужно максимум раз в 30с картинку обновлять. Ну, забавы для можно, конечно, и 1Гц поставить. Посмотрим, это нужно уже экспериментально выбирать наиболее оптимальный режим.

Интересно было бы сравнить с быстродействием "родной" библиотечки от melexis. За какое время у них вычисляется полный кадр на том же самом МК?
Я же, глядя в код, подозреваю, что можно еще немного оптимизировать.

Редко так бывает, чтобы сначала код написал, а потом нарисовал плату, но сейчас почти так. Почти — потому как я все же решил еще добавить 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... )
Почему сразу не выложили нечто подобное - не понимаю. Ведь только теперь этот "ПЛК" стал настоящим ПЛК, т.к. его стало возможным программировать по-человечески — на любимой сишечке. Без ограничений, накладываемых "языками ПЛК".