Перейти к содержанию

    

dxp

Свой
  • Публикаций

    3 495
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

1 Подписчик

Информация о dxp

  • Звание
    Adept

Информация

  • Город
    Novosibirsk

Посетители профиля

7 854 просмотра профиля
  1. А вот и готовая штука. PDF. Что характерно - ключ верхний, но n-канальный.
  2. На ZedBoard на "холостом ходу" греется несильно - чуть тёплый (одно ядро работает, bare metal, второе в стендбае со старта). На семинаре представитель компании прямо ответил на вопрос про одно- и двухядерные, что сам по себе кристалл тот же самый, но одноядерные являются просто отбраковкой двухядерных, и там просто дефектное ядро физически отключено на фабрике после тестирования, т.е. никакого потребления оно не даёт. Даташит говорит про потребление, полагаю, про одно ядро. Если их два, то надо соответственно умножать. Как-то так.
  3. "Требуется работник для работы на работе. Оплата деньгами." (с)
  4. 5 копеек. Для сварки тонкого железа нужно соблюсти следующую полярность: электрод на "-", прищепку - на "+" (это даёт меньшую температуру дуги при том же токе, его легче регулировать). Ну, и наложить шов тоже можно (а не только точки). Для это, конечно, придётся варить с отрывом - делать паузы, чтобы металл успевал остывать (электроды рутиловые, с основными этот номер не пройдёт), но ещё один важный момент - каждое следующее касание нужно делать не рядом с предыдущей точкой, а на её край - варить, как бы опираясь на уже сделанную сварку, - там металл получается немного толще за счёт наплавления и уже не прожигается на раз. Но вообще, 0.5 мм и тоньше - это, конечно, тяжело варить электродами. Очень трудно поймать правильный ток, чуть больше - прожигает влёт, чуть меньше - и непровар (шлак и грязь). Электроды рекомендую OK46.
  5. OS::get_tick_count()

    Функциональность проекта не сломалась? Какой МК? Компилятор?
  6. OS::get_tick_count()

    Похоже, что так. Кстати, этот красивый шаблон, он, я понял, требует же поддержки со стороны более-менее современного компилятора. Т.е. если его добавлять, то надо тестировать на всём зоопарке компиляторов (особенно это тяжко, как ты уже сказал, для iar/avr, iar/stm8). Кроме того, это будет вынуждать пользователя переходить на более современный тул. Имхо, оно того не стоит. С одной стороны да, можно просто выкинуть из TEventFlag::clear/is_signaled критическую секцию - должно везде работать, но надо проверять, если включать это в релиз. С другой стороны, ну сколько этих clear, is_signaled в коде попадается и какой при этом оверхед? Какой там прирост будет? Да практически никакого. Ну, и смысл ворошить? :)
  7. OS::get_tick_count()

    Ну, если уж на то пошло, то конкретно в этом классе TValue - это тип, который на практике всегда атомарный (перечисление с двумя значениями). Даже любой 8-битник может работать с этим за одно обращение. Получается, что из этих функций критическую секцию можно вообще убрать без ущерба для безопасности. Так что таки флаг событий не видится претендентом для использования в нём красивого шаблона. :)
  8. OS::get_tick_count()

    Ну, т.е. по сути не менять в этом случае ничего? И какой тогда смысл менять TValue на AtomicVar<TValue>? Получается, что конкретно класс TEventFlag трогать вообще смысла нет. Я правильно понимаю?
  9. OS::get_tick_count()

    Код красивый, и что он эффективно работает, не сомневаюсь. Но обращаюсь опять к прежнему своему вопросу: вот код функции TEventFlag::wait, там есть ветка else, она тоже защищена критической секцией. Как этот красивый шаблон поможет защитить код в else? Этот шаблон хорошо подходит только для одиночных переменных. Что собственно и отражено в его имени. :)
  10. OS::get_tick_count()

    Ну, так а профит-то получается в чём? Кроме этой get_tick_count() что-то больше и мест не особо просматривается. А там получается вместо одного макроса целая плюсовая кухня вырисовывается. И с чем боремся? :)
  11. OS::get_tick_count()

    Т.е. если в коде есть два обращения к двум разным переменным, объявленным таким способом, то для каждой будет рожаться критическая секция вместо того, чтобы использовать одну на обе? Например, вот простейший флаг события: bool OS::TEventFlag::wait(timeout_t timeout) { TCritSect cs; if(Value) // if flag already signaled { Value = efOff; // clear flag return true; } else { cur_proc_timeout() = timeout; suspend(ProcessMap); if(is_timeouted(ProcessMap)) return false; // waked up by timeout or by externals cur_proc_timeout() = 0; return true; // otherwise waked up by signal() or signal_isr() } } Тут секция защищает всю функцию. Как тут эта автоматика поможет? Тут же несколько разных объектов и вызов внутренних функций, которые подразумевают, что вызываются из критической секции (а внутри они тоже выполняют немало действий, которые должны производиться тоже в критической секции). Проводить анализ, что там безопасно, а что опасно без критической секции, это ещё та работа. Сейчас оно просто и серьмяжно лочит на входе, и всё работает как часы.
  12. Не понимаю, какие подробности нужны. Это обычный яркостный сигнал, оцифровываете его величину - это есть яркость пиксела. Цвета там никакого нет и быть не может. Тепловизор видит тепловые контрасты, там есть только разница по величине, цвета - разницы по спектру - никакого нет. Точнее, приёмник видит в диапазоне 8-14 мкм, это для него считается одной "цветовой" полосой. Что касается снятия сигнала, то смотрите внимательно на диаграмму: там указано, с какого такта мастер клока (от других сигналов синхронизации) начинаются данные. Вот с этого такта и воспринимаете отсчёты АЦП как величину сигнала. Яркостного сигнала. 640 пикселов - 640 тактов. И так с каждой строкой. Кстати, даже правильно оцифровав сигнал и выведя его на монитор, вы картинки не увидите. Дело в том, что там очень большой разброс неравномерностей чувствительности элементов матрицы, который приводит к тому, что сигнал фона на этих наравномерностях даёт больше величину, чем полезный сигнал. Поэтому требуется выравнивание. Самое простое - снять т.н. темновой кадр, например, закрыв матрицу чем-нибудь, что даёт равномерный поток, и потом его вычитать из всех последующих кадров... Но это уже другая история.
  13. OS::get_tick_count()

    Не понял. Вот берём пример из стартового поста: INLINE tick_count_t get_tick_count() { TCritSect cs; return Kernel.SysTickCount; } Тут TCritSect разворачивается в полноценный код. Но мы-то этого не хотим, например, в случае арма, где доступ к SysTickCount и так атомарный. Как сделать так, чтобы на арме секция была пустой, а на авре полной?
  14. Ну если так, то тут... прямо нечего сказать. Если это является проблемой, всё остальное просто неподъёмно.
  15. По ходу это ULIS. Тоже не понимаю проблемы. Сигнал видео там не является стандартным с точки зрения телевизионных и видео форматов. Ну и что - это обычное дело с проприетарными сенсорами. Технически там всё просто: формируете диаграмму в соответствии с даташитом (сигналы RESET, INT, MC) - имея ПЛИС, это делается достаточно обычно, далее оцифровываете аналоговый сигнал - тут главное поймать "окно" семплирования, т.е. момент, когда сигнал уже "успокоился" от переходного процесса переключения очередного пиксела - чтобы не ошибиться, можно это делать непосредственно перед моментом переключения на следующий пиксел. Все времянки надо честно соблюдать. 8.33 МГц там получаются не просто так, а складываются из времянок формирования строки и количества строк. Причём тут 25 МГц, не ясно. Да, ещё надо учесть конвейерную задержку АЦП. Если все сделать правильно, то никаких особых проблем со снятием сигнала нет. Там потом трудности иного рода вылезают - например, регулирование режима сенсора так, чтобы выходной сигнал был в пределах выходного диапазона, а то у микроболометров есть "привычка" уводить сигнал из диапазона при изменении температуры. На то он и болометр.