То ядрото е проектирано за определен процес и от там явно за определена честота. NXP нямат много общо май с бутане по ядрото - би трябвало да ползват готова библиотека.
На сайта на ARM някъде имаше кое ядро за какъв процес е предвидено и за каква честота (май и консумация имаше)...

Mнение на един аматьор за и против PIC и AVR
Повече от една година правя разни неща с PIC.
Поради многобройните съвети и че PIC стават само за мигал ки
реших от месец месeц и половина да ползувам и AVR .
Пиша програмите и за двата вида с Flowcode http://www.matrixmultimedia.com
Програмирам ги с PicKit2
И единствената разлика между PIC и AVR за мен е че AVR умират в моите ръце
Резултат AVR 3br. срещу PIC 0br. с изключени на един издухан RA0 на PIC16f873A
Но процесора си работеше А AVR те умираха тотално
Моя съвет към аматьорите в този бранш ползувате PIC с риск никога да не станете
професионалисти

¶ на теб от Microchip трябва да ти плащат ако не го правят!

A аз се надявам да излезе среда за програмиране на PIC24 и PIC32 подобна или същата като

Flowcode

И да питам нещо случайно попаднах на тези:

някой знаели кои ги използува и за какво на тези цени?


http://www.buyaltera.com/scripts/partse ... =EP4SGX530
http://avnetexpress.avnet.com/store/em/ ... FFG1156CES

И как така програмираш AVR с PicKit2 че нещо не вдявам?

Флоукоде-то откъде го напазарува?

Ето тук е описано:
http://www.sonsivri.com/forum/index.php?topic=27727.0

Официално от тук може да се закупи не е скъпо:
http://www.matrixmultimedia.com/product ... 0for%20PIC
Пиратско копие може да се свали от тук:
http://rutracker.org/forum/index.php

Момковци, не се занимавайте с детски играчки!

Има доста периферия в LM3S сериите, дето няма и помен за тях в PIC32 - пример енкодерен вход (QEP) и мотор контрол PWM, не съм гледал скоро, но нямаше и CAN в PIC32 ...
Така че зависи за какво се ползва, но базата си е по-широка при Луминари.
Това че има много ревизии на ератата за мен е голям плюс - ядрото е бетон, ако са описани и проблемите на периферията, всичко ще е ок. Докъде го докараха Майкрочип с оправянето на етернет контролерите си? Има си бъгове в ПИК, дето висят даже недокументирани с години - това ли е по-добре?
Казвата че скоро ще има и PHY за етернета - някой да е базирал дизайн на база на тия предположения? В старите им PHY-а (SPI-контролера) не само че нямаще auto MDI/MDI-X, ами и ръчните им режими бяха бъгави.

Дали има шанс да изчезнат Луминари - ами вече ги няма, сега са Тексас - дали ще изчезнат тексас, е друг въпрос.

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

Всъщност, ДМА не е ли някои от стандартните АРМ макроселове?

Като цяло прекъсванията на Кортекс са много по-добре организирани от АРМ7/9, с ПИК няма място за сравнение въобще, за ПИК32 незнам.

Че МИПС имал MAC - ами при кортекса има "single cycle 32-bit multiply", а отделно си има "hardware divide" (не е single cycle, май беше 12-13 такта).

Относно ядрата, съм склонен да приема че МИПСа е почти на нивото на кортекса, но периферията при luminary е по-добра.

Само да отбележа, че сравнението по периферия и по бързодействие е доста подвеждащо нещо. Аз твърдях (и продължавам да твърдя), че Луминари имат по-богата периферия и като производителност са по-бързи на теория. Мисля че при еднаква честота куртекс ще е една идея по-бърз от М4К а освен това е луминаритата вече почти от всички серии имат 100MHz, а други като LPC бачкат и на 120MHz.

Но всичко това е само от фактологическата страна на нещата... въпреки горните предимства специално Луминаритата си имат и мнооого сериозни чепове. Толкова сериозни, че ако каубойците не вземат мерки аз лично ще се огранича да им ползвам чиповете само в несериозни проекти....
Тъй че ако Майкрочеп си изпипат нещата, поне от конкуренцията на Луминари може и да не се притесняват. Макар че аз лично се надявам да има други куртекси... Надявам се примерно Атмел да предложат по-голям избор по-добри цени и да няма проблем с наличността. Тогава не бих си и помислил за Глуминари



ми поредната рекламна брошура... само дето хич, ама хич не е вярно....

АРМ7/9 си имаха перфектната архитектура по отношения на прекъсвания и режими на ядрото. При кортекс нещата са меко казано оплескани

Не мога да се съглася - говоря не само за interrupt controller-а, но и за съхраняване на контекста, interrupt nesting-a, че ако щеш и атомик инструкциите за "bit test and set if clear", че да не ти се налага въобще да забраняваш прекъсванията, никъде в целия ОС - при ARM7/9 нямаш такъв atomic lock и се налага за щяло и нещяло да спираш глобално прекъсванията. Това е по-трудно, и отделно хабиш сума ти и цикли доде сменяш контекста.

Разбира се че и при арм7/9 VIC-a не е лош - все пак, бая милиарди ядра цъкат от тях. Аз казвам, че подобренията в Кортекс са доста ценни.

Аз лично съм го сравнявал като feature-и с 28xx на тексаксите DSP-та - определено кортекса се доближава много до тях, а за мен те (28хх) са еталон за мощен микроконтролер с DSP насоченост. Вярно, че са доста специализирани, ама на кой не би му харесал техния HRPWM с 150ps (цитирам по памет) резолюция?

Не знам за продуктите на Луминари, но за другите им продукти знам че дават много добри цени при договорка с тях.

Едит: най-добрият контролер е този, които познавам - ако обективно сравниш арм7/9 с кортекс, ще се съгласиш че има подобрения.

- мотор контрол PWM има, QEP има в dsPIC33, нали се сещаш, че след като са го направили при dsPIC33 ще го направят и при PIC32;


- напротив, има, в някои по 2 даже;


- Глупости на търкалета, ще правя нещо си на ниво драйвер при положение, че при PIC32 DMA няма ограничение дали ще взема от флаша, RAM, или периферия;


- оттук следва, че след като не знаеш как е при PIC32, значи при ARM са по-добре организирани прекъсванията Ми ако знаеше ? А на каква база сравняваш (ds)PIC16/18/30/32 с 32-битов контролер ? Звучи като тюрлю гювече запекано на бавен огън


-The high-performance MDU implements single cycle multiply and multiply-accumulate (MAC) instructions, which enable DSP algorithms to be performed efficiently. It allows 32-bit x 16-bit MAC instructions to be issued every cycle, while a 32-bit x 32-bit MAC instruction can be issued every other cycle.


- Отново неявно се позоваваш на твърдението, че не знаеш как е при MIPS/PIC32, затова извода е, че периферията при Гумнари е по-добра.

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

28xx DSP на TI са наистина добри и старички, напоследък доста се позанимах с тях. Практически имат един сериозен недостатък - цената ( >$20 ) и невъобразимо дългите срокове за доставка. dsPIC33 остъпват по производителност в някои от перифериите, като например АЦП, но в повечето периферия производителността е същата, като цена са обаче около 3 до 4 пъти по-евтини. Един ден сравнявах DSP библиотека за 28xx и наличните аналози в DSP библиотека за dsPIC33, практически каквото имаше едната библиотека, го имаше и другата. Един колега се бори със софтуера за 28xx. Като хардуер платката, която направих тръгна от раз без никакви забележки към 28xx DSP-то. Само клока изглежда леко назъбен в началото на двете плата, но всичко останало си е пушка. Щях да забравя, така и не можахме да подкараме JTAG на 28xx с външен буфер, сума литература изчетохме, ощо толкова чипа сменихме, рязахме, насосвахме и пак не тръгна, или тръгне и заспи. Накря ни свързаха с един гуру от TI и онзи отсече: за какво са Ви тия глупости с буферите ? JTAG-а на 28xx работи с до около 20см. дълги кабели без проблем. Така и се оказа, изхвърлихме буфера и до там бяха проблемите с JTAG на 28xx.

single cycle multiply значи поне два цикъла MAC - нали и ADD трябва да се състои в някакъв момент.

Обаче всичките тия MCU-та с MAC за по "1 цикъл" са подвеждащи, в това число и power.
Става дума за операции между регистри. Ами четенето към тия регистри на данните, коефициентите
и накрая писането на резултата? За тия не-DSP-чави процесори това са поне още три цикъла
(ако имат бърз и достатъчно голям кеш, което не винаги е така). После те повечето
трупат само 32 бита, което не е много (16*16 е ОК, но 32 резултат могат мнооого бързо да се
препълнят).
В истинските DSP-чави процесори, като 54xx (него го знам както трябва), всичко това става в
един цикъл. Т.е. в един цикъл чете два операнда (данни+коефициент), прави MAC и пише един операнд
(резултат), като кръговите буфери са "безплатни". При подходящо организиране и ползване на
части от паметта с "двоен достъп", в рамките на все тоя цикъл и DMA-то може да напише нови
данни някъде, като и неговият кръгов буфер е "безплатен".
Това прави възможни неща с едно 5420 (2 ядра по 100 MHz + достатъчна памет за всичко, някъде
към 200к макй беше общо ако не и повече) работи, за които на "обикновените" процесори ще
им трябва ако не да отидат в гигахерците, то поне доста да се доближат до тях (не е лесна сметката,
но ще е над 700 MHz със сигурност).
Ей го въпросното нещо (разработка на 10 години): http://tgi-sci.com/tgi/hstb.htm .

В последните 3 страници не видох думата "Atmega". А първоначално това беше темата.

Да, обаче какъв лаф стана...

Ще видите вие когато на мисията до Марс на ракетата напишат "NASA powered by Microchip"