Prosty klon PicKit2 i procesory PIC32

Pierwszy raz widzę, by ktoś narzekał na *nadmiar* zasobów. :-))) Niewykorzystaną powierzchnię krzemu obłożyli podatkiem katastralnym? ;-)

Ja sobie nie mogę wybaczyc, ile czasu zmarnowałem na obchodzenie ograniczeń niepełnosprawnych już u poczęcia peryferiów w AVRkach...

Pozdrawiam, Piotr

sam napisałeś "Problem jaki podajesz z tą tablicą jest wydumany, bo zakłada odczyt bez użycia wskaźnika, co w wielu przypadkach jest niefektywne."

Sam napisałeś o odczycie bez wskaźnika, czyli nie przeszukujemy tablicy za pomocą rejestru idexowego tylko czytamy sobie jeden bajt gdzieś z pamięci, wolno? wolno. I dla tego przypadku się odniosłem, w atmedze można odczytać dowolny bajt z ram jedną instrukcją dwu słowową czyli ma długość 32 bity, ale nadal jest to jedna instrukcja "LDS Rd,k" gdzie Rd to dowolny rejestr

Nie, adres jest w rozkazie, napisałem wyżej. To ty musisz załadować adres do rej indexowego i to nawet dwa razy, Lo, Hi bajt a potem dopiero wykonać operację, czyli w sumie trzy instrukcje.

Byc moze - wszak mniejszego kawalka niz jakis tam sie nie nie da zamontowac :-)

Ale to masz na mysli PIC, PIC32, dsPIC ?

Bo mi sie tam wydaje, ze wczesne PICe byly ulomne nawet bardziej niz AVR ...

J.

Napisałem "stary". W zwiazku z tym cała reszta wypowiedzi mija sie z celem.

Ale dalej dzielą to przez 4 czy tam jest lepiej niż w starszych?

Po prostu te same zasoby są w 18F, więcej pamięci, 64Mhz PLL. Wiem, że XC8 supportuje już 16F ale mimo wszystko 18F są bardziej zaawansowane.

Nadal jest Fosc/4, to podstawa tej religi ;). Natomiast Fosc/1 może być wejściem dla timera.

Pisanie programu szło nawet nieźle do czasu owego generatora znaków, na pewniaka po staremu zacząłem szukać polecenia odczytu pamięci programu i mi kopara opadła jak zobaczyłem jak to się robi, peryferia fakt ma fajne ale procek jest tak upierdliwy że zwyczajnie odpuściłem.

W tym celu bazuję na algorytmach, poszczególne bloki tłumaczę na assembler.

Mozesz to rozwinac? 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). Dla STM32F10xx datasheet podaje ze GPIO przelacza do

Dla LM4F120H5QR (marketing zmienil numer na TM... ale o ile wiem parametry maja byc te same) Ti podaje o GPIO:

: Fast toggle capable of a change every clock cycle for ports on AHB, every : two clock cycles for ports on APB

przy 80 MHz to wyglada duzo lepiej niz AVR. Fakt ze to drozszy model, ale nie najwysza polka.

Co przegapilem?

No, jak chcesz naprawde szybkie CPU to sie wstawia bufory na IO, a wtedy sa dodatkoww opoznienia w porownaniu z CPU ktore ma wolniejszy zeger i nie buforuje IO...

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.

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.

Dla STM32F10xx datasheet podaje ze GPIO przelacza do

Tak, GPIO jest również powolne w dużych procesorach z przyczyn niejasnych.

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.

Nic. Do wyboru jest wiele szybkich cpu, ale niektórych nie ma sensu do zabawy z różnych względów brac: albo 3.3V, albo obudowa z miliardem nózek, albo 7 napięć zasilających, itd.

Nie, nie chce. Chce odpowiednie narzedzie do problemu. Wydaje się że PIC się nie sprawdzi a AVR tak.

Jakośv ciągle stosujesz ogólniki "jak najszybciej" zamiast podać konkretne liczby. Ile w Mhz wachlowanie pinem Cię zadowoli 20Mhz,

Potrzebuje minimum około 10 cykli cpu (najlepiej >16 bo wtedy mam swobodę) pomiedzy 1 cyklem zegara Z80, taktowanie powiedzmy 3MHz. Czyli potrzebuje w moim cpu 30MIPSów licząc instrukcję na cykl, tak na start, oraz spodziewam się że GPIO bedzie machało tak samo szybko. Ponadto liczy się też asm, np. niezwykle byłby wygodny skok przez tablicę adresów we flash.

On 2015-11-15 19:25, janusz_k wrote: [...]

Bez przesady z tą trudnością. IMO np. AVR i ARM7TDMI to "the same s*it". Jednak MCU 32-bitowy pozwala uniknąć programiście niektórych upierdliwości, ot, np. atomowe dodawanie liczb "szerszych" niż 8-bitowe. No i fakt, do realizacji jakiegoś urządzenia często nie są potrzebne jakieś duże ilości (D)MIPS-ów, ale np. potrzeba sporo pamięci danych i pod tym względem 32-bitowce są z reguły lepiej wyposażone co pozwala na umieszczenie na PCB jednej kostki zamiast MCU i dodatkowego RAM-u.

On 2015-11-14 13:42, Marek wrote: [...]

tego d*****ad manager-a. :-D

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

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:

Tu korekta do tego co pisalem wczesniej: na Cortexie M0 zapis i odczyt to 2 takty. Skok to 3, razem 7. Przy

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.

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).