Ciekawa teza aczkolwiek ostatecznie uważam, że nie masz racji. Masz jakieś doświadczenia z tym związane ? Jakaś opis który by to potwierdził ? (Jak coś to nie jestem złośliwy tylko ciekawy, chętnie się czegoś nowego dowiem )

Nie jest to dobry pomysł. Niektóre operacje ne peryferiach nie będą działać, bo pomiędzy zapisami będzie pauza większa niż 4 cykle zegara. Nie da się wiec zapisać EEPROM, ustawiać watchdoga, itp.

No i tak to bywa - debuger nie załatwi sam pewnych spraw za programistę ... Tak poczytałem ten wątek ... i aż troszkę strach bierze gdy kolega autor wątku pisze np takie coś:



Po prostu tragedia - proponuję jednak wrócić do podstaw i zastanowić się co to jest C-String, czyli string w C ... bo to nigdy w życiu nie jest stringiem, i jeśli korzystanie z funkcji strncmp_P() lub podobnych powoduje wykładanie się procka do góry nogami i jak kolega pisze powrót do main() ;) albo losowe działanie IF'ów to - .... to panie kochany .... [...[

Nie mniej polecam debugować programy bez optymalizacji

program dalej zachowuje się dziwnie, czego nie jestem w stanie zrozumieć.

char str_95 PROGMEM = '_'; // to zajmie JEDEN koci bajt !!!

Jest możliwość, żebyś sprawdził co znajduje się w zmiennej buf ? za pomocą debuggera oczywiście.

Faktycznie miałem włączoną optymalizację.
Dla sprawdzenia i upewnienia się:

char znak[1]; // tablica 1 "miejscowa"
znak[0] = 'a' // "miejsce" zerowe w tablicy

'a' -> to po prostu a
"a" -> to a + \0
string[] "a" - > a+\0

Zgadza się?

Cześć,

odniosę się, przynajmniej na razie, do tego zdania:
"W przypadku gdy wyślę np. 95 - program przeskakuje po ifach, jakby losowo (pewnie nie losowo, ale ja nie mogę zauważyć prawidłowości)."

Co to znaczy losowo ? Korzystasz z debuggera rozumiem ? Używasz tego na stmie ? nie masz przypadkiem włączonej optymalizacji przy kompilacji ?

PS. Jeśli faktycznie porównanie miałoby być z pojedynczym znakiem o kodzie 95, to wtedy dla tego kodu string nie powinien być "95" tylko odpowiedni znak ASCII, ale zokończony terminującym zerem, czyli w "ciapkach"
[syntax=c]char str_95[] PROGMEM = "_";[/syntax]

lub trzeba by użyć funkcji strncmp_P z podaną długością 1
[syntax=c]char str_95 PROGMEM = '_';
strncmp_P(buf, str_95, 1);[/syntax]

[...]
Problemem jest natomiast (tak mi się wydaje) nie zrozumienie przeze mnie funkcji parse_nrf_data.
Nie za bardzo wiem jak dużo mogę kodu zawierającego tą bibliotekę udostępniać, dlatego dam tylko wycinki.

W miejscu przykładu wstawiłem: (odbiornik)

[syntax=c]void parse_nrf_data ( char * buf, uint8_t len )
{
if (!strcmp_P( buf , 95))
{
target=3*metr;
mknrf_flush_rx();
}

if (!strcmp_P( buf , 96))
{
target=0*metr;
mknrf_flush_rx();
}

if (!strcmp_P( buf , 97))
{
target=3*metr;
mknrf_flush_rx();
}

if (!strcmp_P( buf , 98))
{
target=5*metr;
mknrf_flush_rx();
}

}[/syntax]
[...]
W/g dokoumentacji "The strcmp_P() function is similar to strcmp() except that s2 is pointer to a string in program space."

Jeśli dobrze rozumiem - następujący zapis
[syntax=c]!strcmp_P( buf , 98)[/syntax]
prawdopodobnie porównuje bufor 'buf' z przypadkową zawartością pamięci programu

Czy liczba 98 nie powinna być przypadkiem w "ciapkach"? (tzn. w cudzysłowach).
Najlepiej chyba jakby te stringi były zdeklarowane gdzieś jako progmem.

czyli coś w tym stylu

[syntax=c]char str_95[] PROGMEM = "95";[/syntax]
a w ifach
[syntax=c]!strcmp_P( buf , str_95)[/syntax]

i tak dalej. Na początek można też spróbować ze zwykłym strcmp np.
[syntax=c]!strcmp( buf , "95")[/syntax]
co do kodu nadajnika - to niestety nie mam doświadczenia :-)