W dniu 2023-02-02 o 17:29, J.F pisze:
> On Wed, 1 Feb 2023 22:05:55 +0100, Robert Wańkowski wrote:
>> 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?
>> Gdybym chciał na bieżąco odczytywać wartość i wyświetlać w pętli, to mam
>> kilka fps.
>>
>> Taki wyświetlacz:
>> https://botland.com.pl/wyswietlacze-lcd-tft-i-ips/19
040-wyswietlacz-general-lcd-ips-128-240-x-240-px-do-
raspberry-pi-i-arduino-okragly-waveshare-19192-59044
22371845.html
>
> Pdf nie dali, to niech sp*. Ale - to ma 60k pikseli.

https://www.waveshare.com/w/upload/5/5e/GC9A01A.pdf

> 16 bit/px, okolo 1Mbit.
>
> A jaką masz predkosc SPI?

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

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:
https://botland.com.pl/moduly-wifi-i-bt-esp32/8893-e
sp32-wifi-bt-42-platforma-z-modulem-esp-wroom-32-zgo
dny-z-esp32-devkit-5904422337438.html?cd=18298825651
&ad=&kd=&gclid=CjwKCAiA_vKeBhAdEiwAFb_nrc_djBkEltTFP
xgxEVQM-QkTRhLMWMTm4Yn55ASpYqsSdfjrnEHDDRoCEcgQAvD_B
wE


Robert

do góry

On Fri, 3 Feb 2023 13:25:39 +0100, Robert Wańkowski wrote:
> W dniu 2023-02-02 o 17:29, J.F pisze:
>> On Wed, 1 Feb 2023 22:05:55 +0100, Robert Wańkowski wrote:
>>> 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ę.

To jest troche nadmiarowe, z zapasem dalem :-)

>>> 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:
>>> https://botland.com.pl/wyswietlacze-lcd-tft-i-ips/19
040-wyswietlacz-general-lcd-ips-128-240-x-240-px-do-
raspberry-pi-i-arduino-okragly-waveshare-19192-59044
22371845.html
>>
>> Pdf nie dali, to niech sp*. Ale - to ma 60k pikseli.
>
> https://www.waveshare.com/w/upload/5/5e/GC9A01A.pdf
>
>> 16 bit/px, okolo 1Mbit.
>>
>> A jaką masz predkosc SPI?
> 8 MHz

To teoretycznie wcale nie tak wolno musi byc.

>> A te piksele tj jak ustawione?
>> W kwadrat i rogow nie ma, czy jakos dokola okregu ustawione?
>
> Też na początku się zastanawiałem, bałem się, że będą współrzędne
> biegunowe. :-)
>
> Jest normalnie, narożniki pomija.

No, ciekawe jak sterownik podlaczyli do ekranu ...

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

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 :-)

> Dlatego kupiłem szybszy:
> https://botland.com.pl/moduly-wifi-i-bt-esp32/8893-e
sp32-wifi-bt-42-platforma-z-modulem-esp-wroom-32-zgo
dny-z-esp32-devkit-5904422337438.html

SPI tez ma szybsze?

J.

do góry

W dniu 2023-02-03 o 17:42, 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ę.
>
> To jest troche nadmiarowe, z zapasem dalem :-)

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


>> 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.
>
> no
> a) przygotowac gdzies buforze caly nowy obszar ze znakami, przepisac.

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.
http://3a-meble.com.pl/lib/bc295x/LCD_1inch8-ldrnn3f
w.zip

> b) nie ma gdzies w tej funkcji mozliwosci ustawienia, aby rysowala i
> czyscila jednoczesnie?

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.

> 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 :-)

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.

>
>> Dlatego kupiłem szybszy:
>> https://botland.com.pl/moduly-wifi-i-bt-esp32/8893-e
sp32-wifi-bt-42-platforma-z-modulem-esp-wroom-32-zgo
dny-z-esp32-devkit-5904422337438.html
>
> SPI tez ma szybsze?

https://www.espressif.com/sites/default/files/docume
ntation/esp32_datasheet_en.pdf

39 strona.

80 MHz.

Robert

do góry

On Mon, 6 Feb 2023 00:25:11 +0100, Robert Wańkowski wrote:

> W dniu 2023-02-03 o 17:42, 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ę.
>>
>> To jest troche nadmiarowe, z zapasem dalem :-)
>
> Przeglądają bibliotekę okazało się, że jest:
> Paint_DrawNum()
> ale jak i tak działa to skandalicznie wolno. :-)

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 :-)

>>> 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.
>>
>> no
>> a) przygotowac gdzies buforze caly nowy obszar ze znakami, przepisac.
>
> 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.
> http://3a-meble.com.pl/lib/bc295x/LCD_1inch8-ldrnn3f
w.zip
>
>> b) nie ma gdzies w tej funkcji mozliwosci ustawienia, aby rysowala i
>> czyscila jednoczesnie?
>
> Coś podobnego zrobiłem, czyszczę wyświetlając ten sam rekord kolorem
> czcionki takim samym co tło.

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

> Bo biblioteka nie czyści tła jeżeli
> wyświetlana czcionka ma takie samo.

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
****************************************************
**************************/
void Paint_DrawChar(UWORD Xpoint, UWORD Ypoint, const char Acsii_Char,
sFONT* Font, UWORD Color_Background, UWORD Color_Foreground)
{

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 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.
>
>> 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 :-)
>
> 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.

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.


>>> Dlatego kupiłem szybszy:
>>> https://botland.com.pl/moduly-wifi-i-bt-esp32/8893-e
sp32-wifi-bt-42-platforma-z-modulem-esp-wroom-32-zgo
dny-z-esp32-devkit-5904422337438.html
>>
>> SPI tez ma szybsze?
>
> https://www.espressif.com/sites/default/files/docume
ntation/esp32_datasheet_en.pdf
>
> 39 strona.
>
> 80 MHz.

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.

do góry

W dniu 2023-02-02 o 14:31, Marek pisze:
> On Thu, 2 Feb 2023 13:51:31 +0100, Piotr
> Gałka<p...@c...pl> wrote:
>> Brat napisał to USB od zera 'po swojemu'. Kompiluje się do 5k.
>
> A co konkretnie to USB udaje: HID,CDC?
>

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.

do góry

W dniu 2023-02-03 o 10:16, MKi pisze:
>
>> Może ktoś wie gdzie można znaleźć opis rejestrów pominiętych w manualu?
>
> Ja bym zaczął od napisania do SiLabs. Wtedy (rok 2006) odpowiadali
> szybko i chętnie.
>

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.

do góry

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

> Bo biblioteki pełnia rolę marketingową i poza zastosowania
> eksperymentalne nie powinno się wychodzić.
> Do biznesu zaś, najlepiej trzymać wszystko w czystym kodzie języka
> C i w jak najmniejszym stopniu korzystać ze specyfiki platformy.
> Też stosuję, np. AES128 i mój procesor ma chyba jakieś sprzętowe
> wihajstry do tego ale nie zamierzam korzystać.
>

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.

do góry

Piotr Gałka wrote:
> 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.
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





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

--
jp

www.flowservice.pl
www.flowsystem.pl

do góry

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

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

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.

do góry

W dniu 2023-02-14 o 15:39, Piotr Gałka pisze:
> W dniu 2023-02-13 o 09:26, jacek pozniak pisze:
>
>> 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.
>
> 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.
Nie wiem co w arm-ach jest ale w avr-ch jest rejestr SREG dostępny
normalnie z C.
Wystarczy z and-ować z odpowiednią maską i mamy np przeniesienie czyli
if (SREG & 0x01) {}.

--
Janusz

do góry