andrey_p

Да, именно так. Для ответа на этот вопрос нужно понимать, по какому "интерфейсу" у Вас работает то, что подключено к UART. Также нужно понимать, каким образом Вы планируете обрабатывать данные UART в приложении.

Вы можете устанавливать таймауты, посмотрите на tcsetattr(). Вам нужны параметры VMIN и VTIME.

И что? Как это поможет на фоне огромного количества помех? Лодка может двигаться, а рыбы стоять. А может быть всё наоборот. А ещё рыбы двигаются весьма специфично. Именитый производитель не смог выделить рыб. При этом даже на профильных форумах писали, что эта функция весьма условна.

Рыбак, спиннингист. Давным давно купил себе Humminbird 728 (кажется) с двумя сонарами - dualbeam (20*200кГц/60*83кГц) и quadrabeam(+2X35*455кГц). Недешёвая была игрушка во второй половине нулевых. Имеет функцию поиска рыбы. Плавал в основном по Вуоксе. С рельефом твёрдого дна справляется неплохо, но вот функция поиска рыбы не работала от слова совсем. То есть он находил косяки китов и крокодилов, но визуально это не подтверждалось. Когда стал разбираться в вопросе, то стал понимать, что эта функция может работать только в идеальных условиях. Луч сонара отражается не только от дна и рыб, но и от границы перепада температур, от растительности, искажается илом и т.п. Мне так кажется, что разработка подобного устройства будет стоить весьма серьёзных денег, а результат в любом случае непредсказуем.

Посмотрите в сторону "подсветки страниц" (page coloring). Проблема, возможно, в этом. P.S.: С данным процессором не работал.

Я познакомился с пиками ещё в середине 90-х, очень много писал под pic16 и pic17. Писал на ASM в MPLAB, как для себя, так и на коммерческой основе. Проекты были достаточно большие, с задействованием богатой периферии и математики. Несколько раз пытался перейти на Си, но не видел ни одного вменяемого компилятора для 8-битных микроконтроллеров PIC. Код получался монстроидальный и просто не влезал в контроллер. Необходимые математические алгоритмы вообще не получалось выполнять в реальном времени, при этом на ASM они летали. В общем я изначально и занимался тем, что переписывал код на ASM после того, как сишники сдавались. Потом переключился на pic18, но остался на ASM. В MPLAB очень мощный макроассемблер, позволяющий делать чудеса. В конечном итоге я сделал библиотеку макросов, которая позволяла писать на си-подобном языке. Библиотека была задокументирована и все конструкции покрывались тестами. Это очень сильно упростило разработку. Ниже описание некоторых конструкций. Но это лишь малая часть, вся жесть в деталях, особенно в описании типов данных и условий. Мой Вам совет - если работаете с 8-битными PIC, держитесь подальше от Си.

Там суммы немного не те, да и выбора службы доставки нет.

Есть богатый опыт оптимизации и разработки высоконагруженых приложений. Увы, но это давно не так. Оптимальный код узких мест разрабатывается с учётом специфики платформы. Этот код хорошо документируется, так как при смене платформы он модифицируется или переписывается под новую платформу. Да он нормально не сообразит без подсказок. Для правильной оптимизации нужно понимать архитектуру кэша в целом и на каждом уровне (N-way associative / direct mapped), понимать алгоритмы (политики) вытеснения данных из кэша, алгоритмы синхронизации ядерных кэшей, алгоритмы подсветки страниц памяти, принцип работы TLB и т.п. Вашим студентам несказанно повезло, сейчас мало кто этим озадачивается. И за это Вам огромное спасибо! Я думал, что этому сейчас и не учат...

С личным пользованием у таможни вопросов не было, а вот по поводу "шифрования и криптографии" требовали письмо от производителя с нотариально заверенным переводом. Я писал письмо, отправлял в Terasic, они печатали его на фирменном бланке, ставили подпись и отправляли мне скан. Далее заверенный у нотариуса перевод. В последний раз на таможне сказали, что отныне будут принимать только оригинальные письма с печатью, сканы не катят. Там какое-то новое распоряжение вышло. А вот как такую железку обратно отправлять, вопрос. Кстати, DHL и FedEx сами палят такие посылки, насчёт остальных не знаю.

Offtop: А Вы раньше заказывали подобные платы у буржуев? Я два раза покупал платы FPGA у буржуев (Terasic) и два раза очищал их на таможне. Тот ещё геморрой. В последний раз мне намекнули, что электронное письмо от производителя больше не примут и платы завернут.

Кэш практически убил классическую алгоритмическую оптимизацию. Существуют различные техники оптимизации программ и эти техники зависят от конкретного железа. Самое узкое место систем с динамической памятью - это подсистема памяти, включая кэши. Ядра молотят с огромной скоростью, проблема эффективно доставить данные к ядрам и "выгрузить" данные после обработки. Именно это является причиной прогресса в скорости обработки потоковых данных и практически полное отсутствие прогресса в скорости работы "алгоритмических" программ. Посмотрите на скорость работы графических ускорителей и на характер обрабатываемых ими данных, сразу станет всё понятно. Если Вам интересна эта тема, найдите книгу Криса Касперски "Техника оптимизации программ". Несмотря на то, что книга устарела, её можно использовать как трамплин в мир оптимизаций. Есть неплохие курсы по оптимизации на зарубежных ресурсах, правда, на английском. Этот мир реально интересный. Познав подсистему памяти, Вы измените свой взгляд на классические алгоритмы:) И уж тем более забудете про динамическое выделение памяти там, где этого можно избежать. Ресурсов съедается немерено, да и фрагментацию никто не отменял.

Есть у меня подозрение, что автор умолчал о главном - о синхронизации двух мониторов между собой, а также с внешним источником. И если первое ещё можно сделать силами современных видеокарт с несколькими головами, то второе нереально. Отсюда и FPGA.

Можно взять одноплатник вроде RPI и попробовать прикрутить к нему второй дисплей через видеоадаптер USB. Некоторые такие видеоадаптеры работают под Linux. Хотя всё зависит от требований.

Теперь понятно. Это хорошо при любом решении. Что-то на рынке чипов как-то совсем туго с ISDN. Всё discontinued и obsoleted. Есть только решения для VoIP, в том числе и мосты к ISDN. Может быть посмотреть в эту сторону? Пульты всё равно придётся переносить на новые технологии, зато вы начнёте перенос системы на новые рельсы. В данном случае VoIP. То есть пульт работает на VoIP, а далее через мост в ISDN. Вопрос только в том, как мост передаёт данные.

Я не знаю, какая у Вас топология сети и дистанции, но если речь идёт о соединении точка/точка без усилителей, то я бы предложил делать наложенную сеть, основанную на другом канальном интерфейсе. Найти сейчас специалистов по ISDN не так просто. А найти классических телекомщиков с опытом программирования - это вообще нереальная задача. Говорю, так как в теме. Я очень хорошо знал ISDN и BRI/PRI и являюсь сертифицированным специалистом в данной области - полгода учился в MOSBELL (Alcatel). Вот только последний опыт в этой теме у меня был лет 20 назад. Это решение будет стоить космических денег по причине, описанной выше. Постарайтесь сделать наложенную сеть - это сильно упростит Вам жизнь. Вы пульты сами производите? Система имеет отношение к СКУД?

Заменить указанные микросхемы в составе устройства практически нереально. Проще найти эти микросхемы в продаже и закупить на несколько лет вперёд с учётом потребностей. Ваше устройство, по сути, является ISDN терминалом с доступом по BRI (2B+D). Возможно, обладающее некими специфическими функциями. Дешевле будет переделать всю начинку. Можете рассказать об устройстве подробнее, не раскрывая коммерческих секретов?

Вы, видимо, невнимательно прочитали. Я говорил про оптимизированное решение. Фразы "темпоральные функции" и "создают по ходу нужные таймеры" не дают представления об организации подсистемы таймеров. Таймеры можно реализовать и через таблицы счётчиков, и даже через системные таймеры, но к "большим" системам это не имеет никакого отношения. Так я и не спорю по поводу наглядности диаграмм состояний. Но менеджеры не имеют к диаграммам состояний никакого отношения. Перечитайте ещё раз написанное. Менеджеры работают в составе автоматного процессора и специфичны для домена. Это утверждение говорит лишь о том, что Вы никогда не разрабатывали больших систем. При работе с проектами уровня "микроволновки" о многих вещах даже не задумываются. А попробуйте построить эмулятор сети мобильной связи на автоматах. Миллион(ы) мобильных терминалов, тысячи BTS, десятки/сотни BSC, MSC, GMSC. Если Вы имеете некоторое представление о мобильной связи, то попробуйте представить себе хотя бы эмулятор мобильного терминала. Не нужно называть абсурдом то, с чем Вы не сталкивались. Это просто говорит о разных подходах. Да, в текущих реалиях приходится подстраиваться под существующие ОС. Но я убеждён, что в идеале сервисы ОС должны быть сделаны на автоматах, а планировщик ОС заменён на автоматный процессор с поддержкой последнего на уровне железа. Об этом я и писал в статье. Но это ни в коем случае не говорит о том, что в текущих реалиях в обработчики action можно запихивать тяжеловесные вычисления. И зачем Вам инструменты профилирования, если расчёт времени выполнения цепочки action должен быть встроен в компилятор автоматов? А Вы уверены, что когда Вы занимаетесь профилированием, Вы проходите по всем возможным цепочкам? У меня есть окружение, только собственной разработки. И в автоматном процессоре есть очередь сообщений, поддержка таймеров и ещё куча всего. Реализация отличается по доменам. А вот средств синхронизации в автоматном процессоре нет, но они есть в диспетчере. По вполне понятным причинам - автоматный процессор однопоточный по определению. Если Вы работаете по найму, то все Ваши работы принадлежат работодателю. Все. Тем более, если работодатель финансирует исследования, как это было в моём случае. На любую публикацию нужно получать разрешение работодателя, а публикации должны проходить "очистку". В западных компаниях этот процесс далеко не формальный. Владелец бизнеса вправе сам принимать такие решения. Я начинал работы по автоматному процессору у прежнего работодателя и все результаты остались у него. В новой компании я воссоздал весь framework с нуля как раз из-за опасений того, что могут быть юридические проблемы. Во всех файлах и документах присутствуют copyright-ы компании. Может быть Вы считаете нормальным снести копирайты и перенести код в другую компанию, но всё это может закончится плачевно. Честно говоря, странно слышать подобные высказывания от модератора. Я не хочу вступать ни в какие ненаучные споры. Если Вам не интересен опыт других людей, то так и напишите. Я не могу выложить ни проекты, ни даже их часть. И это не игра в верю/не верю. У Вас же есть подобные диаграммы для свободного доступа, может Вы выложите их, а мы посмотрим?

Я, наверное, немного отстал от жизни. Если речь идёт о генерации кода из диаграмм, то в последний раз я имел дело с автоматической кодогенерацией в начале нулевых - пользовался продуктами Telelogic. Результат меня не сильно удовлетворил. Но основная проблема была даже не в самих средствах проектирования, а в абсолютном неприятии такого подхода среднестатистическими программистами. Ну да ладно, это совсем другая тема. Я использовал какие-то редакторы, порождающие SCXML код, но не впечатлился. Но я свой язык разрабатываю, поэтому у меня субъективное мнение:) Кстати, основная проблема при разработке языка совсем не в описании поведения, а в описании взаимодействия автоматов. То, о чем HSC молчит... Все мои работы по HSC базировались на этом документе 1986 года. И на драфте SCXML, который пребывал в таком состоянии, наверное, лет 10. Когда начинаются разговоры об автоматах, то обычно речь идёт только о состояниях и переходах, но мало кто говорит о создании экземпляров и об обмене сообщениями. А всё дело в том, что любое универсальное решение хоронит всю идею автоматов. Может быть, конечно, эти проблемы учтены в упомянутых продуктах - нужно будет взглянуть. Ниже лишь некоторые нюансы, которые нужно учитывать при разработке решения на автоматах: 1) Основная концепция любого автомата - он должен находиться в одном из состояний. Промежуточные состояния невозможны, поэтому все действия, порождённые некоторым событием, должны производиться мгновенно. Что такое мгновенно? Как в ОСРВ - любое действие должно завершиться не позднее, чем через N секунд. Сразу возникает вопрос: можно ли использовать, например, циклы на переходах? Как считать время выполнения цепочки on_exit->on_transaction->on_entry, причём с учётом history? Мы решили эту проблему введением диспетчера, о котором я писал выше. Нормальный автоматный компилятор должен ограничивать предельное (заданное) время действий на любом комплексном переходе, предлагая сбросить некоторые действия на диспетчер. 2) Я всегда считал и считаю до сих пор, что любое ПО должно разрабатываться с учётом доменной специфики. Так как большая часть моей работы связана с разработкой высокопроизводительных систем, то я считаю динамическое выделение памяти системными аллокаторами абсолютным злом. Если и выделять память, то только с учётом специфики домена. Очередь сообщений в автоматном процессоре должна быть произведением искусства. Я серьёзно. Это касается не только микроконтроллеров, но и полноценных микропроцессоров. Основная задача - снизить частоту и объёмы выделяемой памяти под данные сообщений. Существует несколько решений данной проблемы, но они специфичны для каждого домена. 3) На самом деле, продолжение предыдущей темы. Broadcast и multicast сообщения. Это в теории всё выглядит красиво, а что получается в коде? Простой пример: менеджер ресурсов. Есть один миллион экземпляров (instances). Посылается сообщение, на которое должен отреагировать первый получивший его экземпляр, находящийся в состоянии A. Или экземпляр, находящийся в состоянии A и у которого переменная S в instance data установлена в значение XXX. Посылать запрос к каждому экземпляру? Система просто ляжет. Можно, конечно, вручную вкорячить хэш таблицы, прикрутить базу данных, потом попытаться всё это синхронизировать. Но это уже не совсем автоматы. 4) Автоматы хороши тем, что с их помощью можно создавать ТЗ, понятные заказчику, далёкому от мира компьютерных технологий. Одностраничная диаграмма может легко заменить десятки страниц неперевариваемого текста и при этом показать все дыры в требованиях. Это большое преимущество автоматов, но есть одно но. Заказчику это можно показывать только до определённого уровня детализации. Увеличиваем уровень детализации для кодогенерации - заказчик перестаёт понимать схему. Уменьшаем уровень детализации - не можем генерировать код. Золотой середины для более менее вменяемой системы не существует. Микроволновка не в счёт. 5) Таймеры. Здесь можно вообще диссертацию написать, тем более, что эта тема в HSC не раскрыта. Автоматы предоставляют два примитива для таймеров: set(reset)_timer / clear_timer. Причём после выполнения clear_timer связанное событие от таймера не должно прийти никогда. А теперь вспоминаем про очередь - события от таймеров уже могут находиться в ней, то есть очередь нужно чистить. А теперь представьте несколько миллионов активных таймеров в системе и попробуйте придумать универсальную оптимизацию. Этот список можно продолжать бесконечно. Я не знаю средства разработки, о которых Вы говорите. Я также не знаю, решены ли в них обозначенные и другие проблемы. Но имея некоторый опыт разработки автоматных процессоров смею предположить, что нет. Ещё раз повторю, автоматный процессор пишется под конкретный домен и конкретную платформу. Только в этом случае он может быть эффективным. Если речь идёт об абтрактной поведенческой модели, то такая модель легко кодируется препроцессором СИ на switch/case. А Вы опубликуете на форуме пример коммерческого проекта, закрытого NDA? Открытых проектов, к сожалению, я не веду. Хотя, наверное, стоило бы...

Так уж получилось, что около 15 лет назад я подсел на "автоматы". В то время я работал инженером в крупной западной телекоммуникационной компании. Мы разрабатывали ПО, связанное с обработкой протоколов. Понятно, что протоколы хорошо ложатся на автоматы, но уже тогда было понятно, что автоматный подход к программированию был сильно недооценён. В то время я реально "болел" тремя "болезнями": автоматами, FPGA (работал с кучей плат с Altera) и глубокой платформенной оптимизацией ПО (потоки, кэши, память, и т.п.). Мы с коллегой, который привнёс немало теории в практику, начали разрабатывать различные окружения и библиотеки для автоматного программирования. Сначала мы базировались на драфте SCXML, но нашли его слишком перегруженным. Дело в том, что разработчики стандарта попытались объединить логику и действия в одном месте, но такой подход нам не понравился. В итоге мы пошли своим путём и это закончилось написанием "легковесного" компилятора и runtime для иерархического Harel State Charts, правда без поддержки параллельных состояний и переходов по условию. С параллельными состояниями и переходами по условию не было никаких проблем, но разработку и тестирование нужно было закончить к конференции и мы просто не успевали. Посмотрите на Harel State Charts - это нечто удивительное. Мы стали использовать разработанные окружения в реальных проектах. Но везде была одна проблема - мы не могли сделать проект с нуля, так как поддержка существующего ПО не предполагает такой работы:) А в небольших доработках мощь Harel State Charts не была востребована, поэтому мы упростили разработанное окружение до необходимого уровня. В какой-то момент мы с коллегой приняли решение пойти в аспирантуру, как раз к упомянутому выше Анатолию Абрамовичу. Но, проучившись год, покинули её. Причины ухода из аспирантуры не имеют ничего общего с темой. В процессе обучения я набросал статейку, можете найти её в интернете: "Программисты, компиляторы, процессоры - поиск единого вектора". Статья написана мной от и до, на список авторов можно не смотреть:) Статья, конечно, не совсем научная, но она писалась для широкого круга читателей. Разработанная нами концепция подразумевает разделение любой задачи на две части: автоматную и "процедурную". Автоматная часть работает под управлением автоматного процессора, который запускается в отдельном потоке и отвечает за очереди сообщений, работу таймеров, обработку переходов, смену состояний и условно мгновенные действия. Отдельно хочу упомянуть, что в автоматной части запрещено "ручное" выделение памяти, но это отдельная история - оптимизаторы меня поймут. "Процедурная" часть съедает остальные доступные потоки в системе и базируется на концепции диспетчера (пул потоков с очередью). Идея проста - сбрасывать долгоиграющие задачи в диспетчер, а автомат переводить в состояние ожидания завершения процедуры в диспетчере. Уже позднее я применял данный подход в различных проектах при разработке промышленного ПО, в том числе и написанных с нуля. Как на серверах, так и на контроллерах. Такой подход даёт множество плюсов. Главный плюс - на этапе проектирования всплывают все "тёмные" места, то есть очень трудно пропустить мёртвое состояние. Ещё плюсы - лёгкая автоматизация тестирования, лучшее тестовое покрытие и упрощённый поиск дефектов. Ну и плюс, который понравится архитекторам: автоматный подход позволяет разрабатывать систему сверху вниз с одновременной разработкой тестового окружения и непосредственно тестированием. А вот аппаратный автоматный процессор я так и не потянул. Для его разработки я приобрёл у Terasic SoCKit. Идея была проста - перенести автоматную часть на FPGA, и диспетчер на HPC. Начал работы, но надорвался:) Это невозможно потянуть одному человеку при условии необходимости зарабатывания денег.

Не уверен, что поместил тему в правильный раздел, но другого подходящего места не нашёл. Кому-нибудь из форумчан приходилось делать выбор между FNet и LwIP? По LwIP достаточно много информации, FNet похож на тёмную лошадку. Интересует использование в окружении bare metal. Если кто-нибудь реально сравнивал эти два стека, не могли бы поделиться наблюдениями?

Гугл вам в помощь:) MED'EL

Добрый день! А платы KONA от AJA Вас не устраивают? Эти карточки умеют работать напрямую с видеокартами AMD, что сильно снижает нагрузку на систему в определённых случаях.

Asterisk - это сервер, причём не самый лучший для ответственных задач. Здесь же нужен P2P SIP. Насколько мне известно, готовых проверенных решений в свободном доступе нет, но задача интересная. Только ТЗ нужно нормальное сделать, так как задача достаточно сложная и оценить её по имеющимся данным практически невозможно. Работу нужно делить на две части: подключение периферии и VoIP. Использование DSP - это вообще отдельный разговор. Здесь большУю часть проекта займёт разработка тестового окружения и непосредственно тестирование.

Добрый день! Не могли бы Вы ответить на несколько вопросов: 1) Как предполагается конфигурировать систему? 2) Почему встал вопрос подключения аудио устройств? На плате нет стандартных интерфейсов? 3) Не могли бы Вы описать более подробно способ организации конференции? Просто вариантов много.

Добрый день! А чем Вас гончарные круги не устраивают? Есть на любой вкус и размер, например: http://ceramgzhel.ru/goncharnye-krugi-hsl http://ceramgzhel.ru/Shimpo_RK-Whisper_RK-3D http://ceramicastore.ru/goncharnye-krugi/g...po-rk-5t-1.html и т.д. (поиск в гугл поможет)