psL

Основной недостаток - отсутствие информации. В связи с этим - высокий "порог вхождения" и возможно отсутствие интереса к вашей разработке. Как построена документация, а также на предмет необходимой функциональности можно смотреть, например, аналогичные проекты OpenHab, ioBroker, тот же Windows IoT :laughing: , форумы по домашней автоматизации типа ab-log.ru/forum/ и тп Пмсм, смысла изобретать свое обособленное решение нет, пока нет хотя бы четкого обоснования, что не устраивает в уже существующих. Тем более если это некоммерческий проект. Если коммерческий, то видимо тоже нет. Взять Windows IoT. Даже MS предлагают решение для _уже_ существующего железа (RPi) т.е. пытаются подстроиться под уже существующую инфраструктуру. Что же говорить о небольших группах разработчиков?

как на счет тимвьюер "на какой-нить стмке с граф. дисплеем";)

PWMConfig pwmcfg = {... .channels = { [0]{ .mode = PWM_OUTPUT_ACTIVE_HIGH, .callback = NULL}, [1]{ .mode = PWM_OUTPUT_ACTIVE_HIGH, .callback = NULL}, ... }, };

Что discovery, что Pi - все предполагает уже работу с аппартурой через HAL/BSP. Просто в одном случае это будет stm32cube, а в другом - u-boot/linux Непонятно, зачем учить ARM. Имхо, нужно разбираться с инфраструктурой уже имеющихся пакетов применительно к конкретной задаче и по возможности самостоятельно устранять ошибки в них. вот предлагали же модеру: назовите раздел Single Board Computers и засуньте в нее подразделами все RPi, Banana и тп вместе с ардуинами. нет же ж...

Можно принимать данные через ExecBinding https://github.com/openhab/openhab/wiki/Exec-Binding типо так: Number Sensor "Temperature [%2.1f °C]" (Blablabla) { exec="<[sh ./configurations/scripts/getvalue.sh:1000:REGEX((.*?))]"} скрипт или что там у вас будет тупо печатает значение в stdout

типичный кандидат, например : https://www.linux.org.ru/forum/job/12863037 есть повод задуматься.

т.е. если процесс блокируется вплоть до события на каком-то одном или нескольких дескрипторах сокетов, а потом последовательно обрабатывает эти события, то такой процесс по вашему уже работает не синхронно? синхронность или асинхронность никак не связаны с наличием потоков, а просто говорит о том, будет ли поток заблокирован или нет при взаимодействии с тем или иным ресурсом. В том же JS тоже есть несколько реализаций потоков Web Workers API, например. Они используются для создания фоновых процессов в браузере. Дело в том, что долго работающие тяжелые скрипты могут блокировать страницу браузера (выглядит как зависание страницы). Особенно это заметно при работе с DOM браузера напрямую. Отсюда всякие проекты по отрисовке типа ReactJs. Так что не все так радужно.

с точки зрения приведенного вами кода у вас странное представление о синхронности. Синхронность - это не обязательно отдельный поток. Синхронность - это когда процесс останавливается в ожидание какого-либо события, завершения действия и тп вплоть до наступления оных. А асинхронность, это когда процесс продолжает работу даже если такие событие, завершения действия и тп не произошли. С возможным последующим уведомлением об оных. Т.е. для имитации синхронности по идее нужно было обрабатывать события на сокетах при помощи select, а не каждое соединение в своем отдельном потоке. В случае асинхронности использовать epoll Кстати, современных "синхронных" серверов уже совсем не осталось. И "тормознутый апач" уже давно может epoll : http://httpd.apache.org/docs/2.4/mod/event.html Вот в FAQ у апачей интерсное есть: Benchmarks tend to be a measure of configuration competance, rather than of server quality Еще, вы намекаете, что IPC при асинхронной модели не требует синхронизации. Очереди там всякие и т.п. Атомарность записи чтения обьектов IPC в томже линуксе обеспечивается ядром, с точки зрения юзерспейса ее м.б. не видно, но это не значит, что ее нет

Каждый поток в линукс создается со стеком ~8Мб по умолчанию, вот память и кончается. Можно изменить pthread_attr_setstacksize Но лучше все же для тестирования использовать стандартные инструменты, например http://httpd.apache.org/docs/2.2/programs/ab.html Видимо гуру не знает, что "Сервак на NodeJS" написан на основе libuv, например. А nodejs "в продакшене" прячут за тем же nginx... А так, в принципе, можно договориться до того, чтобы запретить размещение обьектов в стеке средствами C++. Или использовать только реентерабельные функции и статические данные в С. Тогда никакого стека вообще не будет, и никакой кучи тоже.

желательно использовать gnu toolchain который использовался для сборки установленного на плате дистрибутива например, http://gnutoolchains.com/raspberry/

скрипты питона не нужно компилировать, соответственно не нужен cross toolchain

генератор бортсети

https://learn.adafruit.com/7-portable-raspb...tablet/overview http://blog.mcmelectronics.com/post/Buildi...en#.V6ZOLKKx-JA так что про закрепление на двухстороннем скотче недалеко от истины

LPC2468 и uClinux это скорее минное поле... В 2016 году проще и дешевле уже использовать какой-нибудь nuc97x http://www.nuvoton.com/hq/products/micropr...es/?__locale=en http://www.starterkit.ru/html/index.php?na...ew&id=26280

дорогого стОит

http://www.mingw.org/

Не знаю что пишет силабс, никогда DTR-DSR не использовались для управления потоком. DTR - это сигнал готовности терминального оборудования и обычно используется для перевода терминалом (DTE) оконечного оборудования (DCE) в известное состояние, при этом DSR - готовность DCE, т.е. что DCE в это состояние перешел. В большинстве современных модемов вход DTR соединяется напрямую с выходом DSR непосредственно на разъеме RS232, например для того, чтобы определить, что модем подключен. RTS-CTS в сути отражают наличие свободного места в буферах данных DTE и DCE соответственно. И вот они используются для аппаратного управления потоком данных. Направление (вход/выход) этих сигналов зависят от типа оборудования. В случае RTS - для DTE это д.б. выход, а для DCE - вход. Для CTS - наоборот. Кстати, на некоторых модемах аппаратное управление не работает в режиме команд, видимо считается, что размер буферов в этом режиме всегда достаточный и они не могут быть переполнены)

Инженеру, математику и физику дали красный резиновый мяч, и попросили высчитать его объём. Физик опустил мяч в сосуд с жидкостью, и подсчитал объём вытесненной жидкости. Математик замерил диаметр, и высчитал объём через интеграл. А инженер достал из стола "Справочник объёмов красных резиновых мячей. Том III" и нашел нужное значение

Собственно Linux - это только ядро, а Ubuntu, Mint, генту - дистрибутивы линукса. Дистрибутивы в основном решают задачу сборки, распространения и взаимодействия пакетов. Вся emebedded linux система условно делится на загрузчик (u-boot), ядро (linux), корневую фс (rootfs) ну и ваше приложение (optware). Все это собирается вместе системами сборки типа buildroot, OpenEmbedded и т.п. в прошивку. Т.е. чисто работы с железом здесь вообще немного и скорее всего ее уже кто-то сделал за вас, если конечно вы не портируете линукс на оригинальную архитектуру.

тема имеет: продолжение

ПКМ на проекте -> Build options->{Debug, Release}->Linker settings->Add, далее имя без lib

Нужно убедиться, что используется ожидаемый конфиг /etc/wvdial.conf или $HOME/.wvdialrc. Или задать свой конфиг принудительно через --config=/path/to В любом случае нужно приводить свой конфиг и выхлоп wvdial, в противном случае непонятно, что у вас происходит.

не совсем понятно, что вы хотели сказать своей ссылкой. Вот это в .metadata/.plugins занимает 1.5Gb: org.apache.ivyde.eclipse org.eclipse.cdt.core org.eclipse.cdt.make.core org.eclipse.cdt.make.ui org.eclipse.cdt.managedbuilder.core org.eclipse.cdt.ui org.eclipse.core.resources org.eclipse.core.runtime org.eclipse.debug.core org.eclipse.debug.ui org.eclipse.e4.workbench org.eclipse.emf.common.ui org.eclipse.jdt.core org.eclipse.jdt.junit.core org.eclipse.jdt.launching org.eclipse.jdt.ui org.eclipse.ltk.core.refactoring org.eclipse.ltk.ui.refactoring org.eclipse.m2e.core org.eclipse.m2e.logback.configuration org.eclipse.mylyn.bugzilla.core org.eclipse.mylyn.context.core org.eclipse.mylyn.tasks.ui org.eclipse.pde.api.tools org.eclipse.pde.api.tools.ui org.eclipse.pde.core org.eclipse.pde.ui org.eclipse.ptp.services.core org.eclipse.rse.core org.eclipse.rse.ui org.eclipse.search org.eclipse.tcf org.eclipse.tcf.debug org.eclipse.tcf.te.tcf.locator org.eclipse.tcf.te.ui org.eclipse.team.cvs.core org.eclipse.ui org.eclipse.ui.editors org.eclipse.ui.ide org.eclipse.ui.intro org.eclipse.ui.views.log org.eclipse.ui.workbench org.eclipse.ui.workbench.texteditor org.eclipse.wst.common.modulecore org.eclipse.wst.jsdt.core org.eclipse.wst.jsdt.ui org.eclipse.wst.server.core org.eclipse.wst.sse.core Что нужно сделать, чтобы при работе в перспективе cdt эти непонятные плагины не создавались и workspace занимал приемлемый обьем?

Для workspace Eclipse размер директории .metadata ~1.5Gb как-то можно уменьшить? или очистить? В .metadata/.plugins лежит туча плагинов...

100 человек с электроникса - это еще не "большинство". Например, здесь средняя зарплата для вакансии «инженер-электронщик» в России 34 т.р. Нет никакого "большинства". Есть только вы, работа, которую вы делаете и зарплата, которую вам за эту работу платят. Всё.