C++ ośla łączka

Szkic, który wyświetla znaki w nawiasie zawiera: Paint_DrawString_EN(123, 123, "XYZ",&Font16, BLACK, GREEN);

chcę go zmodyfikować, aby wyświetlał zamiast znaków z cudzysłowu wartość tej zmiennej mpu.getAngleX() Da się tak zamiast tego cudzysłowu po prostu coś tam wstawić?

Czy zmian trzeba dokonać głębiej? Paint_DrawString_EN to jest funkcja z biblioteki i tam trzeba coś zmienić?

Dzieje się to na Arduino, mój poziom to blinking LED++

Robert

Powinno sie dac ... tylko fajnie by było, zeby to był string.

A sprintf podobno nie dziala

char fbuf[20]; dtostrf(mpu.getAngleX(), 8, 3, fbuf) ; Paint_DrawString_EN(123, 123, fbuf,&Font16, BLACK, GREEN);

J.

W dniu 2023-02-01 o 17:56, J.F pisze:

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? Gdybym chciał na bieżąco odczytywać wartość i wyświetlać w pętli, to mam kilka fps.

Taki wyświetlacz:

Robert

W dniu 2023-02-01 o 22:05, Robert Wańkowski pisze:

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ą.

Zmień na esp lub arduino ale z arm-em to pójdzie szybciej.

W dniu 2023-02-01 o 22:33, Janusz pisze:

Podłączyłem jak pokazali

W dniu 2023-02-01 o 22:33, Janusz pisze:

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 =

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.

W dniu 2023-02-01 o 22:48, Robert Wańkowski pisze:

danych, np ograniczyć zmiany na wyświetlaczu do pojedynczych elementów a nie odświeżać całego. Tu cykl filmów jak przyspieszyć grafikę

A co konkretnie to USB udaje: HID,CDC?

Pdf nie dali, to niech sp*. Ale - to ma 60k pikseli.

A jaką masz predkosc SPI?

A te piksele tj jak ustawione? W kwadrat i rogow nie ma, czy jakos dokola okregu ustawione?

J,

W dniu 2023-02-02 o 13:51, Piotr Gałka pisze:

Moje doświadczenia z SiLabsem datują się na 2006 rok i procesory 8051. Wtedy biblioteka USB była dobrze napisana i używało się jej wygodnie. Jak mogli tak spaprać coś co dobrze działało?

Ja bym zaczął od napisania do SiLabs. Wtedy (rok 2006) odpowiadali szybko i chętnie.

Też na początku się zastanawiałem, bałem się, że będą współrzędne biegunowe. :-)

Jest normalnie, narożniki pomija.

Już wiem, że te Arduino Uno z 16 MHz nie da rady, aby na bieżąco płynnie wyświetlać nawet jedną wartość numeryczną.

Trzeba czyścić ekran przed następnym rekordem do wyświetlenia. Czyszczę tylko ten obszar od rekordu, a i tak miga.

Dlatego kupiłem szybszy:

Robert

To jest troche nadmiarowe, z zapasem dalem :-)

To teoretycznie wcale nie tak wolno musi byc.

No, ciekawe jak sterownik podlaczyli do ekranu ...

no a) przygotowac gdzies buforze caly nowy obszar ze znakami, przepisac. b) nie ma gdzies w tej funkcji mozliwosci ustawienia, aby rysowala i czyscila jednoczesnie? c) mozna samemu cos takiego napisac, ale nie jest to takie trywialne, d) przejsc na font "7-segmentowy". wtedy wystarczy zapalic lub zgasic kilka fikusnych prostokątów :-)

SPI tez ma szybsze?

J.

W dniu 2023-02-03 o 17:42, J.F pisze:

Przeglądają bibliotekę okazało się, że jest: Paint_DrawNum() ale jak i tak działa to skandalicznie wolno. :-)

Ale to poziom za wysoki dla mnie. Szukałem miejsca w bibliotekach, gdzie są wysyłane dane na wyświetlacz, ale ugrzęzłem.

Tu jest ta biblioteka.

Coś podobnego zrobiłem, czyszczę wyświetlając ten sam rekord kolorem czcionki takim samym co tło. Bo biblioteka nie czyści tła jeżeli wyświetlana czcionka ma takie samo. Ale i tak mizernie. Czas jest tak długi, że główna funkcja programu (wyświetlanie punktu według wskazać akcelerometru - taka poziomica 2D) nie działa płynnie.

Ale linia (patrząc w kod biblioteki), rysowana jest w pętli z pikseli. Tak samo jak czcionki, rysowane są punkt po punkcie według zawartości tablicy. I pewnie będzie trwało podobnie jak wyświetlenie czcionki.

80 MHz.

Robert

Jest nawet void Paint_DrawFloatNum(UWORD Xpoint, UWORD Ypoint, double Nummber, UBYTE Decimal_Point, sFONT* Font, UWORD Color_Background, UWORD Color_Foreground) { char Str[ARRAY_LEN] = {0}; dtostrf(Nummber,0,Decimal_Point+2,Str); char * pStr= (char *)malloc((strlen(Str))*sizeof(char)); memcpy(pStr,Str,(strlen(Str)-2)); * (pStr+strlen(Str)-1)='\0'; if((*(pStr+strlen(Str)-3))=='.') { *(pStr+strlen(Str)-3)='\0'; } //show Paint_DrawString_EN( [...]

Robi z grubsza to samo, co proponowalem - ale po co to podwójne buforowanie?

O, i jest nawet Paint_DrawString_CN ... nowe czasy :-)

Na jedno wychodzi - wyczyscisz i masz ciemny ekran. Narysujesz ... no i miga.

No wlasnie - ma tryb, gdzie jednoczesnie ustawia piksele znaku i tla. Moze troche wolno, ale bez migania.

Tylko nie rozumiem tego koloru czcionki. Sama czcionka jest bitowa - gdzie tu kolor?

parameter: Xpoint ：X coordinate Ypoint ：Y coordinate Acsii_Char ：To display the English characters Font ：A structure pointer that displays a character size Color_Background : Select the background color of the English character Color_Foreground : Select the foreground color of the English character

UWORD Page, Column;

if (Xpoint > Paint.Width || Ypoint > Paint.Height) { //Debug("Paint_DrawChar Input exceeds the normal display range\r\n"); return; } uint32_t Char_Offset = (Acsii_Char - ' ') * Font->Height * (Font->Width / 8 + (Font->Width % 8 ? 1 : 0)); const unsigned char *ptr = &Font->table[Char_Offset];

for ( Page = 0; Page < Font->Height; Page ++ ) { for ( Column = 0; Column < Font->Width; Column ++ ) {

//To determine whether the font background color and screen background color is consistent if (FONT_BACKGROUND == Color_Background) { //this process is to speed up the scan if (pgm_read_byte(ptr) & (0x80 >> (Column % 8))) Paint_SetPixel (Xpoint + Column, Ypoint + Page, Color_Foreground ); } else { if (pgm_read_byte(ptr) & (0x80 >> (Column % 8))) { Paint_SetPixel (Xpoint + Column, Ypoint + Page, Color_Foreground ); } else { Paint_SetPixel (Xpoint + Column, Ypoint + Page, Color_Background ); } } //One pixel is 8 bits if (Column % 8 == 7) { ptr++; } }/* Write a line */ if (Font->Width % 8 != 0) { ptr++; } }/* Write all */ }

O co im chodzi z tymi kolorami?

Moze zmien ciut kolor tla, lub wywal to sprawdzanie i nie kasuj.

Ale tym pomysle pikseli skladajacych sie na znak jest znacznie mniej (bo tylko segmenty), i segmenty wszedzie takie same - wiec nie trzeba calego obszaru znaku kasowac.

A wyswietlacz ile dopuszcza?

No i biblioteka sporo tu jednak wylicza dla kazdego piksela - moze nie w SPI problem.

A i sama biblioteka, gdzie jak widze co bajt chwila jest pin CS zmieniany ... ciekawe czy tak trzeba.

J.

W dniu 2023-02-02 o 14:31, Marek pisze:

Jakiś czas nie zaglądałem na grupę. Nie potrafię odpowiedzieć tak, abym był pewny, że nie wprowadzam w błąd. To urządzenie, które jako pierwsze na Silabsie było robione to HID. Ale on równolegle rozpracowywał też komunikację winusb bo tę stosujemy w pozostałych produktach. P.G.

W dniu 2023-02-03 o 10:16, MKi pisze:

Minęło kilka dni. Wczoraj zadzwonił (od soboty jestem chory i przeniosłem się czasowo z pracą do domu) i pochwalił się, że udało mu się policzyć AESa z wykorzystaniem tej maszynki sprzętowej. Według jego opisu to cała ta maszynka jest tak pomyślana, aby efektywnie kodować długie strumienie danych i tylko tak daje się wykorzystać. Nie ma (chyba) do niej wejścia typu 'policz mi jednego AESa'. Nasze ramki zazwyczaj są poniżej jednego bloku. Przygotowanie do jednorazowego przeliczenia AESa jest odstraszające. Nawet zasugerował, że może to więcej zajmie niż policzenie na piechotę. Tu pewnie przesadził, bo sprzęt jak już ruszy to pewnie nadgoni nawet gdy do policzenia jest tylko jeden blok. Z tego co zrozumiałem to jedyną metodą przekazania wszystkich danych (klucz, wektor inicjujący, co ma być policzone i blok danych) do maszynki jest DMA. Czyli trzeba wszystko poukładać tak jak jest potrzebne i jakoś tam wrzucić i potem tak samo tylko przez DMA można dostać wynik. Ja nigdy nic nie pisałem na procesory. Pojęcie DMA to tylko mniej więcej wiem o co biega, a jak się z tego faktycznie korzysta to nie czuję. P.G.

W dniu 2023-02-02 o 16:09, Jacek pisze:

Kiedyś dawno (trochę dla sportu) na podstawie dokumentów NIST napisałem (C++) swoje procedury dla DES, AES, SHA, CMAC, HMAC. Potem jak doszliśmy do szyfrowania komunikacji brat przepisał je na assembler i na C. Według tego co wiem od brata (piszę o czymś o czym mam blade pojęcie) w przypadku AtXmega (nie ma wbudowanego SHA) napisanie w assemblerze daje kilkukrotną przewagę nad napisaniem w C. Ja to rozumiem tak, że C blokuje 'dla siebie' ileś rejestrów, a żeby policzyć SHA256 bez ciągłego przewalania danych między rejestrami a pamięcią trzeba wykorzystać praktycznie wszystkie rejestry procesora. SHA512 już się tak nie da napisać i różnica między C a assemblerem będzie mniejsza.

Opis jak się liczy AES-a zrozumiałem na tyle dobrze, że używane tam tabele wygenerowałem sobie z równań, aby nie ryzykować błędem przy przepisywaniu, ale dlaczego rozszyfrowywanie nie robione metodą 'do tyłu' tylko 'inaczej do przodu' daje to samo od czego zaczęliśmy to już nie całkiem ogarniam. Chciałbym jeszcze kiedyś na tym samym poziomie zrozumieć wykorzystanie krzywych eliptycznych w kryptografii niesymetrycznej. Czyli nie koniecznie jaka matematyka za tym stoi, ale jak to policzyć z dokładnością do każdego bitu.

Są może gdzieś jakieś przykłady? P.G.

Jak dobry kompilator to sobie jakoś radzi, jak gorszy to gorzej. Czasami w asemblerze można coś bardziej zwarcie napisać.

Jednak w dłuższej perspektywie, pisanie w asm to strata czasu i proszenie się o kłopoty; zmienia się platforma i musisz pisać/testować/poprawiać/testować itd, od nowa.

Jeśli procesor już nie radzi sobie z zagadnieniem to trzeba wziąć większy procesor zamiast schodzić do asemblera.

jp

W dniu 2023-02-13 o 09:26, jacek pozniak pisze:

Zapewne 100% racja, ale ja mówię o kimś, dla kogo assembler był gdzieś tak od 1983 naturalnym środowiskiem, a C używa tylko od jakichś 15 lat.

Do dziś bratu brakuje w C dostępu do bitu przeniesienia, czy parzystości. P.G.