Дали небольшую задачку, но камень должон быть AD ADuC 7026 (там вроде как хорошие ЦАПы). А я с этим ядром вообще не знаком... А тут еще операционные системы под них...
Подскажите, плз, где взять инфу про работу с кейлом для АРМ и про ОС для них.
Спасибо за внимание

Если задачка небольшая, то с ОС можно не заморачиваться.

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


У Keil'а и взять. Учитывая тот факт, что Keil был недавно куплен ARM, стоит посмотреть и arm.com

В принципе если писать на С ядром можно и не заморачиваться. Посмотреть один раз в даташите на раскладку регистров и все.
Помнить, что регистры 32-х разрядные, а прерывания приоритетные.
В общем и целом проц стоит ближе к десктопным, чем к 51-м или АВР.
По части оси - посмотрите FreeRTOS.org там масса примеров.

По-моему, этого недостаточно.
А что касается прерываний, то таки да, два приоритета: FIQ и IRQ (остальные исключения ради простоты можно сейчас не рассматривать). Другие аспекты работы прерываний - дело контроллера прерываний, а не ядра.

Один раз посмотреть на регистровые банки достаточно. Неплохо помнить о переключении ARM/THUMB (хотя для начала можно писать под любой из режимов). Помнить о продвинутом контроллере прервываний (VIC/AIC etc.). Подход к периферии непривычен с точки зрения человека привыкшего к 8-биткам.
Лично я, когда начинал, больше намучился с периферией, чем с ядром. Долго воевал с векторными прерываниями и снятием флажков. С конфигурированием. А сама идея отдельного банка для прерываний проста как шоколад.

Ну, обычно об этом должен помнить компилятор.
Точнее об его полном отсутствии в ADuC и необходимости вручную накладывать маску на флаги при опознавании источника прерываний.
Да нет там ничего особо непривычного. Компилятор сам помнит какой регистр периферии 8 бит а какой 32 или 16, и сам подставляет нужную команду (не ошибаясь).

Про ОС - вышел релиз scmRTOS 3.0beta, там есть порт под ADuC, но, к сожалению, пока только для IAR.

Обычно об этом должен помнить линкер. И автор программы, когда дело доходит до прерываний.


Сколько производителей, столько и мнений


Компилятор знать ничего не знает ни о перифирии, ни о размерности ее регистров. А ошибки, связанные с неправильным описанием регистров, не так уж редки.

Линкер-то да, но компилятор должен предоставить возможность выбрать либо универсальный переход (BX) если смена режима, либо более короткий и быстрый BL если смены нет. А на попытку описать функцию как обработчик прерывания в thumb ругатья должен таки компилятор. Как следствие ошибка отлавливается в процессе компиляции а не после запуска.

Это точно. Но: 1) В исходном посте ечь шла про ADuC и 2) Ну что им сложно было сделать аппаратное наложение маски?????

Почему? Конечно с его точки зрения это обычные sfr, но они уже описаны, причем в описании указан размер. Ошибка в описании если и есть то после первого же вылавливания исправляется и не возникает совершенно случайно в одном из n обращений к этому sfr. В отличие от писания на ассемблере где размер sfr надо помнить программисту, а творческий простор для неправильных обращений к sfr практически не ограничен :-)

Для Bird2: Им еще в ADuC удалось сделать совершенно чудовищные sfr портов ввода-вывода, поэтому во избежание дурацких недоразумений очень удобно "дерганье ног" делать сразу через макросы (спасибо Аскольду Волкову за идею). Внутри файла комментарии как использовать. Сам пользуюсь уже 6 лет.

Компилятор ничего предоставлять не должен. При вызове Thumb-функции из режима ARM линкер подставляет вызов своего veneer-кода, который и осуществляет корректное переключение режима.


Не будет - ничто не мешает писать обработчик в режиме Thumb, просто нужно помнить, что переход на вектор осуществяется в режиме ARM.


Эх, PIC'и вспоминаются


Это если описаны. А если пишешь сам (что приходится делать практически всегда), то случаются ошибки. А на асме, конечно, неудобнее, спору нет.

Ну хорошо, может сойдемся на связке компилятор-линкер? У кого из них больше работы - детали реализации. В любом случае не программист.
В любом случае код, "принимающий" управление на векторе исключения должен быть arm. Дальше конечно - что пожелаете. Тут плавно переходим к первому абзацу :-)
Вот-вот :-(

Ну вообще-то при создании проекта, об этом должен сказать программист.

То есть, если я правильно понял, на С по барабану, что ядро в общем-то принципиально сильно отличается от 8-ми битного, с переключением Thumb/ARM функциями кейл сам справиться

Основное отличие со стороны C - размерность типа int, он будет 32-х битным. С переключением ARM/Thumb сейчас заморачиваться не стоит, сначала освойте режим ARM. Хотя для ADuC Thumb эффективнее.

Если я правильно понимаю, программист при создании проекта говорит в каком режиме компилировать функции по умолчанию. При этом остается возможность жестко указать - эту функцию в thumb, а эту - в Arm. Компилятор (а не программист) должен думать и помнить о том, что при вызове функции foo2 из foo1 надо переключать режим, а при вызове foo3 из foo1 - не надо.

Понятно, будет бороться. Крайний вопрос:
скачал кейл 8.02, но там весь хелп для С51, хотя в списке девайсов ADuC присутствует. Таблетка почему-то не срабатывает, при попытке просмотреть опции проекта кейл ругается и виснет. Это у меня версия такая (для С51), или просто кейл корявый (или таблетка).
Ну и соответственно, есть ли у кого на примете некорявый (попытки поиска пока ни к чему не привели)

Боюсь, вы скачали не тот Keil. Для ARM нужен uVision3.34, вроде крак на него нормально действует.

Это для 51-х, а Вам надо для АРМ.
Для АРМ текущая версия называется RVMDK 3.03a. Ищите на сайте производителя. Демо-версию дают качать после короткой регистрации.

2 Dopler не надо привязываться к версии uVision, это IDE, а не компилятор. Если человек поставит несколько кейлов для разных процессоров в одну папку (как и надо делать), uVision будет для всех одна, самой большой версии.

Ну, если быть точным, то могут сосуществовать 2я и 3я версии...