Arduino.ru

Вижу что использование этого метода уменьшает объём скетча. Значителен ли прирост в скорости работы?

Ну дык проверить самой не вариант? Всё злым дядькам на слово верить?

Почему bitRead, ведь вот так

В статье же написано:

Функции bitRead() и bitWrite() — именно тот случай, когда их низкоуровневая реализация не приведет к существенному увеличению производительности, так что в большинстве случаев проще использовать их именно в таком виде.

Опять же - проверьте сами, посмотрите из чего она состоит... Лучше будет, но ведь лучшее враг хорошего

Ардуину ускоряете, переносимость на другие МК - теряете. Выбор за Вами.

Irinka, открою страшную тайну - именно так лбращались к GPIO до появления проекта Ардуино. Новаторство Ардуино в том и заключается, что оно придумало вместо битовой математики более простые и понятные для юзеров функции, что существенно облегчило программирование МК для простых обывателей и привело к огромной популярности проекта во всем мире.
Конечно, за простоту и удобство приходится платить - в частности эффективностью кода и скоростью работы.

Так что никакого "тюнинга" тут нет. Скорее это возвращение к основам. По смыслу немного напоминает выкидывание из современной легковушки кондиционера, кожаных сидений и магнитолы - чтобы облегчить машину и улучшить время разгона до сотни :)

Что-то я туплю...

byte P2 = (1 << 2);// Пин 2
#define D2_INPUT      DDRD  &= ~P2 //INPUT
#define D2_READ     PIND & P2


Теперь, чтобы проверить что на входе порта делаю условие:

if (D2_READ){} и, соответственно, if (!D2_READ){}

или так?

if (D2_READ==1){} и, соответственно, if (D2_READ==0){}

PS Не ругайтесь)))

byte P2 = (1 << 2);// Пин 2
#define D2_INPUT      DDRD  &= ~P2 //INPUT
#define D2_READ     PIND & P2


Теперь, чтобы проверить что на входе порта делаю условие:

Чтобы не думать об operator precedence, следует в макросах активно использовать круглые скобки. Т.е.:

#define D2_INPUT      (DDRD  &= ~P2) //INPUT
#define D2_READ     (PIND & P2)

Что касается "так или так" - и так, и так можно.

Одно и то же

5416 байт. Использую вышеуказанные метод.

6056 байт. digitalRead()/digitalWrite()

Разница в 640 байт. Приятно

Посиживаю на форуме Схем.нет .... так там такие задроты сидят.... 
нельзя путью ничего спросить, посылают читать, изучать, обзывают.... 
ну вообщем они умные, все остальные глупые (ну очеь мягко говорю)..
А здесь все помогают, объясняют даже если элементарное спрашиваю и глупости всякие.

Большое Вам человеческое СПАСИБО.

byte P2 = (1 << 2);//2
#define D2_INPUT      (DDRD  &= ~P2) //INPUT

Если так:
#define D2_READ     (PIND & P2)
if (!D2_READ){} --- Работает


Если так:
#define D2_READ     bitRead(PORTD, 2)
if (!D2_READ){} --- Не работает

portd выходной порт. Так можно прочитать текущее значение выходного регистра.
pind входной порт. Всегда отдаёт то что на ноге. Даже если настроена нога как выход.

byte P2 = (1 << 2);//2
#define D2_INPUT      (DDRD  &= ~P2) //INPUT

Если так:
#define D2_READ     (PIND & P2)
if (!D2_READ){} --- Работает


Если так:
#define D2_READ     bitRead(PORTD, 2)
if (!D2_READ){} --- Не работает

Не смущает, что в двух примерах, в одном - PIND, в другом - PORTD ? Не испытываете когнитивного диссонанса?

ТООООЧНО)))))))))

Есть еще один момент:

в digitalRead() и digitalWrite() параметр может быть переменной, а в более быстрых макросах - только константой.

Это смотря как их написать.

Если по-простому, то переменную в них использовать просто нельзя. А если по уму - т.е. не полениться расписать вычисление нужной команды прямо в макросе, то переменные использовать можно сколько угодно. Там получится, если константа, то препроцессор сам всё развернёт всё вплоть до нужной команды, а если переменная, то сгенерит код для вычисления нужной команды. Получившийся код будет работать с переменной будет не так быстро, как с константой, конечно, хотя и побыстрее, чем digitalRead.

Мне нравятся такие реализации. Избавляютот ковыряния в битах. При использовании констант - всё в одну инструкцию. И при этом синтаксически одинаково - константа или переменная.

void setup() {

}

void loop() {


}

444 байт (1%) памяти устройства и 9 байт (0%) динамической памяти

#include <arduino.h>
int main() {
// "setup"


  for (;;) {
// "loop"
  }
  return 0;
}

134 байт (0%) памяти устройства и 0 байт (0%) динамической памяти

Так оптимальнее(грамотнее) будет?

Ну, если Вам ничего ардуиновского не нужно, типа millis, analogWrite и пр.

Поняла. Спасибо.

Ассемблер сильно поможет с размером кода, если осилите. Как пример ~1200 байт кода обеспечивают работу круиз-контроля у меня в авто. Это с опросом GPS, кнопок , выводом данных на дисплей, прерываниями ... ...

Особенно начинающие любят с АТ&Т синтаксисом. Ещё Форт, говорят, очень хорошую компактность даёт.

А ищщё ассемблер хорошо поглощает время, если его некуда деть ))

мне мое время значительно дороже :)

Жирные камни сейчас - пучок за условный доллар, и чем дальше - тем за условный доллар они будут жирнее. А вот часов в сутках - уже который миллион лет количество не меняется.

а как же ассемблерные вставки? ))

а так скоро будем мигать на малинке светодиодом )) технологии не стоят на месте )

почему глупость. в ардуино ассемблерная вставка и будет тюнинхом, если работа напрямую с портами уже считается дичью.

про ПЛИС вообще не понял и причем здесь каменный век )))

Кроме шуток - в целом, вы правы, что касается второго предложения. Потому как - рынок, технологии, глупо это не учитывать. Если стоимость условной единицы производительности/объёма/плюшек - неуклонно падает, а развитие производственных средств идёт в ногу со временем - то вариант, когда на малинке моргают светодиодом - уже не выглядит шуткой. Хотя бы просто потому, что так может быть проще, быстрее, технологичней - применительно к какой-то конкретной задаче, разумеется.

Вот скажите, что бы вы выбрали при условии, что стоимость отличается не более, чем на 10-15%: старый восьмибитный камень со скудной периферией, или - 32х-битку, где всякого фаршу - до жопы? Сразу оговорюсь - давайте не будем рассматривать специфичность к задаче, вот просто - на уровне хобби? Миграция на жирные камни, по сути - неизбежна, потому как сейчас те же средства разработки - позволяют без усилий влиться в эту струю. Хобби (а мы тут чисто хоббийщики, по сути) - становится вкуснее и удобнее, и др@читься, извиняюсь, за разницу в 50 рублей - ну такое себе.

Просто мысли вслух, без претензий.

Не парся. хороший секс для импотента всегда глупость. И ниче он не поймет, потому что  не встает. Умение написать круиз контроллер в 1200 байт для таких предмет вечной злобной зависти, вот и беснуется, правда с ПЛИС он тоже не могет. 

Про время. Разумеется на асме скорость разработки ниже. Вот только переход на "Жирные камни" не мгновенный какбы. И чем жирней тот камень - тем дольше его переферию изучать, а без этого переход на него и смысла не имеет. Мал того, камней этих наплодилось - шо у дурака фантиков. А в каждом глюков море, но пока не нырнеш - не узнаеш, т.к. доки хреновые, комюнити куцее спецов мало, я уже набодался както с онионом омега 2, самой компактной линукс платформой, могу поведать. Кроме того, у любого уважающего себя разраба найдется достаточно наработок, которые нужно тянуть за собой в новые жирные камни, а это тоже время, и не малое. Конечно у кого за душей ни строки может прыгать с камня на камень.