SSN-688

[bartes123]

A już myślałem że to taki Luke Perry(Szkop):

[Michał MiKoKu]

full satysfaction...no może mniej niż np po jedzeniu - szczególnie, że szkopy (nawet jak się nazywają Perry) mnie nie pociągają...

[Andrzej1]

Witam

No i zdarzyło się. Jeden z licznych przewodów łączących górną połówkę z dolną dostał się
pomiędzy połówki w trakcie skręcania. Przewody są cienkie, to i szczelina niewielka była.

Ale wystarczająca aby w ciągu paru sekund do wnętrza modelu wlała się setka wody.
Straty są ale stosunkowo małe. Komputer zdaje się nie uległ (co tam jedna setka).
Tylko uszczelka do wymiany - jeszcze na stanie. Na całe szczęście działał
czujnik WOB (water on the board) i wyjąłem model z wody zanim całkiem zatonął.
Ale zmusiło mnie to, do wynalezienia sposobu, oraz takiej konstrukcji, aby na przyszłość to
zdarzyć się nie mogło. Przy okazji wyszło, że inklinometr (ten do góry brzuchem z przylutowanymi
przewodami) może ulec uszkodzeniu gdy nacisną go przewody, których górą (nad nim) idzie
całe wiadro.

Zająłem się więc mikroelektroniką, a w tym wypadku, wytwarzaniem obudowy
do układu scalonego. Obudowa z polistyrenu 0.5 mm i wygląda tak :

Po zamontowaniu na płycie :

Teraz pozostało wymyśleć płot, który poważnie utrudni niesfornym przewodom włażenie
na krawędzie kadłuba przy skręcaniu.
Pierwszy pomysł jest taki, aby przewody połączyć w taśmę, która będzie miała wbudowaną
natruralną sztywność w kierunku na boki. Drugi pomysł to zbudowanie 10 milimetrowego płotu
na newralgicznych krawędziach płyty głównej w celu uniemożliwienia wyłażenia przewodów.
O efektach lub ich braku wkrótce.

Z ukłonami
Andrzej Korycki

[rychenko]

Trudne to życie podwodniaka

[Andrzej1]

Witam

LAla błędów nie wybacza, dlatego ciężkie jest życie kataryniarza w Wielkim
Poście jak mu zdechnie papuga.

Dzisiaj rano kable łączące górę z dołem wyglądały tak :

Widać nieznaczną poprawę w stosunku do dni poprzednich.
Przy założeniu, że docelowo tej cienkiej niebiesko-czerwonej taśmy nie będzie,
widok jest już całkiem znośny.

Pozostała kontrola napięcia akumulatorów, ewentualne ładowanie.
Ładowanie zawsze wykonuję w ten sposób, że ładowarka rozładowuje
akumulatory do minimum napięcia (NiMh 0.9V na celę) i ładuje
od nowa. Prąd rozładowania troszkę więcej niż dziesięciogodzinny.

Ta kontrola jest potrzebna, bo elektronika zbiorników zachowuje się
źle gdy napięcie jest poniżej 8V. Ile poniżej tego nie wiem.
Gdy będę szukał błędów w programie, Gura będzie szukał przyczyn
w elektronice.

Z ukłonami
Andrzej Korycki

[Andrzej1]

Witam

Oto efekt dzisiejszej pracy :
Zestawione stanowisko do testowania okrętów podwodnych w piwnicy :

i wynik testowania :

Za chwilę będę wiedział ... co poprawić w programie aby się dowiedzeć tego co chcę.

Z ukłonami
Andrzej Korycki

[Edit]
Następnego dnia rano :
Po dłuższym poszukiwaniu błędu w programie, znalazłem.
Otóż kompilator GCC nie potrafi porównywać z zerem zmiennych typu char (jednobajtowych).
Z moich trzydziestoletnich doświadczeń wynikało, że :
char c;
c = -10;
if ( c < 0 )
{// będzie wykonane zawsze. A tu kupa. c było traktowane jak liczba dodatnia.
// stąd krzywe zanurzanie okrętu i reszta kłopotów.
}

Zmienne typu char trzeba zastąpić wydumanym typem int8_t, też jednobajtowym i dopiero wszystko działa jak się przynależy.

Za to mam teraz inny problem :
Otóż okręt jest trochę za lekki. Trzeba go dociążyć, bo zbiorniki opierają się o krańcówki
i chcą dalej a tu nie ma pojemności. Trzeba wykonać kopytko z gipsu, odlać parę małych ciężarków
i włożyć je do okręta.
Z ukłonami
Andrzej Korycki

[End of Edit]

[Andrzej1]

Witam

Teraz LAla w majtkach pływa tak :

http://www.youtube.com/watch?v=yeaNZ7sDpXg

W majtkach znajduje się dodatkowe obciążenie, które muszę dołożyć.

Z ukłonami
Andrzej Korycki

[rychenko]

Andrzeju cóż Ty masz za piwnice ? ze okręt podwodny w niej zmieścisz ?
Piękny to widok jak Lalunia się zanurza , głośne są te mechanizmy wewnątrz ? czy to tylko taki pogłos w piwnicy jest?

[ramol]

Z tego co wiem zmienne typu char są przypisane do obsługiwania łańcuchów literowych, tablic, i innych danych gdzie trzeba obsłużyć działanie na łańcuchach znakowych, dlatego też nawet jeżeli zmiennej tego typu nadamy sztucznie wartość cyfrową, to się może nie udać porównywanie zmiennej znakowej ze zmienną cyfrową, a czasami wręcz program wykrywa błąd i nie chce się skompilować nawet. Zmiana typu zmiennej na int który jest zmienną cyfrową powinien faktycznie rozwiązać problem.

Majty świetne, choć lala to raczej jako nowoczesna na wskroś powinna być wyposażona w stringi.


edit: zwykła zmienna typu int też jest oparta na rejestrze 8 bitowym, ale jeżeli używając zmiennej typu char też ci wszystko chodzi to ok, moje obawy dotyczą tego że może się to czasem wykrzaczyć przy wykonywaniu jakichś procedur, bo pomimo że zmiennej char nadajesz określoną wartość to gdzieś w podprocedurach może być potraktowana jako zmienna znakowa i wyjdzie że program będzie usiłował porównać wartości pętli nie z liczbą podstawioną pod zmienną char, tylko ze znakiem z tablicy ASCI odpowiadajacym wartości podstawionej liczby. I wtedy wyjdzie taki mały zonk bo się wywali.

Malutka uwaga: generalnie 8bitowa zmienna może być albo w zakresie 0-256 gdzie całe 8 bitów jest przeznaczone na liczbę, lub w zakresie (-128)do(128) gdzie 7 bitów przeznaczone jest na liczbę a 8 bit zawiera znak.
Stosując zakres zamiast -90 do 90, można zastosować zakres 0 do 180, asembler procesora oszczędza przy każdej operacji dodawania i odejmowania jedną operację sprawdzenia i przepisania znaku, ponieważ dostaje w rejestrze za każdym razem zmienna dodatnią i od razu wykonuje działanie bez operacji sprawdzania znaku zmiennej.

[Andrzej1]

Witam

Ryszardzie, rzeczywiście mechanizmy pracują głośno. Ale przenoszą dość duże siły i wykorzystane
zostały kółka z wibratorów wyznaczające konstrukcję pozostałych kól. Wyeliminowało to koła
o skośnych zębach. Proste zęby są głośne i ładne ....

Masz słusznego Mariuszu, ale ...
Każdy znak ma przypisaną "sztucznie" wartość liczbową .
W ASCII jest to tak :

Kod: Zaznacz cały

NUL   00   00   +   2B   43   V   56   86
SOH   01   01   ,   2C   44   W   57   87
STX   02   02   -   2D   45   X   58   88
ETX   03   03   .   2E   46   Y   59   89
EOT   04   04   /   2F   47   Z   5A   90
ENQ   05   05   0   30   48    [   5B   91
ACK   06   06   1   31   49   \   5C   92
BEL   07   07   2   32   50   ]   5D   93
BS   08   08   3   33   51   ()   5E   94
HT   09   09   4   34   52   -()   5F   95
LF   0A   10   5   35   53   ‘   60   96
VT   0B   11   6   36   54   a   61   97
FF   0C   12   7   37   55   b   62   98
CR   0D   13   8   38   56   c   63   99
SO   0E   14   9   39   57   d   64   100
SI   0F   15   :   3A   58   e   65   101
DLE   10   16   ;   3B   59   f   66   102
DC1(X-ON)   11   17   <   3C   60   g   67   103
DC2(TAPE)   12   18   =   3D   61   h   68   104
DC3(X-OFF)   13   19   >   3E   62   i   69   105
DC4   14   20   ?   3F   63   j   6A   106
NAK   15   21   @   40   64   k   6B   107
SYN   16   22   A   41   65   l   6C   108
ETB   17   23   B   42   66   m   6D   109
CAN   18   24   C   43   67   n   6E   110
EM   19   25   D   44   68   o   6F   111
SUB   1A   26   E   45   69   p   70   112
ESC   1B   27   F   46   70   q   71   113
FS   1C   28   G   47   71   r   72   114
GS   1D   29   H   48   72   s   73   115
RS   1E   30   I   49   73   t   74   116
US   1F   31   J   4A   74   u   75   117
SP   20   32   K   4B   75   v   76   118
!   21   33   L   4C   76   w   77   119
„   22   34   M   4D   77   x   78   120
#   23   35   N   4E   78   y   79   121
$   24   36   O   4F   79   z   7A   122
%   25   37   P   50   80   {   7B   123
&   26   38   Q   51   81   |   7C   124
‘   27   39   R   52   82   }(Alt MODE)   7D   125
(   28   40   S   53   83   ~   7E   126
)   29   41   T   54   84   DEL   7F   127
*   2A   42   U

Sory, ale część znaków się nie wyświetla poprawnie.
Extended ASCII zawiera resztę znaków do 255.

W mikrokontrolerach jest tak, że zmienne jednobajtowe są bardziej regułą niż wyjątkiem.
Powody są take :
1. Ograniczona ilość pamięci w procesorze.
2. Ograniczona wielkość stosu.
3. Najkrótszy z możliwych czas operacji na takiej zmiennej. Tylko jeden bajt pamięci.
4. Na czas odczytu takiej zmiennej (modyfikowanej w przerwaniu) NIE trzeba blokować
przerwań, bo odczyt odbywa się w jednej operacji (assemblerowej), która nie ulegnie
przerwaniu (jak się już zaczęła).
5. Bardzo często zakres oferowany przez zmienną char (-128...+127 za K&R) wystarcza.
U mnie inklinacja (przechył dziób/rufa) zmienia się w zakresie (-90 + 90)
6. W mikrokontrolerach często tablice mają mniej niż 255 elementów. Jakże ponętne jest
użycie jednobajtowej zmiennej kontrolnej pętli (unsigned char). Szybkie łatwe i przyjemne.
Można pewnie znaleźć inne (powody), ale czy nie starczy ?

I wreszcie dlaczemu wprowadzono dwa typy : char i unsigned char ?
Mają się różnić tylko nazwą ? nie sądzę. Dla mnie, to ewidentna niedoróbka GCC.

Dlatego, w LAli, zawsze gdzie mogę, stosuję zmienne typu char lub unsigned char (0...255).
Kompilator Visual Studio 2003 ( i wszystkie poprzednie do VC6) kompilują zgodnie z moimi
oczekiwaniami następujący kod (przed chwilą sprawdziłem) :
char c;
c = -10;
if ( c < 0 )
{// to się wykonuje
int i = c;
int k = i;
}

To co piszesz o ewentualnych błędach kompilacji może wynikać :
a) z przekroczenia zakresu zmiennej char :
char c;
c = 12000; // powinno wykryc błąd
MSVC2003 daje warninga : warning C4309: '=' : truncation of constant value
Podstawienie c = 12; przechodzi bez komentarza.

b) z ewentualnego braku rzutowania stałej int na typ char.
char c;
c = (char)12000; // nie powinno wykryć błędu mimo, że jest, ale wyraźnie zamierzony przez programistę
MSVC2003 nie sygnalizuje nic.

O ile pamiętem, kompilator C Keil'a dla 8051 też tak działa. Zresztą procesor Z80, wydaje mi się,
też miał operacje assemblerowe, ze znakiem i bez, na ośmiobitowych rejestrach. Co do Z80 mogę
się mylić - to było tak dawno.

Z ukłonami
Andrzej Korycki

[Edit]
Język ANSI C, Brian W. Kernighan, Dennis M. Ritchie, WNT, ISBN 83-204-2979-X na stronie 62
podaje :
To czy zwykły obiekt typu char jest liczbą ze znakiem czy bez znaku, zależy od maszyny ....

Z tego wynika, że moje zarzuty do GCC są bezpodstawne, a błąd wynikał ze zwykłej rutyny
i był tak głupi jak wszystkie znalezione błędy. A typ int8_t zagości na dobre w mózgu LAli.

Z ukłonami
Andrzej Korycki
[End of Edit]