Zealota

Moim skromnym doświadczeniem CubeIDE idzie w dobrą stronę. Oceniam tę platformę bardzo pozytywnie w stosunku do TrueStudio i również SystemWorkbench. Powoli przejmuje co najlepsze z obu rozwiązań (bo jednak było trochę różnic), a w obecnym wydaniu w porównaniu do SW jest wyjątkowo szybka jeśli chodzi o uruchamianie, jak na fork Eclipse'a oczywiście. Dodatkowo od dawna nie miałem żadnego problemu z błędami workspace, z czym był problem jeszcze jakiś czas temu. Bardzo dobrze działa indeksowanie i właściwie nie pojawiają się z tego powodu żadne komunikaty, jak w przeszłości. Brakuje mi jedynie poziomu systemu "błędów składni" co w SW działało praktycznie w czasie "rzeczywistym", tutaj czasami dopiero kompilacja zgłasza błędy - szczegónie jest to istotne w analizie makr rejestrów z CMSIS. Ot takie dodatkowe podsumowanie trochę "poza konkursem" ... bowiem mam na podorędziu parę projektów z przetwornikami ALC5631Q, CS4344 i CS5344 a ta seria poradników Elvisa to jak objawienie, podobnie było zresztą z serią poradników o USB. To tak informacyjnie dla tych, którzy mają jeszcze wątpliwość, że taka praca jest wyjątkowo pożyteczna. EDIT. A jeszcze jedno, gdyby dało się do każdej części poradnika dodać odnośnik to części poprzednich i następnych to by jeszcze lepiej się to czytało i analizowało

Jeszcze gwoli ścisłości najnowsza wersja to 1.4.1.

Jako uzupełnienie warto zaglądnąć tutaj: https://www.youtube.com/channel/UCwOkALY6oQbOL1zU7ApaPHg Bardzo podobna tematyka, STM32 oraz ESP32. Tutki, kody, również DSP na FPGA. Wszystko tłumaczone z należytą szczegółowością. Polecam

Żeby jeszcze ostatecznie podsumować temat, który w niezamierzony sposób rozpocząłem, polecam ten oto stream: Stream ten w wielu aspektach porusza zagadnienia, o których nie miałem pojęcia, a teraz jeszcze jaśniej się zrobiło.

Dzięki za tak szczegółowy opis. Póki co zostawiam temat, ale na pewno wróci do mnie gdy przyjdzie pora.

Oczywiście, że chcą, ale pozwól, że jeszcze coś dopiszę, to może naświetli brak wiedzy lub moje błądzenie. Zanim zaczniemy powrócę ostatniego wpisu i tablic napis1 oraz napis2. Opiszę moje przypuszczenia - podkreślam przypuszczenia, w formie pytającej, aczkolwiek podglądam co widzę w debugerze, bo niestety często jest to źródłem mojej wiedzy. Środowisko to CubeIDE_1.3.0. Po deklaracji napis1 zrobi "sieczkę" w pamięci. Dostanę 14 znaków, w tym "0" i nie będę wstanie "rozkodować" tego napisu, bo kompilator rozłożył "po bajcie" zgodnie ze stroną kodową edytora - zwykłe litery po 1 bajcie, polskie po 2, dokładnie jak to jest z tablicą znaków w UTF-8 i chyba nie będę wiedział jak to poskładać. Natomiast napis2 jest dla mnie uporządkowany, bo kompilator "zamienił" UTF-8 na UNICODE. Mam dokładnie tyle bajtów ile liter x 2 + 2 = 20 (tyle zajmuje koniec znaku, jeśli dobrze patrzę), bo akurat skorzystałem z opcji kompilatora, o której pisałem i wchar_t zajmuje 2 bajty. Gdy chcę dopasować litery polskie i np. wyświetlać je w postaci bitmap na LCD, to moje dekodowanie wydaje się banalne, jak ten przykład z tablicą. Mogę indeksować tablicę i sprawdzać warunki, porównywać itd. Co zrobię, gdy dostanę bufor z napisem po polsku? Tego jeszcze nie wiem, nie próbowałem dekodować w tę stronę. Jeśli to będzie Unicode, to nie widzę problemu na tę chwilę. A no i deklaracja znak='ą' jak pokazałem wyżej daje ostrzeżenia: large integer implicitly truncated to unsigned type [-Woverflow] multi-character character constant [-Wmultichar] Wydają mi się to jasne, bo zgodnie ze stroną kodową do danej jednobajtowej próbuję upchać "z edytora" 2 bajty. No to tyle z mojego riserczu. Zamieniam się w słuch.

const char napis1[]="gżegżółka"; const wchar_t napis2[]=L"gżegżółka"; char znak1 = napis1[1]; wchar_t znak2 = napis2[1]; Jeśli tak zadeklaruję napisy to jakie wartości przyjmą zmienne znak1 i znak2 i czemu tylko znak2 daje mi to co chcę, wartość którą ma zainicjowaną w tablicy polskich znaków? Co będzie gdy zrobię tak: char znak = 'ą'; Czemu ten zapis jest do kitu, bo przecież jest, gdy ustawię stronę kodową edytora na UTF8?

Daruj sobie wycieczki osobiste w ocenie jakie książki w życiu przeczytałem oraz w tym ile mam lat. Gadajmy o mikrokontrolerach, bo o tym jest wątek. Dla przypomnienia temat wyjściowy to operacje we/wy na kartę, a właściwie problem (niech będzie mój) z polskimi literami kodowanymi w UTF-8. Nic nie przeinaczam, skrytykowałeś użycie wchar_t do zapisania napisu kodowanego w UTF-8 w pamięci flash, który podałem. Nadal nie wiem dlaczego jest nieelegancki. Gdy zaczęliśmy drążyć to okazało się, że przenośność kodu, endianess, amigi itd. to w ogóle jakieś błędne koło, które ma marginalne znacznie w tej całej dyskusji. Jakie ma znaczenie rozmiar typu wchar 2 czy 4 bajty, jeśli zakres znaków jaki chce używać spokojnie mieści się w 2 bajtach (polskie litery), a gcc jest elastyczne i pozwala regulować taki parametr (-fshort-wchar), a również pomoże gdyby ktoś chciał zaoszczędzić pamięci, itd.... Przecież polski znak w UTF-8 to już jest szeroki, więc co jest nie tak z wchar_t? Próbuję przekazać, że w moim rozumieniu "char" to jest za mało by trzymać w pamięci mikrokontrolera napisy kodowane w UTF-8, szczególnie w kontekście korzystania z polskich liter, które zajmują 2 bajty - zatem należy użyć wchar_t. Gdybym miał inne założenia to bym sobie wziął CP852 i nie miałbym tego problemu i czym to jest hgw w tym kontekście? Skrót oczywiście znam, tak dla uprzedzenia... A zapis: const wchar_t napis[] = L"gżegżółka"; to niby co to jest, jak nie "wepchanie" kodów znaków do tablicy wchar_t? Gdzie tu są "wynalazki"? Być może nadal czegoś nie rozumiem, ZAPROPONUJ jak inaczej zapisać do pamięci mikrokontrolera napis kodowany w UTF-8 i uzasadnij krótko dlaczego właśnie tak. Zwykłe znaki trzymać w char, a polskie w wchar, bo UTF-8 ma zmienną ilość bajtów - przecież to bez sensu. Jeden przykład na pewno powie więcej niż 5 akapitów pisaniny. Co do programowania, nie zamierzam być webmasterem, linuksa czy windowsa używam głównie jako platformy do programowania mikrokontrolerów w c, a nie stricte do programowania - obecnie. Jeśli będzie potrzeba to być może się to zmieni, ale na pewno nie w szerokim zakresie. To, że jakieś pliki dla deweloperów gdzieś są w czeluściach "/" to super, na pewno skorzystam, jeśli poznam - no cóż nie od razu Rzym zbudowano... Ścieżki oczywiście pomocne, nie trzeba szukać po internetach jak napisałeś.

Proponuję zresetować, tę część wątku, bez moich domysłów tylko po uzupełnieniu wstępnym wiedzy, wygrzebałem co mam, bo wszystko wskazuje na to, że zapomniałem o co "kaman". Zanim przejdę dalej to wymaga wyjaśnienia link, który podałem - nigdzie nie pisałem, że z tego korzystałem. Ten link to był dla mnie dowód pośredni na to, żeby "działać" z kodowaniem UTF8 (i nie tylko) to należy (można, trzeba - do wyboru) korzystać z typu "wchar_t" - jeśli się umie, ja być może nie umiem pomimo pewnych pozytywnych wyników - choćby możliwość dekodowania poprawnie polskich znaków w moich projektach, ale mniejsza na razie z tym. Tamte kody po prostu pomieszałem , a główny problem polegał z pomieszania pojęć "UNICODE" i "UTF8" mea culpa, biję się w pierś... Mam w starym projekcie zdefiniowane dwie tablice jedna oznaczona jako Unicode, a druga jako UTF-8 (również też inne "latiny" czy "cp"). Wartości polskich znaków odpowiadają tym choćby tutaj: https://pl.wikipedia.org/wiki/Kodowanie_polskich_znaków Oprócz tego wiele wyjaśnia ten link: https://www.utf8-chartable.de/ Ta tablica dokładnie odzwierciedla, tak myślę, zależność kodów w Unicode oraz UTF-8. To pewnie ta różnica, o której pisałeś czyli znaki Unicode i UTF-8 być może wymagają konwersji, a być może wystarczy obie wersje stablicować i używać w odpowiednim kontekście. Mój ten skrytykowany, niby "elegancki" sposób to właśnie skorzystanie z takich tablic. Przecież "stablicować" czy liczyć w locie to odwieczny dylemat czy poświęcić trochę miejsca w pamięci stałej czy może lepiej liczyć w locie - bez kontekstu zwykle nie można tego rozsądzić, zgadza się? Jak pojmuję Twój tok rozumowania ten cały wchar to na grzyba, bo można sobie coś w locie konwertować i używać innych typów, bo wchar nie jest przenośny i na amidze będę miał problem (lub gdzie indziej). Jak pisałem delikatnie obecnie mam w nosie amigę , jednak przyjmuję ten pogląd na przyszłość o przenośności kodu, bo w sumie w moich założeniach jest, żeby te "polskie znaczki" rozpatrywać w szerszym aspekcie - być może moje projekty, a to trzeba wyjaśnić, mają działać głównie na STM32 i w przyszłości komunikować się z softem na Linuksie - a w ostateczności pod Windows. W środowisku, którym piszę opartym na gcc wchar_t jest 4-bajtowy - można to zmienić za pomocą opcji kompilatora do 2 bajtów, ale to tylko tak informacyjnie. W Windows jest 2 bajtowy tak pisałeś i faktycznie można to znaleźć choćby tu: https://docs.microsoft.com/pl-pl/cpp/cpp/char-wchar-t-char16-t-char32-t?view=vs-2019 W CubeIDE_1.3.0 (chyba kompilator to załatwia) konwersja następuje prawdopodobnie w "locie", bo pomimo wybrania strony kodowej UTF-8, w pamięci lądują znaki z tablicy UNICODE ('ą' = 261). Ten mechanizm jest mi obcy, nie znam standardu, który to opisuje, więc to oczywiście domniemania, może źle patrzę... Co do Twojego "dywiz" na cóż mi on, w kontekście moich wymagań "co do projektów". Rozumiem, że "wywiz" to taki przykład podobny to tej amigi - czyli przerysowanie celem nakreślenia problemu. Nie zamierzam sięgać dalej niż 2 bajty, a w Unicode to nawet nie jest dalej niż 1 bajt? Czy zakres zmiennej 2-bajtowy w Windows nie wystarczy, żeby te kilka polskich znaków dobrze obsłużyć w Linuksie i Windows? Czy opcje kompilatora gcc, które pozwalają sterować wielkością wchar_t, nie wystarczą to kilkusystemowej przenośności kodu? Ostatecznie czemu ten "wchar_t" to zły pomysł, bo niestety nie łapię tej negacji? Czy wchar to nie jest "następca" char, który wymyślono, żeby znaki kilkubajtowe "trzymać" w czymś? A może po prostu sam nie korzystasz z wchar_t tylko z przyzwyczajenia "liczysz wszystko w locie, tak od lat"? Dobrze byłoby chyba te moje wypociny przenieść do nowe wątku...

Do Linuksa mam inna tablicę polskich literek, cóż poradzić, że w Windows zawsze na opak. Co do myślnika, gdy będę go potrzebował to znajdę odpowiedni kod.

Gdy przyjdzie znowu taka potrzeba to wrócę do tematu. Z ciekawości zarzuciłem temat "na internety" i znalazłem takie coś: https://kmim.wm.pwr.edu.pl/myszka/wp-content/uploads/sites/2/2015/03/w11.pdf Jest tam m.in. taki tekst: "powinniśmy korzystać z typu wchar_t (ang. „wide character”), jednak jeśli chcemy udostępniać kod źródłowy programu do kompilacji na innych platformach, powinniśmy ustawić odpowiednie parametry dla kompilatorów, by rozmiar był identyczny niezależnie od platformy." W sekcji "Polskie literki" robią dokładnie to samo co "sam wymyśliłem" także jest coś na rzeczy...

Bo mogę? Bo nie umiem wymyślić nic bardziej zgrabnego? A to jest zgrabne, tak uważam. Nie jestem programistą, żeby z rękawa znajdować dobre rozwiązania do problemu. Przejrzę jeszcze raz wątek skoro autor ma coś do zaproponowania. Dodatkowo dlaczego mam coś kompilować pod Amigę Rozumiem też przewrotny przykład poprzez skrajny, w kontekście moich problemów, przewartościowany przykład, który prawdopodobnie zwraca uwagę na problem przenośności kodu z powodu endianess. Znam ten problem oraz to pojęcie. Programując czysto amatorsko do tej pory nie musiałem nad tym się pochylać. Linux, Windows, STM32 i AVR to wszystko operuje na little endian, zatem póki co mam to w pamięci i się nie przejmuję.

Przytoczę zatem ze swojego podwórka pewien przypadek. Zwykle do programowania używam Eclipse zarówno pod Linuxem jak i Windows i czasami muszę dokonywać importu projektów z jednego środowiska do drugiego i na odwrót. Żeby w plikach źródłowych, które korzystają z polskich znaków nie mieć kłopotu z krzaczkami to założyłem sobie, żeby strony kodowe mieć w obu środowiskach ustawione na UTF8 - założyłem sobie, że tak będzie również dobrze pod kątem przyszłych projektów, które np. będą musiały komunikować się między sobą i poprawnie działać z polskimi znakami i tak zostało. Jeśli więc w plikach źródłowych pojawiają się polskie znaki, np. napisy w pamięci flash, czy komentarze po polsku, to żeby kod był "czysty i poprawny i widoczny" musiałem skorzystać z "czegoś" - prawdopodobnie bez dobrego rozeznania, padło właśnie na wchar_t, użycie char nie wystarczyło. Kawałek kodu, który przytoczyłem, szczególnie w dziedzinie definicji napisów w pamięci, w różnych stronach kodowych się sprawdza - na pewno pod Windows - w Linuksie jeszcze nie testowałem. Mogę ustawić choćby na UNICODE i skorzystać z innych wzorców znaków i również poprawnie to działa. Tłumaczę sobie to tak, że przy ustawionej stronie kodowej UTF8 znaku nie da się "upakować" do jednobajtowego char . Pod Linuksem też chyba się "zmieści" skoro wchar_t ma 4 bajty. Oczywiście to powoduje marnowanie pamięci, ale chyba bez przesady.... Gdybym wcześniej zdecydował się na stronę kodową CP1250, to nie byłoby tego problemu, ale pewnie niepotrzebnie pojawiły się ograniczenia "gdzie indziej". Jeśli jest lepsze rozwiązanie niż skorzystanie z wchar_t ze strona kodowa UTF8, to z chęcią je poznam.

Wreszcie normalne HDMI na pokładzie i gniazda z jednej strony: Na ali do kupienia za 16 dolców.

Tak przeglądam ten wątek, może trochę nieuważnie, ale czy przypadkiem nie jest problem z obsługą znaków dwubajtowych? Swego czasu drążyłem ten temat w c i do obsługi znaków dwubajtowych rozwiązaniem był typ "wchar_t" służący do definiowania znaków. Dzięki temu było możliwa obsługa strony kodowej UTF8 np. ustawionej w Eclipse. Być może w komunikacji z systemem plików też będzie to dobra wskazówka. Może taki przykład będzie przydatny: #include <stddef.h> const wchar_t string[] = L"Ą ś ć ź ń"; Istotny jest ten zapis z dużym "L", a po takiej deklaracji to już bez problemu można było szukać polskich znaków, które dla UTF8 były zdefiniowane tak: #ifdef UTF_8 const wchar_t utf_8Code[18] = { 0xC59A, /*Ś, */ 0xC5B9, /*Ź, */ 0xC59B, /*ś, */ 0xC5BA, /*ź, */ 0xC581, /*Ł, */ 0xC484, /*Ą, */ 0xC5BB, /*Ż, */ 0xC582, /*ł, */ 0xC485, /*ą, */ 0xC5BC, /*ż, */ 0xC486, /*Ć, */ 0xC498, /*Ę, */ 0xC583, /*Ń, */ 0xC393, /*Ó, */ 0xC487, /*ć, */ 0xC499, /*ę, */ 0xC584, /*ń, */ 0xC3B3, /*ó, */ }; #endif