Обработка нажатия кнопки в AVR...

Мастер Ломастер

BerZerK-ku писал(а):

Не знаю что там можно понять не так. Вы говорили о каком-то преобразовании типов, которое всему мешает, а ошибка крылась в другом месте :dont_know:

повторяю в очередной раз для вас: я привел 2 варианта функции, которые проверялись в коде PORTB = get_key_pressed(); - один вариант не изменял состояния порта ни при каких нажатых кнопках, второй - изменял, как надо. в этом случае проблема кроется в преобразовании типов. это вы поняли, надеюсь?

Реклама

BerZerK-ku

Отвечаю честно, без под..ок и сарказма, не понимаю я о чем вы пишете. Можете подробней написать о чем речь? где кто в кого преобразовывался?

:)))

Дошло. Вы видимо считаете, что вот это ~(PORTB & ANY_KEY), будет приведено к int? В IAR вы можете забыть об этом.

Реклама

Мастер Ломастер

BerZerK-ku писал(а):

Отвечаю честно, без под..ок и сарказма, не понимаю я о чем вы пишете. Можете подробней написать о чем речь? где кто в кого преобразовывался?

ладно, еще раз:
0. я написал функцию

Код:

unsigned char get_key_pressed(void){
unsigned char key;
unsigned char key2;
   key = ~(PIND & ANY_KEY);
   delay(15);
   if(key == ~(PIND & ANY_KEY)) 
      return key;
     else
      return NO_KEY;
}

1. я дал начинающему рекомендацию проверить мою функцию при помощи кода while(1) PORTB = get_key_pressed(); и он сказал - НЕ РАБОТАЕТ.
2. я стал выяснять - в чем проблема? и выяснил, что моя функция в этом коде не работает на самом деле.
3. однако, если ее модифицировать чуть-чуть, то она начинает работать. модификация внешне пустяковая:

Код:

unsigned char get_key_pressed(void){
unsigned char key;
unsigned char key2;
   key = ~(PIND & ANY_KEY);
   delay(15);
   key2 = ~(PIND & ANY_KEY);
   if(key == key2) 
      return key;
     else
      return NO_KEY;
}

4. я пришел к выводу, что виновато тут преобразование типов операндов.
5. далее, я изменил функцию по-другому, доведя ее до полностью правильноработающего во всех применениях варианта и снова дал ее товарищу с комментариями.

теперь вам понятно? вы согласны, что неработоспособность двух вариантов этой функции связана с преобразованием типов?

BerZerK-ku

Ответ выше :)))

Мастер Ломастер

BerZerK-ku писал(а):

Дошло. Вы видимо считаете, что вот это ~(PORTB & ANY_KEY), будет приведено к int? В IAR вы можете забыть об этом.

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

а что IAR так себя ведет - просто ужас! несоответствие стандарту полнейшее! я был об IAR-e лучшего мнения (заочно, правда).

Реклама

BerZerK-ku

тяжело найти ошибку там, где ее не будет
Советую прогнать этот код через WinAVR, вы будете неприятно удивлены :)))

Реклама

Распродажа паяльного оборудования ATTEN!
Паяльные станции, паяльники и аксессуары по самой выгодной цене.

По промокоду radiokot скидка 10%

Мастер Ломастер

BerZerK-ku писал(а):

:))) тяжело найти ошибку там, где ее не будет

ошибка есть, по-моему. а то, что в IAR-е вы ее не почувствуете, это говорит о вашем мастерстве. спасибо IAR-у, плюющему на требования стандарта

BerZerK-ku

Эх-х-х, опять не успел дописать :)))

И зря дописывал. Не то проверил. WinAVR все-таки придерживается стандарта )

Мастер Ломастер

а при чем тут WinAVR? этот компилятор вроде как заявляет полную поддержку стандарта С99, во всяком случае в той части, что укладывается в архитектуру 8-ибтных AVR

может быть, вы скажете тогда, что будет выведено этим кодом в PORTB?

Код:

unsigned char v1 = 1;
unsigned char v2 = 255;
unsigned char v3 = 2;

if(v1 == (v2 + v3))
   PORTB = 1;
else
   PORTB = 2;

что будет в порту: 1 или 2?

Реклама

BerZerK-ku

2. Свою ошибку уже признал )

Мастер Ломастер

BerZerK-ku писал(а):

Эх-х-х, опять не успел дописать :)))

И зря дописывал. Не то проверил. WinAVR все-таки придерживается стандарта )

как же так?! гуру Си, и вдруг купился на поведение компилятора?! ведь и так понятно, как ДОЛЖЕН себя вести компилятор - Керниган с Ричи об этом писали в свое время :)))

BerZerK-ku

Ну я исходил не из стандартов, а из производительности. Думал что это для МК важнее :)))

Мое мнение с создателями этого продукта разошлись. Может потому я и выбрал IAR, а может это он зомбирует меня :)))

Мастер Ломастер

то есть пускай программа работает неправильно, лишь бы быстро? надо будет взять себе на вооружение этот подход - у гуров надо учиться :)))

BerZerK-ku

Почему не правильно? Написано не по стандартам, а вот дело свое делает, причем без нареканий.

Мастер Ломастер

BerZerK-ku писал(а):

:))) Почему не правильно? Написано не по стандартам, а вот дело свое делает, причем без нареканий.

т.е. моя неправильная функция у вас делала бы свое дело, так? а потом вам поручили бы Фобос-Грунт-2 программировать, и вуаля! летит наш фобос на дно океана :)))

как же вы можете разбираться в правильности ЧУЖОГО кода, если сами пишите тяп-ляп?! то UL вам не надо приписывать к константам больше 65535, то при байтовых вычислениях вам начхать на typecast...

все, из звания гуру вы разжалованы в быдлокодеры.

phanis

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

Код:

while(1)
{

resp=255;
  while((! (PIN_BUTTON & (1<<KNOPKA))))
  {
    if (resp) 
    {
      
      resp--;
      if(!resp) {
      мои действия();
      delay_ms(100);
      
      }
    }   
    
   
  }

}

BerZerK-ku

А я и не брал это звание, это ваша инициатива :dont_know:

Вообще , если вспомните начало, речь шла именно о IAR. И вы приводили функцию для использования в нем. Даже не задумывался над тем, что в используемом вами WinAVR это будет ошибкой. А вот если бы я со своими замечаниями залез в раздел WinAVR, то ситуация кардинально отличалась бы :)))

Если вы работаете на часовом кварце, то потянет. Если тактовая мегагерцы, то лучше так не делать. Как упоминалось где-то в начале темы, время дребезга достигает десятков мс. Вот это вам и надо отследить.
Хотя не, ошибаюсь, задержка в 100мс в обработчике сделает свое дело. Ложных срабатываний быть не должно )

Мастер Ломастер

BerZerK-ku писал(а):

А я и не брал это звание, это ваша инициатива :dont_know:

Вообще , если вспомните начало, речь шла именно о IAR. И вы приводили функцию для использования в нем. Даже не задумывался над тем, что в используемом вами WinAVR это будет ошибкой. А вот если бы я со своими замечаниями залез в раздел WinAVR, то ситуация кардинально отличалась бы :)))

не заню, о чем вы ведете свои речи, а я всегда веду речь о ЯЗЫКЕ СИ. а это - стандартизированная вещь, изначально задуманная для облегчения написания ПЕРЕНОСИМЫХ программ. если вы знаток НЕСТАНДАРТНОГО ДИАЛЕКТА IAR-Cи - это еще можно понять, хотя нельзя поставить вам в заслугу. и то, что пишите вы полагаясь на IAR - вдвойне плохо. завтра IAR решит следовать стандарту - и что? вам придется менять ориентацию? и переписывать весь быдлокод, оставшийся с прошлого времени? или как?

мало этого, вы еще с упорством канадского легионера настаиваете на том, что и другие могут отступать от стандарта, лишь потому, что "это прокатывает в IAR". в CVAVR прокатывает PORTB.2 - а ну-ка, применяйте это в своих программах, работает же! а ведь для доступа к биту есть вещь, которая "прокатывает" абсолютно везде и всегда (битовые операции с масками), потому что в соответствии со стандартом делается - вот это и есть ПРАВИЛЬНЫЙ ПОДХОД. и только такому подходу МОЖНО УЧИТЬ ДРУГИХ. или даже СОВЕТОВАТЬ другим.

в общем, вы разжалованы и аппеляции не принимаются, пока не исправитесь :)))

BerZerK-ku

извините, а у вас есть хоть одна абсолютно переносимая программа? естественно речь не идет о int main(void) { return 0;}
Переносимость никогда не волновала и думаю волновать не будет.

А зачем что-то переписывать? Это я вас вообще не понимай. Что работает, то и будет работать. Мне не важно какой продукт фирма собирается выпустить в будущем.

И заметьте, ни одного примера или совета я не употреблял со словами "так надо делать". Примеры приводятся под конкретную задачу, советы озвучиваются как вариант решения. Утверждать что так надо не могу, не мое :)))

Мастер Ломастер

одно дело, когда вместо delay(10) при переносе надо написать _delay_ms(10), а другое - когда результат выражений АБСОЛЮТНО НЕВЕРНЫЙ получается. функции простым поиском и заменой корректируются - и программа перенесена. а выражения - это многие часы отладки, поиска ошибок и прочего тупизма. а ведь этого можно избежать, если не допускать отступлений от стандарта. может, у вас в программах и "магические числа" повсюду? а чо, работает же...

если ваша программа будет содержать #define DDD 12300000, то если вдруг IAR решит соблюдать стандарты в новой версии, ваш код перестанет работать после компиляции и хорошо еще, если ворнинг появится - а то ведь может и не появиться...

вы что, на самом деле этого не понимаете? или решили меня измором взять?

Обработка нажатия кнопки в AVR...

Кто сейчас на форуме