Jump to content

    

Rst7

Модераторы
  • Content Count

    4398
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Rst7

  • Rank
    Йа моск ;)
  • Birthday 12/08/1973

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Kharkiv-city

Recent Profile Visitors

23637 profile views
  1. Если вот так сделать, как выше - то все зависит от поведения pvTaskGetThreadLocalStoragePointer. Если его можно позвать не в потоке - то вполне.
  2. Ну Вам просто надо сделать вот что. Вместо int TickCounter; написать #define TickCounter ((int*)pvTaskGetThreadLocalStoragePointer(NULL,TICK_COUNTER_INDEX)[0] И Ваш код заработает. Ну да, надо еще инициализацию сделать в каждом потоке. #define InitTickCounter vTaskSetThreadLocalStoragePointer(NULL,TICK_COUNTER_INDEX,(void*)malloc(sizeof(int))) Тут, конечно, круто использовать alloca() и инитить переменную прямо в стеке, если Ваш компилятор это позволяет.
  3. Если Вы посмотрите на внутренности setjmp/longjmp - то они ничем не отличаются, по-большому счету.
  4. Масса вариантов тогда. TLS какой-никакой есть. Есть Task Tag - тоже можно использовать. Ну и да, опенсорсное ядро вполне можно и пропатчить.
  5. Добавьте переменную __ECBList в область данных ОС, которая хранит состояние текущего потока. Конкретика реализации зависит от типа ОС. Либо храните его в Thread Local Storage (например, та же FreeRTOS поддерживает это). Это может быть даже банальный массив с обращением к нему __ECBList[GetCurrentThreadId()], где GetCurrentThreadId() - функция, которая вернет номер текущего потока. Вариантов масса. Расскажите Вашу конкретику, какая ОС используется?
  6. Moderator: Закрепленный в этом разделе топик что помешало прочитать? Тему перенес.
  7. Конечно. П-296. Вам же не нырять в воду долговременно?
  8. Все равно понадобятся ускорительные цепи, чтобы фронты не заваливать на хоть сколько нибудь длинной линии. Так что "мешок деталей" все равно будет.
  9. Если Вы про "слова производителей" в смысле слов производителей радиомикрофонов и IEM-систем с цифровыми каналами - то они сильно лукавят. Работает это все объективно так себе в реальных условиях, а с учетом негуманного совершенно прайслиста - так и вообще можно сказать, что не работает. Во-первых, никакими моднейшими алгоритмами сжатия с потерями в этих системах и не пахнет. Из-за ограничений по latency плюс предрассудки, царящие в отрасли. Во-вторых, когда в зал в зоне херового покрытия GSM заходит 1000 человек с мобильниками, и все телефоны начинают регулярно пытаться регистрироваться в сети, то наружу вылазят ограничения по линейности приемного тракта до ФСС. Забивает нафиг приемники по входу. И если в случае аналоговых систем там просто пошипит и перестанет, то в случае цифровых - будет мьют, что куда менее приятно.
  10. Все правильно. Заказчик не обязан быть полностью в курсе всех технических тонкостей. А вот разработчик - обязан. Потому именно разработчик формализирует исходные требования, как минимум переписывает их технически грамотным языком, с учетом того, что ему потом буква в букву реализовывать это все придется. Более того, грандмастера этого эпистолярного жанра делают сразу три параллельных документа: а) Техническое задание - потому что, грубо говоря, там написано, что устройство должно делать. б) Технические условия - потому что там написано, что устройство должно делать (это есть в ТЗ) и как это будет проверяться (ведь разрабатывая ТЗ, всегда надо понимать способы проверки, дабы не попали в ТЗ какие-нибудь нетехнические вещи). в) Программа и методика испытаний - потому что там написано, как это будет проверяться (см. пункт про ТУ). Понятное дело, что конкретикой типа "подключить кабель такой-то к разъему X1" документы б) и в) наполнятся только к концу разработки, но все остальное будет готово. И да. За такой эпистолярный жанр надо сразу брать денег с заказчика. 20% от стоимости проекта - это совсем нестыдная цифра для того, чтобы оттолкнуться от чего-то. Если, конечно, делается документ, по которому потом удобно будет работать, а не шопопало абы этап закрыть.
  11. Вы не поверите, но именно разработчик всегда пишет ТЗ на основе исходных данных заказчика. А заказчик его согласовывает. Так было испокон веков у профессионалов. Это только "ойтишнеги" решили, что ТЗ им должен заказчик предоставлять. Ну, собственно говоря, ничего удивительного: IT - это нифига не инженерное дело ;)
  12. Moderator: Точно так же, как и создавать документацию, соответствующую любому другому стандарту, в любой другой САПР. Задавайте конкретные вопросы, иначе снесу тему.
  13. Почему бы ТС не посмотреть изменение режима по постоянному току? Думаю, что это натолкнет его на правильный ответ ;)
  14. Выключите в настройках сетевой карты "Interrupt Moderation" для начала.
  15. Ну когда-то мы так и испытывали оборудование (приборы приемоконтрольные и извещатели пожарные). И на ЭМС, и согласование по искробезопасности. Ничего, справились.