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
2006 16:03:21 +0400:
DEO>>> вот тут задержка получается существенная и всякий раз разная (в DEO>>> зависимости от того по каким веткам пробежало)
DO>> Существенная, в среднем около половины периода прерываний. И что, с DO>> того?
DEO>>> вот я и говорю надо отделить логику низкоуровневого управления DEO>>> от выдачи сигналов на выводы.
DO>> К чему ты это говоришь? Какая разница когда прерывание закончится, DO>> если это происходит до прихода следующего?
DEO> выше ты сказал что половину процессорного времени занимает DEO> прерывание.
Около того.
DEO> субя по коду 2/3 этого времени занимает функция Receive.
Возможно, не помню уже.
DEO> то есть задержка на передачу у тебя на время 1/3*2/3 = 2/9 от DEO> периода тактирования передачи (первая 1/3 от того что прерывания у DEO> тебя с утроенной частотой идут).
Да. И что с того?
DEO> на задержка на 22% можно было бы наплевать если бы время выполнения DEO> процедуры Receive было бы постоянным. оно же у тебя случайное (в DEO> зависимости от того по каким веткам пройдет)
Оно не случайное конечно, но не постоянное. Есть некоторый джиттер. И что собственно, кого он волнует?
DEO> следовательно то что данная реализация сопрягается с другими DEO> девайсами по последовательному интерфейсу - есть такая же DEO> случайность :)
Отнюдь. Тем более, что реально прием и передача разделены во времени.
DEO> не хочешь делать методически более правильно, я тебя не неволю
Я не считаю предложенный тобой путь более правильным. Но если джиттер при передаче критичен, действительно вывод в порт подготовленного на предыдущем прерывании бита можно перенести в начало обработчика, где еще нет ветвлений, тем более, что это действительно очень просто. Выносить все остальное из прерывания я считаю просто вредным.
DEO> просто когда-нибудь проект станет больше и будешь искать баги
Это взято из большого проекта, и никаких багов я в этом месте уже давно не ищу.
DEO> а на AN такой пример ну совсем не годится
Сделай другой, который годится.
DO>> Реализуй, а я посмотрю. Ты просто путаешь два несвязанных между DO>> собой вопроса.
DEO> я не путаю
Путаешь. Джиттер при передаче совершенно не связан с подбором числа для таймера. Совсем.
DO>> Мне ничего не кажется, и делать это можно где угодно, просто там DO>> это делать проще.
DEO> естественно проще и не думать тоже проще ;)
Именно!
DO>> Выдача с приемом вообще не связаны.
DEO> именно связаны: функция Send у тебя начнет работать только после DEO> того как закончит Receive. DEO> модификация одного влияет на время начала выполнения другого.
Начало вообще никого не волнует, это асинхронный протокол.
DEO> мало того по каким веткам пройдет первое влияет на фронты второго.
Влияет, но не слишком сильно. Если это критично, см. выше.
DO>> Значит это надо с той же скоростью делать снаружи. Разницы я не DO>> вижу, кроме того, что так сложней.
DEO> разница в более рациональном использовании процессорного времени. DEO> можно больше квантов отдать другим процессам, например
Нельзя, ведь сделать нужно ровно тоже самое ровно за то же время. Вот если время выполнения основного цикла от этого изменится, то и хрен бы с ним. Ни на что это не повлияет никак. Уж за любыми мыслимыми изменениями температуры оно по любому успеет.
DEO>>> я тут опишу такой алгоритм чтобы по максимуму не переделывать DEO>>> твой,
DO>> Hе надо теорий. Hе надо. Или пример кода или молчание. DEO> я тебе фактически diff на твой код дал, что еще надо?
Надо _работающий__в__железе__пример__кода_. Словеса - по желанию, но ничего кроме других словес это не породит. Толку и от тех и от других - только видимость трафика.
DEO> то есть между входом в прерывание и выдачей сигнала на TTx у тебя DEO> >=100 строк кода с ветвлениями => кода выполняющегося случайный DEO> интервал времени между N и M мкс (считать лень)
А не надо ничего считать. Становишься скопом на ножку Tx и смотришь влазит сигнал в то, что должно быть, или не влазит. Как обеспечить отсутствие джиттера я указал выше. Это практически не требует изменений в программе и переноса чего-то из прерывания наружу, чему надо еще гарантировать вызов вовремя.
DEO> => то что у тебя компьютер принимает случайно поставленный фронт DEO> есть лишь результат того что ты за допуски не вылетел (что тоже DEO> случайно)
Ничего случайного, все закономерно и _меряется_.
DEO>>> 2. вследствие п. 1 мы можем вверху программы определить DEO>>> BAUD_RATE, а строку TMR0 = 133; определить через макрос DEO>>> исходящий из FOSC и DEO>>> BAUD_RATE. и HИКАКИХ подборов.
DO>> Hе можем, потому что узнать сколько тиков таймера контроллер входит DO>> в прерывание можно, проанализировав этот код, но не нужно, потому DO>> что подобрать путем нескольких перепрошивок кристалла проще. При DO>> твоем методе константа будет той же самой, а программа усложнится.
DEO> при моем методе я в начале программы укажу DEO> FOSC и RS232_BAUD_RATE и у меня интерфейс будет работать именно на DEO> выбранном мной BAUD_RATE. DEO> если мне понадобится уйти на 1200 бод, например то я поменяю DEO> константу в начале файла, а ты возьмешься опять за осциллограф
Нет. И от метода это не зависит. На десятый круг пошли. А все потому, что тебе лень сделать и убедиться. Учитывая, что от этого же таймера и остальные "часы" в программе работают, одной константой все равно не обойдешься. Формула для baudrate была в соседнем письме, но от необходимости померять частоту осциллографом она не спасает.
DEO>>> теперь то что о дальнейшей оптимизации:
DEO>>> теперь мой код что я добавил назовем вводом-выводом, а твой DEO>>> (модифицированный как я описал выше) назовем логикой работы RS.
DEO>>> так вот я говорю, что если немного поднапрячь мозги и избавиться DEO>>> от циклов ожидания которые у тебя есть внизу (надеюсь уже не DEO>>> будем придираться к этому термину ;) ), а написав нормальный DEO>>> менеджер
DO>> У меня нет никаких циклов ожидания. И нет никакого верха-низа. DEO> tputstr и printi не возвращают управления пока не произойдет DEO> передача.
Они, как я уже говорил, вызывают idle(), в котором и реализована вся управляющая логика программы. А терминалу в это время делать все одно нечего - только ждать.
DEO> из за этого ты в них вынужден например вызывать CLRWDT. =>
DEO> избыточность
Не в них, а в Idle (ну и еще в требующих ожидания записи в eeprom). Именно там, где и надо. WDT должен именно за основной частью, которая в idle следить. Если она не работает - ахтунг.
DEO> и верх-низ у тебя классический почти - прерывание вверху а вся DEO> остальная программа внизу ;) только tputch и вклинился ;)
В каком порядке скопировал, в таком и расположено.
DEO>>> процессов внизу (хоть тупой перебор функций например) мы можем DEO>>> логику работы RS перенести вниз. (скорость такая маленькая что DEO>>> это запросто)
DO>> Hапиши полностью, покажи что это работает и код - тогда обсудим. DO>> Теории мне не интересно.
DEO> я пока вижу что то что представлено и работает - случайность
Однако оно - работает. А что ты там видишь - не имеет большого значения. А то, что ты сделал (точнее не сделал) не работает, а только место в эхе занимает. Хотя за время этой дискуссии уже можно было сделать.
DEO>>> да деление уже использовать нельзя будет (хотя если часть логики
DO>> А вот это уже не годится. Я не хочу думать о том сколько времени DO>> что выполняется в основном цикле. и что там можно,, а что нельзя DO>> использовать. DO>> Будет надо, хоть весь math.h использую (что я собственно в другом DO>> проекте и делаю).
DEO> это тоже нормальный подход, только не всегда оправдан отдать 50% DEO> процессорного времени какому-то умножению и оставить основной DEO> задаче 1-2% это удавить напрочь перспективу развития девайса
Это решается индивидуально. Есть критичные ко времени места, а есть нет.
DEO>>> оставить все же наверху - перейти к сдвиговым регистрам то можно DO>> Врядли. Хотя 4800 наверное можно вытянуть, оно там на грани. DEO> врядли именно потому что на 4800 плаванья фронтов Send будут DEO> критично вылетать из диапазона.
Это очень легко лечится.
DEO> то есть если у тебя сейчас прерывание занимает 50% времени и ошибка DEO> выставления фронта Send - 22% (верхний нижний предел надо DEO> посчитать)
Это задержка, а не ошибка.
DEO> то на 4800 это будет 100% и 44%
DO>> Бери и делай, кто тебе не дает?
DEO> я и делаю думаешь поправить методические ошибки в твоем коде это не DEO> труд?
Это напрасный труд. Не надо править, и тем более выдумывать несуществующие ошибки. Надо сделать свое.
dima
formatting link