Собственно проблема такая - примеры для AT91SAM7A3 компилятся, линкуются и тп. но!, при попытке прогнать их во встроенном симуляторе Cstartup.s с первой точки (reset) улетает куда-то на адрес 6E7C0000, при попытке переписать стартап чтобы он с ресета уходил на lowlevel_init в симуляторе все ОК, однако в железе - мертвяк. все во Flash_DEBUG

Немного непонятно
А файл прошивки должен формироваться в режиме Реалис. Вы так его формировали?
И ещё, где-то было сообщение нащёт версии 5.11 толи В толи А что она вообще не рабочая.

Теперь мне не понятно...Что значит в режиме Реалис? Дело в том, что моя собственная программа, отлично собиравшаяся в 4.3Х-KS напрочь отказывается компилироваться в 5.11-EV. При попытке переписать startup вроде как адресация после рестарта нормальная - я попадаю в lowlevel init, затем в main - но это все только в симуляторе, а в железе ...
ЛЮДИ, ежели не в падлу, скиньте ссылку на EWARM 4.XX EVALUATION, все-же хочется работать, а не бороться со средствами разработки...

- А это правда, что Сидоров выиграл машину в лотерею?
- Правда. Только не машину, а тысячу рублей. И не в лотерею, а в преферанс, и не выиграл, а проиграл...



Боритесь только сами с собой. Разработчики коммпилятров ошибаются несораизмеримо реже, нежели их пользователи . тем более на переходе в main(). A EWARM 4.xx, Вы конечно взять можете на сайте iar.com, но незачем.

Да я не против бороться, я даже за . Но чтобы бороться надо знатьхоть с чем конкретно. Кто нибудь знает где почитать как startup-ы пишуться в 5.11 с примерами/картинками . На сайте IAR я посмотрю, но по-моему там уже везде ссылки на 5.10-5.11.

C картинками - это Вам тогда в детский сад надо пойти. А так - базовый вариант startup в комплекте поставки + документация на контроллер/ASM.

Да староват вроде как для сада уже... Зря вы так, наглядный пример лучше трех талмудов.

Повторяю:

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

Обратился к первоисточнику:


если я правильно понимаю, то вот сдесь

происходит добавление к текущему адресу числа 24, (смещение на 6 dword) то есть если выполнится первая такая команда, то мы окажемся там, где стрелочка в коде. Так?
Понимаю, что звучит по-дурацки, но...

В счетчик команд заносится соответствующий хандлер, т.е. осуществляется переход на соответствующую метку .

Это понятно, что обработчик заносится..., но меня интересует вопрос правильно ли я понимаю КАКОЙ обработчик туда заносится. Адресация-то относительная.

Нет. "Для разобраться" надо просто слегка посмотреть на архитектуру процессора и на то, что значат в ASM скобочки [].
Хотя написано, конечно от балды. Я так не пишу, дабы не заморачивать голову ненужными магическими числами.
Так читабельнее:

За пример - большое спасибо, так и вправду понятнее. Однако, касаемо моей изначальной проблеммы - а именно не_запускания программы в железе - наткнулся на то, что если workspace поставить flash_flash (а не flash_debug), то все несколько меняется. При компиляции во flash_debug при переходе с "0" адреса происходит улет в 0x6E7C (а там вакуум...и не работает не в железе ни в симуляторе), в RAM_debug 0x7B50, а в flash_flash туда же в 0x6E7C, при этом все работает в симуляторе, но в железе глухо как в танке... При этом код не меняелся никак.
Доктор, где у меня ошибка..?

Столкнулся с такой проблемой.

Не могу в этом IAR експортировать функции (в данном случае __start_firmware()) из startup.s
Прописал:


Тело функции:



пытался вызвать:


При компиляции выдается ошибка, что __start_firmware неопределена. В мануале написано, что для экспорта достаточно прописать PUBLIC __start_firmware. Может чего упустил?

Самое простое - может забыли подключить startup.s к проекту?

Более сложное - если ваш файл компилится в режиме С++, то надо писать extern "C" void __start_firmware(); Если файл может компилиться как в С так и в С++ варианте, то

Спасибо!!! Второй вариант заработал.

Потихоньку разбираюсь с C++. Не пойму один момент.
Как известно, в ARM надо прописать адрес обработчика прерывания в VIC;
Некоторый класс:

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


Ошибка таже:
Error[Pa073]: invalid type conversion (from "__code __interwork void ()" to "DWORD*")

Это вообще возможно или я в трех соснах блуждаю?

Странная ошибка. он должен был ругаться на конвертацию адреса функции-члена в указатель, а он ругается на нее как на обычную функцию. Дело в том, что при вызове функции-члена первым параметром неявно передается указатель на объект. Прерывание не может передать этот указатель. Поэтому, или обработчик должен быть статической функцией-членом (которой не нужен this) или надо написать обычную функцию как обертку:при этом функцию-член-обработчик лучше сделать встраиваимой.

Чтобы было легче понять: Вы объявили 5 экземпляров этого класса (TIMER1, TIMER2, ... TIMER5). Попав в ваш _TIMER::Isr(), откуда он будет знать, какой конкретно из этих 5 таймеров надо обрабатывать? И при инициализации ваш _TIMER:Init() настраивает только первый таймер, а как настраивать остальные? Если вы пишете этот класс под один конкретный таймер, то можно все функции-члены и данные-члены сделать статическими, но тогда появится неудобство - придется явно заводить каждый статический член-данное.

Ой... Вы же передаете TIMER1 в OpenIsr. Видимо где-то дальше оно у вас используется для вызова обработчика. Тогда про статическое не читайте, почитайте это: указатель на функцию-член. И покажите объявление (а лучше и текст) OpenIsr()

Хорошая ссылка. Привожу код для OpenIsr():

Немного конкретизирую идею
Думал сделать отдельный класс TARGET, в котором будут находиться функции , а потом все классы сделать наследниками его. Класс, который написал - это просто пример. Наверное удобнее номер таймера передавать в конструкторе, а потом от этого прописывать прерывания в OpenIsr:

Собственно на пути всего этого стоит то, что не могу передать функции OpenIsr адрес обработчика превывания (метод этого же класса), который она должна записать в регистр микроконтроллера (LPC2468). По ссылке, указанной вами, попытался создать в классе такой указатель: void (_TIMER::*pFunction) ();
Потом в конструкторе попытался сделать так:

На третью строчку в фигурных скобках таже ошибка, не может сконвертировать тип.

Обертку C функции делать не очень хочется, каждый раз при создании класса ее придется тоже создавать.

Ах вот оно как! Я чего-то подумал, что TIMER1 это у вас объект класса _TIMER, а это вы так VIC_TIMER1 переобозвали... Маленькое замечание - не рекомендуется использовать подчеркивание в качестве первого символа в именах, такие имена зарезервированы за компилятором, можете напороться на интересные ошибки. И имена из одних заглавных обычно используются для мароопределений (#define).
Функция, вызываемая по этому указателю, требует this в качестве неявного параметра. По этому указателю определяется, с каким именно из объектов данного класса идет работа. Как ваш обработчик передаст в функцию этот this? Если бы компилятор разрешил вам это преобразование, то у вас для нескольких прерваний VICVectAddr указывал бы на одну и ту же функцию. И как бы эта функция разгребала, какой из таймеров надо обрабатывать? VIC на каждый источник прерывания хочет вызвать отдельную функцию. И никак вы это не обойдете. Или вам придется сделать на N таймеров N функций-"оберток", или в классе объявить N статических обработчиков, которые отличаются от "оберток" только областью видимости.
Посмотрите дизассемблированный текст обращения к любой функции-члену. В R1 находится указатель на объект Если бы компилятор разрешил вам это преобразование, то, поскольку в момент прерывания у вас R1 может иметь произвольное значение, эта функция-член начала бы править данные не в конкретном объекте, а в произвольном месте памяти.

Нет, есть конечно финт ушами - сделать все классы, имеющие обработчики прерывания, полиморфными наследниками абстрактного базового класса, в VICVectAddr заносить указатели на объекты этих классов, а единый обработчик на векторе IRQ считывает VICVectAddr, преобразовывает его к типу "указатель на этот абстракный базовый класс" и вызывает по нему метод обработчика. Но это будет громоздкое (по сохранению регистров на стеке) и совершенно непереносимое на другие архитектуры решение.

Что-то вроде вот такого:Хм, а интересная мысль. Надо взять ее на заметку для небольших неторопливых безОСевых приложений типа загрузчиков.

Сложно. Получается, что с оберткой по-проще. Уже делал что-то подобное (прикрепил один из вариантов оберток).

Еще пока не использовал наследование, пользовался подобными конструкциями:

Хотя, если использовать наследование, то можно это все превратить в одну функцию. Занялся формированием концепции программирования.

Вы сказали для неторопливых, оценивали ли вы размер кода, когда несколько объектов наследуют один и тот же базовый класс? Непонятен момент, как компилируются функции этого базового класса. Для каждого наследника они дублируются или компилятор это как-то оптимизирует?

Объект состоит только из данных. Когда вы обращаетесть к функции-члену, то компилятор по имени объекта определяет, какую именно из функций надо вызвать. Поэтому каждая (невстраиваимая) функция-член встречается в коде ровно один раз. Если это унаследованная функция для данного класса, то будет вызвана функция базового класса. Поэтому накладных расходов по коду при наследовании нет никаких. пример:Единственные накладные расходы, которые могут возникнуть - по памяти данных на архитектурах с выравниванием. Размер struct a_t будет округлен в бОльую сторону до параметра выравнивания (чтобы если из них сделать массив, следующий элемент оказался выровненным), и это округление может оставить пустое место между data_a и data_b в b.

Отлично. Получается можно использовать преимущества ОПП и при этом размер кода практически не увеличивается.
Задам последний вопрос на отвлеченную тему:
Если делать класс например для всех COM портов на контроллере LPC2468. При создании в конструкторе прописывать номер порта. При этом есть проблема, у каждого порта свои регистры. Думал как вариант: создать поля указателей на эти регистры. В конструкторе поставить switch и присваивать здесь этим указателям адреса соответствующих регистров, а в остальных функциях обращаться непосредственно к указателям. Достоинсва: быстродействие, недостатки: лишняя память на поля указателей.

Вариант два: сделать в классе поле номера порта, так же инициализировать его в конструкторе. Потом в каждой функции ставить siwtch() и выбирать соответствующие регистры. Достоинсва: меньше памяти расходуется на поля, недостатки: меньше быстродействие.

Можно ли обойтись (а нужно ли?) без операторов switch() при обращении к регистрам ввода/вывода, которые для каждого COM порта могут находиться в любом месте области памяти?

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

Точно! Как я сразу не догадался. Спасибо за ответы