ATNEL tech-forum

Re: funkcja blokująca teoria

2015-07-10T14:58:11+01:00

Poszukaj w BB

Dla przypomnienia kolega @Jaglarz zrobił skorowidz do BB do pobrania w tym temacie
http://forum.atnel.pl/post51576.html?hilit=skorowidz#p51576

Statystyki: Napisane przez Zaba — 10 lip 2015, o 14:58

Re: funkcja blokująca teoria

2015-07-10T13:51:31+01:00

multitask napisał(a):

Mam pytanie
jeśli zarejestruję
register_uart_str_rx_event_callback ( analizuj_dane );
przestaje mi działać nadawanie z uarta w innym miejscu niż while(1)

Nadawanie nie ma NIC WSPÓLNEGO z callbackiem, który jest TYLKO do odbioru, więc pewnie gdzieś tam jakiegoś babola robisz z tym wysyłaniem

multitask napisał(a):

czy w obsłudzie przerwania to zrobić == dobry pomysł ?

raczej średnio koci pomysł - tzn teoretycznie można ale to bez sensu ... zainteresuj się teraz timerami programowymi, bo peklowanie czegoś do przerwania żeby się robiło co 5 sekund czyli co wieczność to po prostu koszmar

temat dla ciebie to: timery programowe

Statystyki: Napisane przez mirekk36 — 10 lip 2015, o 13:51

Re: funkcja blokująca teoria

2015-07-07T12:12:01+01:00

multitask napisał(a):

ew jak odbierać całe stringi ?

Kurczę - kolego - GREENBOOK - rozdział o UART masz to wyjaśnione krok po kroku i to na dodatek dużo więcej informacji

zaglądałeś do tego rozdziału ? Bo albo nie masz tej książki i wtedy niepotrzebnie umieściłeś ją w podpisie albo już nie wiem o co chodzi ....

Przeczytaj więc ten rozdział i daj znać wtedy czego nie rozumiesz ?

Statystyki: Napisane przez mirekk36 — 7 lip 2015, o 12:12

Re: funkcja blokująca teoria

2015-07-07T10:13:20+01:00

multitask napisał(a):

a tak serio powalczę dzis troszkę z C

No więc DOKŁADNIE - zamiast wprawiać się w poczucie winy, otwórz Bluebooka i przeczytaj rozdział o obsłudze UART za pomocą przerwań i o buforze cyklicznym.

Statystyki: Napisane przez mirekk36 — 7 lip 2015, o 10:13

Re: funkcja blokująca teoria

2015-07-07T09:25:00+01:00

multitask napisał(a):

Mirku ! czy byłbyś tak uprzejmy i podesłał mi jakieś przykłady do przeanalizowania?

Powiedz mi - bo takimi pytaniami wprowadzasz mnie w konsternację albo duże zakłopotanie - no masz w podpisie na forum informację, że posiadasz nie tylko Bluebooka ale nawet Greenbooka - a ty piszesz mi - żebym ja ci podesłał jakieś przykłady do przeanalizowania .... No to ja na to żegnam się teraz lewą nogą po plecach nie mogąc zrozumieć o co ci chodzi - skoro masz to w książce z Bluebooku (odbiór na przerwaniach i opis buforowania cyklicznego) ... w GB masz dalsze z tym przygody czyli odbieranie i parsowanie stringów .... o co więc tu i teraz tobie chodzi - możesz to sprecyzować ?

------------------------ [ Dodano po: 1 minucie ]

multitask napisał(a):

Są różne teorie dlatego warto je sprawdzać w kilku zródłach

Co do teorii i to takich o jakich tu piszesz - to rzeczywiście IDEALNĄ odpowiedzią na to jest post kolegi mokrowskiego !

Statystyki: Napisane przez mirekk36 — 7 lip 2015, o 09:25

Re: funkcja blokująca teoria

2015-07-07T08:44:03+01:00

Bufor cykliczny (ang. ring buffer), ja podglądam tak:[syntax=c]#define sw_on 1
//********************** Funkja glowna main()***********
int main (void){
//====== testowa inicjalizacja zmiennych oraz liczb DEC i HEX mających się wyświetlać na wyśw. LED
cy1=13;
cy2=1;
cy3=14;
cy4=13;

DDRC |= (1<DDRB |= (1<PORTB |= (1<

//init_ADC ();
d_led_init();
sei();

while(1){

// **************timer od CTC d_led.c***********
if(!Tim_led1 && sw_on){
//pomiar(5);
PORTB ^=(1<//Monitor_WLED(DEC,ADCW);//Monitor_WLED(BIN||OCT||DEC||HEX||ZNAK , ADCW);
Tim_led1 =100;// 100 -> 0,5sekundy (1i = 5ms 200Hz)
}
if(!Tim_led2){
PORTB ^= (1<Tim_led2 =500;
}
//******************************************

_delay_ms(100);

//_delay_ms(1000);

PORTC ^= (1<}
}
//******************Koniec funkji main()**********************************************[/syntax]
Co prawda _delay_ms(1000) zakrywa przerwanie - efekt widać na PB1

Statystyki: Napisane przez Wirnick — 7 lip 2015, o 08:44

Re: funkcja blokująca teoria

2015-07-06T20:29:44+01:00

multitask napisał(a):

(ponoc odbieranie nie działa po użyciu _delay)

A powiedz mi skąd bierzesz takie opowieści i bajania ?

Zamiast słuchać takich bajek - sam postaraj się przećwiczyć z Bluebooka bo widzę, że masz - jak działa buforowanie cykliczne i jak jest robiona transmisja UART na przerwaniach. To już później nigdy nie dasz sobie wmówić takich rzeczy

W skrócie - gdy trwa najdłuższy delay to transmisja na przerwaniach leci aż miło ....

Statystyki: Napisane przez mirekk36 — 6 lip 2015, o 20:29

Re: funkcja blokująca teoria

2015-07-03T16:44:21+01:00

Poniżej mały przykład jak np. delaye blokują działanie pętli głównej
[syntax=c]#include
#include
#include

#define LED1PD0
#define LED2PD1

#define LED1_TOGPORTD ^= (1<#define LED2_TOGPORTD ^= (1<
int main(void)
{
DDRD |= (1<
TCCR1B |= (1<TCCR1B |= (1<OCR1A = 3906;
TIMSK |= (1<
sei();
while(1)
{
LED2_TOG;
_delay_ms(2500);
LED2_TOG;
_delay_ms(5000);
//inne rzeczy wykonywane przez procesor np.
//obsługa klawiszy
}
}

ISR(TIMER1_COMPA_vect)
{
LED1_TOG;
}[/syntax]
Dioda LED2 w pętli głównej zmienia stan co 2,5s i co 5s. Inne procesy, np. sprawdzanie klawiszy, wykonują się co 7,5s. Na czas delayów pętla główna "stoi" bo procesor jest zajęty odliczaniem czasu poprzez te nieszczęsne delaye. Dlatego to właśnie jest sposób blokujący.

W tym czasie jedynie włączone przerwania będą działać. Potwierdza to dioda LED1, która ładnie sobie miga co kilkaset ms. Mimo, że pętla główna "stoi".

Do blokujących części programu należą także przydługawe wszelakie pętlę np. while, for. I znów mały przykład
[syntax=c]#include
#include
#include

#define LED1PD0
#define LED2PD1
#define LED3PD2

#define LED1_TOGPORTD ^= (1<#define LED2_TOGPORTD ^= (1<#define LED3_TOGPORTD ^= (1<
int main(void)
{
DDRD |= (1<
TCCR1B |= (1<TCCR1B |= (1<OCR1A = 3906;
TIMSK |= (1<
uint8_t i = 0;

sei();
while(1)
{
for(i=0; i<50; i++)
{
LED2_TOG;
_delay_ms(100);
}

LED3_TOG;

//inne rzeczy wykonywane przez procesor np.
//obsługa klawiszy
}
}

ISR(TIMER1_COMPA_vect)
{
LED1_TOG;
}[/syntax]
Dioda LED1 w przerwaniu miga sobie niezmiennie.
Dioda LED2 miga co ok. 100ms, ale dioda LED3 zmienia stan co kilka sekund. Program w pętli for ładnie miga diodą ale to co jest poza pętlą for czyli miganie LED3 i sprawdzanie klawiszy "stoi" na czas wykonywania się tej pętli for. Czyli z punktu widzenie programu pętla for na czas swoich obiegów blokuje działanie reszty pętli głównej.

Z tego wynika, że blokujące części programu to nie tylko delaye.

Statystyki: Napisane przez jacekk232 — 3 lip 2015, o 16:44

Re: funkcja blokująca teoria

2015-07-03T09:50:56+01:00

musiałeś natrafić na to w BB widać zapomniałeś że o tym czytałeś

delay_ms czy też delay_us po prostu blokuje pracę procesora w taki sposób że żadna inna funkcja nie zostanie wykonana w momencie gdy obieg pętli trafi na delay zablokuje pracę procesora jak i jego timerów na zadany czas.

Zakładając że masz program gdzie dioda ma mrugać co 0,5 sek i obsługujesz te mruganie timerem to w momencie gdy program trafi na delay wydłuży czas mrugnięcia diody z powodu iż cała praca procesora zostanie zatrzymana.

Jak będziesz chciał kliknąć klawisz to zadziała on tylko wtedy gdy obieg pętli nie jest w delayu bo wtedy praca procka jest zablokowana i przycisk nie zadziała, zadziała dopiero jak pętla ruszy dalej.

Mam nadzieję że nie zamieszałem za mocno i udało mi się to łopatologicznie wytłumaczyć.

Statystyki: Napisane przez majster — 3 lip 2015, o 09:50

Re: funkcja blokująca teoria

2015-07-03T09:50:06+01:00

W skrócie _delay_ms(); czy _delay_us(); zatrzymują pracę programu na określony czas. Procesor nie może wykonywać w tym czasie innych zadań.
Raczej używa się terminu "funkcja nieblokująca" czyli taka, która nie używa delay'ów tylko przerwań, zdarzeń czy timerów programowych.
Poczytaj w BB o timerach sprzętowych szczególnie "Tryb CTC - jeden z najważniejszych", oraz rozdział "Wstęp do systemów czasu rzeczywistego".

Statystyki: Napisane przez anshar — 3 lip 2015, o 09:50