Цитата(stells @ 2.12.2009, 8:46)
мне кажется Вы немного перегрузили прерываниями задачу:
1.понятно, нужно вытащить данные до прихода новых, иначе потеряются
2.3.4.действительно нужна высокая точность определения переходов? речь идет о какой частоте?
5.6.7.тоже самое... нужна ли точность?
8.нужно
9.вопрос, все зависит от общего алгоритма работы. и опять же от частоты
10.большой вопрос, зависит от того, что передаем и как реагирует другое устройство на таймауты.
11.вопрос, все зависит от общего алгоритма работы.
так что очевидных прерываний всего 2, остальные надо обосновывать, дабы стек не закончился в первом же такте
5.6.7. В реале у меня получилось порядка 20 000 отсчетов. Тут дело не в точности а в дрожании фронта.
Это связано с тем, что глаз заказчика не должен видеть мерцания ламп из-за джиттера.
Если таковое происходит, то он отказывается платить деньги.
9. При моем подходе это нужно обязательно.
10. Аналогично п. 9.
11. Аналогично п.п. 9. 10.
Чтобы стек не закончился на первом такте нужно либо воспользоваться программным поллингом источников прерываний, как я сделал на PIC18F252, либо выбрать правильный МК.
Цитата(MrYuran @ 2.12.2009, 9:54)
Потратив 3 года на собственные велосипеды в области многозадачности, нынче полностью согласен с zltigo и Сергеем Борщом, что лучше использовать стандартные решения типа общепринятых RTOS, и только в случае особых напрягов пытаться делать своё.
А начинать точно нужно именно с изучения имеющихся решений.
Лучше не использовать общепринятых RTOS. А по поводу велосипедов могу только поинтересоваться, а сколько Вы их попробовали?
Про этих двух перцев с элхи могу сказать только одно - у них есть только два мнения - их и неправильное.
Скажу по секрету, что толкутся они всю свою жизнь только в одном маленьком разделе программирования.
Там, где хляет их достаточно примитивная метода, укладывающаяся в С или С++.
Впрочем, это мое личное мнение об их подходе. Вы имеете право иметь иное.
По поводу имеющихся решений не могу не согласиться. У меня оно уже есть.
Цитата(_pasha @ 2.12.2009, 11:30)
Не грузись, Прохожий!
Уважаемый Павел!
Предлагаю общаться в принятом в приличном обществе стиле. Т. е. на Вы.
Цитата(_pasha @ 2.12.2009, 11:30)
1. Прерывание Rx UART пхнет все, что есть, в кольцевой FIFO - небольшого размера, байт 8..16
2. Tx UART на входе имеет указатель на буфер и его длину. Не напрягая основное время, выдает байт по указателю, после того, как счетчик длины стал ==0, самовыключается.
3. Tx Complete - в терминах АВР - просто выключить передачу по 485
Задача уже решена года 3 тому назад на PIC18F252. С временными интервалами между символами, равными указанным в стандарте на MODBUS/RTU.
Решение обкатано совместно с PLC CJ от OMRON с коммуникационным процессором, с софт PLC OWEN ПЛК150, а так же с большим количеством разновидностей PLC от DELTA Electronics. На двух буферах. Зачем экономить память, если ее и так есть? А возня с кольцевым буфером и указателями только усложняет дело.
Цитата(_pasha @ 2.12.2009, 11:30)
Процессы
1. Подбирает FIFO уарта, отправляет в 256 байт буфер, определяет адрес получателя, парсит сообщение (походу, ведет статистику битых/нормальных пакетов для модбаса), формирует ответ в том же самом буфере, включается на передачу, ждет паузу опросом системного таймера и инициирует прерывание от Tx, указатель и длину буфера ему подсовывает. Его можно не усложнять введением переопределяемой точки входа, но если система надолго завесится над обработкой - лучше крупные шаги вручную разбить на более/менее мелкие и сделать так, чтобы выполнение продолжалось при последующих вызовах функции процесса.
3. Индикаторный - задача - не грузить остальных своими тактами ожидания, а отдавать управление при ожидании.
5. Анализатор АЦП - берет в означенном буфере значение, помечает его как обработанное, чтобы не возвращаться к нему вновь, делает с ним все, что надо и быстренько отдает управление. Наверное, оформлять его тредом точно ненада буит.
6. Вся остальная математика строится по правилам - если делается больше одной итерации - надо отдать управление, затем продолжить работу при последующем вызове.
7. Мыргалки светодиодами - проверили сколько тиков с сист. таймера прошло - и вкл/выкл светодиод.
Все это размещено в суперлупе.
Цитата(_pasha @ 2.12.2009, 11:30)
2. Клавиатурный - по тикам таймера
4. EEPROM -тоже не грузить систему при записи параметров
Эти два процесса сделаны частично в суперлупе, частично в прерывании.
Цитата(_pasha @ 2.12.2009, 11:30)
По прикидкам должно хватать ATMEGA16 с головой. 16МГц кварц.
Компилер WinAVR последний.
В реале PIC18F252, MCC18+ASM.
Я то, собственно чего...
Предлагаю обсудить несколько подходов к решению задачи.
Интересно услышать мнение любителей RTOS, а так же С++.
Только с конкретикой - где, чего и сколько?