NetBSD на МП системах , кто занимался портированием ?

Ну человек не раскололся, какие там датчики. Если они обладают хоть вот такусенькой буферизацией (в смысле, если забыл считать в одну наносекунду, то пипец, нет на эту наносекунду показаний), то реалтайм перестает быть критичным вопросом номер раз.

Цитата Ho Im @ 21.01.06, 21:08

Ну человек не раскололся, какие там датчики. Если они обладают хоть вот такусенькой буферизацией (в смысле, если забыл считать в одну наносекунду, то пипец, нет на эту наносекунду показаний), то реалтайм перестает быть критичным вопросом номер раз.

То есть требуется уточнить будет ли датчик снимать показания непрерывно или же "пошагово" с каким либо интервалом между снятием показаний, я так понял ?

Имеется в виду -- критично ли именно гарантированное время отклика? То есть, настанет ли капец, если вдруг ядро решит: "вот тут у меня idle сильно обделен, дам-ка я ему вот этот большой слайс в X микросек", и пока idle ничего не делает, твои датчики успели с регулярным интервалом в X/20 микросек передать всплеск активности того, что ты там мониторишь, причем через X мкс все утихомирилось и твоя система этот всплеск не зафиксировала. Тем временем этого хватило, чтобы, кхм, от направленного взрыва на АЭС снесло небольшой городишко :]=

То есть, в данном случае, та гипотетическая величина в X/20 мкс будет временем отклика, которое система должна гарантировать, хоть бы все зашиблось.

И дело не в малой величине. Реалтайм можно построить на ис-клю-чи-ттельно эст-то-онских скоростях. Например, частота выборки 1 Гц, тогда и требование такое -- чтобы хотя бы раз в секунду система отвлекалась от своей прочей порнографии на считывание данных. Если какой-то левый процесс поимеет возможность заграбастать на себя 1.000 ... \inf секунд, реалтайм не получился. Если система при любой погоде не будет выдавать такие кванты процессам (скажем, жестко зашить 0.1 с, а в системе 6 процессов) -- будет тебе реалтайм.

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

Цитата

То есть требуется уточнить будет ли датчик снимать показания непрерывно или же "пошагово" с каким либо интервалом между снятием показаний, я так понял ?

Цитата

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

Частота дискретизации, на самом деле. Этим определяется сколько данных за единицу времени (к примеру, 1 сек.) у тебя будет собираться.

Теперь второй вопрос -- как будет работать твой датчик (как он будет организован) -- либо сам накапливать некую часть инфы и, позже сбрасывать на хост, либо сам будет хостом, непрерывно гонящим инфу куда-то для обработки. Это определяется постановкой задачи на разрабатываемую систему ("архитектурой" оной).

Кстати, замечу, что для случая именно термометра -- хост на базе ОС явно избыточен. Т.е., тебе вполне возможно "отбиться" платкой на базе PIC'а (к приемеру, с 18F458 можно работать на частоте внутреннего осциллятора в 40 MHz -- много это или мало?). Причём, на ней же организовать и сбор (буфферизацию информации, если поставить там память) и её первичную обработку (как минимум, реакция на граничные условия -- температура "не больше" и "не меньше" или "резкая дельта в двух соседних выборках"). Т.е., при достижении какой-то пороговой величины, выдавать команду на некий исполнительный механизм (есть возможность работать с I2C, CAN, UART,...).

Ну, как-то всё так.

В принципе, практически одно и то же, просто у тебя термин иностранный, а у меня отечественный :-)

Иное дело, если это хозяйство надо переносным сделать, и чтобы оно внутре какой-либо анализ-подсчет производило -- тогда и процессор хочется поставить, и ОС на него... Хотя обычно достаточно недорогого нотебука на такие случаи.

Цитата

Иное дело, если это хозяйство надо переносным сделать, и чтобы оно внутре какой-либо анализ-подсчет производило -- тогда и процессор хочется поставить, и ОС на него...

Хммм... А не проще ли воспользоваться идеологией Finite-State Mashines (тьфу ты!) "конечных автоматов"?

В принципе, если реакция девайса должна быть простейшая, то... зачем?
А для передачи данных с девайса -- так воооон сколько всяко-разных "шин" по-навояли... Пиши приблуду (хоть под Linux, хоть под NetBSD), ставь на комп, в комп -- шину. А на "шину" -- девайсы простенькие до такой степени, чтобы там глючить было бы нечему... Или как-то так...

Цитата

В принципе, если реакция девайса должна быть простейшая, то... зачем?

Да вспомнился тут совецкий ГСВЧ с "Электроникой-60" внутри. Вопрос, если вычислительные мощности востребованы до такой степени, что мы туда впихиваем ОС, то зачем не делать на рост?

Цитата

Вопрос, если вычислительные мощности востребованы до такой степени, что мы туда впихиваем ОС, то зачем не делать на рост?

Ну, скажем, а зачем платить за выч. мощности больше, нежели нам того потребно?
В принципе, на ARM 7TDMI можно такую платку зачудить. Вот только -- стоит ли оно того? :D:D:D
Если в самом конце мы просто получаем термометр с минимальным функционалом? И не более того.

Цитата

Ну, скажем, а зачем платить за выч. мощности больше, нежели нам того потребно?

Для стендовой системы -- можно переплатить. По ней вычисляем стоимость продакшена.

Иначе упремся в деньги за туеву хучу неудавшихся экспериментальных систем.

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

проц я пока что выбрал этот: AVR 8535 (для него на С вроде удобнее писать я слышал).

Цитата

(для него на С вроде удобнее писать я слышал).

Да. Его gcc должен поддерживать.

Добавлено 25.01.06, 14:06
В остальном -- предложить вариант -- мы предложили. В остальном -- выбор за тобой.

ок, большое спасибо за помощь.