Приветствую Вас.

Начал изучать ARMы для применения в системах управления электроприводами. В этой связи есть несколько вопросов?
1. С микроконтроллерами каких фирм работаете?
2. Какие технические средства используете (отладочные платы, программаторы, стартовые наборы и т.д.) и что можете сказать о них?
3. Какие инструментальные средства разработки используете (ассемблеры, Си-компиляторы, отладчики и т.д.) и что можете сказать о них?
4. Где можно достать русскую документацию по МК на ядре ARM (имеется ввиду подробная документация с описанием системы команд и архитектуры, а не обзорные статьи)?

Что касается выбора элементной базы, то ИМХО филипсы очень подходят, т.к. имеют малую цену и flash-ПЗУ (чего например пока не имеет Atmel)...

Ну вообще для электроприводов лучше DSP - специально заточены под это...
Мы работаем с

1. Philips LPC21xx

2. Виглер
http://www.caxapa.ru/tools/

3.http://www.gaw.ru/html.cgi/txt/publ/_ineltek/at91rm9200.htm
IAR,Crosswork,MULTI,ADS
Я пользуюсь IARом - все устраивает...

4. http://kpv.nnov.ru/index.php?l=philips
http://www.gaw.ru/html.cgi/components/micros/arm/index.htm


Про флешку... думаю на вашу жизнь циклов перезаписи хватит..

К филипсам LPC21xx притензий нет? (а то уж слишком дешево они стоят...).

Насчет Виглера - он подходит не только к LPC21xx? А то в будущем хотелось бы поработать с Atmel (когда они наконец флеш-память в кристалл встроят)...

Насчет DSP - я знаю, что приводчики (например кафедра АЭП МЭИ) работают на них, однако они по многим характеристикам проигрывают микроконтроллерам универсального применения. А поскольку я в настоящее время не знаю ни DSP ни ARM, ИМХО лучше изучать ARM, т.к. это позволит в будущем решать более широкий круг задач. Тем более, что ARMы начинают включать в себя и математику DSP и математический сопроцессор и в перспективе вообще не будут проигрывать в вычислительной мощности этим самым DSP.

Насчет флэшки - пока не ясно...
Однажды я был свидетелем того, как ADuC812 переставали прошиваться через довольно небольшое число циклов перезаписи (~200), а это между прочим очень напрягает. Не хочется во время выполнения проекта бегать с бубном вокруг отладочной платы или, что еще хуже, перепаивать микросхему в корпусе TQFP (а ведь запасной микросхемы может и не оказаться под рукой...)

Еще один момент интересен...

При отладке через JTAG-интерфейс программа прошивается в ПЗУ кристалла или держится гдень-ть в оперативной памяти???

К филипкам пока претензий нет... Вроде все работает, исключая двух вылетевших портов. Но это от статики, наверное...Все остальное работает.
Виглер подходит ко многим...в том числе к атмелу..
Насчет DSP.. ну не знаю.. в чем они проигрывают....
http://dspvillage.ti.com/docs/catalog/gene.../data/c2000_ovw

А например DSP от аналога со встроеным ядром АРМ7

Уже месяца 4 шьем . наверное раз 100 перешили точно.. пока ничего не падало...На инженерных образцах.. знакомые уже почти год работают.. и тоже всё еще шьется.. накройняк новый купите 10 баков не такая уж большая цена.
Перепрошиваться может прекратить любой кнтроллер, независимо от того сколько у него циклов перезаписи... Например если Житаг порт вылетит... или еще чего...

Перепаивать не надо.. для отладки надо брать готовые платки...Evalution board


Для филипков. При отладке, как настроете так и будет. Можно отлаживать из ОЗУ можно из Флеша. Т.е Житаг и во флеш может прошивать. Например зашиватель через Житаг есть в IAR 4.10B.

Evalution Board стоит не 10, а 30 уев. Ну это так, отступление...
Насчет количества перепрошиваний... Я когда диплом делал на ATMega128 я ее раз по 10-20 в день прошивал, а диплом я делал 2 месяца (вот и прикиньте, я прошил ее примерно 600-1200 раз). Разумеется все это я делал не от хорошей жизни, а ввиду отсутствия эмулятора ПЗУ. Вот такие дела...
Через JTAG можно отлаживать через ОЗУ МК, или на плате с JTAG-интерфейсом ОЗУ присутствует?

Ну да пусть и 30

У современных процов обычно циклов перезаписи Флеша не менее 10000.
А так часто зачем перешивать то 10-20 раз на дню?????

Мы вначале все на симуляторе смотрим.....потом прошиваем. Графику тоже на симульяторе отлаживаем. Есть такой симулятор GUI.

Житаг самый дешевый виглер - это просто преобразователь 5 в 3 вольта там 2 буфера стоят и все. Есть подороже покруче.. но и стоят они больше.

Если ОЗУ много, а программа маленькая, то отлаживать можно из ОЗУ проца. Если нет, то отлаживаем из Флеша проца. На телесисе меня вообще прогрузили, что отлаживать надо с помощью принтфа. И никаких вам Житагов. На РС или индикатор все выводим и смотрим... Но я мое мнение - это вата какая-то... однако меня стока народу там прогрузило по этому поводу, что я решил, что большинство так и делает.
Хотя сам ниодного, кто отлаживает с помощью принтфа в живую не видел

Эмулятором ПЗУ сейчас наверное уже никто не пользуется.

Вот www.lamer0k.nm.ru - тут пример проект под IAR.... Когда сам разбирался...Тока он тестовый... Но вроде работал...

У меня была достаточно сложная (по моим меркам) работа - реализация адаптивного управления электроприводом постоянного тока. Отлаживать в отладчике ИМХО можно только простые вещи (например математику и т.д.), т.к. что-то сложное (в плане использования периферии) там сэмулировать достаточно трудно (например опрос клавиатуры или чтение/запись из/в индикатора, показания с датчиков и т.д.). Я использовал не только ЖКИ-индикатор, но и PC-шный дисплей, куда передавал данные по RS-232. Боже упаси использовать для вывода на индикатор printf, нужно написать более компактные и быстрые подпрограммки...

Насчет проекта спасибо, щас скачаю!

Для информации.
Бывают средства разработки, в симуляторах которых имитируются и клава, и экран, есть возможность писать в файл и из файла, имитируется последовательный порт и много другое. Пользуюсь TASKING EDE, там всё это есть, правда нет поддержки АРМа :D

Думаю, не все так просто, т.к. клавиатуры бывают очень разные по схеме подключения, алгоритмам опроса и т.д., тоже относится и к ЖКИ-индикаторам. В отладчиках скорее всего имеется некоторое количество стандартных компонент...

Именно. Но разделив аппаратно-зависимые и независимые части, можно с такими средствами отлаживать основное - алгоритм. А связь с конкретной железкой уже на эмуляторе или на живой плате.

Согласен с one_man_show

Нуно писать все вначале в общем... а отлаживать только конктретную железку..

Вот например чего клаву то олаживать, можно пока виртуальными кнопками обойтись в отладчике.... Например зарезервировать здачу под опрос кнопок и пусть она эмулирует нажатие этих кнопок. Тоже самое с RS.. его вообще можно на компе отработать написать все фунции (например У меня HART протокол).... а потом эти же функции втавить в проц.

Вот ГУИ понравилось отлаживать.. симулятор написан по VC6.0...
Вот там все и отладили...ПОтом код один в один на филипок перекинули и все сразу заработало..
Все остальное только аппаратная реализация под данный контроллер.
Один раз отладил и используй везде...

Кроме того столкнулся например с проблемами, что из=под Житаг отладчика связь с компом нестабильная... Его убираешь-все стабильно.


Но вообщем как кому нравится..

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

Уважаемый hungry
Понятно, что сколько людей, столько и мнений... относительно того, как удобнее разрабатывать, как отлаживать и т.д. lamerok так просто описал достаточно сложный проект с сочетанием следующего: ARM, ОС РВ uC/OS-II, FAT12/16 и GUI. Оценив всю сложность, становится ясно, что при отладке такого проекта "задумываться" над тем, как работает клава или touch screen, просто расточительно по отношению к драгоценному времени, важнее-то основная функция, которую выполняет "железка" целиком.

Поэтому, в зависимости от ситуации, от привычек и многих других заморочек, правы все и да будет всем хорошо! Всё равно, каждый останется при своём, пока не налетит на какие-нибудь грабли и не начнет пересматривать свои подходы. Я, например, налетаю раз в год. Это стимулирует и заставляет почаще общаться и смотреть, что в мире нового.

Думаю, что Вы безусловно правы. Все дело в отсутствии у меня опыта, поэтому так и работаю. Но все таки ИМХО, если есть возможность отлаживать софт на железке (а с современными flash-ПЗУ она появилась), лучше так и делать!

Приветствую, hungry.

>Начал изучать ARMы для применения в системах управления электроприводами.

На отладочные платы какого ценового диапазона ориентируетесь?
Хотелось бы?

>Начал изучать ARMы

без учета применения.
Сколько должна стоить отладочная плата?

С уважением,
Дмитрий.

lamerok,

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

на днях собираюсь нарисовать отладочную плату для lpc ( собираюсь содрать с сахары ), если кому будет надо могу выложить на фтп. Думаю немного модернизировать платку - расположение разъемов и т.д. Если есть пожелания, то выслушаю. Но не обещаю что выполню

Думаю при покупке отладочной платы уложиться в сумму до 50 у.е. (максимум до 100). Если JTAG интерфейс будет стоить больше 50 у.е., тогда обойдусь без него.

P.S. Посмотрел Philips LPC21xx. Все бы хорошо, но везде всего 2 таймера (конечно они там очень навороченные). ИМХО маловато будет (нужно хотя бы 4, пусть 16-разрядные), да и счетного входа они не имеют.
Может кто подскажет модели филипсов с большим количеством таймеров/счетчиков?

Привет, hungry.

Посмотри семейство STR71XF от ST
Мне кажется из этого можно что-то выбрать.

Думаю, этот не подойдет.
Слишком эксклюзивный производитель...
Мне чень-ть по проще нужно (Atmel, AD, Philips и т.п.), поскольку для них и средства разработки будет легче найти да и вообще, им доверия больше.

Не очень сложные кристаллы выпускает Samsung, в частности, S3C44B0X.
И у него аж 6 таймеров.

Эти кристаллы достаточно легко доставаемы и у народа весьма популярны.

На сколько я понял, S3C44B0X не имеет Flash-памяти на кристалле. А мне (как человеку не сильному в электронике) все таки не хотелось бы отходить от базового понятия микроконтроллер (микропроцессорная система в одном кристалле). Я понимаю, когда в кристалл не могут встроить АЦП на 500 MHz, но извините меня, наличие ОЗУ и ПЗУ в микроконтроллере - ИМХО обязательный атрибут.
Думается мне, разработчики S3C44B0X ориентировались на задачи, требующие больших обьемов памяти, а автоматизация технологических процессов (где я и хочу применять ARMы), например, этого не требует - вполне достаточно втроенной на кристалле памяти.

Вам не угодишь ))

А зачем вам так много таймеров???

Там же захваты есть 6 штук аж.. и сравнения есть... тоже 6 штук...
С помощью их можно 6 независимых интервалов считать...

Что-же касаемо АРМа то наилучший способ отладки -- это поставить полнокровное ядро Линукса и через эзернет наладить дистанционную загрузку и отладку по ТЦП/ИП, пользуя при том возможности графической подсистемы Хвиндовс производить вывод не на собственную графическую подсистему, а дистанционно на любой сетевой X-терминал, позволяя отлаживать программу не имея готовой графической подсистемы. И вообще можно написать и отладить программу на ПиСишке, а потом просто перекомпилировать под АРМ...

Для недорогих кристаллов со встоенной Flash (LPCxxxx) uCLinux слишком тяжела, а вот uC-OS - в самый раз. Под неё и GUI есть, и TCP/IP, и разобраться с ней намного легче, ведь hungry сам признался, что опыта у него не много.

Кстати не подскажет кто где взять uLinux под АРМ с прибомбасами???

www.uclinux.org
Не под все АРМы.
Требует - DRAM 8Mb, может быть 4Мб. Сам ставлю 16Mb.
FLASH - в 1Mb уложитесь, но будет плохо. 2Mb или 4Mb.
С уважением,
Дмитрий.

Спасибо... Но это скорее всего на будущее...
Сейчас только 32 кб ОЗУ.. Крутые требования то...

Мне нужно управлять навороченным вентильным двигателем, нужно по два ШИМа на одну фазу, а фаз - от 3 до 6. Вот и ШИМов соответственно нужно от 6 до 12. Дело тут еще и в другом. ШИМы, которые имеются в LPC21xx (6 штук), насколько я понял, могут работать только с одним периодом, а это не есть гуд, т.к. не позволит управлять несколькими параметрами. Кроме того, для ШИМа отдается один из двух таймеров, в результате оставется всего один! Кроме того, таймеры LPC21xx, как я понял, не имеют счетных входов, что тоже плохо. Захватов и регистров сравнения там всего по 4, а не по 6.

Что это я все о грустном... На самом деле кристалл ИМХО хороший, по крайней мере для изучения ARM, а все остальное - приложится...

Кстати, забыл сапросить. Чем программировать ARM (в смысле каким программатором и где его взять)?

Там бутлоадер и программка на писюке на филипсе лежит...по RS232.. через UART0

не надейтесь на уцлинукс или укос, с точки зрения удобства отладки приложений в реальном времени -- это шаг в сторону, если не назад, и еще можно попробовать портировать АНГЕЛ монитор, но это тоже паллиатив, в сложных случаях и он обламывается. Возможно под отладкой мы подразумеваем совершенно разные вещи: я имею в виду такие функции, как возможность приаттачиться к процессу, защиту одного процесса от дугого, перехват исключений по нарушению адресации, а такое возможно лишь в том случае когда работает ядро в защищенном режиме(укос и уцлинукс отдыхают...)

Не знаю как UCOS, а uClinux, Linux как правило выбираются из-за того что большинство приложений, features там просто уже присутсвует.

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

Не понимаю что автор вообще имеет в виду.
С уважением,
Дмитрий.

>>Не понимаю что автор вообще имеет в виду.

По моему автор имел в виду MMU для ARM9. Советую познакомиться поближе с режимами адресации в ARM9. И конечно http://www.arm.linux.org.uk
С уважением
Framer

В курсе, просто в практической работе потребности в отладке таких
вещей как:
>защиту одного процесса от дугого,
>перехват исключений по нарушению адресации,
>а такое возможно лишь в том случае когда работает
>ядро в защищенном режиме
как правило не возникает.
А "приаттачится" к процессу это есть везде где есть отладчик.

С уважением,
Дмитрий.

Видимо здесь идет речь об очень разных применениях АРМа. Лично я собираюсь применять его для задач непосредственного цифрового управления малоинерционным обьектом, т.е. для системы РЕАЛЬНОГО ВРЕМЕНИ. Может быть я безнадежно отстал от жизни, но доверить решение важной задачи операционной системе я бы не решился. Кроме того, я вообще не понимаю, для чего она нужна в таких приложениях.

Вообще для такой задачи и ARM то не совсем то.. что надо...
А оперционка РЕАЛЬНОГО ВРЕМЕНИ.. вам упростит задачу.. Например одна задача управляет одним двигателем, другая другим... третья обрабатывает клаву езе одна связь и т.д.

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