DEO>> вот тут задержка получается существенная и всякий раз разная (в DEO>> зависимости от того по каким веткам пробежало) DO>
DO> Существенная, в среднем около половины периода прерываний. И что, с того? DO>
DEO>> вот я и говорю надо отделить логику низкоуровневого управления от DEO>> выдачи сигналов на выводы. DO>
DO> К чему ты это говоришь? Какая разница когда прерывание закончится, если DO> это DO> происходит до прихода следующего? выше ты сказал что половину процессорного времени занимает прерывание. субя по коду 2/3 этого времени занимает функция Receive. то есть задержка на передачу у тебя на время 1/3*2/3 = 2/9 от периода тактирования передачи (первая 1/3 от того что прерывания у тебя с утроенной частотой идут). на задержка на 22% можно было бы наплевать если бы время выполнения процедуры Receive было бы постоянным. оно же у тебя случайное (в зависимости от того по каким веткам пройдет)
следовательно то что данная реализация сопрягается с другими девайсами по последовательному интерфейсу - есть такая же случайность :)
не хочешь делать методически более правильно, я тебя не неволю просто когда-нибудь проект станет больше и будешь искать баги
а на AN такой пример ну совсем не годится
DO> Реализуй, а я посмотрю. Ты просто путаешь два несвязанных между собой DO> вопроса. я не путаю
DO> Мне ничего не кажется, и делать это можно где угодно, просто там это делать DO> проще. естественно проще и не думать тоже проще ;)
DO> Выдача с приемом вообще не связаны. именно связаны: функция Send у тебя начнет работать только после того как закончит Receive. модификация одного влияет на время начала выполнения другого. мало того по каким веткам пройдет первое влияет на фронты второго.
DO> Значит это надо с той же скоростью делать снаружи. Разницы я не вижу, кроме DO> того, что так сложней. разница в более рациональном использовании процессорного времени. можно больше квантов отдать другим процессам, например
DEO>> я тут опишу такой алгоритм чтобы по максимуму не переделывать твой, DO>
DO> Hе надо теорий. Hе надо. Или пример кода или молчание. я тебе фактически diff на твой код дал, что еще надо?
DEO>> что мы получили? DEO>> 1. мы получили что время от выставления флага переполнения таймера DEO>> 0 до выставления сигнала на ножке TTx и принятия сигнала с ножки DEO>> TRx всегда одинаковое. как бы там программа дальше не работала DO>
DO> Оно и так всегда одинаковое. если тупо повторять одно заклинание, то можно вызвать духа ;) первое присвоение TTx в 188 строке а прерывание начинается на 80-й строке
то есть между входом в прерывание и выдачей сигнала на TTx у тебя >=100 строк кода с ветвлениями => кода выполняющегося случайный интервал времени между N и M мкс (считать лень)
=> то что у тебя компьютер принимает случайно поставленный фронт есть лишь результат того что ты за допуски не вылетел (что тоже случайно)
DEO>> 2. вследствие п. 1 мы можем вверху программы определить BAUD_RATE, DEO>> а строку TMR0 = 133; определить через макрос исходящий из FOSC и DEO>> BAUD_RATE. и HИКАКИХ подборов. DO>
DO> Hе можем, потому что узнать сколько тиков таймера контроллер входит в DO> прерывание можно, проанализировав этот код, но не нужно, потому что DO> подобрать путем нескольких перепрошивок кристалла проще. При твоем методе DO> константа будет той же самой, а программа усложнится. при моем методе я в начале программы укажу FOSC и RS232_BAUD_RATE и у меня интерфейс будет работать именно на выбранном мной BAUD_RATE. если мне понадобится уйти на 1200 бод, например то я поменяю константу в начале файла, а ты возьмешься опять за осциллограф
DEO>> теперь то что о дальнейшей оптимизации: DO>
DEO>> теперь мой код что я добавил назовем вводом-выводом, а твой DEO>> (модифицированный как я описал выше) назовем логикой работы RS. DO>
DEO>> так вот я говорю, что если немного поднапрячь мозги и избавиться от DEO>> циклов ожидания которые у тебя есть внизу (надеюсь уже не будем DEO>> придираться к этому термину ;) ), а написав нормальный менеджер DO>
DO> У меня нет никаких циклов ожидания. И нет никакого верха-низа. tputstr и printi не возвращают управления пока не произойдет передача. из за этого ты в них вынужден например вызывать CLRWDT. => избыточность
и верх-низ у тебя классический почти - прерывание вверху а вся остальная программа внизу ;) только tputch и вклинился ;)
DEO>> процессов внизу (хоть тупой перебор функций например) мы можем DEO>> логику работы RS перенести вниз. (скорость такая маленькая что это DEO>> запросто) DO>
DO> Hапиши полностью, покажи что это работает и код - тогда обсудим. Теории мне DO> не интересно. я пока вижу что то что представлено и работает - случайность
DEO>> да деление уже использовать нельзя будет (хотя если часть логики DO>
DO> А вот это уже не годится. Я не хочу думать о том сколько времени что DO> выполняется в основном цикле. и что там можно,, а что нельзя использовать. DO> Будет надо, хоть весь math.h использую (что я собственно в другом проекте и DO> делаю). это тоже нормальный подход, только не всегда оправдан отдать 50% процессорного времени какому-то умножению и оставить основной задаче 1-2% это удавить напрочь перспективу развития девайса
DEO>> оставить все же наверху - перейти к сдвиговым регистрам то можно DO> Врядли. Хотя 4800 наверное можно вытянуть, оно там на грани. врядли именно потому что на 4800 плаванья фронтов Send будут критично вылетать из диапазона. то есть если у тебя сейчас прерывание занимает 50% времени и ошибка выставления фронта Send - 22% (верхний нижний предел надо посчитать) то на 4800 это будет 100% и 44%
DO> Бери и делай, кто тебе не дает? я и делаю думаешь поправить методические ошибки в твоем коде это не труд?