DpInRock

А зачем его сдвигать? Есть такое понятие - голова (head) и хвост (tail ) буфера. УАРТ пишет по указателю head. Чтец читает по указателю tail? инкрементируя его соотв. образом, догоняя head...

Вообще-то у такого рода компонентов есть собственный буфер, достаточно большой. Не надо вообще ничего делать. А чтобы не отвлекаться - использовать надо этот компонент в отдельном потоке. Пусть декодирует пакеты так, как будто это одна единственная задача. Единственная проблема, визуальное проектирование для отдельного потока не катит. Там все руками надо. (Что намного сложнее, чем написать все это используя винапи. ).

Это все у меня в Дельфи. Тоже пользовался компонентами. Теперь понял, что все эти компоненты - отстой полный. А добиться вашим компонентом легко. Есть у вас событие по приему данных. Ну проверяйте внутри него количество... Что тут такого-то? В чем проблема? Естетственно, учитывать следует, что ровно 14 байт в буфере будет исключительно редко. Ибо у контроллера ком порта есть фифо. Из которого данные забираются сразу все.

Так выглядит решение вашей задачи с использованием WinAPI. Рекомендую выбросить на помойку компонент. Ибо вы все равно не пользуетесь возможностями объектно-ориентированного программирования. А используете данный объект просто как библиотеку. Открытие компорта чуть сложнее. CommTimeOuts:_CommTimeOuts; DCB:_DCB; Procedure OpenPort(s:string); var c:dword; begin r_head:=0;r_tail:=0;r_point:=0;r_inv:=0;r_state:=0; if (hand>0) and (hand<>$FFFFFFFFF) then ClosePort; c:=CreateFile(PAnsiChar('\\.\'+s),GENERIC_READ or GENERIC_WRITE,0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL,0); if (c=$FFFFFFFF) then c:=0; CommTimeOuts.ReadIntervalTimeout:= $FFFFFFFF; CommTimeOuts.ReadTotalTimeoutMultiplier:= 0; CommTimeOuts.ReadTotalTimeoutConstant:= 0; CommTimeOuts.WriteTotalTimeoutMultiplier:= 0; CommTimeOuts.WriteTotalTimeoutConstant:= 1500; if (c>0) then SetCommTimeouts(c, CommTimeOuts); if (c>0) then begin getcommstate(c,dcb); //DCB.DCBlength:=0; DCB.BaudRate:=115200;//256000; DCB.Flags:=$1001; //DCB.XonLim:=0; //DCB.XoffLim:=0; DCB.ByteSize:=8; DCB.Parity:=0; DCB.StopBits:=0; //BuildCommDCB('256000,N,8,1',DCB); SetCommState(c, DCB); EscapeCommFunction(c,CLRRTS); EscapeCommFunction(c,CLRDTR); end; w_head:=0;w_tail:=0; hand:=c; end; Ну а дальше, все, что требуется, запустить отдельный поток с "while(1)...". Таким образом в буфере вы всегда будете иметь принятые данные. Вся информация о текущем количестве у вас будет. Для счастья больше ничего не требуется. И все это занимает 50 строк на паскале.

Вот эта ветка тоже бы могла стать "общеизвестным фактом". К слову, я действительно никогда не использую флаги ошибок периферии (любой). За бессмысленностью. -- Ошибки не существует, пока не выяснены точно условия ее возникновения. Ибо случайные сбои могут быть вызваны некачественным изготовлением микросхемы. А вот регулярные - чаще всего ошибкой разработчиков. И вот регулярные сбои достаточно легко определить. И задокументировать. Пока вот такой задокументированности я не встречал. (Правда и не искал, ибо проблемы не стояло).

Логично предположить, что если TWI работает с сотней микросхем, а с двумя - не работает, то эти две чем-то отличаются от этой сотни... Я даже могу предположить - чем. ( В бытность программирования телефонных кодеков от силиконлаб - у них при исчезновении внешнего фреймового сигнала с вероятностью 50% гробилась связь по SPI Т.е. тактирование интерфейсного блока связано с неким набором внутренних генераторов.)

Если умолчать об AVR (там я использовал только мегу8), то на 9261 и G45 управлял (управляю) TWI аудиокодеками, памятью, видеокамерой. Проблем не отмечено. Без прерываний (как бэ не нужны - все равно переключатель задач работает). Код получен "копипастой"+"удалить ненужное"+"слишком умное упростить" из примеров. Работало сразу. Осциллографом ни разу не тыкал в TWI. --- Вот тов. Алеф отметил явную ошибку гр. топикастера. А если бы не отметил, то вот в копилку мнений о TWI добавилось бы еще одно, причем совершенно напрасное.

Неча на TWI пенять. Работает безукоризненно.

Вы не в соcтоянии определить ОС компьютера, на которой стоит плата? Оригинально. Свежо.

Вообщет чем ближе к лампочке, тем меньшая яркость требуется. А вот чем дальше, тем больше. IR от чего-то отражаются, а от чего-то нет. От чего-то лучше, от чего-то хуже.

русский язык в прямоугольничке ничем не отличается от оного без прямоугольничков. Это раз. 2. Степень детализации прямоугольничка может быть разной. Сначала пишем в виде "ждем нажатие кнопки". А потом этот прямоугольничек детализируем "считываем содержимое порта прикладываем маску если не 0, то выход иначе все сначала" и так далее.

Вы ПРИДУМАЛИ себе определение "алгоритма", который и не понимаете. Алгоритм я вам написал. Примерно. Это и есть алгоритм. Алгоритмов решения одной задачи может быть великое множество. И выражены они могут быть в миллионе различных форм. Форма определяется разработчиком алгоритма. Или заказчиком.

Рано говорить о реализации алгоритма. Вы достаточно внятно описали то, что должно делать устройство. Но не имеете НИКАКОГО опыта в программировании. Безотносительно языка. Программа может быть короткой или длинной. Эффективной или не эффективной (по неким критериям). Но главный критерий - работает - не работает. Посему реализуйте все то, о чем написано ДО СЛОВ "о программировании говорить ...". Для начала можете на любом языке (включая русский) написать следущее. 1. Ждем нажатия какой-либо кнопки. 2. Если нажата только кнопка 1 то... Если нажата только кнопка 12 то... Если нажата только кнопка 13 то... И так далее. Программа будет не такой эффективной, но зато будет работать. А потом, глядя на нее можно применить некую сообразительность и упростить... (Не факт, что это будет возможно, да и не факт что это будет необходимо).

Теперь выяснил все бесповоротно и окончательно (надеюсь на это сильно, но тестирование занимает долгое время, надо ждать пока нагреется) Снижение тактовой частоты к хорошему не приводит. Просто глючить начинает позже. А вот существенное увеличение Vertical Porch (c 5 линий до 127 - как переднего так и заднего) - решило проблему. Полагаю, что 128 линий до и после хватает, чтобы LCD транзисторы чуток перекурили от дерганий туда-сюда. Т.е. реально хватило и 10 линий порча, но я взял чксло линий при котором видно дрожание и поделил на 2. Типа с запасом. Вот пока так. Почему я сразу не поставил 127 линий - не помню. Обычно я ставлю большие порчи, чтобы не так сильно загружать память прямым доступом.

В общем, вдруг интересно. Не в шлейфе дело. Когда программируешь - часто включаешь выключаешь, а когда просто ничего не делаешь - то не выключаешь. И вот тогда LCD начинает нагреваться. И действительно, в зависимости от картинки - начинает глючить. Уменьшение тактовой частоты убирает глюк. Который вновь возникает от дальнейшего прогрева. Кто греется, LCD или проц пока сказать трудно. Проц пока недоступен для охлаждения. --- Скорее всего LCD виноват. Если просто подуть на него слегка глюк прекращается сразу. Что удивительно, этот же LCD уже использовал в серии. Все нормально было. Но управлялся он LPC2478.

Не. Это обычный TFT, 24 битный интерфейс. Уже железно дело в шлейфе. Поставил новый экран - все работает нормально. Но по характеру неисправности - не в жисть не подумал бы на шлейф. И щас не думаю. Пойти в церву, воды купить и попрыскать вокруг. Других мыслей пока нет.

Общем, в копилку мирового опыта. Описанный эффект существует, повторяется строго. Чтобы специально такое сделать, надо долго потрудиться. Причина в самом LCD. Вернее, в шлейфе. Стоит его немного изогнуть - нормальное изображение появляется без всякого программного вмешательства. Но как трабл со шлейфом может давать четкий триггерный эффект, абсолютно четкий и абсолютно триггерный - пока не представляю. Рад этому несказанно, ибо уже привинтил к PutPixel фичу, которая ставит серую точку в конец видеопамяти. В общем, пока все равно чудо.

Процессор AT91SAM9G45. Видеопамять с 70000000, DDr2x16. 24 битный цвет. 1. Делаем черный экран записью нулей. 2. Пишем, рисуем, что хотим делаем - но не белым цветом. 3. Стоит хоть одну точку сделать белой - весь экран становится белым. (Хотя видеопамять как таковая содержит верные данные). 4. Ставим в ЛЮБОМ месте "НЕ БЕЛУЮ" точку. Изображение восстанавливается. 5. Ставим белую куда-нибудь опять. Весь экран белый. Перестройка DMA LCD, целиком самого LCD ничего не дает - экран остается белым (в смысле, при отклюении и перенастройке он становится черным, но после окончания инициалзации - белый). Примечание 1 Программа, которая всем этим управляет находится в той же самой памяти. Примечание 2. "НЕ БЕЛАЯ" точка, которая восстанавливает изображение ДОЛЖНА СОДЕРЖАТЬ В КАЖДОМ БАЙТЕ ЦВЕТА не менее двух единичных битов. К примеру, точка цветом 88 88 88 не восстанавливает изображение, а точка 33 33 33 - восстанавливает. (33 00 33 - не восстанавливает, 53 35 75 - восстанавливает). ------------------- Этот глюк не определяется в обычных условиях, когда на экране многоцветие и мельтешение. А вот попробовал сменить фон калибровки экрана на черный, на котором рисовал чисто белый крестик - и получил этот эффект. Ума не хватает помыслить что это. К сожалению плата в единственном экземпляре. --- Белая точка ничему не вредит, если на экране полноцветная картинка реальная. Но если 90% экрана одного цвета, причем простого цвета - черный, чисто синий например, то белая точка работает....

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

CCCV стиль работы всегда приводит к таким траблам.

Смотря что вы хотите получить от этой схемы. Входная емкость Q2 и этот резистор образуют цепь задержки выключения. Время - примерно R*C (очень примерно). (Это касательно максимального значения). Минимальное определяется максимальным током Q1.

Виндовый драйвер дергает RTS нормально. А вот RC цепочку с транзистором на переключение направления передачи (от TX) - я бы поставил. Типа, как дополнительную возможность. (Переключение на выход при наличии сигнала на TX, - на вход - при отсутствиии).

ROM==Read Only Memory.

Уберите конденсаторы для начала. Напряжения питания обоих устройств должно совпадать. Подтяжку к линиям RX поставьте абы все равно какую, 2.7k. Далее - длина линии. Максимальная скорость передачи связана с длиной. Пример, при уровнях +-12 вольт, скорость 9600, длина линии не более 15 метров. Это к примеру.

Всё.