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

    

AHTOXA

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

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

  • Посещение

Репутация

0 Обычный

1 Подписчик

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

  • Звание
    фанат дивана
  • День рождения 04.09.1970

Контакты

  • Сайт
    https://github.com/antongus/

Информация

  • Город
    Уфа

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

11 949 просмотров профиля
  1. Надо писать на уровень выше, это архив. Кстати, там уже была такая тема. Её местный "Технический специалист" закрыл, типа, невозможно. Хотя в документе на гугль-доксах коллега halfdoom приводил пример форума на таком же движке с нормальным редактором:
  2. А, понял. Эта ссылочка имеет класс fa-share, и её блочит мой блокировщик рекламы. Видимо, название класса совпадает с какими-то известным классом из социальных кнопочек. Вопрос снимается, прошу прощения за беспокойство.
  3. В старом форуме можно было ткнуть в заголовок цитаты, и перейти к исходному (цитируемому) сообщению. Сейчас этого нет. Это очень неудобно, потому что часто бывает нужно вернуться к исходному сообщению и прочитать его полностью.
  4. Возможно речь идёт про это (https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=149152):
  5. А зачем организовывать защиту? Разве от 1.5 вольт что-то может сгореть?
  6. То есть, если в документе есть какое-то замечание, а в этом форуме нет темы по этому замечанию, то надо создать такую тему?
  7. Тогда уж nEw_КаКоЙ-тО тАм РеГиСтР_VaLuE Моё предложение: mySuperRegisterCachedValue
  8. stm8, где VREFINT_Factory_CONV

    В даташите на L151, например, указан в разделе 5.2 Register map.
  9. Инициализация и работа с USART1

    Если отладка, то может быть вы смотрите на UART3->DR? Тогда отладчик этим чтением сбрасывает флаги.
  10. OS::get_tick_count()

    Тогда предлагаю оставить как есть. Системные тики мы уже соптимизировали (вернее, теперь есть способ их оптимизировать путём объявления дефайна в проекте), остальное, скажем так, оптимизации особо не требует :)
  11. OS::get_tick_count()

    Наверняка у Сергея есть ещё кандидаты на оптимизацию. Давай подождём, что он скажет.
  12. OS::get_tick_count()

    Ну почему же. В TEventFlag уберутся критические секции в функциях clear() и is_signaled(). Полной автоматизации не выйдет, но небольшой кусочек будет оптимальнее.
  13. OS::get_tick_count()

    Я ведь уже ответил на этот твой вопрос:) В TEventFlag::wait() нужно оставить общую критическую секцию и использовать функции без CS (getNoCs()/setNoCs()).
  14. OS::get_tick_count()

    Ну, лично я сразу принял вариант с макросом:) А Сергей сказал, что надо что-то универсальнее. Вот и придумываем:)) Вот, я имел в виду что-то типа такого: template <typename T, size_t atomicSize = 4> class AtomicVar { public: void set(T value) { CS cs; val = value; } void setForceCs(T value) { TCritSect cs; val = value; } void setNoCs(T value) { val = value; } T get() { CS cs; return val; } T getNoCs() { return val; } T getForceCs() { TCritSect cs; return val; } void inc(); // -- для тиков private: struct FakeCriticalSection {}; using CS = typename std::conditional<sizeof(T) <= atomicSize, FakeCriticalSection, TCritSect>::type; T val; }; Можно использовать вместо Kernel.SysTickCount, TEventFlag::Value и в других подобных местах. По крайней мере позволит убрать все ненужные критические секции почти автоматом, и не придумывая на каждый случай макрос. ЗЫ. Вот мини-тест: https://wandbox.org/permlink/zmJsh7mWUj1oQ2JH