[elektro] MPLAB-X, PICKIT3, mikroC

[hobilobi at gmail.com]

Nem kívánok hitvitát nyitni, se részt venni benne.
Kinek a pap, kinek a papné, nekem a .......

Mindössze a véleményemet írtam le. Anyázni meg végképp nem fogok.



2015.09.21. 15:50 keltezéssel, Steve írta:
> Nagyon fontolgattam, hogy belemenjek-e egy ilyen hitvitába, ezekből
> mindig anyázás lesz.
> 1. A váltásról: A PIC-et megjelenése óta (1992??? nem emlékszem)
> használtam vagy 8-10 évig, aztán elegem lett és váltottam AVR-re, szóval
> tudom, mit beszélek.
> 2. A 8 bites AVR-ek soha nem váltottak programozási metódust, mai
> darabok is programozhatók ugyanúgy. Megjelentek ugyan újabb programozási
> metódusok is, de azok a régi programozás MELLETT, PLUSZ lehetőségként.
A váltás kivédhetetlen volt, hiszen a kezdetek óta hatalmas fejlődés 
volt a technológiában.
Az ablakosokat nem lehet ugyanúgy programozni mint a mostani flash-eket.
Ezt nem tartom katasztrófális problémának.
Más eszközöknél megvolt ez. Gondolj csak a régi EPROM égetőkre, hányféle 
módon és feszültséggel
ment az égetés.

> 3. A legegyszerűbb esetben 5 szál madzag a printer portra - ezzel már
> lehetett programozni. http://vfx.hu/avr/index.html Az Microchip
> jellegzetesség, hogy újabb és újabb programozókra kényszerít.
A fejlődés sajnos evvel jár. Mi lenne ha mai is kis floppykon kapnánk
a több GB-os programok telepítő anyagát csak azért, hogy ne kelljen CD 
olvasót venni.
A számítástechnika elmúlt 35 éve alatt hány gépet dobtunk ki pusztán 
azért, mert az új dolgok nem mentek már a régi gépen?
Egyes régi dolgok meg nem mennek az új gépen/op. rendszeren.
> 4. A PIC memóriabank rendszere elcseszett megoldás, senki más 8 bites
> nem követte ezt a tévutat.
Evvel egyetértek, de ennek az az oka, hogy a korlátos utasításkód 
méretébe nem fér el a teljes memória cím. Így kénytelenek bankokra 
osztani a teljes memóriát. Nagyobb problémának tartom az egészen kis 
PIC-eknél a túl kicsi stack-et.
> 5. "az AVR-nek nincs nagy választéka egészen pici 8-14 lábú
> változatokból" - de hát minek is? PIC-es szemlélet processzort keresni
> egy feladathoz, AVR-ben ez nem szokás.
Evvel az erővel lehetne mindenhez 8 magos 4GHz-es procit használni, 
mégsem ezt teszik.
Ugyanis sokszor van fizikai méret, teljesítmény igény, ár, stb. korlát. 
Ezt egyetlen IC-vel nem lehet kielégíteni.

> Itt nincs olyan hogy ebben a prociban ez van, a másikban meg amaz, kis
> túlzással azt mondhatom, mindegyik alkalmas mindenre.
> Önkényesen kiemelve az Attiny45-öt: csináltak vele usb-soros átalakítót,
> (
> http://codeandlife.com/2012/02/22/v-usb-with-attiny45-attiny85-without-a-crystal/
> )használható I2C-hez, SPI-hez, van benne 10 bites A/D, analóg komparátor
> - mi a fenének mellé egy másik ugyanilyen proci?
>
>
> 2015-09-21 14:21 keltezéssel, hobilobi at gmail.com írta:
>> Sziasztok!
>>
>> Nem ismerem az AVR-t, most futólag belenéztem. Jól látom, hogy az Atmel
>> studió IDE 6
>> az ingyenes és tartalmaz C fordítót is?
>> Ha ez így van, akkor komolyan elgondolkodom a váltáson.
>> Azt ugyanis kapitális hibának tartom, hogy Microchip horror áron adja a
>> C fordítót.
>> Ez részint arra sarkalja a potenciális használót, hogy okos változatot
>> keressen, részint meg inkább
>> mást fog használni. Nem hiszem, hogy ne térülne meg a HW eladásából egy
>> ingyenes C fordító.
>> Arról nem is beszélve, hogy a használók jelentősen hozzájárulnak a
>> termék hibáinak felderítésében a továbbfejlesztési kívánalmak
>> meghatározásában. Igen sokat fizethetne a Microchip (és más gyártók is),
>> ha le lehetne számlázni nekik az egyes hibák
>> kiderítésére fordított felhasználói költségeket.
>> Nagy cégektől némi támogatásért cserébe már lehetne pénzt kérni, és
>> akkor az fedezhetné a fejlesztési költségeket.
>> Egyetértek, hogy a PIC-ekben van néhány nagyon kellemetlen megoldás,
>> leginkább  a memória bankok.
>> Ennek persze SW oka van.   Aztán a kis verem, se nagy öröm.
>>
>> A fő oka szerintem a mai PIC használatnak az, hogy hamarabb volt mint az
>> AVR, és aki azt annak idején megismerte,
>> bele tanult, az ha nincs komoly kényszer, akkor avval oldja meg a
>> feladatot, és nem áll neki egy új eszközt megtanulni.
>> Általában egy feladat megoldására nincs annyi idő, meg pénz, amibe
>> belefér egy új eszköz megtanulása is,
>> a hozzá valók megvásárlásával együtt. Nagyon rohan a világ, adj uram
>> isten, de tegnapra és ingyen.
>>
>> Aztán ahogy belepillantottam, az AVR-nek nincs nagy választéka egészen
>> pici 8-14 lábú változatokból.
>> Pedig nagyon sokszor bőven elég egy ekkora IC a feladat megoldásához. Ez
>> a PIC javára billenti a döntést.
>> Ráadásul ezek a kis IC-k  1-2 gombóc fagyi áráért kaphatók, ami egy
>> egyszerű kis terméknél döntő lehet.
>> Azt hiszem minden nyűge ellenére a PIC-nek is van létjogosultsága.
>>
>> Noha az is igaz, hogy ha ma kezdeném a szakmát, akkor a mai tudásom
>> szerint, először inkább azt AVR-t ismerném meg.
>>
>> István
>>
>>
>> 2015.09.21. 9:14 keltezéssel, Moravcsik Szilard írta:
>>> Szia!
>>>
>>> Azért a hardver fontosságához lehet mérni (ha ugyan nem fontosabb) a
>>> szoftver fejlesztői rendszert, könyvtárakat, dokumentációt, közösséget,
>>> stb. Szerintem a RapsberryPi is a jó háttér támogatottság miatt ér
>>> többet a nálánál erősebb vasaknál.
>>>
>>> A 90-es években (még ChipCAD előtt, a HumanSoftos időkben) mi is
>>> PIC-ekkel kezdtünk. A választásban sokat segített, hogy egy bőröndnyi
>>> könyvet és mindenféle demo cuccot kaptunk ingyen tőlük. Meggyőztek! :)
>>>
>>> Csak később, nagyobbacska projekteknél jöttünk rá sok ügyetlen PIC-es
>>> megoldásra. Kollégám maroknyi ősz hajszálat köszönhet pl. a PIC16C74
>>> (később "F" sorozat) memória bankolásból eredő szoftver hibáknak.
>>> Ráadásul a kvarcablakos tokok törlése eltartott egy darabig, ezért
>>> egyszerre többel küzdött. A törlő gyakorlatilag mindig tele volt
>>> sütkérező PIC-ekkel. :)
>>>
>>> Ezután jöttek az AVR-ek, amik sok szempontból jelentettek megváltást.
>>> Aztán szereztünk egy "okosított" CodeVisionAVR szoftvert, ami már
>>> tartalmazott egy "varázslót" is a hardver inicializálásához. Tudott
>>> inline assembly-t, jól használható editora, viszonylag gyors
>>> compilere/linkere volt, szépen dolgozott, jó kis szoftver könyvtárai
>>> voltak, stb. Persze járt nálunk "okosított" BASCOM, MikroC, IAR, de
>>> valahogy megmaradt a CvAVR, amit 2004-ben megvettünk és azóta frissítjük.
>>>
>>> Eddig még nem volt akkora projektünk, amit egy 32MHz-en futó xmegával ne
>>> tudtunk volna megoldani. Ha lesz ilyen, megvan a jelölt STM32xxx ARM
>>> család, "csak" megfizethető, jó minőségű fejlesztői hátteret kell majd
>>> hozzá találnunk (a Keil és tsai nagyon drágák nekünk, a MikroC ARM-ről
>>> pedig nem túl jókat olvasunk...).
>>>
>>> Üdv:
>>> szilárd
>>>
>>>