Вы даже не представляете, как я в начале 90x любил возиться с ASM (причем уже после вполне приличного овладения Fortran/С/C++) используя в качестве контролера массовые на то время 286 и высасывая их 12MHz доcуха и потом из 25MHz 386sx все вытягивал. И проект разрастался до нескольких сот килобайт ассемблерного кода... Сейчас это крутится, как минимум, на вполне пристойных 300MHz Geode. Да я конечно прицепил позднее возможность подгружать писаные на С оверлейчики, но все равно не то .
И как мне теперь этот все еще к сожалению, живущий по дурости заказчика проект кровь периодически портит - и переписывать бессмысленно, и пересертифицировать невозможно, и сопровождать многомегабайтные исходники тоскливо.


Возможно, но компиляторы у IAR для разных PIC, естественно, разные - для свежих - посвежее.

Обошелся без отладки , но насколько я помню, там просто DLL от MPLAB используется и все, что MPLAB умеет, будет и IAR уметь.

>> Но, согласитесь, - это уже некрасиво.
>> Просто повышать частоту. А где же работа ума?.

Почему некрасиво? и при чем тут работа ума? Конечному юзеру вообще без разницы что там внутри, а вашими основными критериями должны быть минимальная цена, необходимая надежность и скорость разработки.

Но тем не менее, даже PIC24H 48-МГц AVR покроет...

Мне вот ARM вообще не нужен. Только в несколько проектов заскочил LPC2148, потому как есть USB, а у микрочипа пока только в PIC18. В остальном - ничего особенного. Единственное преимущество ARM по скорости - это наитивная работа с float, бо 32-битный. Но я float-ы только по лени использую =) Ну и с U32 на арме тоже будет конечно веселей...

Вот осенью будут образцы PIC24F серии GB с USB OTG, тогда армы у меня вообще отпадут. Останется только старший AVR32 и то для факультативных задач =)

Разработчики они ведь разные - есть разработчики технологического оборудования - какому разработчику, например, конвеера захочется еще голову забивать.... ну Вы поняли чем

А какие проблемы - стираешь прошивку и 'творишь'

Свежо


Ну 'особенного' нет, а плохого чего? Смысл был после освоения возвращаться к микрочипу и ожиданию "Вот осенью будут образцы PIC24F серии", вместо использования сейчас всего ARM многообразия от многих конкурирующий производителей?

А он, типа, к Вам уже 'пришел', 'освоился' и теперь ему только 'остаться' осталось

>> Ну 'особенного' нет, а плохого чего

когда я писал "ничего особенного" я имел в виду то что имел. Нет ни конкретных засад, ни чего-то сверхъестественного, как по периферии, так и по ядру. Мне, например, не хватало программного сброса. Можно конечно WDT не сбрасывать, что и делал.

>> Смысл был после освоения возвращаться к микрочипу и ожиданию

Смысл простой - не расширять номенклатуру на складе и номенклатуру поставщиков. Если вам плюс-минус полбакса - да наплевать - мне нет.
Я что где-то написал, что жду? Я сказал, что когда будет, филипс отпадет из рассмотрения. А с учетом того, что у микрочипа линейка намного обширней, выбирается контроллер не избыточный, под задачу, что всегда на цене сказывается.

По поводу многообразия - да по сути среди мелких ARM7 его и нет - NXP и ATMEL. Ну может ST сейчас с кортексом подтянется...

>> А он, типа, к Вам уже 'пришел'

Я не про урезанные UC3A/B

Так его и сделали приблизительно это время назад. После чего благополучно плюнули и забросили. Ни тебе компиляторов пристойных, ни IDE, ни бортовой переферии. Вот это по нашему...
А задумка была хорошая - PDP11 в RISK варианте. Жаль, что не сложилось...


Полностью солидарен. В конце концов, не в платформе как таковой дело, а в ее наполнении.

Да никакой это не PDP-11, а самый настоящий RISK-I. И хорошо, что не сложилось. Без нормального компилятора такое программировать - увольте.

А Вы в курсе, что в промавтоматике применяются исключительно языки стандарта МЭК 61131-3. С Вашим (и моим тоже) С или еще хуже С++, а так же со всякими АСМами Вас туда на пушечный выстрел не подпустят.
Насчет разбирательства с чужой писаниной. Да, все языки упомянутого стандарта - в общем-то не очень.
Но на нашем производстве в случае необходимости (поломка, небольшая модернизация) этим делом занимается обыкновенный наладчик, как раз с помошью вышеупомянутых языков. А кодер с улицы здесь не нужен, потому как не отличает реле от гайки, в отличие от наладчика.
Насчет ПЛК на основе компьютерной платформы - все уже сделано до нас, причем неоднократно и со всеми извращениями, типа доступа к ядру процессора . Результаты здесь. К стати, OWEN - это один из результатов.
И к слову, настоящий пром. компьютер начинается от 1500 еврорублей. Так, что конкуренции там не будет и переучивать никого не надо, потому, как на производстве все это давно есть само по себе, со времен стоек типа S5.


Не в терминах дело. А в том, что у нас ни одно дело не доводят до логического завершения. Ядро сносное, но все остальное... Кто мешал написать нормальный компилятор, пока было время?
И потом, я пробовал его программировать на тех дровах, что давались к нему на сайте. Ничего сложного не обнаружил. Не хуже соотв. PICа или AVR.

Сообщение отредактировал Прохожий - Aug 13 2007, 08:58

Термины - это AVR и PIC. А PDP-11 и RISK I - это такие совсем разные архитектуры.


Мда. А использование регистровых окон руками оптимизировал? Спасибо, я не хочу.

Сообщение отредактировал pokos - Aug 13 2007, 09:47

Да не также он это выполнит!

Ваш код при равном количестве циклов PIC/AVR, выполнится в два раза медленнее на PIC с ядром на 40 Mhz чем на AVR с ядром на 20Mhz.

Кто умеет считать заметит что частота в два раза выше, производительность в два раза ниже, это даже не учитывая особенностей системы команд.


Несоглашусь.

Так как - где же в пиках работа ума?
PIC18 с PLL, ядро на 48Mhz, по производительности что AVR на 12MHz.
Что мы сравниваем-то?

Не от большого ли ума в PIC машинный цикл выполняется за 4 такта?
Почему не 1 как в AVR?

Насчет dsPIC согласен, не того поля ягода чтобы его с AVR сравнивать.

Не люблю аналогии, но всё-же:

Дискуссия один в один похожа на: "AMD vs Intel. Какой проц лучше?".

Есть интересное мнение что AMD и Intel не конкурируют, а наоборот сотрудничают. Пока пользователи будут с пеной у рта доказывать что одно лучше другого можно не снижать цены ни на одно ни на другое. В проигрыше только сами пользователи!

Ну разве только..

Тогда уже точно не следует забивать склад и сидеть ограниченном круге поставщиков, не правда-ли?
А вот тут уже к счастью, возможны варианты. Тем более с ходом времени еcть изменения.

Сразу вот так авансом .

Ну полный список:
• Actel
• Analog Devices
• Atmel
• Cirrus Logic
• Freescale
• Hilscher
• Intel
• Luminary Micro
• Micronas
• NetSilicon
• NXP
• OKI
• Samsung
• Sharp
• STMicroelectronics
• Texas Instruments
• Winbond

А из Cortex мелких Luminary уже развернулся.
Кроме того какой Ваш самый массово используемый PIC? Он что, только на Баксовые Cortex тянет?

Пришел в кавычках. Заметили? Я о том-же - девайса еще считай нет, но использовать его уже будете и обязательно на нем останетесь, опять авансом.

А если не будут спорить (спорит не более 1%) то цены снизятся чтоль ?

С чего ?

да и не только, та же Гамма и то и другое сразу поставляет. Думаю, что ей всё-равно, что продавать



думаю автор поста указал тех, кто ARMы уже давно производит и соответственно имеет большой опыт в разработке кристалов данной архитектуры. В данном случае, для определённого круга задач - это действительно Atmel и Philips (NXP). Почему определённого? да потому что можно ли сравнивать круг задач, решаемых например LPC2101 и каким-нибудь кристаллом от Samsung-а? Думаю - нет

А почему именно 2101?
LPC22xx-LPC28xx перекрывают все самсунговские чипы с головой.
Что самое интересное почти каждый второй телефон от самсунг, построен на LPC.

Перед знакомством с МК я довольно тесно сталкивался с ассемблером под х86 - потому мне довольно легко было разобраться и с 51-й серией, и с AVR... пробовал разбираться с PIC - система комманд очень непривычна, да и цены, мягко говоря, пугающие - в "моем селе" 16С84/16F84 стоит сравнимо с ATMega16, если не дороже, и это - при его-то функциональности так что - выбор очевиден.