-
161. Data: 2022-07-19 15:00:30
Temat: Re: Rynek pracy STM32
Od: Piotr Gałka <p...@c...pl>
W dniu 2022-07-19 o 14:48, heby pisze:
> On 19/07/2022 14:18, Cezar wrote:
>> Oczywiście, główną własnością schematu (poza jego poprawnością) jest
>> jego czytelność więc trzeba by mieć wielką wyobraźnię żeby go "napisać"
>
> Jeśli "napiszesz" schemat, to istnieje spore prawdopodobieństwo, że
> pojawią się bloki funkcjonalne, hierarchicznie. A jeśli tak, to
> zrozumienie działania nie wymaga gapienia się w kreski na schemacie a
> jedynie na połączenia w kodzie źródłowym grubych bloków między sobą. To
> wcale nie jest bardzo trudne, programiści robią to od dawna.
Ale schemat jest pod pewnymi względami mało hierarchiczny.
Jak do programu dołożysz wewnątrz procedur wiele różnych goto gdzieś do
wnętrza innej procedury to program przestanie być czytelny.
P.G.
-
162. Data: 2022-07-19 15:07:07
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 19/07/2022 14:54, Piotr Gałka wrote:
> Pytanie wzięło się stąd, że napisałeś, że jak jest taka kontrola wersji
> to nie będzie pytania: Jak on TO do cholery kompilował.
Nie będzie. Wszystkie możliwe narzędzia, opcje, wyjątki itp sa w kodzie.
Rownież, jesli robisz to porządnie, to same polecenia wystartowania
kompilacji z odpowiednimi ifdefami będzie tamteż dostępne, w kontekście
hardware które budujesz. Więc nie tylko nie ma mowy o pomyłkach ale
można to środowisko odtworzyć po latach bez zmian.
Wiec nie, choć trochę tak.
Kwestia higieny.
>> A w celu redukcji #ifdef, można by się zainteresować statycznym
>> polimorfizmem. Ale to już cieżki C++.
> On jest na etapie C.
Nie ma takiego eatpu. Jeśli jesteś w C to jesteś też na początku C++.
Niech zacznie od zmiany kompilatoa z gcc na g++ i nazwy kliku z foo.c na
foo.cpp i już koniec tranzycji na C++. Reszta to darmowy obiad.
> Ale stosuje go jakoś inaczej niż mi by przyszło do głowy. Ma na przykład
> w każdym projekcie plik h o jednej wspólnej nazwie i wczytuje go we
> wszystkich plikach c używanych w wielu projektach. W ten sposób te pliki
> (jakby biblioteczne) generują dla każdego projektu inny obj.
Czyli emuluje templates z C++ używając sztuczek z inkludowaniem.
To jest ogólnie niebezpieczne jak jasna cholera. W większych projaktach
takie rzeczy są zabronone. Po pierwsze dlatego, że są trudne w
utrzymaniu, po drugie dlatego, że od tego są templates w C++.
Każdy programista C wynajduje po latach kwadratowe koła tego typu,
broniąc się przez przejściem do C++ gdzie statyczny polimorfizm jest
częścią jezyka.
> Ja jestem na etapie C++ (ale Ty nazwiesz to C z klasami). Kupiłem kilka
> lat temu książkę Stroustrupa i trochę poczytałem, ale kompilator,
> którego głównie używam (Builder 5) nie ma nawet tego co jest w C++11.
Nie używaj więc Buildera. Nikt tego nie sprawdza.
> A wiedza nie używana wylatuje, więc wszystko co tam wyczytałem mi
> wyleciało.
Tak jak mówiłem, nie czytaj instrukcji ;)
-
163. Data: 2022-07-19 15:08:25
Temat: Re: Rynek pracy STM32
Od: "Grzegorz Niemirowski" <g...@g...net>
Mateusz Viste <m...@x...invalid> napisał(a):
> Tylko po co? Tzn. jeśli zarządzasz lub bierzesz udział w projekcie z
> setkami rozproszonych programistów... no to może mieć jakiś sens. W
> przeciwnym razie svn jest dużo trafniejszą opcją, bo w pełni
> scentralizowaną i łatwiejszą w codziennej obsłudze.
> Mateusz
Niby tak. Z drugiej strony jak we wszystkich pracach mam gita oraz w
projektach Open Source, do których czasem coś dopisuję, to nawet dla samego
siebie użyłem git zamiast przypominać sobie SVN po 15 latach od ostatniego
użycia.
--
Grzegorz Niemirowski
https://www.grzegorz.net/
-
164. Data: 2022-07-19 15:09:22
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 19/07/2022 15:00, Piotr Gałka wrote:
>> Jeśli "napiszesz" schemat, to istnieje spore prawdopodobieństwo, że
>> pojawią się bloki funkcjonalne, hierarchicznie. A jeśli tak, to
>> zrozumienie działania nie wymaga gapienia się w kreski na schemacie a
>> jedynie na połączenia w kodzie źródłowym grubych bloków między sobą.
>> To wcale nie jest bardzo trudne, programiści robią to od dawna.
> Ale schemat jest pod pewnymi względami mało hierarchiczny.
Opisany w języku VHDL/Verilog jest *skrajnie* hierarchiczny. Tam
wszystko w zasadzie jest podporządkowane hierarchi.
Używanie takiego języka wlaśnie wymusza porządek. Schemat to zazwyczaj
płaski zbiór kresek, gdzie bloki funkcjonalne trzeba wydłubywać gapiąc
się pół godziny, a w *HDL masz je ładnie nazwane.
> Jak do programu dołożysz wewnątrz procedur wiele różnych goto gdzieś do
> wnętrza innej procedury to program przestanie być czytelny.
To nie używaj goto ;) Proste.
-
165. Data: 2022-07-19 15:14:46
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 19/07/2022 15:08, Grzegorz Niemirowski wrote:
>> Tylko po co? Tzn. jeśli zarządzasz lub bierzesz udział w projekcie z
>> setkami rozproszonych programistów... no to może mieć jakiś sens. W
>> przeciwnym razie svn jest dużo trafniejszą opcją, bo w pełni
>> scentralizowaną i łatwiejszą w codziennej obsłudze.
>> Mateusz
> Niby tak. Z drugiej strony jak we wszystkich pracach mam gita oraz w
> projektach Open Source, do których czasem coś dopisuję, to nawet dla
> samego siebie użyłem git zamiast przypominać sobie SVN po 15 latach od
> ostatniego użycia.
Mimo to, jeśli ktoś ma startować z tematem od zera, svn będzie
nieskończenie bardziej intuicyjny niż git.
-
166. Data: 2022-07-19 15:25:02
Temat: Re: Rynek pracy STM32
Od: Piotr Gałka <p...@c...pl>
W dniu 2022-07-19 o 14:58, heby pisze:
>> Sądzę, że jeszcze trochę potrwa zanim powiesz programowi, że płytka
>> będzie w obudowie nie ekranowanej a mimo ma spełnić taką a taką normę
>> EMC i on już się tym zajmie.
>
> ASICe "same się routują". Czemu PCB nie miałyby? Przynajmniej częściowo.
> Wrzucasz komponenty krytyczne a reszta drobicy sam się gdzieś wciśnie.
Napisałem 'jeszcze trochę' a nie 'jeszcze długo'.
Jak projektuję PCB to 90% roboty to jest rozmieszczenie elementów.
Ale ja sobie tę robotę robię bo nie chce mi się przerzucić na 4 warstwy,
a na 2 warstwowej wymagam aby 100% bottom było GND. Więc (poza GND)
wychodzi mi projekt jednowarstwowy i rozplątanie tego (takie położenie,
aby dla każdego połączenia przewidzieć drogę którędy pójdzie) zajmuje
najwięcej czasu. Potem pociągnięcie ścieżek to już po prostu realizacja
tego, co się brało pod uwagę przy rozmieszczaniu.
> Nie o szybkosc pracy chodzi, ale o intuicyjność. Te same operacje w CAD
> oznaczają coś innego niż w resztcie świata. Sama selekcja w
> KiCAD/Eagle/Protel jest zupełnie inna, nieintuicyjna, a to dopiero
> początek przygody.
Jestem bardziej przyzwyczajony do Protela i KiCada niż do tej reszty
więc szybciej uznam, że to tam jest nieintuicyjnie.
Ale nie kojarzę na czym polega ta odmienność przy selekcji.
> Głupie usunięcie routingu ścieżek zajmuje mi w KiCADdzie zazwyczaj koło
> 5 minut szukania. Za każdym razem po miesięcznej przerwie. To jest tak
> nieintuicyjnie, że niemożliwe do zapamiętania w mięśniach od klikania.
Nie kojarzę problemu.
W Protelu 3 była łatwa możliwość Unroute całej płytki, ale nie używam go
już od 5 lat.
Modyfikacja ścieżek była ciężka, dlatego najłatwiej było usunąć i
narysować od nowa. Jak pamiętam była tam taka dla mnie bardzo fajna
rzecz - każdą operację dawało się rozszerzyć na inne elementy wybierane
według określanego w danym momencie klucza (bardzo szeroka gama możliwości).
W KiCadzie chyba faktycznie trudniej jest usuwać ścieżki. Ale mnie to
raczej nie boli, bo jest z kolei duża łatwość ich modyfikacji - to jest
miodzio jak to działa. Jeden gość mocno aktywny na forum KiCada pisze,
że on w ogóle nie zwraca uwagi jak się mu ścieżki prowadzą. Jak wszystko
jest połączone to potem je przesuwa tak aby było tak jak mu pasuje.
Ja się jeszcze aż do tego stopnia nie przełamałem i czasem wojuję z
KiCadem aby poprowadził dokładnie tak jak ja chcę a on szczególnie przy
podłączaniu do padów ma jakieś swoje widzimisię. Ale piszę o V5, bo pod
V6 na razie zaprojektowałem 0 płytek.
P.G.
-
167. Data: 2022-07-19 15:29:34
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 19/07/2022 15:25, Piotr Gałka wrote:
> Jestem bardziej przyzwyczajony do Protela i KiCada niż do tej reszty
> więc szybciej uznam, że to tam jest nieintuicyjnie.
> Ale nie kojarzę na czym polega ta odmienność przy selekcji.
Zaznaczanie ramką *zazwyczaj* zamiast zaznaczać, ciągnie mi elementy już
zaznaczone lub wykonuje inne akcje.
-
168. Data: 2022-07-19 15:43:02
Temat: Re: Rynek pracy STM32
Od: Piotr Gałka <p...@c...pl>
W dniu 2022-07-19 o 15:07, heby pisze:
>> Ale stosuje go jakoś inaczej niż mi by przyszło do głowy. Ma na
>> przykład w każdym projekcie plik h o jednej wspólnej nazwie i wczytuje
>> go we wszystkich plikach c używanych w wielu projektach. W ten sposób
>> te pliki (jakby biblioteczne) generują dla każdego projektu inny obj.
>
> Czyli emuluje templates z C++ używając sztuczek z inkludowaniem.
Nigdy nie opanowałem templates, ale tak jak ja je sobie wyobrażam to
chyba to jest jednak coś innego.
U niego raczej chodzi o to, że w pliku jest na przykład komunikacja ze
scalakiem RFID. Ale to jak ona jest faktycznie realizowana zależy od
tego pliku h o wspólnej nazwie dla wszystkich projektów a tam jest
informacja jaki procesor i jak jest podłączony dla danej wersji płytki.
Funkcjonalność, która jest w danym projekcie niezbędna też pewnie jest w
tym pliku (czytamy tylko ID karty, czy pełna komunikacja z kartą Desfire.
Ale nie jestem pewien tego co piszę.
Ja (okolice 1990) emulowałem klasy za pomocą wskaźników na funkcje.
> To jest ogólnie niebezpieczne jak jasna cholera. W większych projaktach
> takie rzeczy są zabronone. Po pierwsze dlatego, że są trudne w
> utrzymaniu, po drugie dlatego, że od tego są templates w C++.
>
> Każdy programista C wynajduje po latach kwadratowe koła tego typu,
> broniąc się przez przejściem do C++ gdzie statyczny polimorfizm jest
> częścią jezyka.
Muszę poszukać co to hasło oznacza. Może wiem, tylko nie wiem, że tak
się nazywa.
> Nie używaj więc Buildera. Nikt tego nie sprawdza.
Nie rozumiem.
P.G.
-
169. Data: 2022-07-19 15:50:59
Temat: Re: Rynek pracy STM32
Od: Dawid Rutkowski <d...@w...pl>
wtorek, 19 lipca 2022 o 14:49:23 UTC+2 Mateusz Viste napisał(a):
> 2022-07-19 o 00:40 -0700, Dawid Rutkowski napisał:
> > A na serio wdrażam się do git (w wydaniu bitbucket) - "intuicyjne" to
> > nie jest, ale jak zobaczyłem w wiki, że napisał to w dwa dni/miesiąc
> > sam Linus Torvalds, to kredyt zaufania urósł niebotycznie.
> Tylko po co? Tzn. jeśli zarządzasz lub bierzesz udział w projekcie z
> setkami rozproszonych programistów... no to może mieć jakiś sens. W
> przeciwnym razie svn jest dużo trafniejszą opcją, bo w pełni
> scentralizowaną i łatwiejszą w codziennej obsłudze.
Klient ma i wymaga.
W skrócie firma oferuje "chmurowy" system czujników.
Nie wiem dokładnie, jak to sprzedają/fakturują, ale w każdym razie u klienta
umieszcza
się tylko czujniki (na ATmega) oraz "gatewaye" - bramki pomiędzy radiową siecią
czujników (xbee albo lora) a "internetem" - a wszystkie dane idą do serwerów firmy,
tam są przetwarzane i udostępniane przez przeglądarkę - nie ma czegoś takiego jak
"serwer u klienta".
No i używają gita - nie wiem, dlaczego git, a nie svn - i twierdzą, że cały system
chmurowy pięknie
tego używa - ale dla "projektów w C" - czy oprogramowania ATmeg w czujnikach - jakoś
nie daje rady się tego wdrożyć.
I rzeczywiście - póki co dla każdego z tych projektów jest tam tylko repozytorium
plików,
które można sobie pobrać i na lokalnym dysku rozpakować, żeby otworzyć w microchip
studio i skompilować.
Jak zaczęliśmy to oglądać to nawet udało się utworzyć branch - ale nie wiedzieliśmy,
w co kliknąć,
żeby w tym branchu podmienić pliki.
No bo chyba nie trzeba używać tylko wbudowanego w bitbucket edytora?
Wczoraj mieli u klienta pokazać koledze, jak to się robi.
Ale do takich cudów jak merge gałęzi to pewnie jeszcze daleko, nie wyobrażam sobie,
że to może dobrze działać,
ale może sam sobie życie utrudniam.
I zastanawiam się też, jak wyglądają pliki wynikowe takiego merge i jak się potem z
nimi pracuje?
Np. w takiej sytuacji - jest jakieś urządzenie produkowane i sprzedawane w jakimś tam
tempie,
na to tempo są robione zapasy magazynowe.
I nagle się okazuje, że przychodzi jakieś wielkie zamówienie.
Oczywiście sytuacja dodatkowa taka jak teraz - okazuje się, że producent używanego
dalmierza
nagle wprowadza nowy model, inaczej obsługiwany, nie można dokupić chipów
inklinometru (cokolwiek by to było;)
ale na szczęście jest jakiś inny - no i żeby było jeszcze ciekawiej, brakuje
mikrokontrolerów
dajmy na to to ATmega324P (i nie ma też innych ATmegaxx4 - no, może są ATmega164P,
ale programu nie zmniejszysz), ale można kupić ATmega3209, bo microchip ma taki
kaprys.
A wielkie zamówienie oczywiście musi być "na teraz".
No to zaczynasz produkcję z tego, co w magazynie tam jeszcze masz,
ale na hurra trzech programistów (bo szybko musi być) bierze się za robotę - jeden
opanowuje nowy dalmierz,
drugi inklinometr, a trzeci przerabia wszystko specyficznie dla ATmega324P na
ATmega3209 (mogłem
dla utrudnienia kazać zamienić ATmega324P na jakiegoś STMa, bo ATmeg nie ma w ogóle
;).
W miedzyczasie jakoś trzeba sobie testować to, co się pisze - a płytki tylko w dwóch
(ATmega324P, dalmierz A,
inklinometr A i ATmega3209, dalmierz B, inklinometr B) a nie w 8 wersjach.
Pomoże coś tutaj programowanie strukturalne - wróć - VCS - czy jednak potrzebny jest
talent?
Takie problemy też miałem, jak sobie założyłem, że program dla uC w unifonach do
systemu domofonowego będzie jeden,
niezależnie od tego, czy będzie to unifon ze słuchawką czy głośnomówiący oraz
niezależnie od tego,
z jakim systemem domofonowym będzie współpracował.
Problemy oczywiście wtedy, gdy po dłuższym czasie się okazuje, że pojawia się pomysł
na nową funkcję,
która ma być dodana do dawno wersji sprzętu, dla której dawno nie zmieniano programu
- albo,
co jeszcze lepsze, niemożliwa do zintegrowania z inną funkcją - albo też trzeba tą
zmianę zrobić
na działającym już od długiego czasu bezawaryjnie systemie (bo to jest problem, jak
coś działa,
a potem nagle zonk, to jest 100 razy głośniej niż jak ludzie są przyzwyczajeni, że
nie działa ;)
Dobrze, jeśli choć możesz dostać hexa, którymi programowano urządzenia na ten obiekt
- i potem
szukaj wersji plików, z których tego hexa skompilowano.
Albo najbliższych - a potem szukaj w hexie różnic i wymyślaj, co zmienić w źródle,
żeby tak samo się
kompilowało.
I jeszcze jedno.
Jest sobie SVN, będący podobno ulepszonym CVS, który był RCSem rozszerzonym o
projekty (i dlatego pewnie
nie był atomowy) - i jest git - no i jeszcze kilka innych systemów.
No ale są przynajmniej dwa. Dlaczego?
Czy jak Linux pisał gita to jeszcze nie było SVNu (bo jednym z założeń gita było -
rób odwrotnie jak w CVS)?
A potem git okazał się zbyt skomplikowany dla rzeczy dużo prostszych niż kernel
Linuxa - który i tak jedzie
na #ifdefach, bo inaczej i tak się nie da?
W takim razie czy SVN nie ma gdzieś szklanego sufitu, przy którym przestaje się
skalować?
Jak np. podobno (tfu) mssql który działa do 100k rekordów a potem się zatyka?
Ja z bazy (pgsql) usuwam co kilka miesięcy kilka milionów rekordów (a z drugiej
tabeli
kilkanaście - 8 razy więcej - bo ktoś przeklęty chyba się w głowę uderzył i wymyślił,
że jeśli w komunikacie, oprócz innych pól, jest 8 odchyłek od rozkładu jazdy,
to będzie "postaciowo-normalnie", że dla tych odchyłek zrobi osobną tabelę,
w której będzie wpisywał identyfikator komunikatu - spory string, numer odchyłki -
int,
oraz samą odchyłkę - bajt...).
Troszkę to trwa, na szczęście udało się wyszarpać opcję, aby komunikaty nie były
wpisywane
do tych tabel - więc nie ma konfliktu między delete+vacuum+reindex a insertami
i system może sobie na bieżąco działać.
Ostatnio wziąłem się za inną tabelę, nieruszaną od 2015, bo miała już 30GB - a index
drugie 30GB - tylko
że tu niestety nie ma takiej fajnej opcji - więc delete poszło, ale jak puściłem
vacuum,
to po pół godziny zadzwonili, że system nie działa ;>
A że jest praktycznie bezawaryjny (taaa, chyba że mam urlop - to najpierw podłączą
kamery jakieś i dadzą jednej z nich IP twojego serwera - całe szczęście, że udało się
podłączyć drugi
kabel, ale jak potem obserwowałem tcpdumpem, że serwer widzi pakiety ze swoim IP
i w ogóle na nie nie reaguje, to się mocno zastanawiałem, czy to mi covid rozwalił
mózg
czy powaliło Linuxowi kernel - ale w końcu przyszło mi na myśl, żeby zobaczyć, jakie
są MAC
w tych pakietach i sprawa się wyjaśniła - a potem znów dzwonią z rana że system
zdechł - a to gdzieś
prąd mignął i jakiś router wszedł w stan nieustalony - ciekawostką było, że na pingi
nie odpowiadał,
ale udało się go zdalnie zresetować - i może przez to wcześniej wydawało się, że
działa w porządku)
Ufff, dobrze, że to pgsql i można vacuum momentalnie scancelować.
Potem jeszcze szybko sprawdziłem, że przy reindex tak samo się blokuje.
Tak że drogie dzieci, nie naśladujcie wujka (Wujcia Wariatuńcia ;) i pamiętajcie -
nie testujemy na produkcji.
A jak nie chcecie mieć kłopotów z bazą danych, to bierzcie pgsql - tabela i index
mogą mieć po 30GB
i nie wpływa to na pracę systemu (chyba że się dysk zapcha).
Żeby ostatecznie dobić mssql to pani księgowa ma na nim niestety płatnika - i chyba
nigdy nie zapomnę
siedzenia nad jeziorem drugiego dnia urlopu i przypominania sobie kolejności
kliknięć, żeby ten
serwer uruchomić w sytuacji, kiedy z jakiegoś nieznanego powodu (dzieje sięto co
jakiś czas)
przestanie się uruchamiać przy starcie windows...
Oczywiście ten drugi dzień urlopu to był jakiś 8 czy 9 dzień miesiąca...
Więc mogło się mssqlowi odwidzieć już sporo wcześniej - ale płatnika zwykle używa się
raz w miesiącu.
-
170. Data: 2022-07-19 15:54:37
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 19/07/2022 15:43, Piotr Gałka wrote:
>> Czyli emuluje templates z C++ używając sztuczek z inkludowaniem.
> Nigdy nie opanowałem templates, ale tak jak ja je sobie wyobrażam to
> chyba to jest jednak coś innego.
> U niego raczej chodzi o to, że w pliku jest na przykład komunikacja ze
> scalakiem RFID. Ale to jak ona jest faktycznie realizowana zależy od
> tego pliku h o wspólnej nazwie dla wszystkich projektów a tam jest
> informacja jaki procesor i jak jest podłączony dla danej wersji płytki.
Tak. To statyczny polimorfizm. Wykonuje się go w C++ za pomocą
templates. Dokładnie tak jak opisujesz - umożliwia np. rozdzielenie
implementacji hardwareowej UART od kodu implementującego protokół bez
ani jednej nadmiarowej instrukcji asm.
To się też da zrobić dynamicznym polimorfizmem (polimorficzne klasy z
metodami wirtualnymi), ale ktoś może marudzić, że to zajmuje cenne cykle
zegarowe na indirect call. Dlatego istnieje też polimorfizm statyczny,
który nie generuje dodatkowego kodu.
> Ja (okolice 1990) emulowałem klasy za pomocą wskaźników na funkcje.
W '95 pisałem w SasC na Amidze kod C++. Wtedy był on w tle konwertowany
przez kompilator na goły C i dopiero kompilowany. Wtedy nikomu bym go
nie polecał, ale od tamtego czasu jednak troche się zmieniło. Obecnie
wiele technik pisania w C++ jest najzwyczajniej lepszych niż kwadratowe
koła wymyślane przez programistów C.
>> Nie używaj więc Buildera. Nikt tego nie sprawdza.
> Nie rozumiem.
Napisałeś, że nie możesz używać C++ bo używasz Buildera. A po co używac
Buildera?