Embedded OS

Hello, Alexey Boyko !

âÕÄÕ ÄÕÍÁÔØ É ÒÅÛÁÔØ ÐÒÏÂÌÅÍÙ ÐÏ ÍÅÒÅ ÉÈ ÐÏÓÔÕÐÌÅÎÉÑ. ðÏËÁ ÞÔÏ È×ÁÔÁÅÔ. ó Õ×ÁÖÅÎÉÅÍ, äÉÍÁ ïÒÌÏ×.

Hello, Maxim Polyanskiy !

void printh(unsigned int i) { unsigned int d = 0x1000; char c; do { if ((c = i/d) > 9) c += 'A'-10; else c += '0'; putch(c); i %=d; d /= 0x10; } while (d > 0); }

é ÎÅ ÎÁÄÏ ÎÉËÁËÉÈ ÓÔÒÏË "0123456789ABCDEF". ó Õ×ÁÖÅÎÉÅÍ, äÉÍÁ ïÒÌÏ×.

Hello, Alexey Boyko !

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

Мне в открытом виде не попадалось.

Учитывая, что отвечаем мы дома, и читаем тоже, договариваться нам не легче чем любым другим подписчикам.

С уважением, Дима Орлов.

Hello, Anton Abrosimov !

èÏÒÏÛÏ, ÐÒÉ×ÅÄÉ ÔÅËÓÔ _ÎÁ_ÐÁÓËÁÌÅ_ (ÎÅ äÅÌØÆÉ, Ñ ÉÈ ×ÏÏÂÝÅ ÎÅ ÚÎÁÀ), ÒÅÁÌÉÚÕÀÝÉÊ Ó×ÏÊ ×ÁÒÉÁÎÔ Write, ÉÌÉ ÈÏÔÑ ÂÙ printf, É ×ÙÚÏ× ÔÁËÏÊ ÆÕÎËÃÉÉ. ñ ÚÎÁËÏÍ ÔÏÌØËÏ Ó ÍÅÈÁÎÉÚÍÏÍ, ÒÅÁÌÉÚÏ×ÁÎÎÙÍ × objects.formatstr

ó Õ×ÁÖÅÎÉÅÍ, äÉÍÁ ïÒÌÏ×.

Thu Mar 24 2005 13:43, Dima Orlov wrote to Maxim Polyanskiy:

DO> void printh(unsigned int i) DO> if ((c = i/d) > 9) c += 'A'-10; DO> И не надо никаких строк "0123456789ABCDEF".

cmp A, 0x0a ; заём в флаге C subc A, 0x069 da A ; в A имеем HEX-представление, в ASCII

Аналогично, преобразование в десятичную систему выполняется без дорогой операции деления, только сдвигами и сложением с коррекцией. "C" конечно же в пролёте...

bzz

Thu Mar 24 2005 12:00, Alexey Boyko wrote to Alex Mogilnikov:

AA>>>>> sizeof(int)=16. AM>>>> Ох-х-х-х-ренеть!!! Это для какой платформы? AM>> sizeof(int)=8, но ни разу не видел живьем. Или у тебя календарь спешит AM>> (до 1 апреля еще больше недели), или у IAR крыша поехала... AB> Объясни почему тебя так дико возбуждает факт, что у AVR-а int занимает 2 AB> байта?

sizeof вычисляется В БАЙТАХ (точнее -- в char-ах), не в битах. IAR suxx.

bzz

Hello Dima.

24 Mar 05 13:43, you wrote to me:

÷ÏÔ Ñ ÔÅÂÅ É ÄÁÌ ÓÏ×ÅÔ, ËÁË ÒÅÛÁÔØ, ËÏÇÄÁ ÐÏÑ×ÉÔÓÑ. ôÏÌØËÏ É ×ÓÅÇÏ.

Alexey

Hello Dima.

24 Mar 05 13:45, you wrote to me:

Я думал так: Короткий импульс нужной ширины в одном направлении, пауза, потом тоже, но в другом направлении. Фигня будет?

Alexey

Hello Kirill.

24 Mar 05 16:13, you wrote to me:

AA>>>>>> sizeof(int)=16. AM>>>>> ïÈ-È-È-È-ÒÅÎÅÔØ!!! üÔÏ ÄÌÑ ËÁËÏÊ ÐÌÁÔÆÏÒÍÙ? AM>>> sizeof(int)=8, ÎÏ ÎÉ ÒÁÚÕ ÎÅ ×ÉÄÅÌ ÖÉ×ØÅÍ. éÌÉ Õ ÔÅÂÑ ËÁÌÅÎÄÁÒØ AM>>> ÓÐÅÛÉÔ (ÄÏ 1 ÁÐÒÅÌÑ ÅÝÅ ÂÏÌØÛÅ ÎÅÄÅÌÉ), ÉÌÉ Õ IAR ËÒÙÛÁ AM>>> ÐÏÅÈÁÌÁ... AB>> ïÂßÑÓÎÉ ÐÏÞÅÍÕ ÔÅÂÑ ÔÁË ÄÉËÏ ×ÏÚÂÕÖÄÁÅÔ ÆÁËÔ, ÞÔÏ Õ AVR-Á int AB>> ÚÁÎÉÍÁÅÔ 2 ÂÁÊÔÁ? KF> sizeof ×ÙÞÉÓÌÑÅÔÓÑ ÷ âáêôáè (ÔÏÞÎÅÅ -- × char-ÁÈ), ÎÅ × ÂÉÔÁÈ.

á, ÎÕ ÄÁ. ñ ÎÅ ÏÂÒÁÔÉÌ ×ÎÉÍÁÎÉÑ.

KF> IAR suxx.

á ÞÔÏ × IAR - ÎÅ ÔÁË?

Alexey

Wed Mar 23 2005 23:00, Anton Abrosimov wrote to Kirill Frolov:

AA>>>>> А как pеализуется тот-же счетчик ссылок без поддеpжки со AA>>>>> стоpоны компилятоpа? KF>>>> А как он может быть реализован на ассемблере, без поддержки со KF>>>> стороны компилятора паскаля? AA>>> Отвечать невнятным вопpосом на вполне конкpетный вопpос - имхо AA>>> как-то нехоpошо с твоей стоpоны. :) Поясню свой вопpос. Hапpимеp, AA>>> локальной пеpеменной-стpоке пpисвоили значение глобальной стpоки. AA>>> Счетчик должен быть инкpементиpован, что в си вполне можно AA>>> сделать пеpеопpеделением опеpатоpа. Hо пpи выходе из AA>>> области видимости локальной пеpеменной и ее автоматическом AA>>> удалении счетчик нужно декpементиpовать. KF>> Очевидно, суммированием значения счётчика с -1 в нужном месте. AA> Это ты объясняешь, как надо декpементиpовать? Спасибо за очень полезную AA> инфоpмацию, сейчас пойду тpениpоваться. :)

Ответ достойный вопроса.

KF>> Для работы с указателями выполняется ряд нехитрых правил (примечательно, KF>> компилятор LCC имеет такую возможность). AA> Мне интеpесен не пpимечательный компилятоp, а возможность pеализации AA> унивеpсальной библиотеки со счетчиком ссылок.

А ты возьми и почитай как там это сделано. Google --> "мне повезёт" -- это сложно?

AA>>> Как обpаботать это событие? KF>> А почему вы спрашиваете? AA> Hе знаешь - так и скажи. Hичего достойного по 'reference count "c++"' AA> сходу не нашлось.

Потому что вам C++ мозги клинит. ++ -- не значит лучше, вообще ничего не значит.

bzz

Wed Mar 23 2005 20:58, Anton Abrosimov wrote to Kirill Frolov:

KF>> У тебя вообще не паскаль. У тебя или "Турбо паскаль" (по аналогии KF>> с турбо-бейсиком) или Delphi (Visual basic). Общего с паскалем -- KF>> в основном только название... Язык паскаль определяется не скажу KF>> сейчас каким ISO, и никаких описываемых тут возможностей там нет. AA> А если есть? Кто его видел-то, это ISO? :)

Google --> "мне повезёт".

KF>> А ничего, что эти const все разного размера, а стек в паскале KF>> устроен "задом наперёд" по отношению к сишному? Ведь для того, чтобы KF>> можно было достать формат, его нужно записывать последним аргументом KF>> в вызове функции. AA> Hе нужно. Это ж паскаль (хоть ты с этим и не согласен), он должен быть AA> защищен от глупых ошибок типа несовпадения количества объявленых и AA> пеpеданных пеpеменных. Поэтому вместе с массивом пеpедается его pазмеp,

Сам-то понял, что сказал? Функция с ПЕРЕМЕННЫМ числом аргументом защищена от вызова с НЕВЕРНЫМ числом параметров.

AA> адpесоваться к элементам (используя []). А все const одного pазмеpа, т.к. AA> все что больше integer пеpедается по указателю, и именно этим обусловлено AA> тpебование "const". Кстати, в iar для avr pазбоp стека пpи пеpедаче

А как на счёт vprintf?

AA>>> Способен ли этот тpанслятоp пеpеваpить эту констpукцию в "void AA>>> Write(char* Format, ...);" зависит только от его AA>>> сообpазительности. KF>> Ага. Ещё в turbo pascal были ограничения по работе с составными KF>> типами. Сути уже не помню (в ряде случаев возможно применение только KF>> "ordinary" типов). В delphi уже исправили? AA> В 3й дельфе испpавлено не было. А сейчас с такими ньюансами не AA> сталкиваюсь и не знаю, я пpофессионально дельфей давно не занимаюсь и чем AA> отличается 8ая от, к пpимеpу, 5ой, ответить не смогу.

Naprimer, с "C" возможно вернуть из функции структуру. В паскале нельзя. В турбо-паскале.

bzz

Пpивет, George.

Вот что George Shepelev wrote to Michael Belousoff:

GS>>> А для AVR я могy и на ассемблеpе пpогpаммкy сделать (собственно, GS>>> как pаз сейчас делаю), хоть это и не самое пpиятное занятие. MB>> Пожалей себя, бpось какy.

GS> Сигнал нyжно выдавать на ножкy с дискpетностью 50 нс. Ваpиант на AVR GS> пpосто напpашивается...

Ты не понял. Кака - не АВР, кака - его мнемоники. Hе надо писать на асме, надо писать на Си, и ваши yши не бyдyт тёплыми и мягкими. :-) Hо, конечно, не бывает пpавил без исключений, и может потpебоваться что-то написать и на асме. Мне такое пока делать не пpиходилось.

Michael G. Belousoff

mailto: mickbell(dog)r66(dot)ru

... ==== Пpоблемy надо pешать до того, как она появится. ====

Hello, Kirill Frolov !

þÔÏ ÜÔÏ ÚÁ ÔÁÒÁÂÁÒÝÉÎÁ? íÏÊ ËÏÄ ÒÁÂÏÔÁÅÔ ÂÅÚ ÉÚÍÅÎÅÎÉÊ ÎÁ pic16, pic18, AVR, HC08, HC11, LPC51, ST7Lite É ÂÕÄÅÔ ÒÁÂÏÔÁÔØ ÎÁ ÞÅÍ ÕÇÏÄÎÏ ÄÒÕÇÏÍ.

ó Õ×ÁÖÅÎÉÅÍ, äÉÍÁ ïÒÌÏ×.

Hello, Alexey Boyko !

Полная. Тем более, что гораздо проще технически управлять частотой, поставив последовательно с лампой дроссель. У люминисцентных ламп нет проблем с ВЧ питанием.

С уважением, Дима Орлов.

ðÒÉ×ÅÔ Alex! ópÄ íÁp 23 2005 17:15, Alex Mogilnikov -> Anton Abrosimov:

AA>>>> åÓÔØ ×ÁpÉÁÎÔÙ ÅÝÅ ËÏÍÐÁËÔÎÅÅ, ÐpÁ×ÄÁ ÚÁ ÓÞÅÔ ÏÔÓÕÔÓÔ×ÉÑ AA>>>> ÓÏÂÓÔ×ÅÎÎÏ ÆÏpÍÁÔÉpÏ×ÁÎÉÑ. á×ÔÏpÓÔ×Ï - IAR, ×ÁpÉÁÎÔ ÄÌÑ AA>>>> sizeof(int)=16. AM>>> ïÈ-È-È-È-ÒÅÎÅÔØ!!! üÔÏ ÄÌÑ ËÁËÏÊ ÐÌÁÔÆÏÒÍÙ? AA>> âÙÌÏ × ÓÏÓÔÁ×Å EW ÄÌÑ AVR. á ÐpÉÞÅÍ ÚÄÅÓØ ÐÌÁÔÆÏpÍÁ? AM> ôÏÇÄÁ ÔÅÍ ÂÏÌÅÅ ÏÈ-È-ÈÒÅÎÅÔØ. ñ ÚÎÁÀ Ï ÓÕÝÅÓÔ×Ï×ÁÎÉÉ ÓÉÓÔÅÍ Ó AM> sizeof(int)=8, ÎÏ ÎÉ ÒÁÚÕ ÎÅ ×ÉÄÅÌ ÖÉ×ØÅÍ. éÌÉ Õ ÔÅÂÑ ËÁÌÅÎÄÁÒØ ÓÐÅÛÉÔ AM> (ÄÏ 1 ÁÐÒÅÌÑ ÅÝÅ ÂÏÌØÛÅ ÎÅÄÅÌÉ), ÉÌÉ Õ IAR ËÒÙÛÁ ÐÏÅÈÁÌÁ... ôÏÌØËÏ ÞÔÏ ÓÏÏÂpÁÚÉÌ, ÞÔÏ ÔÅÂÑ ÔÁË ÕÄÉ×ÌÑÅÔ. üÔÏ ÐpÏÓÔÏ ÏÞÅÐÑÔËÁ Ó ÍÏÅÊ ÓÔÏpÏÎÙ, ×ÍÅÓÔÏ 16 ÓÌÅÄÕÅÔ ÞÉÔÁÔØ 2. äÏÇÁÄÁÔØÓÑ, ÞÔÏ Ñ ÕËÁÚÁÌ pÁÚpÑÄÎÏÓÔØ × ÂÉÔÁÈ, ÉÍÈÏ ÎÅÓÌÏÖÎÏ.

HÁ ÜÔÏÍ ×ÓÅ, ÐÏËÁ. Anton Abrosimov. ... õÍ ÎÁ ÚÅÍÌÅ - ×ÅÌÉÞÉÎÁ ÐÏÓÔÏÑÎÎÁÑ. á ÎÁÓÅÌÅÎÉÅ-ÔÏ ÒÁÓÔÅÔ!

Hi Oleksandr, hope you are having a nice day!

21 Мар 05, Oleksandr Redchuk wrote to Alexey V Bugrov:

OR> просто будет функцией, оформленной как ISR. Hо если внутри этого foo OR> вызвать любую функцию (os_raise_event, например), то в foo будут OR> сохранены/восстановлены все те регистры, которые для подпрограмм OR> сичтаются временными (вызываемая не обязана сохранять).

Да, это хуже. И нет способа убедить его этого не делать? Если есть, то os_raise_event тоже можно сделать "прерыванием" с точки зрения компилятора, тогда при вызове такой функции можно ничего не сохранять.

WBR, AVB

Hi Harry, hope you are having a nice day!

21 Мар 05, Harry Zhurov wrote to Alexey V Bugrov:

AV>> Т.е. у меня ISR - это не ядро, оно может быть писано на чем AV>> угодно, HZ> В моем понимании ISR - есть кусок кода, асинхронно и _аппаратно_ HZ> вызываемый из основной программы.

Это если подходить к вопросу строго формально. Если немного отсупить от формальностей, то ISR это функция, вызываемая асинхронно по отношению к основной задаче аппартным или программным (т.е. из другой функции, вызванной аппаратно по внешнему событию) способом.

AV>> только вот его вызов перехватывается ядром, которое AV>> делает всю черную работу. HZ> куска (задачи/процесса) основной программы и отдает его другому куску HZ> (задаче/процессу), либо основная программа сама отдает управление ядру HZ> путем вызова ядреной функции (что имеет место внутри HZ> функций сервисов). В этом случае обработчик прерывания - есть часть HZ> ядра.

Да. Только часть обработчика (назовем ее системной) является частью ядра. Еще есть пользовательская часть вызываемая из системной.

AV>> У меня _внутри_ пользовательского ISR никакое перпланирование AV>> невозможно. HZ> Поэтому у тебя реально обработчик прерывания является частью ядра HZ> - т.е. он обладает всеми полномочиями ядра, а из него вызывается HZ> пользовательский код, который ты называешь "пользовательским ISR".

Да. Только из-за того, что реальную работу для пользователя делает именно он.

AV>> Note that OSSched() could be written entirely in assembly language AV>> to reduce scheduling time. OSSched() was written in C for AV>> readability, portability and also to minimize assembly language. HZ> :) То, что может быть написано, никто не сомневается. Только сам HZ> он так не сделал по понятным причинам (что-то у меня большие сомнения, HZ> что его планировшик, переписанный на асме, даст хоть какое-то заметное HZ> преимущество. И я, также, не слышал, чтобы кто-то так делал.

Hу дык. Лень - святое дело. :)

HZ>>> А вектора прерываний ты сам руками вставляешь?

AV>> ;=============================================================== AV>> OS_ISRV_SECT CODE 0x0018 ; адрес вектора прерывания. Сюда AV>> ядро прибито AV>> гвоздями. ;-------------------------------------------------------

[skip]

AV>> level bra _os_exit ; if not zero skip task AV>> scheduler ; _skip_user_isr: ;------------------------------------- AV>> -------------------------- ; тута смотрим надо ли запускать AV>> планировщик и т.д.

HZ> Т.е. этот ассемблерный кусок кода ты руками вставляешь каждый раз HZ> для каждого ISR?

:) У пика один вектор прерывания (точнее два, но высокоприоритеное в рассчет не берем, он специально оставлен мной для hard real time задач, т.к. сохраняет аппаратно часть контекста за один такт и прерывает работу ОС даже в критических секциях).

HZ> Или у тебя там где-то еще есть анализ, какой HZ> именно "пользовательский ISR" вызвать?

Да. Внутри пользовательского ISR. Хотя на практике это выглядит примерно так:

void OS_ISR(void) // OS managed interrupt service routine { if (PIR1bits.CCP1IF) // interrupt from display timer { PIR1bits.CCP1IF = 0; // clear interrupt flag ledskeysProc(); // process leds and keys } if (PIR2bits.CCP2IF) // interrupt from system timer { PIR2bits.CCP2IF = 0; // clear interrupt flag ClrWdt(); // clear watchdog timer OS_ClockTick(); // process OS clock outputProc(); // process relay and pwm outputs auxProc(); // process auxiliary inputs and outputs } if (INTCON3bits.INT2IF) // interrupt from ADC { INTCON3bits.INT2IF = 0; // clear interrupt flag OS_SetEvent(&adc_event); // adc data is ready } if (PIR1bits.TMR2IF) // interrupt from dac timer { T2CONbits.TMR2ON = 0; // turn off timer PIR1bits.TMR2IF = 0; // clear interrupt flag OS_SetEvent(&dac_event); // dac request is complete } }

HZ> А этот код, пользуясь тем, что HZ> вектор один, общий? Если так, то как быть, когда для каждого HZ> обработчика свой вектор? Дублировать руками кучу ассемблерного кода?

Hе обязательно. Все пишется заранее в фиксированных адресах и пакуется в либу. В начале каждого вектора кладем на стек его номер и переходим на общий системный обработчик. В общем системном обработчике можем вызывать нужную функцию по пользовательской таблице векторов. Это один из возможных вариантов.

AV>> Hу и что? Это даже замечательно. От этого сгенерированный код AV>> перестал быть функцией, которая может быть вызвана коммандой call? HZ> Перестал - как ты знаешь, call обычно порождает на выходе ret. А HZ> функция, оформленная как __interrupt на выходе будет иметь reti.

Hу да. Об этом я ниже писал.

AV>> Или вообще не указываешь эту прагму, пусть функция будет там где AV>> она есть, а вектор останется не тронутым. HZ> Это можно. Только компилятор начнет вопить, что, типа, вектор не HZ> указали. Можно, конечно, вопли подавить, но это как-то не очень HZ> кузяво.

Hо возможно. Понимаешь, я не изучал детально платформу AVR и не работал вплотную с GCC в применении к эмбеддед, когда я писал для PIC18, переносимость самой оси не ставилась как цель для всеобщего счастья. Это позволило написать ядро, хорошо (на мой взгляд) адаптированное под платформу и компилятор. Hо портируемоесть ОСи не главное счастье. Желательно сохранить совместимость с API оси на другой платформе, где сама ОС может быть на крайней случай написана заново с учетом особенностей той платформы. Более того, исходники ОС не собираются без специальной самописной утилиты, которая патчит объектники после компилятора (иначе переключение задач сделать невозможно).

BTW, насколько я знаю, полностью работоспособного порта uC/OS для PIC18 не сделали, ибо громоздко и не дружит с компилятором. Тот порт, что есть на сайте - "условно равбочий", применять его на практике нельзя.

HZ> Это немало. AV>> Все остальное несущественно. HZ> Кому как. Что-то мне не улыбается таскать руками пачки HZ> ассемблерного кода, не имеющего отношения к целевому проекту, особенно HZ> учитывая, что в рабочих проектах я уже и забыл, когда последний раз HZ> использовал ассемблер.

Тут опять особенности платформы. У меня в пользовательских функциях (в т.ч. в пользовательских частях ISR) _вообще_ нет кода, связанного с ОС, ни сишного, ни ассемблерного. Сама ОС давно лежит в либе, которая пересобирается только при добавлении новых фич в ядро или исправления ошибок в нем же.

AV>> минус только один: меньшая (не очень значительно) переносимость AV>> кода и чуть-чуть большие накладные расходы на вход/выход AV>> из обработчика.

HZ> А таскание вручную низкоуровневого, не имеющего отношения к HZ> прикладной задаче, кода? И обслуживание его - вызовы-то самих HZ> "пользовательских ISR" надо тоже руками вписывать.

Hет. У них должны быть предопределенные имена. Достаточно написать саму функцию, а линкер ее уже прицепит "куданадо".

HZ> Словом, удобство и HZ> автоматизация еще те! Я бы не отнес это к достоинствам.

Зависит от платформы. Для PIC18 с пользовательской стороны получаем абсолютно прозрачный и платформонезависимый (условно) код, который завязан только на API OS и знать ничего не знает про тонкости управления контекстами и прерываниями на платформе.

HZ> То же самое - в осевых прерываниях смело сигналим флаги, мечем HZ> сообщения и т.д. Hа выходе - перепланирование. AV>> и увеличение скорости обработки прерываний, т.к. HZ> Увеличение скорости имеет место _только_ в случае, если было HZ> осевое прерывание, где семафор не взведен (как в случае приема байтов HZ> в пакете). Когда семафор взводится, никакого выигрыша нет, все ровно HZ> так же.

Да. Hо это не мало.

HZ> А по сравнению с обычным (внеосевым) прерыванием тут только HZ> проигрыш по скорости.

Для PIC18 (опять же) совершенно несущественный, т.к. особенность архитектуры - кол-во сохраняемых регистров в том и другом случае почти идентично.

AV>> Если это допустимо, то и вставить перед выходом из функции AV>> прерывания, сгенерированной компилятором, _asm(ret) труда AV>> не составит (это чтобы подменить reti компилятора). HZ> Hе подменить, а вставить перед. Чтобы уверенно сказать, надо HZ> пробовать.

Должно работать. Hа подавляющем большинстве компиляторов ассемблерная вставка отключает оптимизацию как минимум в пределах текущей функции.

HZ> софтовое прерывание, где так же тупо выбирается наиболее приоритетный HZ> процесс и тупо переключаются контексты. Все. Сама идея мне нравится и HZ> я серьезно подумаю над реализацией (главным образом, над тем, как HZ> формализовать процесс "затачивания" свободного аппаратного прерывания HZ> под софтовое).

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

p.s. Вобщем, я так полагаю, пора тему закрывать. Позиции сторон ясны, взаимопонимание практически достигнуто.

WBR, AVB

Wed Mar 23 2005 11:01, Maxim Polyanskiy wrote to Andy Mozzhevilov:

MP>>> Мало того - я считаю, что это основной ключ к несопровождаемости MP>>> в старых проектах. AM>> Hаличие нескольких файлов? Чего кypил?

MP> Курил твои письма, где ты не можешь внятно и четко объяснить какие MP> проблемы испытываешь при сопровождении своих старых проектов.

Тебе что-либо объяснять бесполезно, так зачем распинаться?

AM>> Это напpямyю относится к тpyдоемкости апдейта софта в pаботающем AM>> девайсе, но совеpшенно не коppелиpyет с тpyдоемкостью сопpовождения AM>> самого софта.

MP> Я не склонен это разделять.

Значит у тебя проблемы с элементарной логикой.

MP> Устройства в которых установленны однократные MP> контроллеры должны разрабатыватся с некоторыми другими подходами и с MP> дугими уровнями ответственности, потому, что там другая цена ошибки.

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

AM>> Это не пpоблема, это дополнительная сложность, когда все валяется в AM>> кyче и кpyтится в фоновом цикле. Сложно пpогнозиpовать, хватает AM>> pеально в этом цикле вpемени, чтобы подбиpать события или нет. Только AM>> не надо опять нyдить пpо пpеpывания.

MP> Да причем тут прерывания - на лицо классическая ошибка разработчика. MP> Ты думаешь о том, о чем нормальные люди вообще не задумываются. MP> Hа момент разработки система работает в упоре производительности (памяти, MP> частоты процессора) и дальнейшее развитие на этом железе либо затрудненно MP> либо не представляется возможным. А такое можно себе позволить только для MP> систем, где развитие вообще не предусмотренно. Когда же ты поймешь, что MP> при нормальный подход к разработке, не тот в котором главенствует MP> переносимость проекта, а тот в котором переносимость в 99% не потребуется MP> совсем. Да вот возьмем твой-же пример, ну стоит у тебя там x51 даллас. MP> Предел помоему у любого такого далласа 32mips. И нафига тебе нужна MP> переносимость? rtos? Если уж переделывать плату - 100mips silabs решит MP> все твои проблеммы в этом проекте на сто лет вперед вообще без каких либо MP> гемороев, и ты не будешь задумыватся о том о чем думаешь. Или тебе MP> обязательно туда поставить другой проц? С rtos? Hеделями все под него MP> переписывать? Это уже активная ртософилия, и полное абстрагирование от MP> решения задачи ради мнимого удобства.

А никто проект переделывать и не собирается. Я сказал, что будь этот проект начат сейчас, подход был бы другой. х51 вообще дурной процессор, даже если его сильно разогнать, он не перестанет быть х51 со всеми его недостатками, при этом поднимаясь в цене значительно выше тех же мелких ARM. Да, переносимость в большинстве случаев не нужна, но применение RTOS преследует совершенно другие цели, а переносимость делается если надо и без RTOS, и с ней.

MP>>> Стоимость - параметр конечного пользователя. Тебя должна MP>>> волновать только прибыль! AM>> Стpанный ты, то тебе FX604 поставить за $5 не пpоблема вместо AM>> pеализации оной же в цифpе, потомy что она "хоpошая" (пpичем тyпо, без AM>> обоснования). То начинаешь копейки считать в чyжих пpоектах и давать AM>> невpазyмительные советы.

MP> Как ты не понимаешь простых вещей. "Экономь, но не на себе" (с) реклама MP> АОС ;) Так вот дело в том, что дерготня ногами, что на асм, что на си - MP> задача одного порядка, выполняемая одними людьми за одни деньги.

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

MP> Реализация же нормального приемника чего либо, сравнимого с FX.. - задача MP> совсем другого порядка, выполняемого другими людьми, за другие деньги.

Какими другими, за какие деньги? Если речь идет о FX604, то на том же филипсовском LPC не особо напрягаясь я реализовал работоспособный модем V23 менее, чем за неделю, одновременно осваивая сам ARM и компилятор Си для него.

MP> Поэтому экономить доллар на процессоре можно, а 5 на FX - нельзя!

Можно также не экономить доллар на uC, зато сэкономить $5 на FX, результат будет один, зато при меньшей цене.

MP> Ты MP> конечно можешь сколько угодно переписыватся с Василевским на MP> общетеоретические вопросы алгоритмических решений, или прочитать примерно MP> то-же самое в любой книжке по ЦОС, но основная проблема ждет тебя не в MP> алгоритме решения, а в том как этот алгоритм эфективно положить на MP> контроллер.

Hечего там особо перекладывать. Алгоритм отлаживается полностью в матлабе, включая разрядность АЦП, целевой архитектуры, и прочие мелочи.

MP> Так вот в конечном счете, ты или поймешь цену гемороя, или MP> возьмешь контроллер на 5 баксов дороже, просто потратив кучу своего MP> времени.

Hа данный момент у меня есть LPC, который стОит менее $5. По вычислительным ресурсам модемство V23 в лоб в нем занимает не более 30% производительности на 60 мипсах. PSK модемство по вычислениям заметно скромнее.

MP> Третий вариант - родишь нечто фуфельное, рядом не стоящее с FX, MP> и потом сам себя будешь убеждать, что это круто и все такое.

Я работаю не только для собственного удовольствия. Либо устройство соответствует заданным параметрам, либо нет. Hикаких других критериев не существует. А про FX604 ты так и не смог сказать, какие параметры в ней приводят тебя в такой восторг?

AM>> Я в одном из писем yточнил и подчеpкнyл AM>> _если_не_нyжно_микpопотpебление_

MP> Да не причем тут микропотребление. Просто есть задачи где хочется MP> схалявить. MP> Hапример офигенная штука - эмуляция TL494 на PIC10F204,

Ты точно как Шепелев. "А бывает, что нужно...", "Есть задачи..." Бывает, есть, и что, я где то сказал, что нужно засунуть ARM вместо PIC12c508?

MP>>> Hикаких. У меня как правило память внешняя. Захочу - повешу на MP>>> лишний CS паралельную 28с64. AM>> Пpичем здесь 2864 и как она относится к i2c?

MP> Так-же как ARM к PIC-у.

В линейке PIC-ов очень много разных uC, мелкого и среднего класса. Те, что среднего, вполне можно сравнить с LPC, тем более они в одной ценовой категори.

AM>> Это бpедни pадиолюбителя в плохом смысле этого слова. AM>> Все всегда сколько нибyдь стоит.

MP> Программные FFSK приемники сопоставимые с FX стоят от 700$...

Где стоят? Даже если так - то затраченные $700 окупяться при тираже в 100 штук, то есть мелкая установочная партия.

MP>>> питанию не повесишь работают только в макетах. Зато у нас теперь MP>>> разводчик pdf читает. AM>> Так с этого надо было начинать. Может и тебе yже поpа тyда AM>> заглядывать?

MP> Hичего не знаю - все в сад! Hа макете все работает. Hе гоже программеру MP> решать аппаратные проблемы.

Значит ищи дальше эти аппаратные глюки в своей программе.

wbr, Andy

Hello Kirill!

20.03.2005 3:26:40, Kirill Frolov wrote to Dmitri Litovchenko:

KF>

KF> äÁ ÚÄpÁ×ÓÔ×ÕÅÔ æÏpÔpÁÎ !

HÉËÏÌÁÊ òÏÄÉÏÎÏ×

HÁÐÉÓÁÔØ ÜÔÏÔ ÏÐÕÓ ÍÅÎÑ ÐÏÂÕÄÉÌÁ ÓÔÁÔØÑ "HÁÓÔÏÑÝÉÅ ÐpÏÇpÁÍÍÉÓÔÙ ÎÅ ÉÓÐÏÌØÚÕÀÔ ðÁÓËÁÌØ" × ÖÕpÎÁÌÅ "Datamation". á×ÔÏp ÜÔÏÊ ÓÔÁÔØÉ - ÎÁÓÔÏÑÝÉÊ ÈÁËÅp, É ÍÎÅ ÎÅ ÈÏÔÅÌÏÓØ ÂÙ, ÞÔÏÂÙ "ÍÏÅ" ÓpÁ×ÎÉ×ÁÌÉ Ó "ÅÇÏ", ÐÏÓËÏÌØËÕ ÅÇÏ ÕpÏ×ÅÎØ ÎÁ ÎÅÓËÏÌØËÏ ÐÏpÑÄËÏ× ×ÙÛÅ.

- 1 -

ëÁËÉÍ ÎÁÄÏ ÂÙÔØ ×ÙÓÏËÏÍÅpÎÙÍ ÉÄÉÏÔÏÍ ÄÌÑ ÔÏÇÏ, ÞÔÏÂÙ ÉÚÏÂpÅÓÔÉ ÏÂÕÞÁÀÝÉÊ ÑÚÙË ÔÁËÉÍ, ËÁË ðÁÓËÁÌØ. ÷ÓÅ ÕÞÅÎÉËÉ É ÐÏÓÌÅÄÏ×ÁÔÅÌÉ HÉËÌÁÕÓÁ ÷ÉpÔÁ ÂÕÄÕÔ ×ÅÌÉËÏÌÅÐÎÏ ÞÉÔÁÔØ ËÏÍÍÅÎÔÁpÉÉ É ÐÏÎÉÍÁÔØ, ÞÔÏ BEGIN ÚÎÁÞÉÔ Háþáìï, Á END - ëïHåã. Á ÂÏÌØÛÅÅ ÐÏÔÑÎÕÔØ ÏÎÉ ÎÅ ÓÍÏÇÕÔ. åÓÌÉ ÕÖ ËÏÍÕ-ÔÏ × ÇÏÌÏ×Õ ÐpÉÛÌÏ, ÞÔÏ ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÀ ÎÁÄÏ ÕÞÉÔØ ÎÁ ÑÚÙËÁÈ ×ÙÓÏËÏÇÏ ÕpÏ×ÎÑ, ÔÏ ÄÌÑ ÜÔÏÊ ÃÅÌÉ ÍÏÖÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ æïòô, × ËpÁÊÎÅÍ ÓÌÕÞÁÅ óé (ÅÓÌÉ ÎÅ ×ÙÄÅÌÑÔØ × ÎÅÍ ÐpÉÅÍÙ ÓÔpÕËÔÕpÎÏÇÏ ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÑ). ÷ ÜÔÏÍ ÓÌÕÞÁÅ, ÐÏ ËpÁÊÎÅÊ ÍÅpÅ, ÐpÉÄÅÔÓÑ ÐpÉÌÏÖÉÔØ ÍÏÚÇÏ×ÙÅ ÕÓÉÌÉÑ ÄÌÑ pÅÛÅÎÉÑ ÔÏÊ ÉÌÉ ÉÎÏÊ ÚÁÄÁÞÉ. ñÚÙË ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÑ, ËÏÔÏpÙÊ Ó×ÏÉÍÉ ÓpÅÄÓÔ×ÁÍÉ ÎÅ ÓÐÏÓÏÂÅÎ ×Ù×ÅÓÔÉ ÉÚ ÓÔpÏÑ ÓÉÓÔÅÍÕ, ÎÅ ÍÏÖÅÔ ÓÞÉÔÁÔØÓÑ ÇÉÂËÉÍ É ÎÅ ÄÏÌÖÅÎ ÓÞÉÔÁÔØÓÑ ÑÚÙËÏÍ ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÑ ×ÏÏÂÝÅ.

HÁ ÓÁÍÏÍ ÄÅÌÅ ÄÌÑ ×ÏÓÐÉÔÁÎÉÑ ÈÏpÏÛÉÈ ÐpÏÇpÁÍÍÉÓÔÏ× ÎÅÏÂÈÏÄÉÍÏ ÐpÅÐÏÄÁ×ÁÔØ × ËÁÞÅÓÔ×Å ÏÂÕÞÁÀÝÅÇÏ ÑÚÙËÁ áÓÓÅÍÂÌÅp, ÐpÉÞÅÍ ÎÅ ÏÄÉÎ, Á ÎÅÓËÏÌØËÏ (ÅÓÔÅÓÔ×ÅÎÎÏ, Ó ×ÏÚÍÏÖÎÏÓÔØÀ Ó×ÏÂÏÄÎÏÇÏ Ô×ÏpÞÅÓÔ×Á ÎÁ ÄÁÎÎÏÍ áÓÓÅÍÂÌÅpÅ). ôÏÇÄÁ ÂÕÄÕÝÉÊ ÐpÏÇpÁÍÍÉÓÔ ÓÔÏÌËÎÅÔÓÑ Ó pÅÁÌØÎÙÍÉ ÕÓÌÏ×ÉÑÍÉ.

äÌÑ ÔÏÇÏ, ÞÔÏÂÙ ÏÔÄÅÌÉÔØ ÐÏÔÅÎÃÉÁÌØÎÙÈ ÐpÏÇpÁÍÍÉÓÔÏ× ÏÔ ÓÏÓÕÎËÏ×, ÎÕÖÎÏ ÎÁ ÓÁÍÏÊ pÁÎÎÅÊ ÓÔÁÄÉÉ ÏÂÕÞÅÎÉÑ ÐÏÓÁÄÉÔØ ÇpÕÐÐÕ ÚÁ ÔÅpÍÉÎÁÌÙ É ÐÏÓÍÏÔpÅÔØ, ÞÅÍ ËÁÖÄÙÊ ÉÚ ÎÉÈ ÂÕÄÅÔ ÚÁÎÉÍÁÔØÓÑ. óÏÓÕÎÏË ÂÕÄÅÔ ÉÓÐpÁ×ÎÏ pÅÛÁÔØ ÐÏÓÔÁ×ÌÅÎÎÕÀ ÐpÅÐÏÄÁ×ÁÔÅÌÅÍ ÚÁÄÁÞÕ, Á ÐÏÔÅÎÃÉÁÌØÎÙÊ ÎÁÓÔÏÑÝÉÊ ÐpÏÇpÁÍÍÉÓÔ ÚÁÌÅÚÅÔ × ÍÁÛÉÎÕ ÕÞÉÔÅÌÑ, ×ÙÔÁÝÉÔ ÏÔÔÕÄÁ ôåôòéó, ÚÁ 3 ÍÉÎÕÔÙ ÄÏ ËÏÎÃÁ ÚÁÎÑÔÉÑ Ó×ÏpÕÅÔ ÐpÏÇpÁÍÍÕ Õ ÓÏÓÅÄÁ É ÉÓÐpÁ×ÉÔ × ÓÏÏÔ×ÅÔÓÔ×ÉÉ ÓÏ Ó×ÏÉÍ ÚÁÄÁÎÉÅÍ. ÷ÔÏpÏÇÏ ÓÍÅÌÏ ÍÏÖÎÏ ÐÏÄÐÕÓËÁÔØ Ë ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÀ. ðÅp×ÏÇÏ ÌÕÞÛÅ ÏÔÐpÁ×ÉÔØ ÉÚÕÞÁÔØ ðÁÓËÁÌØ, É ÔÁË, ÞÔÏÂÙ ÏÎ ÚÁÎÉÍÁÌÓÑ ÜÔÉÍ ËÁË ÍÏÖÎÏ ÄÏÌØÛÅ. ìÕÞÛÅ ×ÓÅÇÏ - ×ÓÀ ÖÉÚÎØ. ÷ÙÄÅÌÉ× ÂÕÄÕÝÉÈ ÐpÏÇpÁÍÍÉÓÔÏ×, ÏÂÕÞÁÔØ ÉÈ ÍÏÖÎÏ ÐÏ pÁÚÎÏÍÕ. HÁÉÂÏÌÅÅ ÜÆÆÅËÔÉ×ÅÎ ÓÌÅÄÕÀÝÉÊ ÓÐÏÓÏÂ. õÞÅÎÉËÕ ×ÙÄÁÅÔÓÑ ËÏÍÐØÀÔÅp É ÎÅËÏÔÏpÏÅ ËÏÌÉÞÅÓÔ×Ï ÐpÏÇpÁÍÍÎÙÈ ÓpÅÄÓÔ×, Ó ËÏÔÏpÙÍÉ ÅÍÕ × ÄÁÌØÎÅÊÛÅÍ ÐpÉÄÅÔÓÑ pÁÂÏÔÁÔØ. ïÐÉÓÁÎÉÊ Ë ÜÔÉÍ ÐpÏÇpÁÍÍÁÍ ÌÉÂÏ ÎÅ ×ÙÄÁÅÔÓÑ ÓÏ×ÓÅÍ, ÌÉÂÏ ×ÙÄÁÅÔÓÑ ÍÉÎÉÍÁÌØÎÙÊ ÎÁÂÏp. åÓÌÉ ÐpÏÉÓÈÏÄÉÔ ÏÂÕÞÅÎÉÅ ËÁËÏÍÕ-ÌÉÂÏ ÑÚÙËÕ ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÑ, × ËÁÞÅÓÔ×Å pÕËÏ×ÏÄÓÔ×Á ÖÅÌÁÔÅÌØÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ ÌÉÔÅpÁÔÕpÕ ÎÁ ÑÚÙËÅ, ÚÁ×ÅÄÏÍÏ ÎÅÚÎÁËÏÍÏÍ ÏÂÕÞÁÀÝÅÍÕÓÑ, ÌÉÂÏ ÐpÏÉÚ×ÅÄÅÎÉÑ ÓÏ×ÅÔÓËÉÈ Á×ÔÏpÏ×. ëÏÇÄÁ ÂÕÄÅÔ ÚÁÍÅÞÅÎÏ, ÞÔÏ ÕÞÅÎÉË pÁÂÏÔÁÅÔ Ó ÐpÏÇpÁÍÍÏÊ (ÑÚÙËÏÍ ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÑ) ÄÏ×ÏÌØÎÏ ÓÎÏÓÎÏ, ÍÏÖÎÏ ÐpÅÄÌÏÖÉÔØ ÅÍÕ ÄÌÑ ÉÚÕÞÅÎÉÑ ÉÓÞÅpÐÙ×ÁÀÝÉÅ pÕËÏ×ÏÄÓÔ×Á. ïÎÉ ÂÕÄÕÔ ÐpÏÞÉÔÁÎÙ ËÁË ÚÁÈ×ÁÔÙ×ÁÀÝÉÊ ÄÅÔÅËÔÉ×. úÁÔÅÍ, ÐÏÓÌÅ ÎÅÂÏÌØÛÏÇÏ ÐÅpÉÏÄÁ ÐÅpÅ×ÁpÉ×ÁÎÉÑ ÐÏÌÕÞÅÎÎÙÈ ÚÎÁÎÉÊ, ÐpÏÇpÁÍÍÉÓÔ ÇÏÔÏ× Ë ÁËÔÉ×ÎÏÊ ÄÅÑÔÅÌØÎÏÓÔÉ.

- 2 -

óÐÅÃÉÁÌÉÓÔ, ÐpÏÛÅÄÛÉÊ ÏÂÕÞÅÎÉÅ ÐÏÄÏÂÎÙÍ ÏÂpÁÚÏÍ, ËÁË ÐpÁ×ÉÌÏ, ÕÄÉ×ÌÑÅÔ ÄpÕÇÉÈ "ÐpÏÇpÁÍÍÉÓÔÏ×" ÐpÉÅÍÁÍÉ ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÑ. HÅ ÉÓËÌÀÞÅÎÏ, ÞÔÏ ×ÍÅÓÔÏ ÛÅÓÔÎÁÄÃÁÔÉpÉÞÎÏÊ ÓÉÓÔÅÍÙ ÓÞÉÓÌÅÎÉÑ ÏÎ ÂÕÄÅÔ ÉÓÐÏÌØÚÏ×ÁÔØ ÄÅÓÑÔÉÞÎÕÀ (ÅÓÌÉ ÅÍÕ ÄÏ ÐpÏÈÏÖÄÅÎÉÑ ËÕpÓÁ ÎÉËÔÏ ÎÅ ÏÂßÑÓÎÑÌ, ÞÔÏ ÐpÏÇpÁÍÍÉpÏ×ÁÔØ ÎÕÖÎÏ × ÛÅÓÔÎÁÄÃÁÔÉpÉÞÎÏÊ ÓÉÓÔÅÍÅ). ðpÏÇpÁÍÍÙ, ÎÁÐÉÓÁÎÎÙÅ ÔÁËÉÍ ÓÐÅÃÉÁÌÉÓÔÏÍ, ÂÕÄÕÔ ÓÏ×ÅpÛÅÎÎÙ × pÁÂÏÔÅ, ÎÏ ÐÅpÅÄ ÖÅÌÁÀÝÉÍ ÉÈ ÕÌÕÞÛÉÔØ ÉÌÉ ÕÚÍÅÎÉÔØ ×ÓÔÁÎÅÔ ÐpÁËÔÉÞÅÓËÉ ÎÅpÁÚpÅÛÉÍÁÑ ÚÁÄÁÞÁ (ÚÁ ÉÓËÌÀÞÅÎÉÅÍ ÓÌÕÞÁÅ×, ËÏÇÄÁ Ó ÜÔÏÊ ÚÁÄÁÞÅÊ ÓÔÁÌËÉ×ÁÅÔÓÑ ÔÁËÏÊ ÖÅ ÓÐÅÃÉÁÌÉÓÔ), ÔÁË ËÁË ÐpÏÞÉÔÁÔØ ÜÔÉ ÐpÏÇpÁÍÍÙ É ÐÏÎÑÔØ ÉÈ ÓÕÔØ ËpÁÊÎÅ ÔÑÖÅÌÏ, ÎÁÐpÉÍÅp, ÎÅÌÅÇËÏ ÏÂÙÞÎÏÍÕ ÐpÏÇpÁÍÍÉÓÔÕ ÐpÏÞÉÔÁÔØ ÐpÏÇpÁÍÍÕ ÎÁ áÓÓÅÍÂÌÅpÅ, × ËÏÔÏpÏÊ ×ÓÅ ÞÉÓÌÁ - ÄÅÓÑÔÉÞÎÙÅ. ðpÏÇpÁÍÍÉÓÔ, ÉÚÕÞÁ×ÛÉÊ ÔÁËÉÍ ÓÐÏÓÏÂÏÍ áÓÓÅÍÂÌÅp, ÎÁ×ÅpÎÑËÁ ÚÎÁÅÔ ËÏÄÙ ×ÓÅÈ ÍÎÅÍÏÎÉË × ×ÏÓØÍÅpÉÞÎÏÊ, ÄÅÓÑÔÉÞÎÏÊ É ÛÅÓÔÎÁÄÃÁÔÉpÉÞÎÏÊ ÓÉÓÔÅÍÅ ÓÞÉÓÌÅÎÉÑ É ÍÏÖÅÔ ÐÉÓÁÔØ ÐpÏÇpÁÍÍÙ ÅÍËÏÓÔØÀ ÄÏ ÎÅÓËÏÌØËÉÈ ËÉÌÏÂÁÊÔ ÎÅÐÏÓpÅÄÓÔ×ÅÎÎÏ × ÍÁÛÉÎÎÏÍ ËÏÄÅ, ××ÏÄÑ ÐpÏÇpÁÍÍÕ ÄÅÓÑÔÉÞÎÙÍÉ ÉÌÉ ÛÅÓÔÎÁÄÃÁÔÉpÉÞÎÙÍÉ ÞÉÓÌÁÍÉ. ÷ÏÏÂÝÅ ÇÏ×ÏpÑ, ÐpÏÇpÁÍÍÉÓÔÏ×, ÐÏÄÇÏÔÏ×ÌÅÎÎÙÈ ÔÁËÉÍ ÏÂpÁÚÏÍ, ÍÏÖÎÏ É ÄÏÌÖÎÏ ÎÁÚÙ×ÁÔØ ÈÁËÅpÁÍÉ. ÷ ÓÌÏ×Ï ÈÁËÅp ×ÌÏÖÅÎ ÏÔpÉÃÁÔÅÌØÎÙÊ ÓÍÙÓÌ (ÐÏÞÅÍÕ - ÏÂßÑÓÎÀ ÎÉÖÅ), ÎÏ ËÁÖÄÙÊ ÉÚ ÎÉÈ ÇÏpÄÏ ÎÏÓÉÔ Ó×ÏÅ ÉÍÑ. èÁËÅpÁ ÎÅ ×ÏÌÎÕÅÔ ÓÌÏÖÎÏÓÔØ ÐÏÓÔÁ×ÌÅÎÎÏÊ ÚÁÄÁÞÉ, ÎÏ ÚÁÎÉÍÁÔØÓÑ ÅÀ ÏÎ ÂÕÄÅÔ ÔÏÌØËÏ × ÔÏÍ ÓÌÕÞÁÅ, ÅÓÌÉ ÏÎÁ ÅÍÕ ÉÎÔÅpÅÓÎÁ. úÁÓÔÁ×ÉÔØ ÈÁËÅpÁ pÁÂÏÔÁÔØ ×ÎÅ ÅÇÏ ÉÎÔÅpÅÓÏ× ÄÏÓÔÕÐÎÏ ÌÉÛØ ÉÓËÌÀÞÉÔÅÌØÎÏ ÔÁÌÁÎÔÌÉ×ÙÍ ÏpÇÁÎÉÚÁÔÏpÁÍ.

HÁÉÂÏÌÅÅ ÉÎÔÅpÅÓÎÁÑ ÏÂÌÁÓÔØ ÄÌÑ ÈÁËÅpÁ - ÜÔÏ ÐpÏÇpÁÍÍÙ Ó ÚÁÝÉÔÁÍÉ. óÎÑÔÉÅ ÚÁÝÉÔ

- ÜÔÏ ÏÄÎÁ ÉÚ ÓÌÏÖÎÅÊÛÉÈ ÚÁÄÁÞ, Ó ËÏÔÏpÏÊ ÍÏÖÅÔ ÓÔÏÌËÎÕÔØÓÑ ÐpÏÇpÁÍÍÉÓÔ. ìÀÂÏÍÕ ÐÏÎÑÔÎÏ, ÞÔÏ ÎÉ ÏÄÎÏÍÕ ÓÏÓÕÎËÕ, pÁÔÕÀÝÅÍÕ ÚÁ ÓÔpÕËÔÕpÎÏÅ ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÅ, ÜÔÁ ÐpÏÂÌÅÍÁ ÎÅ ÐÏ ÓÉÌÁÍ, ÄÌÑ ÜÔÏÇÏ ÎÅÏÂÈÏÄÉÍ ÔÁÌÁÎÔ.

÷ ÓÏ×ÅÔÓËÉÈ ÕÓÌÏ×ÉÑÈ ÈÁËÅp ÎÅÏÂÈÏÄÉÍ ÐÏ ÔÏÊ ÐpÏÓÔÏÊ ÐpÉÞÉÎÅ, ÞÔÏ ÐÏÊÔÉ × ÍÁÇÁÚÉÎ É ËÕÐÉÔØ ÄÉÓËÅÔÕ Ó ÐÁËÅÔÏÍ P-CAD ÄÌÑ IBM PC ×ÅÓØÍÁ ÚÁÔpÕÄÎÉÔÅÌØÎÏ, ÐÏÜÔÏÍÕ ÐpÉÈÏÄÉÔÓÑ ÅÇÏ ×ÏpÏ×ÁÔØ. ó×ÏpÏ×ÁÔØ ÐpÏÇpÁÍÍÕ ÂÅÚ ÈÁËÅpÁ ÎÅ×ÏÚÍÏÖÎÏ, ÔÁË ËÁË ÐpÁËÔÉÞÅÓËÉ ÌÀÂÁÑ ÆÉpÍÅÎÎÁÑ ÄÉÓËÅÔÁ ÉÌÉ ËÁÓÓÅÔÁ ÚÁÝÉÝÅÎÁ ÏÔ ËÏÐÉpÏ×ÁÎÉÑ. úÁÇÎÉ×ÁÀÝÉÈ ÐpÅÄÐpÉÎÉÍÁÔÅÌÅÊ ÓÌÏ×Ï ÈÁËÅp ÐpÉ×ÏÄÉÔ × ÕÖÁÓ, ÎÏ Ñ ÄÅÌÁÀ pÁÚÌÉÞÉÅ ÍÅÖÄÕ ÈÁËÅpÏÍ É ËÏÍÐØÀÔÅpÎÙÍ ÐÉpÁÔÏÍ (ÔÅpÍÉÎ SOFTWARE PIRACY ×ÐÏÌÎÅ ÏÆÉÃÉÁÌÅÎ É Ñ×ÌÑÅÔÓÑ ÐpÅÄÍÅÔÏÍ ÐpÉÓÔÁÌØÎÏÇÏ ×ÎÉÍÁÎÉÑ éHôåòðïìá). HÅ ÉÓËÌÀÞÅÎÏ, ÞÔÏ ÈÁËÅp ÍÏÖÅÔ ÚÁÎÉÍÁÔØÓÑ pÁÓÐpÏÓÔpÁÎÅÎÉÅÍ ÐpÏÇpÁÍÍ, Ó ËÏÔÏpÙÈ ÓÎÑÌ ÚÁÝÉÔÙ, ÎÏ ÜÔÏ ÈÁpÁËÔÅpÉÚÕÅÔ ÅÇÏ ËÁË ÞÅÌÏ×ÅËÁ, ÎÏ ÎÅ ËÁË ÐpÏÇpÁÍÍÉÓÔÁ. åÝÅ ÂÏÌØÛÅ ÏÔpÉÃÁÔÅÌØÎÙÈ ÜÍÏÃÉÊ (× ÏÓÎÏ×ÎÏÍ Õ ÔÅÈ, ËÔÏ ÐÏÌØÚÕÅÔÓÑ ×ÏpÏ×ÁÎÎÙÍÉ ÐpÏÇpÁÍÍÁÍÉ, Ô.Å. Õ ÓÏ×ÅÔÓËÉÈ ÐpÏÇpÁÍÍÉÓÔÏ×) ×ÙÚÙ×ÁÀÔ ÈÁËÅpÙ, ÚÁÎÉÍÁÀÝÉÅÓÑ ÉÚÇÏÔÏ×ÌÅÎÉÅÍ pÁÚÎÏÇÏ pÏÄÁ ×ÉpÕÓÏ×.

- 3 -

HÁÄÏ ÚÁÍÅÔÉÔØ, ÞÔÏ ÄÌÑ ÈÁËÅpÁ ÎÅ ÍÅÎÅÅ ÉÎÔÅpÅÓÎÙ É ÚÁÄÁÞÉ, ÏÂpÁÔÎÙÅ ÐpÅÄÙÄÕÝÉÍ, Á ÉÍÅÎÎÏ, ÉÚÏÂpÅÔÅÎÉÅ ÚÁÝÉÔ É ÎÁÐÉÓÁÎÉÅ ÁÎÔÉ×ÉpÕÓÏ× (ÔÏ-ÅÓÔØ ÐpÏÇpÁÍÍ, ×ÙÓÌÅÖÉ×ÁÀÝÉÈ É ÕÎÉÞÔÏÖÁÀÝÉÈ ×ÉpÕÓÙ), ÐÏÓÅÍÕ ÆÉpÍÙ, ÐpÏÉÚ×ÏÄÑÝÉÅ ÐpÏÇpÁÍÍÎÙÊ ÐpÏÄÕËÔ, ÎÅ ÇÎÕÛÁÀÔÓÑ ÎÉÞÅÍ, ÞÔÏÂÙ ÐÏÌÕÞÉÔØ ÈÁËÅpÁ ÓÅÂÅ × ÓÏÔpÕÄÎÉËÉ. ÷ÏÏÂÝÅ ÇÏ×ÏpÑ, ÌÀÂÁÑ ÆÉpÍÁ, ÚÁÎÉÍÁÀÝÁÑÓÑ ÐpÏÇpÁÍÍÎÙÍÉ pÁÚpÁÂÏÔËÁÍÉ, pÁÚ×ÁÌÉÔÓÑ, ÅÓÌÉ ÎÁ ÎÅÅ ÎÅ ÂÕÄÅÔ pÁÂÏÔÁÔØ ÎÅÓËÏÌØËÏ ÈÁËÅpÏ×.

ôÅÐÅpØ pÑÄ ÛÔpÉÈÏ×, ÈÁpÁËÔÅpÉÚÕÀÝÉÈ ÈÁËÅpÁ:

• ËÁË ÕÖÅ ÇÏ×ÏpÉÌÏÓØ, ÈÁËÅpÁ ÔpÕÄÎÏ ÚÁÓÔÁ×ÉÔØ pÁÂÏÔÁÔØ, ÎÏ ÅÓÌÉ ÅÇÏ ÚÁÉÎÔÅpÅÓÏ×ÁÔØ, ÔÏ pÅÚÕÌØÔÁÔ ÐÏÞÔÉ ×ÓÅÇÄÁ - ÛÅÄÅ×p;

• ÈÁËÅpÕ ÔÑÖÅÌÏ ÞÔÏ-ÌÉÂÏ ÎÁÞÁÔØ, ÎÏ ÕÊÄÑ × pÁÂÏÔÕ, ÏÎ ÐÏÔÅpÑÎ ÄÌÑ ÏÂÝÅÓÔ×Á ×ÐÌÏÔØ ÄÏ ÚÁ×ÅpÛÅÎÉÑ ÔÏÊ ÉÌÉ ÉÎÏÊ ÓÔÁÄÉÉ;
• ÐpÉ ×ÙÂÏpÅ ÐpÏÇpÁÍÍÎÙÈ ÓpÅÄÓÔ× ÄÌÑ Ó×ÏÅÊ ÄÅÑÔÅÌØÎÏÓÔÉ ÈÁËÅp ÞÁÓÔÏ ÕÄÉ×ÌÑÅÔ ÄpÕÇÉÈ ÐpÏÇpÁÍÍÉÓÔÏ×. ëÁË ÐpÁ×ÉÌÏ, ÜÔÏ ÏÐpÅÄÅÌÑÅÔÓÑ ÎÅ ÔÅÍ, ÞÔÏ ÐpÏÇpÁÍÍÁ ÕÍÅÅÔ, Á ÔÅÍ, ËÁË ÏÎÁ ÎÁÐÉÓÁÎÁ (ÜÔÏÔ ÔÅËÓÔ, ÎÁÐpÉÍÅp, ÎÁÂÉpÁÅÔÓÑ × ÔÅËÓÔÏ×ÏÍ pÅÄÁËÔÏpÅ, ÎÉËÏÉÍ ÏÂpÁÚÏÍ ÎÅ Ó×ÑÚÁÎÎÙÍ Ó pÕÓÓËÉÍ ÑÚÙËÏÍ, ÎÏ ÕÖ ÏÞÅÎØ pÅÄÁËÔÏp ÈÏpÏÛ);
• ×ÓÅ, ÞÔÏ ÈÁËÅp ÄÅÌÁÅÔ, ÏÎ ÎÅ ÓÞÉÔÁÅÔ pÁÂÏÔÏÊ, É ÅÓÌÉ ÆÉpÍÁ ÐÌÁÔÉÔ ÅÍÕ ÄÅÎØÇÉ, ÔÏ, ×ÅpÏÑÔÎÏ, ÔÏÌØËÏ ÄÌÑ ÔÏÇÏ, ÞÔÏÂÙ ÏÎ ÉÎÏÇÄÁ ÐpÏÉÚÎÏÓÉÌ ÆpÁÚÕ: "ñ pÁÂÏÔÁÀ ÎÁ ÆÉpÍÅ ...";
• ÈÁËÅp ÞÁÓÔÏ ÓÍÅÅÔÓÑ, ËÏÇÄÁ ÞÉÔÁÅÔ ÌÉÔÅpÁÔÕpÕ ÐÏ ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÀ (ÏÓÏÂÅÎÎÏ ÓÏ×ÅÔÓËÕÀ);
• ÌÕÞÛÁÑ ÌÉÔÅpÁÔÕpÁ ÄÌÑ ÈÁËÅpÁ - pÁÓÐÅÞÁÔËÁ ÐpÏÇpÁÍÍÙ;
• ÈÁËÅp ÎÅ ×ÓÅÇÄÁ ÚÎÁÅÔ ÑÚÙË ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÑ, Ó ËÏÔÏpÙÍ ÏÎ × ÄÁÎÎÙÊ ÍÏÍÅÎÔ pÁÂÏÔÁÅÔ;
• ÈÁËÅp ÓÐÏÓÏÂÅÎ ÏÂßÑÓÎÑÔØ ÐÏ ÔÅÌÅÆÏÎÕ ÓÐÏÓÏÂ, ËÏÔÏpÙÍ ÍÏÖÎÏ ÎÁÊÔÉ ÑÞÅÊËÕ ÐÁÍÑÔÉ, ÏÐpÅÄÅÌÑÀÝÕÀ ËÏÌÉÞÅÓÔ×Ï ÖÉÚÎÅÊ × ÉÇpÅ SABOTEUR, ÏÄÎÏ×pÅÍÅÎÎÏ ×ÏÓÓÔÁÎÁ×ÌÉ×ÁÑ ÓÏÄÅpÖÉÍÏÅ ÄÉÓËÁ Ó ÐÏÌÎÏÓÔØÀ ÉÓÐÏpÞÅÎÎÏÊ ÄÉpÅËÔÏpÉÅÊ, ÉÓÐÏÌØÚÕÑ DISC DOCTOR ÆÉpÍÙ Technology Research (ÐpÏÇpÁÍÍÕ, ÎÁÐÉÓÁÎÎÕÀ ÌÉÂÏ ÐØÑÎÙÍ, ÌÉÂÏ ÓÕÍÁÓÛÅÄÛÉÍ);
• ÈÁËÅp ÐpÅÄÐÏÞÉÔÁÅÔ pÁÂÏÔÁÔØ ÎÏÞØÀ, ÔÁË ËÁË × ÜÔÏ ×pÅÍÑ ÓÕÔÏË ÚÁËpÙÔÙ ÐÉ×ÎÙÅ ÚÁ×ÅÄÅÎÉÑ, Á ÔÅÌÅÆÏÎ ÐÏÞÔÉ ÎÅ Ú×ÏÎÉÔ. åÓÌÉ ÏÎ ÚÁÚ×ÏÎÉÌ, ÔÏ ÜÔÏ Ú×ÏÎÏË ÄpÕÇÏÇÏ ÈÁËÅpÁ;
• ÍÕÚÙËÁ ÍÏÖÅÔ ÂÙÔØ ÐÏÍÅÈÏÊ ×Ï ×pÅÍÑ ÞÔÅÎÉÑ ÈÕÄÏÖÅÓÔ×ÅÎÎÏÊ ÌÉÔÅpÁÔÕpÙ, ÎÏ ÎÅ ×Ï ×pÅÍÑ pÁÂÏÔÙ (pÁÂÏÔÙ?!);
• ËÁË ÐpÁ×ÉÌÏ, ËpÉÔÉËÕ ÈÁËÅp ×ÏÓÐpÉÎÉÍÁÅÔ ÂÅÚ ÍÏpÄÏÂÉÔÉÑ, ×ÓÅÇÄÁ ÎÁÈÏÄÉÔ ÏÐpÁ×ÄÁÎÉÅ, ÎÏ ÕËÁÚÁÎÎÕÀ ÏÛÉÂËÕ ÉÓÐpÁ×ÌÑÅÔ (ÅÓÌÉ ÅÅ ÎÅ ÉÓÐpÁ×ÉÌ ÄpÕÇÏÊ ÈÁËÅp);
• ÈÁËÅp ÍÏÖÅÔ ÓÔpÁÄÁÔØ ÔÑÖÅÌÏÊ ÆÏpÍÏÊ ÍÁÎÉÉ ×ÅÌÉÞÉÑ, ÎÏ ×ÓÅÇÄÁ Ï ÜÔÏÍ ÐpÅÄÕÐpÅÖÄÁÅÔ;
• ÍÙÓÌÉÔÅÌØÎÙÊ ÐpÏÃÅÓÓ ÉÄÅÔ Õ ÈÁËÅpÁ ÐÏÄÓÏÚÎÁÔÅÌØÎÏ. üÔÏ ÉÎÏÇÄÁ ÐpÉ×ÏÄÉÔ Ë ÔÏÍÕ, ÞÔÏ ÌÏÖÁÓØ Ó ÖÅÎÝÉÎÏÊ × ÐÏÓÔÅÌØ, ÈÁËÅp ×ÓËÁËÉ×ÁÅÔ, ÏÓÏÚÎÁ×, ÞÔÏ × ÐÑÔÉÓÏÔÏÊ ÓÔpÏËÅ ÅÇÏ ÐpÏÇpÁÍÍÙ ÓÔÏÉÔ ÎÅÐpÁ×ÉÌØÎÏÅ ÕÓÌÏ×ÉÅ ÐÅpÅÈÏÄÁ ÎÁ ÍÅÔËÕ QWERTASDF (ÔÁËÁÑ ÍÅÔËÁ ÔÁËÖÅ × ÐÏpÑÄËÅ ×ÅÝÅÊ, ÔÁË ËÁË ÈÁËÅpÕ ÎÅ È×ÁÔÁÅÔ ÜÎÅpÇÉÉ ÎÅ ÔÏÌØËÏ ÎÁ ÎÁÐÉÓÁÎÉÅ ËÏÍÍÅÎÔÁpÉÅ×, ÎÏ É ÎÁ ÐpÉÄÕÍÙ×ÁÎÉÅ ÕÄÏÂÏÞÉÔÁÅÍÙÈ ÍÅÔÏË - ÇÏpÁÚÄÏ ÐpÏÝÅ ÐpÏ×ÅÓÔÉ ËÕÌÁËÏÍ ÐÏ ËÌÁ×ÉÁÔÕpÅ).

- 4 -

÷ÎÅÛÎÉÊ ×ÉÄ ÈÁËÅpÁ ÍÏÖÅÔ ÛÏËÉpÏ×ÁÔØ ÎÅÐpÉ×ÙÞÎÏÇÏ ÞÅÌÏ×ÅËÁ. óÏ×ÅÔÓËÉÊ ÐpÏÇpÁÍÍÉÓÔ ÏÂÙÞÎÏ ÐpÅÄÓÔÁ×ÌÑÅÔÓÑ ÓÌÅÇËÁ ÌÙÓÏ×ÁÔÙÍ, Ó 8-ËÉÌÏÇpÁÍÍÏ×ÏÊ ÆÏpÔpÁÎÏ×ÓËÏÊ pÁÓÐÅÞÁÔËÏÊ × ËÏpÉÞÎÅ×ÏÍ ÐÏpÔÆÅÌÅ É ËÏÌÏÄÏÊ ÐÅpÆÏËÁpÔ ÐÏÄ ÍÙÛËÏÊ. èÁËÅp ÖÅ ÍÏÖÅÔ ÏÔÐÕÓÔÉÔØ ×ÏÌÏÓÙ ÄÏ ÐÏÑÓÁ, ÓÌÕÛÁÔØ ÔÑÖÅÌÙÊ pÏË É ÎÏÓÉÔØ × ÐÏpÔÆÅÌÅ ÛËÏÌØÎÙÅ ÕÞÅÂÎÉËÉ. éÎÔÅpÅÓÎÅÅ ×ÓÅÇÏ ÈÁËÅpÁÍ ÖÉ×ÅÔÓÑ × óÏ×ÅÔÓËÏÍ óÏÀÚÅ. ÷Ï-ÐÅp×ÙÈ, ÏÎÉ ×ÏÌØÎÙ × Ó×ÏÉÈ ÄÅÊÓÔ×ÉÑÈ, ÔÁË ËÁË ÚÄÅÓØ ÈÁËÅpÏ× × ÔÀpØÍÕ ÎÅ ÓÁÖÁÀÔ É ÛÔpÁÆÁÍ ÎÅ ÐÏÄ×ÅpÇÁÀÔ; ×Ï-×ÔÏpÙÈ, ÄÏËÕÍÅÎÔÁÃÉÑ ÎÁ ÐpÏÇpÁÍÍÕ ÉÌÉ ÑÚÙË ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÑ ÐÏÑ×ÌÑÅÔÓÑ Õ ÈÁËÅpÁ ÕÖÅ ÐÏÓÌÅ ÔÏÇÏ, ËÁË ÏÎ ÏËÏÎÞÁÔÅÌØÎÏ pÁÚÏÂpÁÌÓÑ Ó ÉÎÔÅpÅÓÕÀÝÉÍ ÅÇÏ ×ÏÐpÏÓÏÍ (Ñ, ÎÁÐpÉÍÅp, ÐÏÌÕÞÉÌ ÏÐÉÓÁÎÉÅ ÐpÏÃÅÓÓÏpÁ Z80 ÓpÁÚÕ, ËÁË ÔÏÌØËÏ ÐÏÎÑÌ ÉÓÐÏÌØÚÏ×ÁÎÉÅ pÅÇÉÓÔpÁ I, ÔÏ ÅÓÔØ ÓÁÍÏÅ ÓÌÏÖÎÏÅ, ÞÔÏ × ÜÔÏÍ ÐpÏÃÅÓÓÏpÅ ÅÓÔØ). åÓÌÉ ÖÅ ÈÁËÅp pÅÛÉÌ ÉÚÕÞÉÔØ ÑÚÙË ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÑ É ËÕÐÉÌ Ï ÎÅÍ ËÎÉÖËÕ × ËÉÏÓËÅ óÏÀÚÐÅÞÁÔØ, ÜÔÏ ÅÝÅ ÂÏÌØÛÅ ÁËÔÉ×ÉÚÉpÕÅÔ ÐpÏÃÅÓÓ ÉÎÔÅÌÌÅËÔÕÁÌØÎÏÊ ÄÅÑÔÅÌØÎÏÓÔÉ. ñ ÇÏÔÏ× ÐÏÖÁÔØ pÕËÕ ÄÁÖÅ ÐpÏÇpÁÍÍÉÓÔÕ ÎÁ ðÁÓËÁÌÅ, ÅÓÌÉ ÏÎ ÓÍÏÇ pÁÚÏÂpÁÔØÓÑ × ËÎÉÇÅ "HÁÞÁÌÁ ÐpÏÇpÁÍÍÉpÏ×ÁÎÉÑ ÎÁ ÑÚÙËÅ ðÁÓËÁÌØ" (ó.á. áÂpÁÍÏ×, å.÷. úÉÍÁ, íÏÓË×Á <<HÁÕËÁ>>, 1987) ÄÏ ÔÏÇÏ, ËÁË ÎÁÕÞÉÌÓÑ ÐÉÓÁÔØ ËÏÍÍÅÎÔÁpÉÉ É ×ÙÄÅÌÑÔØ Ä×ÕÍÑ ÐpÏÂÅÌÁÍÉ ËÏÎÓÔpÕËÃÉÀ REPEAT ... UNTIL. ïÎ ÓËÏpÅÅ ×ÓÅÇÏ ÈÁËÅp É ðÁÓËÁÌØ ÚÁÂpÏÓÉÔ ÄÏ×ÏÌØÎÏ ÓËÏpÏ. ðÏÓËÏÌØËÕ ÓÅÊÞÁÓ × ÓÏ×ÅÔÓËÉÈ ÍÁÇÁÚÉÎÁÈ ÎÅÌØÚÑ ËÕÐÉÔØ ÎÅ ÔÏÌØËÏ ÐÁËÅÔ P-CAD ÄÌÑ IBM PC, ÎÏ É ËÏÌÂÁÓÕ, ÈÁËÅp ÞÁÓÔÏ ÎÁÞÉÎÁÅÔ Ó ÔÏÇÏ, ÞÔÏ ÓÏÂÓÔ×ÅÎÎÙÍÉ ÓÉÌÁÍÉ ÓÏÂÉpÁÅÔ ËÏÍÐØÀÔÅp. åÓÔÅÓÔ×ÅÎÎÏ, ÞÔÏ ÜÔÏ ÉÇpÕÛËÁ ÄÌÑ ÄÏÍÁ É ÓÅÍØÉ Ó ×ÏÓØÍÉpÁÚpÑÄÎÙÍ ÐpÏÃÅÓÓÏpÏÍ É ÐÁÍÑÔØÀ × ÐpÅÄÅÌÁÈ 64ë, ÎÏ ÉÍÅÎÎÏ ÎÁ ÔÁËÏÍ ÁÐÐÁpÁÔÅ ÈÁËÅp ÎÁÞÉÎÁÅÔ ×ÏÉÓÔÉÎÕ ×ÙÔ×ÏpÑÔØ ÞÕÄÅÓÁ. ïÐÉÓÁÔØ ÏÝÕÝÅÎÉÑ, ×ÙÚÙ×ÁÅÍÙÅ ÓÏÏÂÝÅÎÉÅÍ ÑÚÙËÁ óÉ "þÉÓÌÁ Ó ÐÌÁ×ÁÀÝÅÊ ÚÁÐÑÔÏÊ ÎÅ ÐÏÄÄÅpÖÉ×ÁÀÔÓÑ" ÐÏÓÌÅ 3-È ÍÉÎÕÔÎÏÊ ÐÏÄÇpÕÚËÉ ÂÉÂÌÉÏÔÅËÉ stdio.h Ó ÍÁÇÎÉÔÏÆÏÎÁ, ÎÅ×ÏÚÍÏÖÎÏ, ÜÔÏ ÎÁÄÏ ÐpÏÞÕÓÔ×Ï×ÁÔØ. ôÅÍ ÎÅ ÍÅÎÅÅ, ÄÁÖÅ × ÔÁËÉÈ ÕÓÌÏ×ÉÑÈ ÈÁËÅpÕ ÕÄÁÅÔÓÑ ÎÁÐÉÓÁÔØ ÓÁÍÏÏÂÕÞÁÀÝÕÀÓÑ ÐpÏÇpÁÍÍÕ ÉÇpÙ × ÄÕpÁËÁ, ÎÅ ÉÓÐÏÌØÚÕÑ ÂÉÂÌÉÏÔÅËÉ ×ÏÏÂÝÅ. éÎÔÅpÅÓÎÙÅ ÓÉÔÕÁÃÉÉ ×ÏÚÎÉËÁÀÔ ÐpÉ ×ÓÔpÅÞÅ Ä×ÕÈ ÉÌÉ ÂÏÌÅÅ ÈÁËÅpÏ×. HÉ ÏÄÉÎ ÓÔpÕËÔÕpÎÙÊ ÐpÏÇpÁÍÍÉÓÔ ÎÅ ÐÏÊÍÅÔ ÓÕÔÉ ×ÏÐpÏÓÁ, ÏÂÓÕÖÄÁÅÍÏÇÏ ÈÁËÅpÁÍÉ, ÔÁË ËÁË ÏÄÉÎ ÈÁËÅp ÍÏÖÅÔ ÉÚßÑÓÎÑÔØÓÑ × ÛÅÓÔÎÁÄÃÁÔÉpÉÞÎÏÊ ÓÉÓÔÅÍÅ, ÄpÕÇÏÊ - × ÄÅÓÑÔÉÞÎÏÊ, ÔpÅÔÉÊ ÎÅ ÉÚßÑÓÎÑÔØÓÑ ×ÏÏÂÝÅ, É ×ÓÅ ÂÕÄÕÔ ÐpÅËpÁÓÎÏ ÐÏÎÉÍÁÔØ ÄpÕÇ ÄpÕÇÁ. ðÅp×ÙÊ pÁÚ × Ó×ÏÅÊ ÖÉÚÎÉ ×ÓÔpÅÔÉ× ÄpÕÇÏÇÏ ÈÁËÅpÁ, Ñ ÂÙÌ ÎÅÍÁÌÏ ÕÄÉ×ÌÅÎ ÔÅÍ, ÞÔÏ ÍÅÎÑ ÐÏÎÉÍÁÌÉ Ó ÐÏÌÕÓÌÏ×Á É ÍÎÅ ÎÅ ÐpÉÈÏÄÉÌÏÓØ ×ÓÅ pÁÚÖÅ×Ù×ÁÔØ É ÐÏ×ÔÏpÑÔØ ÐÏ ÐÑÔØ-ÛÅÓÔØ pÁÚ × pÁÚÍÅpÅÎÎÏÍ ÔÅÍÐÅ. íÅÎÑ ÎÅ ÐÅpÅÓÐpÁÛÉ×ÁÌÉ, ËÁËÕÀ ÓÉÓÔÅÍÕ ÓÞÉÓÌÅÎÉÑ Ñ ÕÐÏÔpÅÂÉÌ × ÄÁÎÎÙÊ ÍÏÍÅÎÔ ×pÅÍÅÎÉ É ÚÁÄÁ×ÁÌÉ ×ÏÐpÏÓÙ, ÎÁ ËÏÔÏpÙÅ ÍÏÖÎÏ ÂÙÌÏ ÄÁÔØ ÏÔ×ÅÔ. óÕÄÑ ÐÏ ÕÄÉ×ÌÅÎÉÀ × ÇÌÁÚÁÈ ÍÏÅÇÏ ËÏÌÌÅÇÉ, ÏÎ, ËÁË É Ñ, ÎÉËÏÇÄÁ ÐpÅÖÄÅ ÎÅ ÓÔÁÌËÉ×ÁÌÓÑ Ó ÄpÕÇÉÍÉ ÈÁËÅpÁÍÉ.

- 5 -

âÅÓÅÄÙ ÍÅÖÄÕ ÈÁËÅpÁÍÉ ÐpÉÎÏÓÑÔ ×ÅÓØÍÁ ÏÝÕÔÉÍÕÀ ÐÏÌØÚÕ, ÏÄÎÁËÏ ÐÏÄÐÕÓËÁÔØ Ë ÏÄÎÏÊ ü÷í Ä×ÕÈ ÈÁËÅpÏ× ÏÄÎÏ×pÅÍÅÎÎÏ ÎÅÄÏÐÕÓÔÉÍÏ. ë ÐÏÌÏÖÉÔÅÌØÎÙÍ pÅÚÕÌØÔÁÔÁÍ ÜÔÏ ÎÅ ÐpÉ×ÅÄÅÔ, ÂÏÌÅÅ ÔÏÇÏ, ÍÏÖÅÔ ÚÁËÏÎÞÉÔØÓÑ ËpÏ×ÏÐpÏÌÉÔÉÅÍ. ðpÉ ×ÓÅÍ ÔÏÍ, ÎÅ ÉÓËÌÀÞÁÅÔÓÑ, ÞÔÏ pÁÚÎÑ× Ä×ÕÈ ÄÅpÕÝÉÈÓÑ ÈÁËÅpÏ× É ÐÏÓÁÄÉ× ÉÈ × pÁÚÎÙÅ ËÏÍÎÁÔÙ, ÍÏÖÎÏ ÐÏÌÕÞÉÔØ ÁÂÓÏÌÀÔÎÏ ÉÄÅÎÔÉÞÎÙÅ ÐpÏÇpÁÍÍÙ. èÁËÅp - ÞÅÌÏ×ÅË ÓÐÏËÏÊÎÙÊ, ÎÏ É ÅÇÏ ÍÏÖÎÏ ×Ù×ÅÓÔÉ ÉÚ ÓÅÂÑ ×ÏÐpÏÓÏÍ "ëÁËÏÊ ËÏÍÁÎÄÏÊ ÐpÏÃÅÓÓÏpÁ ËÏÌÏÂÏË ÅÓÔ ÞÅpÔÁ?" ÉÌÉ "ëÁËÉÍ ÏÂpÁÚÏÍ ÓÎÑÔØ ÚÁÝÉÔÕ ÏÔ ËÏÐÉpÏ×ÁÎÉÑ Ó ÐpÏÇpÁÍÍÙ Infiltrator?". òÁÂÏÔÁ ÈÁËÅpÁ ÎÁÐÏÍÉÎÁÅÔ pÁÂÏÔÕ ÓÔÏÌÑpÁ, ÚÁÂÉ×ÁÀÝÅÇÏ ÛÕpÕÐ ÏÄÎÉÍ ÕÄÁpÏÍ ÍÏÌÏÔËÁ. èÁËÅp ÎÅËÏÔÏpÏÅ ×pÅÍÑ ÈÏÄÉÔ ×ÏËpÕÇ ÍÁÛÉÎÙ (pÁÄÉÕÓ ÈÏÖÄÅÎÉÑ ÍÏÖÅÔ ÓÏÓÔÁ×ÌÑÔØ ÄÏ ÎÅÓËÏÌØËÉÈ ÔÙÓÑÞ ËÉÌÏÍÅÔpÏ×), ÚÁÔÅÍ ÓÁÄÉÔÓÑ ÚÁ ËÌÁ×ÉÁÔÕpÕ É ÄÅÌÁÅÔ ÚÁ ÏÄÉÎ ×ÅÞÅp ÔÏ, ÎÁ ÞÔÏ ÂÙÌÏ ×ÙÄÅÌÅÎÏ 15 ÄÎÅÊ. HÅ ÎÁÄÏ ÄÕÍÁÔØ, ÞÔÏ ÞÅÔÙpÎÁÄÃÁÔØ ÄÎÅÊ, ËÏÔÏpÙÅ ÈÁËÅp ÐÏÔpÁÔÉÌ ÎÁ ÈÏÖÄÅÎÉÅ ×ÏËpÕÇ ÍÁÛÉÎÙ ÐpÏÐÁÌÉ ÄÁpÏÍ: ×ÓÅ ÜÔÏ ×pÅÍÑ ÈÁËÅp ÐÏÄÓÏÚÎÁÔÅÌØÎÏ ÏÂÄÕÍÙ×ÁÌ ÐÏÓÔÁ×ÌÅÎÎÕÀ ÚÁÄÁÞÕ. äpÕÇÏÅ ÄÅÌÏ, ÂÙÌÁ ÌÉ ÎÅÏÂÈÏÄÉÍÏÓÔØ × ÜÔÉÈ pÁÚÄÕÍØÑÈ. ëÏÇÄÁ ÈÁËÅp ÚÁËÁÎÞÉ×ÁÅÔ ËÁËÕÀ-ÌÉÂÏ pÁÂÏÔÕ, ÏÎ Ô×ÅpÄÏ Õ×ÅpÅÎ: ×ÓÅ, ÞÔÏ ÏÎ ÓÄÅÌÁÌ

- ÈÌÁÍ, ÏÄÎÁËÏ ×ÓÌÕÈ ÜÔÏ ÍÎÅÎÉÅ ÎÅ ×ÙÓËÁÚÙ×ÁÅÔ, ÔÁË ËÁË ÚÁËÁÚÞÉË ×ÓÅÇÄÁ ÏÓÔÁÅÔÓÑ ÄÏ×ÏÌÅÎ. èÁËÅp, ËÏÎÅÞÎÏ, pÁÓÓÔpÏÉÔÓÑ, ÅÓÌÉ ÓÌÕÞÁÊÎÏ ÕÎÉÞÔÏÖÉÔ ÛÅÓÔÉÍÅÓÑÞÎÕÀ pÁÂÏÔÕ, ÎÏ ÇÌÕÂÏËÏ × ÄÕÛÅ ÏÎ ÂÕÄÅÔ pÁÄ ÔÏÍÕ, ÞÔÏ, pÁÓÓÔÁ×ÛÉÓØ Ó ÈÌÁÍÏÍ, ÏÎ ÓÍÏÖÅÔ pÅÛÉÔØ ÚÁÄÁÞÕ ÇÏpÁÚÄÏ ËpÁÓÉ×ÅÅ. ïÄÎÁËÏ... ÓÍÏÔpÉ ÎÁÞÁÌÏ ÁÂÚÁÃÁ. Bye, Vladimir. [NedoPC] [MSC-51] [PIC-äá÷éôø] [1878÷å1]