Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: RTOS во встроенных системах.
Шарага > Soft - НЕ железо > Программирование МК
Страницы: 1, 2, 3
Прохожий
Как и обещал открываю тему о RTOS во встроенных системах.
Сначала личное мнение о предмете спора.
По моему скромному мнению RTOS во встроенных системах не является необходимостью.
В большинстве применений можно обойтись имеющейся у большинства МК системой вложенных (или нет) приоритетных прерываний.
По моему мнению, лишний уровень абстракции между программой юзера и "железом" МК в виде RTOS не является необходимостью.
И вообще, представление программы в виде отдельных задач, подобных задачам PC - решение, требующее дополнительных оснований для применения.
Эти основания при решении определенного круга задач, безусловно, есть, но не для всех проектов такой подход обоснован.
ПМСМ, основные критерии к применению ОС следующие:
1. Работа над проектом коллектива разработчиков, слабо разбирающихся в смежных областях (механик и электрик, например).
2. Большой объем HMI, или наличие GUI.
3. Большое количество "дядиного" кода, выполненного под ту или иную RTOS.
Wise
Вы не могли бы, для начала, раскрыть аббревиатуру RTOS?
Дико извиняюсь.. smile.gif
Прохожий
Цитата(Wise @ 1.8.2010, 20:11) *
Вы не могли бы, для начала, раскрыть аббревиатуру RTOS?
Дико извиняюсь.. smile.gif

Real Time Operating System.
Операционная система реального времени.
Wise
Цитата
Операционная система реального времени.

Не очень, пока, понятно.
Что это такое, например, в приложении к (пресловутому) PIC16F?
Для меня будет хорошо, если такой пример будет стоять в самом начале темы.

Может, еще такие же найдутся.. smile.gif
Прохожий
Цитата(Wise @ 1.8.2010, 21:31) *
Не очень, пока. понятно.
Что это такое, например, в приложении к (пресловутому) PIC16F?
Для меня будет хорошо, если такой пример будет стоять в самом начале темы.

Может, еще такие же найдутся.. smile.gif

Лучше этого на русском языке вряд ли что найдется.
Wise
Цитата(Прохожий @ 2.8.2010, 0:37) *
Лучше этого на русском языке вряд ли что найдется.

Зафиксировал, почитаю.
Спасибо.
Wise
..Маленький оффтоп, извините..
Я начинал заниматься Qt, даже вопрос задавал, на этом форуме.
Никто ничего не ответил.
Ну и я пока забросил (не потому, что не ответили, конечно.. smile.gif )
Прохожий, подобные дела входят ли в круг ваших интересов, планируете ли вы открыть раздел на такие темы?
Прохожий
Цитата(Wise @ 2.8.2010, 22:58) *
..Маленький оффтоп, извините..
Я начинал заниматься Qt, даже вопрос задавал, на этом форуме.
Никто ничего не ответил.
Ну и я пока забросил (не потому, что не ответили, конечно.. smile.gif )
Прохожий, подобные дела входят ли в круг ваших интересов, планируете ли вы открыть раздел на такие темы?

Я пользуюсь Борландовским Билдером.
Нынче он официально бесплатный.
Для него есть масса всего. Даже кросс-платформенность декларируется.
Основное его преимущество - пакет специально создавался для тупых, типа меня.
Простейшие приложения делаются практически сразу.
А те, что посложнее через неделю.
И Архангельский нам всем в помощь...

Но, если кому будет интересен Qt, тогда пожалуйста без проблем.
one_man_show
Использую ОС РВ только в тех проектах, где много параллельных или псеводопараллельных задач, причем когда время жизни данных сильно отличается. Например, в одном треде нужно считать таймаут или задержку какую-нибудь, время которой кратно миллисекундам. В другом треде нужно принимать данные из АЦП, проверять уровень сигнала и по тому или иному уровни выставлять разные флаги. В третьем треде проверяем нажатие клавишь. В четвертом ждем звонок...Это небольшой пример того, как работает например мобильник Моторола Мини Так. В свое время приходилось хакать, это та трубка, у которой откидушка была и антенна выдвижная.
MrYuran
Реал тайм он как бы не всегда и нужен, в большинстве проектов достаточно кооперативной многозадачности (естественно, при правильной организации, никаких там пауз типа _delay_cycles(10000) ). У меня пока вообще простая каруселька, даже без приоритетов.
Однако, когда задач много, а времени мало, всё-таки организованная система даёт большую наглядность и удобство.
Пусть даже это не РТОС, а просто планировщик, наподобие Protothreads, который Pasha по любому случаю пеарит.
Конечно, можно всё на автоматах и флагах построить, но когда их (флагов и соответственно состояний) десятки, то очень трудно становится ориентироваться.
Может, и не очень, и не так уж и трудно, но всё равно испытываешь дискомфорт, роясь в многоэтажных конструкциях наподобие стихов Маяковского.

И совсем другое дело:
Код
os_task ProcessCommand(PRIORITY_5)
{
    WaitForEvent(&PacketReceived);
    CheckPacketStructure(&InputBuffer);
    ExecuteCommand(&InputBuffer);
}
Максим Зиновьев
Вспомнились ЕС-10хх, которые слабо отличаются от современных mcu. smile.gif
А были ли реального времени ОС на семействе 10хх? Мож портировать, не отдаваясь в руки современных ява/хтмл-программеров, попутнопейсателей RTOS?
one_man_show
ГетСмарт, для Вас поясню ОС РВ - Операционные Системы реального Времени, это в нашей практике то же самое, что у буржуев RTOS - Real Time Operating System. Если есть желание обсудить меня, создавайте тему в соответствующем разделе.

На задачи раскладывать проще, когда заранее известны все возможные состояния системы. Кроме того, есть ОС РВ, которые сертифицированы для применений в критических средах, например uC/OS-II. используя ее ядро, можно хотя бы не беспокоиться о ее устойчивости и об отсутствии глюков. Некорректное использование и манипуляция задач могут привести к неверным результатам, но хоть не к краху всей системы...правда, об этом тоже придется отдельно позаботиться
Прохожий
Цитата(MrYuran @ 3.8.2010, 9:48) *
И совсем другое дело:
Код
os_task ProcessCommand(PRIORITY_5)
{
    WaitForEvent(&PacketReceived);
    CheckPacketStructure(&InputBuffer);
    ExecuteCommand(&InputBuffer);
}

Ну, то, что Вы привели и задачей-то назвать сложно.
Это некая учебная запись.
Хотя суть понятна.
В моем случае все осложняется прерываниями.
Кроме этого, в Вашей записи есть функция ожидания события в явном виде.
Т. е. Ваша модель не событийная в общем случае.
Мне же ближе событийное программирование, базирующееся на системе приоритетных прерываний.
Ну и автоматы, безусловно.
К стати, в природе есть такие PLC.
В них в текущий момент времени работают только обработчики наступивших событий.
Прохожий
Цитата(one_man_show @ 3.8.2010, 13:34) *
На задачи раскладывать проще, когда заранее известны все возможные состояния системы. Кроме того, есть ОС РВ, которые сертифицированы для применений в критических средах, например uC/OS-II. используя ее ядро, можно хотя бы не беспокоиться о ее устойчивости и об отсутствии глюков. Некорректное использование и манипуляция задач могут привести к неверным результатам, но хоть не к краху всей системы...правда, об этом тоже придется отдельно позаботиться

Выделил в Вашем тексте главные слова, на мой взгляд.
Раз они сказаны, то тогда все ложится на автоматный подход к программированию.
В принципе, это доказано чисто математически...
Если его развивать, то становится очевидной ненужность РТОС, как таковой.
Поскольку вместо нее всегда можно применить событийный гиперавтомат, ложащийся непосредственно на архитектуру выбранного вычислителя (МК или МП).
Другой компот, что методология этого дела находится пока еще в стадии оформления.
Нет специальных языков. Хотя, в принципе, они есть. Но несколько в иной сфере.
MrYuran
Цитата(Прохожий @ 3.8.2010, 19:06) *
Ну, то, что Вы привели и задачей-то назвать сложно.

Вполне себе реальная задача.
Ждёт эвента по принятию пакета, парсит и исполняет команду.
Таких задач может быть больше десятка, а то и двух, что сильно усложняет построение (а также последующую модификацию) автоматов, особенно при необходимости соблюдения приоритетов.
Цитата
В моем случае все осложняется прерываниями.

Обычно прерывания упрощают жизнь, а не усложняют.
Например, заполнение буфера происходит по прерываниям, совершенно параллельно и незаметно для основного приложения
Цитата
Кроме этого, в Вашей записи есть функция ожидания события в явном виде.
Т. е. Ваша модель не событийная в общем случае.

Ну, в конце концов, эта функция при отсутствии эвента может просто передать правление планировщику, равно как и sleep()

one_man_show
Цитата
Выделил в Вашем тексте главные слова, на мой взгляд.
Раз они сказаны, то тогда все ложится на автоматный подход к программированию.
В принципе, это доказано чисто математически...
Если его развивать, то становится очевидной ненужность РТОС, как таковой.
Поскольку вместо нее всегда можно применить событийный гиперавтомат, ложащийся непосредственно на архитектуру выбранного вычислителя (МК или МП).

Полностью согласен, но это возможно, когда задача вылиза и изучена вдоль и поперек. А на практике проще посадить одного-двух программистов и предложить решать задачу "традиционными" для задачи методами. Когда со временем все определено и понятно, уже по экономическим соображениям никто ничего не переделывает. Изучал прошивки множества различных устройств, везде виден почерк не программиста, а менеджера, который диктовал подход. А менеджеры в основном думают о минимизации затрат, а не о технических вопросах
Прохожий
Цитата(MrYuran @ 3.8.2010, 20:39) *
Вполне себе реальная задача.
Ждёт эвента по принятию пакета, парсит и исполняет команду.
Таких задач может быть больше десятка, а то и двух, что сильно усложняет построение (а также последующую модификацию) автоматов, особенно при необходимости соблюдения приоритетов.

Обычно прерывания упрощают жизнь, а не усложняют.
Например, заполнение буфера происходит по прерываниям, совершенно параллельно и незаметно для основного приложения

Ну, в конце концов, эта функция при отсутствии эвента может просто передать правление планировщику, равно как и sleep()

Вы сейчас излагаете вполне нормальный подход.
И он вполне обоснован для больших систем.
Но здесь у Вас стилистические противоречия.
Это что, обработчик события заполнения буфера?
Тогда вызов функции ожидания события алогичен.
Это как бы должно подразумеваться.
И чтобы быть до конца правильными, необходимо предъявить код приемника сообщения.

Цитата(one_man_show @ 3.8.2010, 23:18) *
Полностью согласен, но это возможно, когда задача вылиза и изучена вдоль и поперек.

ПМСМ, Вы здесь правы, но не совсем.
В принципе, все дело в привычке.
Если брать CPLD или FPGA, то там вообще все на автоматах.
И если сочетать МК и FPGA, то без РТОС как бы привычнее.
Или если идти от железа к софту.
Насчет вылизанности задачи тоже не согласен.
Основной скелет решения любой задачи всегда можно представить в виде автомата.
А убрать или добавить состояние и поправить функцию переходов, а так же входов и выходов несложно.
И потом.
В ООП-шном подходе при создании класса Вы, по-хорошему, должны заранее продумать гораздо больше, чем при автоматном.
Цитата(one_man_show @ 3.8.2010, 23:18) *
А на практике проще посадить одного-двух программистов и предложить решать задачу "традиционными" для задачи методами. Когда со временем все определено и понятно, уже по экономическим соображениям никто ничего не переделывает. Изучал прошивки множества различных устройств, везде виден почерк не программиста, а менеджера, который диктовал подход. А менеджеры в основном думают о минимизации затрат, а не о технических вопросах

Правильно. Это когда речь идет о больших системах.
Или о нереально малых временах.
Но программирование "в навал", без предварительной проработки алгоритмов и способов взаимодействия отдельных процессов лично мне не нравится.
Хотя бы потому, что я уже наелся результатами такого подхода, как человек, вынужденный обслуживать все это по долгу службы.
one_man_show
Цитата
Правильно. Это когда речь идет о больших системах.
Или о нереально малых временах.

Я именно такие системы и имел в виду, так как с ними последнее время приходится больше сталкиваться. Прошу прощения, если не до конца правильно понял тему.

Относительно ПЛИС по своему опыту могу сказать, здесь тоже подходы меняются,мы сейчас в ПЛИС имплементируем ядро МК. Получается симбиоз, но в чистой части ПЛИС отпадает необходимость в автоматах, МК берет эту задачу на себя. Если пойти дальше, то в ядро МК можно встраивать ОС РВ. С одно стороны получается через одно место, проще использовать традиционные подходы, раз уж ПЛИС, то и автоматы. Но тут опять встревает практический опыт: экономически выгоднее использовать ПЛИС с ядром МК и с ОС РВ, та как для МК можно найти массу примеров реализации массы задач. Время выхода изделия уменьшается, что больше нравится менеджерам, будь они неладны.
MrYuran
Отличная статья про прототреды.
Для тех, кто не доверяет операционным системам
_pasha
Цитата(MrYuran @ 4.8.2010, 12:54) *
Отличная статья про прототреды.
Для тех, кто не доверяет операционным системам

1. Без гнусной фичи работы с метками, оно не на всех компилерах работает - switch не всегда превращается в таблицу переходов. Тоже геморрой.
2. Сами по себе прототреды - это уже не удивительно. Удивительно, как систему можно "прятать" в функцию idle() - обеспечивая при этом блокировку повторного вызова функций-тредов. Вот этим я и начал пользоваться в последнее время
Код
#define Thread_Pure(name,pc) void *name(void *pc) __attribute__((noinline))
#define Thread_Pure_Def(name,pc) void *name(void *pc)

#define Run_Thread_Pure(name) do{static void *pc=NULL; if(pc != &name){pc = name(lock(&pc,&name));}}while(0);
#define Run_Thread(name,param) do{static void *pc=NULL; if(pc != &name){pc = name(lock(&pc,&name),&param);}}while(0);
static void *lock(void **ppc,const void *pfunc) __attribute__((noinline));
static void *lock(void **ppc,const void *pfunc)
{
void *ptr = *ppc;
  *ppc = pfunc;
  return ptr;
}

Специально подточено под WinAVR - любит он иногда неоптимальностями плеваться.
В общем, после этих манипуляций с блокировкой, необязательно прям-таки выходить из каждой функции, сохраняя ея контекст, только на уровне драйверов. Если поток более высокого уровня - там уж можно и ждать события в цикле.
Правда, пожертвовать стеком немного нада...
Прохожий
Цитата(_pasha @ 4.8.2010, 18:50) *
1. Без гнусной фичи работы с метками, оно не на всех компилерах работает - switch не всегда превращается в таблицу переходов. Тоже геморрой.
2. Сами по себе прототреды - это уже не удивительно. Удивительно, как систему можно "прятать" в функцию idle() - обеспечивая при этом блокировку повторного вызова функций-тредов. Вот этим я и начал пользоваться в последнее время
...

Как-то сложно это все...
Указатели на указатели...
Впрочем, мнение сугубо личное.

Цитата(MrYuran @ 4.8.2010, 13:54) *
Отличная статья про прототреды.
Для тех, кто не доверяет операционным системам

Опять костыли.
А что? По простому не получается?
MrYuran
Цитата(Прохожий @ 4.8.2010, 23:36) *
Опять костыли.
А что? По простому не получается?

Да уж куда проще!
Препроцессорный макрос разворачивается в автомат
Переносимость 100%
Прохожий
Цитата(MrYuran @ 4.8.2010, 23:46) *
Да уж куда проще!
Препроцессорный макрос разворачивается в автомат
Переносимость 100%

Не люблю макросы.
Особенно, когда все в одну строку.
И автомат это не тот.
Пример.
Запись во внутренний EEPROM МК.
Процесс медленный и нудный.
Сама функция записи инициализирует счетчик байт, стартовый адрес EEPROM, стартовый адрес записываемого массива байт.
И осуществляет старт записи первого байта, чтобы инициировать прерывание по концу записи.
А все остальное выполняется в прерываниях.
Когда счетчик байт становится равным 0, выставляется признак освобождения EEPROM.
Прерывания прекращаются сами собой.
Получается псевдоавтомат с двумя состояниями.
Роль переменной состояния выполняет счетчик байт.

_pasha
Цитата(Прохожий @ 4.8.2010, 23:10) *
Запись во внутренний EEPROM МК.
Процесс медленный и нудный.

smile.gif не только нудный, но и насмерть блокирующий доступ к еепрому для всех остальных параллельных процессов. Это, тсз, одна классическая бяка. Вторая - например, 1-wire, там, где надо и интервалы с точностью микросекунды выдержать, и долго курить бамбук, пока, сброс проходит. Решения получаются кривоватыми. Вложу пример. Таймер с микросекундной точностью, позволяющей оказаться в нужное время в нужном месте - вот что нужно. В постановке задачи для 1-wire не обязательно ждать точно 60 мкс - достаточно не менее 60 мкс. А вот если надо точно, и от нескольких потоков - у каждого свой запрос на "будильник"?
MrYuran
Ну и чему это противоречит?
Пишите себе в ЕЕПРОМ по прерываниям, а в это время основная система работает в штатном порядке.
То же самое с прерываниями от УАРТа - кидает себе байты в буфер (или из), а по приёму (отправке) пакета выставляет эвент.
В это время система также работает, как ни в чём не бывало, не подозревая, что там какие-то байты куда-то летают

Цитата(_pasha @ 5.8.2010, 9:19) *
В постановке задачи для 1-wire не обязательно ждать точно 60 мкс - достаточно не менее 60 мкс. А вот если надо точно, и от нескольких потоков - у каждого свой запрос на "будильник"?

Организовать доступ через один драйвер. То есть отдельный поток общается с 1Wire сетью, остальные - через эту прослойку.
Как тут не вспомнить про операционки с ихними очередями и мутексами!
_pasha
Цитата(MrYuran @ 5.8.2010, 8:34) *
Ну и чему это противоречит?
Пишите себе в ЕЕПРОМ по прерываниям, а в это время основная система работает в штатном порядке.

А если у нее нету RWW? Тогда надо кешировать чтение, а памяти и так жалко.

Цитата
Организовать доступ через один драйвер. То есть отдельный поток общается с 1Wire сетью, остальные - через эту прослойку.

Дык таким образом все и делается. Например, драйвер ds18b20 уже над owire.h, оформлен а-ля protothread, бегает внутри idle()
Код
Thread_Pure_Def(DS18B20_thread,pc)
{
    if(pc !=NULL) goto *pc;
static timer_t time;
    time = get_time(0);
    return &&Powered;
Powered:
    if(get_time(time) < POWERUP_TIME) return pc;//power up 2 sec
Sampling:
    OW_reset();
    OW_byte_write(DS18B20_SKIP_ROM);
    OW_byte_write(DS18B20_READ_SCRATCHPAD);

    uint8_t *pos = (uint8_t *)&scratch_pad;
    uint8_t lrc = 0;
    for(uint_fast8_t j=0; j<sizeof(scratch_pad);j++)
    {
        uint8_t wrk;
        wrk = OW_byte_read();
        *pos++ = wrk;
        if(j < offsetof(ds_scratchpad_t,crc)) lrc = OW_crc_update(lrc,wrk);
        else if(lrc != wrk) ds_state = ds_BAD_CRC;
    }
    if(ds_state == ds_OK) ambient = (int8_t)(scratch_pad.temperature >> 4);
// next sample
    OW_reset();
    OW_byte_write(DS18B20_SKIP_ROM);
    OW_byte_write(DS18B20_WRITE_SCRATCHPAD);
    for(uint_fast8_t j=0;j<3;j++) OW_byte_write(0);//default configs
    OW_reset();
    OW_byte_write(DS18B20_SKIP_ROM);
    OW_byte_write(DS18B20_CONVERT_TEMP);
    time = get_time(0);
#if(DEBUGLEVEL == 1)
#define DS18b20_Sampling_Time 500
#else
#define DS18b20_Sampling_Time (10*T1sec)
#endif
Awaiting:
    if(get_time(time)< DS18b20_Sampling_Time) return &&Awaiting;
    ds_state = ds_OK;
    return &&Sampling;
}

Типа того.
Но я вообще-то о совместном использовании микросекундных таймеров, что есть трудность. Кашпировский был неправ, говоря "Ваш будильник разбудит Вас вовремя" - не получаеццо...
MrYuran
Цитата(_pasha @ 5.8.2010, 9:51) *
Но я вообще-то о совместном использовании микросекундных таймеров, что есть трудность.

Микросекундные никак.
Честно отсчитывать тайм-слот в критических местах, в это время все остальные задачи в пролёте.
Даже если использовать ОСРВ (по определению, с гарантированным временем отклика), то там время реакции меньше 50мкс ставить нецелесообразно, из-за сильно возрастающих накладных расходов по времени

Но даже если делать всё на прерываниях (апологетом данного подхода является Прохожий smile.gif ), то всё равно джиттер в несколько мкс, а то и десятков мкс, неизбежен.
Есть, конечно, накрайняк "железные" выходы защёлок таймера, но это уже вообще...
Потом, в случае чего, черт ногу сломит в этих джунглях костылей...
_pasha
Цитата(Прохожий @ 4.8.2010, 22:36) *
Как-то сложно это все...
Указатели на указатели...
Впрочем, мнение сугубо личное.

Если перевести на нормальный язык, то: вызов функции блокируется, если переменная, в которой хранится адрес точки входа, имеет значение, равное адресу этой самой функции. Т.е. для блокировки рекурсивного вызова надо, чтобы
Код
{
void *temp;
temp = pc;
pc= &somefunc;// эта строчка безжалостно выкидывается оптимизатором.
pc= somefunc(temp);
}

Отсюда и сложности.

Цитата(MrYuran @ 5.8.2010, 8:58) *
всё равно джиттер в несколько мкс, а то и десятков мкс, неизбежен.

Самое главное - для чего? Ногами дрыгать, да тайм-стамп поставить. Других задач, извините, не вижу. У мну системные тики тикают по миллисекунде. В принципе, можно и до 10 мкс без боли разгонять, на макс. тактовой. И local continuations в гнусном варианте- тоже, знаете ли, обеспечивают время реакции довольно быстрое.
Далее пример конкретно про АВР. Берем прерывание достаточно высокого приоритета, например, Int0. Настраиваем его, чтобы срабатывало по уровню и засаживаем ногу проца, чтобы запросы на прерывание шли постоянно. Получаем возможность выполнять в прерывании самый приоритетный поток. После каждой выполненной команды у нас будет прерывание. Таким образом можно и паузы микросекундные обработать.
Прохожий
Цитата(MrYuran @ 5.8.2010, 9:58) *
Но даже если делать всё на прерываниях (апологетом данного подхода является Прохожий smile.gif ), то всё равно джиттер в несколько мкс, а то и десятков мкс, неизбежен.
Есть, конечно, накрайняк "железные" выходы защёлок таймера, но это уже вообще...
Потом, в случае чего, черт ногу сломит в этих джунглях костылей...

Какой такой джиттер?
Меня лично он не волнует.
Волнует всегда только одно - максимальное время реакции на событие.
Оно должно быть минимально.
При моем подходе - это так.
Если же это не так, берется булыжник пошустрее.
И опять все хорошо.
А насчет ломанья ног чертом, скажу только одно.
Пока у меня нет пристойного инструмента, все процессы (элементарные автоматы) у меня разбросаны по обработчикам прерываний.
Пример.
MODBUS/ASCII.
Код
-------------------------------------------------------------------------------------------------------------
| Состояние    |        Действие                                        |   Блок, где обрабатывается        |    
-------------------------------------------------------------------------------------------------------------
| WaitRX       |  Ожидание символа ':'                                  | Прерывание от приемника USART     |
-------------------------------------------------------------------------------------------------------------
| Reception    |  Заполнение буфера, HEX -> BIN и подсчет LRC "на лету" | Прерывание от приемника USART     |
-------------------------------------------------------------------------------------------------------------
| WaitEOF      |  Ожидание признака конца пакета 'LF'. RTS=1.           | Прерывание от приемника USART     |
-------------------------------------------------------------------------------------------------------------
| Parse        |  Проверка LRC и разбор пакета и формирование ответа    | Основной суперлуп                 |
-------------------------------------------------------------------------------------------------------------
| WaitToReply  |  Регулируемая задержка ответа                          | Прерывание от системного таймера  |
-------------------------------------------------------------------------------------------------------------
| PreTransmit  | Отсылка заголовка ':'                                  | Прерывание от передатчика USART   |
-------------------------------------------------------------------------------------------------------------
| Transmit     | Передача пакета. BIN -> HEX и подсчет LRC "на лету"    | Прерывание от передатчика USART   |
-------------------------------------------------------------------------------------------------------------
| PostTransmit | LRC ->HEX и ее отправка                                | Прерывание от передатчика USART   |
-------------------------------------------------------------------------------------------------------------
| EndTransmit  | Отправка хвоста CR, LF                                 | Прерывание от передатчика USART   |
-------------------------------------------------------------------------------------------------------------
| EndRTS       | RTS=0                                                  | Прерывание от системного таймера  |
-------------------------------------------------------------------------------------------------------------

Вот. Приблизительно так.
Представляете, какая каша?
Но для меня проблем здесь нет.
Поскольку в автоматике и PLC это - общепринятая практика.
_pasha
Цитата(Прохожий @ 5.8.2010, 19:08) *
Пример.
MODBUS/ASCII.

Это не тот пример. Проблемы со временем реакции маячат в RTU в части обнаружения конца пакета, либо в TCP/IP.
К слову сказать. Угадайте, как написаны у мну софты для приводов? Правильно, вся генерация - на прерываниях, весь УАРТ - на прерываниях smile.gif
Прохожий
Цитата(_pasha @ 5.8.2010, 20:18) *
Это не тот пример. Проблемы со временем реакции маячат в RTU в части обнаружения конца пакета, либо в TCP/IP.

MODBUS/RTU делал.
Работает - проблем с обнаружением конца пакета нет. Максимальная скорость 115200.
Проверялось совместно с VariSpeed7 от OMRON и с различными ОВЕН-ами ПЛК 150 и ИП320.
Подход аналогичный.
А с Modbus over TCP/IP вообще заморачиваться не буду.
Для этого есть W5100.
MrYuran
Цитата(Прохожий @ 5.8.2010, 20:08) *
Какой такой джиттер?
Меня лично он не волнует.

Речь шла об 1Wire, там очень критично начало тайм-слота, по крайней мере первые 60мкс.
Плюс, есть некоторые задачи.
Нарпимер, управление синхронным детектором.
На МСП430 я реализовывал заданные сдвиги фаз без джиттера с помощью железных выходов таймера, благо их там 7+3.
Цитата
Вот. Приблизительно так.
Представляете, какая каша?

Представляю.
Ужоснах.
Второй месяц перерабатываю подобное творчество к более-менее приемлемому виду.
У начальника выражение лица такое, как будто его наё... Бывают, конечно, задержки при проектировании, но тут вроде бы, казалось, отлаженное изделие, его бы чуть видоизменить...
Но у меня уже нервы не выдержали среди этих костылей, и я взял большой лом и начал крушить направо и налево.
Проще было (как я теперь уже понимаю) написать с нуля на своём шаблоне, а оттуда вытащить нужную математику.
Проблема ещё в том, что программа "нанизана" на протокол обмена.
То есть автомат, управляемый извне. Это, мсм, предел маразма. Особенно учитывая, что внешняя часть не моя и там могут быть свои глюки.
У меня совершенно другой подход.
Блок работает автономно, а извне можно посмотреть некоторые параметры или выполнить команды. Но протокол обмена сбоку, он никак не влияет на структуру основной программы и уж тем более не является её стержнем.

Проблема ещё в том (из-за чего я и стремлюсь к унификации), что поректы схожие, но у каждого своя специфика.
В среднем цикл разработки 1-2 года, параллельно 3-4 проекта, причём в любых комбинациях.
Нарпимер, прибегает ГК и говорит: помнишь, мол, ты нам год назад вот это делал (а я то что было вчера, уже не помню pardon.gif )
Так вот, надо заменить то на это, плюс приделать вот это. До конца дня. Время пошло.
Вот и хочется менять только верхнюю логику, не влезая в нижние слои и уж тем более не вспоминая, где какие регистры и какой таймер подо что занят.

Идеальный мэйн:
{
OS::Run();
}
Прохожий
Цитата(MrYuran @ 5.8.2010, 20:49) *
Речь шла об 1Wire, там очень критично начало тайм-слота, по крайней мере первые 60мкс.
Плюс, есть некоторые задачи.
Нарпимер, управление синхронным детектором.
На МСП430 я реализовывал заданные сдвиги фаз без джиттера с помощью железных выходов таймера, благо их там 7+3.

Ну, 60 мкс при моем подходе - без проблем.
А вообще 1Wire - протокол дурацкий.
Поэтому и не прижился особо.
Цитата(MrYuran @ 5.8.2010, 20:49) *
Представляю.
Ужоснах.
Второй месяц перерабатываю подобное творчество к более-менее приемлемому виду.

Это от того, что у Вас нет подобного опыта.
Надо будет принести Вам программку от одной из наших машин.
На PLC, который работает исключительно по событиям.
В их контексте - считай прерываниям.
Порядка нескольких мегабайт подобного кода.
"Размазанные" автоматы - в порядке вещей.
Со временем все это воспринимается вполне нормально.
Цитата(MrYuran @ 5.8.2010, 20:49) *
Проблема ещё в том, что программа "нанизана" на протокол обмена.
То есть автомат, управляемый извне. Это, мсм, предел маразма. Особенно учитывая, что внешняя часть не моя и там могут быть свои глюки.

А вот это уже интересно. Если можно, хотелось бы подробностей.
Цитата(MrYuran @ 5.8.2010, 20:49) *
У меня совершенно другой подход.
Блок работает автономно, а извне можно посмотреть некоторые параметры или выполнить команды. Но протокол обмена сбоку, он никак не влияет на структуру основной программы и уж тем более не является её стержнем.

Это совершенно нормальный подход.
Сам не люблю смешивать мелкое с мягким.
Но, здесь, ПМСМ, важно понять ход мыслей автора текста.
Он же о чем-то думал, наверное...
Цитата(MrYuran @ 5.8.2010, 20:49) *
....
Вот и хочется менять только верхнюю логику, не влезая в нижние слои и уж тем более не вспоминая, где какие регистры и какой таймер подо что занят.

В какой-то мере согласен с Вами. Но за это надо платить.
1. Изучать РТОС, продираясь через многочисленные авторские заморочки. И все равно останутся сомнения.
2. Возрастает оверхед, так или иначе.
3. Программист полностью отрывается от железа, а это плохо.
Тем более, что в конце концов у меня получается тоже самое.
На верхнем уровне уже ничего не смешивается.
К примеру, терморегулятор.
Внизу - все это безобразие, а на верху - расчет полиномов для различных термопар, взятый из C++Builder-а практически без переделок.
one_man_show
Цитата
1. Изучать РТОС, продираясь через многочисленные авторские заморочки. И все равно останутся сомнения.

Автор uC/OS-II описал свою ОС РВ со всеми заморочками, причем очень классно описал.
Цитата
3. Программист полностью отрывается от железа, а это плохо.

Если не заморачиваться межплатформенностью, то Вы правы. Но современная жизнь диктует иной подход: если Ваш программист создал прошивку/софт для одной платформы, Вам через некоторое время может потребоваться решение подобной проблемы на другой аппаратной платформе. Если писать софт в виде слоеного пирога так, чтобы аппаратнозависимые части были в отдельном слое, тогда жить можно.
Прохожий
Цитата(one_man_show @ 5.8.2010, 21:46) *
Автор uC/OS-II описал свою ОС РВ со всеми заморочками, причем очень классно описал.

Как бы хорошо автор не написал документацию, все равно ее надо читать с карандашом в руках, т. е. тратить свое время на "вторяк".
Желательно при этом заранее освежить в памяти теоретические знания по этому вопросу, что тоже требует временных затрат.
Не лучше ли вместо этого изучить поглубже новую платформу, железо, т. е. "первяк" для нашего случая.
Цитата(one_man_show @ 5.8.2010, 21:46) *
Если писать софт в виде слоеного пирога так, чтобы аппаратнозависимые части были в отдельном слое, тогда жить можно.

А при моем подходе так и есть.
Да и вообще, трудно себе представить, чтобы расчет вышеупомянутых полиномов, правильность которого я проверял вообще на PC, как-то пересекался с работой того же дельта-сигма АЦП, подключенного к тому же по I2C.
Вопрос в другом, где проводить границу?
И сколько слоев в данной селедке под шубой?
Я за их минимизацию. Исходя из принципа бритвы Оккама.
MrYuran
Цитата(one_man_show @ 5.8.2010, 21:46) *
Но современная жизнь диктует иной подход: если Ваш программист создал прошивку/софт для одной платформы, Вам через некоторое время может потребоваться решение подобной проблемы на другой аппаратной платформе. Если писать софт в виде слоеного пирога так, чтобы аппаратнозависимые части были в отдельном слое, тогда жить можно.

Именно.
2 года назад ещё применяли кое-где AT89S8253, нынче кругом МСП-шки.
Да и по ходу жизни одного и того же изделия плата может меняться несколько раз, а уж версия программы и подавно.
Заявленный срок эксплуатации - 10 лет.
В течение этого времени всё должно поддерживаться.
Сейчас думаем перейти то ли на кортексы, то ли на цыгналы. Опять всё перелопачивать.
Если даже раз в три года переносить все изделия на новую платформу, ни на что больше времени не останется.
Однако, если менять только самый нижний уровень (HAL) и не привязываться слишком сильно к особенностям конкретного контроллера, то всё значительно упрощается.

Хотел было тему поднять о корпоративном стиле программирования (назрела насущная необходимость такого документа), да пока времени нет.
Там же планирую подумать насчёт платформонезависимости.
Идеал - это если программу верхнего уровня можно будет перенести без изменений на ПК для создания эмулятора и технологических утилит, и обратно.
one_man_show
Цитата
Идеал - это если программу верхнего уровня можно будет перенести без изменений на ПК для создания эмулятора и технологических утилит, и обратно.

Без этого не смог бы часть проектов реализовать, так как софт часто приходится делать, когда еще железа нет.
Прохожий
Цитата(MrYuran @ 5.8.2010, 22:08) *
Сейчас думаем перейти то ли на кортексы, то ли на цыгналы. Опять всё перелопачивать.

А смысл?
Цитата(MrYuran @ 5.8.2010, 22:08) *
Хотел было тему поднять о корпоративном стиле программирования (назрела насущная необходимость такого документа), да пока времени нет.
Там же планирую подумать насчёт платформонезависимости.

Очень интересные темы. Если желаете, можно обсудить.
Цитата(MrYuran @ 5.8.2010, 22:08) *
Идеал - это если программу верхнего уровня можно будет перенести без изменений на ПК для создания эмулятора и технологических утилит, и обратно.

Тогда огребете все проблемы больших ПК.
За все надо платить, к сожалению...
one_man_show
После перехода на ARM9 + Linux мы сразу обленились, даже простые задачи, которые раньше на Сигналах (Силабс) делали, сейчас тиражируем на Арме. Тут тебе и USB Host и TCP/IP по полной программе. Дороже, да, но при многократном повторении платформы для разных задач, затраты на ее разработку вместе с частью софта давно оправдались: портированная версия АльтЛинукс и их репозиторий на 6000 пакетов. По многим задачам софт уже не пишем, а используем готовые пакеты, например для Modbus, NMEA и т.д.
MrYuran
Цитата(Прохожий @ 5.8.2010, 21:49) *
А смысл?

Динамика сейчас очень сильная.
Например, приходит снабженец и говорит: у мсп-шек f149 срок поставки внезапно стал 3 месяца. Так что готовьтесь в случае чего пересесть на f249. Их обещают за три недели.
А мы их потребляем несколько сотен в месяц.
Мы давай метаться, инфу качать, но потом успокоились. Там различия минимальны, а корпус вообще пин-то-пин.
Но в любой момент может что угодно произойти, и надо быть к этому готовым.
То экранчики не достать, то это, то другое...
Ну и опять же, если переходить, то оптом, сразу везде. Чтобы закупаться большими ящиками по нормальной цене, а не у барыг втридорога.
Harbinger
Та же кухня... 249 вроде приручили, но призрак кортекса бродит...
Памяти у этих MSP катастрофически мало оказалось. В свете последних веяний.
Прохожий
Цитата(MrYuran @ 5.8.2010, 23:03) *
Динамика сейчас очень сильная.
Например, приходит снабженец и говорит: у мсп-шек f149 срок поставки внезапно стал 3 месяца. Так что готовьтесь в случае чего пересесть на f249. Их обещают за три недели.
А мы их потребляем несколько сотен в месяц.
Мы давай метаться, инфу качать, но потом успокоились. Там различия минимальны, а корпус вообще пин-то-пин.
Но в любой момент может что угодно произойти, и надо быть к этому готовым.
То экранчики не достать, то это, то другое...
Ну и опять же, если переходить, то оптом, сразу везде. Чтобы закупаться большими ящиками по нормальной цене, а не у барыг втридорога.

Тут как то отмечалось, что дело не в моторе ARM, MIPS, PIC, AVR, а в периферии.
Под нее все равно все по-новой.
А если нет, то получается привязка к производителю.
Что тоже, в общем-то, нехорошо.
Я для себя выбрал второй вариант.
А что касается негативных тенденций с железом, то эту тему тоже надо раскрыть, ПМСМ.
Мы тоже столкнулись с этим при покупке IGBT.
У нас еще и контрафакт был...
OFF.
Хорошо было, если бы Вы нашли немного времени и просветили нас всех по поводу GNU программирования.
В техническом смысле. Что, где и зачем.
Я думаю, что можно было бы отдельный подфорум в рамках МК сделать...
MrYuran
Цитата(Harbinger @ 5.8.2010, 22:14) *
Та же кухня... 249 вроде приручили, но призрак кортекса бродит...
Памяти у этих MSP катастрофически мало оказалось. В свете последних веяний.

После атмелов с ихними 128 (или 256?) байтами 2 кила не знали куда деть.
pardon.gif
Все вычисления - во float-ах, все флаги - как минимум char
И всё равно половина остаётся...
А вот флеши в индикаторном блоке с графическим экраном и поддержкой 2-х языков уже почти не осталось...
one_man_show
Цитата
Тут как то отмечалось, что дело не в моторе ARM, MIPS, PIC, AVR, а в периферии.
Под нее все равно все по-новой.
А если нет, то получается привязка к производителю.

Именно по этой причине перешел на Линукс. В тех приложениях, где требуется реальное время, использую на низком уровне МК послабее
Прохожий
Цитата(one_man_show @ 5.8.2010, 23:58) *
Именно по этой причине перешел на Линукс. В тех приложениях, где требуется реальное время, использую на низком уровне МК послабее

МК послабее на низком уровне - это не транзистор BC847 и не UC3842, которые делают все и по рупь ведро.
Это тоже привязка к производителю, поскольку - нет компонента - нет системы.
Вот и получается ходьба по замкнутому кругу.
А под Линукс драйвера нужны, однако.
И писать их - гемор еще тот...
one_man_show
МК на нижнем уровне - это МК, на котром обычно уже сделана масса проектов, чтобы его выбор не вызывал вопросов.
Цитата
А под Линукс драйвера нужны, однако.
И писать их - гемор еще тот...

Используйте стандартные интерфейсы по-максимому, для которых драйверы есть, или заведите программиста, который умеет оперативно подкрутить драйвера. Такого спеца можно использовать и на расстоянии, а не в штате держать
Прохожий
Цитата(one_man_show @ 6.8.2010, 0:52) *
МК на нижнем уровне - это МК, на котром обычно уже сделана масса проектов, чтобы его выбор не вызывал вопросов.

Но этот МК не из воздуха берется. Его тоже надо купить. И здесь могут быть разные косяки.
Цитата(one_man_show @ 6.8.2010, 0:52) *
Используйте стандартные интерфейсы по-максимому, для которых драйверы есть, или заведите программиста, который умеет оперативно подкрутить драйвера. Такого спеца можно использовать и на расстоянии, а не в штате держать

Уж лучше зависеть от производителя МК, чем от такого снобливого и амбициозного существа, коим является системный программист.
Harbinger
Цитата(Прохожий @ 5.8.2010, 23:44) *
МК послабее на низком уровне - это не транзистор BC847 и не UC3842, которые делают все и по рупь ведро.
Это тоже привязка к производителю, поскольку - нет компонента - нет системы.

В своё время наблюдалась некая унификация распиновки MCS-51 у различных производителей и, пмсм, это было хорошо весьма.
С нынешними прогрессивными архитектурами, пардон, каждый дрочит, как хочет (или же я не всё знаю?)... последнее, на что сподвигся, некий "мегадевайс", в который можно ставить 51 от нескольких производителей, или mega162 от одного-единственного, перепаяв пару-тройку "нулёвок" да блокировочных конденсаторов...
Idle
>>Уж лучше зависеть от производителя МК, чем от такого снобливого и амбициозного существа, коим является системный программист.
насквозь видят, но я не весь такой
Прохожий
Цитата(Idle @ 6.8.2010, 21:58) *
>>Уж лучше зависеть от производителя МК, чем от такого снобливого и амбициозного существа, коим является системный программист.
насквозь видят, но я не весь такой

Да ладно!
Мы все такие.
К сожалению...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2020 IPS, Inc.