Если ваш вопрос не влез ни в одну из вышеперечисленных тем, вам сюда.
Ответить

Re: RSLK от TI (Robotic System Learning Kit)

Пн сен 14, 2020 17:51:42

Да ничего суперского я там не придумал. BGM13, SPI дисплей и 3 кнопки. Для программирования вывел JTAG, и еще, все оставшиеся выводы BGM вывел дорожками на пады, чтобы если позже что еще взбредёт в голову, можно было подпаяться проводками. Ну и еще на плате развёл SEPIC преобразователь на MCP1661.

Уже не помню, писал или нет, возникла мысль сделать робота на PSoC в конструктиве "старого" робота. Вот сейчас сижу, пытаюсь развести плату. Правда, драйвер двигателей собираюсь ставить такой же как у "старого" - TB6612. И если останется место, попробую вместить BGM.

А вот кстати, вопрос на засыпку. У JTAG интерфейсов TDI - TDO можно сцепить цепочкой. Я такой фокус применял с зайлинксовыми CPLD. Там у меня на одной плате стояло 3 штуки xc2c64a и через один разъём я мог достучаться до любого из трёх и прошить им конфигурацию. А как на такой фокус отреагируют Simplicity Studio и PSoC Creator, если я в одну цепочку сцеплю PSoC и BGM? Кто-нибудь это пробовал? Просто у этих софтов, я не видел в меню такой штуки как Boundary Scan, которая была в ISE iMPACT.
Ser60 писал(а):Насчёт SDIO
Если бы я знал! Хочу всего и побольше. То, журналирование, что был сделавши на 24c512, где на один фрейм писался всего один байт (1000 фреймов в секунду), мне маловато. И даже на этих соревнованиях я эту информацию не собирал. Там я вижу только грубую картинку, что видят фото сенсоры:
Это в расшифрованном виде. Проезд перекрёстка. Может, реальные показания всех восьми сенсоров мне не нужно, но вычисленное значение ошибки хотел бы (это еще 16 бит). Потом показания заданной и реальной скорости, показание пройденного пути, номер сегмента по которому иду и, может еще чего-нибудь. Другая проблема, писать в plain text или кодированными блоками. Во втором случае, надо где-то разместить инструмент для его декодирования и визуализации (ну хотя бы в электронную таблицу загрузить).

Re: RSLK от TI (Robotic System Learning Kit)

Пн сен 14, 2020 20:51:22

Не знаю насчёт JTAG - всегда использую SWD. Тем более вопрос как поведут себя разные инструменты. Я-бы поставил отдельные разъёмы для программирования PSoC и BG13, так даже удобнее будет на мой взгляд.

Re: RSLK от TI (Robotic System Learning Kit)

Вт сен 22, 2020 23:04:22

Хм, хотел сделать плату с такой цепочкой, но с возможностью разорвать цепь, если не пойдёт. Но, таскал-таскал дорожки по плате и понял, что не могу такое количество цепей растащить и решил сделать два разъёма (с возможностью хотя бы проводами попытаться соединить в цепь). Развёл. осталось сделать соединения между PSoC и BGM. А чтобы убедиться, что проект соберется сделал новую ветку проекта, добавил UART и... проект не собирается. Unable to pack the design into 24 UDBs. Вот и всё. А у меня как раз сегодня возникла одна затея, хотел попробовать реализовать. И теперь не знаю, от чего отказаться или плюнуть на PSoC и пытаться на другом МК.

Например, stm32f051. Может, если я возьму более многоногий кристалл, там удастся еще и энкодеры подключить и обработать? Я ему сделал запись журнала на FRAM. Проверил пока на "эмуляторе" - вроде работает. Причем всё работает через DMA. Только на каждый отсчет формируется буфер и данные самостоятельно передаются в FRAM. Да, с записью журнала у этого робота проблем нет (ну за исключением того, что надо выпаять 24c16 и впаять что-нибудь поменьше? Чтобы высвободить адрес для FRAM). Проблема в чтении.

Тут был вспомнивши, что когда-то i2c eeprom можно было писать JDM-программатором (это для PIC - еще то чудо!). Поэтому начал искать, а нет ли такого софта для PicKit3. Оказалось, что есть. Но попробовав, у меня ничего прочитать не удалось. Пришлось отбросить затею.

С другой стороны, на роботе для лабиринта, я прекрасно читаю журнал средствами самого робота или через USB, или через BGX. На роботе с STm32f051 USB нет, зато есть BT. Правда, HM-15 - к нему BGX'ом не подключишься. И тут меня осенило. У меня же есть ThunderBoard Sense 2! Там есть UART, который доступен как USB CDC через Segger. Надо только написать клиента. И пошел я писать. Попутно, поставил пятый Simplicity Studio и круто с ним обломился. Почитал про migration c 4 на 5-й - ой, полностью всё изменено. Сначала думал, что надо бы отбросить старое и браться за новое, но, почувствовал, что это тогда будет очень долго. Поэтому установил еще и 4-й. Кстати, автоматической миграции с 4 на 5 для блютус программ нету. Но есть целый документ про то как это делать.

Ну да ладно. Сделал soc-empty, Взял в руки AN0045 - про то как писать interrupt driven UART на EFM32, что-то написал и пытаюсь запустить и получить у себя на терминале "Hello World". Ничего не получается. Получается GPF. Стоит в буфер положить хоть один символ - GPF. Подумал, что ошибка в обработчике прерывания - поставил брейкпоинт, но там останов не происходит. А... копируя из AN0045 я не везде заменил UART1 на USART0 и название функции обработчика прерывания было не верным (так что прерывание срабатывало и процессор по вектору уходил куда-то?). Ладно, исправил. А теперь перестало компилироваться. проблема с обработчиком прерывания по приёму. Как выяснилось, в проекте уже один есть, а я пытаюсь втюхать второй. Оказывается там есть RETARGET_USART, и на самом деле является нужным мне USART0. Начал изучать - о, как раз то что надо - приём по прерываниям (правда буфер маленький - всего 8 байт), но нет функции проверки пришло что-нибудь или нет. Ладно, грязными ручками туда залез и добавил. Передача, правда, идёт не по прерываниям. Но, хотя бы локальное эхо я получил - т.е. что принял, то и отправил назад. И похоже, работает. Не могу догадаться, как "корректно" изменить размер буфера. В коде есть такая строчка:
Код:
#ifndef RXBUFSIZE
#define RXBUFSIZE    8                          /**< Buffer size for RX */
#endif  
Вот только где разместить свой дефайн, чтобы он пересилил по умолчанию не могу найти в настройках проекта. Ну и думаю, передачу через прерывания напишу тут же. Теперь надо бы сделать соединение с HM-15.

Re: RSLK от TI (Robotic System Learning Kit)

Вт сен 22, 2020 23:18:09

Поэтому начал искать, а нет ли такого софта для PicKit3. Оказалось, что есть. Но попробовав, у меня ничего прочитать не удалось. Пришлось отбросить затею.

По работе время от времени нужно бывает кое-что писать в 24С16. Для этой цели именно третий пиккит и использую. Посмотрите в хелпе к standalone 3.10 версии программы как подключать эти еепром к нему.

Re: RSLK от TI (Robotic System Learning Kit)

Сб сен 26, 2020 23:13:41

Ну, значит мне не везет. Началось с того, что просто зайти на сайт микромела и скачать этот программатор нельзя - надо искать гуглом и где-то на форуме была ссылка куда-то в недра микрочипа (правда, нерабочая) и потом дальнейший поиск "рабочей" ссылки. И файл "Readme for the PICkit(TM) 3 Programmer Application with scripting support", конечно же читал. Но после того как оно "прочитало" отсутствующую микросхему (а ведь она должна была дать ACK на команду адреса!) доверие к сему "программному продукту" у меня как-то пропало. Вот только что, взял резистор 5 килоом и вставил между 2 и 6 выводами - без проблем читает отсутствующую микросхему. Правда, вот это изменение я не делал:
NOTE: The I2C (24LC) Serial EEPROM devices require the following PICkit 3
hardware changes to work properly:

Remove TR3 from the PICkit 3.
Remove R50 from the PICkit 3.
Если это обязательно, то ну его нафик. Если мне это сильно понадобится, возьму или синюю таблетку, или cy8ckit-049 и напишу сам что надо. Пока это вариант не двигаю, так как считать это одно, а еще надо расшифровать - привести в "читаемый" вид. А под виндовс, у меня как-то нет опыта. Под FreeBSD там был мощный bash, grep, awk. на худой конец perl и cc, а под виндовсом есть какой-то power и где-то спрятанный c# - их еще найти надо. Специально, наверное, спрятали от юзеров.

Поэтому я эту неделю посвятил соединению блютус модуля HM-11 c Thunderboard Sense 2. Это позволит сделать клиента, который я могу или через USB-CDC подключить к компьютеру или сделать совершенно автономный пульт - на борту кнопки и светодиоды уже есть и дисплей подключенный по SPI - тоже. Только снова забыл как надо подключать к проекту SPIDRV - через менюшки не получается. Ну, с этим разберусь. По ходу дела, что-то был сломавши. Или это студио взглючила? Внезапно прошивка перестала собираться. выдаёт ошибку в файле sleep.c в platform/emdrv/sleep/src. Начало утверждать, что одного поля в структуре не существует. Пошел разбираться - не понимает то, что оно типа bool. Стоит сменить на int или void - поле становится доступно. Что я не так сделал - ума не приложу. Пришлось весь проект убить и создавать по-новой, тогда стал собираться. Правда все наработки по последовательному порту потерял.

Была мысль отбросить четвертый студио и начинать работать с 5. Правда там структура программы несколько иная, поэтому раз уж изучать, так сразу новое, но на свой компьютер поставить не смог. Инсталяция не запускается - жалуется об отсутствии одной DLL в системе. Пытался гуглить проблему - ничего толкового не нашел. sfc /scannow никаких проблем не находит, а в интернете этот файл можно скачать только 32-битную версию, а у меня 64-битная система.

Re: RSLK от TI (Robotic System Learning Kit)

Вс окт 04, 2020 18:29:59

Закончил рисовать плату очередного робота. Оставил идеологию прообраза: тот же микроконтроллер, но с большим числом ног, другой блютус модуль, подключил таходатчики моторов, FRAM для журналирования разместил тут же на плате. И разводкой i2c соединил с памятью не только микроконтроллер, но и блютус модуль - смогу напрямую считывать лог. Завёл на АЦП блютус-а напряжение батареи через делитель, чтобы тестер не вытаскивать для оценки состояния батареи. И вот уже собрался ставить платы на заказ, начал подбирать детали, и оказалось, что микроконтроллера нигде в продаже нет. Всюду "отсутствует на складе". Маузер говорит "Factory lead time 51 weeks" - да это же целый год! Фарнелл, тоже - поставка до 2021.10.15. Ну я попал. Не, ну можно её откуда-нибудь выпаять. У меня она стоит в часах и с платы Discovery тоже можно выковырнуть. В продаже есть 031 - но там ОЗУ всего 4 килобайта. А 071 требует изменения разводки. - там 3 пары питающих ног, а не 2 (не считая аналогового питания). Впрочем, немного потаскал дорожки туда-сюда и пере развёл "более совместимый" вариант.

Поразмышлял на тему: "а что такого плохого, что при разгоне робот задирает нос?". А ничего плохого, возможно и нет. Просто это "задирание" не нужно воспринимать как перекрёсток. Поэтому придумал различие - ожидаемый перекрёсток или не ожидаемый. Решил так, что первый участок сегмента - всегда не ожидаемый перекрёсток. Т.е. я могу задать первому участку длину 1 метр и проходя этот метр "перекрёстки" будут игнорироваться. Есть мысль определить наоборот - перекрёсток ожидаем только на последнем участке, а его длину я всегда ставлю 65.535 метров потому как границы по дальности нет, а границу определяет следующий перекрёсток. Но пока не придумал как это сделать проще и изящнее.

HM-11 c Thuderboard Sense 2 соединил. Конечно с некоторыми ограничениями. Так как скорость порта HM-11 9600, а Thunderboard 115200 - одним махом передаётся где-то 25 байт. В обратную сторону, вроде без проблем. Вернее, проблем не было пока я использовал код драйвера RETARGET_USART. Но у него только приём делается по прерываниям и с буферизацией. Передача происходит с блокирующим ожиданием. Поэтому я залез туда и сделал передачу тоже по прерываниям. Правда оно иногда странно себя вело - пропадали символы и появлялись чуть позже. Чтобы выяснить где проблема в блютус канале или UART, я сделал контрольный вывод принятого по блютус на OLED дисплей. Но тогда проблема исчезла. И даже когда выключил контрольный вывод - всё работало как надо. Возможно, я после "подчистки" кода не перепрошил модуль и там остался сырой вариант. Ну, теперь я могу с роботом общаться и конфигурировать. Надо только придумать какие команды мне нужны для удобства.

Так же размышляю, что я могу писать в журнал. Есть, конечно, ограничение - я не нахожу FRAM микросхемы ёмкостью больше чем 128к x 8. Так как i2c шина сконфигурирована на 400kbps, то за секунду я могу "перекачать" 40 килобайт (один байт требует 8 бит и ACK, поэтому я поделил просто на 10 - с запасом). Если частота сэмплирования у меня будет 1000 раз в секунду, до за раз могу передать 40 байт. Вроде не плохо. Но, при "этих 40 килобайт в секунду", 128 килобайт закончатся за 3 секунды! Поэтому скорее объём FRAM оказывается ограничивающим фактором. Если считать время хода по трассе до 16 секунд, то в секунду я могу писать только 8 килобайт, i.e. 8 байт за сэмпл. Маловато. Ну для начала сойдёт. Может, когда сделаю нового робота у которого будет вместо HM-11 модуль BGM я смогу через него передавать данные... хотя на скорости 115200 - это 11 байт на сэмпл... надо еще думать.

Вчера были соревнования Лего-роботов. Я туда не поехал. Думал, что будет доступна страница с результатами, но не смог её найти. Нашел толькоLego sumo в Challonge.com, но там только номера роботов. Мои поздравления роботу под номером 9, который прошел и групповой, и финальный этап без единого поражения. Правда, чей это робот - не известно ;-). И похоже, что в Литве вчера тоже проходили аналогичные соревнования. ОК, продолжаем готовиться к своим соревнованиям.

Re: RSLK от TI (Robotic System Learning Kit)

Вс окт 04, 2020 20:30:57

Слежу за и радуюсь Вашим успехам. Насчёт отсутствия МК в продаже - не понял какая модель интересует. Может можно её купить напрямую у ST? Я вчера заказал с сайта ST пару семплов и, при условии бесплатности самих семплов, заплатил всего $4 за их пересылку по UPS. Не знаю, если покупать, то их пересылка может дороже стоить будет(?)

Да, FRAM память меньше по объёму, чем Flash/EEPROM, поскольку их ячейки больше и сделать их соразмерными с другими технологически сложно. Поразмышляем по поводу передачи данных напрямую на комп. Если скорость сбора данных от сенсоров у Вас определяется скоростью I2C (400кbps), то если коммуникация с HC-11 идёт на скорости грубо 9.6 kbps, а с Thunderboard - на 115 kbps, то интерфейс обоих является бутылочным горлом. Сам радиотракт по протоколу 4.0 может максимум передать 320kbps (см. здесь), но, думаю, организовать это будет непросто, так что хорошо, если получится раза в 2 меньше. Не понимаю почему Вы привязываетесь к HC-11 - неужели только потому, что он есть в наличии? Ведь даже если использовать модуль с версией 4.2 протокола, то максимальная скорость передачи по воздуху возрастает в теории до 800kbps а при версии 5.х ещё примерно в 2 раза больше, и радиотракт тогда не будет замедлять I2C. Касательно UART, в BGM13 даже при тактировании периферии от 4 MHz легко получается скорость UART в 230kbps и мпожет удастся увеличить её до 1000kbps при большей частоте периферии. Может на передающем конце робота следует организовать двойную буферизацию на основе небольшой FRAM и/или коммуницировать с передающим модулем черeз I2C/SPI вместo UART. На приёмном конце у компа, если хотите задействовать плату Thunderboard, у неё выдача UART -> USB идёт через чип программатора и поднять её скорость (мне) не представляется возможным. Однако, можно поставить на плату гребёнку контактов и установить на них свой UART/I2C/SPI -> USB конвертер на CP2104 или подобном чипе. Однако, это будет ненамного проще, чем отдельный донгл на BGM модуле спаять.

Re: RSLK от TI (Robotic System Learning Kit)

Вс окт 04, 2020 21:47:38

Не-не-не. Я к HM-11 не привязываюсь. Просто в прошлом году я на неё заложился и собрал пару плат с этими модулями. Сейчас, глубже познакомившись с блютус, оно меня совершенно не устраивает, но пока позволяет обкатать некоторые модули и лучше понять что я хочу получить. Поэтому новые проекты начинаю наполнять BGM-13. На BGM-13 я уже могу написать что-либо подобное пресловутому HM-11, но лучше отвечающему моим задачам. На новой плате, я постарался завести на BGM всего чего: сериальный порт с микроконтроллера, шину i2c (еще не знаю, буду ли использовать как мультимастер или кого-то сделаю слейвом), напряжение батареи (надеюсь, что удастся воспользоваться встроенным операционным усилителем, как повторителем перед АЦП) и просто дигитальные сигналы от светодиодов, чтобы они повторялись на клиенте. А, и еще подключил один синий светодиод для индикации соединения, например. Ну и, еще не знаю зачем, развёл одну SPI-EEPROM.

По поводу бутылочного горлышка: я с HM-11 передачу не планирую. Только через терминал получить на 9600 csv-файл с данных, что будут сохранены в FRAM. Правда, тут тоже надо посчитать, сколько времени на это потребуется. Надеюсь, соревнования не успеют закончиться, пока буду сливать данные. А вот в случае с BGM, кто мне мешает создать в нём буфер килобайт эдак на 32 и пусть оно прокачивается. Может, поставлю SPI-FRAM для дополнительной буферизации. Надо будет определиться с объёмом данных. Вот на данный момент уже придумал, чем наполнить 8 байт, которые планирую сейчас собирать: две 8-битных и три 16-битных переменных.

Насчет stm32f051, я уже переиграл - на плате поменял два сигнала и подвёл питание к еще двум выводам. Так что теперь у меня плата готова принять любой stm32 в корпусе LQFP48 (ну почти... скажем, из F0 и F1. F410 - всё же не лезет.). Поигрался в CubeMX - могу поставить 031, 051, 071, 091. Даже stm32f103c8t6 - та что стоит на "синей таблетке" (правда TIM2 у неё не 32-разрядный, а я его планирую использовать для захвата импульсов с таходатчиков). Так что я уже в корзину бросил stm32f071 - он из той же серии, что и 051, так что особых проблем перенести текущий код на новый робот большого труда составить не должен, а там можно уже дальше развивать с появившимися новыми возможностями.

Re: RSLK от TI (Robotic System Learning Kit)

Вс окт 04, 2020 22:48:33

Если закладываетесь на BGM, рекомендую посмотреть на BGM22. Там процессор другой архитектуры и вообще другая 40нм технология. Это позволило, помимо всего прочего, впихнуть больше регистров настройки периферии. Сейчас конфигурация выводов настолько гибкая, что просто мечта, так что плату с ней разводить проще, чем с BGM13, хотя не по всем выводам они совместимы.

Re: RSLK от TI (Robotic System Learning Kit)

Пт окт 16, 2020 15:37:18

Всё же TI продолжил "развитие" RSLK. На неделе, обнаружил, что в curriculum-е появился 21 модуль. Пожалуй, самый объёмистый: 8 видео лекций (презентация на 112 страниц), и 7 коротеньких видео по результатам лабораторных работ. В этом модуле предлагается к роботу подключить или плату дальномерного сенсора TOF OPT3101 производства pololu, или плату boosterpack с сенсорами BP-BASSENSORSMKII, или обоих вместе. К сожалению, на данный момент еще не доступны файлы для 21-й лабораторной работы (на сайте лежит версия 01.00.01 прошлого года, где еще нет каталога для 21 лаб.работы). Но платы и модули можно уже купить: первую у pololu (32$), вторую на маузере (40€), digi-key и у самого TI (25$). Пока ознакомился с лабами и пролистал даташиты.

OPT3101 в отличии от ST VL6180 не имеют собственного источника и приёмника излучения, а позиционируются, как способные работать с "любыми" свето- и фотодиодами. На картинке модуля pololu на плате расположены с одной стороны 6 светодиодов (3 группы по 2 в каждой), а с другой стороны 2 фотодиода (в параллель). Этот модуль обнаруживает препятствия в 3-х направлениях. Правда, поставляемый "крепеж" ну... Не могу найти культурного слова, как описать. Поэтому, там предлагается, тем кто имеет доступ к 3d принтеру напечатать нормальные фиксаторы.

Плата BP_BASSENSORSMKII содержит толпу сенсоров: температуры, влажности, освещения, ускорения и магнитометр. И еще сенсор "hall effect" - не знаю, что им измерять.

Все сенсоры имеют i2c интерфейс, поэтому лабораторные начинаются с написания простейшего "драйвера" i2c - функций записывающих 1,2,3 байта и читающей 1 байт. Наверное, этого будет достаточно для работы с этими сенсорами.

Ну что ж - мне подкинули новую игрушку. осталось дождаться, когда придут модули. А то, похоже, что соревнований не будет - у нас сильно ухудшилась эпидемиологическая ситуация и поэтому до середины ноября запрещены все "занятия по интересам" кроме индивидуальных.

Получил и спаял плату нового робота для следования по линии. Конструктив оставил как у старого на stm32f051, только сделал на 071-м. Портирование кода прошло почти легко. Но первый запуск был не удачным. Хорошо, что додумался не подключать аккумулятор, а подключил сначала лабораторный БП с ограничением тока. И сразу - ток максимальный, напряжение упало до 2,5в. Начал рыть - быстро нашел: SPI EEPROM к блютус модулю припаял задом наперед. Развернул - всё равно КЗ. Думал повредил уже - выпаял. КЗ. Ну тут уже надо дорожки резать? Ладно. выпаял один стабилизатор на 3,3 в - все еще КЗ. Но уже легче: либо драйвер двигателей, либо драйвер светодиодов. всё оказалось просто - не тот шлейф к плате оптических сенсоров поставил - в результате выход драйвера светодиодов был просто закорочен. Отключил шлейф - на выходе есть 15в и ток в ограничение не входит. Поставил всё - светодиоды светят как надо. Дальше смотрю программу - программа виснет при попытке прочитать FRAM. Нашел маленькую ошибку в драйвере i2c - при масштабировании функции чтения памяти с 16 битным адресом пропустил одну строчку при копировании. Потом, чуть повозился с энкодером (левый работал, а не работал правый), потом с мотором - выровнять "полярность", так как выводы управляющие направлением развёл как удобнее - надо было в программе правильно назначить, который вывод вперед, а который назад. Так что, думаю, на соревнованиях он уже побежал бы. Теперь еще надо под BGM13 софт накропать.

Пока возился с этим STM пришла в голову мысль, что вот хорошая альтернатива для MSP432. Можно сделать 8-канальный захват, 32-битный захват для тахометров итд итп. Попробовал в CubeMX покрутить несколько вариантов. А там заметил, что у Куба есть Cross Selection. Т.е. выбираешь кристалл другого производителя и он подыскивает аналог среди ST-шных микроконтроллеров. Так для MSP432P401R набрал с 92% соответствием stm32G473. Хм, подбор, конечно, несколько тенденциозный... Подобранный кристалл гораздо круче оригинала. Правда, ST несколько слукавил - проигнорировал, что у MSP АЦП 14-битный (показал, что типа 12-бит). Я уж тут собрался его закупить, но тут случилось чудо -пришла моя покупка на e-bay сделанная в феврале. А там я заказал платку на stm32f407. Прикинул, что она тоже хорошо по ресурсам подходит. Правда, конструктив её не очень годится. Пока сижу в раздумьях - приспособить эту плату или развести свою.

Re: RSLK от TI (Robotic System Learning Kit)

Пт окт 30, 2020 21:12:59

В общем, все соревнования пролетают на неопределённый срок. Сейчас пандемия, а не то легкое заболевание, что было весной. Потому все мероприятия отменены. Думаю, что 19 декабря в TSI тоже никаких соревнований не будет. Ладно, посмотрим. А пока я получил платку BASSENSORSMKII - но как файлов для 21 лабораторной работы как не было - так нет. Хотел уже было написать на форум 2e2 или e2e, как он там на тексасовском сайте... обломился - нужен валидный университетский е-майл. Людям третьего сорта писать нельзя. Ладно - будем ждать. Правда, просмотрел лекции и прочитал план лабораторных - оказывается, всё очень плохо. Датчики дальномеры результаты дают хорошо, если 10 раз в секунду. Акселерометры используются для определения столкновения (а я тут губу раскатил, что координаты будем определять).

Короче, с горя вытащил плату робота на stm32f405, который будет бегать по линии, и у которого будет 16 сенсоров. Решил продолжать оживлять. А так как я его начал делать с CubeMX и библиотеками HAL - задача состояла в разбирательстве с этими библиотеками. Чтение конфигурации сделал, дисплей с кнопками - работают, коммуникация через BT HM11 идёт, моторы уже крутятся. Ну, следующий этап - тахометры. Пока, чтобы просто путь считал. Мучил-мучил, считать не хочет. Топчется плюс-минус один, а дальше не идёт... Причину то нашел - оказывается, я сконфигурировал делать захват (и прерывание) и по фронту, и по спаду, а в обработчике про это забыл и писал, как будто прерывания идут только по фронту. Потом, выяснилось, что силабс и куб по разному интепретирует определение типа XXXX_Pin. В Simplicity Studio это номер пина порта, а куб как (1ul << Pin). Из-за этого у меня никак не работал правильно макрос BITBAND_PERI и не определялось правильно направление вращения. Для прерывания по фронту определение направления выполняется так:
Код:
if (Enc_Left_B) {
   // Идём назад
} else {
   // Идём вперед
А для фронта и спада надо так:
Код:
if (Enc_Left_B ^ Enc_Left_A) {
   // Идём вперед
} else {
   // Идём назад
Ну а как сделать исключающее ИЛИ для двух бит которые могут находиться в разных портах и в разных разрядах? Приводить к 0 и 1 через маски? Когда под рукой есть такая удобная штука. Вот только, почему ST этот макрос не включает в свои хидеры?

А вот, пока разбирался с этими таходатчиками, немного по-анализировал об их погрешностях. Вот простые картинки:
Изображение
Так выглядят "идеализированные" сигналы с таходатчиков (инкрементального энкодера). Ну, я немного скривил, рисовал всё же малярной кистью (ms painbrush). Но в идеале, длительность импульсов и пауз между ними должна быть одинаковой и фронт (и спад) второй фазы должен быть ровно по середине первой фазы. Так что все вертикальные линии находятся на одинаковом расстоянии. Это в идеале. Теперь посмотрим на конструкцию энкодера. Это плата с двумя датчиками холла, над которым крутится магнитный диск с 6 полюсами - 3 северных и 3 южных. Допустим, что диск идеален - полюса не перекошены и между ними ровно 60 градусов. В этом случае, вариант 1х - один импульс на (допустим) северный полюс - будет работать идеально - никакого джиттера возникать не должно. Хотя, нет - может возникать, если этот диск на вал будет посажен криво или с эксцентриситетом. Тогда интервал между прерываниями будет плавать.

Если же мы захотим увеличить "разрядность" - измерять период не только по фронту, но и по спаду - вариант 2х - в дело начинает вмешиваться и то какой зазор между диском и датчиком холла:
Изображение
При увеличении дистанции импульс может сужаться. Этот эффект можно ликвидировать, если построить триггер, который при определённой магнитной напряженности северного полюса устанавливал триггер в 1 и при такой же напряженности южного - сбрасывал... не знаю, есть ли такие сенсоры?

Ну и самый проблемный вариант, если мы хотим учитывать еще и вторую фазу. Как писал, в идеале, вторая фаза должна быть сдвинута ровно на половину. Вроде как конструктивно это делается - магнитный диск: полюса повторяются с периодом 120 градусов, датчики стоят под углом друг к другу по дуге 90 градусов (что составляет -30°). Но оказывается, малейшая не соосность и эти углы поплыли:
Изображение
Вот для примера я сдвинул сенсоры в направлении стрелки и по отношению к диску они стоят уже не на 90°, а на все 120°. Ну, это я так грубо нарисовал, но тем не менее - энкодеры, что продаются pololu для моторчиков "с micrometal gear" они не "садятся" на кольцо на корпусе, а просто напаиваются на выводы моторчика. Ну можно, конечно, постараться напаять по-точнее... но выводы то - гибкие и при нагрузке на соединительные провода, плату ни что не удерживает от съезжания в сторону.

Вот и резюме 21-й лабораторной работы - все датчики шумят. Ну об этом буду думать, когда буду настраивать PI регулятор оборотов двигателей.

А вот кстати, пока я искал как правильно написать макрос BITBAND_PERI, гугл меня вывел на сайт http://www.micromouseonline.com/. Ух, почитал, и понял, что мне еще далеко до решения настоящего лабиринта. Вот, даже и не знаю с какого конца подступиться, чтобы робота научить ходить по-диагонали. Когда в прошлом году смотрел на youtube соревнования Robotex в Таллине, мне показалось, что там тоже один робот по лабиринту ходил в таких местах по-диагонали. Теперь, я убедился, что это так и есть. Напал на одну статью - там тоже участники в своих неудачах винят трассу: стенки имеют не тот коэффициент отражения.

Так, таходатчик я оживил, теперь надо бы оживить АЦП и ПДП. Сконфигурировал, написал, компилирую - облом. Халява закончилась - ваши 32К исчерпаны. А я еще не начал самого робота писать - только подготавливал инфраструктуру. С другой стороны, у кристалла с 1 мегабайтом флеша ютиться на 32 килобайтах... Так что, долой кейл, ставим CubeIDE.

Re: RSLK от TI (Robotic System Learning Kit)

Пт окт 30, 2020 21:27:50

uldemir писал(а):я сконфигурировал делать захват (и прерывание) и по фронту, и по спаду, а в обработчике про это забыл и писал
Может лучше ШИМ захват?

uldemir писал(а):Так выглядят "идеализированные" сигналы с таходатчиков (инкрементального энкодера).
Таймеры STM32 могут работать с энкодерами.

uldemir писал(а):Так что, долой кейл, ставим CubeIDE.
Надеюсь что комп мощный потому что IDE на основе Eclipse - тормоза!

Re: RSLK от TI (Robotic System Learning Kit)

Пт окт 30, 2020 22:01:42

нужен валидный университетский е-майл
Могу с этим помочь: отправить Ваш вопрос от своего имени. Если хотите, пришлите вопрос в ЛС.
определённой магнитной напряженности северного полюса устанавливал триггер в 1 и при такой же напряженности южного - сбрасывал... не знаю, есть ли такие сенсоры?
Видел такие у силлабов, если актуально могу поискать конкретные модели.

Re: RSLK от TI (Robotic System Learning Kit)

Пт окт 30, 2020 22:15:22

Мурик писал(а):Таймеры STM32 могут работать с энкодерами.
Мгм, знаю, но мне нужно не только считать расстояние, но и измерять скорость вращения чтобы на двигатели сделать ПИД-регулятор. Можно подать на два таймера разом, но тогда нужен будет очень многоногий кристалл, чтобы все нужные каналы захвата были доступны (и для энкодеров мне нужно 2 32-разрядных таймеров, мне лень вторую половину считать программно, раз уж начал делать аппаратно и для периода удобно имень еще 2 таких же... надо посмотреть, есть у ST такой кристалл с 4 32-разрядными счетчиками?)
Мурик писал(а):Может лучше ШИМ захват?
Это когда один канал захватывает фронт, а другой спад? Собственно, это мне лень было писать, что как средство уменьшения помех - считать отдельно периоды между фронтами и между спадами, и для другого канала тоже. Это как фильтр с усреднением с N=2 или 4. Тогда источником погрешностей должен остаться только магнитный диск. Но, это приведёт к задержке актуальных данных. Снова 21-я лаба - для подавления шумов пропускать через фильтры - улучшаем сигнал/шум, но получаем задержку. А если задержка станет слишком большой, стабильность ПИД-регулировки тю-тю. Ну это я могу сделать программно.

Мурик писал(а):Надеюсь что комп мощный потому что IDE на основе Eclipse - тормоза!
Комп так себе. Но с эклипсом так и так приходится иметь дело: Code Compose Studio = eclipse, Simplicity Studio = eclipse. Да, он запускается ооооочень долго. НО! Вот этот проект сгенерённый кубом и HAL-овскими библиотеками Кейл жуёт 9 с половиной минут на моём компе, а CubeIDE - всего полторы минуты - это полный clean and rebuild проекта. В чем тут подвох - не понимаю.

Ser60 писал(а):Могу с этим помочь:
Спасибо, но я просто подожду. Станет скучно, сам начну с ними играться. На этой плате еще есть датчик освещенности. И в дополнительных заданиях предлагается роботу искать место накрытое крышей при помощи этого датчика. Жаль, что этот сенсор цвета не распознаёт. Но вот как датчик стоящий сверху, заставить видеть, что находится под роботом? И возникла мысль, что можно было бы воспользоваться световодами. Надо бы выкопать тослинковский кабель и посмотреть, будет ли это работать? Тогда я могу сенсор расположить там где мне удобнее, а свет подавать таким световодом.

Насчет датчиков холла, хорошо знать что такие существуют. Если мне взбредёт в голову сделать свои платы - тогда я этим займусь. Пока надо израсходовать то, что я уже успел понапокупать.

Re: RSLK от TI (Robotic System Learning Kit)

Сб окт 31, 2020 00:29:08

uldemir писал(а):Вот этот проект сгенерённый кубом и HAL-овскими библиотеками Кейл жуёт 9 с половиной минут на моём компе, а CubeIDE - всего полторы минуты
Долго! Самый тежеловесный проект для STM32H7, сгененированный кубом у меня компилируется секунд за 30 максимум.
Для простых МК типа STM32F0 полная пересборка занимает около 5 секунд.
IDE собирает многопоточно, т. е. при компиляции все ядра процессора задействованы.

Re: RSLK от TI (Robotic System Learning Kit)

Сб окт 31, 2020 05:30:03

Вот линк на летний Tech Talk от Silicon Labs, где они неплохо рассказывают о своих Hall effect сенсорах.

Касательно Eclipse, похоже, за этим будущее, т.к. всё больше производителей используют этот подход. Считаю это хорошо в плане стандартизации и более быстрого перехода на другие изделия, если потребуется. Я недавно апгрейдил один из своих старых лаптопов на i7 процессоре с 8г памятью, поставив в него SSD вместо штатного HDD и Win10 с целью разработки приложений под Simplicity Studio v5. Так вот, "простой" Bluetooth проект генерируется на нём за 56 секунд. Написал простой в кавычках, поскольку там основное место занимает BT стек и компилируется всё в около 170Кб в .text. По-моему неплохо, поскольку код перекомпилируется нечасто при наличии всяких подсказок по синтаксису. А вообще, само IDE работает весьма лихо даже на этом компе 9-летней давности, и что-то ускорить особого желания даже не вызывает. Содержимое всех окон и вкладок меняется практически мгновенно с кликом мыши, а чего ещё надо от IDE? Также и Segger Studio работает достаточно быстро, однако реальный монстр в плане IDE и разработки - это Android Studio. Даже на современных компах тормозит конкретно. Правда, не пробовал пока новую версию 4 IDE.

По поводу световодов, в продаже имеются световоды для LED индикаторов в виде пластиковых трубок (light pipe). Может подойдут(?) Если хотите сетевое оптоволокно использовать, по-моему там будет нужен какой-то специальный инструмент для обрамления концов.

Re: RSLK от TI (Robotic System Learning Kit)

Сб окт 31, 2020 10:43:26

Ну я не говорил, что у меня комп крутой...
Изображение
Лет 7 назад в него собрал всё самое стабильное и быстрое из имеющегося у меня. Хотя, пожалуй, пора обновляться.

Эклипс меня устраивает. Вот только проблема с хот-кеями. Свои объявлять я пока стесняюсь, а встроенные пока не нашел. Есть Ctrl+B - Build ALL, но не нашел для Build Project. И совсем не вижу компиляции одного файла (в Keil Ctrl+F7). В кейле хорошо, F7 F8 - программа скомпилировалась и залилась, а тут пока надо мышой возить долго. Сначала понравилось, что можно в исходники "прилинковать" файл из чужого проекта, но хидеры почему-то не находит, хотя они тоже "прилинкованы" - надо добавлять путь в Includes.

Можно было остаться на Кейле - чтобы не пользоваться HAL-овскими библиотеками, достаточно было бы написать свой i2c-мастер. Жаль, что у F0 и F4 они разные. Потому как всё остальное практически одинаковое. UART я был вынужден написать сам, так как HAL-овский подход меня совершенно не устроил. С таймерами, АЦП и ДМА, думаю, разобрался бы. Впрочем с i2c тоже разобрался бы, только устаёшь писать всё время одно и то же: для MSP i2c написал, для stm32F0 - написал, теперь еще для stm32F4 и EFM32? С последним тоже случился облом.

На роботе с stm32F071 я на одну шину i2c посадил еще и BGM13P. Думал, что он мог бы тоже из EEPROM по этой шине прочитать свои конфигурационные параметры. Но не сложилось - оказалось, что EMLIB-овский i2c не поддерживает multi-master. Поэтому пока некоторые параметры hardcoded. Надо думать, как из этой ситуации выкрутиться.

Посмотрел презентацию при датчики холла, пошел на фарнелл (маузер сегодня с утра что-то глючил) и поискал сенсоры si7202. Хм, но у них оказалось, что уровень для Operate point и Release point разные: типа +1,4mT и -0,6mT. Но сделал поиск вообще - оказалось, что infineon и diodes inc имеют в своём арсенале сенсоры у которых эта величина одинакова.

Re: RSLK от TI (Robotic System Learning Kit)

Сб окт 31, 2020 19:45:05

У силлабов тоже есть сенсоры с симметричными порогами, см. список.
Насчёт hotkeys в Eclipse - всё написано в Гугле, например здесь. Вот, например, как задействовать F7 для компиляции проекта. Там-же можно и для компиляции отдельного файла свою комбинацию добавить.
keys.png
(44.13 KiB) Скачиваний: 192

Re: RSLK от TI (Robotic System Learning Kit)

Сб ноя 07, 2020 20:55:07

То, чего я так боялся, что случится - случилось! Я постоянно боялся, что играясь с LaunchPad-ом я нечаянно сотру ту часть флеша где у меня лежат конфигурационные параметры и я не смогу вспомнить, какие там были значения, чтобы восстановить. В общем, так и случилось. Не, ну я был когда-то сделавши имидж памяти при помощи UniFlash. Только это было не регулярно и из-за проблем с этой программой (работает когда захочет, а когда нет - хоть об стену бейся!) оказалось, что я не смог восстановить коэффициенты PID контроллера двигателей.

Тут я сказал - хватит. Надо внешнюю EEPROM независимую от памяти программ ланчпада. Вопрос, какую? i2c? Пройденный этап - скучно. Тут посмотрел на схему TI-RSLK MAX Chassis Board v1.0 и мне бросилось в глаза, что 3 контактика P10.0, P10.2 и P10.3 у ланчпада свободны - никуда не подключены, а на эти контакты выходит EUSCI_B3 - последовательный порт. Ну, его можно сконфигурировать в режим SPI, например. Правда для SPI не хватает еще P10.1 (spi_clk), но он идёт на цепь AUX_C, которая подключается к плате дальномеров OPT3101 на тот контакт, который зовётся GP1 и, похоже, в данном случае не используется (когда этот модуль придёт - штырьки там запаивать не буду). Так вот, а еще у меня валялись, когда-то давно приобретённые S25LF204 - 512K SPI EEPROM. К тому проекту, для чего приобретал, я охладел, вот они и провалялись без дела - теперь будет от них польза.

С SPI я уже имел дело, подключая OLED дисплей, в 11 лабораторной работе. Только там был EUSCI_A3. Ну, взял, скопировал инициализацию, обработчик прерывания, поменял всюду "_A3" на "_B3". Так, передача есть, осталось добавить приём. О, это оказывается не так просто. Ведь приём происходит разом с передачей. Т.е. для приёма надо передавать. И когда я передаю, я принимаю. Как определиться, когда читать, когда писать? Крутил-крутил переменные, пока они не выстроились в стройную логичную систему. Теперь, подаю на вход функции параметры - получаю нужное число импульсов. Вроде, основа есть.

Теперь попробую подключить память и буду туда читать-писать. Ой, как подключаю ланчпад - всё гаснет. Ага, сделал короткое замыкание. Микросхему припаял на кусок печатной платы вырезанный из платы для последнего робота - там для BGM13 я развёл как раз для такой SPI EEPROM. И вот вырезая, оголил кусок земляного полигона и припаивая проводок к ножке микросхемы - проводок касался этого полигона и коротил на массу. Ах, а я так красиво был усадивши эту платку с микросхемой в термоусадку! Ну, что поделать. Начал писать-читать. Что-то ничего не читается, а пишется ли? Неизвестно, прочитать то не удаётся. Начал искать обрывы, проверять правильность соединения, даже осциллограф вытащил и с ним начал смотреть сигналы. Аааа, фаза импульсов не совпадает - данные меняются по фронту, а должны по спаду. Поменял полярность - что-то уже заработало.

Вообще, самую большую головную боль мне доставил сигнал выборки P10.0/UCB3STE. Тот, что надо подавать на вход CS# микросхемы памяти. Он как-то не алгоритмизируется. Его надо активизировать в начале транзакции и снять по окончании. Так вот в автоматическом режиме, стоит чуть проспать и не записать в передающий регистр данные, как этот сигнал деактивируется и транзакция прерывается. Пробовал поднимать скорость, уже при 6 МГц были случаи, когда эта потеря происходила. Поэтому, пришлось этим выводом управлять программно. И работать на скромных 1 Мгц (нам спешить некуда), иначе, есть реальный шанс получить overrun error (я пока этот флаг игнорирую).

тут исходники:

Re: RSLK от TI (Robotic System Learning Kit)

Пт ноя 13, 2020 02:09:27

Если применяете ToF (Time of Flight) сенсоры в своих роботах, может Вас заинтересует вебинар от ST по их новой продукции. Я просмотрел сегодня, моду PDF слайды прислать если интересно.
Ответить