DO> Hет никакой связи. Я же уже дважды объяснил почему число в таймере надо DO> подбирать. От момента возникновения прерывания до начала его обработки DO> проходит некоторое время это время всегда одинаковое, потому подбор в твоем случае связан только с тем что если "разделить" твое прерывание, то до обработки прерывания по передаче данных у тебя сперва должно обработаться прерывание по приему данных. вот тут задержка получается существенная и всякий раз разная (в зависимости от того по каким веткам пробежало)
вот я и говорю надо отделить логику низкоуровневого управления от выдачи сигналов на выводы.
ты просто слушать не хочешь, хотя я уже это 10 раз повторил. так бы и на PIC можно было 4800 реализовать ;)
DO>>> Этого я совершенно не понял. Ты про обработку команд, вводимых с DO>>> терминала? я ответил на этот вопрос уже два раза я про выдачу/распознавание битов данных и битов старт/стоп/четность вот ниже ты и отквотил
DEO>> нет про низкоуровневую реализацию RS232 старт-бит данные (от 5 до 9 DEO>> бит) бит четности два стоп-бита DO>
DO> Так где же, кроме прерывания это делать? можно и в прерывании, если тебе кажется что кроме как там негде ;) но тогда в прерывании это делать _после_ того как очередной бит будет выдан на ногу и принят с неё :)
DEO>> парсить/собирать в кучу эти данные если в основной программе, а в DEO>> прерываниях только двигать, то в прерываниях можно будет не DEO>> заботиться о подборе значений таймера :) DO>
DO> Hапиши на С, я так не понимаю. А не заботиться нельзя, даже если в DO> прерывании я только ножкой дергаю. может быть и напишу, но вроде я внятно объясняю вот на человеческом языке алгоритм для варианта как ты хочешь, "все в прерываниях" (хотя в прерываниях вовсе не нужно этого делать)
я тут опишу такой алгоритм чтобы по максимуму не переделывать твой, а скажу лишь, что если пойдешь и поглядишь какую-нибудь аппаратную реализацию RS232 и примерно так же реализуешь в виде сдвиговых регистров то код станет раза в полтора меньше можно сделать и логику отделить в другое место, ну да ладно.
короче доработка напильником:
твоя void interrupt sys_int(void) {
добавляем строки static bit inbuffer=0; // тут могут быть начальные static bit outbuffer=0; // значения другие - тебе виднее
сразу после T0IF = 0; добавляем строки
inbuffer=TRx; TTx=outbuffer;
а дальше весь твой же код как он есть, но все обращения к TTx и TRx замени на обращения к inbuffer outbuffer.
что мы получили?
- мы получили что время от выставления флага переполнения таймера 0 до выставления сигнала на ножке TTx и принятия сигнала с ножки TRx всегда одинаковое. как бы там программа дальше не работала
- вследствие п. 1 мы можем вверху программы определить BAUD_RATE, а строку TMR0 = 133; определить через макрос исходящий из FOSC и BAUD_RATE. и HИКАКИХ подборов.
теперь то что о дальнейшей оптимизации:
теперь мой код что я добавил назовем вводом-выводом, а твой (модифицированный как я описал выше) назовем логикой работы RS.
так вот я говорю, что если немного поднапрячь мозги и избавиться от циклов ожидания которые у тебя есть внизу (надеюсь уже не будем придираться к этому термину ;) ), а написав нормальный менеджер процессов внизу (хоть тупой перебор функций например) мы можем логику работы RS перенести вниз. (скорость такая маленькая что это запросто)
да деление уже использовать нельзя будет (хотя если часть логики оставить все же наверху - перейти к сдвиговым регистрам то можно дооптимизироваться и до возможности применять деление), но т.к. процессорное время будет использоваться более рационально вполне вероятно мы сможем и BAUD_RATE поднять раза в два. два раза скорее всего и PIC вытянет с нормальным подходом :)
PS: а если ты еще перепишешь strtoi по тому же принципу как я переписал твою printi то получишь еще одну такую же (если не больше) экономию в объеме и скорости выполнения :)
PPS: ну что, если не разобрал свой макет на котором это собрано попробуешь доделать в соответствии с моим рекомендациями?
DO> Для этого из tputch вызывается idle. вот я и говорю сделать классический событийный вид, а не ставить костыли :)
DO> Во-первых, никто никому и ничего не должен. Процессы должны получать свое DO> время, они его и получают. И никакого хаоса и путаницы нет и в гораздо DO> более DO> сложных программах. ты где-то выше сказал фразу "для того чтобы получить нормальный Апликейшн нотес", а уж коль взялся за такого уровня задачу, изволь таки не открещиваться или прекратим разговор :) в AN код должен быть прост и понятен у того кто читает не должно быть продираний сквозь дерево функций с циклическими завязками как у тебя. алгоритм должен быть четко виден.