Kollegák!

A probléma megoldódott, a két testet (ICD + céláramkör) egy 100uH-s induktivitással kötöttem össze a sima összekötés helyett. A fene tudja miért, megérzés volt

Lehet hogy valami zaj resetelte a PIC-edet. Nekem is voltak /vannak hasonló gondjaim elemes és földelt ügyben.

Üdv,

Leírnám problémám a microchipes CDC fw-el, hátha valaki más is találkozott már vele.. Szóval, nagyon kicsi módosítás csináltam a fw-el, annyi volt, hogy kiszedtem mindent, amit nem használtam (pl usart ), a led -blinking fv-bennt hagytam, jelzi az usb státuszát. Na meg beleírtam, glory cikkje alapján hogy ha 1-es karakter jön akkor led be, ha 2-es led ki. Ez egész jól megy is egy darabig, de egy idő után (pár órás üzem)eltűnik a sorosport a gépről és a ledek begyorsulnak (USB status ledek).
Nem találkozott még senki sem ezzel a problémával?
üdv,
mogus

senkinek nincs ötlete?

Csinálj rá egy interruptos timeres villogtatót. Hogy egyáltalán megy e a proci.

A kontroller tuti megy, mert az USB status ledek villognak. Azok meg "egy task" -ként futnak. Tehát el sem akad sehol... egyébként ezek a ledek gyorsabban villognak, amit nem értek, hogy lehet...
üdv,
mogus

Lehet hogy az van hogy valami más task kihal, vagy nem fut le, és ezért az usb státusz ledeket villogtató rutin-ra többször és hamarabb kerül sor. Ettől gyorsabban villoghat.

Arra nincs tippem hogy melyik task és miért, én sosem járattam órákig. De valószínűleg összefügg azzal hogy nincs attached állapotban az eszköz szóval valami lehet hogy arrafelé lesz a hiba.

A hétvégén és is összedobtam egy 18F4550 demo kacsolás, Lucifer javaslatára, lásd az inditott topic. A bootloaderes megoldással meggyult a bajom. A user mode és bootload mode átkapcsláskor
sokszor elérhetetlenné válik az PIC, látszik az USB hiba és az üzemmódváltás sem megy. Pl.
- PC bebootol,
- bootloder megy
- program betöltés
- user módba átkapcsolás -> ritkán sikerül

De a betöltött program egy PC boot után megy rendesen, USB rendben.
Vissza akarok kapcsolni bootload módba - nem megy.
PC újraindítás segít.
Device manageres eltávolítás, más portba dugás sem segít.
Ötlet? (Compaq nw8440 laptop Win2000 oprendszer)

Melyik kapcsolást csináltad? Szerintem hardver hiba.

Ezt a kapcsolást csináltam meg.
Ugy érted, hardver hiba PC oldalon? Ugyanis egy másik PC-n, linux alatt az üzemmódváltás megy. Persze ott a bootloader módnak nincs érteleme. Vagy esetleg van linuxra is bootloader program?

Szia!

Még nem jutottam el odáig, hogy az USB-vel foglalkozni tudjak, de feltett szándékom.

Összeütöttem viszont egy olyan bootloadert, ami soros vonalról használható, és nem kell hozzá PC oldalon extra program. Ezt meg lehetne próbálni Linux alatt is, én azt gondolom, hogy gond nélkül kellene működnie.

Ha minden jól megy, ma fogok szerezni 18F2550-eket és megpróbálhatom majd a soros portos bootloadert átírni az USB-s CDC-n keresztüli működésre. Ha ez sikerül, akkor biztosan lesz Linux alá is bootloader.

Bővebben: Link

Korrekció: ezt ezt csináltam meg, továbbá van egy LED a 29-es lábon,
ami a bootloader állapotot jelzi.
Szilva, szivesen beállok linux bootloader teszternek

Találtam ezt az USB bootloadert linuxhoz. Lehet, hogy át kellene tolni a talicskát linuxos ügyekben linuxos topikhoz.

Ez pedig jó kapcsolás nekem működik. Próbáld újrarakni a CDC drivert mondjuk. Azt nem értem hogy Linux alá honnan szereztél CDC drivert. Vagy nem is CDC firmware-t használsz? Vagy esetleg nem raktad fel a drivert?

Egyébként a Microchip bootloaderje nem CDC hanem HID class-t használ. Szóval ezen az úton kéne elindulni inkább linux ügyben. Gyanítom hogy a Linux is minden gond nélkül kezeli a HID class-t, nem kell hozzá semmi driver ott se.

Szia, nem hiszem, hogy a kapcsolással gond lenne, inkább Windows/PC probléma lehet.
Linux alatt pedig egyszerű, mint egy faék.
Be kell tölteni a kész cdc-acm modult, megjelenik (lehet, hogy más linuxnál meg kell csinálni) egy
/dev/ttyACM0 device, ami úgy használható, mint egy soros port. Esetleg stty -jal a sebességet, stb be kell/lehet állítani.

Lehet, h láma kérdés, de honnan lehet szerezni ilyen cdc-acm modult? (Debian Etch-em van)

Nem tudom mikori OS a Debian Etch, de valószínű hogy már a kernelben benne van a modul.

Add ki a

parancsot, és valszínű, örülni fogsz.
(Meglepődtem, hogy már egész régi kernelekben benne van az cdc-acm.)

Azt hiszem, a másik topicba linkelt be valaki egy képet egy USB-s adatgyűjtőről, itt a teljes cikk:

Bővebben: Link

Ma megvettem a 18F2550-eket, és a próbapanelemet kibővítettem az USB-hez szükséges dolgokkal, így már van rajta RS232, USB és PICkit2 ICSP csatlakozó is. A fenti linken szereplő cucc hex-ét beprogramoztam a PIC-be (config-ot is gyártani kellett hozzá), a microchipes CDC driverrel kiválóan működik. Eddig bíztató a dolog

Szó nélkül betöltötte, sajna most nincs időm vele foglalkozni jobban, de ha már szóba került meg kellett kérdeznem.
Lucifer: én se tom, mikori, ez a legujabb stabil Debian
Köszi mindkettőtöknek!

Adott egy 18F4550 a minimális usb-s áramkörben (annyi módosítással, h a portjait kivezettem, jelenleg 7szegmenses kijelző, i2c busz van rajta), cdc firmware van a picben.
A problémám az, hogy nem mindig ismeri fel az xp. Időnként kiírja, h nem lehet felismerni/elindítani, eszközkezelőben sárga felkiáltójel van az ikonján.
Főleg cdc üzemmódban csinálja, boot módban még nem volt rá példa. Néhány pic reset, esetleg usb kábelről lehúz, visszadug meg szokta oldani.
Erre tud valaki megoldást?
Előre is köszönöm a segítséget!

Rajta van a 470nF?

A 18as láb és a föld között van.

Az USBtasks-ot elég sűrűn hívod meg? Úgy értem, a fő ciklusban, ami meghívja ezt is, nincs véletlenül nagy "időhúzás"?

Van benne néhány dolog: hőmérséklet-, időlekérdezés, kijelzőre írás, stb.
Az USBTasks() a fő ciklus legelején van.
Ha gond, hogy lassú a fő ciklus, akkor hova rakjam a kódot? Majd átnézem, ami olyan azt átrakom timerbe.

Hát, igen, lehet gond.

Én az elmúlt két hétben írtam egy USB-s kezdeményt a nulláról, asm-ben. Egyelőre egy HID device-t (jelenleg egy joypad-et) valósít meg, de végig kellett szenvedni a kérdés-felelek mókát, amit USB enumeration-nak hívnak.

A Microchip nagyon "nagyvonalúan" dokumentál néhány dolgot az USB kezeléssel kapcsolatosan, így a példák forrásának és az eredeti USB doksik bújásának eredményeképpen jutottam el idáig. A fejlesztés során szükség volt debugra, amit egy RS232 kimenettel valósítottam meg, erre írtam ki információkat. Tapasztaltam, hogy ha túl sok időhúzás volt a kiírások miatt, akkor valószínűleg kifutok az időből, mert nem várt USB reset-ek jöttek, vagy esetleg nem sikerült az enumeráció. Ilyenkor ha csökkentettem az elküldött debug infók mennyiségét, akkor helyreállt a rend. Most még én is pollozós főciklusban dolgozom fel az USB-s tennivalókat, és az RS232 küldés sem bufferes, ezért megakasztja a procit.

Úgy gondolom, hogy a Microchip USB framework-jét is meg lehet csinálni interruptosra, legalábbis a kommentek erre utalnak benne. Akkor nem az USBtasks hívgálná a kiszolgáló rutinokat, hanem az USB interrupt a megfelelő interrupt flagek esetén. Ekkor nem lenne kritikus, hogy a főprogramban milyen lassú műveleteket végzel. Valószínúleg egyébként nem kis munka ez az interruptos megvalósítás.

Ha van módod az időhúzást lecsökkenteni, vagy ideiglenesen kiiktatni ezeket a teendőket a progidból, akkor esetleg tehetnél egy próbát, hogy valóban ez-e a gond Nálad is. Ha igen, és időhúzások nélkül nem téveszt, akkor el kellene gondolkodni rajta, hogy hogyan tovább.

szilva!
Nincs kedved megosztani azt a kis USB-s "kezdeményt" ? Nagyon hálás lennék! Főleg, hogy asm-ban van!

Beraktam az USBTasks()-t még a főciklus elé, közvetlenült az InitializeSystem() hívás után, plusz még néhány helyre a fő ciklusban.
A probléma nem szűnt meg, bár, mintha kevesebb reset kéne neki.
Sztem az i2c-s kommunikáció lassítja a progit, szoftvereset használok.
A progi keveset használja az usbt, ez egy óra, a pcről kapja az idő, dátum és ébresztés beállításokat.

A fő ciklus előtt van néhány i2c-s olvasás/írás, azok közé is beraktam az USBTasks() hívást.
Most felismerte, nyomtam néhány (<10) resetet, egyszer se volt gond.
Mivel a probléma csak kapcsolódáskor jelentkezett, a fő ciklusból kiszedjem a plusz hívásokat? Vagy egyelőre még várjak vele? Végülis elférnek, a kijelzést nem lassította be.>

Korán örültem: 10ből 1-szer előfordult a probléma. Tekintettel arra, h csak beállításkor lesz gépre kötve, sztem elfogadható.
Közben gondolkozok néhány kódrészlet timerbe rakásáról. De nem szeretnék átesni a ló túloldalára, ha sok kód van a megszakításkezelőben, akkor meg ott lesznek fennakadások. Pl nem fut le mielőtt jön 1 újabb megszakítás.