atom1477 napisał: Ale nie znaczy to że pod BACOMem się czegoś nie da zrobić.
Dlatego też w pewnym sensie w BASCOMie też się da napisać dobry kod.
Nie stwierdziłem, że się nie da

Widziałem kilkanaście lat temu w QBASIC'u dobre kody, i złe kody. Nie ważny jest język - ważny jest programista ;]
atom1477 napisał: I dlatego też nie powiedział bym że C będzie lepsze. Będzie równie dobre (jeżeli chodzi o panowanie nad prockiem). Bo nikt nie zmusza do korzystania z tych wysokopoziomowych funkcji BASCOMa, tak samo jak nie zmusza do stosowania SPLa na STMie.
Skoro tak, to tym bardziej obowiązuje powyższe stwierdzenie.
Serio, bascoma dotykałem ostatni raz jakieś 9 lat temu i odkąd zacząłem pisać w C, już chyba nie znajdę drogi powrotnej

Ale skoro sam bascom daje możliwość operacji na SFRach, to w gruncie rzeczy da się w nim napisać wszystko, i to tak, żeby kod był wydajny.
Dodano po 15 [minuty]:
tmf napisał: To, że kol. @jacynka84 ma tylko 440 kHz na SPI nie wynika ze złej konfiguracji tego interfejsu, lecz z tego, że zegar SPI jest generowany tylko w czasie transferu. Można to zinterpretować tak, że SPI jest taktowany np. 16 MHz, a skoro zegar efektywnie wynosi tylko 440 kHz to znaczy, że interfejs wysyła bajt danych, a następnie bardzo długo czeka na kolejny bajt.
Trochę podejrzane, patrząc na przytoczony kod. Kol.
jacynka84 nie wspomniał o jakichkolwiek przerwaniach, więc odrzucam możliwość długich ISRów zakłócających przepływ podanej pętli wysyłającej dane po SPI. Dziwne jest, że rdzen na obsługę pętli i zagnieżdzonej pętli czekającej na bit, marnuje
aż tyle czasu.
tmf napisał: Jeszcze jedna uwaga a propos DMA - jeśli po SPI tylko chcesz nadawać, to możesz zignorować odbierane bajty. Dlatego nie trzeba pod odbiór podpinać DMA, czyli jeden kanał wystarczy.
Plus dla designerów krzemu - w STM32 i większości LPC, SPI odmawia wysyłki gdy bufor odbioru jest zapełniony. Dopiero w LPC8xx da się ignorować odbiór...
tmf napisał: IMHO składnia jest logiczniejsza, niż jakieś bascomowe zaklęcia, popróbuj trochę C, szybko się przekonasz, że jest lepiej.
Popieram absolutnie. Chociaż, jak wspomniał
atom1477 i w bascomie można. Tylko zamiast uczyc się helpa do bascoma, trzeba nauczyć się manuala do procka. I rozmawiać bezpośrednio z prockiem, bez udziału złodziejskiego (pod względem wydajności) pośrednika...