nanorobot

. Смотрел, но видимо кругозор ограничен. Спасибо, интересно будет ознакомиться.

Плюсую. Полагаю что TQFP48 с 12 bit DAC на борту, кроме STM32 нет. Есть в MSP430, но не в счет. Имеется в виду ядро CortexM с частотой >= 32Мгц. Не считая других плюшек STM - большого количества таймеров продвинутой функциональности, RAM 8-32K и т.п. upd: MSP430 c DAC не менее TQFP64, а STM32 есть и TQFP32

Почти все из написанного - лишнее. Суть на самом деле проще. Отладка работает. Почти. Образ грузится. Программа стартует, но достижение breakpoint вызывает у avarice ошибку Segmentation Fault. Запаузить выполнение возможно. Просмотреть значения переменных тоже. На Sourceforge эта тема есть. Есть и способ решения. Но у меня не получилось. Если кто справился - подскажите пжлст. PS: На всякий случай: AVR-JTAG-USB от Olimex - клон Atmel JTAG ICE mkI

Появилась необходимость в старом проекте отловить редко проявляющийся глюк. Проект написан на avr-gcc без использования отладчика. Сейчас безуспешно пытаюсь воспользоваться отладчиком AVR-JTAG-USB от Olimex. Гугл говорит использовать avarice и в Debug Configuration выбрать протокол mi2. avarice c отладчиком коннектится, мегу видит, но дальше тишина... Запустить отладку в эклипсе не получается. В Eclipse 2020, которым пользуюсь в настоящее время, в Debug Configuration поля "protocol" нет. Выход - ставить более старую Eclipse? Или есть варианты? командная строка запуска avarice avarice -j /dev/ttyUSB0 -B 1000 -P atmega128 -d localhost:1201 выхлоп в консоль терминал Waiting for connection on port 1201. Connection opened by host 127.0.0.1, port 33218. GDB: <qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+> ->GDB: qXfer:memory-map:read+ GDB: <vMustReplyEmpty> ->GDB: GDB: <Hg0> ->GDB: GDB: <qTStatus> ->GDB: GDB: <?> ->GDB: S05 GDB: <qfThreadInfo> ->GDB: GDB: <qL1160000000000000000> ->GDB: GDB: <Hc-1> ->GDB: GDB: <qC> ->GDB: GDB: <qAttached> ->GDB: GDB: <qOffsets> ->GDB: GDB: <g> GDB: (Registers)Read 32 bytes from 0x800000 jtagRead command[R, 1]: 52 20 1F 00 00 00 20 20 response: 29 00 07 0F 00 00 00 00 00 00 00 00 00 00 00 00 3D 02 2A 00 3D 6D 10 0B 9F 04 A9 09 BC 02 9D 00 00 41 jtagRead command[R, 1]: 52 20 02 00 00 5D 20 20 response: 00 00 00 00 41 command[2, 1]: 32 20 20 response: 00 00 01 41 PC = 0 ->GDB: 2900070f0000000000000000000000003d022a003d6d100b9f04a909bc029d0000000000000000 GDB: <qL1160000000000000000> ->GDB: GDB: <qSymbol::> ->GDB: GDB: <qL1160000000000000000> ->GDB: GDB: <qXfer:memory-map:read::0,18a> ->GDB: l<memory-map> <memory type="ram" start="0x800000" length="0x20000" /> <memory type="flash" start="0" length="0x20000"> <property name="blocksize">0x100</property> </memory> </memory-map> GDB: <m543a,2> GDB: Read 2 bytes from 0x543A jtagRead command[R, 1]: 52 A0 00 00 2A 1D 20 20 response: 94 0E 00 41 ->GDB: 0e94 GDB: <Z1,543a,2> Segmentation fault (core dumped)

Резонно конечно. Но на мой взгляд, GD32 доступность тоже не очень, с тенденцией к снижению. И удорожанию. Ошибаюсь?

В свете дефицита STM32 может быть стоит обратить внимание на Cortex M от Holtek? Поиск насчет покупки дал только одну вменяемую ссылку https://holtekusa.com/orderonline.php?id=12 Неясно, можно ли купить из России. Digikey ими не торгует - спроса нет? Почему? Имеющие опыт использования, поделитесь. Где приобретали, как оно в работе?

Графическая библиотека LVGL -да, в исходниках. Ваше предложение понятно, что можно я уже таким мерами и сделал, результат не очень. Кроме того, библиотека довольно развитая, там все эти возможности есть, просто пока не получилось найти верный подход. Решение ищешь один раз, а используешь потом многократно, так что "помучиться" смысл есть.

Сложно выбрать правильный раздел форума, продолжу здесь. Начнаю худо бедно делать GUI. Использую LVGL / RT-Thread. Готовых виджетов, понятное дело не хватает . Да простит меня автор LVGL, делаю свой на базе lv_bar. В исходном варианте он только для вывода. У меня он используется для ввода, приблизительно как lv_slider. Это мне удалось. Кроме того на на lv_bar привязывается lv_label (это стандартная фича LVGL), на котором отображается текущее значение изменяемой величины. Так вот, никакими силами мне не удается сделать что бы lv_label располагался в цетре lv_bar. Игры с разнообразными align и fit не приводят ни к каим изменениям, lv_label все время расположен в левом верхнем углу lv_bar. Подскажите, или направьте в соответствующий раздел форума.

В доке самый минимум, часто просто упоминание регистра и в двух словах назначение. Исходники с гитхаба очень помогают. Все стадии обмена тоже формируются "железом" но не в один присест - через манипуляции регистрами I2C_DATA и I2C_CTL. PS. Отчасти оклеветал. I2C_ADDR как раз описан более менее, просто я как то мимо проехал..

Ага, спасибо. Собственно с i2c у меня уже проблем нет, но в этом проекте тоже много полезного.

Не понял. Зачем ведущему хранить адрес ведомого где то, кроме памяти. По крайней мере в случае использования аппаратного TWI, как мастера, регистры I2C_ADDR и I2C_XADDR не используются. Поясните Вашу мысль?

Ну не знаю... На v3s аппаратный TWI запустил за один день, при условии что с камешком раньше дела не имел, не показалось что долго. Из преимуществ - возможность сделать всю работу по прерываниям.. Ну вот есть у меня такой фетиш - реалтайм...

Да я уже понял что бред написал. Чисто глядя исходники инициализации мастера. Про режим слейва мысль в голову не зашла. Ну уж удалять не стал. А I2C аппаратный запустил. Пять минут назад, буквально.

Предыдущий вопрос решил использованием таймера. UART + RS485 в режиме DMA работает. Следующий пункт I2C. При наличии в V3S аппаратных итерфейсов TWI (I2C) драйвера I2C для RT-Thread @V3S реализованы ногодрыгом и запустить их пока не удалось. Решил писать свой, используя аппаратный TWI. Роюсь в тех же исходниках - rpidmx512 и XBOOT. Ни в одном из них не обнаружил использования регистров I2C_ADDR и I2C_XADDR - они вообще зачем то нужны?

Мысль интересная. Единственое "но" в том что слегка нарушается идеология rt-thread в плане использования rt_device. Хотя вероятно этим можно пренебречь. Возможно там и все драйвера не лучше уартовского. использовать только шедулер, сервисы ядра...