Hадежный контроллер нужен........

Hi Dmitry !

Совсем недавно 05 Aug 06 13:57, Dmitry E. Oboukhov писал к Ruslan Mohniuc:

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

WBRgrds Ruslan

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

Hello, Arcady Schekochikhin! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 5 Aug 2006 08:11:01

AS> Dmitry Orlov wrote:

MZ>>> Документация на компилятор и библиотеку есть поставке, в формате MZ>>> ПДФ.

AS> А что там в GCC может быть такого AVR-специфичного? Ну ключей AS> немного - так они и в info описаны.

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

dima

Чет я нихрена не понял - типа народ должен (ну ты на этом все время настаиваеш) вникать в твою поделку (конкурс) а ты не хочешь? Ну - хозяин барин.

Фичи всегда надо. Фичи дают идеи.

Если ты думаешь что твоя программа была примером "не-поделия" то ты глубоко заблуждаешся - корявости в ней было выше крыши. Ну так однако вникаем. Ты и сам говоришь - пишеите на чем хошь типа - сравним заодно. А результат - нытье сплошное - сравнивать в Фарнеле, делать как у меня, уартов нельзя, кварцев нельзя, язык типа Си - других я не знаю...

AS>

AS> Это в общем случае совсем неважно - ну будет легкий тремор фронтов - на AS> таких скоростях AS> это не важно. я говорил об этом - он говорит что подбирать пришлось потому что расчетное реальному не соответствовало то есть быстродействие написанного видимо недостаточно для того чтобы гуляния фронтов были в рамках допустимого

AS>

AS> Да тут и так никаких переборов! про подбор писал не я, а DO, я его за язык не тянул

AS> Константа таймера - 138 типа - AS> но вот время входа в прерывание - величина переменная это что еще за новость такая? в честь чего это она переменная?

AS> - зависит от сгенерированного компилятором пролога - ее и AS> учитывает константа -5 (138-5==133).

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

AS> То что ДО пишет с "магическими числами" прямо в программе AS> - за это надо руки отрывать - но на то у него свое начальство есть. ага :)

AS>

AS> Чтобы сделать так как ты говоришь надо ГАРАHТИРОВАТЬ что ты AS> успеешь подготовить очередной бит приема/передачи до того как AS> сработает второе прерывание. я об этом писал тоже :) гарантировть можно двумя способами: написать нормальный менеджер процессов внизу и забыть о делениях либо наверху в ввод-вывод включить регистры сдвига, а логику все равно отделить

то есть

1. прерывание
2. выдвигаем из регистра вывода младший бит
3. вдвигаем в регистр ввода старший бит
4. выход из прерывания.

а парсинг/загрузку регистров осуществлять снизу. таким образом время выполнения пунктов 1-2-3-4 будет всегда постоянным => плаваний фронтов не будет, а снизу задержки будут не так уж критичным ну допустим не успел - просто следующий байт на сколько-то времени задержится (прерывание вставит сколько-то СТОП-ов)

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

AS> а сделать просто счетчик - правда AS> тогда сдвиговые регистры станут 11-битными - AS> геморрой на ПИКе. почему геморрой? сдвиг 16 бит - две команды: сдвиг одного (в перенос выдвигается), сдвиг второго перенос (вдвигается)

да, аккумулятор тут один, вот тут и начинаются отличия PIC, от AVR ;)

AS> Исполняя код Rx/Tx в прерывании мы превращаем процессы AS> приема/передачи в приоритетные. AS>

достаточно ввод-вывод сделать приоритетными

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

AS>

AS> В машине состояний алгоритм как раз нифига не виден. но зато отлично видны алгоритмы отдельных малепусеньких частей это состояние меняющих :)

AS> Hо тут действительно корявости AS> хватает - и в алгоритмах, и в инфраструктуре, и в стиле. вот вот, я говорю что если все вылизать то вполне вероятно что 4800 можно и на PIC до ума довести. не говоря уж об AVR :)

AS> Hе путается. Полностью следует стандартам (вот до какого именно - не помню AS> - сам глянь). А AS> тонкости - мануал по пентиумам содержит ссылки на именно этот компилятор - AS> в части AS> использования intrinsic functions для возможности использования хитрых AS> команд. Понятно что AS> все это становится непортабельным - за чем сразу следует совсем уж не такая AS> жесткая AS> необходимость в "безупречном следовании правилам языка". Ты много написал AS> программ на Си AS> которые пришлось без изменений переносить между хотя бы 3-4 компиляторами? тип процессора и стандарт языка в идеале вообще не должны быть связаны друг с другом :)

Это в общем случае совсем неважно - ну будет легкий тремор фронтов - на таких скоростях это не важно.

Да тут и так никаких переборов! Константа таймера - 138 типа - но вот время входа в прерывание - величина переменная - зависит от сгенерированного компилятором пролога - ее и учитывает константа -5 (138-5==133). То что ДО пишет с "магическими числами" прямо в программе - за это надо руки отрывать - но на то у него свое начальство есть.

Чтобы сделать так как ты говоришь надо ГАРАНТИРОВАТЬ что ты успеешь подготовить очередной бит приема/передачи до того как сработает второе прерывание. А именно этого делать не хочется - лучше сделать некоторые оптимизации типа занести в сдвиговый регистр стартовый и стоповые биты, чтобы не морочиться с номерами состояния а сделать просто счетчик - правда тогда сдвиговые регистры станут 11-битными - геморрой на ПИКе. Исполняя код Rx/Tx в прерывании мы превращаем процессы приема/передачи в приоритетные.

В твоих мечтах, к сожалению.

В машине состояний алгоритм как раз нифига не виден. Но тут действительно корявости хватает - и в алгоритмах, и в инфраструктуре, и в стиле.

Что такое "в МК собираешь"? JAL это такой самопальный язык - строго для ПИКов. Интересуюсь я им просто потому что показался оригинальным с очень любопытными идеями. А так я с ПИКами не работаю теперь - АВР если только иногда (и то довольно давно уже). Сам язык конечно коряв - ну так самопальщики делали. Но что интересно - вокруг JAL есть большая компания народа, реально его использующая в своих изделиях (ну скорее конечно "поделиях") - ибо ассемблера мало, а воровать (ну типа "попробовать" как ДО) - буржуи не любят конкретно. Менталитет. А тут вроде как неплохой процедурный язык, имеет много фич, сильно проще чем Си в реализации (но и сильно слабее Си во многом, хотя на этом языке можно делать такие финты!). Я компилятор JAL изучал, отлаживал и правил именно на вот этом переводе trm с Си на JAL - просто для размятия пальцев в свободное время.

Привет Arcady!

AS> И самый лучший компилятор для x86 несомненно интеловский.

Как называется?

AS> Это если мы AS> про _компилятор_ а не рюшечки. Этот компилятор знает все подробности AS> устройства всех пентиумов.

Это, конечно, хорошо, но важнее безупречное следование правилам языка. Если компилятор "путается" в синтаксисе, то о том, насколько хорошо он знает все тонкости процессоров, речь просто не идет...

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Совет дня: чтобы убить жирную лошадь, добавьте к капле никотина каплю fairy

Привет Dmitry!

DO>>> Да видеть-то можно что угодно, а нормальной документации, как и DO>>> нормальной готовой среды разработки в gcc как не было, так и DO>>> нет.

DEO>> а какой документации тебе не хватает? по gcc такой ее талмуд что DEO>> читай не перечитаешь :)

DO> Конкретного описания копмилятора и линкера под целевую платформу.

В GCC нет линкера.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Я удалю твою жажду. Без возможности восстановления.

Intel C compiler. ICC. Интел его дает на-халяву для линуха.

Не путается. Полностью следует стандартам (вот до какого именно - не помню - сам глянь). А тонкости - мануал по пентиумам содержит ссылки на именно этот компилятор - в части использования intrinsic functions для возможности использования хитрых команд. Понятно что все это становится непортабельным - за чем сразу следует совсем уж не такая жесткая необходимость в "безупречном следовании правилам языка". Ты много написал программ на Си которые пришлось без изменений переносить между хотя бы 3-4 компиляторами?

Привет Dmitry!

DO> А в линуксе оркад и пикад не работают

У меня в FreeBSD PCAD-2000 работает. Hе вижу причины не работать ему в линуксе Димы.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... мне маны читать некогда, я программист (c) Andrew Wingorodov

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

Hello, Dmitry E. Oboukhov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 05 Aug

DO>> Hет никакой связи. Я же уже дважды объяснил почему число в таймере DO>> надо подбирать. От момента возникновения прерывания до начала его DO>> обработки проходит некоторое время

DEO> это время всегда одинаковое, потому подбор в твоем случае связан

Конечно. Потому у меня там всегда константа 133, а не от случая к случаю.

DEO> только с тем что если "разделить" твое прерывание, то до обработки DEO> прерывания по передаче данных у тебя сперва должно обработаться DEO> прерывание по приему данных.

Чушь. С тем, что делается в прерывании, значение константы никак не связано вообще.

DEO> вот тут задержка получается существенная и всякий раз разная (в DEO> зависимости от того по каким веткам пробежало)

Существенная, в среднем около половины периода прерываний. И что, с того?

DEO> вот я и говорю надо отделить логику низкоуровневого управления от DEO> выдачи сигналов на выводы.

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

DEO> ты просто слушать не хочешь, хотя я уже это 10 раз повторил. DEO> так бы и на PIC можно было 4800 реализовать ;)

Реализуй, а я посмотрю. Ты просто путаешь два несвязанных между собой вопроса.

DO>>>> Этого я совершенно не понял. Ты про обработку команд, вводимых с DO>>>> терминала?

DEO> я ответил на этот вопрос уже два раза я про выдачу/распознавание DEO> битов данных и битов старт/стоп/четность вот ниже ты и отквотил

DEO>>> нет про низкоуровневую реализацию RS232 старт-бит данные (от 5 DEO>>> до 9 бит) бит четности два стоп-бита

DO>> Так где же, кроме прерывания это делать?

DEO> можно и в прерывании, если тебе кажется что кроме как там негде ;)

Мне ничего не кажется, и делать это можно где угодно, просто там это делать проще.

DEO> но тогда в прерывании это делать _после_ того как очередной бит DEO> будет выдан на ногу и принят с неё :)

Выдача с приемом вообще не связаны.

DEO>>> парсить/собирать в кучу эти данные если в основной программе, а DEO>>> в прерываниях только двигать, то в прерываниях можно будет не DEO>>> заботиться о подборе значений таймера :)

DO>> Hапиши на С, я так не понимаю. А не заботиться нельзя, даже если в DO>> прерывании я только ножкой дергаю.

DEO> может быть и напишу, но вроде я внятно объясняю вот на человеческом DEO> языке алгоритм для варианта как ты хочешь, "все в прерываниях" DEO> (хотя в прерываниях вовсе не нужно этого делать)

Значит это надо с той же скоростью делать снаружи. Разницы я не вижу, кроме того, что так сложней.

DEO> я тут опишу такой алгоритм чтобы по максимуму не переделывать твой,

Не надо теорий. Не надо. Или пример кода или молчание.

DEO> короче доработка напильником:

DEO> твоя void interrupt sys_int(void) DEO> {

DEO> добавляем строки static bit inbuffer=0; // тут могут быть DEO> начальные static bit outbuffer=0; // значения другие - тебе DEO> виднее

DEO> сразу после T0IF = 0; добавляем строки

DEO> inbuffer=TRx; DEO> TTx=outbuffer;

DEO> а дальше весь твой же код как он есть, но все обращения к TTx и TRx DEO> замени на обращения к inbuffer outbuffer.

DEO> что мы получили? DEO> 1. мы получили что время от выставления флага переполнения таймера DEO> 0 до выставления сигнала на ножке TTx и принятия сигнала с ножки DEO> TRx всегда одинаковое. как бы там программа дальше не работала

Оно и так всегда одинаковое. Определяется периодом тамера и временем входа в прерывание.

DEO> 2. вследствие п. 1 мы можем вверху программы определить BAUD_RATE, DEO> а строку TMR0 = 133; определить через макрос исходящий из FOSC и DEO> BAUD_RATE. и HИКАКИХ подборов.

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

DEO> теперь то что о дальнейшей оптимизации:

DEO> теперь мой код что я добавил назовем вводом-выводом, а твой DEO> (модифицированный как я описал выше) назовем логикой работы RS.

DEO> так вот я говорю, что если немного поднапрячь мозги и избавиться от DEO> циклов ожидания которые у тебя есть внизу (надеюсь уже не будем DEO> придираться к этому термину ;) ), а написав нормальный менеджер

У меня нет никаких циклов ожидания. И нет никакого верха-низа.

DEO> процессов внизу (хоть тупой перебор функций например) мы можем DEO> логику работы RS перенести вниз. (скорость такая маленькая что это DEO> запросто)

Напиши полностью, покажи что это работает и код - тогда обсудим. Теории мне не интересно.

DEO> да деление уже использовать нельзя будет (хотя если часть логики

А вот это уже не годится. Я не хочу думать о том сколько времени что выполняется в основном цикле. и что там можно,, а что нельзя использовать. Будет надо, хоть весь math.h использую (что я собственно в другом проекте и делаю).

DEO> оставить все же наверху - перейти к сдвиговым регистрам то можно DEO> дооптимизироваться и до возможности применять деление), но т.к. DEO> процессорное время будет использоваться более рационально вполне DEO> вероятно мы сможем и BAUD_RATE поднять раза в два. два раза скорее DEO> всего и PIC вытянет с нормальным подходом :)

Врядли. Хотя 4800 наверное можно вытянуть, оно там на грани.

DEO> PS: а если ты еще перепишешь strtoi по тому же принципу как я DEO> переписал твою printi то получишь еще одну такую же (если не DEO> больше) экономию в объеме и скорости выполнения :)

А зачем? Влазит, работает, что еще надо?

DEO> PPS: ну что, если не разобрал свой макет на котором это собрано DEO> попробуешь доделать в соответствии с моим рекомендациями?

Разобрал давно.

DO>> Для этого из tputch вызывается idle.

DEO> вот я и говорю сделать классический событийный вид, а не ставить DEO> костыли :)

Ты не говори, ты сделай.

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

DEO> ты где-то выше сказал фразу "для того чтобы получить нормальный DEO> Апликейшн нотес", а уж коль взялся за такого уровня задачу, изволь DEO> таки не открещиваться или прекратим разговор :)

Прекращай, если не хочешь делать.

DEO> в AN код должен быть прост и понятен у того кто читает не должно DEO> быть продираний сквозь дерево функций с циклическими завязками как DEO> у тебя. алгоритм должен быть четко виден.

Бери и делай, кто тебе не дает?

dima

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

Hello, Dmitry E. Oboukhov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 05 Aug

DO>> Hу так откуда тогда 1200 ампер за 500ns?

DEO> ну вот смотри, дроссель у тебя = бесконечности возьмем классический DEO> понижающий регулятор.

DEO> выходной ток через дроссель - непрерывный (он равен же DEO> бесконечности)

DEO> а транзистор и обратный диод коммутируют выходной ток, не так ли?

И что? Ты про токи в ключах говоришь? Так как их скорость изменения сказывается на чем-то?

DO>> Трансформаторами еще можно сочленить.

DEO> емкость у трансформаторов обычно сильно выше емкости у оптронов (а DEO> уж тем более у фиберов), а потому с помехами на трансформаторах DEO> часто хуже бывает (в сложной, многопотенциальной системе)

У тебя же все равно части системы через емкость источника питания этих частей связаны.

dima

DO> И что? Ты про токи в ключах говоришь? Так как их скорость изменения DO> сказывается на чем-то? источниками помех обычно являются фронты тока в индуктивностях (паразитных)

то есть до коммутации ток тек через диод и его присоединительные индуктивности, то после коммутации ток течет через транзистор и его индуктивности.

DEO>> которые в сумме и есть среда. очень очень гибкая. DO>

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

DEO>> вот пример, расскажи как ты будешь решать его IAR DO>

DEO>> допустим тебе нужна таблица 200 значений f=(A,B,C,x) DEO>> где A, B, C - постоянные которые ты планируешь выбрать в процессе DEO>> отладки а таблица собственно ставит в соответствие f и x DO>

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

а я возьму и добавлю исходник на каком-либо другом языке (например m4 или perl) и у меня программа просто будет собираться из всего полученного. а менять константы буду в одном из файлов перед сборкой :)

DO> И в чем легче уходить с gcc по сравнению с iar? речь не о компиляторах а о среде разработки, которой типы компиляторов должны быть по барабану

DEO>> под вайном Оркад работает, а пикад я со времен 4-й версии забросил DO>

DO> А у меня под ХР и то и другое работает. а зачем работать и в том и в другом? ума не приложу :)

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

Hello, Dmitry E. Oboukhov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 05 Aug

DO>>>> Да видеть-то можно что угодно, а нормальной документации, как и DO>>>> нормальной готовой среды разработки в gcc как не было, так и нет. DEO>>> вот среда разработки то как раз наоборот существенно лучше DEO>>> GNU-utils :)

DO>> Это не среда, это утилиты какие-то.

DEO> которые в сумме и есть среда. очень очень гибкая.

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

DEO> вот пример, расскажи как ты будешь решать его IAR

DEO> допустим тебе нужна таблица 200 значений f=(A,B,C,x) DEO> где A, B, C - постоянные которые ты планируешь выбрать в процессе DEO> отладки а таблица собственно ставит в соответствие f и x

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

DO>> Hу тех же контроллеров IAR в 20 раз больше поддерживает. А чего DO>> между компиляторами все время скакать?

DEO> а того, что когда натыкаешься что один компилятор тебе почему-то не DEO> подходит берешь другой. например ошибку нашел или оптимизатор у другого лучше итп

И в чем легче уходить с gcc по сравнению с iar?

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

DEO> не вижу я облегчения

А я - вижу.

dima

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

Hello, Dmitry E. Oboukhov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 05 Aug

AVB>>>> А чем плох? DEO>>> в линуксе например не работает. DEO>>> для меня например это существеннейший фактор

DO>> А в линуксе оркад и пикад не работают и куча всего остального. Мой DO>> бывший сотрудник на новой работе вообще в осциллографе и копилирует DO>> и прожигает. Под виндой, понятное дело.

DEO> под вайном Оркад работает, а пикад я со времен 4-й версии забросил

А у меня под ХР и то и другое работает.

dima

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

Hello, Arcady Schekochikhin! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 5 Aug 2006 10:22:10

AS> Чет я нихрена не понял - типа народ должен (ну ты на этом все время AS> настаиваеш) вникать в твою поделку (конкурс) а ты не хочешь? Ну - AS> хозяин барин.

Я предлагаю народу, когда он говорит, что А лучше чем Б показать это на примере и не говорить голословно. Какое принципально новое качество (недостатки очевидны) может дать этот твой язык я не вижу. Просто переписывать на него мой код считаю бессмысленным

AS> Фичи всегда надо. Фичи дают идеи.

В обсуждаемом ключе, это бесплодные идеи. Мы же не обсуждаем тут создание новых языков, тем более, что хватает уже созданных. В С вызов функции выглядит как f(arg), а не a-la Delphi' properties и не как перегруженный в C++ опрератор =.

AS>>>>> я думаю в синтаксисе легко разобраться - а разные "некрасивые

AS>>> В чем "есть смысл"? Не понял фразы.

AS> Если ты думаешь что твоя программа была примером "не-поделия" то ты AS> глубоко заблуждаешся -

Не думаю, более того, декларировалось иное.

AS> корявости в ней было выше крыши. Ну так однако вникаем. Ты и сам AS> говоришь - пишеите на чем хошь типа - сравним заодно. А результат -

Говорю. Но мне написанное не на С не интересно. Кому-то может быть интересно, я не против. Я, помнится, просил тебя прислать скомпилированный hex, чтобы я мог проверить как он работает, но ты так и не прислал.

AS> нытье сплошное - сравнивать в Фарнеле, делать как у меня, уартов AS> нельзя, кварцев нельзя, язык типа Си - других я не знаю...

Не нытье, а условие. Потому что если не сравнивать в Фарнеле, применять кварцы и uart'ы, то легко дойти до применения пентиума и программы на VB. А кидать сюда исходники на одному тебе известном языке? Можно конечно, но как-то плохо выглядит.

dima