Имеется опыт работы с 8 битными контроллерами ATmega.
Хочется освоить что-либо помощнее.
Надо иметь на борту АЦП, I2C, SPI и желательно ЦАП и USB.
Корпус не более QFP64 по кол-ву ног.
Пока выбор пал на LPC2142-48.

Что мне надо иметь, чтобы писать программы и шить в такой контроллер?
Какой софт/железо?
Вроде есть недорогие отладочные платы с такими контроллерами на сайте MT-System.
Не знаю только, высылают они товар по почте или нет.

Между const и volatile? В том что const запрещает запись в пременную (и при попытке такой записи компилятор выдаст ошибку) а volatile не запрещает.
Во-первых флеш (и ОЗУ) бывает медленной, и одна инструкция с доступом в память может занимать далеко не один такт процессора.
Во-вторых не забывайте, что ширина инструкции 32 бита, ширина адреса тоже 32 бита, поэтому одной командой можно обратиться лишь к ячейке, находящейся сравнительно недалеко от адреса, из которого берется инструкция (куда указывает PC). Для доступа к остальным ячейкам используется косвенная адресация, их адрес надо сначала загрузить в регистр из ячейки, в которую можно "дотянуться" в регистр, а уже потом косвенно по содержимому регистра считать значение. В режиме THUMB ширина инструкции 16 бит, развивать мысль?

"Ппереведи!" Наоборот, он будет вполне резонно полагать что *adr не изменится и использовать вместо него x.
Вот смотри пример:
В данном случае компилятор имеет право в точке (1) не считывать в y содержимое памяти *adr а использовать для инициализации y значение х. Даже более того, он может вообще не создавать addr, а сразу использовать значение 7. И вообще весь этот код превратить в z = 14. А вот в случаемы его заставляем в точках (1) и (2) сгенерировать чтения ячейки z. Ведь если z это, например, таймер, то между точками (1) и (2) его значение могло измениться.
Еще не все потеряно - стиль можно изменить.

Что ж, разберем его "по косточкам":
0xFFFFF000 - константа.
(unsigned long *)0xFFFFF000 - указатель на unsigned long, содержащий (указатель содержит, а не unsigned long) адрес 0xFFFFF000
(volatile unsigned long *) 0xFFFFF000 - указатель на unsigned long, содержащий адрес 0xFFFFF000, при этом содержимое ячейки, куда он указывает, может изменитья в любой момент. Поэтому каждый раз, когда в программе встречается обращение по этому указателю, надо считывать эту ячейку (пример см. выше).
((volatile unsigned long *) 0xFFFFF000) - то же самое.
*((volatile unsigned long *) 0xFFFFF000) - содержимое ячейки, на которую указывает вышеописанный указатель.
(*((volatile unsigned long *) 0xFFFFF000)) - то же самое.

Нет. это не константа имеет значение 0xFFFFF000, а область памяти имеет фиксированное расположение по адресу 0xFFFFF000. И содержимое области памяти константой не является. Причем заметьте, с точки зрения языка С квалификатор const вместе с volatile не говорит о том, что переменная не может измениться, а говорит лишь о том, что в эту переменную запрещена запись. И в вашем определении VICIRQStatus присутствует ошибка - в VICIRQStatus запись запрещена, определение должно выглядеть так:
И еще раз обращу внимание, что тут описан не константный указатель, а указатель на константу (на ячейку в которую запрещена запись).

Ну не придирайтесь к словам. Пусть будет "Компилятор может со 100% вероятностью рассчитать какое значение будет иметь переменная в этой точке не считывая ее в этом месте".

У меня сложилось впечатление что разложена она не по тем полочкам. Постарался изложить макимально подробно. Если "звезда справа" все еще смущает - читайте все доступные материалы про указатели.

[/quote]"выскакивает ошибка" - неинформативно. Какая ошибка? Почему у меня (на том же компилере, пример Blinky для AT91SAM7S) не выскакивает?[quote]
Во первых я выше достаточно информативно описал ситуацию. Пример blinky, это пример из uVision, а я обсуждал примеры из книги. Blinky тоже попробовал, та же ошибка. Специально для вас повторю:
[quote]Build target 'LPC2106'
assembling Startup.s...
Assembler messages:
Error: Error: can't open Files\Keil\ARM\INC\Philips\ for reading
Files\Keil\ARM\INC\Philips\: No error
compiling Blinky.c...
arm-uclibc-gcc: cannot specify -o with -c or -S and multiple compilations
Target not created[/quote]
Я не сомневаюсь, что подшаманив, всё будет в порядке. Дальнейшее обсуждение данного вопроса считаю БЕСМЫСЛЕННЫМ, ибо я изучаю RealViwe, а все сторонние коды беру в виде алгоритмических идей. Имхо, хоть и медленный, но лучший способ для осваения.
По поводу:
[quote]Например, использование putchar(), а #include<stdio.h> и в помине нет.[/quote]
Я знаю, что может быть и своя putchar. Как мне не знать, если я как раз своим и пользуюсь. Пересмотрел все проекты примеров, и действительно не нашёл подобного случая, показалось наверное. Извиняюсь за дезинформацию.
Возник вопрос. Есть такой регистр LSR. В нём 5 бит сигнализирует FIF0 пуст, 6 SHIFT регистр пуст. Хочется реализовать следующую конструкцию. Есть функция puts(выводит байты в UART). Кидаешь, например функции 10 байт, она сразу заполняет буфер FIFO и возвращается в программу, пока байты отправляются, мы делаем полезную работу. Далее мы опять вызываем функцию puts. Как ей определить заполненность FIFO? Ведь нет бита FIFO полн, или придётся впустую ждать пока он опустеет, чтоб конкретно знать 16 байт можно загнать. Кто нибудь реализовывал подобную конструкцию?

А что там в даташите написано про этот регистр?
Наверняка, можно определить конец передачи или по прерыванию, или (если нет соотв. бита) 5 бит LSR будет сигнализировать, что буфер пуст
Тебе бы надо User Manual скачать на твой чип, там должно быть подробно описано.

Сообщение отредактировал sonycman - Jan 28 2007, 15:59

2Сергей Борщ
Спасибо за продуктивную дискуссию . Стала понятна звезда справа, это инициализация указателя. В некоторых местах вы меня неправильно поняли, но не буду заострять на этом внимание. Главное совместными усилиями найти истину.

2sonycman
Так я этот регистр из Datasheеt и брал. (LPC210X). Я же писал, что как раз, конец передачи определить можно. Цель использовать FIFO передатчика на все 100%. Ну, смотри, к примеру, есть такой код:
x=1;
x++;
puts("Hello word"); Инструкция возвратится сразу после заполнения буфера, дальше буфер сам аппаратно опустошается.
x++;
x+=y;
puts("Hello word"); Вот здесь и запара. Если puts, будет знать размер заполненного буфера, то она дополнит его, и сразу возвратится. И мы не потеряем ни одного такта впустую.(а при скорости 9600 это огромное время!) Хотя бы бит заполнения был, тогда она работала бы так, скинул байт, проверил бит, всё OK? Скинула следующий байт, не OK, ждём OK.

А разрядность Shift регистра какая?

В принципе, ты и так не потеряешь время зря.
Задействуй прерывания.
Как только передача из FIFO закончится - произойдёт прерывание.
Там ты снова заполнишь буффер следующими данными.
А основная программа в это время пусть занимается своими делами.

Да, это им удалось. Хотя zltigo утверждает что UART просто чудесный. Я обошелся так - завел счетчик и считаю в нем сколько бит послал в FIFO. Если перед отправкой очередного байта обнаружил флаг FIFO пуст - счетчик обнуляю. Если насчитал в счетчике 16 байт - жду флага. Тоже не самый красивый вариант, но лучше ничего пока не придумал.

Тоже интересно было бы посмотреть другие варианты.

2Сергей Борщ
Сергей, просвятите меня, пожалуйста, насчёт понятия HEAP.

В файле Startup.s почти любого проекта под uVision RV имеются такие строки:

IMPORT __use_two_region_memory
EXPORT __user_initial_stackheap
__user_initial_stackheap

LDR R0, = Heap_Mem
LDR R1, =(Stack_Mem + USR_Stack_Size)
LDR R2, = (Heap_Mem + Heap_Size)
LDR R3, = Stack_Mem
BX LR

Я это понимаю так: объявляется модель памяти как две области. Какие именно это области мне не понятно
Дальше идёт инициализация (заполнение нулями) стёка и данных пользователя.
Затем инициализация регистров значениями адресов и размеров стёка и этой самой кучи (HEAP). Причём это делается вручную, а ведь есть системная функция для этого. Почему?

Так вот, куча в этом стартовом коде всегда имеет размер 0 байт.
А я где-то прочитал, что в этом случае невозможно использовать функции выделения памяти библиотеки С - malloc и подобные.

Тогда получается, что куча - это область свободной памяти, из которой происходит выделение кусков при использовании функций запроса памяти?

Да, в С понятие "куча" - это область для динамического выделения памяти. Скорее всего ее размер задается где-то в настройках проекта.
Не работал с RV, поэтому подробнее не скажу.

Куча явно задаётся в Configuration wizard (Startup.s).

Да, да - или в визарде, или ручками в тексте:

Heap_Size EQU 0x00000000
AREA HEAP, NOINIT, READWRITE, ALIGN=3
Heap_Mem SPACE Heap_Size

Значит, если я захочу пользоваться malloc() и другими подобными функциями - я должен буду задать размер HEAP, отличный от нуля.

Сообщение отредактировал sonycman - Jan 28 2007, 19:04

Я никогда не утверждал, что 550 - "чудесный". Он индустриальный стандарт разработанный МНОГО лет назад и ВПОЛНЕ сбалансированый. На таких оптимальных решениях учиться надо.
Чудесным вообще ни один UART не называл а максимально лучшим называл имеющийся у AMD186.
Что-то у Сергея с памятью
Оптимальное использование Tx FIFO 550 совместимых чипов - после прерывания по опустошению FIFO
забить его 16 байтами (или сколько есть).
Относительные "проблемы" возникают при попытке "чуть-чуть" улучшить с помощью Tx FIFO небуферизированный вывод. Причем именно чуть-чуть улучшить, ибо все рассуждения по улучшению небуферизированного вывода сводятся к тому, что если захочется напечатать "ля!", то эти три символа быстренько влезут в FIFO и время сэкономим. А если печатаем "Привет морякам Балтики от грода-Героя Севастополя!" - упретесь и тупо будете ждать теряя офигенное время?
Либо задача позволяет терять время - тогда просто по байтику пихайте и заморачивайтесь. A если нет, то буфер должен быть по любому и "проблемы" в общем-то и нет.








Да. А правильный путь для контролллеров - вместо штатного тупого менеджера памяти использовать свой (или переписать штатный), который под Heap будет использовать всю оставшуюся память контроллера.

Блин, вот пока вижу только два недостатка у AT91SAM7S серии:
1. нет собственного PLL для USB, поэтому, при использовании последнего, придётся ограничить частоту CPU на 48 Мгц.
2. Нет DMA для USB. Для всей остальной периферии есть, а вот для USB почему-то нет.

Сообщение отредактировал sonycman - Jan 28 2007, 22:35

Странно, когда читал, форумы, то основная претензия к LPC была наличие UDP только у USB, а у AT91SAM7 UDP была у каждой периферии. Вот вырезка из datasheet:
Доступ к UDP организован через шинный интерфейс APB. Доступ (чтение или запись) к буферу данных FIF

Если поищете по форуму,
http://electronix.ru/forum/index.php?showt...6057&hl=DMA
найдете (тема еще несколько раз всплывала), что я думаю о пользе пользе DMA у контроллеров без кэша и/или
с одним банком памяти . Короче не расстраиваетесь, это не пентиум - ничего особо Вы не потеряли.