W dniu 2023-02-01 o 22:33, Janusz pisze:
> W dniu 2023-02-01 o 22:05, Robert Wańkowski pisze:
>> W dniu 2023-02-01 o 17:56, J.F pisze:
>>> char  fbuf[20];
>>> dtostrf(mpu.getAngleX(), 8, 3,  fbuf) ;
>>> Paint_DrawString_EN(123, 123, fbuf,&Font16,  BLACK, GREEN);
>>
>>
>> Działa, dziękuję.
>>
>> Parametry można ustawić i wyświetlić. Ale jestem trochę rozczarowany
>> prędkością działania, no właśnie nie wiem czego. Biblioteki, procesora?
> Wyświetlacza,  graficzny wymaga dużo danych, masz go chociaż podłączony
> pod fizyczne spi czy też jest programowo sterowany na innych  pinach niż
> spi?
> Am prędkość możesz sprawdzic podłączając zwykły alfanumeryczny 2*15 z
> odpowiednia biblioteką.
>

Nigdy nie napisałem nawet linijki kodu dla mikrokontrolera to pewnie nie
powinienem się odzywać, ale hasło "z odpowiednią biblioteką" spowodowało
skojarzenia z ostatnimi wydarzeniami u nas to napiszę parę słów. A nuż
jakieś konstruktywne wypowiedzi się pojawią.

Brat opanowuje teraz procesory EFM32... Silabsa.
Pierwszy na tapecie był EFM32HG309F64G-C-QFN24 podłączony do USB.
Ichnia biblioteka USB kompilowała się na 35k i się wieszała. To chyba
też wyjaśnia dlaczego ich systemy uruchomieniowe (podłączane po USB) się
wieszają.
Nie spodziewaliśmy się, że obsługa USB wymaga więcej pamięci niż mamy na
cały program (64k - 4k (bootloader) - 12k (wirtualny EEPROM) = 48k / 2 =
24k na program).
Brat napisał to USB od zera 'po swojemu'. Kompiluje się do 5k. Zapewne
nie jest tak uniwersalne, ale się nie wiesza i urządzenie poszło do
ludzi. Najbardziej go dziwiło, że u nich wszystko przez DMA i nie da się
tego wyłączyć. No jak już jest flaga, że przyszła ramka i jest ona
dostępna to dlaczego on ma jeszcze teraz czekać aż to się z jednego
miejsca przeniesie do drugiego skoro akurat to jest to, co on chce jak
najszybciej obsłużyć.
Przyczyną wieszania jest błąd w hardware, który daje się obejść
programowo, ale im się widocznie nie chciało.
Brat mi tłumaczył, ale nie pamiętam dokładnie (było 2 miesiące temu).
Problem się pojawia, gdy transmisja ma długość wielokrotności 64 bajtów.
Ogólnie stwierdził, że był dotychczas rozpieszczony modułem USB z
AtXmega i nie miał pojęcia, że taki moduł da się tak spieprzyć jak to
jest w tym Silabsie.

Drugi na tapetę trafił EFM32PG22C200F128IM40-C. Wybraliśmy 128k bo tyle
pamięci dotychczas starczało. Bilans będzie chyba mniej więcej taki: 128
- 8(bootloader) - 24 (EEPROM) = 96 /2 = 48 na aplikację, która (w
AtXmega) ma poniżej 30k.

Projekty płytek już poszły do produkcji, a brat zgłębia procesor.
Kilka dni temu mnie zawołał aby mi pokazać głupotę na którą się natknął
w ref. manualu. No w życiu by nam do głowy nie przyszło, że ktoś, może
takie kłody rzucać nam pod nogi w tych czasach, kiedy wszystko się wali
i nie wyrabiamy się z przerabianiem urządzeń na elementy, które akurat
rzucili na rynek.
Widziałem na jego komputerze, nie chce mi się szukać gdzie to jest. Jak
doszedł do rejestrów do używania sprzętowego AES-a to jest tam napisane
coś w stylu, że procedury krypto mogą używać tylko specjaliści a reszta
hołoty powinna korzystać z biblioteki i dlatego pomijają opis tych
rejestrów.
Nie wiem co dalej. Czy np. jest szansa aby ta ich biblioteka krypto
zmieściła się w naszym bootloaderze. My potrzebujemy jakieś 4k, czy im
wystarczy te drugie 4k?
Na razie brat chyba podszedł do tego według jednej z metod rozwiązywania
całek - 'przez zaniechanie'. Wrzucił nasze procedury programowego
liczenia AESów i SHA, a rozpoznanie jak stosować ich moduł krypto
zostawia sobie na kiedy indziej.

Nie szukaliśmy (jesteśmy mocno zajęci - ja już robię następną płytkę -
tym razem z EFM32TG.. bo te PG22 i PG23 mają za mało nóg).
Może ktoś wie gdzie można znaleźć opis rejestrów pominiętych w manualu?
P.G.