NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Czy programator PicKit2 w prostym klonie obsługuje procesory PIC32 z napięciem 3,3V?
Goto page Previous 1, 2, 3, 4, 5, 6 Next
Piotr Wyderski
Guest
Guest
Mon Nov 16, 2015 6:34 pm
Marek wrote:
Quote:
Daj sobie spokój z 16F.
Czemu, 1709 JEST FAJNY!!!
))
Pozdrawiam, Piotr
Piotr Wyderski
Guest
Guest
Mon Nov 16, 2015 6:37 pm
Marek wrote:
Quote:
Na zasoby nie patrz, Microchip zawsze wsadza co się da nawet do
prymitywnego mcu tej klasy.
prymitywnego mcu tej klasy.
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
janusz_k
Guest
Guest
Mon Nov 16, 2015 6:53 pm
W dniu 2015-11-15 o 20:37, Marek pisze:
Quote:
On Sun, 15 Nov 2015 19:17:08 +0100, janusz_k <Janusz_kk@o2.pl> wrote:
Jedno pobranie nieefektywne?
A dlaczego jedno?
sam napisałeś "Problem jaki podajesz z tą tablicą jest wydumany, bo
Jedno pobranie nieefektywne?
A dlaczego jedno?
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
0-32 a k liczba 0 - 65535.
Quote:
W atmedze jest to jeden rozkaz 2*word, a ty musisz wpier załądować
rejestr indexowy a później dopiero wczytać daną adresując ją tym
rejestrem, czyli dwie a nawet trzy operacje.
Momencik, ale żeby w Atmedze móc wywołać ten rozkaz adres trzeba gdzieś
załadować, prawda? Coś tu na skróty idziesz
.
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.
--
Pozdr
Janusz_K
J.F.
Guest
Guest
Mon Nov 16, 2015 6:55 pm
Użytkownik "Piotr Wyderski" napisał w wiadomości grup
dyskusyjnych:n2d498$b4f$1@node1.news.atman.pl...
Marek wrote:
Quote:
Na zasoby nie patrz, Microchip zawsze wsadza co się da nawet do
prymitywnego mcu tej klasy.
Pierwszy raz widzę, by ktoś narzekał na *nadmiar* zasobów.))
Niewykorzystaną powierzchnię krzemu obłożyli podatkiem katastralnym?
prymitywnego mcu tej klasy.
Pierwszy raz widzę, by ktoś narzekał na *nadmiar* zasobów.
))
Niewykorzystaną powierzchnię krzemu obłożyli podatkiem katastralnym?
Byc moze - wszak mniejszego kawalka niz jakis tam sie nie nie da
zamontowac :-)
Quote:
Ja sobie nie mogę wybaczyc, ile czasu zmarnowałem na obchodzenie
ograniczeń niepełnosprawnych już u poczęcia peryferiów w AVRkach...
ograniczeń niepełnosprawnych już u poczęcia peryferiów w AVRkach...
Ale to masz na mysli PIC, PIC32, dsPIC ?
Bo mi sie tam wydaje, ze wczesne PICe byly ulomne nawet bardziej niz
AVR ...
J.
Sebastian BiaĹy
Guest
Guest
Mon Nov 16, 2015 7:15 pm
On 2015-11-16 15:45, Marek wrote:
Quote:
Atmega nie przeszkadza w wywlaszczaniu.
PIC (stary) przeszkadza w wywłaszczaniu.
Powolutku. Już ustaliliśmy, że pice z corem 14 bit ("stare" czyli 16F i
mniejsze) są do bani i ich nie bierzemy pod uwagę w porównywaniu z
Atmegą, bo tu nie ma co porównywać. W czym przeszkadzają 18F w tworzeniu
wątków?
PIC (stary) przeszkadza w wywłaszczaniu.
Powolutku. Już ustaliliśmy, że pice z corem 14 bit ("stare" czyli 16F i
mniejsze) są do bani i ich nie bierzemy pod uwagę w porównywaniu z
Atmegą, bo tu nie ma co porównywać. W czym przeszkadzają 18F w tworzeniu
wątków?
Napisałem "stary". W zwiazku z tym cała reszta wypowiedzi mija sie z celem.
Sebastian BiaĹy
Guest
Guest
Mon Nov 16, 2015 7:24 pm
On 2015-11-15 21:39, Marek wrote:
Quote:
albo K które mają 64MHz PLL.
Ale dalej dzielą to przez 4 czy tam jest lepiej niż w starszych?
Marek
Guest
Guest
Mon Nov 16, 2015 9:58 pm
On Mon, 16 Nov 2015 18:37:43 +0100, Piotr Wyderski
<peter.pan@neverland.mil> wrote:
Quote:
Pierwszy raz widzę, by ktoś narzekał na *nadmiar* zasobów. ))
))
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.
--
Marek
Marek
Guest
Guest
Mon Nov 16, 2015 10:00 pm
On Mon, 16 Nov 2015 19:24:57 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:
Quote:
Ale dalej dzielą to przez 4 czy tam jest lepiej niż w starszych?
Nadal jest Fosc/4, to podstawa tej religi
.
Natomiast Fosc/1 może być wejściem dla timera.
--
Marek
AlexY
Guest
Guest
Tue Nov 17, 2015 12:54 am
Marek pisze:
Quote:
On Mon, 16 Nov 2015 10:55:03 +0000, AlexY <alexy@irc.pl> wrote:
No to nie o mnie, jeszcze nie znam atmeg i nie piszę w C, tylko
assembler.
Szczere wyrazy współczucia, szczególnie jeśli miałbyś męczyć
assembler w tych 16F.
No to nie o mnie, jeszcze nie znam atmeg i nie piszę w C, tylko
assembler.
Szczere wyrazy współczucia
, szczególnie jeśli miałbyś męczyć
assembler w tych 16F.
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.
Quote:
Kiedyś popełniłem na tych układach prosty sterownik włącz/wyłącz z
modemem gsm. Całość w assemblerze (było to zanim przeszedłem na 18F i
C), modem nie obsługiwał trybu text w smsach tylko pdu no więc
machnąłem pdu encoder/decoder w tym assemblerze. Efekt był taki, że po
dwóch dniach przerwy od napisania działającej wersji mimo komentarzy za
cholerę nie mogłem się połapać o co chodziło "autorowi" w tym kodzie...
modemem gsm. Całość w assemblerze (było to zanim przeszedłem na 18F i
C), modem nie obsługiwał trybu text w smsach tylko pdu no więc
machnąłem pdu encoder/decoder w tym assemblerze. Efekt był taki, że po
dwóch dniach przerwy od napisania działającej wersji mimo komentarzy za
cholerę nie mogłem się połapać o co chodziło "autorowi" w tym kodzie...
W tym celu bazuję na algorytmach, poszczególne bloki tłumaczę na assembler.
--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html
Waldek Hebisch
Guest
Guest
Tue Nov 17, 2015 4:08 pm
Sebastian Bia?y <heby@poczta.onet.pl> wrote:
Quote:
On 2015-11-14 22:45, Marek wrote:
?e najlepszym rozwi?zaniem by?yby peryferia PICa z rdzeniem AVR.
A nie z rdzeniem ARM?
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
?e najlepszym rozwi?zaniem by?yby peryferia PICa z rdzeniem AVR.
A nie z rdzeniem ARM?
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? 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
18 MHz, to duzo mniej niz maksymalny zegar, ale porownywalne z
AVR przy 18 MHz zegarze. Do tego w praktyce dane do GPIO trzeba
jakos wyprodukowac, a z odzcztanymi danymi cos zrobic. Wiec
wyglada ze gdzis polowa czestoci zegara to maksimum na GPIO.
Wiec taki STM32F10xx powinien wygrac z AVR gdzies do 36 MHz.
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?
Quote:
Dla pr?dko?ci. ARMy sa wolniejsze ni? si? wydaje po MHz. Ogolnie im
szybszy procesor w MHz tym wolniejsze GPIO Taka obserwacja, nie
zawsze trze?wa.
szybszy procesor w MHz tym wolniejsze GPIO
Taka obserwacja, nie
zawsze trze?wa.
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...
--
Waldek Hebisch
Sebastian BiaĹy
Guest
Guest
Tue Nov 17, 2015 8:32 pm
On 2015-11-17 15:08, Waldek Hebisch wrote:
Quote:
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?
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.
Quote:
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).
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.
Dla STM32F10xx datasheet podaje ze GPIO przelacza do
Quote:
18 MHz
Tak, GPIO jest również powolne w dużych procesorach z przyczyn niejasnych.
Quote:
wyglada ze gdzis polowa czestoci zegara to maksimum na GPIO.
Wiec taki STM32F10xx powinien wygrac z AVR gdzies do 36 MHz.
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.
Quote:
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?
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?
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.
Quote:
No, jak chcesz naprawde szybkie CPU
Nie, nie chce. Chce odpowiednie narzedzie do problemu. Wydaje się że PIC
się nie sprawdzi a AVR tak.
Marek
Guest
Guest
Tue Nov 17, 2015 11:23 pm
On Tue, 17 Nov 2015 20:32:41 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:
Quote:
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
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
Jakośv ciągle stosujesz ogólniki "jak najszybciej" zamiast podać
konkretne liczby. Ile w Mhz wachlowanie pinem Cię zadowoli 20Mhz,
100Mhz, 1000Mhz?
--
Marek
Sebastian BiaĹy
Guest
Guest
Wed Nov 18, 2015 7:57 pm
On 2015-11-17 23:23, Marek wrote:
Quote:
jakiegoś urządzenia albo pobrać z niej dane. Nie pytaj po co, retro
jako
hobby
Jakośv ciągle stosujesz ogólniki "jak najszybciej" zamiast podać
konkretne liczby. Ile w Mhz wachlowanie pinem Cię zadowoli 20Mhz,
100Mhz, 1000Mhz?
jako
hobby
Jakośv ciągle stosujesz ogólniki "jak najszybciej" zamiast podać
konkretne liczby. Ile w Mhz wachlowanie pinem Cię zadowoli 20Mhz,
100Mhz, 1000Mhz?
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.
JDX
Guest
Guest
Thu Nov 19, 2015 1:29 pm
On 2015-11-15 19:25, janusz_k wrote:
[...]
Quote:
Mylisz się, po pierwsze łatwiejszy w nauczeniu, po drugie 95% projektów
amatorów nie wykorzystuje mocy obliczeniowej 8 bitowca a co dopiero 32.
Bez przesady z tą trudnością. IMO np. AVR i ARM7TDMI to "the same shit".
amatorów nie wykorzystuje mocy obliczeniowej 8 bitowca a co dopiero 32.
Bez przesady z tą trudnością. IMO np. AVR i ARM7TDMI to "the same shit".
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.
JDX
Guest
Guest
Thu Nov 19, 2015 2:01 pm
On 2015-11-14 13:42, Marek wrote:
[...]
Quote:
http://www.youtube.com/watch?v=LjfIS65mwn8
Po czym Microchip odpowiedział mu tym filmem :-)
http://www.youtube.com/watch?v=3YUvlrVlNao
Hehe, jak oglądałem Dave'a to od razu pomyślałem, że przyczepią się do
Po czym Microchip odpowiedział mu tym filmem :-)
http://www.youtube.com/watch?v=3YUvlrVlNao
Hehe, jak oglądałem Dave'a to od razu pomyślałem, że przyczepią się do
tego dickhead manager-a.
elektroda NewsGroups Forum Index - Elektronika Polska - Czy programator PicKit2 w prostym klonie obsługuje procesory PIC32 z napięciem 3,3V?