eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaProsty klon PicKit2 i procesory PIC32Re: Prosty klon PicKit2 i procesory PIC32
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!pwr.wroc.pl!new
    s.wcss.wroc.pl!not-for-mail
    From: Waldek Hebisch <h...@a...uni.wroc.pl>
    Newsgroups: pl.misc.elektronika
    Subject: Re: Prosty klon PicKit2 i procesory PIC32
    Date: Mon, 23 Nov 2015 08:28:38 +0000 (UTC)
    Organization: Politechnika Wroclawska
    Lines: 92
    Message-ID: <n2uinm$af6$1@z-news.wcss.wroc.pl>
    References: <564673de$0$644$65785112@news.neostrada.pl>
    <56474c09$0$22837$65785112@news.neostrada.pl>
    <n27j3j$o8p$1@node2.news.atman.pl>
    <a...@n...neostrada.pl>
    <n27rje$l7$1@node2.news.atman.pl>
    <a...@n...neostrada.pl>
    <n287ed$c4k$1@node2.news.atman.pl>
    <a...@n...neostrada.pl>
    <n28ahn$f2e$1@node2.news.atman.pl> <n2fcdm$lkb$1@z-news.wcss.wroc.pl>
    <n2fvdi$81d$1@node1.news.atman.pl>
    NNTP-Posting-Host: math.uni.wroc.pl
    X-Trace: z-news.wcss.wroc.pl 1448267318 10726 156.17.86.1 (23 Nov 2015 08:28:38 GMT)
    X-Complaints-To: a...@n...pwr.wroc.pl
    NNTP-Posting-Date: Mon, 23 Nov 2015 08:28:38 +0000 (UTC)
    Cancel-Lock: sha1:xaODW7wEZHsZfsFWnBUd01aZS+g=
    User-Agent: tin/2.2.1-20140504 ("Tober an Righ") (UNIX) (Linux/4.1.3 (x86_64))
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:688968
    [ ukryj nagłówki ]

    Sebastian Bia?y <h...@p...onet.pl> wrote:
    > On 2015-11-17 15:08, Waldek Hebisch wrote:
    > >> Nie. Mam tutaj na tapecie przyklad: potrzebuje 1 instrukcj? na 1 clock i
    > >> hiper szybkie GPIO bez du?ych oblicze?. AVR to daje. Taktowany 3x
    > >> szybciej ARM nie ... Taktowany 10x szybciej ARM kosztuje maj?tek i ma
    > >> footprint wielko?ci 10ciu AVR?w. I pewno wolniejsze GPIO ;)
    > > Mozesz to rozwinac?
    >
    > Mam trywialne zagadnienie, musze wyprodukowa? jak najszybciej zmiany na
    > magistrali adresowej Z80, ale za pomoc? AVR. To znaczy ?e musze jak
    > najszybciej wypycha? rejestry na porty tak aby zaemulowa? odpowied?
    > jakiego? urz?dzenia albo pobra? z niej dane. Nie pytaj po co, retro jako
    > hobby :)
    >
    > Dane s? gotowe w rejestrach, chodzi o ich wypychanie jak najszybciej i w
    > precyzyjnych momentach.

    No, jesli chesz emulowac Z80 to musisz napierw policzyc co
    wyslac na szyne...

    > > Czytajac datasheety widze ze instrucje obslugujace
    > > GPIO w ARM maja sie wykonac w 1 takcie procesora (chyba ze GPIO jest
    > > podwieszone do szyny z wolniejszym zegarem, ale to w modelach majaczych
    > > szybszy zeger).
    >
    > Problemem jest fakt ?e w ARM kod wykonywany z Flash jest wolniejszy ni?
    > wykonywany z RAM. Efektem czego SAM7 poganiany zegarem 60MHz przegrywa?
    > z AVRem poganianym 20MHz. By?em tym bardzo zdziwiony do czasu a? nie
    > doczyta?em ?e Flash ma absurdalnie du?e waitstates. W obu wypadkach by?o
    > mov 0,port; mov 1,port; jump again; Oczywi?cie mog? przenie?? kod do RAM
    > i ju?, ale wtedy okrakiem staje pr?dko?c GPIO w SAM7. I tak si?
    > oduczy?em patrze? na MHz.

    Niestety, flash jest powonly i jest normalne ze procesor ma szybszy
    zegar niz zegar flash-u. Dla liniowych fragmentow kodu powinien
    dzialac prefetch, tylko przy skokach powinny dojsc te waitstates.
    Po tym con napisales zdecydowalem sie sprawdzic jak to wychodzi
    na innych prockach. Na Atemega 328P (jako baza) wychdza 4 cykle
    na okrazenie. Na STM32F051R9T6 ponizsza petla z RAM-u wykonuje
    sie w 7 taktach:

    00000000 <wr_loop>:
    0: 6010 str r0, [r2, #0]
    2: 6011 str r1, [r2, #0]
    4: e7fc b.n 0 <wr_loop>

    Tu korekta do tego co pisalem wczesniej: na Cortexie M0
    zapis i odczyt to 2 takty. Skok to 3, razem 7. Przy
    48 MHz zegarze daje to 6.857 MHz -- pomiar na pinie
    z dokladnoscia do bledu pomiaru daje to samo. To jest
    lepiej niz 5 MHz osiagalne z Atmegi. Oczywiscie 3 takty
    na skok boli w porownaniu z 2 dla Atmegi. Flash moze
    dodac waitstates, ale nie powinno to byc wiecej niz 2
    na skok (a optymistycznie 1). Wiec mysle ze nawet
    przy pracy z flasha Cortex M0 powinien byc szybszy niz
    Atmega.

    > Dla STM32F10xx datasheet podaje ze GPIO przelacza do
    > > 18 MHz
    >
    > Tak, GPIO jest r?wnie? powolne w du?ych procesorach z przyczyn niejasnych.

    Jak rozumiem chodzi o ograniczenie EMI, a przy okazji mozna
    uniknac problemow jak sciezki sa niedopasowane do pinow.
    Ten STM wyzej ma konfigurowalna szybkosc, "high" ma miec
    czasy narastania i opadania ponizej 5 ns przy malym obciazeniu,
    "medium" na czasy ponizej 25 ns, ale to wystarczylo zeby
    bramka LSTTL zlapala impulsy.

    > > wyglada ze gdzis polowa czestoci zegara to maksimum na GPIO.
    > > Wiec taki STM32F10xx powinien wygrac z AVR gdzies do 36 MHz.
    >
    > W moim projekcie jak zauwa?yle? wy?ej potrzeba jest r?wnie? 5V :) Mia?em
    > nadzieje na dsPIC33, ale okaza?o si? ze tam zegar dzielony jest dalej
    > przez 4 wi?c nic nie zyskam.

    5V zasilanie czy zgodnosc z 5V? Jak rozumiem Z80 pracowal na
    poziomach zblizonych do TTL i czesto byly do niego podpiete
    uklady LSTTL. Ten STM ma produkowac syganaly zgodne z TTL
    (pierwszy stopien licznika do zliczania impulsow na pinie
    byl w LSTTL) i wytrzymac 5V na wejsciu, wiec jak mu dodasz
    zasilacz 3.3 V to powinien dzialac na szynie Z80. Oczywiscie
    trzeba by spradzic obciazalnosc, ale 8 mA na pin to chyba
    podobnie do Z80...

    A propo: uklady serii STM32F030 (podstawowe parametry takie
    jak STM32F051) to najtansze procki ktore zauwazylem w
    katalogu Farnella (nie szukalen dlugo wiec moze jest
    cos tanszego).

    --
    Waldek Hebisch

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj

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: