захожу в магазин, вижу Windows на ноутбуке — выхожу из магазина…
Если Вы учитесь — производители предлагают бесплатно попользоваться, если Вы зарабатыаете деньги, почему другие не должны это делать.
Если Вы обучаете студентов — обратитесь к разработчикам, возможно, есть лицензия для ВУЗов.
А то что бесплатно — придется вручную прикручивать. Тут ничего не поделать.
Напишите как нужно. Будем учиться по Вашим статьям. Только не отсылайте читать других авторов, ведь интересен Ваш подход и консультироваться с Вами.
начинают делать также, а потом их приходится бить по рукам.
Не повезло Вашим подчиненными, если таковые имеются.
программиста можно выгонять с собеседования, так как это явно не эмбеддер, язык С он точно не знает, как следствие и С++ тоже.
да, хорошо чувствовать превосходство. Только когда появляется на собеседовании человек, который покажет, что Вы плохо знаете, то его тоже отсеете?
Эти записи такие разные, явно стоит вендорлока, ещё и свой аналог для описания регистров нагородим. Вы же его автоматически генерируете? И тесты у вас есть?
Вы о чем?
и да, CMSIS тестируют на пользователях, не просто так вссплывают опечатки и баги.
2) IAR — компилятор для профессионалов(нет). Только в заголовке будет запись типа:
#error This file should only be compiled by ARM IAR compiler and assembler
IAR платный, а вы не оставляете мне возможности собрать проект другим компилятором. Может быть мне его купить за 2-3к$? А у вас он куплен?
Под линукс он не поставляется, наверное, придется ещё и винду покупать. Ну да ладно: «Я привык работать в IAR. Да, есть другие IDE, но мне хватает возможности IAR».
где Вы в коде нашли не совместимость с другими компиляторами? я порекомендовал IAR, т.к. мне он показался удобней. но это не означает, что все поголовно должны перейти на него.
у меня iar не куплен, лицензия (как написано в тексте) ограничение кода. для дома и семьи хватает.
За лицензию платит заказчик, когда я отдаю исходники. И вообще, почему хороший инструмент должен быть бесплатным?
3) Как правило, начинающие разработчики изучают С++ со стороны ООП и это вполне себе оправданно, но это не серебряная пуля. C++ — мультипарадигмальный язык программирования, наиболее мощными возможностями которого являются метапрограммирование и программирование в пространстве типов, позволяющие сгенерировать оптимальный код, который так важен в эмбеддед.
так и расскажите об этом новичкам!
Все расчеты в коде, который вы привели, можно выполнить на этапе компиляции, сведя все к записям в регистры GPIO, у вас это все считается в рантайме.
можно. каждый выбирает свой путь
А если у вас по ТЗ время перехода МК в некое состояние 1мс, при этом настроить нужно 200 ног?
не попадалось. не уверен, что на все случаи жизни можно сделать что-то универсальное.
А че там обрадаьывать-то? Если у нас есть DMA, то работа с уартом не сильно отличается от работы с массивом в памяти. Ну а сконфигурировать его макросами не составляет большого труда.
В теории да. У меня как раз проблема при использовании DMA — как организовать циклический буфер? Как раз в библиотеке ModBus хочется прикрутить DMA.
Делать же набор функций чтобы дергать ножкой это правда жир, кушающий и такты и стек.
но и контроллеры стали жирнее.
Можно, конечно, надеяться, что компилятор соптимизирует.
Это я привел пример только для пинов. Без прерываний. Боюсь спросить как будет тотже уарт выглядеть на дефайнах. Особенно инетересен обработчик.
Макросы тоже не плохи, раньше пользовался подобным. Но вот предложил другой подход.
то все можно заменить на одну строчку без накладных.
да можно заменить, но скорость работы от этого не вырастет. про наглядность — у каждого свой вкус)
Здесь доступ и поход в таблицу виртуальных методов отнимает кучу времени.
а Вы замеряли сколько тактов теряется? при максимальной оптимизации я не заметил особой разницы.
Ну и так по мелочам, вместо указателей можно ссылки передавать, будет уверенность, что все проинициализировано.
здесь абсолютно согласен, это старая дурацкая привычка) буду исправляться и по тихоньку иссправлять
Еще возможный недочет в том, что при передаче портов легко спутать их последовательность (так как тип один и тот же), и если этот метод будет вызваться несколько раз то вероятность спутывания увеличивается каждый раз. Поэтому и ссылки желательно убрать тоже либо в список
это был как пример. конечно, лучше списком или структурой или подобным.
Да еще добавлю. Так делать не совсем хорошо:
virtual void Reverse() { Set(!Get());}
Принцип Лисков нарушается, потом можно очень удивить кого-то, кто будет использовать этот класс и переопределять этот метод. Когда один пин будет вести по одному, а другой вдруг станет вести по другому. Лучше его сделать либо чисто виртуальным, либо не виртуальным вообще.
Разве тройная буферизация всегда исключает необходимость проверки вертикального бланка? Если у вас ЦПУ отрисовывает кадр всегда быстрее, чем контроллер дисплея грузит кадр в экран, то тройная буферизация теряет смысл перед двойной буферизацией. Ну и, собственно, когда контроллер дисплея всегда быстрее грузит кадр нежели система его отрисовывает та же история. При этом, я понимаю как это может помочь «в среднем». Вы же читали обсуждения про тройную буферизацию выше (случаи когда кто-то из ЦПУ или LTDC быстрей)? Было бы интересно вас выслушать.
1. один буфер используется, когда поцессор успевает отрисовать кадр во время бланка (вертикального) или перерисовывается малая часть кадра, не заметная для глаза
2. два буфера используется, когда процессор не успевает отрисовать кадр во время бланка. при этом отрисовка нового кадра начинается, когда освободился буфер. т.е. программа (поток) отрисовки должна ожидать.
3. тройная буферизация используется когда идет непрерывный поток формирования кадров (например, камера или Ваш случай, где пытаетесь достичь много fps)
да, я читал выше про тройную буферизацию. там за бланками следить не надо, только контролеру видео сообщить, с какого адреса начинать следующий кадр.
почитайте как делается тройная буферизация, там не сложно. главное, не запутаться какой буфер на вывод, какой в очереди, а какой свободный.
Можете пояснить? Казалось бы, ни один их этих способов не должен зависеть от соотношения скоростей формирования кадра/отображения кадра. При любом соотношении, оба способа должны давать адекватную картинку (без дрожания), ведь переключение буферов в обоих методах происходит исключительно внутри VBLANK.
я код не видел, из контекста понял, что Вы формируете кадры не синхронно с выводом и переключением буферов (см. выше п.2)
У нас в этом примере только графическое приложение исполнялось. Помимо этого разве что системный таймер. Поэтому полученные 85 FPS это когда система только графикой и занимается. Если экран 60 Гц, то можно прикинуть какая часть свободного времени остается.
Обсудив ситуацию, мы решили отложить унификацию до более глубокой проработки графического стека.
Попробуйте сделать тройной буфер, как рекомендовали выше. Это классика. Тогда не будет проблем с маленькими или большими разрешениями. И не надо ловить «обратный ход луча» или как принято сейчас называть — «вертикальный бланк».
Ваш первый способ (с переключением слоев) работает только, когда скорость формирования кадра выше скорости вывода, второй (переключение буферов) — наоборот.
Возможно, это мое мнение, но fps замерять не очень корректно, более правдиво — время, затраченное на формирование кадра. Тогда можно оценить свободное процессорное время для других задач.
Может, надо сначала внимательно почитать документацию и теорию, а потом экспериментировать? Что Вы в итоге измеряли: пропускную способность памяти? Скорость DMA?
захожу в магазин, вижу Windows на ноутбуке — выхожу из магазина…
Если Вы учитесь — производители предлагают бесплатно попользоваться, если Вы зарабатыаете деньги, почему другие не должны это делать.
Если Вы обучаете студентов — обратитесь к разработчикам, возможно, есть лицензия для ВУЗов.
А то что бесплатно — придется вручную прикручивать. Тут ничего не поделать.
Напишите как нужно. Будем учиться по Вашим статьям. Только не отсылайте читать других авторов, ведь интересен Ваш подход и консультироваться с Вами.
Не повезло Вашим подчиненными, если таковые имеются.
да, хорошо чувствовать превосходство. Только когда появляется на собеседовании человек, который покажет, что Вы плохо знаете, то его тоже отсеете?
Вы о чем?
и да, CMSIS тестируют на пользователях, не просто так вссплывают опечатки и баги.
где Вы в коде нашли не совместимость с другими компиляторами? я порекомендовал IAR, т.к. мне он показался удобней. но это не означает, что все поголовно должны перейти на него.
у меня iar не куплен, лицензия (как написано в тексте) ограничение кода. для дома и семьи хватает.
За лицензию платит заказчик, когда я отдаю исходники. И вообще, почему хороший инструмент должен быть бесплатным?
так и расскажите об этом новичкам!
можно. каждый выбирает свой путь
не попадалось. не уверен, что на все случаи жизни можно сделать что-то универсальное.
посмотрел Ваш стиль написания. Красиво. Молодец.
вот только зачем в области пользователя доступ к регистрам?
или если отвечать Вашим стилем: за это надо мордой об экран
можно даже пользоваться, ничего криминального в коде нет
буду стараться
а кто будет учить работников? ждать Вас? мне нужны специалисты сейчас.
А вот от Вас ждем интересный статей. Я серьезно, поделитесь опытом.
В теории да. У меня как раз проблема при использовании DMA — как организовать циклический буфер? Как раз в библиотеке ModBus хочется прикрутить DMA.
но и контроллеры стали жирнее.
так ведь для этого и существуют компиляторы.
Макросы тоже не плохи, раньше пользовался подобным. Но вот предложил другой подход.
да можно заменить, но скорость работы от этого не вырастет. про наглядность — у каждого свой вкус)
а Вы замеряли сколько тактов теряется? при максимальной оптимизации я не заметил особой разницы.
здесь абсолютно согласен, это старая дурацкая привычка) буду исправляться и по тихоньку иссправлять
это был как пример. конечно, лучше списком или структурой или подобным.
хорошее замечание.
спасибо.
Есть классы для uart, spi, can. К примеру, для urat сделан modbus rtu, wake.
Одно дело пользоваться этими структурами в пользовательский части кода, другое дело, когда они спрятаны внутри классов.
нет. это упрощение синхронизации.
да, не относится к оптимизации, а относится к невнимательности или непониманию принципов формирования кадров.
1. один буфер используется, когда поцессор успевает отрисовать кадр во время бланка (вертикального) или перерисовывается малая часть кадра, не заметная для глаза
2. два буфера используется, когда процессор не успевает отрисовать кадр во время бланка. при этом отрисовка нового кадра начинается, когда освободился буфер. т.е. программа (поток) отрисовки должна ожидать.
3. тройная буферизация используется когда идет непрерывный поток формирования кадров (например, камера или Ваш случай, где пытаетесь достичь много fps)
да, я читал выше про тройную буферизацию. там за бланками следить не надо, только контролеру видео сообщить, с какого адреса начинать следующий кадр.
почитайте как делается тройная буферизация, там не сложно. главное, не запутаться какой буфер на вывод, какой в очереди, а какой свободный.
я код не видел, из контекста понял, что Вы формируете кадры не синхронно с выводом и переключением буферов (см. выше п.2)
ну, тут у каждого свое мнение.
Попробуйте сделать тройной буфер, как рекомендовали выше. Это классика. Тогда не будет проблем с маленькими или большими разрешениями. И не надо ловить «обратный ход луча» или как принято сейчас называть — «вертикальный бланк».
Ваш первый способ (с переключением слоев) работает только, когда скорость формирования кадра выше скорости вывода, второй (переключение буферов) — наоборот.
Возможно, это мое мнение, но fps замерять не очень корректно, более правдиво — время, затраченное на формирование кадра. Тогда можно оценить свободное процессорное время для других задач.
Может, надо сначала внимательно почитать документацию и теорию, а потом экспериментировать? Что Вы в итоге измеряли: пропускную способность памяти? Скорость DMA?