Robert_1967 napisał(a):
Co do funkcji lcd_char_P, czy lcd_str_P() , to myślę, że lepiej je rozgraniczyć (P)
Wcześniej podałem rozwiązanie z użyciem uniwersalnej funkcji akceptującej zarówno dane we FLASH jak i w RAM. Jeżeli jednak ktoś woli używać osobnych funkcji, nic nie stoi na przeszkodzie. Wystarczy (nawiązując do wcześniejszego przykładu) zastąpić kwalifikator __memx na __flash:[syntax=c]// deklaracja
void lcd_str_P( const __flash char* s );
// definicja
void lcd_str_P( const __flash char* s )
{
while(*s)
{ lcd_char( *s++ ); }
}[/syntax] i już mamy osobną funkcję z przyrostkiem _P, która akceptuje tylko wskaźniki do pamięci FLASH. Nadal jednak wewnątrz funkcji można uniknąć konieczności używania wiadomych makr do odczytu danych stosując normalny zapis, jak w przypadku danych w RAM.
Ważne jest to, że jeśli zdefiniujemy dane we FLASH za pomocą kwalifikatora __flash, nadal musimy używać odpowiednich funkcji z przyrostkiem _P z bibliotek standardowych (takich jak np. memcpy_P() czy też strcmp_P() ), tak jak to robimy w przypadku użycia PROGMEM. To, że autorzy bibliotek standardowych nie użyli funkcji uniwersalnych, tak jak to pokazałem wcześniej, wynika z faktu, że funkcje biblioteczne są zawsze bardzo dokładnie optymalizowane m.in. pod kątem szybkości wykonania. Funkcja uniwersalna używa wskaźników 24-bitowych i potrzebuje kilku dodatkowych taktów do rozróżnienia umiejscowienia danych, przez co jest minimalnie wolniejsza. W wielu przypadkach jednak, takich jak np. opisywane tutaj wyświetlanie danych na LCD lub przykładowo transmisja UART, to spowolnienie jest praktycznie bez znaczenia, więc bez obaw o szybkość kodu można takich funkcji jak najbardziej używać. No i oczywiście to, że funkcja ma przyrostek _P nie musi wcale oznaczać, że była napisana z użyciem makr pgm_read_xxx(), jak pokazałem nieco wyżej
rskup napisał(a):
W końcu trzeba pójść do przodu i poprzerabiać swoje biblioteki na __flash-owe i zacząć już tylko tak używać
Przerabianie bibliotek wcale nie jest konieczne.
Powiedzmy, że mamy gotowy moduł do obsługi UARTa z funkcją zawierającą w nazwie przyrostek _P, np. uart_send_str_P(), przeznaczoną do transmisji danych odczytywanych z pamięci FLASH napisaną z użyciem makr z rodziny pgm_read_xxx(). Możemy normalnie dołączyć ten moduł do naszego projektu bez dokonywania w nim zmian.
Jeżeli teraz w pliku main.c zdefiniujemy sobie ciąg znaków we FLASH:[syntax=c]const __flash char mystring[] = "Hello World!";[/syntax]to możemy przekazać go do naszej "starej" funkcji:[syntax=c]uart_send_str_P( mystring );[/syntax]i będzie ona działać prawidłowo, tak samo jakbyśmy zdefiniowali mystring przy użyciu PROGMEM.
Oczywiście dobrze jest zachować pewną systematykę i stosować albo jeden sposób, albo drugi, ale nie musimy przerabiać tych funkcji od razu wszystkich.
Daro69 napisał(a):
Możliwe że niebawem, po przeanalizowaniu informacji z Twojej stronki - sporo tego,
przestawię się na sposób z kwalifikatorem __flash .
Myślę, że warto się przekwalifikować
Co do ilości materiałów, moim zdaniem nie trzeba się zrażać. Starałem się przedstawić sprawę jak najbardziej kompleksowo, pokazać jak najwięcej aspektów sprawy. W rzeczywistości nie jest to jakoś szczególnie skomplikowane, to tylko tak wygląda na pierwszy rzut oka
Na początek można pominąć rozdziały o danych w obszarach pamięci powyżej 64KiB lub w zdefiniowanych sekcjach, bo to jest raczej rzadko potrzebne, tym bardziej jeśli do tej pory nie musiałeś korzystać z makr pgm_get_far_address(), pgm_read_word_far() itp.W razie czego można pytać. Postaram się odpowiedzieć na wszelkie wątpliwości (w miarę wolnego czasu oczywiście
).Statystyki: Napisane przez andrews — 16 maja 2018, o 17:41
]]>
