eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaZagwozdka w C Keil.
Ilość wypowiedzi w tym wątku: 84

  • 21. Data: 2019-02-12 02:33:25
    Temat: Re: Zagwozdka w C Keil.
    Od: k...@g...com

    W dniu poniedziałek, 11 lutego 2019 14:27:54 UTC+1 użytkownik Mateusz Viste napisał:
    > Bo to zaiste nie (ANSI) C. Na co komu deklarowanie zmiennych w środku
    > kodu? Jeśli odczuwasz taką potrzebę, to zapewne twój kod wymaga
    > refaktoryzacji. Prawdziwe C to C89, wszystko inne to wymysły młodzieży,
    > której się nudziło.
    Wiem, że rozmawiamy trochę z przymrużeniem oka, więc miałem kiedyś
    przygodę, kiedy utrzymywana przeze mnie paczka (co gorsza, w Pythonie)
    przestała się budować. Tam był kod w C który był generowany
    automatycznie, a narzędzia do współpracy Python - C na pewnym etapie
    przestawiły flagi kompilatora z domyślnego "ANSI C z typowymi bajerami"
    na "brak wstępu dla młodzieży, wyrzucaj error przy czymkolwiek
    czego nie można według C89". Wszystko dzięki temu, że generowany
    kod miał "int i;" przed forem a nie na początku funkcji.
    Wtedy się dowiedziałem, że tego nie było w standardzie bo wszystkie
    kompilatory C jakich w życiu używałem nie miały co do tego
    obiekcji;)

    > No ok - uczciwie muszę przyznać, że zdarza mi się korzystać z 'long
    > long', ale to jedyna rzecz której mi czasem braknie w C89. :)
    Ja patrzę z punktu widzenia kogoś, kto czasem napisze coś na
    "normalny" komputer i chyba nigdy nie udało mi się napisać programu
    w C, który używa poza jakimiś niekrytycznymi pętlami po 100 elementach
    któregokolwiek z typów danych z C89. Standard C w tym zakresie jest
    spuścizną po czasach Unixa, kiedy starano się zrobić jeden przenośny język
    oprogramowania i system operacyjny obejmujący miriadę komputerów.
    Efekt jest taki, że w kontekście zwykłego x86-64 windowsowy long
    ma 32 bity, a uniksowy 64 i obydwa podejścia są zupełnie koszerne
    pod względem standardu. Long long rzeczywiście jest sposobem
    na wymuszenie zmiennej, która będzie miała te >= 64 bity ;)

    Pozdrawiam,
    --
    Karol Piotrowski


  • 22. Data: 2019-02-12 09:31:34
    Temat: Re: Zagwozdka w C Keil.
    Od: Mateusz Viste <m...@n...pamietam>

    On Mon, 11 Feb 2019 17:33:25 -0800, kropelka wrote:
    > Ja patrzę z punktu widzenia kogoś, kto czasem napisze coś na "normalny"
    > komputer i chyba nigdy nie udało mi się napisać programu w C, który
    > używa poza jakimiś niekrytycznymi pętlami po 100 elementach
    > któregokolwiek z typów danych z C89.

    Ale przecież typy danych w C89 są całkiem normalne: char, short, int,
    long... Ich szerokości mogą zmieniać się z jednego komputera na drugi
    (np. taki int może mieć raz 16, raz 32, a innym razem 64 bity), ale to
    wszystko jest zgodne z C89. long natomiast ma zawsze co najmniej 32 bity
    - w jakich zastosowaniach jest potrzeba więcej na "normalnym" komputerze?

    Mi zdarza się (rzadko, ale jednak) użyć uint64_t do liczenia jakichś
    naprawdę dużych wielkości, np. do zliczania cykli CPU, a czasem nawet po
    _uint128_t (gcc) sięgnę jak potrzebuję popracować na adresach IPv6. Ale
    to naprawdę sporadyczne przypadki, stąd ciekaw jestem co takiego piszesz
    że w C89 nie da się :)

    Mateusz


  • 23. Data: 2019-02-12 22:39:24
    Temat: Zagwozdka w C Keil - wyjaśnienie.
    Od: "Irek.N." <t...@j...taki.jest.pl>

    No więc znalazłem chwilę aby podjechać do klienta i popatrzeć dokładnie
    w kod.
    Na wstępie małe usprawiedliwienie - procedura była napisana na 8051 i
    uruchomiona na jednym z pierwszych PLC jakie zrobiłem, w latach 90, ale
    stosowana też później*. W tamtych czasach wydawało mi się, że ogarniam
    podstawy C :)

    W maszynie którą diagnozowałem definicja zmiennej DEL_STEP była o zgrozo
    jako unsigned char. Nie zwróciłem na to uwagi, choć zauważyłem, że
    sprawdzany jest tylko młodszy - przekazany - bajt zmiennej z którą
    wywołano funkcję. Wygląda więc na to, że kompilator miał rację.

    Po zmianie definicji na unsigned int kompilator robi OLR na obu
    połówkach zmiennej DEL_STEP a następnie sprawdza czy wynik operacji jest
    zerowy. Bardzo ładne rozwiązanie moim zdaniem.

    Zrobiłem jeszcze jedną rzecz. Ponieważ jak zauważyliście, nie ma
    gwarancji, że sprawdzenie 16 bitów będzie poprawne w przypadku gdy
    przerwanie może je zmienić, podłączyłem oscyloskop, persystencję na
    nieskończoną i obserwowałem czas generowany przez procedurę. Zdarzały
    się błędnie odliczone interwały, ale nie za często. Zrobiłem jak Mateusz
    podpowiedział - flaga w przerwaniu modyfikującym zmienną. Nie złapałem
    żadnego błędnego odliczenia.

    Tak więc przepraszam, ale wychodzi na to, że sensacji nie ma, kompilator
    jednak dawał radę, a ja znowu się czegoś nauczyłem :)

    Dzięki wszystkim za pomoc.


    Miłego.
    Irek.N.
    * w późniejszych wersjach kodu (trochę inna wersja PLC) już była
    poprawna definicja jako typ 16 bitowy, czyli kiedyś to zauważyłem,
    poprawiłem i zapomniałem :(


  • 24. Data: 2019-02-12 23:02:14
    Temat: Re: Zagwozdka w C Keil - wyjaśnienie.
    Od: stary grzyb <s...@o...pl>

    > ... kiedyś to zauważyłem, poprawiłem i zapomniałem :(

    Przynajmniej jakaś pociecha dla mnie - myślałem, że tylko ja mam sklerozę ;)


  • 25. Data: 2019-02-13 09:10:34
    Temat: Re: Zagwozdka w C Keil - wyjaśnienie.
    Od: "HF5BS" <h...@...pl>


    Użytkownik "stary grzyb" <s...@o...pl> napisał w wiadomości
    news:q3vfp6$rq6$2@dont-email.me...
    > > ... kiedyś to zauważyłem, poprawiłem i zapomniałem :(
    >
    > Przynajmniej jakaś pociecha dla mnie - myślałem, że tylko ja mam sklerozę
    > ;)

    Panie, ja tam nie mam sklerozy, odpukać! Puk puk... Kto tam? :):)

    Kiedyś mi prawie półtora roku zajęło, aby złapać, dlaczego przy pracy z TC,
    wyskakuje mi pewne (niepożądane) okienko. Banał, że śmiać sie chce :)
    Czemu tyle? Bo stale zapomniałem wyłapać okoliczności, w jakich się to
    staje.

    --
    Łapy, łapy, cztery łapy,
    A na łapach pies kudłaty.
    Kto dogoni psa? Kto dogoni psa?
    Może ty? Może ty? Może jednak ja...?


  • 26. Data: 2019-02-13 10:44:58
    Temat: Re: Zagwozdka w C Keil - wyjaśnienie.
    Od: Piotr Gałka <p...@c...pl>

    W dniu 2019-02-12 o 23:02, stary grzyb pisze:
    > > ... kiedyś to zauważyłem, poprawiłem i zapomniałem :(
    >
    > Przynajmniej jakaś pociecha dla mnie - myślałem, że tylko ja mam
    > sklerozę ;)

    Zdarzyło mi się kiedyś, że postanowiłem, że coś muszę zmodyfikować w
    jednym programie. Wyszukałem miejsce gdzie to należy poprawić - a tu
    "już ktoś to zrobił". Według daty pliku wynikało, że góra miesiąc temu :(
    P.G.


  • 27. Data: 2019-02-13 11:28:08
    Temat: Re: Zagwozdka w C Keil - wyjaśnienie.
    Od: "J.F." <j...@p...onet.pl>

    Użytkownik "Irek.N." napisał w wiadomości grup
    dyskusyjnych:q3vee4$o74$...@n...news.atman.pl...
    >Na wstępie małe usprawiedliwienie - procedura była napisana na 8051 i
    >uruchomiona na jednym z pierwszych PLC jakie zrobiłem, w latach 90,
    >ale stosowana też później*. W tamtych czasach wydawało mi się, że
    >ogarniam podstawy C :)

    >W maszynie którą diagnozowałem definicja zmiennej DEL_STEP była o
    >zgrozo jako unsigned char. Nie zwróciłem na to uwagi, choć
    >zauważyłem, że sprawdzany jest tylko młodszy - przekazany - bajt
    >zmiennej z którą wywołano funkcję. Wygląda więc na to, że kompilator
    >miał rację.

    uzyc niewlasciwy typ - zdarza sie.
    Ale nie spojrzec jaki to typ przy sprawdzaniu/szukaniu bledu ... czas
    na lecytyne :-)

    >Po zmianie definicji na unsigned int kompilator robi OLR na obu
    >połówkach zmiennej DEL_STEP a następnie sprawdza czy wynik operacji
    >jest zerowy. Bardzo ładne rozwiązanie moim zdaniem.

    Typowe.

    >Zrobiłem jeszcze jedną rzecz. Ponieważ jak zauważyliście, nie ma
    >gwarancji, że sprawdzenie 16 bitów będzie poprawne w przypadku gdy
    >przerwanie może je zmienić, podłączyłem oscyloskop, persystencję na
    >nieskończoną i obserwowałem czas generowany przez procedurę. Zdarzały
    >się błędnie odliczone interwały, ale nie za często.

    Czyli potrafi przerwanie trafic miedzy dwie instrukcje ?
    No w sumie - zawsze miedzy dwie trafia, tylko kwestia
    prawdopodobienstwa, kiedy trafi miedzy dwie istotne.

    A tych instrukcji przy ORL byc moze nawet wiecej.

    >Zrobiłem jak Mateusz podpowiedział - flaga w przerwaniu modyfikującym
    >zmienną. Nie złapałem żadnego błędnego odliczenia.

    Rozumiem, ze najpierw zmieniles typ zmiennej na int ?

    Ale nie bardzo rozumiem - przerwanie ustawia flage, modyfikuje
    zmienna, gasi flage ?
    na przetwarzanie w procesie głownym nie ma to znaczenia - sprawdzi
    sobie, ze flagi nie ma, zacznie czytac zmienna ... i tu przerwanie
    przychodzi.
    Co innego gdy uzywa zmiennej przerwanie wyzszego poziomu.

    Ja bym tam wylaczyl przerwania na czas sprawdzenia, to raptem kilka
    instrukcji, ale w pojedynczym while zaprogramowac to trudno.

    A swoja droga - czy Keil sam ich nie wylacza ? Dla zmiennych volatile
    powinien.

    >* w późniejszych wersjach kodu (trochę inna wersja PLC) już była
    >poprawna definicja jako typ 16 bitowy, czyli kiedyś to zauważyłem,
    >poprawiłem i zapomniałem :(

    Ale o co chodzi - powiekszyles wartosc opoznienia ponad 255, i sie
    okazalo, ze nie czeka tyle co powinien ?

    J.


  • 28. Data: 2019-02-13 13:48:39
    Temat: Re: Zagwozdka w C Keil - wyjaśnienie.
    Od: Janusz <j...@o...pl>

    W dniu 2019-02-13 o 11:28, J.F. pisze:
    > Użytkownik "Irek.N."  napisał w wiadomości grup
    > dyskusyjnych:q3vee4$o74$...@n...news.atman.pl...
    >> Na wstępie małe usprawiedliwienie - procedura była napisana na 8051 i
    >> uruchomiona na jednym z pierwszych PLC jakie zrobiłem, w latach 90,
    >> ale stosowana też później*. W tamtych czasach wydawało mi się, że
    >> ogarniam podstawy C :)
    >
    >> W maszynie którą diagnozowałem definicja zmiennej DEL_STEP była o
    >> zgrozo jako unsigned char. Nie zwróciłem na to uwagi, choć zauważyłem,
    >> że sprawdzany jest tylko młodszy - przekazany - bajt zmiennej z którą
    >> wywołano funkcję. Wygląda więc na to, że kompilator miał rację.
    >
    > uzyc niewlasciwy typ - zdarza sie.
    > Ale nie spojrzec jaki to typ przy sprawdzaniu/szukaniu bledu ... czas na
    > lecytyne :-)
    >
    >> Po zmianie definicji na unsigned int kompilator robi OLR na obu
    >> połówkach zmiennej DEL_STEP a następnie sprawdza czy wynik operacji
    >> jest zerowy. Bardzo ładne rozwiązanie moim zdaniem.
    >
    > Typowe.
    >
    >> Zrobiłem jeszcze jedną rzecz. Ponieważ jak zauważyliście, nie ma
    >> gwarancji, że sprawdzenie 16 bitów będzie poprawne w przypadku gdy
    >> przerwanie może je zmienić, podłączyłem oscyloskop, persystencję na
    >> nieskończoną i obserwowałem czas generowany przez procedurę. Zdarzały
    >> się błędnie odliczone interwały, ale nie za często.
    >
    > Czyli potrafi przerwanie trafic miedzy dwie instrukcje ?
    > No w sumie - zawsze miedzy dwie trafia, tylko kwestia
    > prawdopodobienstwa, kiedy trafi miedzy dwie istotne.
    >
    > A tych instrukcji przy ORL byc moze nawet wiecej.
    >
    >> Zrobiłem jak Mateusz podpowiedział - flaga w przerwaniu modyfikującym
    >> zmienną. Nie złapałem żadnego błędnego odliczenia.
    >
    > Rozumiem, ze najpierw zmieniles typ zmiennej na int ?
    >
    > Ale nie bardzo rozumiem - przerwanie ustawia flage, modyfikuje zmienna,
    > gasi flage ?
    > na przetwarzanie w procesie głownym nie ma to znaczenia - sprawdzi
    > sobie, ze flagi nie ma, zacznie czytac zmienna ... i tu przerwanie
    > przychodzi.
    > Co innego gdy uzywa zmiennej przerwanie wyzszego poziomu.
    >
    > Ja bym tam wylaczyl przerwania na czas sprawdzenia, to raptem kilka
    > instrukcji, ale w pojedynczym while zaprogramowac to trudno.
    >
    > A swoja droga - czy Keil sam ich nie wylacza ? Dla zmiennych volatile
    > powinien.
    W avr studio nie wyłącza, i keil pewnie też,
    w gcc jest do tego osobna sekcja, atomic block się nazywa
    i w niej sie takie porównania robi.


    --
    Pozdr
    Janusz


  • 29. Data: 2019-02-13 16:22:44
    Temat: Re: Zagwozdka w C Keil - wyjaśnienie.
    Od: stary grzyb <s...@o...pl>

    >> Przynajmniej jakaś pociecha dla mnie - myślałem, że tylko ja mam
    >> sklerozę ;)
    >
    > Kiedyś mi prawie półtora roku zajęło, aby złapać, dlaczego przy pracy z
    > TC, wyskakuje mi pewne (niepożądane) okienko. Banał, że śmiać sie chce :)
    > Czemu tyle? Bo stale zapomniałem wyłapać okoliczności, w jakich się to
    > staje.

    Ja mam nawet tabletki na poprawę pamięci, ale co z tego, skoro ...
    zapominam je brać :)


  • 30. Data: 2019-02-13 21:13:12
    Temat: Re: Zagwozdka w C Keil - wyjaśnienie.
    Od: "Irek.N." <t...@j...taki.jest.pl>

    >> Po zmianie definicji na unsigned int kompilator robi OLR na obu
    >> połówkach zmiennej DEL_STEP a następnie sprawdza czy wynik operacji
    >> jest zerowy. Bardzo ładne rozwiązanie moim zdaniem.
    >
    > Typowe.

    Dla mnie bardzo eleganckie :)

    > Rozumiem, ze najpierw zmieniles typ zmiennej na int ?

    W * pisałem, że już kiedyś to znalazłem. Oczywiście że poprawiłem :)

    > Ale nie bardzo rozumiem - przerwanie ustawia flage, modyfikuje zmienna,
    > gasi flage ?
    > na przetwarzanie w procesie głownym nie ma to znaczenia - sprawdzi
    > sobie, ze flagi nie ma, zacznie czytac zmienna ... i tu przerwanie
    > przychodzi.
    > Co innego gdy uzywa zmiennej przerwanie wyzszego poziomu.

    Procedura ustawiająca zmienną modyfikowaną w przerwaniu ustawia flagę i
    czeka na jej zgaszenie. Przerwanie odlicza i jak doliczy to gasi flagę.

    > Ja bym tam wylaczyl przerwania na czas sprawdzenia, to raptem kilka
    > instrukcji, ale w pojedynczym while zaprogramowac to trudno.

    Niepotrzebna zabawa. Poza tym wprowadzasz dodatkowy jitter ;)

    > A swoja droga - czy Keil sam ich nie wylacza ? Dla zmiennych volatile
    > powinien.

    Niestety ale ignoruje zupełnie volatile, a nie powinien moim zdaniem.


    > Ale o co chodzi - powiekszyles wartosc opoznienia ponad 255, i sie
    > okazalo, ze nie czeka tyle co powinien ?


    No ba, dajesz operatorowi możliwość ustawiania parametru w zakresie
    100-500, a tu zonk, czasami maszyna się buntuje :)

    Miłego.
    Irek.N.

strony : 1 . 2 . [ 3 ] . 4 ... 9


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: