W dniu 2022-07-18 o 22:11, heby pisze:

> Masz mozliwosć wysofania się z dowolnej poprawki, wliczając w to
> detalicznie pojedyncze linie, całe wrzuty, stan z konkretnego dnia,
> grupy plików, całe implementacje itd itp. Możesz w ułamku sekund
> przełaczyć się na źródła tydzień wstecz, coś sprawdzić, i wrócić do
> pracy na aktualnym stanie.

Opis możliwości bardzo mi się podoba. Ja nie piszę embedded tylko
czasami (bardzo czasami) coś na PC. Przypominam sobie tylko jeden raz
kiedy cofałem się do stanu z jakiegoś dnia przed kilku laty.
Podejrzewam, że CVS choć ma możliwości imponujące to chyba nigdy bym z
nich nie skorzystał.

> Dodatkowo pozwala Ci tworzyć osobne "sandboxy eksperymentalne" nazywane
> zazwyczaj branchami. Sprawdzasz coś, robisz przez 3 tygodnie i na koniec
> albo dobre (i mergujesz) albo złe (porzucasz).

Nie pracuję w ten sposób. Najpierw długo się zastanawiam, a potem jak
już robię to .... nigdy nie musiałem się z niczego wycofywać.


> Robisz 7 rzeczy
> jednoczesnie?

Brzmi bardzo groźnie, chaotycznie i jakby mnie ktoś gonił :)

> Robiłes coś 6 lat temu i nie pamiętasz jak? NIe szkodzi, branch tam
> dalej jest, można sprawdzić, albo przenieśc zmiany.

Częściej nie pamiętam w którym programie to było (mam takich różnych
programików około 100). Jak już znajdę który to jest na tyle krótki, że
od razu znajduje to co potrzebuję.
Podejrzewam, że kontrola wersji raczej dotyczyłaby każdego z nich z
osobna - chyba by mi w tym nie pomogła.

> Zachorowałeś? Kolega kontynuuje pracę nad problemem, bez grzebania Ci w
> prywatnych plikach.

Jesteśmy niezastąpieni i to się może zemścić.

> Dysk się popsuł w laptopie? Nie szkodzi, zmiany są w CVS.

Poczekaj, a gdzie to CVS ma te zmiany? Nie na dysku?

> Systemy kontroli wersji są super ważne w pracy w grupie, ale dla 1
> programisty są bardzo ważne.

Z naciskiem na 'programistów'. Jak ja coś piszę góra miesiąc w roku....

> Po jakimś czasie okazuje się, że jak masz taki system, to nagle
> pojawiaja się automaty budujące, eliminujące bugogenne białko z procesu
> produkcji, pojawia się testowanie automatyczne, pojawia się masa innych
> elementów inzynierii oprogramowania, które nie mają sensu, jesli nie
> masz CVS.

Same się nie pojawią. Nie czuję dlaczego bez CVS nie mają sensu.

> Na świecie jest wielu którzy nie używają CVS. Na 99% z powodu
> niepojmowania zalet i mylenia ich z wadami. A niepojmowanie polega na
> tym, że CVS wymagają porzucenia głupich nawyków - szczególnie, że
> wymagają higieny pracy.

Napisz proszę parę haseł o tej higienie.
P.G.

do góry

On 18/07/2022 22:30, Piotr Gałka wrote:
>> Masz mozliwosć wysofania się z dowolnej poprawki, wliczając w to
>> detalicznie pojedyncze linie, całe wrzuty, stan z konkretnego dnia,
>> grupy plików, całe implementacje itd itp. Możesz w ułamku sekund
>> przełaczyć się na źródła tydzień wstecz, coś sprawdzić, i wrócić do
>> pracy na aktualnym stanie.
> Opis możliwości bardzo mi się podoba. Ja nie piszę embedded tylko
> czasami (bardzo czasami) coś na PC. Przypominam sobie tylko jeden raz
> kiedy cofałem się do stanu z jakiegoś dnia przed kilku laty.
> Podejrzewam, że CVS choć ma możliwości imponujące to chyba nigdy bym z
> nich nie skorzystał.

Nie, to działa odwrotnie. Ponieważ nie masz takich możliwości, to
przyzwyczaiłeś się z nich nie korzystać.

>> Dodatkowo pozwala Ci tworzyć osobne "sandboxy eksperymentalne"
>> nazywane zazwyczaj branchami. Sprawdzasz coś, robisz przez 3 tygodnie
>> i na koniec albo dobre (i mergujesz) albo złe (porzucasz).
> Nie pracuję w ten sposób. Najpierw długo się zastanawiam, a potem jak
> już robię to .... nigdy nie musiałem się z niczego wycofywać.

Znowu dokładnie ta sama odpowiedź: ponieważ nie masz takiej możliwości,
to tego nie robisz.

>> Robisz 7 rzeczy jednoczesnie?
> Brzmi bardzo groźnie, chaotycznie i jakby mnie ktoś gonił :)

Nie. Dam przykład:

1) projektujesz PCB. Za tydzień będa płytki. Pliki w CVS z tymczasem:
2) poprawiasz firmware, aby był gotowy na nowe połaczenia, ale Stasiek
zachorował i nie możesz kontynuować wiec:
3) dorabiasz miganie diodą. Miganie rzecz ważna, więc dorobić warto, ale
w połowie:
4) O przyszły płytki! I to z błędem! Poprawiasz wiec, miganie może zaczekać.
5) Stasiek przyszedł.

Jak widzisz, multitasking nawet w 2 osoby może być wielowątkowy. W jedną
też i to jak.

>> Robiłes coś 6 lat temu i nie pamiętasz jak? NIe szkodzi, branch tam
>> dalej jest, można sprawdzić, albo przenieśc zmiany.
> Częściej nie pamiętam w którym programie to było (mam takich różnych
> programików około 100). Jak już znajdę który to jest na tyle krótki, że
> od razu znajduje to co potrzebuję.

A gdzie go znajdujesz? I czy to coś ma backup? A jak umrzesz, to ktoś
się w tym połapie?

> Podejrzewam, że kontrola wersji raczej dotyczyłaby każdego z nich z
> osobna - chyba by mi w tym nie pomogła.

Nie. Możesz je mieć wszystkie razem. Możesz mieć wiele niezależnych ale
w jednym repozytorium. Możesz mieć wiele repozytoriów. Co tam uważasz.

>> Zachorowałeś? Kolega kontynuuje pracę nad problemem, bez grzebania Ci
>> w prywatnych plikach.
> Jesteśmy niezastąpieni i to się może zemścić.

To jakiś powazny bład organizacyjny. Ludzie nie mogą być niezastąpieni.

>> Dysk się popsuł w laptopie? Nie szkodzi, zmiany są w CVS.
> Poczekaj, a gdzie to CVS ma te zmiany? Nie na dysku?

Na *jednym* filesystemie, którym łatwiej się zająć pod wzgledem
bezpieczeństwa niż 10 dyskami w 5 latpopach z 7 wirusami.

>> Systemy kontroli wersji są super ważne w pracy w grupie, ale dla 1
>> programisty są bardzo ważne.
> Z naciskiem na 'programistów'. Jak ja coś piszę góra miesiąc w roku....

Aby była jasnośc: CVS maja w nosie co w nich trzymasz. Z jednym
wyjątkiem: nie lubią plików binarnych. Możesz je tam trzymac, ale sam
sobie jesteś wtedy winien, bo pojęcie mergowania, blame itd nie pracują
na plikach binarnych i tracisz. Stąd tak duży nacisk na to, aby *źródła*
czegokolwiek (programu, pcb, cad) trzymać w formie tekstowej, a nie
binarnej i jeden z wielu powodów dla których ludzie porzucają CVS bo ...
maja pliki binarne.

>> Po jakimś czasie okazuje się, że jak masz taki system, to nagle
>> pojawiaja się automaty budujące, eliminujące bugogenne białko z
>> procesu produkcji, pojawia się testowanie automatyczne, pojawia się
>> masa innych elementów inzynierii oprogramowania, które nie mają sensu,
>> jesli nie masz CVS.
> Same się nie pojawią. Nie czuję dlaczego bez CVS nie mają sensu.

Mają sens, ale są trudne w kontroli.

Dam przykład.

1) wrzucam coś w CVS na "główny poziom"
2) automatycznie w tyle, dedykowany serwer, widzi tą wrzutę, ściąga
źródła i puszcza na nich testy
3) po chwili dostaje maila że program się kompiluje i przeszedł testy
4) po drodze nie ma białka/galaretki

Gdyby, nie posiadał CVS mógłbym dalej puszczać to ręcznie, ale to jest
elemen białkowy, który należy eliminować. Bo testy możesz puścić nie te,
nie tu, nie tymi i nie tak. Białko to poważny problem w IT.

>> Na świecie jest wielu którzy nie używają CVS. Na 99% z powodu
>> niepojmowania zalet i mylenia ich z wadami. A niepojmowanie polega na
>> tym, że CVS wymagają porzucenia głupich nawyków - szczególnie, że
>> wymagają higieny pracy.
> Napisz proszę parę haseł o tej higienie.

1) wszystko co prowadzi do działania programu/urządzenia jest trzymane w
CVS. WSZYSTKO. Po bombie atomowej, jesli tylko CVS przetrwa, ma byc
możliwosc odtworzenia bit-w-bit całości produktu.

2) nie ma "bo Stasiek to ma jeszcze taki pliczek na c: co ustawia...".
Stasiek idzie na dywanik do managera

3) nawet narzędzia, bibliteki zewnętrzne, opcje kompilacji, obrazki,
pliki konfiguracyjne IDE. WSZYSTKO. Ale patrz 6)

4) istnieje "główny branch" na którym obowiązkiem programistów jest
utrzymanie spójności. Nie ma "wrzucę ten pliczek, a te dwa jutro bo już
po 16". Albo wszystko albo nic. Bałagan można sobie robić na swoich
branchach eksperymentalnych. Na głównym ma być perfekcyjnie i atomowo.

5) Każda wrzuta w głowny branch jest prawidłowo opisana. Nie ma
"poprawka" albo "już działa". Jest "Poprawiono generację PWM dla trybu
16 bit w związku z bugiem L000872 zmieniajac współczynnik podziału kwarcu".

6) CVS trzyma źródła. Nie binaria. Wrzucenie binariów == dywanik u
managera. Jeśli coś jest binarne (np. gcc w wersji X) to w CVS jest
wrzucona informacja że gcc jest w wersji X.

7) wszyscy używają CVS. Używanie lewych środków przesyłania "poprawek i
fixów" jest niedopuszczalne.

Większosc o restrykcje, których zadaniem jest niezrobienei sobie kuku.
Są bolesne, szczególnie dla ludzi którzy wczesniej odwalali byle jak,
czyli trzymali pliki na c:, pakowali do zipów, chowali pod nazwami
"2022_fg_nowy_7_z_popawkami.zip" itp dziadostwo.

Restrykcje są po to, aby było łatwiej.

I jest.

Serio.

PS. Zrobienie repozytorium i rozpoczęcie pracy, w przypadku Subverion,
to 2 kliknięcia w pustym katalogu. Nie przesadzam. Nie ma wymówek.

do góry

W dniu 2022-07-18 o 22:23, heby pisze:

> To i tak Ci nie uratuje tyłka: struktury danych są w RAM.

Nie. Wszystkie istotne dane są zapisywane do flasha.
Zasilanie jest tak zrobione, że od przerwania (zaraz zabraknie ci prądu)
do faktycznego zaniku jest dość czasu na dokończenie aktualnego zapisu
do flasha.
Przy resetach itp. w RAMie mogą zginąć jakieś ostatnio wysyłane ramki -
ale to nic zostanie powtórzone.

> rejestry są
> "zrobione z ram".

Struktura danych jest taka, że w przypadku resetu (przerwa w zasilaniu,
watchdog) stan wskaźników do flasha jest odtwarzany z jego zawartości a
stan innych rejestrów stanów aktualnych zasadniczo daje się odtworzyć z
danych z flasha i RTC. Stany chwilowe nie są odtwarzane (np. był impuls
otwierania przejścia i miał jeszcze trwać 3s). Przerwa w zasilaniu, po
jakimś czasie powrót zasilania. Impuls nie zostanie dokończony - byłoby
bez sensu aby otworzyć drzwi dlatego, że włączono zasilanie.
Gdybym to ja pisał to byłbym w stanie rzucić więcej dających pojęcie
informacji.
Ogólnie jak się wyłączy zasilanie i po jakimś czasie włączy to nasze
urządzenia mają pracować jak gdyby nic się nie stało, nawet jak nie mają
kontaktu z komputerem przez względnie długi czas (jak się przepełni
bufor zdarzeń (chyba 32 tysiące) to albo nastąpi zgubienie najstarszych
albo się zablokuje (chyba flaga ustawiana przez użytkownika)).

> Masz ten sam problem. PC też może się przestawić bez
> powodu i program pójdzie w maliny.

Jak nie zacznie wysyłać nam błędnych danych (prawidłowo szyfrowanych i
podpisywanych) to nic poważnego się nie stanie.

> Gdybym rozmawiał o urządzeniu typu respirator, nie miało by takiej budowy.

Oczywiste.

> To nie jest klasyczny układ automatyki do sterowania promem kosmicznym.
> To urządzenie testujace. Najwyżej nie przetestuje. Przyjdzie operator i
> wciśnie reset.
....

> Nie myl urządzenia do robienia rzeczy nieważnych z rozrusznikami serca.

W najmniejszym stopniu nie krytykuję tego urządzenia. Opisuję tylko
dlaczego nam nie pasują tego typu rozwiązania, choć może jesteśmy w tym
temacie trochę dinozaurami.
P.G.

do góry

On 18/07/2022 22:58, Piotr Gałka wrote:
>> To i tak Ci nie uratuje tyłka: struktury danych są w RAM.
> Nie. Wszystkie istotne dane są zapisywane do flasha.

Nieprawda. Podczas pracy algorytmu dane są w RAM.

Są narażone na uszkodzenie. Na przykład od promieniowania kosmicznego.
To nie żart - ludzie w ten sposób np. łamali zabezpieczenia kart SIM
(hasło: nop slope). Z braku promieniowania kosmicznego używano żarówki...

> Zasilanie jest tak zrobione, że od przerwania (zaraz zabraknie ci prądu)
> do faktycznego zaniku jest dość czasu na dokończenie aktualnego zapisu
> do flasha.

To idealny świat.

>> rejestry są "zrobione z ram".
> Struktura danych jest taka, że w przypadku resetu (przerwa w zasilaniu,
> watchdog) stan wskaźników do flasha jest odtwarzany z jego zawartości a
> stan innych rejestrów stanów aktualnych zasadniczo daje się odtworzyć z
> danych z flasha i RTC.

Więc to bardzo specyficzny problem. Nic wspólnego z moim nie ma.
przypominam, że odpowiedziałem na marudzenie "Java jest wolna
straszliwie", a nie na "jak pisać soft do respiratorów".

> W najmniejszym stopniu nie krytykuję tego urządzenia. Opisuję tylko
> dlaczego nam nie pasują tego typu rozwiązania

Ale jak nikogo nie przekonuje do tych rozwiązań. Bo to nie są
rozwiązania, tylko workaroundy. Powód dla którego pojawił się tutaj ten
malutki system z Linuxem to postawienie się w opozycji do stwierdzeń
"Java jest wolna". Java jest tak wolna, jak kiepscy są programiści. A
java ma wyjątkowo kiepskich.

do góry

W dniu 2022-07-18 o 22:57, heby pisze:

> To jakiś powazny bład organizacyjny. Ludzie nie mogą być niezastąpieni.

Zdajemy sobie z tego sprawę, ale to jest chyba typowa bolączka wielu
mikrofirm.

> Na *jednym* filesystemie, którym łatwiej się zająć pod wzgledem
> bezpieczeństwa niż 10 dyskami w 5 latpopach z 7 wirusami.

Pracuję na komputerze (jednym) bez dostępu do internetu. Na sieci
wewnętrznej jest dysk (w środku chyba są dwa dyski zrównoleglone) do
backupów.

> Restrykcje są po to, aby było łatwiej.
>
> I jest.
>
> Serio.

Dzięki za opis.

> PS. Zrobienie repozytorium i rozpoczęcie pracy, w przypadku Subverion,
> to 2 kliknięcia w pustym katalogu. Nie przesadzam. Nie ma wymówek.

Nie sztuka kliknąć. Sztuka wiedzieć gdzie.

Jak znam siebie to musiałbym z miesiąc postudiować jakieś opisy tego
zanim w ogóle spróbowałbym użyć.
A mam tyle innych rzeczy których powinienem się pouczyć - choćby te 32
bitowe procesory.

Jak się chciałem przenieść do KiCada to najpierw przeczytałem całą
dokumentację. A teraz na forum widzę masę ludzi, którzy pytają o rzeczy
które są jak byk w "Getting started".
P.G.

do góry

W dniu 2022-07-18 o 23:13, heby pisze:

>> Zasilanie jest tak zrobione, że od przerwania (zaraz zabraknie ci
>> prądu) do faktycznego zaniku jest dość czasu na dokończenie aktualnego
>> zapisu do flasha.
>
> To idealny świat.

To i tak jest zabezpieczenie na wszelki (normalnie nie zdarzający się)
przypadek bo zasilanie buforowe.

> Więc to bardzo specyficzny problem. Nic wspólnego z moim nie ma.
> przypominam, że odpowiedziałem na marudzenie "Java jest wolna
> straszliwie", a nie na "jak pisać soft do respiratorów".

Nie zakonotowałem tego "Java jest wolna". Według mnie jesteśmy w ogóle
poza kontekstem tego Twojego urządzenia. Ot po prostu staram się tropchę
wytłumaczyć 'starych dziadków' - czyli siebie.
P.G.

do góry

W dniu 2022-07-18 o 23:13, heby pisze:

Pora kończyć pracę i wybrać się do domu.
P.G.

do góry

On 18/07/2022 23:16, Piotr Gałka wrote:
>> To jakiś powazny bład organizacyjny. Ludzie nie mogą być niezastąpieni.
> Zdajemy sobie z tego sprawę, ale to jest chyba typowa bolączka wielu
> mikrofirm.

To zależy. Owszem, czasami cieżko zastapić talent. Ale nie może być tak,
że człowiek umiera i nikt nie wie "jak on TO kompilował". Ta wiedza musi
być dostepna i zazwczaj jest w CVS. Jesli jej tam nie ma to firma jest o
jeden zawał od bankructwa.

>> Na *jednym* filesystemie, którym łatwiej się zająć pod wzgledem
>> bezpieczeństwa niż 10 dyskami w 5 latpopach z 7 wirusami.
> Pracuję na komputerze (jednym) bez dostępu do internetu. Na sieci
> wewnętrznej jest dysk (w środku chyba są dwa dyski zrównoleglone) do
> backupów.

Dalej, jeden dysk sieciowy łatwiej (automatycznie) backupować, niż dyski
klientów.

Repozytorium możesz miec poza firmą. Wtedy ktoś inny dba o backupy.

>> PS. Zrobienie repozytorium i rozpoczęcie pracy, w przypadku Subverion,
>> to 2 kliknięcia w pustym katalogu. Nie przesadzam. Nie ma wymówek.
> Nie sztuka kliknąć. Sztuka wiedzieć gdzie.

"Create repository here" w TortoiseSVN na przykład.

> Jak znam siebie to musiałbym z miesiąc postudiować jakieś opisy tego
> zanim w ogóle spróbowałbym użyć.

Albo 1 osoba, która w niecała minutę przedstawi proces tworzenia repo i
wrzucenia do niego pliku. No może w 2 minuty z popijaniem herbatki.
Reszta elementów do ogarnięcia w godzinkę, z czego więskzość
samodzielnie bez czytania instrukcji.

> Jak się chciałem przenieść do KiCada to najpierw przeczytałem całą
> dokumentację.

To bez sensu. Po pierwsze, to zbedna wiedza w większości, po drugie
zazwyczaj dokumentacje do projektów darmowych nie są spójne do stanu
apliakcji.

> A teraz na forum widzę masę ludzi, którzy pytają o rzeczy
> które są jak byk w "Getting started".

Niech pytają. Czytanie dokumentacji świadczy o braku intuicyjności
obsługi programu. Akurat w przypadki KiCADa to faktycznie ma miejsce.
Czuje ból głowy za każdym razem, kiedy dotykam czegokolwiek z CAD w nazwie.

do góry

On 18/07/2022 23:20, Piotr Gałka wrote:
> Nie zakonotowałem tego "Java jest wolna". Według mnie jesteśmy w ogóle
> poza kontekstem tego Twojego urządzenia. Ot po prostu staram się tropchę
> wytłumaczyć 'starych dziadków' - czyli siebie.

Ale ja też jestem stary dziadek ;)

Może tylko roche bardziej obcykany w dużych projektach
programistycznych. I troche mniej w małych, trudnych projektach embedded.

Grunt aby nie stawać w opozycji. To dwa różne światy.

Ale kontrola werji taka sama (być powinna ;)

do góry

On 18/07/2022 13:58, Arnold Ziffel wrote:
> stary grzyb <s...@o...pl> wrote:
>
>> Na początek wystarczy Nucleo, bo programator na płytce jest wydzielony.
>> Nawet bez odłamywania go od reszty modułu, można nim programować własne
>> układy z STM, co robiłem przez kilka pierwszych lat. Dopiero niedawno
>> kupiłem ST-Link V3SET - trochę "na wyrost", bo na razie nie mam potrzeby
>> korzystania z jego możliwości wykraczających poza V2.
>
> To pewnie tak właśnie zrobię.
>

mam jakieś nucleo w szufladzie... bawilem sie kilka lat temu ale to
jeszcze były czasy przed ESP32. Dzisiaj to juz prawie nie ma sensu...

Tak z ciekawości... da się to jakoś ogarnąć pod linuksem (w sensie IDE,
debugowanie i flashowanie)? U mnie windows poszedl w odstawke z 8 lat
temu i nie chce wracać.

c.

do góry