Sziasztok!

Kipróbáltam a 2.4-es Microchip USB Frameworkben lévő USB Device - CDC - Serial Emulator-t PIC18F14K50-el.
Az USB bekötését a PIC18F4550 minimális usb kapcsolási rajzról másoltam.
Az átalakító működik, a sebességet átállítottam 57600 bps-re.
Viszont megnézve a Low Pin Count USB Development Kit Users Guide-ban a kapcsolási rajzot, látok néhány ellenállást amit én kihagytam. A mellékelt képen pirossal bejelöltem.
Ezekre akkor nincs szükség?
A szintillesztőm MAX232CPE és csak az RX és TX vonalak vannak bekötve.

Jelenleg próbapanelon van összekötve, de ha így jó, akkor bedobozolom.

Van egy olyan sejtésem, hogy a "bolondbiztos" kapcsolásokba azért terveznek be soros áramkorlátozó ellenállásokat, hogy a helytelen programozás következtében esetleg szembekapcsolódó kimenetek ne nyírják ki egymást.

Köszönöm szépen a választ!
Inkább nem spórolom ki ezt a néhány ellenállást.

De ha véletlenül nem működne, akkor azokat vedd ki legelőször. Én egyébként 150..270 ohm között tennék oda, illetve semilyet.

Köszönöm a választ!
Működik a rajzon feltüntetett értékekkel.

Ezen a PICen a D+ és az ICSPDAT ill. a D- és az ICSPCLK lábak közösek. Eddig nem mertem úgy USB-re kötni, hogy rajta volt a Pickit2. Nem is szabad ilyen formában? Szükséges valamilyen leválasztás?
Féltem a gépet és az USB portját.

Na igen, ezt nem értem, microchipnél hogy gondolták ezt, hogy ugyanoda teszik a két csatlakozást. Én is agyaltam már rajta, hogyan lehetne ezt üzembiztosan csinálni, de igazából nem sikerült semmi megoldást találnom. Talán az analóg kapcsolókkal (74HC4066) lehetne a legbiztosabban leválasztani az USB portról a chipet, és a programozás idejére összekötni a Pickit2-vel, vagy inkább itt kellene a bootloadert használni... De én is kíváncsi vagyok mások véleményére.

Köszönöm a választ.
Nem próbálkozok, inkább felváltva csatlakoztatom az USB-re és a Pickit2-re, vagy marad a bootloader .

Ha tényleg ilyen eszetlenül van kialakítva a bekötés, akkor a fejlesztői panelre egy kétáramkörös "beakadós" nyomógombot tennék inkább (bontani az USB adatvonalakat, amíg programletöltés folyik). Az USB kommunikációba szerintem nem lenne szabad a rádugott, de inaktív PICkit2-nek bekavarnia, viszont a programozáskor az USB 3.3V-os vonalait "nem illik" 5V-os logikai jelekkel birizgálni.

Apropó: nemrég összeraktam egy AVR-es kütyüt, amiben szoftveres (bitbanging) USB firmware két portbiten kommunikál (low speed) USB-n. Az asztali gépen rendben működött, a laptopon fel sem ismerte az eszközt. Más AVR-es, hasonló cuccok mentek rendben. Kis kínlódás után kiderült, hogy az 5V-os USB adatvonalakat a laptop nem szerette, egyszerűen nem vette a küldött adatokat. Rátettem két 3.6V-os zenert az adatvonalakra és azóta minden jó. Tudni kell, hogy az AVR-es USB-knél a két portbiten van két soros 68 ohm-os ellenállás, és ajánlás szerint az USB csati felőli oldalon 3.6V-os zenerek. Ebben az áramkörben kispórolták a zenereket. Általában működik is, de mint ahogy látjuk, nem mindig... Szóval itt megtanultam, hogy illik figyelni az USB adatvonalak jelszintjére!

Fejlesztés esetén, amikor viszonylag sűrűn változtatod a firmware-t ez egyrészt kényelmetlen is, másrészt a csatlakozók sem erre vannak kitalálva sajnos. Ha van más mód, én inkább elkerülném a dugdosást.

Múltkor olvastam olyat, hogy ezek a 1xK50 jelzésű chipek nem fejlesztésre vannak kitalálva, hanem olcsó sorozatgyártásra, ezért nincs is beépített debug lehetőség. Tehát úgy gondolták a gyárban, hogy majd fejlesztesz valamelyik xy5z chipen, ahol x legalább kettő, a már letesztelt, kész kódot csak lefordítod 1xK50-re, és sorozatban égeted, majd rakod be a kész áramkörbe és dobozolod.

Van a PICben bootloader.

Ezt annyira nem nevezném fejlesztésnek :
Csak egy kicsit módosítottam a Microchip demoján:
Felvittem a sebességet 57,6kbps-re és kiszedtem a LEDek villogtatását.
A bootloadert is módosítottam picit:
Engedélyeztem az MCLR-t és tettem be egy boot gombot.

Amúgy bootloadert szoktam használni USB-s PIC esetén.

Ez hihető magyarázat (ha jól emlékszem a flash endurance is elég kicsi szám ezeknél a PIC-eknél), ettől függetlenül nem biztos, hogy a portolásnál elég a chip típusát átírnod fordítás előtt, tehát minimális fejlesztési lehetőségekre azért szükség lehet. A fejlesztői környezetben szerintem mindenképpen célszerű valami olyat kitalálni, ami szükségtelenné teszi a csatlakozók ki-be dugdosását.

A programmemóriát ezerszer, míg az EEPROM-ot 100 000-szer lehet újraírni.
Hobbi célra elég lehet. Én úgy szoktam, hogy ha valamelyiket fejlesztésre használom, azt hagyom a kész áramkörben.

Sziasztok!

Olyan kérdésem lenne, ha USB eszközként használom a PIC-et (akár HID, akár CDC), mindenféleképpen belefutok abba, hogy kikapcsolja a megszakításokat?
Egy olyan eszközt akarok csinálni, melyre a működéséhez szükséges adatokat USB-n keresztül töltöm fel, de ezek az értékek bármikor változhatnak, tehát fixre nem építhetem bele a programba.
Viszont a megszakításokra szükségem van, és már egy alap USB-s programnál is kiírja a PIC C, hogy kikapcsolja a megszakításokat. (Interrupts disabled during call to prevent re-entrancy: (usb_token_reset))
Ilyenkor mit tudok tenni?

Valami bővebbet írják, hogy miért is lenne szükséged a megszakításokra, mert a feladatok nagy része valódi megszakítás nélkül is megoldható, elég ha csak a főprogram végtelen ciklusából figyeljük a megszakításjelző flageket.

Milyen C-ben programozol? Mert nekem nem írta ki ezt az MCC18-ban. Jelenleg is megszakítást haszálok magára az USB pollingra is(CDC).

Hű, pont ilyen kellene nekem is! A CDC demót módosítottad? Beavatnál a részletekbe?

Mintha a legújabb microchip usb csomagban már lenne HID és CDC is megszakításból használva. Én is csináltam régebben egy ilyen módosítottat az 1.3-as csomagból, valahol ebben a témában be is linkeltem úgy emlékszem, de az biztos, hogy több terhelést jelentett az enyém a processzorra nézve, mint a pollingos módszer. Persze lehetett volna rajta optimalizálni, de én csak azt akartam megnézni, hogy működik-e, és tovább nem csináltam vele semmit.

Gyújtásszögvezérlőt csinálok, a megszakítások a timerek miatt kellenek, meg a holtpontjelzés miatt.
Van 3 megszakítás az EXT, ami a jeladótól jön - a holtpont figyelés, van egy timer ami bekapcsolja a trafó töltését/megszakítja a trafó töltését, és van egy timer, ami reseteli a munkaállapotot (túl sokáig nincs jel, akkor leállt a motor, nem töltünk, nem számlálunk)
Szerintem ezek mindenképp kellenek. :/

Szerkesztve: PICC-t használok

Itt találtam egy csomagot. Köszönöm!

Ez egyébként 1.2 verziónak mondja magát...

A Timer0 high megszakítást okoz, kevesebb mint 1ms-onként. A lekezelés a következő:


A main-ban pedig van egy főciklus:


A User_Process és a USART_Controll a user.c fájlban van.
Az USART_Controll nálam egy RS485 hálózatot jelent, de helyette nyílván bármilyen az USB-től független folyamatok lehetnek.
Ja igen a Timer0_Count itt nem érdekes, máshol használom...

Igen, a terhelés több, de nem történhet meg, hogy egy megszakítás lekezelése miatt nem biztosított a válasz a PC pollingjára. Én se csináltam volna így, ha nem lett volna gondom pl. amikor egy USART megszakítás jött.

Köszönöm az információt! Ez így egyszerűnek látszik.
A főprogram ciklusa már ismerős, s pont ez volt a célom, hogy az USBTasks() kikerüljön onnan, hogy a főprogramban ne legyen időkritikus tevékenység.

Egy egyszerű parancsértelmezőt szeretnék a User_Process() helyére tenni, ami a PC-ről jövő utasítások szerint tevékenykedne (impulzusszámlálás, DAC vezérel tápegységek beállítása, feszültségmérés, miegyéb). Az adatokat meg külön parancsra átadná a PC-nek.

Nincs mit! Én is pont ilyen formán használom.

Üdv!

Van valakinek tapasztalata PIC USB+SPI kombóval?
Mert a kettő külön-külön frankón működik, de ha "összerakom" a kódot a PIC-be akkor sem az USB sem az SPI nem megy. Egyik sem megszakításos, hanem 'simán' végtelen ciklusba futnak.
Ja még annyi, hogy 18F14K50 mplab c18 fordító, és hardveres SPI. (az USB és az SPI is a példaprogram alapján )

Köszi

Pont ez az ok.

Akkor ezek közül valamelyiknek vagy mindkettőnek interrupt-al kellene működnie?

Egyébként lehet hogy az SPI annyira visszafogja, hogy nem tud 100mikrosec-enként lefutni az USBDeviceTasks();? Csak 2 bájtot küld ki az SPI

Az USB igényli, hogy 1ms-enként választ kapjon a pollingjára. Ezt megszakításban meg lehet oldani. Nemrég volt erről szó, olvass vissza pár oldalt.

Az SPI nem ennyire időkritikus.

Nem muszáj egyiknek sem, csak nem szabad, hogy az SPI-s rutin hosszú ideig fusson, és lefogja a processzort. Jó lenne ismerni a ControlSPI() függvényt belülről, de szerintem jobban járnál, ha kézzel beállítanád az SPI reigsztereket, és figyelnéd a while(1) ciklusban a megszakításjelző flagjének a bebillenését (SSPIF vagy valami ilyesmi), ha bejövő adatra vársz. Bár ha a kontroller a master, akkor végülis nem kell adatra várni, előre ismert idő alatt jön be az adat. Szóval szerintem az a ControlSPI() csinál valami galibát...

x=(int)(fabs((float)(val-curr_pos))); tudom, tudom ez jól lelassítja de enélkül is 'megakad'
Egyébként visszább olvasva, valaki írta hogy teliszórta USBTask() metódussal az egész kódját, na énis megtettem (a kódot nem másolom be mert undorító lett ) de most legalább működik igaz a státuszledek villogása a 100-ad részére lassult