openocd & чтение/запись ячеек из TCL

есть задачка из TCL'ного скрипта поработать с массивами в памяти подопытного контроллера.

я что-то не могу найти какими функциями можно это делать

то есть есть нечто вроде

mdb address, count или mdw address, count

и оно выводит на терминал дамп.

вопрос, а как получить тот же дамп/значение ячейки но внутри TCL'ного массива/переменной?

... Цифровая техника вытесняет аналоговую: цифры лучше букв! (ц)

Reply to
Dmitry E. Oboukhov
Loading thread data ...

c openocd разобрался, оказывается в стейбл версии были поломанные команды mem2array и потому при их применении он ругался что их нельзя применять, ну я грешным делом и стал искать что-то другое, а спросил прямо у разработчиков и ответили что в мастере уже пофиксено. поставил

- работает.

поскольку драйвера моего АРМа нет в оосд, то накидал скриптик на TCL который программирует флешку. скрипт бросает 512 байт в флеш и дает команду на запись, ждет готовности, бросает новые 512 итп

работает довольно медленно

возникает соблазн кидать сразу порциями по 20-30 кб (сколько в озу влезет) и передавать управление внутреннему загрузчику.

вопрос - кто по этому пути ходил, сильно можно быстродействие поднять или нет?

вообще кто как АРМы (от атмел в частности) программирует/отлаживает?

... Мы хлещем в жару портвейн! Мы не греем пива зимой!

Reply to
Dmitry E. Oboukhov

Hi Dmitry, hope you are having a nice day!

15 Aug 10, Dmitry E. Oboukhov wrote to Dmitry E. Oboukhov:

DEO> вообще кто как АРМы (от атмел в частности) программирует/отлаживает?

С АРМами пока работать не довелось, для всех остальных платформ общего назначения принцип один - выкинуть нафиг все чужие софтовые пакеты и написать/портировать свои. Получается намного предсказуемее и нет всяких странных проблем, лезущих из чужого софта. Это же касается всяких флеш/бутлоадеров.

WBR, AVB

Reply to
Alexey V Bugrov

DEO>> вообще кто как АРМы (от атмел в частности) программирует/отлаживает?

AVB> С АРМами пока работать не довелось, для всех остальных платформ общего AVB> назначения принцип один - выкинуть нафиг все чужие софтовые пакеты и AVB> написать/портировать свои. Получается намного предсказуемее и нет всяких AVB> странных проблем, лезущих из чужого софта.

софтовые пакеты это имеется ввиду библиотеки? да, исповедуем примерно тот же подход.

у меня вопрос был о программировании/отладке. openocd дает возможность из скриптов поиграться с периферией процессора. то есть например можно через JTAG дергать линии ввода вывода на порту, настраивать таймеры итп. получается очень удобно всякие тесты (те что к реальному времени не относятся) писать: скриптовый язык, можно _быстро_ что-то попробовать/проверить. ну и отладчик можно подключить и прямо по командам походить, точки останова навесить итп

AVB> Это же касается всяких флеш/бутлоадеров.

собственно вся эта тема и возникла по причине того что начал я с того что выкинул предлагающийся Sam-Ba. потому что это какой-то ужоснах

... Подходи, буржуй, глазик выколю!

Reply to
Dmitry E. Oboukhov

Hi Dmitry, hope you are having a nice day!

16 Aug 10, Dmitry E. Oboukhov wrote to Alexey V Bugrov:

DEO> у меня вопрос был о программировании/отладке. DEO> openocd дает возможность из скриптов поиграться с периферией DEO> процессора. то есть например можно через JTAG дергать линии ввода DEO> вывода на порту, настраивать таймеры итп. получается очень удобно DEO> всякие тесты (те что к реальному времени не относятся) писать: DEO> скриптовый язык, можно _быстро_ что-то попробовать/проверить. DEO> ну и отладчик можно подключить и прямо по командам походить, точки DEO> останова навесить итп

Если доступ к потрохам через JTAG документирован, я бы для этих целей написал свою библиотеку. Скриптовые языки на самом деле не так уж и много преимуществ имеют перед скомпилированным кодом. Если тулчейн уже поднят и настроен, то собрать тестовую тулзу на С ничуть не сложнее.

Отладчик таки да, используется штатный. Но обычно (на других платформах) с ним как раз все бывает хорошо.

К сожалению работа через JTAG документирована далеко не везде. :(

WBR, AVB

Reply to
Alexey V Bugrov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.