Hi Колеги
// извинявам се за кретенския въпрос, но доста търсих и не мога да намеря...

Чета тука за ARMове да се образовам леко и се стигна до "хело уълрд" програмката. В сайта на АРМ има доколкото разбрах две среди за развой: (старата) ARM Developer Suite и RealView Developer Suite, които съдържат така нужния ми ARMulator (или поне аз си мисля че ми е нужен), който бил един вид симулатор на истински АRM. Въпроса е че не мога да намеря от къде да сваля никое от тях...
Ако някой може да ме просветли каква среда се използва най-често, от къде може да се свали и т.н. ще бъда безкрайно благодарен!

// отново сори за глупавия въпрос, но явно съм достатъчно тъп да не намеря нищо

ми изобщо не е глупав въпроса ти... много сериозен даже....
Значи първо трябва да помислиш между комерсиална среда и опън сорс. Тук ще срещнеш различни съвети, но решението трябва да е твое!
Второ да прецениш до каква сложност ще е софта ти по принцип. Имай предвид, че при АРМ и едно просто на пръв поглед нещо може да ти отнеме години, а в същото време за един ден да подкараш система с тъч скрийн, мрежи и прочие. Всичко много относително и много зависи от това с какъв ОС ще почнеш или без ОС ще се мъчиш...
И не на последно място с какво време и ресурси разполагаш - от това зависи какво може да ползваш.

Оттук нататък вече е лично мнение... Забрави за армулатори и простотии.... Ако си за по-елементарни неща може да погледнеш IAR от комерсиалните, макар че аз лично бих ти препоръчал Eclipse + GCC, защото това е най-доброто решение и дава най-много възможности. Но трябва да знаеш, че това не винаги е най-удобното... Знаеш опън сорс нещата понякога са недодялани и най-малкото трябва време да ги разучиш. Но от там нататък като възможности може би само на GreenHills имат някои предимства, останалите комерсиалки са просто едни лъскави....

едит: ако ти се пробва опън сорс -> www.yagarto.de четеш внимателно и инсталираш каквото ти казват...

Ами-и-и-и... за сложноста на бъдещия ми сорс не бих могъл да гадая защото за сега целта е обучение Примерно леки проектчета като GPIO(бутончета, интеръпти и т.н)/UART/SPI/I2C...
Колкото до ОС-а ... ми предполагам Виндоус, НО знам ли какво ще се наложи.

Ще погледна IAR. Там поне имам мизерен опит от ТУ...

Други мнения?

под ОС имах предвид RTOS-че дето да търкаляш в желязото... Ъъ вероятно си мислиш че такива бози ти не трябват, ма поразгледай първо форумите да видиш колко хора се оплакват че не могат едно GPIO да подкарат. Те тва е проблема на ARM - шибаната периферия, че за едно GPIO имаш 30-на регистъра, пък за UART/SPI е още по-сложничко. Примерно за USB сорсчето дето ползвам е към 20-на сорс файла. Повярвай ми едва ли ще искаш сам да си го пишеш. И аз не съм го писал сам де
Не че няма да намерип и OS-less код... но си е зор ако трябва да смесваш различни сорсове, безсмислен зор...

Затова човек трябва да скача на Луминари + библиотеката им и няма нищо по-лесно от подкарване на ARM и перифериите му .

я раздуй малко за тая библиотечка? Не че ще тръгна да я ползвам, питам просто от любопитство...

ST също давават много библиотеки за периферията (вкл. USB и Ethernet). Апликейшъни също има доста. И стандартните математики - FIR, IIR, FFT.

OS естествено не дават , оно си струва пари

Ами имаш направено всичко за всички периферии и можеш да го ползваш напълно безплатно и работи супер.
Аз работя с няколко чипа на Луминари вече около година и половина и честно си казвам, че досега не съм намерил никакъв проблем.
Всичко си работи като пич. Единствено имах малко грижи докато се светна как точно работи контролера на прекъсванията, че не е нещо много просто, но това по-скоро си беше мой проблем. Всичко друго бачка на 6 даже без да се налага да отваряш дейташита. Аз поне за пръв път попадам на нещо, работещо толкова гладко и без проблеми. Някои дребни неща са направени малко странно, т.е. можело е да бъдат и по-добре измислени, но неможе пък всичко да е перфектно. Та аз поне, вече залагам доста на тая фирма и смятам да си ги ползвам най-редовно. Аз работя с IAR 4.42 версията.
Сега като се замисля имам една забелжка - ако могат да направят една програмка, дето да смята скоростта на CAN интерфейса и да ти дава констатите за регистрите цена няма да имат. Всеки път като се засиля да чета как се смята скоростта и никога не мистига търпението да стигна до края. Добре, че досега все ми се налага да ползвам стандартни скорости, дето ги има в библиотеката, ама скоро ми предстои да пусна един CAN на 33.3 кбита/сек и още от сега даже не ми се почва да смятам . Между другото - някой ако е срещал такава програма много ще се радвам да я сподели тук .

Това че бачка стабилно си го споменавал и преди, но любопитството ми е какви са точно възможностите на тая библиотечка и как е организирана...

Иначе те всичките си имат някакви библиотечки. Атмел също имат и библиотеки и примери, ако ги събереш на едно място може би ще се получи едно CD. За бачкането бачкат, ама кво да ти кажа - дърво! Стават само ако искаш да се бъзикаш, но в сериозен проект не може да ги ползваш. Първо са много неефективни, в смисъл достъпа до всеки регистър едва ли не е облечен в отделна функция, което генерира страшно много излишен код. Но това е най-малкия проблем. Големият проблем, е че нямат концепция да се получи нещо като API и който го ползва да не трябва да изчита открай до край дейташийта, за да го ползва това API.
Имат хиляди примерни, като почнеш от пращане на байт по серийния и стигнеш до USB че и Ethernet, но реално всеки пример си е сам за себе си и не дай си боже да поискаш да направиш две неща премерно хем UART хем SPI и става каша. За да ги подкараш двете неща, трябва да разучиш как работят перифериите, да измислиш как да ги използваш паралелено и за капак да преправиш атмелския код. То просто си губи смисъла да им ползваш нещата... Според мен едно API има смисъл ако ти спестява мъките да разучаваш кво седи отдолу. Искаш примерно да ползваш UART - гледаш какви функции ти трябват за да отвориш четеш, пращаш. Докато при Атмел не е така.
Всъщност те функциите си ги имат, само дето обикновено са блокиращи, т.е. отваряш една периферия и ако зависнеш на четене всичко умира. Все пак става дума за чипове с по 10-15 периферии, просто не става на първата периферия да забиеш като Windows на флопи диск...

Не знам дали ги обясних проблемите... с две думи нещата на Атмел са добре ако нямаш ОС, т.е. ако приложението ти е една нишка с една периферия. В момента в който решиш, че приложението трябва да е повече нишки или повече периферии и ползата от библиотечките им става отрицателна... Та любопитството ми беше за Луминари дали те са направили нещо по-така или и те седят на варианта "1 нишка + 1 периферия"...

Ами и на ST са така както описваш. Правени са за работа без ОС. Сигурен съм че и на Luminary са така. И са бавни - всичко е облечено във викане на функции.

То въобще никой няма да си прави труда да ги прави ОС френдли. Причини дал господ.

Но за начално заиграване стават.

Незнам дали си виждал това, малко е PIC ориентирано, но може да е от полза

http://intrepidcs.com/support/mbtime.htm

здравейте

на мен ми стана интересно за greenhills средата, явно във форума има хора, които са я ползвали; аз отидох на сайта, опитах да изтегля някаква демонстрационна версия, чунким видя защо този развоен пакет е толкова велик - така съм чувал - че е велик и струва много долари; не успях да намеря; както и да е; от информацията, която видях на сайта на greenhills, най интересен ми се видя дебъгерът; явно има доста възможности, например да събира големи trace буфери за по-късен анализ

аз никога не съм ползвал подобни възможности, а съм чел, че доста АРМ процесори ги поддържат; накратко - каква е идеята на тези trace-ове

изобщо - какъв е келепирът от споменатите trace-ове? някой от колегите във форума ползвал ли е такива неща, с какво са му помогнали, по какъв начин могат да са полезни за по-широката публика (от която съм част и аз - като цяло ползвам прости техники за дебъг и не съм много навътре с хардуера)?

предварително благодаря за споделения опит!

Келипир има... и то голям понякога. В много случаи е невъзможно да се дебъгва по традиционен начин. Примерно много:
1) процесора управлява печки двигатели, квото се сетиш и спиране на брейкпоинт ще прецака тия неща дето се управляват
2) процеосра комуникира с разни мрежи и при спиране на брейкпоинт отсрещната страна те отсвирва...
3) дори и да ги няма горните проблеми, пак понякога те изкушава да видиш "предисторията". В смисъл знаеш как да разпознаеш проблема - да речем омазване на памет, но ако софтуера е много сложен не можеш да определиш кой и кога ти е омазал паметта.
Това общо взето често се получава при големи операционни системи, дето нямаш поглед върху всичко и в един прекрасен момент нещо се издънва, но тогава вече е късно щото ти виждаш върха на айсберга. В такива случаи не можеш да дебъгваш стъпка по стъпка докато се издъни, щото то тогава или отказва да се издъни или имаш милиони или милиарди стъпки...

Идеята на трейсовете е проста - записва се в реално време достатъчно информация за това какво изпълнява процесора. После тоя запис го "дебъгваш", като за целта към дебъгера освен стъпка напред имаш и "стъпка назад", т.е. може да ходиш напред-назад както си искаш и да си слагаш брейкпоинтове и т.н.
Това е... Удобно е щото пести страшно много време. Пресдтави, че си търсиш кой ти омазва паметта.... Намираш момент в който още не е омазано и момент в който вече е омазано. В повечето случай имаш и скала на времето, така че цепиш на две интервала и гледаш дали е омазано или не... И определяш коя половина от интервала трябва пак да разцепиш на две и пак на две и пак... Колкото и голям да е интервала с логаритъм двоичен му разказваш играта
Апропо ако си логнал всичко дебъгира си работи пълноценно - т.е. виждаш паметта, променливи - всичко за която точка от времето си искаш.

Специално Greenhills имат и други екстри, много добре онаглядват трейс записа, така че визуално виждаш къде има по-голяма активност, къде по-ниска. Към това като сложиш и разни статистики може освен за дебъгване да го ползваш и да си оптимизираш кода и да хващаш "тънките" места...

За съжаление... тия гъдели обаче още не са за простосмъртни като нас. Аз ги разказвам, щото съм ходел на разни презентации и на Грийнхилс и на други, но нямам трейс емулатор. Цените на читавите започват от 10,000 еуро. А специално Greenhills които ми харесват нещата им са направени така че да трябва да вземеш техен емулатор, техен дебъгер, техен компилатор, че и тяхна RTOS.... Цената на това удоволствие няма да коментирам, само ще кажа че не мога да си го позволя
Има и по-евтини варианти, обаче те са или много измислени (за шарани) или твърде неудобни.. Между другото отскоро GDB направиха някаква поддръжка за трейс, така че да се надяваме скоро да се появят и опън сорс или по-евтини решения.

здравейте

като че ли ще е дълго това, което искам да пиша; днес (02122008) най-сетне успях да компилирам цялостен набор от gnu инструменти за софтуерна разработка върху арм-ове; пакетът с инструменти изтеглих от www.codesourcery.com; точният адрес, дано не бъркам, е: http://www.codesourcery.com/gnu_toolcha ... c.tar.bz2; шибано, доста шибано е да се ориентира човек в този сайт... но това е пакетът; основните включени пакети за разработка са: binutils, след тях gcc, после (и не задължително) newlib, има и още няколко (като напр. дебъгерът gdb); за припомняне - binutils съдържа основните инструменти за опериране с обектни файлове - свързващ редактор, асемблерен транслатор, програми за инспекция на обектни файлове, и други подобни инструменти; после, gcc е пакетът от gnu компилатори - поддържат се доста езици, но мисля, че от най-голям интерес за развой върху вградени системи (каквото и да значи това) са c и c++; аз лично знам само c, и малко асемблер (каквото и да значи това); накрая следва newlib, не съм съвсем сигурен какво точно включва тази библиотека, но ми се струва, че е замислена като компактна стандартна c библиотека, пригодена за употреба в разработки с вградени системи, и изобщо при малки по обем и наличност на ресурси системи; от пакетите жизнено необходими според мен са binutils и c компилаторът от gcc пакета

тази комбинация съм ползвал досега успешно за различни проекти за т.нар. "bare metal" арм конфигурации; тази комбинация се компилира и употребява лесно; макар и да не знам почти нищо от c++ и да не ми се налага да ползвам стандартни библиотеки (работя по скромни проекти срещу скромно заплащане), усещам, че да се подкара цялостен, здравословно и жизнено работещ gnu набор от инструменти е важно; днес, най-сетне - надявам се - успях, и искам да споделя опита си (най-малкото защото не успях да намеря твърди и ясни инструкции, и е по-добре лично за мен да документирам, отколкото да забравя и да ми потрябва да мина по същия път отново); фактически:

shopov@katana ~/src/arm-2008q3-39-arm-none-eabi/binutils-build $ ../binutils-stable/configure --prefix=/home/shopov/elfarm/ --program-prefix=elfarm- --target=arm-elf
shopov@katana ~/src/arm-2008q3-39-arm-none-eabi/binutils-build $ make
shopov@katana ~/src/arm-2008q3-39-arm-none-eabi/binutils-build $ make install
-- problems with building the documentation - no thing to worry about
-- copy newlib libc include directory (newlib/libc/include) to ${prefix}/arm-elf/include
shopov@katana ~/src/arm-2008q3-39-arm-none-eabi/gcc-build $ ../gcc-4.3/configure --prefix=/home/shopov/elfarm/ --program-prefix=elfarm- --target=arm-elf --with-as=/home/shopov/elfarm/bin/elfarm-as --with-ld=/home/shopov/elfarm/bin/elfarm-ld --disable-threads --disable-shared --disable-libssp --with-cpu=arm7tdmi-s --with-mode=arm --with-sys-root=/home/shopov/elfarm/ --with-dwarf --with-newlib --enable-languages=c,c++
shopov@katana ~/src/arm-2008q3-39-arm-none-eabi/gcc-build $ make
-- success??!!?!?!
shopov@katana ~/src/arm-2008q3-39-arm-none-eabi/gcc-build $ make install
-- problemс with building the documentation - no thing to worry about
shopov@katana ~ $ path=/home/shopov/elfarm/bin/:$PATH
shopov@katana ~/src/arm-2008q3-39-arm-none-eabi/newlib-stable $ ./configure --target=arm-elf --prefix=/home/shopov/elfarm/
-- problems arise here; resolved by symlinking to "elfarm-" prefixed programs and on "no-file-no-problem" basis
-- c and c++ test drivers built successfully
-- 8 9 6 6 9 8; 896698

"--" в началото на ред са коментари, останалите са буквални команди; на редовете не в началото на реда, буквалният низ "--" обозначава конфигурационен параметър

нищо не съм писал за дебъгер; това според мен не е съвсем основна част на развоен пакет; освен това, gnu наборът от инструменти генерира изпълними файлове в elf формат, с dwarf дебъг информация; комбинацията elf/dwarf е установен от дълго време, де факто стандарт, който се поддържа от всеки уважаващ себе си дебъгер, и то не само за арм-ове; аз лично успешно съм ползвал rowley crossworks и gdb дебъгери за армове; gdb се компилира лесно и работи, поне за мен, по-добре от rowley crossworks, но се конфигурира по-трудно; като цяло - удобен, но на места - неодялан

защо пакетът на codesourcery? защото включва подръжка на thumb2, т.е. armv7-m (cortex) ядра
защо gnu? защо не някоя интегрирана графична развойна среда?
въпрос на избор; може би така съм свикнал; в никакъв случай не съм gnu или linux фанатик; освен това, ако човек не го мързи твърде много, gnu инструментите могат да се интегрират в някоя графична развойна среда, аз лично съм ползвал rowley crossworks (на такава ми казаха да работя, за което ми и плащат), знам, че и eclipse е такава някаква графична среда, но не съм я позвал - много ми е интересно да прочета ако някой тук я е ползвал, да сподели впечатления и опит; хубаво ще е да се чуят мнения

изобщо и окончателно, ще се радвам тези записки да са от полза за някой, някога; на мен цялото упражнение ми струва много труд и мъка, но крайният резултат, според мен, си заслужаваше, доволен съм, и дано не съм дотежал на някой с много писане

поздрави,
шопов

miro_atc - сори, че чак сега ти отговарям, ама нали бяха празници при нас и бях малко на пътишествия по кърищата на Америка .
Иначе библиотеката е организирана точно с API функции и се работи много лесно. Отделно имаш и по два варианта на самите функции за работа с перифериите - блокиращ и неблокиращ и ти си решаваш кой да ползваш. Само за пример - единия ми проект беше една джаджа с GPS и GPRS, microSD card, 2 CAN, външна I2C памет, 3 серийни канала, 4 АЦП-та, по 8 цифрови входа и изхода, един ZigBee модул, един модул VGA CMOS камера и разни други дребни неща. Та цялото това нещо съм му написал кода без да се налага да отворя дейташита на процесора и без идея да си имам с какви ригистри се работи и как се инициализират отделните периферии. Кода стана около 50к и още около 20к за бутлоадер през GPRS-а. И професорчето си бачка без проблеми вече няколко месеца и аз поне не открих никакви бъгове, освен моите си в моя код. Та смятам, че Луминари предприеха един много добър ход и това ще им помогне да се наложат на пазара. Отделно имаш сорс кода на всички библиотеки и ако нещо не ти харесва как е направено можеш да си го промениш по твой образ и подобие . Ето ти PDF-а с описанието на API функциите на библиотеката и ще придобиеш представа много бързо за какво става въпрос.