Nem a konfigurációs bitek állítják be az órajelet, hanem a program, futás közben (lásd előző beírásomat).

Azok is konfigurációs bitek, nem?

Addig kotortam a fórumokat (mindenütt csak zokogtak róla, hogy asm-ezni kell mert az xc8 eredménye nem fér bele), míg végül úgy döntöttem, leszek nyuszi, és nem most fogok megbirkózni vele. Csak maga a hid nekem amúgy kevés, bele kell férnie egy saját protokollnak is, amivel spi buszra forgatom át az endpointokat, és a sebességhez az sem utolsó, ha van annyi memória a szerencsétlen kontrolleren, hogy duplabufferezhetek. Legközelebb, ha nagyon szétesz az unalom, majd belevetem magam, és kitesztelem, végül le tudok-e fordítani xc8-al valami használhatót hozzá (belefér-e), de a mostani körben már burzsoá sznob leszek, és felhasználok egy pic32-est. Francos sok ram rulez.

(Az említett dat fileokat ebbe a topicba töltötted fel?)

Konfigurációs biteknek a nemfelejtős memóriában tárolt beállító biteket (ennél a típusnál 0xF80000 - 0xF80012 címtartomány) szokás nevezni.

Az órajel beállítására a dsPIC33 és PIC24HJ típusoknál az az ajánlott módszer, hogy a konfigurációs bitekkel belső oszcillátorra állítjuk (FNOSC_FRC), s a POR után a program menet közben maga kapcsol át külső oszcillátorra és állítja be a PLL-t a Speciális Funkciójú Regiszterek beállításával.

Ezért gondoltam azt, hogy a konfigurációs bitek beállítása nem mérvadó. Inkább a main.c-ben kell megnézni a beállító részt, az #if defined(__dsPIC33EP512MU810__) stb. után.

A PICkit2 klón topikba.

Beállítások a 48 MHz -re vonatkozólag, így próbálkozom:

A példákban sem látok PLL-unlock folyamatot, se __builtin függvény használatát, tehát gondolom érvényesül a fenti beállításom. Itt sem látok unlock szekvenciát az Aux. Osc. beállítása során: Bővebben: Link

Miért nem próbálod ki? Adott lábra adjál ki a számított órajel szerint pl. 1 Hz-es villogást és azzal el tudod dönteni!

Ha kell neked egy annyira pontos oszcillátor, hogy a belső nem elég, akkor mennie kell a külsőnek. Ha az mégsem megy, már azzal sem vagy hátrébb, hogy fagyni hagyod az egész cuccot. Akkor legalább észre lehet venni egyből, hogy valami gáz van. Részemről mindig nyugodt lélekkel configoltam külső oszcira alapból. Működés közben átállni sosem vacakoltam vele. Nagyon gány voltam?

Az előző hozzászólásokban elsősorban a PLL beállítása volt kérdéses, azt mindenképp programban kell beállítani ezeknél a típusoknál (dsPIC33, PIC24HJ).

Ha az üzembiztonság lényeges, akkor mindenképp belső oszcillátorról ajánlatos indulni, s átkapcsolni akkkor érdemes, ha a külső kristály vagy oszcillátor már stabilan megy. Ha nem lényeges, akkor az ilyen finomkodásnak nyilván nincs jelentősége.

Kezembe került sparkfun-ék ubw32-ese, amire felgyógyítanék pár usb client demo-t. Anno a 2013 februári libet használtam c32 fordítóval. Nézem a doksikat, a c32-t beszüntetett fejlesztésnek bélyegezték, és csak xc support van (ami anno halom bug volt, azért is használtam inkább a februári libet). Azóta eltelt pár hónap, és nem tudom, most mennyire idegbaj az xc fordító (mplabx nem szimpi, jobb szeretem windows parancssori scripteket, amiket magam írok meg), meg az újabb libek. Ha nagyon gáz, egy aprócska figyelmeztetést szeretnék, hogy nyugodtan pihentethetem még kicsit, vagy ha valaki próbálta már, és olajozottan gördül, akkor arról egy visszajelzést. Előre is köszönöm.

Oké, most futottam össze a 18f87j50 esetével is. Ahol elektronikai muszáj, és nem szeret-nem szeret kérdése, ott természetesen én is neki esek. Azért nem esett le a tantusz, mert mostanában többet kuksolom az olyan környezeteket, ahol bőven van áram, és nem kell centizgetni a milliamperekkel, hogy kell-e egy periféria, vagy sem, végső soron kell-e nagyobb órajel, vagy sem, és nem az akku élettartam az alfája és az omegája mindennek. Amikor van áram bőven, és az elektronika sem kötelez rá, olyankor az oszcillátorozás csak önmagáért való kínszenvedés (mert egyébként nem kicsike kínszenvedés minden alkalommal 10x átolvasni az adatlapot, hogy ne szúrjam el).

Felraktam pic32-esre egy usb lib generic demo-t, és abba a nevetséges helyzetbe kerültem, hogy nagyobb szívás azzal a pic-el kommunikálni pc oldalon, mint megküzdeni az elektronikai oldallal. Ha kényelmes programot akarok hozzá, és nem c++-al szenvedni, hanem c# alatt fejleszteni, kb egy darab LibUsbDotNet lib létezik hozzá, ami crashel szanaszét. Ha valaki talált akár működő custom libet az mc példákhoz c# alá, akár libusb_win32 portot, ami nem crashel, sikítson plz.

Axelson néni C# demóját próbáltad már? (Ezen az oldalon a My Host Applications szekcióban a winusb_cs v2.2 for Visual C# .NET-re gondolok)

Én nem próbáltam, meg a C# sem is érdekel , de keresésre hirtelen ezt találtam.

Keresgélek sorozatgyártott pic-es usb dongle eszköz után. Valami 8 bites pic usb-re kötve és bedobozolva (!). A programozásával én is elboldogulok. Egy program védelmére lenne hardver kulcsnak. Úgy kellene kinéznie, hogy ügyfélnek a kezébe lehessen adni, és amiket én fabrikálok, azok nagyon nem olyanok. Tud valaki tippet adni?

Ha nem zavar, hogy külföld, akkor aliexpress.com oldalon keresgélve USB dongle housing kulcsszóra ezt találtam.

Az első kérdés bőven nem az, ki gyártja, hanem hogy létezik-e egyáltalán? A linkelt eszköz valami ftdi cuccos. Hogyan lehetne azt átprogramozni hardverkulcsnak ? Biztos nem rossz 30 ezer forintért mindössze egy üres házat venni, de ha utána ugyan úgy fabrikálni kell bele, és nem csak átprogramozni + felhasználni, nem ér az meg nekem 30 rugót.

Szerintem ez csak a műanyag ház (méghozzá 250 db-os tételben). Olyan panelt rakhatsz bele, amilyet akarsz...

Egyébként itt is van hasonló termék: Bővebben: Link

A linkelt eszköz egész pontosan csak a ház. 250darabot adnak 112$-ért, és azt "fabrikálsz" bele, amit akarsz.

Amúgy meg azt nem mondtad mennyi kell, és ha már hardverkulcsot szeretnél, akkor bizony sajátot érdemes készíteni, egy meglévőt átprogramozni sokkal nehezebb feladat. Arról nem is beszélve, hogy amivel én eddig találkoztam hardverkulcs, azt csak roncsolással lehetett (volna) szétszedni, s utána se volt biztos, hogy sikerül újraprogramozni az eszközt (fekete pacával mit kezdesz?).

Amúgy meg lehet, hogy inkább Atmel irányban gondolkoznék és egy Attiny45-öt használnék fel, mivel az csak 8 lábacska és szoftveres USB mehet bele, vagyis jóval kissebb helyre össze lehet rakni a paneljét és akár ebbe is bele lehet rakni (ilyen piciben még kultúráltabb lenne).
Szerintem egyébként átmehetnénk a kérdéseddel a dobozolási technikák topikba, inkább odavaló a téma.

Valami félreértés lesz. Én nem dobozt kerestem. Én terméket kerestem egészben. A dobozt te kezdted el reklámozni - gőzöm sincs, miért.

Nem bántam volna, ha valaki benyögi, hogy látott valahol hobby terméket, ami felprogramozható hardver kulcsnak is. Igazán semmi több nem kell, mint egy usb tápolt áramkör benne egy 8 bites piccel, ami eredetileg a fene tudja mit csinál - felőlem aztán bármit - és be van dobozolva. A legviccesebb ötletem egyébként beszerezni valami elfekvő pickit2 készletet, ha még létezik olyan - úgy emlékszem, abban 18f4550-esek voltak - és azt átprogramozni egy mc usb generic példával 64 byte be és ki, a többit arra már rápakolom. Ha van annál jobb is, ami hardverkulcsosabbnak néz ki (mc-ék ugyanis lehetségesen a torkomnak esnek, ha ilyet követek el üzleti célra), inkább azt választanám.

Ne legyél ennyire telhetetlen! Egy 2x3 cm-es nyákot csak össze tudsz hozni egy PIC18F14k50 (vagy még egyszerűbb) mikrovezérlővel.


A legnagyobb probléma a jogszerűen használható VID,PID megszerzése lesz. Ezen nem segít a PICkit2 átbarkácsolás sem. Ezt hogy akarod megoldani?

Mert feltételeztem rólad, hogy képes vagy összerakni egy alapvető áramkört, ami nem áll másból csak egy USB csatlakozóból két kondival meg ellenállással a mikrovezérlő mellett és csak az a problémád, hogy a végső termék hogyan fog kinézni.

De ha mindenképen kész terméket akarsz venni, akkor tessék gugli első találat:
Sentinel Hardware Keys

A linket köszönöm.

Két külön esetről van szó. Ha van időm játszadozni valamivel, és csak nekem kell, fogok egy furatos próbanyákot, és forrasztgatok. Ha viszont megtörténhet olyan is, hogy egyik napról a másikra adjak elő valamiből 100 darabot, nincs idő játszadozni. A nyákot gyártatni kell, utána forrasztgatok, aztán saját nyilvántartás a serial-okról.. nem kicsike falat azt mind lenyelni. Azok a nyavajás hw keyek simán teljes embert igényelnének, pedig konkrétan abból a haszon kereken: 0. Szóval dobta a főnököm a problémát, védeni kellene a programot, és adjak neki megoldást. Meg tudom csinálni, ha elpepecselhetek vele, de ha nem, te mi mást tennél a helyemben? Köszike szépen, hogy összeszidtál valaki más szervezési trehányságaiért

Sziasztok!
Szeretnék segítséget kérni, PC és PIC kapcsolatban. Több áramkört csináltam már USB kapcsolattal, PC > PIC irányba (CDC). Notebookon fejlesztgettem, használtam. Mindig minden ment, felcsatlakozott, működött. Egyszer egy asztali géppel akartam használni, és nem csatlakozott fel, nem ismerte fel a külső eszközt (soros portként), hibát jelzett, stb.. Ha USB HUB-on keresztül csatlakoztam, akkor néhány HUB esetén működött, de bizonytalan a működés. Gyakorlatilag minden asztali gépen gond van, laptopon soha, és nincs szükség HUB-ra. A működése egyszerü, csak adatot küldök a PIC-re, másodpercenként 10 byte. A kontroller kiteszi a kapott adatot két portra, és kész.

Köszönettel: SzB.

Milyen alkatrésszel van megoldva az USB CDC illesztés?

18F4550 PIC, a példák és programok szerint.

Ami még kimaradt. 230MHz- 2G PROCI, xp - WIN8.1 (32bit) tesztelve.

A Win 8.1 alatt voltak és vannak problémák a Microchip USB programjaival. Az okok valószínűleg az USB 3 kezelése miatti változtatásokban keresendő.

Rendszertől függetlenül, csak bizonyos HUBbal megy asztali gépen, de akkor is esetleges. Notebookon mindenen, mindig.

Tápszűrési problémákat sejtek. Esetleg tápfeszültség nagyságában lehetnek eltérések. Tegyél még 100nF kondikat tápvonalakra, ahová lehet, csodákra képes. Ha a PIC táplábainál nincsenek, mindegyik Vdd-nél, akkor azokkal kezd. aztán a táp belépő pontokhoz és ha van hosszabb tápvezeték szakasz, akkor oda is, ahová lehet...