Nem erre gondoltam, hanem valószínűleg újabb technológiát alkalmaznak a gyorsabb/nagyobb kontrollereknél és lehet, hogy a "belső EMC-vel" nem tudnak megbírkózni!

4-8 mhz-es kvarcok meghajtásáról beszélünk? Mit keresne ott az emc?

Lehet olyan is, amire kissi céloz, hogy egy adott áramköri csoport, mint pl. az oszci, rossz helyre lett tervezve, ezért ha fut, akkor a mellette lévő más részeket bezavarja. Ezt áttenni azért nem olyan egyszerű, mert egy kis négyzetbe belezsúfolni mindent, hogy még jól is működjön, nem egyszerű játék. Szerintem a Microchip jóval le van maradva más nagy nevű gyártóktól(Intel, AMD) technológiában, ezért jönnek ezek a dolgok a nagyobb sebességeknél, gondolom.
De lehet, hogy olyan gond van, amit te említesz...

Pl. A belső mag nem 3.3V -on jár, de a külvilággal 3.3V -os illesztőkön keresztül tartja a kapcsolatot. Az oszcillátor lábak digitális ki/bemenetek, átprogramozható funkciójú lábak. Egy megbonyolítja a kivezetések áramkörét.
Ha azt nézzük, hogy a 32MZ bejelentése kb 1.5 .. 2 éve törént és már a 4. verziónál tartanak, akkor feltételehzetően volt jó néhány jelentősebb problémájuk, amit mindenképen ki kellett javítani a forgalomba hozatal előtt. Sokan mozdultak rá a családra, készítettek már teméket (már gyártásban van, de még mindig nincs megfelelő típus hozzá). A piac kikövetete, hogy valamit kiadjanak, hogy lehessen tesztelni a programozókat, fejlesztőket, programokat.

Szerintem is a piac miatt jelent meg. Nem tudom milyen nehéz változtatni egy magon, de biztosan nem könnyű, ha ezt még nem javították ki. Persze lehet mondani, hogy nem nagy dolog egy külső órajelet rákötni, és talán igaz is, de midenesetre fura, hogy ilyen amatőrnek látszó hibát el tudnak követni. Ez olyan, mint ha egy autónak csak mankó kerekei lennének, vagy csak tréleren lehetne szállítani...

Sziasztok!

Igaz, máshova már felraktam ezt a kérdést, de ott javasolták, hogy inkább ide kellene felrakni, valamint a moderátorok szíves elnézését kérném, a "XVIII. Csak egy helyen kérdezz!" szabály megsértése miatt.

Segítséget szeretnék kérni, hogy hogyan induljak el a feladatom megoldásához.
A feladatom a következő: Adott egy PIC32(mx440f512h), ami bizonyos feladatokat lát el. Adott egy PC, aminek értékeket kellene kiolvasni az eszközből, illetve értékeket beírni. Mivel az eszköznek hordozhatónak kell lennie (pontosabban PC függetlennek, maximum illesztőprogram szükséges), ezért én az USB-s kommunikációt tartom a célnak megfelelőnek.

Tehát a kérdésem volna, hogy a feladat megoldásához milyen anyagokat nézzek meg, minek olvassak utána, mikre lesz még szükségem?

Mellékes információként még elmondanám, hogy a PC oldali vezérlő programot én C# nyelven szeretném megírni, illetve a PIC-et pedig valamilyen C nyelven, jelenleg az MPLAB X (XC32-vel) és a mikroC PRO for PIC32 áll rendelkezésemre. Az USB sebesség az nem fontos, illetve az eszköznek működnie kell ha nincs USB kapcsolat, viszont a kapcsolat alatt nem árt a működés.

szerk.: Elvileg keddre kellene kész lennie a cuccnak...

Szerk. 2: Amit eddig találtam Gugli barátunk segítségével, az a libUSB a PIC-hez és LibUsbDotNet a PC-hez, bár tutorialokat, meg példakódokat nemigen találtam hozzá, de remélem ez jó kiindulási alapnak.

Szerk. 3: Esetleg ha valaki venné a fáradozást, és tudna engem korrepetálni egy kicsit ebben a témában, azt nagyon-nagyon megköszönném

Sziasztok!

Belefutottam a MODBUS kommunikációs protokollba, és van néhány dolog amit nem értek. Ha valaki tudna segíteni nagyon megköszönném.
A protokollt értem, azonban azzal van problémám, hogy az adatok, amiket később ezen a kommunikáción keresztül szeretnék átvinni, hogyan, és hova kerülnek a pic-be. Az még rendbe lenne, hogy a pillanatnyi állapotokat kiovasom, de a modbus-ban van valami olyan, hogy "regiszterekből" olvassa ki az adatokat. Gondolom ezek sima memóriacímek. Na ezt nem értem, hogy milyen adatokat, és minek kell elmenteni? Úgy feltételezem, hogy két féle kiolvasási mód lehetséges, egy pillanatnyi állapot, és egy mentett állapot. Minek?

Szia!
Nem vagyok szakértő, de használtam már PIC-el... Nem igazán értem a kérdésedet, mert a MODBUS egy protokoll, le van írva, hogy milyen sorrendben kell küldened és hogyan az adatokat: azt, hogy mit és miért, azt Neked kell tudni ( ill. ha van egy gép, akkor az ezzel a protokollal az általad kért adatot küldi, ha meg Te csinálod a programot, akkor a kérdés értelmezése után a megfelelő byte-okat kell az adatfolyamba beillesztened !) !?

Kicsit fura, hogy azt írod, a protokollt érted, aztán felteszel pár kérdést, amiből kiderül, hogy nem.
Természetesen az adatok mindig memóriában vannak és onnan jönnek-mennek. Tehát a vett adatokat az adat memóriába teszed(bár néha ez lehet EEPROM, vagy akár flash, illetve bármilyen memória típus, ha létezik a fogadó áramkörben). Viszont a modbusz regiszterek címei nem egyeznek meg a PIC memória címekkel, azt neked kell lekezelned, neked kell meghatároznod, hogy egy MODBUS regiszer, vagy regiszter mező mit tartalmaz és milyen címre hivatkozva éred el.

A MODBUS egy protokol, amit PLC -khez fejleszettek ki. Egy PLC -ben többféle típusú adat is lehetséges. MODBUS típusok szerint: Coil - digitális kimenetek állapota; Input status - digitális bemenet állapota; Input regiszter: több bites periféria állapota (pl. A/D átalakító, eseményszámláló); Holding regiszter: a PLC belső regisztere (számított értékek tárolására - üzemóra).
A különböző adattípusokat a nekik megfelelő táviratokkal lehet kiolvasni ill (amelyiknél lehet) az értékeket beállítani.

Ezt írta és OK, hogy PLC-re fejlesztették ki, de ma már sok periféria ismeri ezt a protokollt, így neki kell tudni, hogy milyen módon és mit akar/tud elérni, ill. leprogramozni ( és a PIC-eket is meg lehet tanítani rá ! ) !

Bocsánat, elnéztem a hozzászólást. tamasati -nak szólt volna.

További kérdéseidet majd a PIC - USB - PC témakörbe tedd be! A C# mintaalkalmazásra ott már találsz is egy általam berakott linket (én magam nem próbáltam, én a Visual C++ 2008 Express-ben írt Microchip demókkal szoktam szerencsétlenkedni, azokat írom át céljaimnak megfelelően).

A Microchip Libraries for Applications mintapéldáival érdemes kezdeni. Ha a 64 bájt/1ms sebességnél nem kell több, akkor a Device - HID - custom demos mintapéldát ajánlom.

Semmi gond !

Koszonom a segitseget, vegig fogom oket nezni

tamasati:

A MODBUS-nak van néhány layer-1-es fejlesztése, van pld modbus via ethernet, de a legáltalánosabban használt protokol a modbus rtu, ami layer-1-en egy sima rs485 half duplex uzemmódban, és az minősül reset event-nek, ha 3 millisec ideig nincsen kommunikáció. Reset után adat csomag kezdődik fejléccel, és mezei soros portos adatfolyammal a header + data megcímez neked egy regisztert, és írja, mit szeretne oda berakni, vagy éppen azt a regisztert kéri tőled vissza. Veszed a csomagot, és kielemzed, mit tegyél, aztán megteszed. Általános protokol szerint half duplexen a master egyszer kérdez, és utána addig vár, míg a megcímzett slave el nem küldi neki az adatokat. Ha 3 millisec ideig nem küldte el, akkor már ne is küldje, time out error state van. De ezeket mind ming megtalálod a modbus.org sire doksijaiban. Rá kell szánni az időt és rendesen végig olvasni legalább egyszer mindent. Ha kutyafutta holnapra működjön, inkább felejtsd el. Túl sok mindenről kell ott gondoskodni, és ha végig olvastad, kicsit emészteni is kell a gondolatot, hogyan is építs áramkört ahhoz, hogy azzal a kommunikációval jó legyen.


cmdnetwizard:

Talán a modik ezért még nem tépik szét a koponyacsontomat Frissen küzdöttem meg hasonlóval. Tippek: töltsd le az mc 2013 febr 15-ös libet, abból a lib generic device demo-t használd, pc oldalon pedig libusbdotnet teljesen tuti c#-hez, a site-ján példaprogramokat is találsz. Elméletben 64 byte*19 / 1 msec, de az csak dma-val tud meglenni. Ha win7 alól tolod programozottan, és mindig várnod kell a protokollod szerint oda-vissza válaszra, a libusb0 driver 128 / 1 sec sebességgel fog oda-vissza válaszolni (64 byte / 8 millisec lesz a sávszélességed). A régebbi "normális" ( ) mplab-ot használd fordításhoz, vagy írj magadnak fordítóscriptet. A demo nagyon egyszerű, rászánsz pár napot figyelmesen, nem lehet vele problémád, olajozott a cucc.


Más. Pic32mx kérdés.

Valamiért az spi-re azt írja, 20-25 mhz-ig üzemképes, és nem nagyon tudok rájönni, miért. Ahogy nézegetem az oszcillátor blokkot, pic32mx1/2 esetében is, meg mx3..7 esetében is fel lehet programozni azt a baudrate generator-t 40 mhz-re, és elvileg dma-val tudhatja a gyakorlatban is megtáplálni a kimenetet akkora sebességgel. Próbálta már valaki maxig kihúzni a 32mx-ek spi-jét? Csak külső áramköri parazita-jelenség probléma a probléma, hogy gyenge lenne a meghajtás vagy ilyesmi, vagy van valami belső proci mag gyengeség is, amit adatlapból nem sikerült kinyomoznom?

Sziasztok!
A kérdésem elsősorban arra irányul, hogy jól gondolom-e a következőt:
Adott egy PIC18F46K80-as eszköz, megszakításban soros, spi, can, és 3 timer szalad. Ez utóbbiban van [1 msec-es] analóg jelek digitalizálása. Külső szemlélőként teljesen véletlenszerűen az analóg értékek beolvasása jócskán eltér az előző ciklusban beolvasott-tól. Pl. n. ciklusban 100 a konvertált érték, az n+1. ciklusban már 500.
Az előfordulhat, hogy az analóg mintavételezést, ill konvertálást megszakítja egy másik interrupt (ez természetes) és közben az adc már nem lesz megfelelő érték, ahogy visszakapja a vezérlést
a timer0? (ebben van az adc read). Tiltsam le az adc_read-ben a megszakításokat?
Minden mikroC-ben. Minden megszakítás alacsony prioritású, egyszintű.

Köszönöm,
Roland

Csak akkor, ha a GIE bitet a megszakítási rutinban állítod. Nem szabad állítani, a retfie utasítás megoldja.

Először próbáld meg,hogy letiltasz mindent, csak az AD fusson és az is sokkal lassaban. Állíts elő megbízható feszültség forrást, pl. elem leosztásával, majd vizsgáld a kapott értékeket. Ha ekkor jó lenne, akkor vizsgáld a valós forrást. Ha ekkor is jó, akkor gyorsítsd fel 1k-ra a Timert. Ha ekkor is jó, akkor egyenként indítsd el a megszakításokat. Ki fog derülni hamar (szerintem az első pár lépésben), hogy mi a baj. Nem hinném, hogy a megszakítások miatt van...

Én is inkább az az akvizíciós idők és az A/D órajel beállításai körül néznék szét. Az IT nem szólhat bele, az átalakítás akkor is lezajlik, hogy az eredményt mikor olvasod ki, ettől független.

Az átalakítás indítása mikor történik az is befolyásolhatja.Amikor indulnia kellene , akkor van megszakításban valami miatt az sem igazán jó.A következő kérdés , milyen frekvenciájú jelet milyen időtartamonként digizel. A szinusz egyes részei igen meredekek.

Persze ez így van. Több azonos szintű megszakításnál úgysem lehet pontos időzítést csinálni. Arra gondoltam, itt inkább az lehet a probléma, hogy a csatornaváltások között nincs kivárva a megfelelő idő a mintavevő kondi töltésére/kisütésére. Az A/D a GO bit bebillentése után 1 ciklussal leválasztja a kondit, innen 14 TAD-ra megszületik az eredmény. Hogy a proci mit csinál közben, az mindegy, az eredményt nem befolyásolja.

Nem állítom a GIE bitet egyik megszakításban sem.

A konstrukciótól nagyban függ ez, sajnos nem jöttem még rá, hogyan tudom kiszedni csak pl. az adc-t.
Azt kipróbáltam, hogy potival leosztott megbízható analóg inputot adtam az eszköznek, amikor már ebbe a fázisba került a gép. Egy idő után szintén előjön ez a probléma. A mintavétel idejétől sem vettem észre releváns függést.

Tehát a mintavétel indítása előtt pl. kapcsoljam ki az GIE-t?
A jel változása "lassú" néhány száz érték / mp (12 bit adc-n értve) - és a konstrukcióból adódóan sem lehet hirtelen változás. Ezt be is írtam a programba, hogy hagyja ki az extrém kiugró értékeket. Ez segít bizonyos esetekben, de jobban érdekel, hogy mitől vannak ezek a kiugrások...?
A jel maga nem stacionárius.

az analóg beolvasó int rutin forrásrészlet:


elméletileg csatornaváltosokra van 5 usec delay per pillanat . A chip 48 MHz-en megy.
Valszeg az 5 usec a kevés?

Ebből a programrészből nem tudom megmondani, de az biztos, hogy a csatornaváltás után kellene várni (ami gondolom az ADC_Get_Sample függvényben van), nem a mérések között, bár oda is javasol 2TAD-ot, ami a javasolt 64Tosc-nál nem kevés idő, ha nem a belső RC órajelet használod. Különben az 5-10us elegendőnek tűnik.

Miért, nem te írtad a programot?

De. Abszolút.
A bug-gal együtt Csak nem találom mi okozza....

Belső RC clock, 2 TAD a beállítás.
Az ADC_Get_Sample() rutin: (ezt a mikroC libraryból hívom)


Ahogy nézem van benne delay. Meg azt is, hogy jó hosszú...