Jump to content

    

nanorobot

Участник
  • Content Count

    430
  • Joined

  • Last visited

Community Reputation

0 Обычный

About nanorobot

  • Rank
    Местный
  • Birthday 02/05/1962

Recent Profile Visitors

3340 profile views
  1. В данном случае (Microchip / Atmel) это будет ASF? Еще один куб, - избавь боже...
  2. Изначально да, так оно и было. Но уже довольно давно OS и HAL независимые друг от друга программные продукты. Можно использовать вместе или порознь. Ставить в один ряд куб и Chibios / HAL от итальянского "хлопца" Giovanni Di Sirio, имхо, неуместно. Две большие разницы.
  3. + UART, SPI, I2C, USB, MMCSD, RTC, PWM ... Можно и свысока отнестись, но помощь для старта переоценить сложно.
  4. https://www.chibios.org/dokuwiki/doku.php?id=chibios:products:hal:start
  5. ОС не привязана к периферии , я этого и не утверждал. Но в ChibiOS еще и HAL имеется.
  6. Незнакомая периферия, меньшее, по сравнению с STM32, community. Отсутствие порта ChibiOS. Но все равно взял, пробую...
  7. Под "разобрался" подразумевалось, что нашел где искать привязку к event. Запустить ТСС0 в режиме SLAVE (в режиме мастера ТСС1, запускать хочу от события OVF )пока не получилось. Суть проблемы в том, что по DS, для активизации режима SLAVE, необходимо взвести бит MSYNC в регистре CTRLA. Записываю в ТСС0.CTRLA.MSYNC единичку, контролирую отладчиком, читается как 0. Остальные биты CTRLA пишутся и читаются норм. Саму по себе систему эвентов проверил, привязал к событию TCC1.OVF инвертирование пина порта на светодиод - работает, светодиод мигает. Каких то ограничений на изменение CTRLA.MSYNC в DS не описано. PS. Ограничения обнаружил сам. CTRLA.MSYNC устанавливается в 1 и читается правильно, еси это выполнить ДО изменения регистра управления эвентами TCC.EWCTRL. Но все равно не работает. (((
  8. разобрался.. это в отдельной главе EVSYS.
  9. Согласно DS на данный камень возможно управление таймерами/счетчикам TCC внешними событиями, в регистре EVCTRL можно разрешить/запретить входные события, выбрать тип управления - Start, Stop, Retrigger и т.п. Но нигде не удалось найти каким образом выбрать/осуществить привязку к какому либо событию. В инете удается найти лишь примеры, как это реализовать с помощью ASF, но принципиально не планирую использовать эту библиотеку. Помогите разобраться с вопросом, пжлст.
  10. зависание на этой строке может происходить в случае если для соответствующего SERCOM не включено тактирование. Проверено личным, очень скромным, опытом. вероятно для второго уарта вот в этой строке GCLK->CLKCTRL.reg = GCLK_CLKCTRL_GEN(0) | GCLK_CLKCTRL_ID(SERCOM0_GCLK_ID_CORE) | GCLK_CLKCTRL_CLKEN; у Вас не исправлено SERCOM0_GCLK_ID_CORE на SERCOM2_GCLK_ID_CORE, или что то в этом духе. По возможности, прошу отписаться, в этом ли была причина.
  11. Все UARTы, которые мне доводилось видеть, имели два физически разных регистра данных на одном адресе. Один для приема, второй для передачи. Поэтому переданные данные никогда нельзя увидеть в регистре DATA - там могут быть только принятые данные. Игогда может иметься возможность "закольцевать" приемник с передатчиком, то есть соединить выход передатчика со входом приемника - в этом случае - да, возможен прием "эха", и в регистре данных можно наблюдать переданные данные. Конкретно по ATSAMD и его уарту ничего сказать не могу, сам только начинаю эту тему, но у меня ATSAML - вынужденно переползаю в связи с дефицитом STM32.
  12. Спасибо. Что то начало получаться. Подключился: JLinkGDBServer -if SWD -device ATSAML21E18 Удалось залить прошивку из Eclipse, убедился что прошивка работает. Видимо с OpenOCD что то не так.
  13. Ну во первых в том, что не работает. Не стартует , не останавливается на main(). Во вторых в том что вторая и предпоследняя строки второго лога не вполне ясны, и как бы на что-то намекают. Непонятно на что. Нет лога заливки прошивки в чип - ну и самой заливки как таковой, и тд. А вообще проблема получила и другие грани. Попробовал запустить отладку с этим JLink на давно отлаженном дивайсе на STM32L052, результат - стартует и улетает куда то на адрес FFFFFFFF или как то похоже, и после сброса не работает тоже. Запуск с STLink - все нормально запускается и работает. Кроме того на JLink SWD DPIDR - (сигнатура чипа?) в обоих случаях (и для ATSAML21 и для STM32L052) равна 0x0bc11477. Я бы грешил на сам JLink, но PS: Исходный проект Windows / emBitz и тот же самый JLink запускается и работает норм. Ранее с этим JLink работал несколько лет назад, все это время использовал STLink. Но дефицит STM заставил присмотреться к альтернативным чипам.
  14. Портирую проект для ATSAML21E18B / emBitz под Eclipse / makefile / openocd. Имел ряд сложностей, которые более менее успешно преодолел. Сейчас не могу запустить отладку JLink / OpenOCD. Коннект JLink c таргетом проходит успешно. Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46 Info : Hardware version: 8.00 Info : VTarget = 3.306 V Info : clock speed 1000 kHz Info : SWD DPIDR 0x0bc11477 Info : saml2x.cpu: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for saml2x.cpu on 3333 Info : Listening on port 3333 for gdb connections Запуск отладки вызывает вот такие сообщения в консоль. Info : accepting 'gdb' connection on tcp/3333 target halted due to debug-request, current mode: Thread xPSR: 0x61000000 pc: 0x00002c64 psp: 0x200006d0 Warn : Prefer GDB command "target extended-remote 3333" instead of "target remote 3333" target halted due to debug-request, current mode: Thread xPSR: 0x61000000 pc: 0x00000114 msp: 0x20001688 Обновлял прошивку JLink до последней версии. OpenOCD так же ставил самую новую версию. Не помогло. PS: Исходный проект Windows / emBitz и тот же самый JLink запускается и работает норм.
  15. Пытаюсь запустить FreeRTOS на процессоре ATSAML21E18. Linux, GCC, Eclipse. Нашел нечто подходящее в качестве заготовки на github. Почти все проблемы удалось решить. Уперся в последнюю (надеюсь). При компиляции получаю следующие ошибки: ..FreeRTOSv202107.00/FreeRTOS/Source/portable/Common/mpu_wrappers.o: In function `xPortRaisePrivilege': ..FreeRTOSv202107.00/FreeRTOS/Source/portable/Common/mpu_wrappers.c:69: undefined reference to `portIS_PRIVILEGED' ..FreeRTOSv202107.00/FreeRTOS/Source/portable/Common/mpu_wrappers.c:74: undefined reference to `portRAISE_PRIVILEGE' Поиск показывет что "portIS_PRIVILEGED() " "portRAISE_PRIVILEGE" etc существуют только для CortexM3, M4 и выше. Что где подправить?