W dniu 2022-07-25 o 21:29, heby pisze:

> Architekturę zrobiłbym zupełnie odwrotnie, tzn moduły rejestrowały by do
> tabelki co mają.

Tak mi było dla mnie naturalnie.
Jak wyszukuję według GUID i jest ich kilka to zakładam, że przyszły
użytkownik tego kodu (czyli ja za ileś tam lat) w takiej sytuacji będzie
musiał np wypisać na ekranie numery urządzeń i zapytać użytkownika o
które urządzenie mu chodzi. Czyli już w momencie wyszukiwania jest mi
potrzebna tabelka.
Jeśli chciałbym mieć tabelkę wszystkich, które w danej aplikacji w sumie
używam to wtedy byłaby to tabelka do której wszyscy zgłaszają co używają.


>>    fun({0x00112233,
>> 0x4455,0x6677,{0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0x
FF}});
>> }
>> Drugiego wywołania funkcji fun Builder 5 nie akceptuje.
>> Próbowałem dawać dodatkowe nawiasy i nic.
>
> void fun(GUID const& g);
>
> fun( GUID(0x100,0x100,...) ); ?
>

Wstawiłem ten const&, żeby nie było, że kombinuję inaczej.
Żadna z poniższych kombinacji nie przechodzi:
fun(GUID{0x00112233,0x4455,0x6677,{0x88,0x99,0xAA,0x
BB,0xCC,0xDD,0xEE,0xFF}});
fun(GUID(0x00112233,0x4455,0x6677,{0x88,0x99,0xAA,0x
BB,0xCC,0xDD,0xEE,0xFF}));
fun(GUID(0x00112233,0x4455,0x6677,(0x88,0x99,0xAA,0x
BB,0xCC,0xDD,0xEE,0xFF)));
fun(GUID(0x00112233,0x4455,0x6677,0x88,0x99,0xAA,0xB
B,0xCC,0xDD,0xEE,0xFF));
fun(GUID(0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x8
8,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0xFF));

W obu ostatnich przypadkach: Error: Cannot cast from 'int' to '_GUID'.

To są wszystko próby jakie ja już te 5+ lat temu robiłem.

Ale właśnie sprawdziłem, że takie coś przechodzi:

unsigned int a=0x00112233;
unsigned short b=0x4455;
unsigned short c=0x6677;
unsigned char d[8]={0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0xFF};

GUID g= {a,b,c,{d[0],d[1],d[2],d[3],d[4],d[5],d[6],d[7]}};

Dlaczego ten dziadowski GUID, który w sumie jest przecież ciągiem
bajtów, jest definiowany w taki dziwny sposób to dla mnie zagadka.

Pamiętam, że wtedy próbowałem podawać dane inaczej (może jest inny
konstruktor), ale nie trafiłem w nic sensownego.

To w sumie oznacza, że mógłbym jako parametr konstruktora podać ciąg
bajtów zapisany jako łańcuch (bo inaczej to chyba nie da się (w moim
Builderze) wpisać od razu w linijce).
W konstruktorze klasy bazowej musiałbym to korzystając z tej metody
zamienić na GUID i przypisać tę wartość zmiennej w tej klasie bazowej
(ale raczej po prostu GUID a nie referencji do GUID).

A może bardziej zgodne z defaultową postacią zapisu tych GUID będzie
jakby konstruktorowi klasy bazowej dać 4 zmienne (dword,word,word,byte*).
Zakładam, że da się wpisać (byte*)".....". Jak nie to ostatni parametr
char*.
byte, word, dword to moje typedef stosowane we wszystkich programach.

To chyba jest metoda, aby uzyskać mniej więcej to co chciałem.
Sprawdzę jak zadziała i może przerobię wszystko, co w tym temacie mam
napisane, ale zdecydowanie nie teraz.

> Wątpie. Builder nigdy nie był specjalnie nowoczesny

Możliwe, ale chodzi mi po głowie, że jakieś rzeczy, które oni wcześniej
zrobili widziałem gdzieś jako nowość w C++11.
Nie pamiętam o co chodziło - po prostu zapamiętałem zdziwienie, że
czytam, że coś jest nowe, gdy ja to już od dawna znam.
P.G.

do góry

W dniu 2022-07-26 o 13:53, Piotr Gałka pisze:
> jakby konstruktorowi klasy bazowej dać 4 zmienne (dword,word,word,byte*).

A może zamiast byte* jednak dać tam 8 pojedynczych bajtów.
Po co oszczędzać na liczbie parametrów - powinny wylądować ciurkiem na
stosie. Ale komputer 64 bitowy obrabiając bajty chyba dużo kombinuje.
Zaczynam się skłaniać do podania 4 liczb dword.
Ale i tak będę musiał z tego powydzielać bajty do tej nieszczęsnej
definicji GUID czyli i tak robotę z pojedynczymi bajtami mu zapewnię to
może jednak zostawić tak, aby wyglądało podobnie do standardu - czyli
(dword,word,word,byte,byte,byte,byte,byte,byte,byte,
byte).
P.G.

do góry

On 26/07/2022 13:53, Piotr Gałka wrote:
> W obu ostatnich przypadkach: Error: Cannot cast from 'int' to '_GUID'.

Jesteś pewny tego "_" ?

Ogólnie kod zachowuje sie, jak gdyby GUID nie miał konstruktora
przyjmującego cokolwiek, poza konstruktorem kopiującym, stworzonym
automatycznie.

do góry

W dniu 2022-07-26 o 14:55, heby pisze:
> On 26/07/2022 13:53, Piotr Gałka wrote:
>> W obu ostatnich przypadkach: Error: Cannot cast from 'int' to '_GUID'.
>
> Jesteś pewny tego "_" ?

Taki jest komunikat.

Ogólnie to chyba kiedyś dawno czytałem, że Builder do wielu
identyfikatorów dodaje sobie z przodu '_'. Być może to było jak kiedyś
mi coś pisałeś jak zrobić bibliotekę. Może wtedy się okazywało, że jak
ja nazywam jakąś funkcję ala to ona przez innych musi być wołana jako
_ala. Było jakieś uzasadnienie, ale nie pamiętam.
A może ten GUID to jakieś makro i tak faktycznie głębiej jest _GUID a
kompilator po rozwinięciu makr zna już tylko _GUID.

> Ogólnie kod zachowuje sie, jak gdyby GUID nie miał konstruktora
> przyjmującego cokolwiek, poza konstruktorem kopiującym, stworzonym
> automatycznie.

Ja zakładałem, że to raczej struktura niż klasa, tylko, że w C++ to się
prawie niczym nie różni. Nie chciało mi się szukać po windows.h bo to
jest zazwyczaj mało czytelne dla mnie.

Ale skoro mogę wpisać
GUID{dword,word,word{byte,byte,byte,byte,byte,byte,b
yte,byte}} to
pasowało by chyba do struct zawierającej te dane w takich rozmiarach i
takiej kolejności, a kopiowanie dla struktur to nawet w C było jak w
ogóle słowo konstruktor w odniesieniu do języka nie istniało dla mnie.
P.G.

do góry

W dniu 2022-07-21 o 16:41, heby pisze:

>> Na razie o ile wiem to według brata przykład USB na załatwienie
>> prostej rzeczy zabiera 10x za dużo miejsca i nie zostaje miejsca na
>> naszą aplikację, a chcemy się zmieścić w 1/2 flasha z powodu upgrade'ów.
>
> Gcc ma flagę -Os? Symbole debugowe wyłaczone w docelowej binarce?
>
> Raczej nie dam wiary, że jest tak źle. Prosty kod usb UARTa na STM32
> zajmował jakies kilobajty. Ba, w małym AVR potrafili to zmieścić, z
> softwareową emulacją.

Odgrzebię starą wypowiedź bo małe! co nieco mogę powiedzieć.
Z tą objętością to pewnie przesadziłem.
Nie wiem co to flaga -0s
Make ostatnio używałem z Turbo C++ 1.0 w okolicy 1990. Od tamtej pory
używam po prostu środowiska więc nie znam żadnych flag.

Dziś brat trochę mi opowiedział o tym przykładzie USB który ma z jakimś
ich systemem uruchomieniowym. To jest przykład, ale to wygląda jakby
stosowany zestaw funkcji miał być (według słów brata olbrzymią)
biblioteką do obsługi USB w tych procesorach.

To co mogę powiedzieć jest trochę jak głuchy telefon bo wiem, że choć ma
się jakieś wyrobione zdanie trudno jest czasami wszystko wyłożyć komuś
(czyli mi) kto nie zna szczegółów. Mówi się wtedy tylko o prostych
najważniejszych rzeczach i wiele szczegółów ginie.

Mówił mniej więcej tak:
Jakoś w końcu udało mi się przebić przez ten przykład. Wreszcie mi to
zadziałało - urządzenie zgłasza się jako nasze. Tylko tyle tam mi śmieci
zostało z tego co oni napisali...
Nie uwierzysz jak idiotycznie to jest napisane. Po pierwsze wszystko
robią w przerwaniach. Kto to widział. Przerwanie powinno być krótkie, a
nie że jak się zaczyna to końca nie widać. Całe ramki analizują w
przerwaniach. Na dokładkę na cały czas przerwania blokują wszystkie
inne. No jak takie coś ma potem w ogóle działać.
Jest taki endpoint kontrolny do którego przychodzą tylko ramki
sterujące. Jest ramka z danymi z którymi trzeba coś zrobić i jest ramka
na którą ja mam odpowiedzieć. Jak odpowiem to mam dostać potwierdzenie w
postaci pustej ramki. Wyobraź sobie, że oni jak wyślą te dane to
przestawiają cały endpoint kontrolny na odbiór zwykłych ramek (a
przecież do enpointa kontrolnego takie ramki nie mogą w ogóle trafiać) i
w ten sposób odbierają tę pustą ramkę i potem znowu przestawiają
wszystko na odbiór ramek sterujących bo może taka się zdarzy.
Zapytałem, a czy muszą się przestawiać:
Nie w życiu. Tę pustą ramkę swobodnie odbieram bez przestawiania
czegokolwiek. Program jest tak pisany jakby było wiadomo, że teraz ma
przyjść akurat ta pusta ramka. A jak nie dotrze to będzie to wisiało bo
się nie przestawi na ramki sterujące. Przecież tak nie może program
wyglądać. I potem ktoś się wzoruje na czymś takim i mamy jak mamy.
Ja: Jak przestawiony na normalne to kontrolnych nie odbierze?
Nie odbierze.

To był trochę przycinek do mnie, bo moje programy na PC komunikujące się
z naszymi urządzeniami ja tak piszę, że czekam na to co wiem, że ma
przyjść i jak jest coś innego to wywalam błąd. Brat w ogóle nie
akceptuje takiego podejścia i nie omieszka mi tego zawsze wytknąć.
Podobno ratuje mnie tylko to, że moje programiki to są do prostych
operacji z naszymi urządzeniami i jak się coś wysypie to można
powtórzyć. Ale ja uważam, że skoro ja rządzę na łączu to mogę zakładać,
że wszyscy się podporządkują.
Według niego nie można nigdy czekać na to co się wię, że ma przyjść i
nie wiedzieć co zrobić z nieoczekiwanymi ramkami i co zrobić jak się nie
doczekamy (ja w niektórych sytuacjach je celowo gubię i czekam (z
timeoutem) na tę jedną jedyną co wiem, że ma przyjść).
Zawsze trzeba być przygotowanym na wszystko bo może na łącze dostanie
się wcześniej jakaś inna ramka.
To jego podejście chyba głównie jest kopiowaniem podejścia z RS485 gdzie
kompletnie nie wiadomo co przyjdzie, czy do mnie, czy w ogóle inni
rozmawiają, czy może zderzenie ramek. I urządzenie ma w każdej chwili
wiedzieć (czyli tyle co przerwanie na zbocze - a w sensie całej szyny
RS485 najdalej po czasie propagacji zbocza - około 10us), że linia jest
zajęta i jak się ma chęć coś nadać to trzeba poczekać na koniec czyjejś
transmisji.
To wynika z tego, że my na RS485 nie stosujemy odpytywania tylko każdy,
kto coś ma do nadania nadaje. Informacje są przekazywane prawie
najszybciej jak się da. Minimalne przerwy na łączu wynikają z dodawania
losowych opóźnień aby jak dwaj wejdą na raz to przy następnym razie już
jeden był wcześniej od drugiego.
P.G.

do góry