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 12:10:58 +0400:
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
formatting link