Bo to statyczny polmirfizm. Masz abstrakcyjną klasę ModBus, która nie musi wiedzieć z jakiego UARTu i na jakim cpu będzie korzystać. Dowiaduje się w momencie specjalizacji szablonu, podczas kompilacji, gdzie nastepuje konkretyzacjia wszyskiego, na stałe. Dlatego statyczny.
Ah, czyli czepiasz się definicji? Tak, konfiguracja sprzętowa jest
*polimorficzna*, bo masz kilka klas realizujących na rózne sposoby ten sam interfejs hardwareowy.
Tak jak abstrakcja ModBus wyabstrahowana od konkretnego UARTu.
No patrz, moje wszystkie klasy UART mają metodę "sendChar( char c);
Taa i potem piszesz sobie program z wieloma przypisaniami do zmiennej i warunkami a kompilator dojdzie do wniosku że ona wynikowo będzie miała np 0 i możesz w d.. pocałowac, jedynie volatile ratuje przed szaleństwem kompilatora, tu pewnie nawet to nie pomoże :)
Co do Protela to wydawało mi się, że Protel3 który mamy nie był aż tak przeładowany jak Protel 98 bo coś tam bardzo pozmieniali z plikami wtedy, ale Protela 98 praktycznie nie znam.
To co miałem na myśli na pewno brakowało w V5. W V6 z tego co mi się obiło to możliwe, że się da jakoś zrobić dopisując swoje regułki w formie nie wiem jak to nazwać - pseudokodu. Tego typu rozwiązanie uważam za nie całkiem rozwiązane bo człowiek pisząc ten kod musi trochę wiedzieć jak to zapisać. Jak nawet to się uda to jak będzie taka potrzeba za dwa lata to od nowa wyszukiwanie przykładów, ich analizowanie i ogarnianie. A powinno się wszystko dać zrobić na zasadzie wybierania z menu bez żadnych wątpliwości.
Chodzi mi o sprecyzowanie wymagań clearance dla np. izolowanego RS485 (bo mam takie potrzeby).
W Protelu 3 mogłem to zrobić tak:
- definiuję klasę netów (IZO) i wkładam do niej wszystkie po stronie izolowanej,
- w regułach produkcyjnych dodaję jedną regułę o clearance, - określam (wybór z menu), że pierwszym obiektem jest klasa netów, - według tego co wybrałem pojawia się możliwość wyboru - wybieram klasę IZO, - określam (wybór z menu), że drugim obiektem jest też klasa netów, - z menu wybieram default (nie pamiętam jak to tam zwał). - ustalam, że clearance ma być 3mm.
I działa - pozwala ścieżkom izolowanej części być między sobą blisko, ale nie pozwala zbliżyć się do pozostałych ścieżek na płytce.
W KiCadzie V5 nie dało się tego dlatego, że clearance można było przypisać do klasy netów a nie między klasami. Jak do klasy IZO przypisałbym 3mm to one między sobą też chciały utrzymywać 3mm.
Inne co mi brakowało, ale daje się to uzyskać inaczej to klasy footprintów W Protelu zawsze dzieliłem elementy na Big, Medium, pozostałe. Dla big w regułach produkcyjnych ustawiałem, że podłączenie do filled zone przez 4 odcinki o szerokości 30 mils, dla średnich 20 mils, a dla pozostałych 10 mils.
W KiCadzie nie mogę tego tak łatwo definiować na etapie projektowania płytki. Zrobiłem to wpisując na stałe te szerokości podłączeń do definicji footprintów i jest do przyjęcia.
Ogólnie na etapie V4 uważałem, że KiCad jest porównywalny z tym Protelem
3 i dlatego postanowiłem się przenieść. V5 już uważałem za lepszy. W V5 najbardziej mi brakowało (z mojego starego Protela) możliwości określenia kolorów linii połączeń i ukrycia linii GND bo to są dla mnie połączenia, których nie muszę zrobić więc strasznie utrudniają przy rozmieszczaniu myślenie jak rozplączę te połączenia. P.G.
Nie całkiem. Teraz rozmawiamy o embedded pod hasłem mój brat to robi. Kiedyś pisał wszystko w assemblerze. Naście lat temu dał się przekonać do C, ale nadal w naszych (jako firmy, jego, jako autora) programach są spore kawałki w assemblerze. Np. SHA256 w tym AtXmega zabrało mu praktycznie wszystkie rejestry. W C się nie da, bo C ileś tam rejestrów blokuje na swoje potrzeby. Zapisane w C działało wielokrotnie wolniej (konieczność ciągłego przerzucania danych między rejestrami a RAMem). Jakaś biblioteka, którą gdzieś znalazł też działała wyraźnie wolniej.
Ale ja nic nigdy nie napisałem embedded. C++ uczyłem się z książki Stroustrupa z 1991 roku. Mam ksero oryginału. Potem kupiłem polskie wydanie (1994,1995). Na bazie przykładów z książki napisałem Makroassembler 8051, który potem brat używał do wszystkiego. Dlatego jak bym się uparł to template może być dla mnie, ale nie mam na razie powodu się upierać. P.G.
On 19/07/2022 18:35, Janusz wrote: > Ale na avr-ze to nie pójdzie bo ten procek nie wykonuje programu z ram-u > (architektura Harvard) więc żadnej kopi nie uruchomi.
Tutaj masz dwa przykłady napisne przed chwilą na kolanie:
Polimorfizm statyczny:
formatting link
A tu dynamiczny:
formatting link
Oba migają diodą jak szalone, na moim Harvardowym Arduino z biednym AVRkiem. Co mogę mieć źle, że mam dobrze?
Nie rozumiem dlaczego napisałeś, że najważniejsze. Czy STM32UART0, AtmegSoftwarUartImpl i UartMock to pochodne _HardwreUartImplementation ?
Z innej wypowiedzi zrozumiałem, że virtual w ogóle nie da się jak kod jest wykonywany z flasha. Ale nie wiem czy na pewno. Przecież zestaw wskaźników na funkcje wirtualne danej klasy może być w flashu. Obiekt danej klasy znajdujący się w RAMie może mieć wskaźnik na tę tabelkę wskaźników więc może wywołać odpowiednią dla siebie funkcję. Jak nawet wywołamy według wskaźnika na obiekt to też sobie to znajdzie.
O includowaniu pisałem jako właśnie o złym rozwiązaniu w sytuacji, gdy próbujemy dynamicznego polimorfizmu
Temat C++11 pojawił się w temacie mojego popróbowania innych nowych możliwości C++.
A statyczny polimorfizm jest w temacie embedded a tam są środowiska dostarczane przez producentów procków więc pewnie bardziej aktualne.
Czyli powinienem teraz przekonać brata do C++ koniecznie z templates. Będzie trudno :)
Dokładnie.
Niektóre moje programy trafiają do naszych klientów. Ogólnie to wziąłem się za tę komunikację UDP bo pracowanik, który pisze dla nas (tysiące razy poważniejsze programu od moich) twierdził, że to co my kombinujemy nie ma sensu i w ogóle 'nie da się'. Zamiast walczyć z jego przekonaniami postanowiliśmy, że w takim przypadku trzeba to zrobić samemu. Problem nie był w komunikacji tylko w postawionej według niego na głowie konfiguracji sprzętu co my uważaliśmy za najlepsze rozwiązanie i nadal tak uważamy.
Nie znam. Chciałbym poznać. Nie mam czasu. Poprawiłem raz skrypt w Pythonie do generowanie BOM w KiCadzie. Już mało pamiętam. Dodałem wywołanie jakiejś funkcji, która przy okazji wołała po raz drugi jakąś funkcję Sort. Z tym, że jedno z tych wywołań było jakby Sort to była funkcja klasy a drugi raz jakby to była funkcja globalna ale wołana z tą samą klasą jako parametrem.
Co mnie totalnie zdziwiło. Jak była tylko oryginalna postać tego skryptu to sortowało 'nie do końca' a jak doszedł ten drugi Sort (którego wcale nie chciałem tam wkładać, po prostu był w czymś co chciałem dołożyć) to się okazało, że już sortuje 'do końca'. Tych moich zmian nie ma dużo jakbyś chciał to mogę służyć oryginałem i moją wersją.
Olałem to, że coś się robi dwa razy - nie jestem w stanie stwierdzić dlaczego już jest dobrze, ale jest dobrze. Jeszcze nie doszedłem do tego tematu w przypadku V6. Mam nadzieję, że obejdzie się bez zaglądania.
Przyjmuję do wiadomości i cieszę się, że jak na moje skromne potrzeby RAD się sprawdził.
Bo testowanie własnego kodu invitro, unittestami, jest waznym etapem pisania jakiegokolwiek kodu, z miganiem diodą włacznie.
W templates "nie muszą być pochodne". Zgodnośc interfejsu badana jest podczas wypełniania szablonu. Jeśli tylko jakaś klasa ma metodę foo() i ktoś chce ją zawołać w momencie specjalizacji szablonem, to zadziała. W dynamicznym polimorfizmie musisz dodawać wartwę interfejsu z metodami wirtualnymi. W statycznym nie. Można by powiedzieć, że statyczny polimorfizm bazuje na "opóźnionej kompilacji, do ostatniej chwili, kiedy już wszystki wiadomo"
Bzdura. Stosowny przykład podałem kilka postów wyżej.
Bo to bzdura. Wirtualizacja działa na praktycznie wszyskich procesorach, od 6502 po współczesne. Jeśli gdzies nie działa, to będzie jakiś wyjątkowy wyjątek.
Dynamiczny jest w embedded troche niepotrzebny. On jest przydatny kiedy programujemy obiektowo. W malym embedded potrzeba obiektowości jest sporadyczna.
Jesteś ograniczony i tak Builderem oraz bratem używającym z niechęcią C. Wątpie, aby cokolwiek z C++11 miało jakąkolwiek wartość przed RAII czy szablonami. Nie warto. No może dla "auto" warto.
Nie widuję. Statyczny polimorfizm stosowany jest w niektórych biblitekach Arduino. Został zaakceptowany przez środowisko embedded tylko dlatego, że nikt głośno nie powiedział, że to C++. Jak by powiedział, to od razu by się obrazili, jak Janusz. Teraz muszą używac, nie ma odwrotu. Pękło bredzenie o tym, jak to C++ się nie nadaje do embedded.
Nie. Za późno. Jesli mysli asemblerem, to nie przekonasz. Nie próbuj nawet. Jesli robi dobrze to, co robi, to niech robi, to co robi.
To taka dysputa teoretyczna. Przecież obaj wiemy, że nie będziesz zmieniał przyzwyczajeń bez powodów.
Prawidłowo: ewoluować. To białko ma się dostosować do zmian w komputerach, a nie odwrotnie.
Jasne i potem siada świeżak ( albo autor po paru latach) do takiego kodu i pół godziny się zastanawia co k@#$a autor miał na myśli pisząc taki kod. Idź sie topić razem z tymi przykładami.
A w jaki sposób z tego co napisałeś wynika, że to dotyczy testowania własnego kodu. Dla mnie to były po prostu trzy wersje użycia tego template dla trzech różnych klas. Co takiego szczególnego ma w sobie ta trzecia nazwa?
Czyli to co jest wymagane to aby każda z tych klas miała te funkcje które zostaną użyte w template. Poza tym każda może mieć dodatkowo inny zestaw funkcji - to nie robi.
Niechęć to była lata temu. Teraz już lubi C. On po prostu uważał, że ważny jest algorytm, a zapisać go już można w dowolnym języku. Panuje nad znacznie bardziej skomplikowaną rzeczywistością w tych urządzeniach niż ja. Jak coś chce ze mną uzgodnić to czasem kilka godzin schodzi na to abym wyrobił sobie obraz sytuacji w której trzeba ustalić jak coś robimy. A sytuacja to bardzo drobniutki fragment całości ogarnianej przez te urządzenia.
Właśnie "auto" mi się podobało i nie wiem jak się to nazywa, ale takie tworzenie w locie (w jednej linijce) klasy z jakąś jedną funkcją (może konstruktorem) co się okazało z jakiegoś powodu było często potrzebne i wprowadzono nowy sposób zapisu tego w kodzie źródłowym.
A myślałem, że jak dostarczają środowisko to tam z definicji będzie można pisać w C++.
Kiedy Ty od czasu do czasu piszesz o zabetonowanych środowiskach siedzących w swoim grajdołku z ubiegłego wieku. P.G.
Się wydaje oczywiste. Aż niemożliwe, aby tego nie spróbował. Niestety to nie ja. Mogę tylko gdybać. Może kompilator nie pozwalał grzebać w 'swoich rejestrach'. Może to gdzieś trzeba było odblokować, ale że to były pierwsze podejścia do C to nie wiedział. A może po prostu coś mi się pomieszało. P.G.
vialtile używane jest tylk ow sytuacji, kiedy *coś* może zmienić zawartość zmiennej *nieoczekiwanie*.
Takie sytuacje to:
Inny wątek.
Przerwanie.
Rejestr sprzętowy.
Tylko w jednej sytuacji z tej listy używamy volatile. W dwóch używamy barier. Istnieją mikroskopije architektury, w których nie ma barier, ale teraz nawet miganie diodami robi się na ARMach.
Jeśli wyoptymalizowało Ci kod, który korzysta ze zmiennej i "naprawiłeś" to przez delklarację volatile, to masz naprawdę nikłe pojęcie o tym, jak pracuje kompilator i gdzie jest przyczyna niedziałania.
Nie przejmuj się, mnie też nie przekonał ani on ani poprzednicy, jak pracujesz sam nad kodem to i sam sobie panujesz nad kolejnymi wersjami. Co innego praca zespołowa i chyba głównie w takiej pracy sie to uzywa, ale dla np mnie jest strasznie upierdliwe.
Dostaniesz taką kaszkę mannę że tydzień będziesz dochodził co jest gdzie :)
Magiczne zaklęcie znane każdemu, kto kiedykolwiek słyszał o unit testach. Zawsze podaje taki przykład, aby każdy sobie uzmysłowił, że
*zawsze* masz co najmniej dwie klasy do takiego szablonu: rzeczywistą i testujacą.
To nie jest takie trywialne. Powiedzmy, że mniej więcej.
Może. Tak samo w dynamicznym może.
Można pisac w C jak w asemblerze ;) To może było złudzenie z tym lubieniem :P
Tak też kiedyś myślano. Obecnie mysli się inaczej: ważne jest wyrażenie, co chcesz uzyskać, aby kompilator dobrał optymalny kod.
Tak właśnie działa C++: tam bardziej określasz co chcesz, a nie jak chcesz.
Lambda. Niestety lambda w embedded, w restrykcjch związanych ze stosem, może być lekko nieciekawa, jesli użyjesz jej bezmyslnie. Choć bardzo często kompilator usuwa lambdę i generuje kod optymalnie. Ogólnie należy byc ostrożnym. Pod spodem dzieje się sporo dziwnych rzeczy.
Raczej nie. C++ w embedded musi się rozpychać w lasie ignorancji. Naprawdę dużo dobrego zrobiło Arduino, że tylnymi drzwiami wprowadzono C++. Okaząło się że nie gryzie, działa i to na 8-bit procesorach. Magia. A miało wybuchać.
Jesli ktoś ma warsztat który działa, to bym go nie zmieniał.
Rzecz nie w tym, aby zrobić rewolucję, rzecz w tym, aby sobie zdawać sprawę, że można lepiej. I być może kiedyś małymi krokami dojśc do tego "lepiej" w praktyce.
Problemem jest postrzeganie "lepiej" jako "gorzej" bo jest poza strefą komfortu. I z tym walczę. Również u siebie.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.