Нещата са някъде по средата. Микрочип нямаха безплатен C компилатор допреди да изкарат XC-тата, освен ограничените версии (без оптимизации). Свидни спомени проблясват от hi-tech.
Това че има еднаква периферия - хм, старите 16/18 бяха без fifo на уарт-а, новите 24 и нагоре имат фифо, така че не са еднакви. А и това да си пазят старата периферия не го виждам като предимство, очаквам и там да има развитие. Примерно тексасците имат някой периферии, дето са си там от 10-тина години. И то без да са орязани.
Всъщност нито за пик, нито за нещо друго се налага да се работи на ниво регистри. Ако производителя не си е направил труда да направи макар и малка опаковка на достъпа до хардуера са за коша.
Миро, ти гледал ли си им библиотеките? Поне хардуерната абстракция? Каква хардуерна абстракция е това да ти дадат функция - Init_Uart(controlRegValue)??? Алооо??? Точно регистъра искахме да скрием, аз ако ще ровя чаршафи да ви сметна контролния регистър, за чий ми е вашата функция? Аматьори .... Не че това го няма и при някой арм-ове, но то е до производител - някой го могат, други не и не искат да инвестират там. На майкрочип и арм ядро да им дадат (продадат/подарят), пак същия продукт ще извадят.

За сравнение за АРМ има CMSIS. Не че е панацея, но решава доста от проблемите около ядрото. Да не говорим че микрочеп разчитат на това да "скрият" разликите в библиотеките си (не много успешно) - което си го има за АРМ, и то за чипове от различни производители. Викат му екосистема. А с миРКочип си на single source. Дали пък това не променя мисленето на пикобореца - дай да сложа и пик в следващия проект, че да пребъде името на аризонеца, че да не ги хване анемия и да ги поеме пустинния пясък, и да ми отидат на вятъра знанията ... ?

За мен ужасът, свързан с работа по майкрочип, са развойните средства - MPLAB-а и ICD/PicKit. Това е светлинни години назад от конкуренцията. Вземи еклипс или emblocks и имаш 10пъти по-добра среда. Да не слагаме в кюпа среди като Code Composer или CodeWarrior, или AVR Studio-то - които са фирмени както мплаб-а, и тях трябва да гледаме за сравнение. А за дебъг-а - просто мъка. Ако с 32-ките работи J-Link или openocd може и да ги пробвам, но пиккит-а е просто програматор, за дебъгер е кошмар. Е, поне докато не видиш нормален дебъгер, някой хора си мислят че така е нормално. А това че правят по-големи чипове (евала за 512К рам) значи че трябва малко да обърнат внимание и на дебъга.
J-Link примерно работи с много повече чипове отколкото миркочеп ще изкарат до края на Мур. Не знам за какви клокове и напрежения говорите. То и в мплаб-а се случва да омажеш проекта и да си скапеш дебъга. Щото е софтуерен (или поне асистиран софтуерно).

А омазването на дебъг-а ако преконфигурираш пинове - ми затова си има закачане под ресет? Къде е проблема?

Едит: съседните теми за Кинетис/стм/атмел/... дали не показват, че ползването на арм те вади от филма да си ограничен от един производител?

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

гледал съм разбира се. Нямаше да го кажа ако не бях;-)
Друг е въпросът, че аз ПИК не ползвам и само разглеждам код и алгоритми... И доколкото разбирам от това как се пишат библиотеки смятам, че качеството на Майкрочеп е значително по-добро. Най-малкото мен може да обвиняват че съм фен на ПИК, през живота си не съм пипал техен чеп и нямам намерение да пипам, но което си тяхно, тяхно си... не мога да си кривя душата



ох, не ми говори за това недоразумение на природата... Не искам даже да я коментирам!

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

Понеже аз първо отпочвам от ератите, не помня да съм виждал нещо което да няма. Никой не иска да хвърля излишни пари за нови маски, та си решават някак къде е прагът на болката и там спират. И Микрочеп въобще не са някакви шампиони в ератите, справят се доста прилично на фона на всеобщото бързане, даже бих казал че са сравнително читави.

Всъщност, ако някой е изшлайфал много добре хардуера и почти няма ерата, това са например Xilinx/Altera. Забележително инженерстване. Ама там пък проблемите идват от меката част ..

повече кефят PLX. чаршафите са публични, а ерЕтите са под NDA.

илко,
слайдовете са може би ОК. в крайна сметка всяка компания се мъчи да прави кинти за акционерите, а не кеф за разработчиците.

в същност, наличието на леснодостъпна MIPS архитектура на пазара е добро нещо. и ги разбирам, че не искат да се бутат в един наситен пазар от АРМ-ове. отдавна са изтървали АРМ влака и никого няма да впечатлят, с каквото и да излязат на коловоза. в крайна сметка - имат си Стратегия, следват я и очевидно изкарват добри кинти за акционерите. по света пикоборци много, хората си ги търсят и всички са щастливи.

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


от 486 насам интел вкарват все повече и повече микрокод за фиксване на бъгово в силикона. без никакви обяснения. за еди коя си маска - ето ви битсрийм, зареждате и не пипате нищо. но поне дават пачове. АМД и това не дават, там е пълна конспирация.

интел напоследък така си преправиха сайта, че не мога да намеря нищо. не че ми е притрябвало нещо особено в момента, просто ми се ще да следя с едно око модата. обаче нещата станаха непроследими, освен ако не си на 'държавна' заплата в БАН. "Software development guide for PXA32" има повече страници, отколкото са транзисторите в 6502...

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

В крайна сметка тази серия контролери ще е глътка свеж въздух за твърдите фенове на Микрочип. Очакваме да узреят за FPU и SIMD... може би в някоя следваща серия.

Ограничени и без оптимизации са две различни неща. Ограничена е до определен размер на кода. Аз работя обикновено със стари версии на техните компилатори, примерно MPLAB dsPIC C v3.23 от 2010г. и мога без да платя и стотинка да го използвам за производствени нужди. Ако пък толкова много ми трябва оптимизация мога да си го компилирам от сорс код или да похарча $500.


MPLAB 8.xx работи и с RealICE, a MPLAB X работи и с J-Link. Извинявай, ама да разчиташ на PICKit си е аматьорщина. RealICE работи толкова бързо и добре, колкото и J-Link при ARM-овете.

Като вметна CW, стария им CW 6.x е толкова кинеф, колкото и MPLAB 8.xx , дърво от всякъде. Новият им CW 10.x пък не може да импортва стари проекти, при MPALB X не съм имал проблем да импорта кой да е стар проект. Code Composer старите им версии е същото дърво като CW 6.x, един макрос не можеш да проследиш и да видиш какво става. Когато минаха на Eclipse нещата се подобриха. Но да не забравяме, че при Freescale/Texas всичко е платено и би трябвало IDE фирмените им среди да са много по-добри, ама не са ( тук не слагам Eclipse и NetBean базирани решения ).


Можеш ли да изброиш последните 3 проекта, в които си използвал FPU и за какво, ако разбира се, не е строго секретно ??

В момента FPU-то ми трябва за смятане на регресия с две свободни променливи по метода на Levenberg–Marquardt. Функцията на която трябва да се сметнат параметрите е експоненциална. Не виждам как ще стане с целочислена аритметика. Със софтуерна емулация на FPU ще е като минимум 10 пъти по-бавно, а на мен ми е важно всичко да се смята бързо за да се пести батерия.

Този метод оправя ли се с 23-битова мантиса?

Да - няма забележима разлика в резултатите като се работи изцяло с float или изцяло с double. Понеже има много степенувания (а степенуването е бавно) се принудих да си напиша оптимизирана функция за степенуване, която го смята с полином от 5-а степен и сега е добре като скорост.

за тези, които се интересуват и от скорост - метода е следния:

x ^ y = exp( y * ln( x ) )

тоест степенуването се разлага на три операции - един натурален логаритъм, едно умножение и една експонента

понеже натуралния логаритъм и експонентата вече са функции с един единствен параметър - те могат да се апроксимират с полином във вида:

exp(x) = a x^5 + b x^4 + c x^3 + d x^2 + e x + f = ((((a x + b ) x + c ) x + d ) x + e ) x + f

по същия начин се апроксимира и натуралния логаритъм

както виждате вече има само събирания и умножения които на ARM-овете са винаги по един такт и така в 21 такта имаме изчисление на float ^ float

всичко това може да се направи и с логаритъм и експонента на база 2 (както е по IEEE 754 - числата са представени като двоична мантиса и 2 на степен цяло число експонента ) и тогава всичко става още по-удобно

Друго приложение за floating е фонова калибрация на е-компас. Freescale препоръчват по възможност ядро с FPU. Не че не става и без, но са тежки изчисления.
Или код-генерирани алгоритми от моделиращ софтуер - примерно Matlab/simulink.

Брей, тц, тц... човек да се чуди направо как са писали софтуера тия преди 30-40 години на 8-битови неща без FPU. Че даже и до космоса стигнали с тях

Те стигали до космоса ама бааааавно , а сега с един клок и са горе !