Milyen mikrovezérlőt?

Programozás - kezdő

Sziasztok!

Milyen mikrovezérlőt javasolnátok hobby projektekhez? Szeretnék USB, Ethernet illesztést, mindenféle szenzort kiolvasni (hőmérséklet), esetleg kis ház-automatizálás a későbbiekben szóba kerülhet.

Évezredekkel ezelőtt PIC-el foglalkoztam, de azóta sok minden változott, gondolom. Atmel elsőre szimpatikus az égető hardver egyszerűsége miatt.

Szívesen olvasom a tippeket, javaslatokat!

Üdv, Cözi

Update: Jelen pillanatban első próbának a PIC tűnik esélyesnek, főleg a haza felhasználói tábor, illetve az egyszerű beszerezhetőség miatt. A fejlesztő környezet sem eget rengetően drága. Ezzel együtt az ARM-vonal is ígéretes, ezzel is érdemes foglalkozni, de erről még nem rendelkezem elegendő információval. Atmel is jó, de mivel emberi erőm véges, őt teszem most a harmadik helyre.

  • 17628 megtekintés

( apal v | 2010. 11. 04., cs – 22:57 )

atmel: +1. 

./configure && make && make upload

, fejlesztes sem tul bonyolult.

( junior013 | 2010. 11. 04., cs – 23:01 )

Ugyan atmel-be én már nem bonyolódtam bele, de manapság már komolyabb "agynak" biztosan azt használnám. Kisebb dolgokra (pl. házautomatizálási perifériáknál egyszerű busz-illesztés) viszont maradhat a pic.

( skynetpro | 2010. 11. 04., cs – 23:24 )

az ethernet nem piskóta!
az atmel nekem szimpatikus, én a 8 bites mega sorozatot használtam/használom megelégedve.
btw a pic sem lebecsülendő, a microchipnek vannak jó dolgai, de nem az én világom.
én most ismerkedek egy arm cortex-m3 alapú rendszerrel.

( uid_16401 | 2010. 11. 04., cs – 23:32 )

Azt válaszd amihez jobban értesz.

De a PIC sem rossz választás:

- PIC18F66J60-PIC18F97J60 családban IEEE 802.3 ethernet buffert tartalmaz
- PIC18F4x5x, PIC18F2x5x család integrált USB 2 modult tartalmaz
- PIC16F913 integrált LCD meghajtóval
- ezen kívűl RF megoldások és sok minden más is megtalálható a Microchip kínálatában is.

Szóval lehet a PIC-ből is építkezni, és a programozó logika sem túlságosan bonyolúlt. Persze a nagymenők az Amtel-re esküsznek, de árban valamivel drágább mint a PIC.

Ha meg komolyabb szerkezet kell, akkor érdemes elgondolkodni a Xilinx termékek használatán is, habár az is elég mélyvíz egy kezdőnek.

***
programozó nők rémálma: a végtelen ciklus

Ez NAGYON szimpatikus! 5 perc alatt találtam Magyar forgalmazót is :)
Sajnos még sokat kell olvasni ahhoz hogy jobban megértsem meddig lehet ezzel eljutni.
A lényeg (ha jól értettem) hogy USB (esetleg soros) vonalon programozható egy kis bootloader segítségével. Minden elterjedt OS és programozó környezethez illeszthető.
Amit még nem látok:
- milyen nyelven, milyen compilerrel is tudom ezt programozni (én az assemblert preferálom, a C-t csak akkor ha megtudom nézni a közbülső assembly kódot)?
- a debuggolás részletei - break point és regiszter/memória (esetleg I/O) kiolvasás?
- tudnak ezek a lapok önállóan, PC nélkül üzemelni?

* Én egy indián vagyok. Minden indián hazudik.

Egy chipeseket C/C++ - fejvakargatás. Lehet, a matematikai könyvtár mondjuk kapóra jön. De ha nem kell komolyabb számításokat végezni?
Alapvetően kétféle felhasználása lehet a beágyazott mikrogépeknek (szerintem):
- önálló, környezet tűrő (-40 ... +50 C fok), kis méretű és fogyasztású intelligens eszközök.
- realtime és vagy gyors reakciójú, feldogozás a nagyobb számítógépek (mondjuk PC) kiegészítésére (pl. érzékelők, klf. eszközök vezérlése)
Mindkét esetben a hangsúly a kis reakció időn van, tehát legalább az interrupt rutinokat assemblyben akarnám írni, de legalábbis megnézni mit is generál a C/C++ ezekre. Boldogult firmware programozói koromban egy-egy utasítás megnyerése is fontos volt.

* Én egy indián vagyok. Minden indián hazudik.

Egyrészt ma már sokkal nagyobb teljesítményűek a mikrovezérlők, mint firmware programozói korodban lehettek.
Másrészt a nagyobb teljesítményű MCU-k risc utasításkészletét a C fordítóhoz optimalizálják, valamint az általam ismert C fordítók az optimalizálás során a legtöbb assembly programozóénál gyorsabb kódot eredményeznek.

Természetesen egyes helyzetekben szükség lehet bizonyos programrészek assemblyben történő megírására, de a 40-80 MIPS-es vagy még gyorsabb processzorok esetén itt-ott 2-3 utasítással több még a megszakításkezelő rutinokban sem vészes. Ha meg igen, oda célhardver kell FPGA-ból, ami 5-10ns alatt "válaszol" az eseményre és a "ráérősebb" feldolgozást végzi a háttérben az MCU.

Tudom, hogy TCP/IP és USB stack-et, CAN és LIN modulokat is meg lehet írni assemblyben, a kérdés az, hogy megéri-e a sokszorosára növelni a fejlesztési időt és ezáltal a beleölt pénzt, miközben az elérhető sebességkülönbség már nem jelentős.

Néhány kB-os programtárral rendelkező mikrovezérlők esetén én is assemblyben kódolok (megszokás? hagyomány? vagy csak jobb érzés? nemt'om), de egy ARM esetén ezt már nem vállalnám be.

Másrészt a nagyobb teljesítményű MCU-k risc utasításkészletét a C fordítóhoz optimalizálják, valamint az általam ismert C fordítók az optimalizálás során a legtöbb assembly programozóénál gyorsabb kódot eredményeznek.

Igazabol ez nem a C forditok problematikaja. :)

---
pontscho / fresh!mindworkz

( STP | 2010. 11. 05., p – 01:23 )

Ugyan nem használtam (még), de nézz rá a PIC32-re.
SAM9260/9261-el van jó tapasztalat is (a default szopás mellett).

PIC32 nagyon jó. Van hozzá C fordító (lényegében valami gcc klón, diákoknak azt hiszem ingyenesen le lehet tölteni.)

Az égetőt meg meg kell venni. Én is próbálkoztam sokáig házibarkács égetőkkel, de több PIC-et sikerült tönkretenni, mint amennyibe egy olcsóbb gyári égető kerül. (hobby célra a PICkit 3 -at tudom ajánlani.)

PIC32-nél is tudsz egy két dologgal szívni. Az MCLR lábán nem tűri a nagy fesz.-t (talán az 5V-ot sem.), illetve elég érzékeny az egyik kondira.

Szerk.: sajnos csak TQFP tokban lehet kapni, azt meg nem egyszerű forrasztani.

( kovacsj | 2010. 11. 05., p – 07:36 )

A PIC azért jó, mert sokkal több és különböző feladatra alkalmas, ám ez az árában is kedvezően érezhető tipusa van, az Atmel meg azért, mert - szubjektív vélemény - egyszerűen jobb. :)

Hobbihoz szerintem bármelyik jó, bár az Atmel árai az utóbbi időben eléggé megemelkedtek.

( zamek | 2010. 11. 05., p – 07:55 )

Az eddigi javaslatokkal szemben en messze nem ajanlanam a pic-et. Az eddigi tapasztalataim szerint:

-minden munka tulnovi a "csak nehany bemenet es nehany kimenet kozotti logikai kapcsolat" meretet
- a legdragabb eroforras az emberi munkaero
- ha az idod nagy reszet azzal toltod, hogy a fordito es a hw hulyesegeit megkeruld, akkor idot vesztegetsz.
- a pic annyival nem olcsobb, mint egy "normalis" uC. Sokan ezzel a hulyeseggel jonnek, pedig, ha egy munka utokalkulaciojat elvegzed, kiderul, hogy a uC ara a teljes koltseg kevesebb mint nehany szazaleka. A legdragabb a sw!

szubjektiv velemeny: a hardware microsoft-ja a microchip.
ostoba architektura, kicsi memoria, kicsi stack. Vedett kodokat egyes pic-eknel egy mozdulattal olvashatova lehet tenni. Gyari ajanlott kapcsolassal nem rezgo oscillator. Huu, mit fogok ezert kapni a pic-fan-oktol! :)

Ha most kezdesz foglalkozni a temaval, valassz olyant, ami kesobb is jo lesz. Mindenkeppen C-ben programozz, ne assembler-ben, mert akkor roghoz kototte valsz.

Avr jo valasztas, de pl. a Cygnal 80c51Fxxxx nagyon korszeru, a Texas-nak is van az msp sorozata ami jol hasznalhato es szeles valasztekot nyujt. Szandekosan nem mondom, az en "kedvenc" controlleremet, mert az a cel, hogy a feladathoz valassz processzort es ne a rosszul ertelmezett markahusegedhez. Sokan buktak mar bele akik elhittek a microcontrol m$-hoz hasonlo hasbaakasztasait es azt hittek, hogy 3 bemenet 4 kimenet kozotti logikai kapcsolat utan mar mindent meg tudnak csinalni pic-kel.

Forditonak mindenkeppen az sdcc-t ajanlom, mert ertelmes kodot fordit szemben pl. a keil c forditoval, ami raadasul csak mikrofutyi alatt fut es az ingyenes verzio csak 2Kb merethatarig hasznalhato. Az sdcc platformfuggetlen, nyilt forrasu es sok processzorra tud forditani.

Ha el akarsz melyedni a temaban nezd meg a freeRTOS-t ami egy multitaskos nyilt forrasu mikrokernel (cooperative es preemptive(!) multitasking) GPL licenc alatt. Igaz a doksiert penzt kernek (kb. 30$).

Ethernet:
az X retegu (4 retegu TCP/IP es a soha nem is letezett ISO-OSI 7 retegu) protokoll stack-nek csak a legalso retege hardware, a tobbi sw! Eselytelen ezt egy uC-re megirni. Erre vannak celhardware-ek nehany ezer HUF-ert.

Tetszik ez a hozzászólás zamek!

Mivel elég sokat programoztam PIC-en, igazat kell adnom, neked. Bár a 18F-as család már-már a használhatóság határát súrolja. Azért így is kell vele elég sokat szívni.

Mindenképpen nézd meg az Atmelt, a jó öreg 8051 családot és az ARM-ot is. Meg amiket még ajánlanak a többiek!

Fordítónak mindenképpen érdemes C compilert használni, de az sdcc-t pl. PIC esetén enyhén óvatosan használnám. Elég sokat szívtam vele. Csak megfelelő programozási stílussal generál neked olyan kódot, amilyet szeretnél (esetleg, hibamenteset, vagy túl hosszú lesz a kód). Korábban sokat programoztam PIC-eket ass-ban, és ez mély nyomot hagyott bennem :)

Alex

Sajnos tapasztalat:)

Ennél már csak az a bosszantóbb, amikor pic-fun-ok szenvedélyesen bizonygatják, hogy milyen jó a cucc és semmi nem lehet jobb nála. Manapság elképesztően jó processzorok jönnek ki, ostobaság foggal-körömmel ragaszkodni egy eszközhöz.

Nemrég volt egy munka, amiben 20 csatornán keresztül kellett analóg jelet mérni (12bit, hőmérséklet) és szabályozni pwm-en keresztül és mindezt rs323-n keresztül pc felé feltolni, ill. a pc felől beállítani és elindítani/megállítani.
Én a pc oldalt csináltam, az első pic-fun megjelent, a szokásos nagy mellény:
"én fizikus végzettségű vagyok, már csináltam 1 csatornás szabályozást, én csináltam a pc oldalt is viziló bézik-ben, akkor ezt is meg tudom csinálni"

Kérdeztük tőle mekkora körülfordulási időt tudna hozni, először hümmögött, majd kis segítséggel kiszámolta, hogy kb. 3-4 mp alatt meglesz az:)

Szerencsére a megrendelő érezte, hogy itt nincs minden rendben és elhajtotta. Végül kb. 15mS lett rendes uC-vel.

A legrosszabbak az ilyen okostojások. Lejáratják a szakmát. Ezek azok az emberek akiknek - korlátolt agyuk miatt - arra már nem marad energiájuk hogy józanul fölmérjék a képességeik határát. (Jól elvannak a kis homokozójukban.)

( covek v | 2010. 11. 05., p – 08:36 )

AVR:

- USBasp programozáshoz,
- Szoftverfejlesztéshez standard C,
- Arduino kisérletezgetéshez,
- Ha kell tudok adni Makefile-t, pár hasznos headerfile is elérhető ha gondolod.

c

( nemka | 2010. 11. 05., p – 08:40 )

Ne az égető egyszerűsége miatt válassz típust, hanem maga a processzor(család) legyen normálisan használható, könnyen beszerezhető és legyen hozzá megfelelő és folyamatos támogatás, lehetőleg a gyártótól vagy a helyi disztribútortól. Programozó és debuger már készen is olcsón beszerezhető a legtöbb típushoz

És ne csak a PIC vagy az Atmel legyen szem előtt. Kis teljesítményű 8 bites processzorok között valóban ennek a két gyártónak az MCU jelentik itthon a kézenfekvő megoldást, de az USB és az Ethernet már komolyabb teljesítményt igényel és ebben a kategóriában vannak alternatívák. Olcsón vannak ARM és MIPS core-os MCU-k több gyártónál (Texas, NXP) is és talán érdemes általánosabban elterjedt magot választani, hogy később könnyű legyen típust, gyártót váltani, ha egy projekt megkívánja.

Ethernetes projektekhez én a PIC24 + ENC párost használom (a most folyamatban levőhöz is), mert olcsó, könnyen beszerezhető, komoly támogatása van és programozható, hogy melyik periféria melyik lábat használja, ami nagy királyság. Ha ez már nem lenne elég, valószínűleg az ethernetes PIC32-t venném, mert jó a kapcsolat a ChipCAD-del és a meglevő fejlesztőeszközökkel is használható. (Emellett van NXP, Texas, Cypress holmim is, amiket kipróbálgattam, NXP-vel fejlesztettem is etherenetes holmit.)

De nem biztos, hogy neked is ez a jó választás. Nézd meg, hogy mi az, ami elérhető, olvass el pár adatlapot és a legszimpatikusabbat válaszd.

de az USB és az Ethernet már komolyabb teljesítményt igényel
+1

de par trukkot azert lehet csinalni. pl ftdi konvertert beletenni, ami usb <-> rs232-t csinal: plusz egy ic, oszt kesz is vagy. adhadsz neki sajat vid/pid-et is, atmel oob tudja kezelni (gyk csak osszekotod madzaggal a ke't ic-t), tud flowcontrolt, mindent. ajanlottak is; mondjuk me'g nem probaltam ki kozvetlenul, csak rtfm alapjan mondom ezeket - de a kozeljovoben tervezek jatszani ilyenekkel.

ftdi-t sokan szidják, mert drága, sérülékeny, nincs dip tokos verzió (ez hobbi körökben gond lehet)
cserébe tényleg oob megcsinál mindent, de atmega-hoz van gpl-es szoftveres usb-stack: v-usb http://www.obdev.at/products/vusb/index.html
hasznos lehet még a cdc232, ami gyakorlatilag az ftdi szoftveres megvalósítása, nyilván jóval lassabb, de általában bőven elég és elég olcsó.

PIC ide, vagy oda Microchipnek elég sok jó terméke van ha nem is a mikrokontrollereket nézzük :
ftdi chip szerű usb-rs232 IC-t csináltak, a neve mcp2200 , árban pedig fele az ftdi termékeknek chipcad .

Amúgy először azt kellene eldönteni, hogy 8bites, vagy 32 bites rendszert akar használni. A 32 bites-é a jövő, ez tény, de nem egy feladat van, amire 32 bit ágyúval verébre kategória és gyönyörűen meg lehet oldani 8bites kontrollerekkel.

( BlackCode | 2010. 11. 05., p – 09:36 )

Texas Instruments - MSP mikrovezérlői

Texas Stellaris (leánykori nevén Luminary Stellaris) LM3S sorozat.
ARM Cortex-M3 core (a XXI. század 8051-e :-D), ethernet MAC+PHY, mindenféle periféria.
Én ezt javaslom, mert gyors, olcsó, elég sok eszköz közül lehet választani, és a GCC vagy a CLANG fordít hozzá kódot.

De bármilyen ARM Cortex-M3 core-os mikrovezérlőt választhatsz, nem fogsz csalódni.
Amit kipróbáltam: ST-ék STM32F103-as sorozata (szakdolgozatomhoz ezt használtam), LM3Sxxxx (ezzel demóztam a Kandóban).

NXP LPC17xx és Atmel AT91SAM3xxx is létezik, de ezeket nem próbáltam.
Hamarosan érkezik a FreeScale Kinetis mikrovezérlője ARM Cortex-M4 core-ral, lebegőpontos, SIMD és DSP utasításkészlettel.

Fuszenecker Róbert

P.S. Én javíthatatlan ARM-os vagyok.
P.S_2.: Nincs ARM részvényem.

Szia!

Nehéz jó irodalmat ajánlani.
Amit mindenképpen el kell olvasni, vagy legalább át kell lapozni (regisztráció szükséges):
ARMv7-M Architecture Reference Manual, Cortex™-M3 Technical Reference Manual és a chip adatlapja, pl. LM3S8971, STM32F103...

Általában: http://infocenter.arm.com/help/index.jsp
Kicsit STM32 specifikus, de a Cortex-M3 része ugyanaz: hóvirág

Aki meg akar térni:
http://arm.com/files/pdf/Cortex-M3_programming_for_ARM7_developers.pdf

Nem árt érteni a gcc-hez, a legfrissebb Ubuntuhoz már van gcc, ami ARM targetre fordít (mintaprogramokat tudok adni -- LM3S8971, STM32F103).

Fuszenecker Róbert

+1

Nekem is ez lett volna a javaslatom. Ezeknek a kontrollereknek szerintem nagyon hatekonyak. Gyakorlatilag SoC. Eleg erosek ahhoz, hogy komplett OS-eket is futtass rajtuk pl. ethernut, FreeRTOS, eCOS, sot meg akar Linux is:-) es csak az alkalmazasokkal irasaval kelljen torodnod. Ez nem hatrany, ha gyorsan akarsz valami mukodot osszerakni.

A Cortex sorozatnal raadasul torekedtek az egysegesitesre (CMSIS, http://www.google.hu/search?source=ig&hl=hu&rlz=&q=cmsis&btnG=Google+ke…), igy ha egy tipust megtanultal, nem tul nehez atallni egy masikra es portolni is aranylag konnyen tudod. A Texas Instruments-nel rendelhetsz ingyenes mintakat is (en szerdan este rendeltem es ma kaptam meg oket:-)))

A legtobbnel van beepitett bootloader, a programozashoz akar egy soros port is eleg, de valaszthatod a debugot is segito JTAG-et is (akar openocd-vel).

Egesz hasznalhato fejelesztoi kornyezetet tudsz kialakitani nyilt forrasu programokbol is (pl gcc/g++ + eclipse + gdb + openocd).

/sza2

+1

Engem is kezdesz rábeszélni az ARM-ra. Nézegetek próbapaneleket, most ez tetszik: NXP LPC1758 ARM-CM3 Board. Persze az alap dolgok érdekelnének, hogyan induljon el egy kezdő, milyen hw, sw környezettel dolgozzak. Jó közösségi oldalak, példaprogramok tömkelege sokat segítene :-)

Üdv, Cözi

Segítek.
Tudok küldeni leírást (a szakdolgozatom egy része erről szól -- a többi részét tilos elolvasni :-D).
Sőt, van pár mintaprogramom, a Kandón volt egy előadás az ARM Cortex-M3-ról.

A link: http://hg8lhs.ham.hu/publications/index.html

Tilos kritizálni a formázást, ma már teljesen másképp csinálnám. Mea Culpa.

Lásd még: comment-1155225

Fuszenecker Róbert

Köszönöm :-)

A legegyszerűbb, ha kinézed magadnak a chip-et pl. a Farnell-en, és az FDH-nál mgrendeled :-)
Ha van proci, akkor majdnem minden van, már csak tápot kell építeni, de azt már megoldottam (LM317 rulez): szabályozható 1.25-12 V-ig.
NYÁK-ot pedig csináltatni kell, számos gyártónak vannak jó ajánlatai (nem ajánlok céget, inkább Google-n nézz utána, hogy mi van hozzád közel).

Fuszenecker Róbert

Ügyesen :-)

Kicsit előónozom a NYÁK-ot, a felesleget eltávolítom ónszívó madzaggal (nem tudom, mi a rendes neve) úgy, hogy egy kicsi azért maradjon, majd begyantázom.
Ez azért is jó, mert a gyantába "beleragad" a QFP tok, és nem mozdul el, miután a helyére illesztettem. Nagyítóval vagy mikroszkóppal.

Ha a helyén van a tok, akkor már csak végig kell simogatni a tok 100 lábát a jól megtisztított forrasztópákával (ennek nem kell hegyesnek lennie, sőt... úgyis csak arra használom, hogy felmelegítsem a tok lábát, és az alatta levő ón, és persze a bőséges folyasztószert. A lábakat belülről kifelé kell simogatni :-)

És érsemes a szemben lébő sarkokon egy-egy pöttyintéssel (megérinted a pákával a lábakat) rögzíteni a tokot, hogy tényleg ne mozduljon el.

Fuszenecker Róbert

Igen, sajnos maga a Farnell is nagyon drága. Legalábbis a magyar kereskedőkhöz képest.
Viszont nagy előnye, hogy nagyon sok olyan terméket árulnak, amit nehéz lenne más úton beszerezni.

Pl. a Konthában vagy a Lomexben eszembe nem jutna ARM-ot keresni, mert nem az a profiljuk.
Ők egyszerű kandósnak árulnak lábas alkatrészeket :-)

Fuszenecker Róbert

Nekem is csorog rá nyálam, annyi minden van benne és annyi mindent meg lehet vele valósítani.
Feladatok:

- protópanel - nem próba! - azaz ha egy-két darab kell arra is jó.
A követelmény, hogy működtetni lehessen egy lecsupaszított OS -t, akár RAM -ból és összekapcsolható legyen a fejlesztő géppel (soros, USB, ethernet minél egyszerűbb és olcsóbb de megbízhatóan). Legyen megfelelő illesztő felület amivel tovább lehet bővíteni. Korrekt áron beszerezhető, szerelve/beüzemelve, NYÁK + alkatrész, csak NYÁK kiszerelésben.

- pontos és reprodukálható leírás az alaptelepítésről - akár SPI segítségével.

- megfelelő fejlesztői környezet - szövegszerkesztő, compiler(ek) és break pointal támogatott debug, regiszter és memória kiolvasási lehetőséggel.

* Én egy indián vagyok. Minden indián hazudik.

( glex | 2010. 11. 05., p – 14:50 )

Nálam PIC nyert.
Akartam ethernetet, USB-t, RS232-t, stb és mindezt úgy hogy ne kelljen SMD-t forrasztani.
- Ahol csak 4-6 IO kellett ott jól jött a 12F sorozat. Beépített oszcija van, így kvarc sem kellett mellé.
- Ha USB kellett, akkor 18F2550 komplett USB támogatással van DIP tokban.
- Nagyobb teljesítményhez ott a PIC 24F sorozat amiből szintén van DIP tokos .
- Hálozatra ott az ENC ethernet IC szintén van DIP tokban.

Alapvetően ezek a PIC-ek fő csoportjai
12-es sorozat - 8bit, kevés IO, alacsony teljesítmény, alacsony fogyasztás
16-os sorozat - 8bit, akár 33 IO, komolyabb teljesítmény (5 mips)
18-as sorozat - 8bit, sok IO, C nyelvre optimalizált utasításkészlet
24/33-as sorozat - 16bit, DSP utasítások nagy teljesítmény (16-40Mips)
PIC32 - 32bit, USB, ethernet, sok ram, stb

Fordítónak a CCS fordítót használom. Meg tudod nézni az ASM forrást is benne és nagyon sok perifériához van "driver" CCS alatt.

Arduino játékra jó. Nem kell hozzá égető hardver, mert USB-n keresztül frissíthető a szoftvere. Sok "shield" van hozzá amik között van ethernet shield is. De ha az arduino mókádból hardvert akarsz varázsolni, akkor ott már gondolkodni kell, a PIC-nek pedig elég egy panelt maratni...

Hmm...

A programozó PICkit2 nem egy nagy összeg. A C fordító elvileg a Microchip oldaláról letölthető. Nézegetem a fórumokat is, nem tűnik nagy kalandnak, legalábbis a példa szerint van néhány ember, akinek sikerült az USB kapcsolat.

Az ENC kiegészítés is szimpatikusnak tűnik.

Tudnál még egy kicsit írni arról, milyen az élet a PIC világban?

Üdv, Cözi

Ez igaz, de a kérdésem arra vonatkozik, hogy Linux alatt hogyan kezelem le az USB porttal bíró PIC-et? Vagyis tegyük föl, megépítem a HW-t, felprogramozom, WinXP alá telepítem a megfelelő drivert, a gép felismeri a PIC-et, öröm és boldogság. Ez a folyamat érdekelne Linux-szal (ott mit kell tennem, hogy működésre bírjam az eszközt; kapok egy sima soros portot, /dev/tty_X?).

Üdv, Cözi

Felprogramozod a PIC-et: megmondod neki, hogy milyen eszköz akarjon lenni (természetesen nem elég a típust beállítani, hanem a hozzátartozó protokollokat is implementálni kell).
Feltelepíted a drivert: olyan drivert raksz fel, ami pont azt az eszköztípust ismeri fel (és kezeli), amilyennek programoztad a PIC-edet.

Na ugyanezt Linuxon is meg tudod csinálni.

kapok egy sima soros portot, /dev/tty_X?

Ha olyan eszközzé programoztad a PIC-edet, aminek a drivere Linuxon egy sima soros portként jelenik meg, akkor igen. Pl. vannak USB-soros átalakítók, azoknak a drivere jellemzően valami /dev/ttyUSBX jellegű device lesz. Ha pont egy ilyen soros-portot szimulál a PIC-ed az USB másik végén, akkor pont így fog kinézni a device, ami megjelenik.

Én írtam már néhány USB-s PIC alkalmazást. A libusb teljesen megfelelelő a kezelésre. Ennek használatával nem kell foglalkoznod azzal hogy az eszköz hol van a /dev/ könyvtárban és mi a neve, stb. Régebben - amikor még csak a libusb-0.12 létezett - írtam egy saját egyszerűsített kezelő réteget az aszinkron kezelés hiánya miatt. Ma már a libusb-1.0 mellett ez fölösleges, ráadásul a szinkron mód többnyire elég.

( vl v | 2010. 11. 09., k – 01:19 )

Na, akkor én is felteszem a kérdésemet:

Mikrokontrolleres Ethernetes vezérlőre mit érdemes használni, ha a következők a szempontok:
- SMD technológia nélkül lehessen használni = azaz vagy létezzen belőle nem-SMD-s kivitel, vagy létezzen hozzá emberi áron előregyártott board, amibe már nem nekem kell az SMD cuccot bevarázsolni
- tudjon Ethernetet kezelni
- bónusz, ha USB-t is tud kezelni
- egyedi darab esetén Ethernettel együtt férjen bele a ~15-20 rugós bűvös értékhatárba
- sorozatot lehessen előállítani belőle 10 rugón belül.

Miért ezek a számok? Mert 15-20 rugóért lehet venni készen OpenWrt-síthető access-pointot (WL-500GP, WR1043ND), amiben jól szituált 250-400MHz-es MIPS van, gyors 10/100 vagy 10/100/1000-es Ethernettel, bónuszként Wifivel, az USB-re meg rakhatok bármi kicsi egyszerű cuccot (pl. egy soros portot, arra meg egy 800 Ft-os PIC-et, ha valami speckó interfész kell), ráadásul dobozt is adnak hozzá. Na ennél kéne olcsóbbnak lenni, hogy érdemes legyen vele foglalkozni.

A szempontjaid érthetőek, de ...
- te a több tízezres sorozatgyártású termék árait akarod a pár száz darabos "sorozatra" kivetíteni (WL-500GP, WR1043ND)
- az általad hamarjában felsorolt eszközök, általában 0 .. 40 Celsius fok, alapvetően szobahőmérséklet
- ami az SMD -t illeti, az igazán finom cuccok csak ilyesféle tokban elérhetőek - én inkább amolyan öcsi paneleket hiányolok, ami nagyobban de kivezeti minden lábát a szokásos raszterben
- az ethernet kezelés bizonyos "kaliber" alatt nem alkalmazható opció, hiszen az ethernet kontrollered "nagyobb kaliber" lesz mint a procid
Ami minden ötletnek megfelelnének, az valami erősebb Xilinx (vagy hasonló) amivel "emulálni" lehet bármely a piacon fellelhető egychipest + a debug és programozási rugalmasság.
Nincs mese, még mindig ott tartunk (ez a 80 -as évek óta így megy), hogy valami gyártó/gyártmány mellett le kell tenned a garast, és megvenni a hozzátartozó fejlesztő és modellező/prototípus eszközöket.
Az egész embedded dolog arról szól, hogy a feladathoz a processzort/hardwaret.
Az univerzális embedded processzor architektúra fából vaskarika. Nem tudsz árban versenyezni az olyanokkal akik sok ezres példányban készülő dolgokat építenek és arra vetítik ki a fejlesztési költségeket. Ha a megrendelő ki kell, hogy fizesse az egyedi fejlesztés költségét vagy használja azt ami van!
Döntsd el hobbi vagy megélhetés, ön ajándék vagy befektetés/beruházás. Egyébként nekem sem ízlik ez.
Közben felmerült egy kollektív(?) projekt ötlete - gondolom már másoknak is eszébe jutott, de nekem most ugrott be egy régi elgondolásom. Ha alapul veszünk egy közepes teljesítményű PC hardwaret azon is szimulálható/emulálható egy átlagos egychipes, csak az I/O -ról kellene gondoskodni realtime! - ezt persze úgy kell elgondolni, hogy nem ezen fejlesztesz (X window IDE stb.) ez csak egy jól hozzáférhető, olcsó emulátor/szimulátor amit egyik oldalon hozzákötsz az emulálandó hardware modellhez, a másik oldalon egy fejlesztő PC -hez.
Virtuálisan olyan kiépítésű egychipest választhatsz amilyet majd, a gyártmányban kell. Olyan kódot írsz rá ami a gyártmányba töltve egy az egyben használhatsz ...
Biztos vannak korlátai a dolognak, de kivitelezhetőnek tűnik.

* Én egy indián vagyok. Minden indián hazudik.

ha tényleg ilyesmivel szeretnél foglalkozni, akkor az AVR32-n alapuló ATNGW100 board-ot javaslom (pl. mscbp forgalmazza idehaza).

házilag a fenti feltételekkel wrt54gl-tudású eszközt álmodni sem hiszem, hogy érdemes.
egyrészt, mert through-hole alkatrészekkel nem lehet nagysebességű kommunikációra alkalmas eszközöket építeni (és egy ilyen eszközben _minden_ több 10- és 100MHz-eken rohangál, a dip-tokok lábainak parazita induktivitása pedig jól elrontja a pár 10-100ps-es felfutási idejű négyszögjeleket), másrészt még ha smd alkatrészeket is használsz, a signal integrity miatt (kontrollált impedanciájú huzalozás, stb.) illik minimum 4-, de inkább többrétegű nyákon összehozni a panelt - ez pedig a költségkeret nagy részét elviszi egyből.
az innen már szinte mellékes is, hogy kell némi elméleti és gyakorlati háttér ahhoz, hogy nagyobb frekvencián is működőképesen route-olja az ember pl. a memóriát az (általában nemhogy smd, pl. tqfp, hanem inkább bga-tokozású) SoC-hoz... és akkor a nagysebességű, differenciális route-olás örömeiről (pl. high-speed usb, GbE, vagy akár "csak" a ddr memóriák clk és \clk vezetékei, stb.), vagy a táp-integritással kapcsolatos buktatókról és egy csomó más szépségről nem is beszéltem...

( kojot | 2010. 11. 10., sze – 07:17 )

A legtöbben, konkrétan csak egy gyártót ajánlók véleményével óvatosan bénj! Ez sajna ismert és felesleges kasztosodás. Ki melyik oldalon áll, mit tanítottak neki, stb. Ez olyan int az M$-Linux hívők tábora,a kialakulás már az iskolában eldőlhet. Hiba!
A feladathoz úgy válassz vezérlőt h a vélhető bővítésen felül maradjon még 4-5 portod üresen. De nézd meg azért az árát is,és h valóban szükséges-e esetleg a drágábbat választanod. Kell-e a a sebesség, port szám memória stb.
Gyakorlati eset. Kedves kollega azért választotta adott gyártó termékét mert "azt ismeri". A konkurens gyártó terméke viszont az éppen elegendő tudással és egy pici tartalékkal viszont lényegesen olcsóbb lett volna. Az első komolyabb megrendelésen emiatt rögtön 1.2millával többet költött az adott cég a szükségesnél. A V2 verziónál pedig még ennél is többet... majdnem, a nem szólok rá, h helló! gondolkozz már és tanulj egy kicsit ha kell,mert ez a te zsebedre is megy! Váltott....

kojot javaslatát érdemes megszívlelni. A fordító programról annyit hogy én pl. sdcc-t használok PIC processzorokra. Persze az évek alatt a vele adott könyvtári függvények túlnyomó többségét átalakítottam és optimalizáltam gépi kódban. Így már lehet használni. Persze a fordítások eredményét érdemes ezután is megnézni assembly nyelven és tapasztalatom szerint a c kódot átírva többnyire rá lehet venni hogy kisebb és gyorsabb kódokat készítsen úgy hogy nem kell utólag belenyúlni az assembly-be.

( 4fonya | 2010. 11. 11., cs – 19:29 )

A feladathoz válassz processzort. A PIC-ek nagyon változatos perifériakészlettel kerülnek piacra. Amit nem tudnak alapból ahhoz meg van kiegészítő áramkör. Pl. ethernet. Az Atmel dolgait nem ismerem. Ne a szerszám határozza meg azt az eszközt amivel meg akarod valósítani a feladatot. Magyarán az égető másodlagos, nehogy már a farka csóválja a kutyát. :-) Sajnos pénzbe kerül de érdemes a munkaeszközöket megvenni és az érdemi munkával törődni. Ha valaki ásni akar akkor általában nem próbál meg ásót kovácsolni és fát vágni a nyélhez hanem megveszi készen. (Kivéve ha erre semmilyen lehetősége sincs, bár akkor valószínűleg kovácsolni sem fog tudni.) Annak idején utánépítettem egy Pickit-2 programozót, de csak néha-néha volt hajlandó fölismerni a PC. Sosem tudtam rendesen életre kelteni. Ma sem tudom hogy mi volt a baj vele.

"Ne a szerszám határozza meg azt az eszközt amivel meg akarod valósítani a feladatot."
Azért ez egy kicsit naiv. A fejlesztési időt jelentősen tudja csökkenteni a jó eszköz. Az idő az pénz! A fejlesztőeszközök megbízhatóságáról nem is beszélve. A legszebbeket akkor lehet sz'vni amikor szoftver hibát keresel és hardware hiba van, uram bocsá' fordító.

* Én egy indián vagyok. Minden indián hazudik.

( covek v | 2010. 11. 11., cs – 20:43 )

Kicsit körüljártam a témát ismét.

Mi kell a szoftverfejlesztéshez?

- Linux és M$ alatt is megtalálható PIC és AVR-hez is ami kell.

Mi kell a chip-ek felprogramozásához?

- eszköz ami a számítógép valamely portjára (soros, párhuzamos, USB) csatlakoztatható.

Egy AVR-dapa szerintem verhetetlen árban. Egységes felületen megoldható az AVR-ek felprogramozása. (nekem sikerült a lomok között találni egy 25 pólusú soros alaplapra dugható csatlakozót a maga 9 eres vezetékelésével. A csatlakozó pont egyezik az AVR-ekhez használt egyik mérettel. A 25-os felület pedig pont ellenpárja a párhuzamos porti csatlakozónak. A burkolata pedig tökéletesen elrejti azt a 4 ellenállást és a forrasztásomat.)

Ahhoz, hogy hobbicélra valaki elkezdjen ezzel foglalkozni teljesen meggyöző az AVR féle lehetőség.

Ha PIC felprogramozása is hasonlóan egyszerű akkor
kérek valakit győzzön meg. :)

c ex hg8lvb

PIC felprogramozása: PC-re rádugom a PICkit2-t, PICkit2-t rádugom a targetre, MPLAB-ban megadom a PICkit2-t programozó eszköznek, fordítás után programozás ikonra kattint és kész. Szerintem ez éppen elég egyszerű. (PICkit2 helyére bármely másik, az MPLAB által ismert PIC programozó hardver behelyettesíthető.)

Persze lehet jönni azzal, hogy az algoritmus bonyolult meg a hardver is több pár szál drótnál, de aki nem programozó hardvert akar fejleszteni, annak ez teljesen érdektelen.

ICD2 linux alatt (+ fejlesztőkörnyezet): http://piklab.sourceforge.net/
PicKit2 linux alatt: http://mcuee.blogspot.com/2007/06/pickit-2-under-linux-mini-howto.html

Én 5000Ft körül vettem a PICkit2-t egy próbapanellel együtt.
De ekkora tétel már hobbiszinten sem jelentős annak, aki komolyan gondolja és hosszú távra tervez. Egy hobbiműhely felszerelése annyiba kerül, hogy 2000Ft különbség nem tétel.

Aminek számítania kellene a használt eszköz kiválasztásánál:
- fejlesztőkörnyezet kezelhetősége
- eszköz tanulhatósága
- eszköz alkalmassága a várható feladatokra

Az elsőt és az utolsót általában minden mikrovezérlő család teljesíti.
A tanulhatóság viszont egyénenként változik. Nekem a PIC bejött, a PIC10-től a PIC32-ig voltak/vannak projektjeim. De ismerek olyanokat, akik nem igazán boldogulnak a lapozós/bankolós memóriákkal. És ez a fajta memóriakezelés lehet az egyetlen dolog, ami a PIC ellen dönthet.

Mindegyik vezérlőhöz létezik ezer féle programozó.
PIC-hez is van "párszázas" (és itt tényleg értsd úgy hogy <1000Ft) programozó és létezik drágább is.
Ami olcsó az pl Watt féle párhuzamos programozó (http://wattmep.tvn.hu/WLPT_Vpp_Mini_v4/WLPT_Vpp_mini_v4.html)
vagy egy bármilyen JDM programozó.
Ezekről viszont tudnod kell, hogy nem "üzembiztosak". JDM esetében pl ha nincs elég feszültség a soros porton, akkor nem fog sikerülni az égetés.
Persze van olyan JDM ami külső tápról megy, ott nincs ilyen probléma (nekem is ilyenem van).
A PicKit2 már elég komoly programozó. ebayen van sok utángyártott példány. A kapcsolási rajzai is fent vannak a neten, tehát házilag is elkészíthető.
PIC-ek esetében a komoly programozók a PicKit2, PicKit3, ICD2. ICD2 és PicKit3 akkor érdekes ha PIC32-vel is akarsz foglalkozni.

AVR-eknél is ugyanez a helyzet. Az olcsó programozó nem biztos hogy üzemelni fog a gépeden. A drágább üzembiztosabb.

Mind a kettő vezérlőnél él az, hogy rakhatsz bele bootloadert. Ennek az a feladata, hogy pl készítesz egy USB billentyűzetet emuláló eszközt.
Ha úgy indítod el a szerkezetet, hogy közben nyomod pl az X gombot, akkor a bootloader üzemmódba kerül az eszköz. Ekkor pl USB-n keresztül tudsz rá égető nélkül új szoftvert tölteni. Ezt a metódust egyébként más ismerheted pl telefon/TV/DVD lejátszó/MP3 lejátszó szoftver frissítéssel kapcsolatban is.

Fejlesztőkörnyezetek tekintetében PIC esetében tudsz asm-ben dolgozni. ha C-ben akarsz akkor a microchipnek van gyári fordítója ami ingyenes. Létezik belőle fizetős is. A fizetős verzióba plusz kód optimalizáló eszközök vannak.
nagyon dicsérik a Hi-tec és a CCS fordítókat.
Ha jól emlékszem mindegyik fordítónak van linuxos verziója (CCS IDE viszont csak Win-re van)

AVR linux alatt pedig avr-gcc

USB téren pedig a legyegyszerübbek:
Létre tudsz hozni USB HID eszközt, amit pl billentyűzetnek ismer fel a géped (általános billentyűzet, linux és win alól is jól megy). Ekkor a mikrovezérlődről gyakorlatilag bármilyen billentyű parancsot ki tudsz adni.
Tudsz csinálni virtuális soros portot, amit szintén felismer win és linux is. Ebben az esetben pedig bármilyen más programnyelven tudsz neki küldeni adatot és tudsz fogadni tőle adatot egy virtuális soros porton keresztül.

( Mcsiv v | 2010. 11. 12., p – 09:42 )

igaz nem teljesen ide tartozik, de hasonszőrű, illetve ha már ilyen sok szaki gyűlt össze akkor felteszem a kérdést:)
LVDS-el vezérelhető TFT panelt kéne meghajtanom (PIC lenne a kézenfekvő, mert ahhoz van mindenem).
Az tuti, hogy közvetlenül ez nem fog menni, már csak a clock sebessége miatt sem, de próbálkozott/találkozott már valaki, valami hasonló projecttel? Egy rövid iránybalökés kéne nekem, hogy merre induljak. A legjobb az lenne, ha valami köztes alkatrésszel, pic oldalról egy dual portos ramot töltögetnék fel, a másik oldal meg hajtaná a kijelzőt.

ha megnézed a témát pont én nyitottam:D igaz 2 évvel ezelőtt, de azóta sem született ott sem normális megoldás (ultrabrutál vezérlőt vehetek én is 40e ft-ért, de azért hobbi projectnek ez túlzás, főleg hogy van egyszerűbb megoldás is, csak nem publikáltak részleteket).
Ezért is vetettem fel, hátha talált már valaki normális/elfogadható áru/működő megoldást :)

Ahh, igen, cpld/fpga szinten mondjuk úgy, nem vagyok naprakész, de valahol mindent el kell kezdeni:D
Reménykedtem benne, hogy van valami kész, kevésbé szöszölős megoldás. Igazából egy 640x480x8bit már elegendő lenne a célomnak (házautomatizálás project, jelenleg egy pc vezérli, ezt szeretném kiváltani valami olyannal, ami nem eszik meg alapból 50 wattot:))

szarabb vassal viszont nincs ertelme szenvedni. szerintem egy ekkora kijelzot nem fogsz tudni normalisan kihajtani egy nyolcbites avr-rel vagy pic-kel... nem marad eleg processzoridod meg memoriad masra.
szerintem nem az arm ocd jtag letolton fog mulni a projekt, dragabb dolgok is lesznek ott. persze nem en csinalom.

Az én programozó hardverem (Olimex ARM-USB-OTG) már réges-régen visszahozta az árát.
Például azzal, hogy nem kellett időt fordítani arra, hogy megépítsem.
És nem kellett a hajamat tépni amiatt, hogy a programozó hardver nem működik.
A hiba mindig az én áramkörömben volt, és ezt jó volt tudni :-)

Fuszenecker Róbert

P.S. Egy bruttó 18.000 Ft-os dologról beszélünk, ami még egy diáknak is megfizethető.

A Wiggler, egy a printer portra akasztott kis interfész, van rajta egy min. HCT245 -ös busz meghajtó csip (így csak 5V -os dolgokat piszkálhatsz), két csatlakozó némi kondi és ellenállat. Ezt egy idomított majom is összetudja rakni, elromlani ebben nincs minek. A PonyProg nevű cucc még egyszerűbb.
A listában találtam olyat is ami USB és valahol amerikában gyártják, 30$ a kütyü (ami egyébként jó még egy kupac dologra ISP, I2C, smbus stb.) ja és a mérőzsinórok +5$ így együtt ez 7276,15 Ft a bankomnál, és megában foglalja a "worldwide shipping" -et is. Ha ez is drága ...
Az AVR hez a TÁVIR (vagy mi) honlapján találsz 7500,- Ft -ért komplett JTAG -et.
Úgyhogy a horrortól ez eléggé messze van.

* Én egy indián vagyok. Minden indián hazudik.

( whitehawk v | 2010. 11. 12., p – 10:18 )

Fujitsu uC-ket kerüld, szar a doksi, rossz az angolja, nehezen érthető néhol.

A fejlesztő környezet csak windowsos, csak single-user, registry-t kell mókolni, hogy mindenkinél menjen. Az AVR-es fejlesztés kellemesebb volt.

Nekem az AVR állt kézre, bár őszintén nem sokat mikrokontrollereztem, csak némit a Kandón, meg itt a másik suliban.

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

( tovis v | 2010. 11. 13., szo – 08:23 )

Úgy tűnik, hogy a merités két fő vonalat különít el ATMEL és Microchip.
Annyit érdemes ehhez hozzátennem, hogy itt két processzor architektúra is "ütközik" a PIC és az AVR (az ARM túlmutat ezeken a kalibereken), ami nem az alkalmazhatóságukat határozza meg, de számomra aki az Intel vonalat használta és az egychipesek 48/49 és végül 51 sorozatában van otthon, a PIC mint olyan idegen. A PIC architektúrája és op. kódja idegen és "pervertált" (stack, akku stb.) számomra. Amikor döntesz érdemes megnézni melyik szimpatikusabb mert ez sokat fog nyomni amikor egy-egy új dolgot kell csinálnod - tudniillik nehéz lesz az átállás.
(Nem véletlen, hogy az AVR sorozat is alapvetően az 51 -es architektúrára és op. kódra támaszkodik - bevált, sokan használják. A Microchip, történelmileg egy leheletnyivel később dobott a piacra flash -el integrált cpu -kat mint az Atmel.)
Egyébként mind jól támogatott, és bejáratott.
* Én egy indián vagyok. Minden indián hazudik.

( Cozi v | 2010. 12. 05., v – 16:43 )

Beszereztem életem első PicKit 2 csomagját, most szórakozok vele. Eddig jónak tűnik :-)

Üdv, Cözi

itt találsz USB-s forrásokat, amik lefordulnak gpasm alatt:
http://jap.hu/electronic/pic18-usb.html

forrás C-ben sdcc fordítóhoz:
http://www.microchip.com/forums/tm.aspx?m=170553

forrás C-ben boostC fordítóhoz:
http://www.embeddedadventures.com/pages/p/Tutorials/id/29

Ezek közül az elsővel foglalkoztam, ez volt ami legkönnyebben elindult.

Kb 10 évig használtam PIC-et, majd 15 évig AVR-t.
Még ma is követem a PIC világot, de büntetés lenne visszatérnem rá.
A PIC-esek bizonygatják, hogy nem drága a 18.000 Ft-os PIC égető. De arról hallgatnak, hogy a PIC eddig 3-szor váltott programozási metódust, két garnitúra programozót dobhattam ki.
Az Atmel procik meg még ma is az eredeti módon programozhatók, ráadásul 1 darab IC-vel,fél órai munkával, 200 Ft-ból megvan az égetőd.
Ezzel az égetővel programozható akár még az RTOS futtatásására is alkalmas AtMega256 is.
De hogy ne a csúcsot mondjam, álljon itt mintának, mit tud egy kis vacak 8 lábú AVR:
http://yveslebrac.blogspot.com/2008/10/cheapest-dual-trace-scope-in-gal…
(Azért próbáld színvallásra bírni őket, mekkora összegből tudnák ezt a két csatornás, usb-s szkópot kihozni. Atmelnél ez egy 360 forintos proci+200 az égető.
PIC indul 18.000-ről és melyik 8 lábú PIC tudna ilyet?
Ja, hogy egyik sem???)
Megint győzött a PIC-es duma a proci tudása helyett.

Igen, azt kell tudomásul venni, hogy a hw árak meredeken zuhannak és ma egy 32bites architekturát kapsz olyan áron, mint amibe pár éve a 8 bites került.
Ráadásul az mcs51 nagyon hw-ízű, ami azt jelenti nálam, hogy olyan hardware-esek tervezték, akiknek nem volt közük a software-hez.
pl. az eredeti mcs51-ben egy db 16 bites regiszter volt (dptr), amelyet csak inkrementálni lehetett. Ez anno 1980-ban érthető volt, mivel néhány kapuval több integrálása komoly költséget jelenthetett. Az atmel ráfejlesztett, a 90-es években, kihoztak egy felülről kompatibilis mikrokontrollert, amelyben már 2 dataptr volt, de továbbra is csak inkrementálni lehetett őket, holott a néhány kapu itt már nem okozott volna gondot. Persze nem okoz különösebb nehézséget, csak jelzi a hozzáállást. Az arm-en látszik, hogy újragondolták az egészet.

A fentiek fényében az a kérdés, hogy az új feltörekvő nemzedék hajlandó-e megtanulni az új architektúrát, vagy az ősök nyomdokain szép lassan elsorvadnak a régebbi 8/16 bites eszközökkel neadjisten assemblerben programozva.

Most persze mindjárt két oldalról is rámrohannak, hogy "jó az a régi technika, mert nekem eddig mindent sikerült megcsinálni vele", valamint "assemblerben kell tudni programozni".

Az első kérdésre egy történetet szoktam idézni az első világháborúból:

Amikor az angolok megjelentek a csatatéren a tankkal és halomra lövöldözték a monarchia katonáit, az osztrák tábornokok hümmögve nézték -tisztes távolságból- a mészárlást, majd a végén ez volt a megállapításuk: "Szép-szép, de azért mégiscsak a lovasroham az igazi!"

A másikra az, hogy az assembler röghöz köt, ill. nézzük meg a pc fejlődését:
ki használ manapság üzleti(!) célra assemblert? Ha időkritikus a feladat, egyszerűen minimális ráfordítással gyorsabb processzorra váltok.
A kód biztosan kifizetődőbb C-ben mint assemblerben, mivel - legfeljebb kis munkával - hordozható.

Nagyon jó így is ez az áttekintésed, még jobb lenne a tárgy ismeretében ;)
A jelek szerint nem is hallottál az Atmel AVR családjáról.
Ez 32 regiszterrel, ortogonális utasításkészletével vagy két évtizeddel frissebb, mint az őskövület mcs51.
Esetleg még érdemes tanulmányoznod a most felfutó xMega vonalat, ami pontosan arról szól, hogy nem a 32 bites világ lineáris sebességnövelése az út, mert ez egyben fogyasztásnövekedéssel jár. Ezen ugyan enyhít a technológia fejlődése, de az arányosság marad: nagyobb sebesség egyenlő nagybb fogyasztás.
Ezzel szemben Atmelék analízise szerint a bottleneck mindig a perifériák kezelése. Ennek megfelelően az xMegák fogyasztása a technológia fejlődésének arányában csökken, de az új, intelligens perifériákhoz delegálható feladatok, amik event-re felprogramozhatóan, _interrupt nélkül, a processzormag igénybe vétele nélkül_ mozgatnak blokkokat akár periféria-periféria, akár periféria-memória viszonylatban, bizonyos területeken még verik is a konkurrens 32 bites világot.
És mielőtt elmennénk a mellébeszélés irányába,ezek nem tudományos célú, lebegőpontos hatszáz ismeretlenes egyenletrendszerek megoldására készülnek. Oda DSP való, nehogy ezen lovagoljon bárki is.
Ezek a processzorok a hétköznapi életben egyre gyakoribb elemes táplálású processzorok iránti igényt elégítik ki, töredék fogyasztással és azonos vagy jobb turnout mellett, mint egy mostani 32 bites.

Mea culpa, tenyleg kimaradt nekem az avr.

Mentsegemre szolgaljon, hogy pont abban az idoben amikor ez jott, en valtottam pc/linux kornyezetre es nehany eve kerultem vissza kis kerulovel az embedded linux vilagba, ill. van meg ralatasom a kollegaim altal vitt mcs51 es pic-es ugyekre.

En speciel nem a nagyobb sebesseg mellett erveltem, hanem a 32 bites architektura mellett a 8 bitessel szemben, ill. arrol, hogy elavul a regi mcs51 es pic assembler paradigma.

A fogyasztas csokkentes talan azert nem jo erv, mivel ezt a regiek is tudjak, sleep mod, stb.

Nézd át a fórumot, itt idézte valaki. Különben is, az összehasonlítási alap a 200Ft-ból építhető Atmel programozó.
A PIC-es gagyi programozók meg azon kívül, hogy ezzel nem versenyképesek, pár évente mehetnek a kukába - hála Microchip szemét üzletpolitikájának.
Azon kívül mondj egy 360 Ft-os PIC-et, amivel az említett kétcsatornás USB szkópot csak _megközelíteni_ tudod:)))))))
http://yveslebrac.blogspot.com/2008/10/cheapest-dual-trace-scope-in-gal…

Átnéztem, mert nem emlékeztem rá. Meg is találtam, de ott egy ARM programozóról volt szó!

A csoda 200Ft-os programozó működik laptoppal is, amin se soros, se párhuzamos port sincs?
Lehet 3 csatornás szkópként használni?
Teljesen üzembiztos?

PIC-hez is lehet találni a neten mindenféle olcsón elkészíthető kapcsolást, de az üzembiztosságuk kérdéses...
A Pickit2 PIC10F-től dsPic-ig (+ serial eepromokat és néhány más eszközt is kezel) használható, és szerintem megéri, hogy nem azzal kell szenvedni, hogy most a programozás sikerült rosszul, vagy a programban van valami hiba.

Nagyon-nagyon kezdő vagyok PIC terén, más típusú mikrovezérlőkkel pedig egyáltalán nem foglalkoztam, úgyhogy biztosan nem én leszek, aki ennél olcsóbb / szebb / jobb kétcsatornás szkópot csinálok PIC-ből.
De azt hiszem hobbi célú felhasználásnál (ez az egész topik onnan indult) kb. mindegy hogy egy mikrovezérlő 300 vagy 500 Ft, valószínűleg nem használsz belőle olyan mennyiséget, hogy ez döntse el a kérdést.

PIC-hez is lehet találni a neten mindenféle olcsón elkészíthető kapcsolást, de az üzembiztosságuk kérdéses...

Aki megnézi a neten található kapcsolásokat, elolvassa a datasheetet, hogy hogyan kéne programozni, az tud összetákolni PIC-hez is kb. 200 Ft-ból egy működő interfészt. Nekem pl. elsőre összejött.
Fog kelleni hozzá viszont rendes soros port, meg külső táp, de hát akinek az sincs odahaza, az meg mit akar...

( tovis v | 2010. 12. 10., p – 08:55 )

Kicsit kezd terjengővé válni ez topic. A processzor, gyártó és vagy család választása rengeteg mindentől függ. Ha hobbizni kell akkor amihez könnyebben hozzáférsz, még az ár sem annyira döntő.
Ha professzionálisabb dologra kell (értsd pénzt akarsz belőle látni) akkor a beágyazott feladatnak legmegfelelőbb processzort kell választanod, ahol is a képletben a legsúlyosabb tényező a feladat.

Hobbista dolgokhoz, pénzért (a hobbikra szoktunk áldozni), nekem ez tűnik a legszimpatikusabbnak:
http://dangerousprototypes.com/bus-pirate-manual/

Ha olcsón akarod ott a Wiggler - alapvetően egy 74HCT245 -ös meghajtó tok.
http://www.ccac.rwth-aachen.de/~michaels/index.php/hardware/armjtag

A jövő pedig az ARM komplexitású processzorok irányába mutat.

Majd' elfelejtettem: a felületszerelés nem olyan szörnyű, számos hobbi bolt árul olyan kis paneleket, amire felbiggyesztehted és aztán a szokásos 0,1" raszterbe illesztheted a procit.

* Én egy indián vagyok. Minden indián hazudik.

( szokea | 2010. 12. 10., p – 19:24 )

Xmega mindent tud játékra és kisebb projektekre is ideális.
Hálózatra +ENC28J60 ..
mscbp.hu a magyar disztribútor az árak nem vészesek.

szokea

( zsiros | 2010. 12. 19., v – 21:30 )

Ha már ennyi szakember gyűlt össze, hagy kérdezzem meg, hogy szerintetek Atmega88-nál mi történik akkor, ha HC-49US reduced size kvarc és két 18pF-os kondi helyett egy HC-49U standard height kvarc-ot és két 30pF-os kondit teszek? Azt feltételezem, hogy azzal is simán elmegy. Szerintetek? (Az AvrUsb500v2 programozót szeretném megépíteni)

En 27pF-os kondenzatorokkal siman hasznaltam mar tobbszor is. Valoszinuleg siman menni fog, maximum egy kicsit nagyobb lesz a fogyasztas. De - ha a programozo utanepiteserol van szo - gondolom ez nem annyira kritikus. A "nagy" kvarc meg csak helyet foglal, mas baja nincs. Viszont a FUSE bitek ehhez kapcsolodo reszet jol allitsd be, mert az lehet hogy nem indul be a rezges. (A "szakember"-t meg most nem kommentalom... :) )

Van a mikrokontollerben a program-memorian kivul meg par byte-nyi konfiguracios resz, ezekeht hivja az Atmel FUSE-nak. Az ATmega88-ban 3 ilyen "regiszter" is van: hfuse, lfuse, efuse. (Ezek is EEPROM memoriak, a programozaskor allitod be oket, termeszetesen kikapcsolas utan is megorzik a tartalmukat.) Ezekben minden egyes bithez valamilyen funkcio tartozik (meg szep! :) ), van koztuk tobb is, ami az orajel eloallitasahoz kapcsolodik. Ha nem jol vannak beallitva, a kulso kvarc nem fog elindulni, nem lesz a toknak orajele, igy nem is fog menni. A "gaz" az tud lenni, hogy a programozashoz is kell orajel. Alapbol egy belso, kalibralt RC oszcillator szolgaltatja az orajelet, de ha Te kulso kvarcot akarsz hasznalni, akkor a belso valoszinuleg Neked nem jo... Tehat at kell allitani ugy, hogy a kulso kvarc legyen az orajelforras. De ha az nem indul el, orajel hianyaban nem fog menni a programozas se. :) Amugy egy kerdes: a Te kerdesed ATmega88-ra iranyult, viszont a linken levo kepeken ATmega8 van a cuccban. A FW tamogatja az ATmega88-at is? A ket tokban sok a kozos (viszont pl. mas az I/O terulet merete, a regiszterek is mashogy vannak kiosztva, mashol mezdodik a RAM, ...), de 1-az-1-ben nem tudja az egyik a masikra forditott progit futtatni!

Szerk: jobban megnezve a linket, a kapcsolasi rajzon az AVR tipusanal ATmega8, ATmega88, ATmega168 szerepel, ugyhogy a vegen a kerdes targytalan. De benne hagyom, okulas veget... :)

Jo kerdest tettel fel... :) Bootloadert mar irtam, de a FUSE biteket nem kellett programbol allitgatnom. Nem a programmemoriaban vannak, mashogy kell oket kezelni. Olvasni biztos lehet, a katalogus 276-ik oldalan a 26.8.9-es resz targyalja, ill. a LOCK biteket lehet irni (26.8.7-es resz). Mintha ott is lenne valami megkotes (csak "befele" lehet a biteket programozni, tehat szigoritani tudsz csak), de erre most nem talalok utalast. Igy ranezve a FUSE bitek irasanak lehetosegerol nem talalok semmit, de csak gyorsan futottam at, lehet hogy megoldhato.

A kondik arra szolgálnak hogy a kvarc a megfelelő modusban és frekvencián rezegjen, illetve még hőkompenzációt is szolgálhat. Ha megnézed egy kvarc frekvencia karakterisztikáját, egy nagy kupac rezonáns frekit fogsz látni, a minőség/kivitel függvényében a névleges rezonancia freki körül akár egy szép pamacsot is. A pamacsban tud ugrálni is (pl. hőre) ezt lehet megfogni a kondival. Általában, nagyon ritkán lehet találkozni olyannal, hogy van némi eltérés a névleges frekvenciától de ezt még mérni sem egyszerű - mérőfej kapacitás 10-15 pF. Szóval ha rezeg és a kapcsolat van a géppel (jó a baudráta) nem lehet gond. Szoba hőmérsékleten fogod használni, ebből sem lehet nagy gond.
Nyugodtan próbálkozz meg a 30 pF kondikkal, ha nem megy akkor nem biztos hogy a kondiban van a hiba (nekem már sikerült úgy vennem 20 db CPU + 20 db 24 MHz kvarc hogy az egész sorozat kvarc sz'r volt).

* Én egy indián vagyok. Minden indián hazudik.

( mspike | 2010. 12. 20., h – 08:19 )

Hello,
előre is bocs, lusta voltam végig olvasni az egész topic-ot... Annyit szeretnék javasolni, hogy AVR helyett ha akarsz Ethernet-et akkor már egy ARM-mal kezdjél... sokkal nehezebb lesz a dolgod.... DE, annak idején én is AVR + uChip Ethernet illesztővel csináltam a diploma munkám, és mikor pont a jó részekhez értem volna kifogytam a hardverből... igen bosszantó, mert onnan már nem nagyon van visszaút... lehet gányolni, több memóriát akasztani rá stb... de talán egyszerűbb már mindjárt az elején egy nagyobb ARM-mal indulni... MSC árul kész proto bordot is ha a programozás rész jobban érdekel mint a "hegesztés" :) így is forraszthatsz eleget amikor csinálod a senzorokat, vagy húzod a kábelt a lákásba :D (kábelezésre használj majd biztech-es kábelt, van benne két táp dzsinórr :D meg egy csomó jelvezeték... nagyon klassz cucc)

Üdv P.

( Cozi v | 2010. 12. 30., cs – 15:30 )

Nos, eljutottam egy darabig, de most segítséget kérnék.

A PIC-es fejlesztői panelem remekül működik, a Microchip "Microchip Solutions v2010-10-19\USB Device - HID - Custom Demos" mintaprogramjával játszom. Win alatt tudom vezérelni az áramkört, adatot fogad a program, csodás. Én Linux alatt szeretném ugyanezt elérni (a win-es c++ forrásban megtaláltam, milyen adatot kell küldeni és fogadni). Ahogy körbenéztem, a libusb olyan könyvtár, ami win és linux alatt egyaránt elérhető. Nosza, akkor használjuk, gondoltam.

Nem vagyok járatos, így a Gugliban addig jutottam, hogy Freepascal alatt egy unit segítségével elérhető a libusb. Sajna ubuntu 10.10 alatt sehogy nem bírtam telepíteni (feloldhatatlan csomagfüggőségi hibával ejti a telepítést, de a részletekhez csak ezt írja: "mseide-msegui").

Akkor megnéztem, és elvileg Java alól is használható a libusb, de nem találtam általam felfogható leírást a Netbeans alóli használat belövéséhez.

Akinek van tapasztalata, adna egy kis segítséget, hogyan lépjek tovább ezen a problémán?

Maga a PIC-es programoz C alól megy, nem tűnik nagy ördöngösségnek, de PC-n szívesen maradnék az előbb említett két nyelvnél.

Üdv, Cözi

Elosszor en is libusb-vel csinalnam C-ben. Arra van egy csomo pelda a neten, alap funkciokat kb 1 oldalnyi kodbol meg lehet valositani. Ha mar mukodik, at tudod tenni FP-re, de talan java-ra is.

Hogy pelda is legyen, itt egy rovid rutin ami egy lcd-re tol ki par bajtot : 


/*	User mode Displaytech 64128A USB driver
	V 2005.07.29.
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <string.h>
#include <errno.h>

static int idVendor  = 0x0547;
static int idProduct = 0x2236;
static int bcdDevice = 0x0000;
int altsetting = 1;
int interface = 0;
int config = 1;
int timeout = 3000;
int claimed=0;

#include "libusb.c"

int do_exit(int ret) {
    if (claimed==1) usb_release_interface(device_handle,interface);
    usb_close(device_handle);
    exit(ret);
}

int main(int argc, char* argv[])
{
	unsigned char linedata[32][64];
	int line;
	int fd;
	unsigned char *fbuf;
	fbuf = malloc(1024);
	if((fd = open(argv[1], O_RDWR)) < 0) {
		perror(argv[1]);
		exit(1);
	}
	fbuf = mmap(NULL, (1024), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

	if(0 <= usb_find_device()) {
		printf("device (v=0x%04x p=0x%04x) found\n",idVendor,idProduct);
	} else {
		printf("Error: device (v=0x%04x p=0x%04x) not found, %s\n",idVendor,idProduct,strerror(errno));
		do_exit(-1);
	}
	if(0 <= usb_claim_interface(device_handle,interface)) {
		printf("interface (i=%d) claimed\n",interface);
		claimed=1;
	} else {
		printf("Error: could not claim interface (i=%d), %s\n",interface,strerror(errno));
		do_exit(-1);
	}
	if(0 <= usb_set_altinterface(device_handle,altsetting)) {
		printf("active alternate setting (alt=%d) set\n",altsetting);
	} else {
		printf("Error: could not set alternate setting (alt=%d),%s\n",altsetting,strerror(errno));
		do_exit(-1);
	}
	for(line = 0; line < 32; line++) {
		linedata[line][0] = line;
		memcpy(linedata[line]+32, fbuf+line*32, 32);
		if(usb_bulk_write(device_handle, 2, linedata[line], 64, timeout) < 0) {
			perror("usb_bulk_write");
		}
	}
	while(1) {
		for(line = 0; line < 32; line++) {
			linedata[line][0] = line;
			if(memcmp(linedata[line]+32, fbuf+line*32, 32)) {
				memcpy(linedata[line]+32, fbuf+line*32, 32);
				if(usb_bulk_write(device_handle, 2, linedata[line], 64, timeout) < 0) {
					perror("usb_bulk_write");
				}
//				printf("Change in line %d\n", line);
			}
		}
		usleep(10000);
	}
	free(fbuf);
	return 0;
}

Túl vagyok egy hajtépős hétvégén, de végre működik Linux alól az USB vezérlés. Nem sikerült a libusb-t életre csiholnom, így a hiddev-en keresztül zaklatom az áramkörömet.

Másnak mik az ilyen irányú fejlesztési tapasztalatai?

Üdv, Cözi

---

Azóta sikerült a minta áramkör összes képességét elérni. Most nagyon tetszik nekem ez a PIC-es világ :-)

Én is mostanában játszottam PIC-cel, addig sikerült eljutnom, hogy két PIC-et összekötöttem I2C-n, amin keresztül tudtam üzenetet küldeni a mastertől a client felé, illetve meghajtottam vele hétszegmenses kijelzőt.

Ezek egyelőre csak kísérletek voltak a valódi program előtt, de még csak itt tartok. Amik nekem kelleni fognak:

* PC->PIC USB kommunikáció
* óraszinkronizáció
* PWM output
* lehet, hogy több PIC kell, ezek között I2C kommunikáció lesz, illetve óraszinkronizáció I2C-n

A működő USB-s kódjaidat (mind PIC, mind PC oldalon), ha megosztanád, az nagy segítség lenne. Cserébe fel tudom tenni az I2C-s kódokat valahova, ha érdekel.