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
janusz_k
Guest
Guest
Sun Nov 15, 2015 7:17 pm
W dniu 2015-11-15 o 17:58, Marek pisze:
Quote:
On Sun, 15 Nov 2015 16:18:03 +0100, Zbych <zbych@onet.pl> wrote:
Na tak, przecież przełączanie wątków można robić na minimum na
16-bitach, sorry zapomniałem. Dobrze, że w innych firmach o tej
zasadzie
nie słyszeli.
Atmega posiada mechanizmy sprzętowego wsparcia przełączania wątków czy
wywłaszczenia cpu? Bo przypominam, że mówimy o Atmedze.
Na tak, przecież przełączanie wątków można robić na minimum na
16-bitach, sorry zapomniałem. Dobrze, że w innych firmach o tej
zasadzie
nie słyszeli.
Atmega posiada mechanizmy sprzętowego wsparcia przełączania wątków czy
wywłaszczenia cpu? Bo przypominam, że mówimy o Atmedze.
Nie.
Quote:
A co ma długość rejestrów do możliwości _liniowego_ adresowania?
8080 to potrafił, Z80 to potrafił, ale widać geniusze z microchipa
na to
nie wpadli.
Rotfl, jaka jest różnica między łączeniem rejestrów 8 bitowych w 8080
cxy Z80 (nie wiem po co te przykłady skoro mówimy o Atmedze i PIC) w
jakikolwiek sposób aby poruszać się w 16bit przestrzeni adresowej od
użycia rejestru wyboru banku (wyboru starszego bitu w adresie)? Oba
mechanizmy dają taki sam efekt i są tym samym. Ale to nie oznacza, że są
tak samo wydajnymi metodami w porównaniu do pełnego jednego rejestru
16bitowego, gdzie jest realna (a nie pośrednia) liniowość w zakresie 16
bit adresacji.
Kiedy właśnie w atmedze te dwa rejestry zachowują się jak jeden, tylko
operacje są troche ułomne bo dodawać, odejmować można w zakresie 0-63.
Więc w obsłudze jest dużo prostszy bo nie trzeba przełączać banków.
Quote:
To, że C18 ma problem z odczytem tablic inaczej niż przez wskaźnik (nie
wiem po co robić inny odczyt) to tylko problem tego kompilatora, jest
hitec, jest sdcc a teraz nawet xc8. w tych też ten problem występuje?
Czyli mam uC z 4kB RAMu na pokładzie i zrobienie w nim "wielkiej"
tablicy przekraczającej 256B to przegięcie? Dobrze się czujesz?
Zdefiniuj "większe". Problem jaki podajesz z tą tablicą jest wydumany,
bo zakłada odczyt bez użycia wskaźnika, co w wielu przypadkach jest
niefektywne.
Jedno pobranie nieefektywne?
wiem po co robić inny odczyt) to tylko problem tego kompilatora, jest
hitec, jest sdcc a teraz nawet xc8. w tych też ten problem występuje?
Czyli mam uC z 4kB RAMu na pokładzie i zrobienie w nim "wielkiej"
tablicy przekraczającej 256B to przegięcie? Dobrze się czujesz?
Zdefiniuj "większe". Problem jaki podajesz z tą tablicą jest wydumany,
bo zakłada odczyt bez użycia wskaźnika, co w wielu przypadkach jest
niefektywne.
Jedno pobranie nieefektywne?
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.
--
Pozdr
Janusz_K
janusz_k
Guest
Guest
Sun Nov 15, 2015 7:17 pm
W dniu 2015-11-15 o 18:07, Marek pisze:
Quote:
On Sun, 15 Nov 2015 16:18:03 +0100, Zbych <zbych@onet.pl> wrote:
16-bitach, sorry zapomniałem. Dobrze, że w innych firmach o tej
zasadzie
nie słyszeli.
No to teraz wiem, kogo konkretnie miał na myśli Sebastian pisząc o
polskich wynalazcach najszybszych na świecie furmanek :-)
Głośno o tym było
16-bitach, sorry zapomniałem. Dobrze, że w innych firmach o tej
zasadzie
nie słyszeli.
No to teraz wiem, kogo konkretnie miał na myśli Sebastian pisząc o
polskich wynalazcach najszybszych na świecie furmanek :-)
Głośno o tym było
--
Pozdr
Janusz_K
Sebastian BiaĹy
Guest
Guest
Sun Nov 15, 2015 7:19 pm
On 2015-11-15 17:58, Marek wrote:
Quote:
Atmega posiada mechanizmy sprzętowego wsparcia przełączania wątków czy
wywłaszczenia cpu? Bo przypominam, że mówimy o Atmedze.
wywłaszczenia cpu? Bo przypominam, że mówimy o Atmedze.
Atmega nie przeszkadza w wywlaszczaniu.
PIC (stary) przeszkadza w wywłaszczaniu.
Pi x drzwi na tym polega różnica. Oba nie mają żadnego wsparcia
sprzętowego i prawde mowiąc - znacznie większe procesory nie mają. Ważne
żeby nie przeszkadzać.
Prawda jest taka że PICa zaprojektował elektronik zaś AVRa programista.
Widać to po ograniczeniach obu arch.
janusz_k
Guest
Guest
Sun Nov 15, 2015 7:25 pm
Quote:
A nie z rdzeniem ARM? No bo tak na prawdę po co hobbyscie 8 bitowy mcu z
jego wszystkimi ograniczeniami 8bitowca? Kiedy pojawiły się pic32mx w
wersji dip28, wygodne w prototypowaniu uznałem, że chrzanić 8bitowce.
Pomijając wąskie zastosowanie gdzie taki 8bitowiec z XLP (eXtreme Low
Power) przydaje się w aplikacji zasilanej bateryjnie, to poza tym nie
widzę zalet w ich stosowaniu w hobby czy w domu i zagrodzie.
Mylisz się, po pierwsze łatwiejszy w nauczeniu, po drugie 95% projektów
jego wszystkimi ograniczeniami 8bitowca? Kiedy pojawiły się pic32mx w
wersji dip28, wygodne w prototypowaniu uznałem, że chrzanić 8bitowce.
Pomijając wąskie zastosowanie gdzie taki 8bitowiec z XLP (eXtreme Low
Power) przydaje się w aplikacji zasilanej bateryjnie, to poza tym nie
widzę zalet w ich stosowaniu w hobby czy w domu i zagrodzie.
Mylisz się, po pierwsze łatwiejszy w nauczeniu, po drugie 95% projektów
amatorów nie wykorzystuje mocy obliczeniowej 8 bitowca a co dopiero 32.
One w sumie bardziej przeszkadzają niż pomagają.
Dopiero skomplikowane obliczenia zmiennoprzecinkowe wymagają 32-bitowca.
Piszę skomplikowane bo widziałem kilka projektów DFT robionych na 8
bitach które sensownie chodziły.
A że naprawiam sprzęt profesjonalny to mam szerszy ogląd co jest
używane, większość sterowników czy prostych terminali chodzi na 8 bitach
mocniejsze procki są dopiero w kolorowych terminalach z dotykiem,
falownikach i serwach, nowych plc.
--
Pozdr
Janusz_K
Zbych
Guest
Guest
Sun Nov 15, 2015 7:44 pm
On 15.11.2015 17:58, Marek wrote:
Quote:
On Sun, 15 Nov 2015 16:18:03 +0100, Zbych <zbych@onet.pl> wrote:
Na tak, przecież przełączanie wątków można robić na minimum na
16-bitach, sorry zapomniałem. Dobrze, że w innych firmach o tej
zasadzie
nie słyszeli.
Atmega posiada mechanizmy sprzętowego wsparcia przełączania wątków czy
wywłaszczenia cpu? Bo przypominam, że mówimy o Atmedze.
Na tak, przecież przełączanie wątków można robić na minimum na
16-bitach, sorry zapomniałem. Dobrze, że w innych firmach o tej
zasadzie
nie słyszeli.
Atmega posiada mechanizmy sprzętowego wsparcia przełączania wątków czy
wywłaszczenia cpu? Bo przypominam, że mówimy o Atmedze.
Czy to co ma AVR wpływa jakoś na brak ograniczeń w PICach?
Nie bardzo rozumiem po co za każdym razem wywlekasz jakiegoś AVRa?
A odpowiadając na pytanie - nie, nie ma sprzętowego wsparcia, ale daje
możliwość przełączania wątków. Antyczna '51 to dawała.
Quote:
To, że C18 ma problem z odczytem tablic inaczej niż przez wskaźnik (nie
wiem po co robić inny odczyt)
wiem po co robić inny odczyt)
Za każdym razem jak pada argument, na który nie masz sensownej
odpowiedzi to pada pytanie "a po co?", "czy avr to ma?", albo jakieś
mądrości o furmankach. Jesteś jakoś uczuciowo związany z PIC?
Quote:
Czyli mam uC z 4kB RAMu na pokładzie i zrobienie w nim "wielkiej"
tablicy przekraczającej 256B to przegięcie? Dobrze się czujesz?
Zdefiniuj "większe".
tablicy przekraczającej 256B to przegięcie? Dobrze się czujesz?
Zdefiniuj "większe".
np. 573B.
Quote:
Problem jaki podajesz z tą tablicą jest wydumany,
bo zakłada odczyt bez użycia wskaźnika, co w wielu przypadkach jest
niefektywne.
bo zakłada odczyt bez użycia wskaźnika, co w wielu przypadkach jest
niefektywne.
To czy ja użyję w sposób jawny wskaźnika, czy nie, nie ma znaczenia.
Kompilator niech pod spodem tak to robi, żeby było efektywnie.
Ja chcę mieć dostęp w liniowy sposób do całej wbudowanej pamięci.
AlexY
Guest
Guest
Sun Nov 15, 2015 8:33 pm
Marek pisze:
Quote:
On Sun, 15 Nov 2015 13:11:29 +0000, AlexY <alexy@irc.pl> wrote:
Dostałem w prezencie szynę nowych PICów (16F877), ucieszyłem się
Daj sobie spokój z 16F.
Dostałem w prezencie szynę nowych PICów (16F877), ucieszyłem się
Daj sobie spokój z 16F.
Bo?
Dałem sobie spokój z PICami w ogóle, ta kość ma ze 2 razy więcej zasobów
i bajerów aniżeli potrzebowałem, odpuściłem głównie z powodu zagmatwanej
obsługi SFR i pamięci RAM oraz bezsensownej obsługi tablic w pamięci
programu, a potrzebowałem generator znaków dla LCD graficznego.
--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html
Marek
Guest
Guest
Sun Nov 15, 2015 8:37 pm
On Sun, 15 Nov 2015 19:17:08 +0100, janusz_k <Janusz_kk@o2.pl> wrote:
Quote:
Jedno pobranie nieefektywne?
A dlaczego jedno?
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.
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
.
--
Marek
Marek
Guest
Guest
Sun Nov 15, 2015 9:15 pm
On Sun, 15 Nov 2015 19:44:01 +0100, Zbych <zbych@onet.pl> wrote:
Quote:
Czy to co ma AVR wpływa jakoś na brak ograniczeń w PICach?
Nie bardzo rozumiem po co za każdym razem wywlekasz jakiegoś AVRa?
Nie bardzo rozumiem po co za każdym razem wywlekasz jakiegoś AVRa?
No bo nie wiem czy zauważyłeś ale dyskusja jest o wadach i zaletach
avr i pic (core pic16 żeby było z czym porównywać)
Quote:
Za każdym razem jak pada argument, na który nie masz sensownej
odpowiedzi to pada pytanie "a po co?",
odpowiedzi to pada pytanie "a po co?",
Ależ gdyby były to argumenty w ramach granic tematu to słowa bym nie
powiedział :)
Quote:
"czy avr to ma?", albo jakieś
mądrości o furmankach. Jesteś jakoś uczuciowo związany z PIC?
mądrości o furmankach. Jesteś jakoś uczuciowo związany z PIC?
Nie ukrywam tego, inaczej głosu bym nie zabierał.
Quote:
Kompilator niech pod spodem tak to robi, żeby było efektywnie.
Ja chcę mieć dostęp w liniowy sposób do całej wbudowanej pamięci.
Ja chcę mieć dostęp w liniowy sposób do całej wbudowanej pamięci.
Tu zgoda, dlatego nie przemawia do mnie argument, że skoro kompilator
zły to mcu też do bani. Można zmienić kompilator.
A nawet odwrotnie. Kiedyś używałem sdcc bo jest wygodniejszy w
pewnych aspektach programistycznych (nie odróżnia wsk. do ram i
flash) no i jest otwarty ale generuje kod nieoptymalny pod kątem
rozmiaru. Wróciłem do C18, bo daje prawie o połowę mniejszy kod. Wolę
już upierdliwości C18 (pod strony programistycznej) ale przynajmniej
generuje kod optymalny pod architekturę do jakiej został stworzony.
--
Marek
Marek
Guest
Guest
Sun Nov 15, 2015 9:39 pm
On Sun, 15 Nov 2015 19:33:20 +0000, AlexY <alexy@irc.pl> wrote:
Quote:
Bo?
Dałem sobie spokój z PICami w ogóle, ta kość ma ze 2 razy więcej
zasobów
i bajerów aniżeli potrzebowałem, odpuściłem głównie z powodu
zagmatwanej
obsługi SFR i pamięci RAM Wiekóworaz bezsensownej obsługi tablic w
pamięci
programu, a potrzebowałem generator znaków dla LCD graficznego.
Dałem sobie spokój z PICami w ogóle, ta kość ma ze 2 razy więcej
zasobów
i bajerów aniżeli potrzebowałem, odpuściłem głównie z powodu
zagmatwanej
obsługi SFR i pamięci RAM Wiekóworaz bezsensownej obsługi tablic w
pamięci
programu, a potrzebowałem generator znaków dla LCD graficznego.
Własnie dlatego.
Jest to architektura nieprzyjazna C*, kompatybilna z 25 letnim 16F84,
raczej do programowania w asemblerze, co przy tej arch. to koszmar.
Na zasoby nie patrz, Microchip zawsze wsadza co się da nawet do
prymitywnego mcu tej klasy.
Nie wiem czemu userzy z doświadczeniami z Atmegą a chcący poznać pice
wybierają często 16F, które są rząd klasy w tyle za Atmegami.
Oczywiście to szybko wychodzi więc później mówią że pice (wszystkie)
są do bani.
Jeśli ktoś zna Atmegę i programuje w C to powinien wybierać układy
18F, szczególnie układy serii J które mają super precyzyjne wew.
oscylatory albo K które mają 64MHz PLL.
*- co nie oznacza, że nie ma kompilatorów C do nich.
--
Marek
AlexY
Guest
Guest
Mon Nov 16, 2015 11:55 am
Marek pisze:
[..]
Quote:
Nie wiem czemu userzy z doświadczeniami z Atmegą a chcący poznać pice
wybierają często 16F, które są rząd klasy w tyle za Atmegami. Oczywiście
to szybko wychodzi więc później mówią że pice (wszystkie) są do bani.
wybierają często 16F, które są rząd klasy w tyle za Atmegami. Oczywiście
to szybko wychodzi więc później mówią że pice (wszystkie) są do bani.
Akurat takie dostałem za friko, firma gdzie kolega robił przestała ich
używać i reszta miała iść do utylizacji.
Quote:
Jeśli ktoś zna Atmegę i programuje w C to powinien wybierać układy 18F,
szczególnie układy serii J które mają super precyzyjne wew. oscylatory
albo K które mają 64MHz PLL.
szczególnie układy serii J które mają super precyzyjne wew. oscylatory
albo K które mają 64MHz PLL.
No to nie o mnie, jeszcze nie znam atmeg i nie piszę w C, tylko assembler.
--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html
Marek
Guest
Guest
Mon Nov 16, 2015 2:44 pm
On Mon, 16 Nov 2015 10:55:03 +0000, AlexY <alexy@irc.pl> wrote:
Quote:
No to nie o mnie, jeszcze nie znam atmeg i nie piszę w C, tylko
assembler.
assembler.
Szczere wyrazy współczucia
, szczególnie jeśli miałbyś męczyć
assembler w tych 16F.
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...
--
Marek
Piotr Wyderski
Guest
Guest
Mon Nov 16, 2015 3:00 pm
Marek wrote:
Quote:
Wolę już upierdliwości C18 (pod strony programistycznej) ale
przynajmniej generuje kod optymalny pod architekturę do jakiej został
stworzony.
przynajmniej generuje kod optymalny pod architekturę do jakiej został
stworzony.
Ale dopiero w trybie "jak se kupisz", bo wersja free nie ma
włączonej optymalizacji. Co w 21. wieku jest absurdem i raczej
powinno odstraszać od wejścia w PICe, zwłaszcza te duże. Na
ARM jest darmowy i bardzo dobry kompilator.
Pozdrawiam, Piotr
Marek
Guest
Guest
Mon Nov 16, 2015 3:31 pm
On Mon, 16 Nov 2015 15:00:09 +0100, Piotr Wyderski
<peter.pan@neverland.mil> wrote:
Quote:
Ale dopiero w trybie "jak se kupisz", bo wersja free nie ma
włączonej optymalizacji. Co w 21. wieku jest absurdem i raczej
powinno odstraszać od wejścia w PICe, zwłaszcza te duże. Na
ARM jest darmowy i bardzo dobry kompilator.
włączonej optymalizacji. Co w 21. wieku jest absurdem i raczej
powinno odstraszać od wejścia w PICe, zwłaszcza te duże. Na
ARM jest darmowy i bardzo dobry kompilator.
Zgodzę się, płatne narzędzia w takim przypadku i w dzisiejszych
czasach to nieporozumienie, szczególnie gdy konkurencja udostępnia
utilsy za darmo bez ograniczeń funkcjonalnych.
Dla mnie wygląda to, że w Mchp w marketingu siedzi jakąś grupa
oszołomów, lub są pod jakimś wpływem. Co z resztą sami potwierdzili
pośrednio w filmie będącym odpowiedzią na krytykę pickita3.
--
Marek
Marek
Guest
Guest
Mon Nov 16, 2015 3:45 pm
On Sun, 15 Nov 2015 19:19:52 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:
Quote:
Atmega nie przeszkadza w wywlaszczaniu.
PIC (stary) przeszkadza w wywłaszczaniu.
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? Oprócz stosu hardwerowego mają stos softwarowy oraz
rejestry do zarządzania nim (FSR*, STKPTR itd). Kojarzę nawet
wsparcie do 18F w FreeRTOS.
--
Marek
Piotr Wyderski
Guest
Guest
Mon Nov 16, 2015 5:20 pm
Sebastian Biały wrote:
Quote:
PS. Absurdalność programatora PICów (dziwaczne napiecia, zamkniety arch,
kiepska dokumentacja, brak alternatyw itd) trzyma mnie od lat z daleka
od PICów. Może to kiepski argument, ale start z byle czym innym jak AVR
czy STM32 jest o niebo wygodniejszy
kiepska dokumentacja, brak alternatyw itd) trzyma mnie od lat z daleka
od PICów. Może to kiepski argument, ale start z byle czym innym jak AVR
czy STM32 jest o niebo wygodniejszy
Tylko niestety AVR mają bardzo biedne peryferia. Z tego powodu
nigdy nie było mi szkoda ich porzucenia na rzecz PICów.
Pozdrawiam, Piotr
elektroda NewsGroups Forum Index - Elektronika Polska - Czy programator PicKit2 w prostym klonie obsługuje procesory PIC32 z napięciem 3,3V?