Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Способы программирования МК
Шарага > Soft - НЕ железо > Программирование МК
Прохожий
Основной проблемой при программировании МК является организация многозадачности.
Самый распространенный пример:
1. Кнопки.
2. ЖКИ.
3. Последовательный порт.
4. Собственно задача, для которой все, что описано вверху предназначено.
Пункт 4 может подразумевать несколько задач.
Рассмотрим простой пример.
Допустим, надо сделать фазовое управление мощностью для нескольких независимых выходных каналов.
Пусть их будет три.
Девайс должен отслеживать точки перехода через ноль для трех фаз.
Ноль пусть будет рабочий или нерабочий в зависимости от параметров.
Вполне допустимо объединение датчиков фаз.
Он должен формировать импульсы управления оптотиристорами каналов в зависимости от заданных для них углов отпирания.
При этом HMI включает в себя двухстрочный индикатор по 16 символов в строке, три кнопки +, -> и Ентер.
Так же присутствует протокол ModBus/RTU на RS485 с максимальной скоростью 115200 кбит/c.
Добавим сюда наличие трех каналов измерения напряжения на нагрузке (RMS) и, соответственно, тока.
Ну, и заодно считалку мощности на нагрузке, а так же три ПИД регулятора по мощности на нагрузке или один в зависимости от рабочести нуля.
Такой вот постановк задачи.
Чтобы не разводить не нужных именно здесь религиозных споров, МК может быть любой.
К нему предъявляются достаточно простые требования.
1. Наличие системы прерываний.
2. Наличие трех таймеров с разрешением не менее 16 бит.
3. Наличие AЦП с приемлемой скоростью.
4. Наличие аппаратного USART.
5. Наличие бесплатного С компилятора и отладочной среды.
Ну, и чтобы подогреть интерес, сообщу, что такие устройства используются в линиях средней и малой производительности по выдуву пластиковых бутылок.
Предлагаю обсудить разбивку общей задачи на подзадачи.
Затем обсудим способы их решения с обеспечением их псевдопараллельности..
Прохожий
Цитата(Огурцов @ 1.12.2009, 23:24) *
Задача решается добавлением в камень одного-двух-трех ядер. Фсе.

На самом деле, задача несложная. Решается вполне себе одномоторным камнем.
Причем дешевым. На PIC24 вообще на раз.
Все проблемы здесь - в организации многозадачности.
Прохожий
Цитата(maximiz @ 2.12.2009, 0:57) *
Я, наверное, поступил бы следующим образом:

1. оценил реально необходимое кол-во выборок АЦП по трёхфазке,
2. приблизительно оценил бы кол-во тактов на эту выборку +алгоритм пид
3. зная времена между фазами трёхфазки и пид, постарался бы засунуть в каждый Nый промежуток опрос клавиатуры, ком/рс-485, вывод на жки, забив бы остальное меняющимся от колва тактов "работы с предыдущей фазой" и тактов "работыс I/O" кол-вом NOP. Или, ежели по прерываниям от каждой фазы- не забивал бы NOP, просто забил бы...

Прохожий, какие недостатки? "Дяденька, я ведь не настоящий сварщикпрограммист..."©

Недостатков, в принципе, нет. Вы описали классический "Суперлуп" без прерываний.
На простом суперлупе такая задача не решается.
В ней присутствуют противоречия между обменом данными по последовательному каналу (поскольку данные терять нельзя) и синхронизацией с сетью.
На наше счастье в современных МК имеется в наличии серьезная система прерываний, т.е. внешних событий.
Причем, прерывание с более важным приоритетом может отложить выполнение обработчика другого прерывания с менее важным приоритетом.
В связи с этим надо начать с расстановки важности прерываний - событий.
Мой вариант такой.
1. Прерывание от приемника USART.
2., 3., 4., Внешние прерывания от переходов фаз через ноль.
5., 6., 7., Прерывания от таймеров, формирующих углы отпирания.
8. Прерывания от системного таймера (здесь определяется время квантования для ПИД, опрашиваются кнопочные входы и т. д.)
9. Прерывание от АЦП.
10. Прерывание от передатчика USART.
11. Прерывания от IIC или от внутренней EEPROM (надо для хранения параметров)
Все остальное можно поместить в суперлуп и выполнять последовательно.
11. Обслуживание индикатора в зависимости от кнопок.
12. Расчет алгоритма ПИД регулятора (торов).
Теперь о просматриваемых задачах.
В явном виде этих задач не так много.
1, 2, 3. Обнаружение и фильтрация переходов через ноль.
3, 4, 5. Выдача импульсов управления.
6. Работа с последовательным каналом.
7. Накопление среднеквадратичных значений напряжений и токов.
8. ПИД-регуляторы.
9.ЖКИ.
10. Кнопки (устранение дребезга).
11. Общение с внешней или внутренней EEPROM.
И немного о данных.
Нам потребуется два буфера - буфер приема и буфер передачи емкостью в 256 байт каждый (таково требование протокола ModBus/RTU).
Остальное пока в тумане.
Теперь можно приступить к выбору МК.
Сформируем требования к нему.
1. Наличие перечисленных выше аппаратных средств
1.1 4 таймера.
1.2 АЦП с нужной скоростью.
1.3 USART с возможностью аппаратного управления направления потоком (поскольку RS485 - это полудуплекс).
1.4. Наличие аппаратного IIC для внешней ретентивной памяти для хранения параметров или внутренней EEPROM.
1.5 Приветствуется наличие аппаратной поддержки параллельного порта (для ЖКИ)
2. Определим минимальную скорость.
По требованию протокола ModBus/RTU в символе содержится 11 бит (1 стартовый, байт данных, бит паритета, стоповый бит).
Следовательно самый быстрый процесс - это отправка последовательности данных.
Вмешательство процессора МК в него будет требоваться каждые 11/115200 = 95 мкс.
За это время "мотор" МК должен успеть выполнить около 1000 команд - этого вполне достаточно, чтобы не потерять переходы через ноль и иметь запас по времени.
3. Память программ. Пока особого значения не имеет. У современных МК ее хватает с головой.
4. Память данных - не менее 512 байт.
5. Приветствуется наличие внутренней EEPROM. Если ее нет, то потребуется наличие IIC.
Итак, мы имеем задачу и критерии для выбора МК под нее.
stells
Цитата(Прохожий @ 2.12.2009, 2:16) *
В связи с этим надо начать с расстановки важности прерываний - событий.
Мой вариант такой.
1. Прерывание от приемника USART.
2., 3., 4., Внешние прерывания от переходов фаз через ноль.
5., 6., 7., Прерывания от таймеров, формирующих углы отпирания.
8. Прерывания от системного таймера (здесь определяется время квантования для ПИД, опрашиваются кнопочные входы и т. д.)
9. Прерывание от АЦП.
10. Прерывание от передатчика USART.
11. Прерывания от IIC или от внутренней EEPROM (надо для хранения параметров)
Все остальное можно поместить в суперлуп и выполнять последовательно.

мне кажется Вы немного перегрузили прерываниями задачу:
1.понятно, нужно вытащить данные до прихода новых, иначе потеряются
2.3.4.действительно нужна высокая точность определения переходов? речь идет о какой частоте?
5.6.7.тоже самое... нужна ли точность?
8.нужно
9.вопрос, все зависит от общего алгоритма работы. и опять же от частоты
10.большой вопрос, зависит от того, что передаем и как реагирует другое устройство на таймауты.
11.вопрос, все зависит от общего алгоритма работы.
так что очевидных прерываний всего 2, остальные надо обосновывать, дабы стек не закончился в первом же такте
MrYuran
Цитата(stells @ 2.12.2009, 8:46) *
так что очевидных прерываний всего 2, остальные надо обосновывать, дабы стек не закончился в первом же такте

Да ладно...
при нормальном использовании стек почти не расходуется, да и 1-2к рама в более-менее средних кристаллах "хватит всем (С)"
При такой постановке задачи надо брать кристалл с правильными таймерами.
Например, мой любимый MSP430, у которого 2 таймера, у каждого минимум по 3 защёлки с внешним захватом и железным выходом.

Потратив 3 года на собственные велосипеды в области многозадачности, нынче полностью согласен с zltigo и Сергеем Борщом, что лучше использовать стандартные решения типа общепринятых RTOS, и только в случае особых напрягов пытаться делать своё.
А начинать точно нужно именно с изучения имеющихся решений.
stells
Цитата(MrYuran @ 2.12.2009, 9:54) *
Да ладно...
при нормальном использовании стек почти не расходуется, да и 1-2к рама в более-менее средних кристаллах "хватит всем (С)"

я утрировал конечно, скорее всего речь идет о 50Гц и стек нужен максимум байт на 100, т.к. между переходами 3-х фаз через 0 все успеет отработать, но все-равно прерываний много... мне кажется smile.gif
_pasha
Цитата(Прохожий @ 2.12.2009, 1:16) *
Мой вариант такой. 

Не грузись, Прохожий!

1. Прерывание Rx UART пхнет все, что есть, в кольцевой FIFO - небольшого размера, байт 8..16


2. Tx UART на входе имеет указатель на буфер и его длину. Не напрягая основное время, выдает байт по указателю, после того, как счетчик длины стал ==0, самовыключается.

3. Tx Complete - в терминах АВР - просто выключить передачу по 485

4. Выделяем один системный таймер для организации тиков 1мс (инкремент счетчика тиков в прерывании) Это - для интерфейса, а также для паузы при включении передачи по RS485

5. Прерывание АЦП. Задача - обеспечить переключение каналов в требуемой последовательности и беспаузный рестарт преобразователя. Все данные складываются в буфер с возможностью отметить каждое значение как прочитанное. Т.е. для 10-битного результата при записи в 16-битную переменную взводим старший бит, а процесс уже обнулит когда обработает.

6. Прерывания от компараторов на переход через ноль и для формирования углов отпирания - тут все ясно. На входе прер. компаратора соотв. канала - угол отпирания, переведенный во временной интервал. При наступлении прерыв. - проверяем валидность перехода через ноль (проще всего - приблизительно, по отметкам системного таймера из п.4) и задаем нужный интервал, каскадно разрешая прер. на выход угла отпирания.

7. Берем по принципу protothread - организуем процессы вида

Код
void *process(void *proc_pc, void *local_paramset);

void *process(void *proc_pc, void *local_paramset)

{

if(proc_pc != NULL) goto proc_pc;

// всяко - разно

if(uart_rx_event()) return &&State1; // гнусь допускает использование меток как указателей для последующих косвенных переходов

return NULL; // 

State1: // при следующем вызове мы уже тута

}

int main(void)

{

 system_init();

for(;;)

{

static void *pc1=NULL;

pc1 = process(pc1,NULL);// итд для всех процессов

}

return 0;

}


Это все для гнуся. Про бесплатный компилер - соблюли smile.gif

Про данные. Буфер 256 байт все-таки можно и один оставить


Процессы 

1. Подбирает FIFO уарта, отправляет в 256 байт буфер, определяет адрес получателя, парсит сообщение (походу, ведет статистику битых/нормальных пакетов для модбаса), формирует ответ в том же самом буфере, включается на передачу, ждет паузу опросом системного таймера и инициирует прерывание от  Tx, указатель и длину буфера ему подсовывает. Его можно не усложнять введением переопределяемой точки входа, но если система надолго завесится над обработкой - лучше крупные шаги вручную разбить на более/менее мелкие и сделать так, чтобы выполнение продолжалось при последующих вызовах функции процесса.

2. Клавиатурный - по тикам таймера

3. Индикаторный - задача - не грузить остальных своими тактами ожидания, а отдавать управление при ожидании.

4. EEPROM -тоже не грузить систему при записи параметров

5. Анализатор АЦП - берет в означенном буфере значение, помечает его как обработанное, чтобы не возвращаться к нему вновь, делает с ним все, что надо и быстренько отдает управление. Наверное, оформлять его тредом точно ненада буит.

6. Вся остальная математика строится по правилам - если делается больше одной итерации - надо отдать управление, затем продолжить работу при последующем вызове.

7. Мыргалки светодиодами - проверили сколько тиков с сист. таймера прошло - и вкл/выкл светодиод.




По прикидкам должно хватать ATMEGA16 с головой. 16МГц кварц. 

Компилер WinAVR последний.

Прохожий
Цитата(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, а так же С++.
Только с конкретикой - где, чего и сколько?
AlexKlm
Идеально всё равно не получится. Я сделал программу (не для этого, но тоже кое-что критично), там у меня таймер на несколько десятков микросекунд работает (забыл уже), за время прерывания от таймера происходит складирование отдельных выборок. А в цикле while всей программы обрабатываются всякие прочие события на портах. Наверное будет правильно разрешать делать прерывание таймера чем либо другим лишь в крайнем случае, а лучше никогда. Так кстати в AVR прерывание от UART по приоритету ниже таймера по этой причине.

Делают AVR как назло с такими дико низкими частотами, всего 16 мгц. Каменный век. Зато процессор телефона 160 мгц с кучей никому не нужных выводов. Кто бы мог объяснить (попутно) логику такого явления?
Прохожий
Цитата(AlexKlm @ 2.12.2009, 22:54) *
Делают AVR как назло с такими дико низкими частотами, всего 16 мгц. Каменный век. Зато процессор телефона 160 мгц с кучей никому не нужных выводов. Кто бы мог объяснить (попутно) логику такого явления?

В принципе, скоростные и сверхскоростные процессы можно вынести в CPLD или FPGA. Будет значительно быстрее, чем в телефоне.
А на частоту смотреть надо с оглядкой... Это же не те вычислители. Там конвейеры разные. Реал тайм просто так в лоб, как мы привыкли, не выйдет.
А AVR не люблю. Он не совсем правильный. Производитель погнался за дешивизной и сделал очень кривую внутреннюю память данных.
Прохожий
Цитата(Огурцов @ 3.12.2009, 0:52) *
Нет, не можно. Это, если хотите, должно быть внутри проца, а не стоять отдельным корпусом.

Почему?
Цитата(Огурцов @ 3.12.2009, 0:52) *
Ну да, у интеля выходит, а атмел какой-то особенный.

Кроме гнусности в виде помойки 486 системы команд не выходит ничего.
Смешались в кучу кони, люди.
Без компилятора и линкера сломаешь себе практически все.
Хоть я и не люблю атмел, но заступлюсь.
По сравнению с Интелом - это вполне пристойный и обозримый проц.
Прохожий
Цитата(Огурцов @ 3.12.2009, 1:13) *
Сегодня уже нет места лишним корпусам. А что мешает-то ?

Мне лишний корпус не мешает. Заказчикам тоже.
И попробуйте без внешней логики сделать хотя-бы нормальный синхронизатор для многофазного преобразователя.
Цитата(Огурцов @ 3.12.2009, 1:13) *
Нормально. Зато все процы совместимы. А атмель видимо специально делает их несовместимыми. Хоть бы поленились чтоли.

Ничего нормального. У них был бардак с самого начала. Еще с I8080.
А чем Атмел не угодил-то.
Тем, что с Интелом не совместим? Или еще чем?
А любителям совмещений можно воспользоваться ЯВУ.
Кстати, несовместимых с Интелом и между собой МК хренова куча...
Цитата(Огурцов @ 3.12.2009, 1:13) *
А что, в компиляторе что-то должно поменяться ?
Флешь же одна, да ?
А новую нить запустить - записью в io-регистр.
Да, есть проблема с одновременным обращением к общим ресурсам.
Так "а вы не делайте" (с)

Новая нить и на одном ядре работает.
Рулит событийная многозадачность на прерываниях.
И никаких RTOS.
_pasha
Цитата(Прохожий @ 2.12.2009, 21:31) *
Уважаемый Павел!
Предлагаю общаться в принятом в приличном обществе стиле. Т. е. на Вы.


Если Вы восприняли фразу как фамильярность - что ж, приношу Вам свои извинения 


Цитата
А возня с кольцевым буфером и указателями только усложняет дело.

Здесь и далее - сугубо дело вкуса. Такие задачи реализуемы безусловно во множестве вариантов, что на пиках, что на авр.

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


По поводу С++ - не осуждаю smile.gif т.к. абсолютно равнодушен к ЕС++.



Цитата(Прохожий @ 2.12.2009, 22:09) *
А AVR не люблю. Он не совсем правильный. Производитель погнался за дешивизной и сделал очень кривую внутреннюю память данных.

правильный/неправильный, а пики 18-е по производительности делает smile.gif
MrYuran
Цитата(_pasha @ 3.12.2009, 15:28) *
По поводу использования ОСей (кстати, и приведения их в конкретный рабочий вид) - "не читал, но осуждаю". Имхо, ничего там волшебного и избавляющего от проблем нету. Единственное обстоятельство, которое может меня заставить юзать RTOS - участие в коллективном проекте.

Ну, в любом случае, что-то унифицированное. Прототред там, шедуллер или ещё чего...
Просто когда имеется одновременно десяток проектов, которые постоянно "дышат", да ещё некоторые в нескольких вариациях, и когда они реализованы в принципе одинаково, но "с нюансами"... Это начинает раздражать.
В конце концов, простейшая кооперативная ось типа jacOs точно вреда не принесёт. Зато ключевое слово - система, то есть систематизированный подход
Прохожий
Цитата(_pasha @ 3.12.2009, 15:28) *
Если Вы восприняли фразу как фамильярность - что ж, приношу Вам свои извинения

Дело не в фамильярности. Мы же с Вами русские интеллигенты, а не какие-то там англосаксы.
Цитата(_pasha @ 3.12.2009, 15:28) *
Здесь и далее - сугубо дело вкуса. Такие задачи реализуемы безусловно во множестве вариантов, что на пиках, что на авр.

Согласен. Поэтому и не оговаривал тип МК в самом начале.
Цитата(_pasha @ 3.12.2009, 15:28) *
По поводу использования ОСей (кстати, и приведения их в конкретный рабочий вид) - "не читал, но осуждаю". Имхо, ничего там волшебного и избавляющего от проблем нету. Единственное обстоятельство, которое может меня заставить юзать RTOS - участие в коллективном проекте.

Не так давно виртуально беседовал с очень грамотным программистом. В своих проектах он использует RTOS. Или не использует. В зависимости от обстоятельств. У него есть понятия "компилятор, диспетчер, алгоритм"
Т.е он предлагает разделить системное программирование и прикладное даже на уровне МК.
Иными словами.
Всю рутинную работу по оптимизации кода отдаем компилятору с выбранного ЯВУ.
Для этого, естественно, учим выбранный язык практически досконально.
Далее, свой алгоритм пишем так, чтобы обеспечить самодокументирование.
Для этого изучаем набор вполне определенных правил.
После этого в качестве диспетчера, обеспечивающего синхронизацию процессов, применяем RTOS.
Это позволяет скрыть механизм этой самой синхронизации, чтобы не отвлекаться на него, а сосредоточится только на своих задачах.
Для этого вникаем в эту самую ОС.
Т. е. определенная сермяжная правда в этом деле есть.
Полученный в результате всех этих манипуляций, код теоретически будет однообразным и будет представлять собой документ алгоритма.
И это обстоятельство, в свою очередь, позволит быстро создавать программный продукт, понятный широкому кругу пользователей, переносимый на другие платформы, легко верифицируемый.
Цитата(_pasha @ 3.12.2009, 15:28) *
По поводу С++ - не осуждаю smile.gif т.к. абсолютно равнодушен к ЕС++.

А что такое EC++?
Цитата(_pasha @ 3.12.2009, 15:28) *
правильный/неправильный, а пики 18-е по производительности делает smile.gif

Честно говоря, производительность AVR по отношению к PIC18 сильно преувеличена.
А для дальнейшего обсуждения этого вопроса надо открыть новую тему в разделе "Флейм (ругань)".

Цитата(MrYuran @ 3.12.2009, 16:03) *
Ну, в любом случае, что-то унифицированное. Прототред там, шедуллер или ещё чего...
Просто когда имеется одновременно десяток проектов, которые постоянно "дышат", да ещё некоторые в нескольких вариациях, и когда они реализованы в принципе одинаково, но "с нюансами"... Это начинает раздражать.

А для меня все и так одинаково.
Цитата(MrYuran @ 3.12.2009, 16:03) *
В конце концов, простейшая кооперативная ось типа jacOs точно вреда не принесёт. Зато ключевое слово - система, то есть систематизированный подход

Слова RTOS и "систематизированный подход" не синонимы. ПМСМ.
_pasha
Цитата(Прохожий @ 3.12.2009, 19:58) *
А что такое EC++?

С недавних пор так сокращают embedded C++

Цитата
Честно говоря, производительность AVR по отношению к PIC18 сильно преувеличена.

Только один бесспорный момент - умножение 16*16 и большое кол-во регистров - на них можно неплохо сэкономить тактики. Остальное - не столь трагично smile.gif Никакого флейма.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2020 IPS, Inc.