Marek pisze:
> On Sun, 15 Nov 2015 13:11:29 +0000, AlexY <a...@i...pl> wrote:
>> 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

do góry

On Sun, 15 Nov 2015 19:17:08 +0100, janusz_k <J...@o...pl> wrote:
> Jedno pobranie nieefektywne?

A dlaczego jedno?

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

--
Marek

do góry

On Sun, 15 Nov 2015 19:44:01 +0100, Zbych <z...@o...pl> wrote:
> 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?

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

> Za każdym razem jak pada argument, na który nie masz sensownej
> odpowiedzi to pada pytanie "a po co?",

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

> "czy avr to ma?", albo jakieś
> mądrości o furmankach. Jesteś jakoś uczuciowo związany z PIC?

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

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

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

do góry

On Sun, 15 Nov 2015 19:33:20 +0000, AlexY <a...@i...pl> wrote:
> 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.

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

do góry

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

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

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

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

do góry

On Mon, 16 Nov 2015 10:55:03 +0000, AlexY <a...@i...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.

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

do góry

Marek wrote:

> Wolę już upierdliwości C18 (pod strony programistycznej) ale
> 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

do góry

On Mon, 16 Nov 2015 15:00:09 +0100, Piotr Wyderski
<p...@n...mil> wrote:
> 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.

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

do góry

On Sun, 15 Nov 2015 19:19:52 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> 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? Oprócz stosu hardwerowego mają stos softwarowy oraz
rejestry do zarządzania nim (FSR*, STKPTR itd). Kojarzę nawet
wsparcie do 18F w FreeRTOS.

--
Marek

do góry

Sebastian Biały wrote:

> 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

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

Pozdrawiam, Piotr

do góry