Jump to content

    

haker_fox

Свой
  • Content Count

    5954
  • Joined

  • Last visited

Community Reputation

0 Обычный

About haker_fox

  • Rank
    Познающий...
  • Birthday 01/18/1986

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

15090 profile views
  1. Эх, я уж думал, что Господь услышал) Я видел это объявление. Но нужных мне микросхем там нет. Мне нужны лёгонькие STM32F030 (051), а глючные оригинальные F103 я бы и даром не взял. Там слишком длинная еррата. Хотя у меня немного их и есть.
  2. РРРР! Пока для личного пользования еду на старых запасах официально купленных STM. Есть немного LPC. Господи, услышь наши молитвы, ниспошли нам STM'ок по цене хотя бы в два раза выше докризисной. Но чтобы это было уже стабильно и на годы...
  3. Блин, страшно там закупаться) Я бы взял по этой цене. Мне 10 штук вполне достаточно для личных целей...
  4. Хоть и без ответа на Ваш вопрос, но: а зачем? Где такая хитрость нужна?)
  5. Сейчас нет. Завтра появятся. Что же мне добавлять virtual в спешном порядке?
  6. P.S. Резюмирую. Да, я немного плыву в теме накладных расходов при использовании классов и виртуальных методов. И ещё много в чём. Но не я один плыву. Например, тут утверждалось постоянно, что будет использоваться VTABLE при использовании виртуальных методов. Чтож, будет. Но только при определённых обстоятельствах, котоыре не уточнялись. А не всегда. Так что... вывод каждый может делать сам.
  7. Не в разных, а в тех местах, которым эти настройки принадлежат. По-другому мне кажется странным... Вот добавил код снизу. Вот фрагмент листинга. Ну всё, не применяем Си++ во встраиваемых устройствах) Видны обращения к "втабле")))
  8. Применяю плюсы в МК года с 2006. Темпалгин и цитрамон не глотаю. Просто Вы не знаете Си++. Это единственно верный ответ.
  9. Ну вот и я об том же... Я чуть выше неверно выразился, говоря о том, что метод заинлайнился. Торопился. Допустил опечатку. Конечно же не заинлайнился, а просто попал в этот же листинг. Переход BL на него есть. А так, если я всё корректно проверил, да, встроился. Но у меня драйвер описан полностью в хидере.
  10. Брр... Ненадёжно. Особенно, если modbus rtu. Лучше ножку найти свободную и дёргать направление передачи по желанию.
  11. Отладочная - не совсем показатель) ИМХО, конечно. Всё-таки она работает, как правило, на столе. В тёплых и мягких условиях. Уф, спасибо!
  12. Не знаю, в каком диапазоне у Вас меняется аргумент SOME_TRESHOLD , но пусть от 0.1 до 1.0. Сгенерите таблицу квадратных корней в lookup таблицу, затем домножайте аргумент на 100 (в рантайме будет быстрее, чем вычислить корень), а можно и сразу умноженный записать. Затем, выбирайте из таблицы получившимся индексом... Ну это так, на гране полушутки...))) Вы уж не серчайте, но это на фоне темы об "эффективном программировании" от Си-плюс-плюс-водов))))
  13. Добрый день! Не могу разобраться сам. Можно ли пустить этот интефрейс от MAC, встроенного в микроконтроллер, до PHY, расположенного на материнской плате. Сам микроконтроллер будет располагаться на плате-модуле, который будет надеваться на штыревые разъёмы типа PLD-20. Видел, что линии пускают через разъёмы типа SODIMM (сорри, если неправильно назвал), но вот через "банальные штыри" не видел. Мне даже 100 Мбит не нужно. Достаточно 10, если такое ограничение потребуется.
  14. О, у Вас новые статьи на хабре! Почитаю! Рад, что Вы в порядке)))
  15. У меня так и сделано. И есть общий абстрактный класс, в котором определены виртуальные функции open(), close() (эта не реализуется, т.к. во встраиваемой системе мне нет нужды закрывать драйвера), имеется член m_open, который сохраняет результат открытия драйвера. Лучше или хуже - это понятия субъективные, поэтому отвечу за себя только. Мне лучше тем, что древовидная структура классов драйверов позволяет при необходимости добавлять сущности не к конкретным драйверам, например последовательных портов, а в их базовый класс от которого они наследуются. Или даже в общий базовый класс, если это нужно для всех всех имеющихся драйверов. Данная концепция ни раз себя оправдывала, мне так удобно. Если Вам удобно делать по-другому, то, пожалуй, дискуссию можно закрыть) Каждый останется при своём мнение, а возможно и изменит его в будущем. Смотря как объявлена виртуальная функция в базовом классе. Если это pure virtual (не помню русский термин), то обязан. В противном случае - нет. А Вы читаете внимательно то, что я пишу? Я, как я помню, написал "в общем случае". Фраза допускает и то, что есть исключения. Так я Вас разве заставляю это делать? Мне, вот, нужно. Т.к. тот же графический интерфейс прибора позволяет задавать настройки порта. И где мне их прикажете хранить? В моём случае они как раз доступны и доступные через единый (т.е. для всех платформ) интерфейс. Для Вашего уникального последовательно порта, который, как мне кажется, является чем-то даже и не похожим на УАПП можно создать свой драйвер, даже не наследуя от базового класса. Здесь, я считаю, нужно выбирать, как проектировать. Тупо наследовать и перегружать я, вроде, пока ни кого не призывал) Возможно и будут, признаюсь я не все тонкости Си++ знаю, и в листинг по каждому чиху не смотрю. Смотрю, обычно на map-файл и делаю вывод. Ну и что? Вот код задачи из текущего проекта (личного) У драйвера последовательного порта перегружен метод open(), вот фрагмент class Stm32f0x1UsartCmp : public Stm32f0x1Usart<Num, RxSize, RxPin, RxAF, TxPin, TxAF> { public: Stm32f0x1UsartCmp() {} RetVal open() override { if (this->m_open == RetVal::Ok) return this->m_open; /// TODO automatically choose vector based on template args Nvic::install(USART1_IRQn, irqHandler); setupDirPin(); setDirIn(); this->setNvic(); this->enableClock(); BaseUsart::Settings settings; settings.baudrate = BAUDRATE; this->m_open = this->setSettings(settings); flush(); return this->m_open; } Видно, что драйвер отнаследован. Вот листинг \ In section .text, align 4, keep-with-next 11 void CmpSlave::task() { \ _ZN4Link8CmpSlave4taskEv: (+1) \ 0x0 0xB57C PUSH {R2-R6,LR} \ 0x2 0x.... LDR R0,??DataTable2_5 \ 0x4 0x7800 LDRB R0,[R0, #+0] \ 0x6 0x2800 CMP R0,#+0 \ 0x8 0xD105 BNE ??task_0 12 static Drv::Stm32f0x1UsartCmp<> usart; \ 0xA 0x2001 MOVS R0,#+1 \ 0xC 0x.... LDR R1,??DataTable2_5 \ 0xE 0x7008 STRB R0,[R1, #+0] \ 0x10 0x.... LDR R0,??DataTable2_6 \ 0x12 0x.... 0x.... BL _ZN3Drv17Stm32f0x1UsartCmpILNS_13BaseSerialBus6BusNumE1ELj1ENS_3Pin3PinILc66ELj7EEELNS3_8FunctionE0ENS4_ILc66ELj6EEELS6_0ENS4_ILc66ELj5EEEEC1Ev 13 14 auto result = usart.open(); \ ??task_0: (+1) \ 0x16 0x.... LDR R0,??DataTable2_6 \ 0x18 0x.... 0x.... BL _ZN3Drv17Stm32f0x1UsartCmpILNS_13BaseSerialBus6BusNumE1ELj1ENS_3Pin3PinILc66ELj7EEELNS3_8FunctionE0ENS4_ILc66ELj6EEELS6_0ENS4_ILc66ELj5EEEE4openEv \ 0x1C 0x0005 MOVS R5,R0 15 16 for (;;) { 17 wdgmngr.alive(); \ ??task_1: (+1) \ 0x1E 0x.... LDR R4,??DataTable2_7 Нет BLX'ов. Более того, компилятор зайнлайнил вызов этой функции (остальные не стал проверять). В том же листинге (фрагмент) \ In section .text, align 4 \ __softfp RetVal Drv::Stm32f0x1UsartCmp<>::open() \ _ZN3Drv17Stm32f0x1UsartCmpILNS_13BaseSerialBus6BusNumE1ELj1ENS_3Pin3PinILc66ELj7EEELNS3_8FunctionE0ENS4_ILc66ELj6EEELS6_0ENS4_ILc66ELj5EEEE4openEv: (+1) \ 0x0 0xB5FE PUSH {R1-R7,LR} \ 0x2 0x0004 MOVS R4,R0 \ 0x4 0x88A0 LDRH R0,[R4, #+4] \ 0x6 0x2800 CMP R0,#+0 \ 0x8 0xD101 BNE ??open_4 \ 0xA 0x88A0 LDRH R0,[R4, #+4] \ 0xC 0xE02A B ??open_5 \ ??open_4: (+1) Я не помню, чтобы на форуме жаловался на медленную работу ПО,. Оверхэд есть всегда. И он не только в количестве машинных инструкций выражается. А, например, в потере времени на форуме)))) Так в чём же дело? В неправильном инструменте? Или в неправильном его использовании? Вы наверняка видели нечитваемые исходники на Си или Си++ без ООП. Я, вот, видел. Даже сегодня у коллеги, все прелести: магические числа, константы и переменные названы в одном стиле, строки сравниваются не с помощью strcmp, а примерно так if( src[0] == dst[0] && src[1] == dst[1] и т.д. И я не придумываю. Именно так строки он и сравнивает. Конечно, этот код не идёт в наши приборы. Он делает тестовые стенды для производства, и приборов не касается. Тоже читаемость никакая? Я бы сделал абстрактный класс и оба этих наследовал от него. Ну если Вас не пугают VTABLE, которая может там появится. Если код описать в хидере, то с большой вероятностью он заинлайнится, как у меня в примере выше. Ах, это и есть ABC. Т.е. класс только с интерфейсом (pure virtual functions). Полегчало мне))) Ну вот смотрите, у меня все все все драйверы имеют этого родителя. Как я понял, это и есть ABC. И функция open() заинлайнилась. Да, инлайнится не 100%, но тут либо шашечки, либо ехать)) А если серьёзно, удобство окупается, ИМХО. Да и в листинг глянуть не проблема.