Prosty klon PicKit2 i procesory PIC32

Atmega posiada mechanizmy sprzętowego wsparcia przełączania wątków czy wywłaszczenia cpu? Bo przypominam, że mówimy o Atmedze.

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

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.

A czy nie są to czasem łączone rejestry jak w 8080, przy czym zapis odczyt i tak jest w 8bit. kawałkach?

No to teraz wiem, kogo konkretnie miał na myśli Sebastian pisząc o polskich wynalazcach najszybszych na świecie furmanek :-)

Tak są łączone i odczyt w kawałkach ale co to ma za znaczenie? operacje są robione na obu tzn word i to jest istotne, służą do adresacji pamięci.

Nie.

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.

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.

Głośno o tym było :)

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.

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.

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.

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?

np. 573B.

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.

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.

A dlaczego jedno?

Momencik, ale żeby w Atmedze móc wywołać ten rozkaz adres trzeba gdzieś załadować, prawda? Coś tu na skróty idziesz :).

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

Ależ gdyby były to argumenty w ramach granic tematu to słowa bym nie powiedział :)

Nie ukrywam tego, inaczej głosu bym nie zabierał.

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.

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 pisze: [..]

Akurat takie dostałem za friko, firma gdzie kolega robił przestała ich używać i reszta miała iść do utylizacji.

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.

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

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

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.

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.

Tylko niestety AVR mają bardzo biedne peryferia. Z tego powodu nigdy nie było mi szkoda ich porzucenia na rzecz PICów.

Pozdrawiam, Piotr