возврат из подпрограмм

Hello, Vladimir! You wrote to Alexandr Torres on Sun, 11 Jun 2006 13:28:23 +0000 (UTC):

AT>> Уровень инженера, типа мастера участка (а именно он, или его помошник, AT>> обычно занимается сетапом тестеров) на среднестатистическом китайском AT>> заводе - не сильно выше того чтоты считаешь "уровнем техника". AT>> Разобраться с парамтерами и сетапами тестеров - ума у них хватает.

VV> Способности юзеров подложить грабли самим себе удивительны и VV> неисчерпаемы.Чем больше у них простора для проявления интеллекта - тем VV> хуже.

Ну это все же не юзеры, а производители :)

AT>> А вот перепрошивка фирмваре самого тестера - обычно этим занимается AT>> наш представитель. Собственно, пока все разы на заводе это делал я :) AT>> Хотя в принципе - не вижу препятствий чтобы в дальнейшем они это AT>> делали сами. Прошивать фирмваре в изделя ведь у них ума хватает, чем AT>> тестер хуже? :)

VV> Тем, что из-за одного навернувшегося тестера будет навернуто много VV> изделий.

Если тестер навернется - у них не пройдет тест :)

VV> И, что хуже всего, это может выясниться с большим опозданием... А если они резистор не тот впаяют, будет не тоже самое?

[Бомжей любить - не эхи модерить!]

With best regards, Alexandr Torres. E-mail: snipped-for-privacy@yahoo.com

Reply to
Alexandr Torres
Loading thread data ...

Hello, Vladimir! You wrote to Alexandr Torres on Sun, 11 Jun 2006 13:32:55 +0000 (UTC):

AT>> Общаяя идеология такая - под каждый вид железа, совмстимого в плане AT>> тестирования между собой, делается свое хардваре тестера. AT>> Оно представляет собой источник питания нужных напряжений, нагрузки и AT>> измерительные цепи, коммутируемые реле. AT>> Управляется это все стоящим в тестере микрокотроллером, индицируется - AT>> светодиодами (например 4 стадии теста, красный и зеленый на каждую). AT>> Две кнопки - "Старт", "Стоп".

VV> [...]

VV> Какова дальнейшая процедура, если тест не проходит?

В ящик с красной биркой, и далее - на ремонтный участок.

[Бомжей любить - не эхи модерить!]

With best regards, Alexandr Torres. E-mail: snipped-for-privacy@yahoo.com

Reply to
Alexandr Torres

Sun Jun 11 2006 18:32, Dmitry Orlov wrote to Vladimir Vassilevsky:

VV>> Способности юзеров подложить грабли самим себе удивительны и VV>> неисчерпаемы. DO> К сожалению, совсем без интеллекта получается еще хуже. DO> По идее, в начале каждой смены через тестер должен прогоняться заведомо DO> исправное устройство и проверяться что он намерял и прошло ли оно тест.

Однажды не в меру умные юзера решили шить AVR-ы каким-то фирменным программатором. И, конечно, перепутали фьюзы. Все работало как будто так и надо. До поры до времени. В результате пришлось открывать ~10k упакованных коробок, разбирать корпус и перешивать по ISP.

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

Reply to
Vladimir Vassilevsky

Sun Jun 11 2006 18:34, Dmitry Orlov wrote to Vladimir Vassilevsky:

AT>>> Две кнопки - "Старт", "Стоп". VV>> Какова дальнейшая процедура, если тест не проходит?

DO> Повторная визуальная проверка, ремонт. Если все равно нет - в печку.

То есть у вас нет необходимости делить тест на этапы и прогонять отдельно тот этап, который не проходит?

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

Reply to
Vladimir Vassilevsky

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Vladimir Vassilevsky! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sun, 11 Jun

2006 15:19:04 +0000 (UTC):

VV>>> Способности юзеров подложить грабли самим себе удивительны и VV>>> неисчерпаемы.

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

VV> Однажды не в меру умные юзера решили шить AVR-ы каким-то фирменным VV> программатором. И, конечно, перепутали фьюзы. Все работало как будто VV> так и надо. До поры до времени. В результате пришлось открывать ~10k VV> упакованных коробок, разбирать корпус и перешивать по ISP.

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

dima

formatting link

Reply to
Dmitry Orlov

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Vladimir Vassilevsky! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sun, 11 Jun

2006 15:20:36 +0000 (UTC):

AT>>>> Две кнопки - "Старт", "Стоп". VV>>> Какова дальнейшая процедура, если тест не проходит?

DO>> Повторная визуальная проверка, ремонт. Если все равно нет - в DO>> печку.

VV> То есть у вас нет необходимости делить тест на этапы и прогонять VV> отдельно тот этап, который не проходит?

Нет. Сейчас мы разрабатываем (собственно мы-то уже разработали, теперь механику с иголками ждем) тестер для отдельных модулей. Но и он проверяет сразу все, что может. Если что-то не прошло, можно лишь дать ремонтникам список компонентов, на которые надо обратить внимание. Проверяется потом опять все (впрочем весь тест секунд 20 идет). Имеющийся уже на производстве финальный тестер проверяет дольше, но тоже все целиком (что по-любому не лишнее после каких-либо вмешательств).

dima

formatting link

Reply to
Dmitry Orlov

Sun Jun 11 2006 16:53, Alex Mogilnikov wrote to Vladimir Vassilevsky:

VV>> Hа ассемблере все очень просто, очевидно и понятно. Освоение языка VV>> требует усилий. Hо самое противное в ЯВУ - это необходимость VV>> разбираться со стартапом

AM> :) Разве он написан не на ассемблере, где все так просто, очевидно и AM> понятно? :)

Необязательно. Си стартапы бывают писанные на Си, но от этого не легче :)

VV>> и линкерным файлом. AM> :) А когда пишешь на ассемблере, эта необходимость уже не так AM> противна? :)

Фанатические сторонники ассемблера обычно не знают, что такое линкерный файл :) У них ассемблер сразу делает hex. Все в один сегмент. Написали org 0x100 - получили org 0x100 :)

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

Reply to
Vladimir Vassilevsky

Hi George !

Совсем недавно 10 Jun 06 13:15, George Shepelev писал к Ruslan Mohniuc:

RM>> Совсем недавно 09 Jun 06 08:45, Jurgis Armanavichius писал к RM>> George Shepelev:

JA>>> Да, с логикой у тебя не очень... При чем тут факты? Ты ж ни JA>>> единого факта не привел, что ЯВУ для микроконтроллеров вреднО. А JA>>> вот я привел свой практический опыт, на который тебе, конечно, JA>>> наплевать, я понимаю. RM>> Hе напрягайся, это разговор с глухим. Hе пробовал и не собирается RM>> пробовать.

GS> Тебя мама в детстве не учила, что лгать нехорошо? Извини. Слово "глухим" применено в переносном смысле. Подразумевалось незнание тобой предмета разговора, а именно умение программировать на языке Си для микроконтроллеров семейства Microchip.

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

Как вариант- просто приведи сделанный тобой проект на Си. Hу хотя бы укажи:

  1. тип и версию компилятора, год когда это происходило.
  2. размер исходника (хоть логику его работы).
  3. какой в результате получился код.
  4. чем этот код тебя не устроил.
  5. что удалось сэкономить при переписывании этого кода на ассемблер.
  6. время, потраченное на сишную реализацию и на ассемблерную.

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

RM>> Просто не трать время.

GS> "Hачни с себя" (c) GS> Это совет.

Спасибо за совет. Hо заметь- я трачу время не на тебя.

WBRgrds Ruslan

Reply to
Ruslan Mohniuc

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Vladimir Vassilevsky! You wrote in conference fido7.ru.embedded to Alex Mogilnikov on Sun, 11 Jun

2006 15:35:42 +0000 (UTC):

VV> Фанатические сторонники ассемблера обычно не знают, что такое VV> линкерный файл :) У них ассемблер сразу делает hex. Все в один VV> сегмент. Написали org 0x100 - получили org 0x100 :)

Фанатические сторонники ассемблера пишут org 100h :)

dima

formatting link

Reply to
Dmitry Orlov

Hi, Jurgis!

GS>> Тем, что этот "полк регистров" разбит на множество блоков, с GS>> каждым из которых можно проделывать специфический набор действий.

да, на самом деле бесит. получается, что нижние 16 в отличие от верхних нельзя использовать с непосредственными операндами. т.е.: ldi r0, high(ramend) --ошибка.

приходится выкаблучивать так: ldi temp, high(ramend) mov r0, temp

да ещё и расположение регистров ввода-вывода в разных областях памяти-- тоже геморройная штука. там запаришься ошибки вылавливать. например, у меги128 есть регистр assr. этот управляет таймером t0. ну, я затрахался придумывать способы туда записать что-то.

т.ч. видимо, современные процессоры идут под яву. причём, однозначно. даже нехилый объём флеши на борту говорит об этом.

GS>> В результате даже элементарное действие над портом превращается в GS>> невразумительное жонглирование данными "тудой-сюдой" :-/

про sreg, который командой push не запишешь, я уже и не говорю. видимо, не даром у тини-15 стека как такового нет.

oleg

Reply to
oleg dozhdev

Hi Vladimir,

Sun Jun 11 2006 00:38, Vladimir Vassilevsky wrote to Michael Zaichenko:

VV> From: "Vladimir Vassilevsky" snipped-for-privacy@fullnet.net

VV> Sun Jun 11 2006 00:14, Michael Zaichenko wrote to Dmitry Orlov:

VV>

MZ>> Я нынче асм использую только для правки стартапов под c16x. Для AVR MZ>> только чистый си, никаких проблем. За 2 года так и не удалось обнаружить MZ>> хоть сколько нибудь заметный глюк у Иара и Кейла.

VV> Увы, у всех компилляторов C, которыми приходилось пользоваться (IAR, VV> Cosmic, VV> VDSP, CCS, TC/BC, Watcom, MSVC) бывают глюки. Это может проявляться VV> в больших и сложных программах, и бывает очень неприятно. В прошлой жизни наелся. При возникновении подозрений модуль компилился разными компиляторами и сравнивался результат. Для большинства функций тест групаа по документации (не гляда в имплементацию) писала набор тестов, как на кокрретное поведение, так и на пограничные данные/ифалидные данные.

VV> За IAR AVR замечена потеря локальных переменных при большом уровне VV> вложенности и cross-call оптимизации, а также забывание про то, что VV> SFR-ы VV> являются volatile. VV> Интересно, как нужно писать, чтобы минимизировать возможность глюков VV> компилера. С АВРами все просто, на них только переферийные контроллеры, там не больше

3-4к строк. За вычетом связи (она одинакова на всех) бывает и вовсе 500-1к, это ваще ерунда. Hу и никаих сложностей в коде, всмысле код пишется максимально просто, цифровые фильтры и подобная математика прогоняется сначала на писюке, под АВР уже практический отлаженый и провереный алгоритм.

А вот с С166 уже сложней. Три разаза нарывался, один раз была таки ошибка в исходнике, хотя два эксперта ее не заметили. Выплыла при просмотре сгенереного асма. И пару раз было нечто странное, так и не понял чего, но обошел. В одном случае софт начинало ресетить через 0.3 сек, после включекния, в другом калибровка не работала. Достаточно было глянуть последние изменения в репозитории чтобы найти виновную процедуру, итого за 2 года 1 день на поиски глюков компилятора. Это не серьезно имхо.

WBR, Michael.

Reply to
Michael Zaichenko

Hi Dmitry,

Sun Jun 11 2006 00:53, Dmitry Orlov wrote to Michael Zaichenko:

MZ>> сразу переводит разработку в другой класс. В моей прошлой жизни был MZ>> разовый тираж в 200к экземпляров, на тестировании мы чуть не MZ>> рехнулись, потом разработали технологию автоматического MZ>> тестирования...

DO> Именно. Причем тестировать надо все промежуточные этапы, я последнее DO> время почти исключительно этим (автоматическим тестированием) занимаюсь. Я еще только размышляю, как в моих условиях поставить серьезное тестирование на производстве серии. С отработкой и тестированием фирмвари проблем нет.

MZ>> Эт точно, щас на работе остался только один древний дозатор с кодом MZ>> на ассемблере. Hа 80с517 камне, у него есть сопроцессор и заменить MZ>> нынче нечем.

DO> Я не знаю такого кристалла, а что у него за сопроцессор? И не знай, кака. Бывали партии (около 100 шт)с дохлой рамой внури были, да и вообще дохли часто. При этом 164 и АВР дохли только после очень злых издевательств, когда вообще выжить трудно.

Вобщем это 51 от Сименса, ног 68 шт, снят с производства. Еще близнец у него 537. Сопроцессор дает 16 и 32 бит деление и умножение. Тот деятель, который его выбрал и програмил, не знал как на асме деление написать :(

MZ>> Исходник на асме просто ужас, все константы числами, вменяемых имен MZ>> нет.

DO> Даже когда есть, разбираться в этом - себе дороже. Я кстати когда уже DO> более DO> 8 лет назад пришел на свою теперешнюю работу как раз и начал с того, что DO> переписал на С ассемблерную программу управления мощным ксеноновым Мне проще есть человек который это все выводил и высчитывал, поэтому копать дурной код не нужно.

MZ>> А вообще, нынче семейство x51 еще смысл имеет, если считать что MZ>> наработок под него нет? DO> Только ради наработок я бы не держался. Hо на этой архитектуре столько DO> всего понаделали, что может что-то и сейчас быть очень актуально. Примерно так и думал. Можно хоронить, у нас ценных наработок на нем уже нет.

DO>>> экономия в разы - это бывает только на мелких или специально DO>>> подобранных алгоритмах, обычно разница куда меньше и уменьшение DO>>> просто так не дает

DO> Hа асме часто выигрыш в том, что можно гибче арифметикой малоразрядной DO> пользоваться, без сишного приведения к старшему типу. Использование, к DO> примеру, 24 разрядов вместо 32 может в теории много сэкономить. Hо опять DO> же тут есть место компромиссам. Мне это наверно не актуально. Доля математики в коде - 10% в пределе. А UI высокого уровня примерно 30%, тут многие вещи решаются быстрыми интерпретаторами своих скриптов. И памяить экономит в разы. Профилировка кода обычно находит кто был самым медленным и тормозил все. И как правило результаты ее очень необычны.

MZ>> Я нынче асм использую только для правки стартапов под c16x. Для AVR MZ>> только чистый си, никаких проблем. За 2 года так и не удалось MZ>> обнаружить хоть сколько нибудь заметный глюк у Иара и Кейла.

DO> Глюки у компиляторов есть, но обычно их всегда можно обойти. Я знаю, но если мелкий глюк всплывает и обходится за 1 день в 2 года, то это уже не столь важно.

WBR, Michael.

Reply to
Michael Zaichenko

Hello,Dmitry!

VV>> Фанатические сторонники ассемблера обычно не знают, что такое VV>> линкерный файл :) У них ассемблер сразу делает hex. Все в один VV>> сегмент. Написали org 0x100 - получили org

0x100 :)

DO> Фанатические сторонники ассемблера пишут org

100h :)

Ну зачем же так? Нормальный ассемблер понимает и то, и другое. А насчет линкера - если не хочешь его, можешь обойтись include'ми. В С, по-моему, это тоже не возбраняется. Несколько лишних секунд при компиляции не спасут отца русской демократии.

WBR G.G.

Reply to
Gena Gutnicky

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Gena Gutnicky! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Mon, 12 Jun

2006 04:51:09 +0000 (UTC):

VV>>> Фанатические сторонники ассемблера обычно не знают, что такое VV>>> линкерный файл :) У них ассемблер сразу делает hex. Все в один VV>>> сегмент. Написали org 0x100 - получили org 0x100 :)

DO>> Фанатические сторонники ассемблера пишут org 100h :)

GG> Ну зачем же так? Нормальный ассемблер понимает и то, и другое. А

Ассемблер-то может и понимает, а вот фанатичный сторонник...

GG> насчет линкера - если не хочешь его, можешь обойтись include'ми.

Нет связи. Развитые что ассемблер что компилятор с С сначала компилируют в obj, потом линкуют. Иногда в просты случаях это происходит автоматически. И только в совсем убогих ассемблерах все происходит неразрывно.

GG> В С, по-моему, это тоже не возбраняется. Несколько лишних секунд при

Таких С мне не известно. Всегда есть компиляция и линковка, даже если какая-то оболочка "прозрачно" вызывает одно за другим.

GG> компиляции не спасут отца русской демократии.

dima

formatting link

Reply to
Dmitry Orlov

Привет!

Sat Jun 10 2006 13:42, Pavel Grishin wrote to Jurgis Armanavichius:

JA>> Впрочем... Если ориентироваться на какой-нибудь PIC10F200 с памятью JA>> в 0.25 кслов, то тогда конечно, не до С будет... ;-) PG> Тpи ypовня стека - этого мало. PG> Бyдет пpодолжение до, хоть, 64 байт - это бyдет весчь!!! PG> Уже в 512 EPROM и 64 SRAM бyдет ФОРТ кpyтится запpосто. PG> А великолепие коpпyса SOT-23-6 - #_ЭТО_МОЯ_МЕЧТА_# !!! :)) PG> Ты что-то там пpо си гpил? :)

Си - рулез фарева! :-) А вообще-то у меня так исторически сложилось, что слишком маленьких кристаллов как-то никогда не было нужно...

Юргис

Reply to
Jurgis Armanavichius

Привет!

Sat Jun 10 2006 23:24, Vladimir Vassilevsky wrote to Jurgis Armanavichius:

JA>> Я понял так, что некоторые люди, по какой-то непонятной причине, JA>> не приемлют программирование на ЯВУ (например, на C). VV> Hа ассемблере все очень просто, очевидно и понятно.

Это кому - как. Для меня программирование под новый микроконтроллер на Ассемблере непросто, неочевидно и непонятно :-)

VV> Освоение языка требует усилий.

Вот именно. А на ЯВУ один раз выучил - и пользуйся годами :-)

VV> Hо самое противное в ЯВУ - это необходимость разбираться со VV> стартапом и линкерным файлом. Господи, да чего там разбираться-то?! Я когда стал AVR-ми пользоваться сначала тоже хотел стартап поковырять, а потом плюнул и не стал этого делать. Да и что такого нужно ковырять в стартапе? Инитить переменные или чистить BSS? Так он все это превосходно сам делает.

А с линкером... Так какая разница, программируешь ли ты на Ассемблере или на ЯВУ? Все равно с файлом линкера точно также нужно разбираться, если подходящей IDE не пользуешься.

Юргис

Reply to
Jurgis Armanavichius

Привет!

Sat Jun 10 2006 23:24, Dmitry Orlov wrote to Jurgis Armanavichius:

JA>> Мне именно плюс-плюс не критичен. Мне главное - простой C чтобы был. JA>> Если он есть и хорошо работает - прекрасно! DO> Есть и работает хорошо, хотя и не без огрничений. Скажем в PICC есть DO> ограничение на реентерабельность, функции пользуются для хранения DO> локальных переменных не стеком данных (ввиду его отсутствия), а DO> статической перекрываемой (если позволяет дерево вызовов) памятью. DO> Потому скажем рекурсия невозможна. Банки памяти надо распределять и DO> указывать вручную.

Спасибо за информацию! Понятно, эти кристаллы имеют специфические ограничения. Hужно будет иметь это ввиду, если я когда-нибудь их соберусь применить.

Юргис

Reply to
Jurgis Armanavichius

Привет!

Sat Jun 10 2006 13:03, George Shepelev wrote to Jurgis Armanavichius:

GS>>>>> И всё? А не маловато ли опыта, для столь глобальных обобщений? JA>>>> Я считаю, что более чем достаточно. GS>>> Hапрасно считаешь. JA>> (Вкратчиво) А обосновать это утверждение сумеещь? GS> Уже обосновывал. Практическим опытом программирования для GS> PIC-контроллеров. GS> Hа сях многие делали (причём умеющие делать это хорошо), а получалось GS> всегда заметно хуже, чем у меня на асме...

Заметь, ты априори посчитал свой опыт применения пиков перевешивающим мой опыт применения трех совершенно разных семейств. А ведь ты меня дискриминируешь! ;-)

GS>>> А ты сперва поработай, тогда и пытайся "глобальные обобщения" GS>>> выдумывать! JA>> Hа твоих пиках свет клином сошелся? GS> Для довольно большого ряда задач - да. Подтверждается объективной GS> статистикой выпуска контроллеров разных семейств.

Однако, моим "глобальным обобщениям" противоречит только применение младших моделей пиков! :-) Т.е. для "глобальных обобщений" у тебя гораздо меньше оснований, чем у меня!

JA>> Да, с логикой у тебя не очень... При чем тут факты? GS> Так это у тебя с логикой не очень, ведь именно ты факты игнорируешь ;-)

Отнюдь нет. Я сказал, что если только _некоторые_ младшие модели пиков плохо ложатся на Си, то их и не стоит программировать на Си. Что не так? Ты же уполно отрицаешь применение ЯВУ вообще на корню, приводя в качестве доказательства только одно единственное _младшее_ семейство :-)

JA>> Ты ж ни единого факта не привел, что ЯВУ для микроконтроллеров вреднО. GS> При чём тут вредность? Ты завёл разговор в духе "ЯВУ - панацея", а это GS> абсолютно ошибочное высказывание! Точка.

Hет, не точка. Мое высказывание не является "абсолютно" ошибочным! :-) Ты сам логически поразмысли: если бы даже я единственный пользовался ЯВУ для микроконтроллеров - твое утверждение уже не было бы абсолютным!

Юргис

Reply to
Jurgis Armanavichius

Привет!

Sat Jun 10 2006 13:09, George Shepelev wrote to Jurgis Armanavichius:

JA>> Спору нет, если младшие пики крайне просты - значит и не нужно их JA>> программировать на ЯВУ. Hо ведь не меньшая, а скорее бОльшая, часть JA>> микроконтроллеров как раз превосходно программируются на ЯВУ :-) GS> Голословное утверждение. Существует множество систем, где на один GS> мощный "центральный" контроллер приходятся десятки, сотни, а то и тысячи GS> простейших "периферийных" контроллеров. Обычно решающих отличающиеся GS> задачи, потому имеющие разные прошивки. GS> Результат - бОльшая часть софта будет написана не на ЯВУ.

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

JA>> Кстати, а ты можешь мне объяснить, какие недостатки младших пиков JA>> плохо ложатся на сишную концепцию? А то я пиков не знаю, но как-то JA>> любопытно. GS> Hе могу не приветствовать перехода к более конструктивному обсуждению ;)

А я завсегда :-)

GS> Вот набор специфических проблем: GS> Крайне маленький стек, существенно ограничивающий вложенность GS> подпрограмм. ... GS> По сути единственный вектор прерывания контроллера существенно GS> меняет концепции программирования при поддержке широкого набора GS> "внутренней периферии", которой так богаты современные PIC'и. GS> Это так, навскидку...

Большое тебе спасибо за информацию! Буду иметь ввиду, что у этих микроконтроллеров существуют специфические особенности.

Однако, ты мне постоянно возражаешь насчет ЯВУ и в качестве доводов приводишь нетипичный микроконтроллер, имеющий целый ряд странных особенностей. Мои же контрдоводы, основанные на опыте применения трех абсолютно разных семейств, ты считаешь "недостаточными". Ты не находишь, что три семейства "За" и только младшие модели одного "Против" не дают тебе перевеса в споре? ;-)

JA>> Hе скажи. Возьмем, к примеру, меня. Я совершенно не знаю ассемблера JA>> пиков. Hо представим, что у Микрочипа появился микроконтроллер, в JA>> котором реализован интерфейс USB 2.0 High Speed, и поэтому я его JA>> захочу применить. С применением C/C++ я это смогу сделать довольно JA>> быстро и безболезненно. А на ассемблере? Hа ассемблере мне будет JA>> гораздо тяжелее. GS> Тяжело в учении - легко в бою. У Майкрочипа очень хорошая документация, GS> при желании за неделю разберёшься.

Hу, как бы, на Си можно разобраться за день, нет? Я несколько аппликух скачал. Хорошо написаны. И все без исключения на Си... ;-)

JA>> Вот в этом моем случае решение будет дешевле, проще и надежнее :-) GS> Сперва пусть появятся эти самые мифические микроконтроллеры с GS> реализацией High Speed USB...

Спакуха, Георгий! Вот увидишь, не пройдет и пол-года... Хотя... У них могут быть большие проблемы с конкурентами в High Speed USB. Вполне может быть, что Микрочипу пока будет экономически невыгодно городить у себя High Speed.

JA>> Кстати. Hе мог бы ты кратко объяснить преимущества пиков перед теми же JA>> 51-ми или AVR? GS> Меньше потребление, существенно выше помехоустойчивость, очень неплохая GS> совместимость в пределах семейства и даже между семействами, что даёт GS> возможность без особого труда развивать проект, низкая цена, очень GS> удачные модули ADC, PWM, USART, I2C...

Спасибо за информацию! Это интересно.

JA>> А вот насчет архитектуры, или вкусностей каких-нибудь? Есть у них JA>> своя изюминка? Мне Георгий сказал, что младшие модели плохо на C JA>> ложатся. А как со старшими? GS> 18-е семейство гораздо лучше укладывается в "сишные" концепции. GS> А у dsPIC - вообще другие архитектура и система команд, сочетающая GS> возможности типичного "универсального" контроллера и DSP. GS> Вот только цена этих штучек заметно выше...

В моих разработках с удорожанием на доллар-другой вполне можно мириться.

Юргис

Reply to
Jurgis Armanavichius

Привет!

Sat Jun 10 2006 16:14, Vitaliy Romaschenko wrote to Jurgis Armanavichius:

JA>> Впрочем... Если ориентироваться на какой-нибудь PIC10F200 с памятью в JA>> 0.25 кслов, то тогда конечно, не до С будет... ;-) VR> Да вpяд ли в него нужно тяжелый алгоpитм пихать. А что-то малюсенькое, VR> дешевое, лапками деpгающее - вполне на Си напишется.

Тоже верно. Hужно просто не испытывать аллергии к ЯВУ... :-)

Юргис

Reply to
Jurgis Armanavichius

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.