Прошу совета у гуру. Делаю некое устройство, превращающее машину в что-то вроде умного дома на колесах. Устройство делается на основе LPC2378. Большую часть получаемых данных оно обрабатывает само и реагирует тоже само. Почти все данные можно получить с этого устройства на компьютер через USB либо ethernet ну и управляться оно тоже может через эти интерфейсы. Плюс оно имеет свой экран LCD 128x64 и 4 кнопки (esc, enter, <, >). Практически весь код (основа - nichelite) взаимодействия с датчиками машины, gps и компьютером написан, осталось сделать отрисовку данных на экране, меню и т.п. - т.е. интерфейс.

Чтобы не шить постоянно контроллер и проверять как смотрится тот или иной экран с данными решил сделать схему в протеусе и замоделировать интерфейс на нем. Взял в протеусе lpc2138, подключил к нему wg12864, 4 кнопки, кварц, виртуальный uart терминал. Скопировал проект в другой каталог и слегка его подрезал - убрал запуск задач сети, инициализацию usb, подправил загрузчик, отключил инициализацию отсутствующей переферии. Ставлю в keil девайс lpc2138, компилирую с созданием .hex. В настройках контроллера в протеусе указываю файл прошивки. Запускаю симуляцию и фик... Ничего... Тишина. Даже трейсы не показывают что PLL сконфигурен. В логе симуляции пишет что XTAL1 и XTAL2 not modelled - я так понимаю это означает что в симуляторе они не учитываются ? Убрал нафик оптимизацию - не помогло.

Ладно, чтобы посмотреть что за фигня ставлю дрова Proteus VSM AGDI и запускаю симуляцию через keil как отладку. Прохожу потихоньку инициализацию - все нормально. В трейсах пишет что мол PLL enabled FOSC=10Mhz, CCLK=60Mhz, FCCO=240Mhz а потом PLL connected OK. На этапе инициализации воткнул отрисовки логотипа на LCD - все нарисовалось. А дальше начинаются глюки - на ровном месте валится в DAbort (например в ns_printf валится в разных местах). Бывает и инициализацию не проходит. Все что можно уже проверил. Не могу понять в чем дело. Плюс совсем непонятные глюки с UART1 - на 2378 у меня делители расчитывались при инициализации для нужных скоростей, а потом брались уже из таблицы. Тут смотрю виртуальный терминал хрень выдает. Ставлю трейс на UART1 - смотрю в логах скорости совсем бредовые. Считаю делители пихаю их в DLL, DLM - на выходе бред. Ставлю DLL=1 DLM=0, смотрю скорость которую трейс пишет, считаю частоту - получаю как и положено 15Мгц (VPBDIV = 0). Путем экспериментов выяснил, что на любое значение DLM модель реагирует неадекватно и непредсказуемо Короче потратил фигову кучу времени и получил 0 результата.

Кто-нибуть работал в протеусе с этой моделькой ? Это я что-то не так делаю или она такая глючная ?

З.Ы. Протеус у меня 7.5SP3....

Сообщение отредактировал Regressor - Nov 16 2009, 14:23

Поубивал бы за всякие протеусы.
Вам шашечки или ехать? Вы что будете заказчику отдавать, работающий дивайс или картинки на экране о том, как он теоретически может работать?
Работайте с конкретным железом и разберитесь что такое отладка.
PS Возможно после всего этого Вы сможете смело именоваться Progressor

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

Теперь вот думаю, что в протеусе просто закончить отрисовку данных (это вроде получается сделать), а собственно интерфейс тестить уже на железке.

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

Чтобы не перепрошивать во flash, проблемные куски можно отладить загружая программу в ОЗУ.

У меня MT-Link... Внешнего ram у контроллера нету. Где можно почитать как отлаживать куски в памяти ?

Вчера чисто ради интереса поменял в симуляторе проц на lpc2124 (как в VSM chess протеусовском) и все заработало нормально млин.... Бывает же такое.

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


1. Совсем не факт, что заработает на реальном железе.
2. Если есть живой контроллер и MT-Link, то что же ещё Вам надо? Зачем тратить время на глючные модели?

Кстати, по поводу перепрошивки. Я при разработке своих проектов очень редко пользуюсь отладкой в ОЗУ, всегда шью прямо во flash даже пользуясь одной отладочной платой для многих проектов. Ещё ни разу не исчерпал ресурса.

Почему это не заработает на реальном железе ? Уже работает. Речь о том чтобы красоты на графическом экранчике навести (чтобы видно было, чтобы лишних пикселей не было, чтобы просто, понятно и исчерпывающе) и удобство менюшек урегулировать. Все низкоуровневые вещи вроде LCDUpdate уже сделаны. Я просто перенес код работы с лсд и кнопками на протеус и он там работает.

При прошивке во флеш я нажимаю кнопку прошивки и жду пока шьется и проверяется. А это секунд 20. Потом смотрю, тыкаю кнопки, нахожу косяки, и правлю их. И опять. И по новой. Куча времени уходит. Пока это низкоуровневый код получения данных и дерганья ногами и обработки прерываний его удобнее на плате проверять. А интерфейс... Я вот сел вчера на диван с ноутом, сделаю кусок - скомпиляю, ctrl-f5 - и практически мнгновенно вижу результат. Код этот от железа не зависит, исхитрений особых нет.

Ресурс флеша вроде как 10000 циклов перезаписи. При том, что я пока писал софт перешился раз 200 не больше так что за ресурс то особо не переживаю.

+ Synopsys, Mentor, MODELSIM. Паяло и шнурок завсегда рулит