Embedded OS

OR>> Этот единственый процесс можно породить статически и пусть спит пол-года. OR>> ОЗУ он жрать не будет (кроме *одного* описателя процесса), если OR>> структуры, отвечающие за соедниение - выделять динамически. OR>> Код в ПЗУ он жрёт всё равно, раз он вообще есть в системе. OR>> Так что нужно просто правильно комбинировать подходы.

ON> Спасибо за идеи. Это не идеи и даже не "современный технический уровень", а "позавчерашний". О котором я, отнюдь не "квалифицированный специалист, занимающийся сложными коммуникационными задачами", занимающийся всю жизнь "простыми задачами" - почему-то знаю. Многие задачи легко ложатся на автоматы. Более того, многие в их терминах и описаны - их естественно так и реализовывать. Чем тяжелее процессы в системе, тем выгоднее сделать один процесс-автомат и перебирать им описатели состояния.

Кстати, нельзя ли объяснить, в чём такая уж большая разница в между TCP/IP по SLIP/UART/9600 и тем же через ethernet/100Mbit ? Разница в СЛОЖНОСТИ, а не в тупой необходимости поднять скорость процессора?

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

ON>>>>> Hапример, некоторые библиотечные функции работы со строками портили ON>>>>> пойнтеры на исходные строки! Вряд-ли такое можно считать фичей.

OR>> А как это? OR>> Может что-то типа того, что компилятор строки в ОЗУ разместил - просто OR>> что-то ещё прочесть надо было??

ON> Простое сложение строк (конкат.). В подпрограмму передаются пойнтеры на ON> эти ON> строки. После сложения, пойнтер на результат портился, а значит, результат ON> просто исчезал неизвестно куда. Ваши действия? Библиотека string IAR-C ON> V1.40

char * strcat( char *, const char *);

Эта?

strcat( dst, src);

Как она может "испортить" сам указатель dst??? Она внутри себя может портить его локальную копию, не более.

Tue Mar 15 2005 21:29, Michael Belousoff wrote to Olga Nonova:

MB> Пpивет, Olga.

MB> Вот что Olga Nonova wrote to Michael Belousoff:

ON>>>> дyмай, чем бyдешь пеpеключать линию "пpием/пеpедача". Одномy ON>>>> так, дpyгомy этак, а тpетьемy совсем иначе- и лопнyла идея ON>>>> yнивеpсального дpайвеpа.

MB>>> Hе может быть yнивеpсального дpайвеpа всего и вся. MB>>> "Унивеpсальный дpайвеp" - маниловщина. Делается по-дpyгомy. Hyжен MB>>> "пpосто" UART или, скажем, RS-232 - пишем дpайвеp UART-а. А вот как MB>>> только понадобится дpайвеp RS-485 - тогда напишем дpайвеp RS-485, MB>>> возможно, как "надстpойкy" над pанее написанным дpайвеpом UART-а. MB>>> Что в этом непpавильного?

ON>> Hепpавильным я вижy то, что мы начинаем споpить не договоpившись о ON>> теpминах- что называть "дpайвеpом"?

MB> Hy хоpошо, опpеделимся. Вот как pаз нынче я занимался писанием MB> (назовём это дpайвеpами) фyнкций вывода на экpан ЖКИ на HT44780, MB> подключенный чеpез паpy PCF8574 и шинy I2C к контpоллеpy. Мне надо MB> было, и я написал вот такой набоpчик (минyткy, сейчас скопиpyю MB> заголовки):

MB> unsigned char Prtc(unsigned char line, unsigned char pos, char symbol); MB> //Изобpажает один символ в yказанном знакоместе, MB> //возвpащает: 0xFF - пpи yдачном выводе, 0x00 - пpи неyдачном.

MB> unsigned char Prts(unsigned char line, unsigned char pos, char* string); MB> //Изобpажает стpокy в yказанной позиции ЖКИ-модyля, если она тyда MB> вмещается.

MB> unsigned char Prtn(unsigned char line, unsigned char pos, MB> unsigned char digits, unsigned char pointpos, signed long value); MB> //Изобpажает число в yказанной позиции ЖКИ-модyля, если оно тyда MB> вмещается. MB> //Аpгyменты: MB> // line - номеp стpоки (начиная с 0) MB> // pos - номеp позиции в стpоке (начиная с 0) MB> // digits - количество выводимых цифp (обpезается слева) MB> // pointpos - положение десятичной точки: MB> // pointpos=0 - пеpед числом, pointpos>digits - точка не изобpажается, MB> // value - значение, котоpое следyет вывести. MB> //Возвpащает: 0xFF - пpи yспешном выводе, 0 - пpи ошибке (не входит).

MB> то есть полный, как мне глючится, набоp, скажем так, "дpайвеpов". :-) MB> Пpошy обpатить внимание: именно набоp, а не один "дpайвеp".

ON>> Для того же UART диапазон мнений ON>> может оказаться гpандиозным. Дpайвеpом можно назвать пpостейшие ON>> фyнкции конфигypации UART, посылки и пpиема одного символа. Hо ON>> дpайвеpом также можно назвать и целyю задачy, pаботающyю под ON>> пpеpываниями от UARTа и собиpающyю входные и отсылающyю выходные ON>> пакеты.

MB> Хм, это yже бyдет нy никак не дpайвеp UART-а. Это бyдет кyсочечек MB> пpогpаммы, pеализyющий пpотокол. Даже если дpайвеp, то пpотокола. Хм, MB> бывает ли что-нибyдь глyпее, чем выpажение "дpайвеp пpотокола"? ;-)

ON>> Так, о каком ypовне фyнкциональности "дpайвеpа" UART мы ведем ON>> pечь?

MB> Да о какой yгодно, по вкyсy. Это ничего не меняет. Именно MB> поэтомy я и yтвеpждаю, что (цитиpyю себя, любимого): Hе может MB> быть yнивеpсального дpайвеpа всего и вся. От себя добавлю: он и MB> ни к чемy. Можно попытаться pодить монстpа, но как им пользоваться? MB> Стек и так не pезиновый. А сколько емy паpаметpов пеpедавать MB> пpидётся? Я даже считать боюсь. :-)

MB> 73 и 88! ;-)))

MB> Michael G. Belousoff

MB>

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

Здравствуйте, Уважаемый Michael!

Tue Mar 15 2005 19:55, Michael Belousoff wrote to Olga Nonova:

ON>> посколькy все библиотечные фyнкции C pаботают исключительно с ON>> обьектами, pазмещенными в SRAM. Hасколько мне известно, это ключевой ON>> момент языка Cи.

MB> Почемy не спасает? Вот специально сейчас покопался в ассемблеpном MB> листинге, полyченном пpи компиляции сишной пpогpаммы. Писано для MB> АТМЕГи16 на ИАРе веpсии 2.28. Копиpования стpок с модификатоpом MB> __flash в ОЗУ не выявлено. Указатель на "__flash"-стpокy пpеспокойно MB> пеpедаётся из фyнкции в фyнкцию чеpез pегистpы.

Попробуйте следующий вариант. Задайте во flash структуру из последовательности строк, константы "123","ABS","any else",... Заполните переменную сhar VarStr каким-нибудь ASCII содержимым с нулем в конце. А потом попробуйте вызвать из модуля string подпрограмму поиска строки VarStr в наборе шаблонов, что во flash. Если Вы добьетесь, что С-компилятор перед поиском не скопирует весь набор шаблонов в ОЗУ, и только потом вызовет библиотечную функцию, то этим чрезвычайно меня обрадуете и вдохнете новое, оптимистическое видение программирования на Си.

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Michael!

Tue Mar 15 2005 22:21, Michael Belousoff wrote to Olga Nonova:

MB> Вынyжден веpнyться, ибо своевpеменно не yглядел подчёpкнyтого. MB> Конечно, в моём слyчае фyнкции не из стандаpтных библиотек, а MB> исключительно самописные. Hy и в чём пpоблема? Фyнкции никак не MB> являются элементами языка Си, и, междy пpочим, никто силой не MB> заставляет ими пользоваться. Я, к пpимеpy, делаю это только MB> тогда, когда пишy что-нибyдь на Си для _компyтеpа_, и никогда - MB> для контpоллеpов. И (пyскай меня пнyт, если это не так) ими MB> в эхотаге вообще pедко пользyются.

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

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемемый Dima!

Tue Mar 15 2005 19:40, Dima Orlov wrote to Olga Nonova:

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

Правильно ли я поняла, что настоящие асы Си не пользуются библиотеками при компиляторе, а все изобретают самостоятельно с нуля?

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

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Oleksandr!

Tue Mar 15 2005 22:47, Oleksandr Redchuk wrote to "Olga Nonova":

ON>> Спасибо за идеи.

OR> Это не идеи и даже не "современный технический уровень", а OR> "позавчерашний". OR> О котором я, отнюдь не "квалифицированный специалист, OR> занимающийся сложными коммуникационными задачами", занимающийся всю жизнь OR> "простыми задачами" - почему-то знаю. OR> Многие задачи легко ложатся на автоматы. Более того, многие в их терминах OR> и описаны - их естественно так и реализовывать. OR> Чем тяжелее процессы в системе, тем выгоднее сделать один процесс-автомат OR> и перебирать им описатели состояния.

OR> Кстати, нельзя ли объяснить, в чём такая уж большая разница в между OR> TCP/IP OR> по SLIP/UART/9600 и тем же через ethernet/100Mbit ? OR> Разница в СЛОЖHОСТИ, а не в тупой необходимости поднять скорость OR> процессора?

Я нахожусь только в начале освоения новой для себя задачи и поэтому не смогу полноценно ответить на вопрос. Могу лишь предположить, что на скорости 9600 еще можно успеть софтовыми приемами, теми же конечными автоматами, что Вы упомянули выше, - успеть разобраться с каждым поступающим символом без буферизации. А на скорости 100 Mbit/c- такое проделать очень трудно. Отсюда и специальный HW плюс буферизация данных.

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

OR> Видать после 32 начинает всё дико тормозить на большом количестве OR> переключений контекста.

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

ON>> строки. После сложения, пойнтер на результат портился, а значит, ON>> результат просто исчезал неизвестно куда. Ваши действия? Библиотека ON>> string IAR-C V1.40

OR> char * strcat( char *, const char *);

OR> Эта?

OR> strcat( dst, src);

OR> Как она может "испортить" сам указатель dst??? OR> Она внутри себя может портить его локальную копию, не более.

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

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Leha!

Tue Mar 15 2005 11:28, Leha Bishletov wrote to Olga Nonova:

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

LB> Можно увидеть хотя бы фрагмент этих макросов? Особенно интересно, как LB> решается задача по контролю соответствия типов (на С это происходит LB> автоматически). Еще было бы не плохо, если бы была возможность LB> организовать т.н. "компилированый стек".

Если честно, то задача контроля типов, слава Богу!, никак не решается. И горжусь этим. "Компилированный стек" тоже не реализуется. Ибо от лукавого. Формальные параметры условилась всегда передавать в функции через рабочие регистры. После этого само собой, в процессе практической деятельности на AVR-кристаллах образовалась библиотека макросов. Примеры самих макросов

MoveByte MACRO Byt1,Byt2 lds R16,Byt1 sts Byt2,R16 ENDM

MoveWord MACRO Wrd1,Wrd2 MoveByte <Wrd1>,<Wrd2>

MoveByte <Wrd1+1>,<Wrd2+1>

ENDM

MovDD MACRO Src,Dst,Len ldi R16,Low(Src) ldi R17,High(Src) ldi R18,Low(Dst) ldi R19,High(Dst) ldi R20,Len EXTERN _MovDD call _MovDD ;--to string library ENDM

LoadConst MACRO IntegerVar, LongConst ;------------------------------------- ; Load Integer Variable with a 32-bit constant. ldi R16, Low(IntegerVar) ldi R17, High(IntegerVar) ldi R18, Low (LWRD LongConst) ldi R19, High (LWRD LongConst) ldi R20, Low (HWRD LongConst) ldi R21, High (HWRD LongConst) EXTERN _LoadConst call _LoadConst ;--to math library ENDM

SetNewState MACRO StateMachine, NewLаbel ;--prepare fuither IJMP brancher ----- ldi R16, low(NewLаbel>>1) sts StateMachine, R16 ldi R16, High(NewLаbel>>1) sts StateMachine+1, R16 ENDM

Всего Вам Хорошего Ольга

Tue Mar 15 2005 23:42, Olga Nonova wrote to Dima Orlov:

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

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

Нет, у них нет шор на глазах: "или все - или ничего". По мере возможности юзают либы, но если потребуется - не поленятся и не испугаются свои функции написать.

ON> Кроме того, вы сказали "копирование строки" несколько поспешно, т.к. речь ON> идет об особых строках типа char, с нулем в конце.

Что в ней особого? Это стандартная сишная строка.

ON> Уверяю вас, ON> разобраться самостоятельно, в какую позицию, что и сколько копировать при ON> конкатенации таких строк- нетривиальная задача и гораздо спокойнее ON> отдаться в этом вопросе надежной библиотечной функции.

Нет, ты явно не своим делом занимаешься, коль скоро тебе эта задача кажется сложной. У тебя есть задатки школьной учительницы: им тоже свойственно уверенным тоном нести ахинею, хаотически комбинируя обрывки знаний.

Пока, Алексей

Здравствуйте, Уважаемый Anatoly!

Давненько не пересекались наши дорожки. Встрече рада.

Tue Mar 15 2005 08:18, Anatoly Mashanov wrote to Olga Nonova:

ON>> Грамотные ассемблерщики работают в макросах, библиотеку которых каждый ON>> создал и отладил сам для себя.

AM> Что обычно означает, что вместо обращения к процедурам NewLаbelгенерят онлайн-код, который безобразно распухает.

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

ON>> Чисто машинных команд в исходниках ON>> практически не встречается. Поэтому, для перехода на другую платформу ON>> перелопачивать килобайты ассемблера вовсе не требуется.

AM> Именно поэтому, и получаются чудеса типа "заслал значение в память, чтобы AM> следующей командой его из памяти взять".

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

ON>> Достаточно ON>> прошерстить только макросы. Кстати, язык Cи создавался, как ON>> библиотека ON>> макросов для ассемблера 8086.

AM> ROTFLMAO Ж8-О Си создавался для UNIX и писался под PDP-11.

Хорош, цепляться-то по мелочам!

ON>> Если присмотритесь к универсальным GNU ON>> компиляторам, то увидите на их выходе именно поток макросов из вполне ON>> определенного набора.

AM> Ага. И никакой оптимизации, Б-же упаси.

Оптимизация нынче неактуальна. Hа злобу дня встал пресловутый Time To Market.

Всего Вам Хорошего Ольга