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

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

Вс мар 14, 2021 09:49:14

То есть, вопрос закрыт?

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

Вс мар 14, 2021 10:15:17

Наверное, да. Это вне моего контроля. Могу только пойти и создать тикет - что там за J-Link CDC такой? Прошелся по конфигурации J-Link - ничего не нашел. Думал, может, это проблема Putty - что RTS не активирован -поставил даже TeraTerm как в AN0059.0: UART Flow Control - никаких изменений.

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

Вс мар 14, 2021 19:47:02

Установки в регистрах выгядят правильно, можно попробовать вывести UART на внешние выводы и задействовать внешний преобразователь USB-UART. У меня нет такой плвты, не могу подключиться. А на других платах, например Thunderboard Sense 2, удалось добиться работы UART в 4-проводном режиме через отладочный Jlink?

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

Пн мар 15, 2021 17:15:46

На внешние выводы не буду пока пробовать... потому как потом окажется, что это проблема драйверов USB-Com. Но попробовал на TB sense 2. Проблемы теже, да и работает менее стабильно. Немножко была проблема с коэффициентом деления. По схеме там кварц 48МГц, но похоже, что тактовый там 38.4 - встроенный RC? Один раз, вроде, завелось... но, мне так показалось, что или Putty не корректно реагирует на изменение параметров порта на ходу, или если не закрывать flash programmer, то возможно заливается та версия, что была в момент открытия его. Так что я совсем не понимаю что происходит, а ткнуться пробником в цепь там возможности нет совсем.

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

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

Вт мар 16, 2021 07:12:11

Да, действительно к сигналам UART на плате не подобраться. Но мне кажется, что всё нормально работает. При передаче данных из МК (мне) сложнее создать ситуацию ожидания сигнала RST драйвером. Я собрал схему на монтажке, состояшую из отдельного BGM220 модуля, соединённого с USB-UART конвертером на CP2102N.
o3.jpg
(67.2 KiB) Скачиваний: 207

Сконфигурировал UART на 4-проводной режим, а также TeraTerm на Hardware Control RTS/CTS в проекте.
USART.zip
(30.35 KiB) Скачиваний: 232

Далее, в TeraTerm читаю огроменный файл. Посмотрел сигалы на плате.
o1.jpg
(93.04 KiB) Скачиваний: 204
и
o2.jpg
(93.98 KiB) Скачиваний: 207

Видно, что МК притормаживет приём файла время от времени, в то время как не передачу сыплет байтами как из пулемёта. Т.е. терминал на компе успевает загрузить всё в свой буфер и не тормозит передачу из МК. Нужно внешнее приложение, выставляющее сигнал RTS, т.к. терминалом он все время разрешён. Короче, у меня нет основания считать, что что-то не работает.

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

Вт мар 16, 2021 08:22:09

Ну я и не думаю, что проблема в мк. Проблема явно или в JLink. или монтаже на плате (например, кусочек припоя залипший между ножками). СОбственно, сделал тикет. Вот ответ:
I could reproduce your issue. it looks the EFM32GG395 never assert the RTC even I enable the hardware flow control.
I tried to change below code in routine RETARGET_SerialEnableFlowControl1 and EFM32GG12 could send/transmit to EFM32GG395/VCOM.

У меня couldn't send/transmit. Короче, rotten luck.

Ну этот момент непринципиален, так как этот интерфейс всего-навсего для отладки-конфигурации и на саму работу влиять не должен. Тут подумываю, за какой следуюший модуль хвататься. Сначала думал, DMA vs Timer, а сейчас подумываю про i2c, так как наверное, не стоит торопиться впаивать эту плату в макетку, чтобы начинать крутить двигатели. И пока позаниматься дальше коммуникациями.

Немного забегу вперед,это нужно для планирования ресурсов: ADC умет оцифровать 8 каналов последовательно? А то я смотрю на схему аналоговых соединений - там всего 4 шины + 4. Но первые 4 AX, BX, CX и DX подключены к ADC мультиплексору POS, а вторые AY, BY, CY, DY - NEG. Значит ли это , что реально я могу только 4 канала оцифровать?

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

Вт мар 16, 2021 08:55:36

Можете скопировать сюда свой заданный вопрос в тикете?

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

Вт мар 16, 2021 16:40:44

Ну,если кого интересует мой корявый английский...
А вот только что удалось решить проблему. Во-первых перепрошил новую прошивку J-Link (у меня была какая-то 0v....на 1v4p2b352. Однако, какое старьё маузер продаёт...),а во вторых (наверное, это было самое главное) в админовской консоли этому адаптеру дал команду
Код:
serial vcom config handshake rtscts

И теперь всё работает как надо.

С АЦП, похоже, есть возможность сканировать (как в даташите написано) до 32-х входов. Посмотрим. Пока, мне не удаётся придумать как распределить остальные ресурсы. На этой плате слишком мало контактов. и то среди них 2 контакта выделены на какой-то BOARD_ID.

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

Вт мар 16, 2021 18:23:13

Да, забыл ответить про АЦП: можно повесить неколько пинов на ту-же аналоговую шину и сканировать более чем 4 канала.
А что, Вам прислали какие-то изменения в коде функции RETARGET_SerialEnableFlowControl1? Если Да, можете выложить их сюда?

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

Вт мар 16, 2021 20:08:48

Изменения "RETARGET_SerialEnableFlowControl" Это было для "clarification". Т.е. для подтверждения проблемы нужно было выполнить проект из SSv4 с добавленной строчкой.

If I understand it correctly you are using the VCOM (EFM32GG395 controller that works as onboard JLink debugger, which integrate a USB CDC interface). You route the EFM32GG12 USAR0 to JLINK CDC port.

I could reproduce your issue. it looks the EFM32GG395 never assert the RTC even I enable the hardware flow control.
I tried to change below code in routine RETARGET_SerialEnableFlowControl1 and EFM32GG12 could send/transmit to EFM32GG395/VCOM.
Код:
  RETARGET_UART->CTRLX    |= USART_CTRLX_CTSEN | USART_CTRLX_CTSINV;


I need check with the board designer to see what happen. I am testing the vcom example with minor change.
Код:
int main(void)
{
  int c;
  int index;

  /* Chip errata */
  CHIP_Init();

  /* Initialize LEUART/USART and map LF to CRLF */
  RETARGET_SerialInit();
  RETARGET_SerialEnableFlowControl();  //added this line to enable flow control.
  RETARGET_SerialCrLf(1);

Я подтвердил, что без строчки работает, а после добавления - нет.

Тогда я получил такой solution:

I investigate this a bit. It looks below procedure could make the hardware flow control work.

1. upgrade the adapter firmware to the latest.
Изображение
on my side the adapter firmware is located in folder like below:
C:\SiliconLabs\SimplicityStudio\v4\offline\hwtools\firmware\S1015C_adapter_firmware_package
2. right click and open console in debug adapter window.
Изображение
3. send command in 'admin' tab
serial vcom config handshake rts
Изображение

И после его выполнения, ничего не изменилось, но я попробовал дать в команде не только 'RTS', а 'rtscts' - и тогда все проекты заработали: "bare-metal-iostream" и мой проект. Т.е. как я понял, у купленной платы в JLink была зашита старая фирмварь и еще выключен rts/cts handshake для vcom CDC.

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

Вт мар 16, 2021 21:09:01

Ценная информация. Спасибо!

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

Вс мар 28, 2021 14:43:59

Увы, не всё так радужно. Оказалось, достаточно перезапустить терминал, как всё возвращается на круги своя - снова выставляется СTS и данные с микроконтроллера в J-Link не идут, пока опять ручками в консоли не введёшь команду "serial vcom config handshake rtscts", что несложно если запущен SimplicityStudio (я вообще эту вкладку держал постоянно открытой, чтобы после просыпания компьютера её быстро выполнить). Причем если спросить конфигурацию командой serial vcom, получаю ответ:
Код:
TB> ----- Virtual COM port -----
Stored port speed  : 115200
Active port speed  : 115384
Stored handshake   : rtscts
Actual handshake   : rtscts
TB>
Но трансфер не идёт до повторения той команды. Зато после команды вываливает, всё что я успел в буфер натолкать. Так что я просто выключил этот несчастный flow control.

Запаял платку на макетку, макетку воткнул в шасси робота и... снова не так. Планировал использовать плату с дисплеем и кнопками, что я сделал для установки сверху тексаковского ланчпада, но оказалось, что разъём соединяющий дисплей с шасси, мешает всавить USB штеккер для программатора. Вставить, возможно, но для этого надо плату приподнимать - не очень красиво выглядит. Но хотя бы функционирует. Взялся за изучение таймеров и получил первое движение робота - моторы работают. Попутно адаптировал драйвер i2c, что был написавши для MSP - теперь работает под EFM. Причем, мне кажется, даже лучше получилось, чем для MSP - все переходы машины состяния происходят только прерываниях - нет проблемы с чтением "одного байта", как было у меня с MSP. Но надо еще тестировать. Причем выяснил, что если в даташите написано что надо посылать NAK+STOP, это надо делать так:
Код:
I2C_DEV->CMD = I2C_CMD_NACK | I2C_CMD_STOP;
а не
Код:
I2C_DEV->CMD = I2C_CMD_NACK;
I2C_DEV->CMD = I2C_CMD_STOP;

Пока свежа в памяти информация про таймеры занялся тахометрами. Причем, так как в системе помимо 16-битных таймеров присутствует пара 32-битных и, вдобавок, все таймеры могут работать как квадратурные энкодеры, решил к таходатчикам подключить сразу два таймера: WTIMER - в квадратурном режиме для отсчета позиции, а простой TIMER - для измерения периода. Правда, из наличествующих выводов не удалось найти вариант, чтобы один вывод был подключен и к нужному каналу захвата WTIMER и TIMER. Поэтому на 4 сигнала пришлось задействовать 5 выводов. WTIMER-ы уже работают - тестовая программа показала, что цифры меняются, когда робота катаю по полу. Измерение периода - набросок сделал, но пока не тестировал. Думал, может сразу запустить PID регулировку двигателя - ведь механическая часть не изменилась. Но, пока проблема со считыванием конфигурационных параметров.

После того как сделал измерение расстояний на WTIMER, обнаружил, что то же самое можно было сделать на модуле PCNT - он тоже умеет работать квадратурным декодером и их на кристалле целых 3. Но он, к сожалению, всего 16-битный. С другой стороны, я тут прикинул, что 16-битный счетчик у моего робота будет иметь "период" около 10 метров, Не криминал, вообще-то, так как сегмент такой длины не ожидается. Единственное, нужно будет озаботиться, чтобы вся математика в этом случае выполнялась в 16-битном режиме.

Хм, вроде компиляторы, что для MSP, что для EFM, мне казалось, одинаковые - GCC. Но, похоже ключи и настройки разные. Code Compose Studio мне всю плешь проел бы за то, что я оперирую 16-битными данными. Simplicity Studio мне еще ни разу такого предупреждения не выдал. Зато, в одном месте предупредил, что я могу использовать неинициализированную переменную. И это было в том месте, где я в CCS промолчал. Сделал "не спортивную функцию" - ввод и редактирование маршрута (на самом деле мне нужно было иметь возможность просто посмотреть сгенерённый маршрут, но в целях юниформности сделал и редактирование) и иногда там что-то глючило, а собраться пройтись отладчиком и выловить, что там происходит никак не мог собраться.

И да, я использую готовый код от MSP, только меняю хардварную часть. Я уже жаловался, что мне выводов не хватает? Так вот пожалуюсь снова. После дисплея, i2c, моторов и тахометров у меня осталось всего 9 выводов. при этом, подразумевается, что для SPI я делаю два сигнала CS - для OLED дисплея и EEPROM. Вот про EEPROM у меня печально. При таком соединени, я не могу разом использовать EEPROM для запис журнала и делать вывод на дисплей. А у этого микроконтроллера есть QuadSPI. По описанию, я так понял, что можно на него насадить эту EEPROM и получить её содержимое "прозрачно" в адресном пространстве микроконтроллера. Правда, с нахрапа никаких примеров использования в гугле не нашел (про силикон лаб, вообще, в гугле ничего толком не находится), а даташит... скажем так, там упоминаются такие термины и сокращения, которые я не знаю. Если про DDR/SDR я догадываюсь, то что поразумевается под PHY в данном контексте - еще не в курсе. И не до конца уверен, что моя S25FL204K будет там работать. Да и с выводами на плате печально - если захочу подключить так, то дисплей нужно будет перетаскивать в другое место и тогда для сенсора линии выводов совсем не останется. Пока, я укладываюсь (осьтавшиеся 8 выводов пойдут под сенсор линии, а 9-й отдам под АЦП для измерения напряжения батарейки), но жаль, что не могу попробовать то, что для меня еще внове.

Тут на днях удалось всё же приобрести TPS61089 - может всё же попробую, когда с этим наиграюсь, сделать маленького робота. Хе, планировал делать на STM32... но теперь, что-то сомневаться начал. Вообще, в дефиците микросхем виноват автопром, как я в новостях вычитал. Они в ожидании спада производства, заказали меньше микросхем, поэтому производители и перестали их клепать. Теперь все хотят возобновить производство, а деталей нет. Да и говорят, у Renesas что-то было погоревши недавно.

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

Вс мар 28, 2021 15:11:50

MCP23S017 - расширитель портов с SPI интерфейсом. Может поможет.

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

Вс мар 28, 2021 16:11:59

Увы, это не спасёт отца русской демократии. А вот если есть подобного типа микросхема с таймером и 8 каналами захвата... Знаю, что есть такие UART, счетчики событий итп. Но вот про захват не попадалось. Потому как для сенсора линии мне нужно отмерять время, за которое разрядится конденсатор через фотоприёмник. Была как-то мысль самому такое сляпать на CPLD, но 8 каналов захвата по 8 бит - это уже 64 триггера, а еще надо и счетчик, и логика ввода-вывода. Так что в xc2c64 оно уже не вместится, а более крупные CPLD занимают на плате гораздо больше места, что для такой маленькой проблемы уже за много.
Тогда уж надо поискать 8-канальный ADC... но пока у меня стоят сенсоры, которым требуется таймер. Была мысль сделать плату для подключения к АЦП, но фотодатчики денег стоят. Сейчас у меня есть куплен один комплект, но это для маленького робота.

А расширитель портов у меня и так уже используется. Кнопки, что я нажимаю на плате дисплея, подключены через PCA9536 к i2c.

Вообще, я склоняюсь к изготовлению своей платы, просто сначала надо кристалл "почувствовать". Я такую плату в формфакторе Launchpad на Cypress PSoC5 уже сделал, просто пока не запускал - увлёкся EFM-ами.
Изображение
На ней, кстати, тоже напряг с контактами вышел - всего один вывод свободным остался.

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

Вс апр 11, 2021 12:08:29

Пока я торможу - не могу придумать как на EFM32 считывать конфигурацию из SPI EEPROM, решил слегка развеяться и порешать лабиринт.

Когда я начал решать лабиринт, у меня были 2 ограничивающих фактора - дополнительное время требуемое на поворот и замедление при проходе перекрёстка прямо. Собственно, от второго я, вроде, избавился (или стараюсь избавиться), поэтому при вычислении кратчайшего расстояния я этот параметр считаю, что можно принять равным нулю. И решение лабиринта оказывается приемлемым до тех пор, пока разгон и торможение робота составляет меньшую часть длины сегмента между узлами. Но я тут прикинул, что сейчас мой робот разгоняется целых 12 сантиметров. При длине сегмента 30см, получается так, что он 2/3 времени расстояния разгоняется и тормозит. Поэтому, надо бы в расчете сделать так, чтобы чем длиннее прямой ход, тем "выгоднее" этот маршрут получался бы.

Это можно достичь так - помимо реально существующих участков AB, BC, CD, DE итд, создать участки AC, AD, AE, BD, BE итд, Причем длина AC меньше суммы AB и BC, |AD| < |AB|+|BC|+|CD|.
Изображение
Но создавать в памяти все эти линки - слишком много съест той же памяти. И тут созрела мысль. Если я смог сделать виртуальным линк соединяющий меридианальные и широтные направления, то почему не сделать такими же виртуальными и эти связи. Поэтому попытался написать расчет так, что расчитывая узел считать не только 2 соседних узла (с севера и юга для меридианального направления или с востока и запада для широтного), но и все остальные прямо доступные следом за ними.

Следующая проблема - как расчитать "стоимость" этих сегментов. Потому как они перестали быть пропорциональными расстоянию. На сайте micromouseonline.com оказывается есть статья "Time taken to run a straight". В ней Питер Харрисон ввёл параметр k, как отношение ускорения к начальной скорости и получил очень простую формулу "сколько времени требуется для прохода n клеточек". Но, эта формула подразумевает, что за максимальное число клеточек робот не достигнет своего предела скорости, т.е. он будет 8 клеточек разгоняться и 8 клеточек тормозить не достинув максимума. У меня пока еще не так... Поэтому я об этом еще буду думать. Ну и конечно, то что у меня параметры задаются в совершенно разных единицах измерения: максимальная скорость в сотых долях оборотов колеса в минуту (шаг колеса известен - 220мм, так что 1 соответствует 2,2/60 мм/сек), а ускорение в изменении этой "сотой доли в минуту" за 1/400 секунды - задачу не облегчает. Бррр.

Пока есть возможность, дополню примерами.

Алгоритм без возможности выбора длинных прямых участков:
Изображение

Алгоритм с выбором длинных прямых участков:
Изображение
Совсем небольшая разница, но прямой кусок увеличился на 2 клеточки.

И кстати, когда я написал этот текст, во мне закралось сомнение, что при такой модификации алгоритм заполнения (flooding) уже работает не корректно. Для этого сделал два теста:
Изображение и Изображение
Левый сделан алгоритмом заполнения, а второй по алгоритму Дейкстры (сортированной очереди). Разница налицо.

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

Вс апр 18, 2021 09:26:43

Победа над SPI EEPROM. Я долго оттягивал (из-за лени) момент, когда всё же надо будет взяться за написание доступа к EEPROM. Потому как знал, что для этого придётся еще залезть и в DMA. Радости доставляло еще и то, что память у меня получается сидящей на одной шине с OLED дисплеем. И хотя, вроде, это классическая конфигурация - несколько устройств на шине выбираемые разными сигналами CS, с поддержкой такого ни один драйвер связываться, почему-то, не желает.

В общем, я поначалу, чтобы самому не возиться с переключением CS и конфигурированием DMA, решил применить готовый SPIDRV. По прошлому разу помнилось мне, что там функциям драйвера передаётся указатель на структуру с которой желаю работать и дальше драйвер делает всё сам. Но не тут то было. Оказалось, что я не могу сделать две driver instances указывающий на USART3, которые имеют разные локации выводов.

После такого облома, пришлось, всё же самому заняться. Получилось не так уж и сложно. Так как я для OLED дисплея уже отслеживал окончания трансфера, то этот же признак я использовал, чтобы знать что можно не только переключить линию data/command дисплея, но и полностью регистр EUSART3->ROUTELOC0, чтобы сигнал chip select переместился на нужный контакт. Но я поленился: приём сделал через DMA, но передачу в SPI делал по-старому, по прерываниям. И вот, после того как я задрал тактовую частоту до 5МГц (5 Mbit/s) - снова, ничего не считывается из EEPROM. Ну да, по прерываниям с такой скоростью программа не успевает кормить EUSART данными и он снимает CS с устройства и EEPROM считает, что эта транзакция завершена. Пришлось напрячься и сделать так же передачу тоже через DMA. После чего копирование из памяти в память - сделать было очень просто.

Вот для примера функция "обмена" с EEPROM - данные из буфера заливаются в SPI и из SPI данные заливаются в этот же буфер:


А всё то время, что я ленился, я посвятил другой игрушке. Когда, боль-менее разобрался с таймерами, подумалось мне, что можно сделать одну интересную штуку: чтобы первый таймер формировал импульсы, а другой таймер эти импульсы считал. Для счета импульсов, применил PRS - Peripheral Reflex System. С её помощью, я сдалал так, что счетчик считал импульсы с 4 сигналов первого таймера - 3 импульса от разных каналов compare и update event. А и еще, чтобы сбрасывался по фронту импульса compare нулевого канала (когда он есть). Для суммирования импульсов сделал им объединение по логическому ИЛИ. И как ни странно, эта конструкция даже заработала. Но так как я это устройство планирую сделать блютусным - делал его на модуле BGM220P. И тут оказалось, что EFR32BG и EFM32GG несколько отличаются. Первое, что меня ввергло в ступор, когда простая запись числа в регистр таймера вызвала GPF. Оказалось, что в некоторые регистры нельзя писать пока устройство не включено, а в другие - когда включено.

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

Единственное, что мне еще хватает в PRS - вывести эти каналы на контакты микросхемы. Не только, чтобы посмотреть на них осциллографом (хотя, это тоже не помешало бы), но и сформировать нужные сигналы. Вот выше помянутый "первый таймер" мне должен сформировать черырёхфазную последовательность, но у него всего 3 канала сравнения. Хотя 3-х вполне достаточно, но два сигнала тогда получаются как логическое выражение из исходных сигналов. Так я мог бы всё сформировать внутри кристалла, а пришлось снаружи припаять к176ЛЕ10, чтобы сформировать требуемые сигналы.

А так, у меня последовательность формируется практически аппаратно. Единственное, по прерыванию по переполнению таймера, в него загружаются следующая партия данных. Хоть, тут DMA несколько круче, чем в MSP432, но сомневаюсь, что мне удастся сделать так, чтобы DMA мне загружало из таблицы 4 числа в 4 разных регистра:
Код:
    TIMER1->TOPB = sequence[line][3];
    TIMER1->CC[0].OCB = sequence[line][0];
    TIMER1->CC[1].OCB = sequence[line][1];
    TIMER1->CC[2].OCB = sequence[line][2];
А запрягать 4 канала DMA - это слишком, тем более, что эта операция должна быть синхронной - нельзя чтобы в регистры попали данные из разных кадров.

Хотя вывести сигналы PRS наружу нельзя, зато, как я понял, внешние сигналы можно без проблем ввести в эту PRS и через неё направить куда мне нужно. Поэтому, следующим этапом планирую рассмотреть, какие у меня есть еще доступные таймеры с каналами захвата и уже таким образом сделать устройство считывающее на роботе фотосенсоры отслеживающие линию. Правда, до того как за это возьмусь, мне еще надо сделать два семижильных гибких шлейфа. А зачищать МГТФ - это удовольствие ниже среднего.

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

Сб май 01, 2021 06:40:02

Хочется начать словами мистера Зорга из фильма "Пятый элемент"... только не могу решить какой: первой фразой "I am little disappointed" или финальной "I am very disappointed".

Когда надумал применить PRS для сенсора линии и начал смотреть... оказалось, что этот модуль на efm32gg не имеет ничего общего с PRS модулем на efr32bg. Структура другая и возможности, тоже совсем другие. И тогда, я подумал, что подключение энкодера к таймерам я могу выполнить не "снаружи", а внутри. Тем самым освободив один вывод микроконтроллера. Немного потыркавшись удалось, соединить пин PB3, который шел на WTIMER0_CC0 c TIMER0_CC0, который я хотел соединить перемычкой через порт PD1, и который, в результате этого высвободился. Правда, выяснилась несколько неприятная особенность. Не все выводы можно так "перекинуть". Например, взбреди мне в голову протащить выводы PE8, PE9, PE10, PE11 - я смог бы протащить только один из них. Но пока мне нужно было протащить только один - всё сработало прекрасно. И, кстати, этот PRS имеет возможность вывести сигнал наружу.

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

Так как я высвободил один вывод порта, была мысль сделать заряд конденсаторов сенсора аппаратным. Напомню, как предполагается работать этому сенсору:

В начале цикла (за 10 мкс до 0) на фотосенсор с подключенным ему параллельно конденсатором подаётся напряжение питания, которое заряжает конденсатор. В момент 0 напряжение снимается и конденсатор начинает разряжаться через фотосенсор. Чем сильнее фотосенсор освещен - тем быстрее конденсатор разряжается.

Так вот, один из каналов ведущего таймера я определил для сигнала PWM, который и будет "последние 10 мкс цикла" давать активный уровень. Сначала думал поставить 8 транзисторов, которые будут коммутироваться этим сигналом. Но, для этих транзисторов надо слишком много места. Поставить микросхему типа 555ИР22 - проводов, вроде меньше, но места еще больше. Мне очень не хотелось делать так как это делают обычно путём простого перепрограммирования порта с ввода на вывод. Во первых в конфигурации порта нельзя отключить периферию - можно только в конфигурации периферии отключить порты. Но тут я подумал, а не задействовать ли PRS? Здесь же сигнал ШИМ можно завести в PRS и вывести на контакт... но, 1 сигнал только на 1 контакт. Хм, я могу этот сигнал раскидать на несколько сигналов PRS - но тут облом, не все нужные мне выводы могут подключаться к PRS. И даже те, что могут - часть подключается к одному и тому же каналу, т.е. разом оба задействовать нельзя. Хм, и получится ли выводить через PRS в порт, который уже подключен как вход захвата таймера??? А, чтобы не переконфигурировать порт с ввода на вывод, тут оказалось возможным сконфигурировать порт как WiredOR - если я туда выдаю лог.1 - на выводе есть напряжение, если лог.0 - то на выводе нет ничего и он работает просто на ввод. Поэтому просто по прерыванию ШИМ я вывожу 1 в порт, а по прерыванию по переполнению счетчика вывожу туда 0. Вот тут я получил, возможно, ответ на предыдущий вопрос - пока не были от выводов отключены входы таймера, я туда вывести ничего не мог.

Другой канал таймера назначил на "порог" срабатывания - граница между белым и черным.

Ну так вот, разобравшись с захватом таймеров, решил поэкспериментировать, как будет работать PRS на включение зарядки конденсаторов. Ресурсы распределены так:
Код:
//                                          (robot's right)
// reflectance sensor 7 connected to PE.11            PRS3#2
// reflectance sensor 6 connected to PE.10            PRS2#2
// reflectance sensor 5 connected to PE.15  tim3cc1#0 PRS14#3
// reflectance sensor 4 connected to PE.14  tim3cc0#0 PRS13#2
// reflectance sensor 3 connected to PE.13  tim2cc2#3 PRS2#3
// reflectance sensor 2 connected to PE.5   tim3cc2#2
// reflectance sensor 1 connected to PE.9             PRS8#2
// reflectance sensor 0 connected to PE.8             PRS3#1
//                                          (robot's left)
Получилось так что второй сенсор выхода PRS вообще не имеет, а нулевой и седьмой делят между собой третий канал, а третий и шестой - делят второй канал. Т.е. реально получается только 5 выводов могу подключить. Ну что же, подключаем:
Код:
    CMU_ClockEnable(cmuClock_PRS, 1);
    PRS->CH[2].CTRL = PRS_CH_CTRL_SOURCESEL_TIMER2 | PRS_CH_CTRL_SIGSEL_TIMER2CC1 | PRS_CH_CTRL_INV;
    PRS->CH[3].CTRL = PRS_CH_CTRL_SOURCESEL_TIMER2 | PRS_CH_CTRL_SIGSEL_TIMER2CC1 | PRS_CH_CTRL_INV;
    PRS->CH[8].CTRL = PRS_CH_CTRL_SOURCESEL_TIMER2 | PRS_CH_CTRL_SIGSEL_TIMER2CC1 | PRS_CH_CTRL_INV;
    PRS->CH[13].CTRL = PRS_CH_CTRL_SOURCESEL_TIMER2 | PRS_CH_CTRL_SIGSEL_TIMER2CC1 | PRS_CH_CTRL_INV;
    PRS->CH[14].CTRL = PRS_CH_CTRL_SOURCESEL_TIMER2 | PRS_CH_CTRL_SIGSEL_TIMER2CC1 | PRS_CH_CTRL_INV;
т.е. один сигнал с CC1 второго таймера соединил с 2, 3, 8, 13 и 14 каналами. Сам таймер в PRS формирует уровень, а не импульс:
Код:
TIMER2->CC[1].CTRL = TIMER_CC_CTRL_MODE_PWM | TIMER_CC_CTRL_PRSCONF_LEVEL;

Ну вот, а теперь назначаем сигналы на выводы и включаем:
Код:
    PRS->ROUTELOC0 = PRS_ROUTELOC0_CH2LOC_LOC2 | PRS_ROUTELOC0_CH3LOC_LOC2;
    PRS->ROUTELOC2 = PRS_ROUTELOC2_CH8LOC_LOC2;
    PRS->ROUTELOC3 = PRS_ROUTELOC3_CH13LOC_LOC2 | PRS_ROUTELOC3_CH14LOC_LOC2;
    PRS->ROUTEPEN  = PRS_ROUTEPEN_CH2PEN | PRS_ROUTEPEN_CH3PEN | PRS_ROUTEPEN_CH8PEN |
                     PRS_ROUTEPEN_CH13PEN | PRS_ROUTEPEN_CH14PEN;
И как ни странно, всё работает. Даже те каналы, которые подключены ко входам захвата таймеров. Т.е. тут полная гармония, в отличии от случая, когда я вручную вывожу лог.1

Есть одна странность. Если у робота на MSP432 "порог" между черным и белым был в районе 800, то у этого в районе 300. Возможно, из-за того, что порог уровня лог.1/0 у EFM32 выше. Но я еще проверю. Но вот из-за этой "повышенной" чувствительности возникает проблема с влиянием паразитной засветки. И тут есть два решения или уменьшать паразитную засветку установив какого-либо типа ширму вокруг сенсоров, или "вычитать" помеху. Правда, для вычитания помехи требуется, чтобы все каналы давали пропорциональный сигнал (а не половина, как у меня сейчас). Так как у меня больше нет доступных таймеров, видимо, сенсор придется переделать на аналоговый и считывать ADC. Плату уже нарисовал, осталось собраться с духом и заказать платы.

Немного повозился с модулем CRC. Конфигурацию в EEPROM я защищаю контрольной суммой CRC32. Тут конечно, надо смотреть внимательно на порядок следования байт и бит. В MSP432 "правильная" контрольная сумма получалась, если биты писать прямо, а результат считывать с реверсного регистра. "Правильная контрольная сумма", эта та, которую если дабавить к текущей сумме в результате даст 0. Т.е. я считаю контрольную сумму без последних 4 байт и записываю эту сумму на их место. Затем, при считывании всех байт должен получиться 0, если данные не повреждены. Вот, а в EFM32 и писать, и читать надо было с "прямых" регистров, чтобы получилась бы такая же контрольная сумма.

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

Сб июл 10, 2021 15:57:30

Захотелось мне приключений... на свою голову. На сайте micromouseonline.com нашел другой способ управления двигателями. Не ПИД, а Phase Lead - не знаю как он зовётся по русски - ФАПЧ? Математика там оказалась мне не по зубам, но в конце статьи, для таких непонятливых как я, небольшая экселевская табличка, для расчета коэффициентов. Ну, попробовал снова снять характеристики двигателей, внести их в таблицу и получить коэффициенты. Потом набросал код и попытался запустить. Увы, ничего хорошего не получилось - ничего похожего на регулирование. Пока у меня робот стоял "на чурбачках" и дрыгал колёсами в воздухе, я пытался проверить нет ли ошибок в коде итд. И вот, в один момент, слышу как затих один мотор и через несколько секунд - второй.

Код сразу в сторону - надо выяснять что случилось. Батарейки? Драйвера? О - моторы! Тестером звонятся, а вот при подключении к лабораторному БП вижу, что ток жрут, но не крутятся. Что ж, пришло время разобрать эту конструкцию и посмотреть, что там в животике. А в животике, оказался очень простой моторчик. И у меня сразу возникло ощущение Deja Vu. После небольшого поиска удалось найти нечто похожее на то, что нужно. Диаметр вала во всяком случае совпадал. Хоть цена была просто смешная, зато доставка кусачая. Ну, заказал дюжину моторов - чтобы их теперь можно было палить в своё удовольствие и чтобы доставка хотя бы сравнялась со стоимостью товара. Опосля двухмесячного ожидания получил эти моторчики... Оказалось не совсем то: маломощная версия того, что было изначально.

Ах, я не написал, что случилось с моторчиком - щетки коллектора перегорели. И так как это очень дешевенькие моторчики, то щетки у них не графитовые, а простые металлические пружинки. Причем, состоящие из двух "пальцев". И у них отгорело по одному "пальцу"так, что оставшийся касался коллектора в правильном месте, а отгоревший - теперь тоже касался коллектора, только в другом месте. Конструкция полученных двигателей была такая же, только выглядит еще более хлипко. Но самое проблемое отличие было в том, что на фотографиях лота нигде не было вида со стороны контактов. И вот там еще две нестыковки. Во-первых форма контактов - они были загнуты и вставлены в пазы в корпусе. Ну это не большая беда - вытащил и разогнул так чтобы можно было напаять плату энкодера. А во-вторых - диаметр фланца из которого выходит вал. У оригинального он имеет диаметр 5мм и на него точно садится плата энкодера. И еще под этим фланцем, виден подшипник. Скольжения, конечно. В полученном двигателе, диаметр фланца 3.5мм и никакого подшипника не видать - похоже вал просто крутится в этом пластике. И что будет, если вал нагреется и проплавит этот пластик? Но тем не менее, энкодер напаял - теперь посмотрим, какие у этого мотора будут характеристики....

А никакие. Когда просто вставил в рабочий робот (где моторы под Пропорционально-Интегральным управлением) и запустил тест моторов - в течении минуты сдохли. Может я переборщил с коэффициентами и у меня слишком жёсткое регулирование?

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

Наличествующий сенсор, как аналоговый использовать не удастся, так как фотодиод на плате зашунтирован конденсатором 2.2 nF, что с резистором 47к даст фильтр с постоянной времени в треть миллисекунды. Поэтому нужна плата без конденсаторов. Такие у меня есть, но они с сенсорами KTIR07 - а они без линзы и они должны быть гораздо ближе к поверхности. Поэтому нарисовал свой вариант такого сенсора в совместимом конструктиве. Проблема была как запитывать светодиоды подсветки. К сожалению,что за драйвера использует Pololu для своих сенсоров, тайна покрытая мраком, поэтому я применил свой излюбленный вариант MIC2292 - повышающий драйвер светодиодов.

Изображение

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

Теперь остаётся изучить работу АЦП и начать думать каким образом делать "вычитание паразитной завсетки". Пошел читать даташит.

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

Вс июл 18, 2021 14:28:42

Итак, резюме по двигателям. Так как затарился я дюжиной моторов, смонтировал следующую пару и решил пройтись систематично: снять характеристики и только потом вставлять в схему регуляции. Так вот характеристики снять не удалось. На графиках выходил какой-то бред. Вероятней всего, снова влияние моторов на датчики холла? Как проверить? А, есть идея - снял с осей магнитные диски. В идеальном случае все отсчеты должны быть нулевыми. А если есть влияние магнитного поля моторов на таходатчик - будут какие-то данные. И вправду, оригинальные Pololu моторы помехи не создают, а вот эти новокупленные - вижу множество срабатываний. Так что в данном случае - деньги на ветер. Надо будет покупать на TME.eu оригинальные моторы. Так что мало того что эти моторы "повизгивают", дают массу помех, так они еще и медленнее крутят - попробовал поставить один такой, другой оригинальный - при одинаковом питании робот стабильно заворачивает

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

Чт сен 02, 2021 16:58:01

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

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

Тут надо пройтись по нескольким модулям. Во-первых таймер - он (планировалось, что) будет генерить ШИМ для включения и выключения светодиодов подсветки и создавать два импульса, которые я через PRS объединю по ИЛИ и подам на вход АЦП. Так что второй модуль - PRS, который будет делать только что упомянутое и еще переносить сигнал ШИМ на нужный мне вывод. Тут оказалось, что выбранный мною вывод PD1 я не могу никак использовать. На него не выходит ни один регистр захвата сравнения нужного мне таймера, да и PRS сигнал я тоже туда вывести не могу. Пришлось поменять - перенес на PF5 - туда можно вывести PRS. Третий модуль - АЦП. С ним разбирался долго и всё равно еще некоторые моменты не понял. Но тем не менее, где-то с третьего раза заработало. Последнее, что я вспомнил, что забыл сделать - включить тактирование. Конечно, самое сложное было указать последовательность сканирования входов. Нечто среднее, между жесткой привязанностью и полной свободой. Тут полная свобода в пределах группы выводов. Тусовал-тусовал выводы, но всё равно, придется монтаж переделывать, так как не могу их расположить так, чтобы сканировались по порядку. Хотя я немного недопонял. По диаграмме, получалось, так , что на положительный вход АЦП коммутируются только шины X, поэтому соединение выводов с шиной Y игнорировал. Но потом, вычитал, что можно использовать и шину Y тоже, просто АЦП опору подключит к положительному входу и несмотря на то, что результат получится отрицательный, в регистр всё же будет записан правильный результат. Вот только как в цепь всунуть операционник (на будущее), пока не увидел или это в режиме сканирования нельзя? Ну и четвертый модуль - LDMA. Надо же как-то по-быстрому результат оцифровки поместить в массив. Вот что мне не очень нравится, я не понимаю, как с этим LDMA сделать циклический режим работы, как я делал с STM32F030/051/071. Поэтому просто в прерывании окончания трансфера инициализирую следующий трансфер. Единственная радость в том, что в этом DMA нет проблем с назначением каналов, как это было с MSP432. Все каналы равны и различаются только приоритетами.

Но вот если я всё же смогу делать два измерения, с освещением и без, как сделать так, чтобы они не перепутались? Правда, пока у меня есть мысль, DMA трансфер делать на 16 отсчетов - тогда первые 8 байт будут с освещением, а вторые 8 - без освещения. Вообще, есть мысль, реакцию на включение и выключение подсветки смотреть не напряжение на светодиодах, а уровень на фотоприемниках - так я увижу сумму реакций и преобразователя, и фототранзисторов. Ну, это буду делать вечером, когда стемнеет и солнечный свет не будет мешать.
Ну вот ночь... желтый луч сигнал включения преобразователя питания светодиодов, а синий луч - сигнал на выходе фотодатчика.
Изображение Изображение
Так что видно, что уровень устанавливается 100мкс спустя после включения подсветки, и после выключения где-то через миллисекунду (период 2.5мс).

Набрела мысль сделать робота на шаговых двигателях, чтобы лучше контролировать движение. Приобрёл пару маломощных шаговых двигателей. Теперь проблема колёс. Пока искал варианты, нашел, что колёса от этого шасси Romi можно насадить на 5мм вал шагового двигателя. Нужно только приобрести mounting hub pololu-1998. Но пока созрею сделать заказ пройдёт время. А тут возникла мысль, что от колёс Romi меня интересуют только эти резиновые покрышки! Поэтому пластмассовую часть я могу напечатать сам под нужные мне валы. Вот результат моих трудов:
Изображение Изображение
Центральное отверстие надо было рассверливать. Взял сверло из комплекта... комплект, правда, странный - только целые миллиметры 2, 3, 4, 5 итд. Вставил пяти миллиметровое сверло в сверлилку, прошелся. Пытаюсь одеть на вал - не лезет. Померял диаметр вала - 5мм. Начал пытаться вставлять со всей силы. Чуток вошел, но это не то. Пробую вытащить - поломал. Из-за этого пришлось новое печатать. Так в чем дело? А вот смотрю, оказывается в этом "целочисленном" комплекте свёрла имеют другие диаметры. То, что я думал 5 мм, оказалось 4.9мм. 6мм - правильное, а 7 и 8 - 6.9 и 7.9. Вот засада. Хотя чего хотеть. В этом году при проверке выбраковал один комплект щупов. На щупе написано 0.9, а на самом деле он 1.0мм (или наоборот, уже точно не помню - на работе в ящике валяется). Как такой щуп ОТК завода выпустило?
Еще там на втулке есть отверстие в котором надо будет резьбу М3 нарезать. Правда, не знаю как мне это удастся - не будет ли сам шкив мешаться? С другой стороны, колёса налазят на вал достаточно туго и держатся без прокручивания.
Ответить