RFM12B ATMega644P - Brak komunikacji po przepisaniu programu z Bascom na C

Witam!
Na początku przepraszam bardzo, jeśli popełnię jakieś błędy, ale siedzę nad problemem już od rana non-stop i pewnie nie widzę czegoś prostego, a stopień mojej frustracji osiąga już granice bezpieczeństwa.
Ale do rzeczy:
Mam następujący kod odbierania RFM12B napisany w Bascom (gotowiec z forum):


Współpracuje on idealnie z następującym kodem odbiornika:


Z chęci obsługi RFM'a w języku C wziąłem datasheet do ręki, przestudiowałem komendy, porównałem założenia teoretyczne z danymi wysyłanymi do układu w przykładzie i spłodziłem takie oto kody:

plik RFM12B_reg.h:


I niestety kod C po wgraniu do procesora nie działa...
Fusebity niezmieniane (taktowanie wewnętrzny RC 8Mhz), połączenia elektryczne tym bardziej (wszystko zmontowane na płytce PCB, syganły idą do RFM'a przez translator, z niego bezpośrednio do uC, ale na sofcie z BASCOM działa, więc to nie kwestia układu.)
W załączniku posyłam zrzuty przebiegów na liniach MOSI MISO SCK i SS (do otworzenia potrzebny jest darmowy program http://www.saleae.com/downloads
---
Jedyną znaczącą różnicą w przebiegach jaką zauwazyłem to zachowanie linii MISO:
1. W programie BASCOM linia ta pozostaje cały czas w stanie wysokim, poza momentem odczytu rejestru statusu (komenda &H0000).
2. W programie C linia ta przechodzi w stan niski w momencie, w którym stan niski przyjmuje linia CS, i "pika" stanem wysokim w momencie odczytu rejestru statusu (0x0000) (co ciekawe kod w Bascom pokazuje, że ustawione są bity: gotowość na zapis do bufora TX i POR, tymczasem C pokazuje tylko POR - jakby nie rozumiał dobrze wszystkich komend)
---
Bascom:

C:

---
Z góry bardzo dziękuję za wszelką pomoc, gdyż już po prostu nie wiem gdzie popełniam błąd, a próbowałem wielu kombinacji i nic nie pomaga...

Studiowałem tę stronkę, ale chcę to uruchomić na sprzętowym SPI, a nie kompilować kolejnego gotowca z internetu, komendy do układu RFM12 nadaję dokładnie takie same, więc przypuszczam że problem leży gdzieś w konfiguracji SPI...

Status SOLVED.
Dla potomnych wyjaśniam co było nie tak. Otóż wszystko wynikało z różnicy w "prędkości działania" niektórych funkcji - konkretnie w Bascom w funkcji:

Czas między zresetowaniem pinu CS a początkiem oczekiwania w pętli na stan wysoki na pinie MISO jest z powodu takiej a nie innej konstrukcji języka dłuższy niż czas zareagowania układu RFM12B i konwertera na wybór układu (stan niski na linii MISO sygnalizował w rzeczywistości zajętość układu, a nie problemy ze sprzętowym SPI jak przypuszczałem).
tymczasem w mojej pierwszej wersji kodu C tej funkcji:

z racji tego że pisałem w C i w sumie te fragmenty były pewnie tłumaczone na kilka pojedynczych instrukcji asm (nie chce mi się już tego analizować dokładnie) czas pierwszego sprawdzenia był krótszy niż czas reakcji układu i sprawdzenie stanu było dokonywane ZANIM układ RFM12B i konwerter zareagowały na nSEL i wystawiły na linię MISO informację o zajętości (czyli stan niski), co powodowało z kolei zbyt szybkie wysyłanie danych i nadpisywanie buforów modułu RFM12B
Na chwilę obecną kod wygląda tak:

I działa w 100% zgodnie z założeniami.
---
PS. Lista rejestrów z pierwszego posta zawiera pewne braki, bo przygotowywałem ją na podstawie DS układu RFM12 a nie RFM12B, ale każdy może łatwo porównać różnice i usunąć nadmiarowe funkcje oraz dopisać brakujące.
---
EDIT: W nowszej wersji BASCOM, która została zaktualizowana (2.0.7.6) i zoptymalizowana też przy tych kodach pojawił się problem taki sam jak w C - pomogło dodanie komendy Waitus 1 po ustawieniu stanu niskiego na CS