eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaRynek pracy STM32Re: Rynek pracy STM32
  • Data: 2022-07-21 14:17:25
    Temat: Re: Rynek pracy STM32
    Od: Piotr Gałka <p...@c...pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    W dniu 2022-07-21 o 12:53, Janusz pisze:
    > W dniu 2022-07-21 o 09:28, heby pisze:
    >> On 21/07/2022 09:20, Janusz wrote:
    >>>> Zaraz po tym jak określisz dlaczego dynamiczny polimorfizm działa na
    >>>> moim Harvardzie.
    >>> A w którym miejscu napisałem że nie może?
    >>
    >> Tutaj:
    >>
    >> On 19/07/2022 18:35, Janusz wrote:
    >>  >> Jak to zaprząc do realizacji różnych funkcji przez każdą kopię (nie
    >>  >> wiem jak to się nazywa) tego templates.
    >>  > 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.
    >>
    >> Co prawda dotyczy to statycznego, ale tym gorzej dla Ciebie.
    > Co gorzej, odpowiedz na pytanie, czy avr wykona program z ramu?
    >

    Janusz,
    sorry, ale dzielnie bronisz pozycji nie do obrony.

    Kluczowe słówko: 'bo'.
    Kwestia nie wykonywania z RAMu była użyta tylko jako wytłumaczenie
    dlaczego do głównej tezy, że program wygenerowany z templates nie
    pójdzie w avr.
    Chodzi o prawdziwość/nie prawdziwość tej głównej tezy a nie użytego
    argumentu za nią.

    Skojarzenie....
    Kiedyś (+- 1990) potrzebowaliśmy aby 8751 'wykonywał' program ze swojego
    RAMu (128 bajtów).
    Zrealizowaliśmy to jako interpreter programu pisanego w opracowanym
    przez nas języku na bazie języka Forth (opiera się na odwrotnej notacji
    Polskiej).
    Interpretacja pojedynczego rozkazu średnio zajmowała 10us (rozkaz
    maszynowy zajmował 1us).

    Oczywiście brat napisał ten interpreter ale wszystkie programy w tym
    Forth pisałem ja. Czyli każdy z programów musiał być zapisany na mniej
    niż 128 bajtach (no bo jeszcze stos procesora i dane).

    To były programy do programowania poszczególnych GALi różnych
    producentów (każdy rozmiar GALa * każdy producent to osobny program) i
    do programowania poszczególnych EEPROMów szeregowych (I?C, SPI,
    microWire i kilku innych).
    W ten sposób załatwiliśmy to, że mogliśmy rozszerzać gamę programowanych
    elementów bez konieczności upgradeowania oprogramowania (w tamtym czasie
    konkurencyjne programatory wymagały w tym celu odesłania do producenta).

    Bardzo dokładnie musiałem panować nad RAMem - gdy program ładował
    pierwszy blok danych do programowania to zazwyczaj niszczył swój
    początek. Rozmiar używanego w danym programie bloku danych dobierałem
    tak, aby zniszczenie nie sięgnęło głównej pętli.
    Liczba bajtów potrzebna na stos procesora zależała od treści mojego
    programu (ile zagłębień pętli) i uwzględniałem to w poczatkowym
    ustawieniu wskaźników.

    Wiem, że już kiedyś na p.m.e to pisałem, ale siła skojarzenia z "nie
    wykonuje programu z ram-u".
    P.G.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

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: