Rst7

Масса вариантов тогда. TLS какой-никакой есть. Есть Task Tag - тоже можно использовать. Ну и да, опенсорсное ядро вполне можно и пропатчить.

Добавьте переменную __ECBList в область данных ОС, которая хранит состояние текущего потока. Конкретика реализации зависит от типа ОС. Либо храните его в Thread Local Storage (например, та же FreeRTOS поддерживает это). Это может быть даже банальный массив с обращением к нему __ECBList[GetCurrentThreadId()], где GetCurrentThreadId() - функция, которая вернет номер текущего потока. Вариантов масса. Расскажите Вашу конкретику, какая ОС используется?

Moderator: Закрепленный в этом разделе топик что помешало прочитать? Тему перенес.

Конечно. П-296. Вам же не нырять в воду долговременно?

Все равно понадобятся ускорительные цепи, чтобы фронты не заваливать на хоть сколько нибудь длинной линии. Так что "мешок деталей" все равно будет.

Если Вы про "слова производителей" в смысле слов производителей радиомикрофонов и IEM-систем с цифровыми каналами - то они сильно лукавят. Работает это все объективно так себе в реальных условиях, а с учетом негуманного совершенно прайслиста - так и вообще можно сказать, что не работает. Во-первых, никакими моднейшими алгоритмами сжатия с потерями в этих системах и не пахнет. Из-за ограничений по latency плюс предрассудки, царящие в отрасли. Во-вторых, когда в зал в зоне херового покрытия GSM заходит 1000 человек с мобильниками, и все телефоны начинают регулярно пытаться регистрироваться в сети, то наружу вылазят ограничения по линейности приемного тракта до ФСС. Забивает нафиг приемники по входу. И если в случае аналоговых систем там просто пошипит и перестанет, то в случае цифровых - будет мьют, что куда менее приятно.

Все правильно. Заказчик не обязан быть полностью в курсе всех технических тонкостей. А вот разработчик - обязан. Потому именно разработчик формализирует исходные требования, как минимум переписывает их технически грамотным языком, с учетом того, что ему потом буква в букву реализовывать это все придется. Более того, грандмастера этого эпистолярного жанра делают сразу три параллельных документа: а) Техническое задание - потому что, грубо говоря, там написано, что устройство должно делать. б) Технические условия - потому что там написано, что устройство должно делать (это есть в ТЗ) и как это будет проверяться (ведь разрабатывая ТЗ, всегда надо понимать способы проверки, дабы не попали в ТЗ какие-нибудь нетехнические вещи). в) Программа и методика испытаний - потому что там написано, как это будет проверяться (см. пункт про ТУ). Понятное дело, что конкретикой типа "подключить кабель такой-то к разъему X1" документы б) и в) наполнятся только к концу разработки, но все остальное будет готово. И да. За такой эпистолярный жанр надо сразу брать денег с заказчика. 20% от стоимости проекта - это совсем нестыдная цифра для того, чтобы оттолкнуться от чего-то. Если, конечно, делается документ, по которому потом удобно будет работать, а не шопопало абы этап закрыть.

Вы не поверите, но именно разработчик всегда пишет ТЗ на основе исходных данных заказчика. А заказчик его согласовывает. Так было испокон веков у профессионалов. Это только "ойтишнеги" решили, что ТЗ им должен заказчик предоставлять. Ну, собственно говоря, ничего удивительного: IT - это нифига не инженерное дело ;)

Moderator: Точно так же, как и создавать документацию, соответствующую любому другому стандарту, в любой другой САПР. Задавайте конкретные вопросы, иначе снесу тему.

Почему бы ТС не посмотреть изменение режима по постоянному току? Думаю, что это натолкнет его на правильный ответ ;)

Выключите в настройках сетевой карты "Interrupt Moderation" для начала.

Ну когда-то мы так и испытывали оборудование (приборы приемоконтрольные и извещатели пожарные). И на ЭМС, и согласование по искробезопасности. Ничего, справились.

Это пофиг по многим причинам: а) Так надо для функционирования устройства. б) Требуемая полоса под такой броадкаст всего 0.5Мбит/с, что для стомегабитной сети - как слону дробина. в) "Мало-мальски умный коммутатор" можно настроить. Главное, что обычные тупые не боятся такого совсем. Так что для проводного сегмента это не является проблемой. А вот для wlan - является, и именно это и хочется решить.

Встала задача на любом оборудовании из магазина "все по рублю" обеспечить следующее. Есть LAN - обычный Ethernet на тупых свичах, 100M/1G. Помимо обычных пакетов с данными одно из устройств в сети генерирует широковещательный пакет для всех других устройств с периодом 1мс. Ну вот так надо. В один из свичей включен обычный WiFi-роутер портом LAN. Соответственно, проводная сеть и WLAN - это просто одна сеть с точки зрения L2. Вот это широковещание укладывает WiFi напрочь. Причем, сама по себе проводная сеть продолжает работать как ни в чем не бывало. И да, сам по себе этот широковещательный пакет не интересует на беспроводных устройствах. Есть желание создать такой широковещательный пакет, который нормально распространится внутри проводной сети, но будет надежно отброшен WiFi-роутером и не попадет в WLAN. Для некоторых роутеров годится такое - в поле тип/длина заголовка самого Ethernet ставим 0 - и все, какой-нибудь TP-LINK TL-WR841N уже ничего не маршрутизирует в WLAN. Но другие роутеры, которые из соседнего магазина "не по рублю, а по рубль двадцать семь" таки валятся и от такого пакета. Понятное дело, что в каком-нибудь Mikrotik'е отлично настраивается правило, и уже никто никогда никуда не попадет, но надо обеспечить работу в произвольных условиях, с неизвестным заранее оборудованием у конечного пользователя. Возможно, кто-то читал стандарты более внимательно чем я, и подскажет, в каком направлении рыть. PS Отказаться от широковещания возможно, но не хотелось бы, уж очень удобно задачу решает.

Да, это можно опустить. Сделано исключительно для удобства понимания. Более того, обычно в Capture есть как флаг того, что он сработал, так и флаг того, что произошло переполнение (сработал несколько раз, а значение не вычитано из регистров). Тогда вообще все еще проще: void Compare(void) { if (CaptureFlag) { if (CaptureOvf) result=180; else result=CaptureVal; } else result=-180; } Прерывание Capture не используется вообще. Но, понятное дело в такой простоте есть тонкости. Связаны они с тем, что импульс может прийти ровно в момент Compare и немного дрожать, и там возможны варианты типа дребезга +180..-180. За этим надо следить. Более точно поведение надо обсуждать с учетом выбранного микроконтроллера и его периферии.

Очень просто. У Вас два прерывания - по захвату (Capture) и по сбросу опорного таймера (Compare) uint cnt; uint result; void Compare(void) { cnt--; if (cnt==0) { result=CaptureVal; } else { if (cnt>0) result=180; else result=-180; cnt=0; } } void Capture(void) { cnt++; } Вот и все. Какие тут сложности?

Да я проверил просто, будет ли генерация, и можно ли управлять амплитудой, в общем, не промахнулся ли я в придумывании схемы в уме. Строить это надо в железе для нормальной проверки, но у меня под рукой есть только OPA1632 (они явно похуже по искажениям будут), а вот эти драйвера от AD, похоже, еще не выпускаются.

Это почему? Да и откуда тут взяться синфазному сигналу (ну понятное дело, что из-за неточностей номиналов его чуть-чуть будет).

Я вот думаю, а не построить ли на таком драйвере именно генератор. Полностью симметричный. Ну вот типа так: R8 - это, собственно говоря, элемент управления. Резистивный оптрон, например.

Пожалуйста, вот вам раздел на сайте TI - http://www.ti.com/audio-ic/converters/adc/overview.html "High-performance audio ADCs", заметьте. Так что ирония неуместна совершенно. Остальные пункты вытекают из первого, но вот пятый отдельно порадовал: Ой-ой-ой. Вы хоть знаете, что такое абсолютный слух?

Да, конечно, не режектор, оговорились просто. Только как Вы себе видите пассивный BPF с центральной частотой 1кГц и с подавлением на 2кГц в 20дБ? И да, без катушек на сердечниках.

Мысль меня такая уже посещала и я ее усиленно думаю. Вопрос только в том, получится ли режектор на ОУ с нужными искажениям/шумом. Надо бы где-то 20дБ на октаву. Опять же, блин, проверить как?

Это понятно (ну мне понятно). Я про вот ту схему, которая "генератор Виктора" - ну конские там номиналы для адекватного уровня шума. Опять же, я толковал про другую схему. С выходом у меня вообще есть нюанс. Мне бы симметричный. Тоже голову ломаю, как бы сочинить хороший преобразователь из несимметрии в симметрию. Или вообще попробовать придумать полностью симметричный генератор. Мало. Для генерации с -120дБ у меня есть хорошая звуковая карта (RME ADI-2 PRO FS) Вот с выхода этой карты на вход моего АЦП: Только вот тот же порядок цифр THD у самого этого источника. А хотелось бы отделить одно от другого.

Пардон, но у меня чувство прекрасного страдает, когда я пытаюсь осилить 30 страниц, заполненных аудиофильским бредом. Просто ребятам на этих форумах невдомек, что помимо очередных клонов 5532 (определяются по моднейшей надписи в даташите GBWP=50MHz) есть и хорошие современные ОУ, которые могут нормально работать с более низкими сопротивлениями в цепях ООС.

а) Я не знаю, чего там люди намеряли, потому что пяток резисторов с сопротивлением в десяток килоом дадут три-четыре микровольта шума в полосе 20кГц. б) -120 мне мало, для -120 у меня есть RME ADI-2 PRO FS. Мне бы хоть на 10дБ лучше. А лучше на 20.