[Megoldva] Saját készítésű USB device-nak milyen vid:pid?

Elektronika, Elektromos eszközök

Mivel többen írtak hőmérséklet mérő modul használatáról, illesztéséről R-Pi-hez, gondoltam egyet, s összeraktam egy PIC16F1455-tel és egy MCP9808-cal egy hőmérőt. Ezzel 0.0625 °C felbontással lehet hőmérsékletet mérni, értelemszerűen kerekíteni fogok 0.1 °C-ra. Mivel van dilatációs elven működő hőmérőm, amelyet elég könnyű leolvasni, a project elsődleges célja kevésbé a hőmérséklet mérése - bár időfüggvény regisztrálására jó lesz -, sokkal inkább az USB-hez szerettem volna közelebb kerülni. Hogyan néz ki egy USB stack egy mikrokontrolleren, mekkora sz.pás összekalapálni - eddig: nagy :) -, mik a buktatói annak, amikor egy meglévő C kódhoz saját relokálható assembly kódot írok, s így tovább.

Aztán felvetődött: milyen vendor ID:product ID legyen az eszköznek adva? Van erre valami „szabad” tartomány amatőr, home célokra, mint a frekvenciák esetében, vagy adjak random vendor ID-t? Aztán, ha ütközik valamelyik jelenlegi vagy jövőbeli gyártóéval, akkor bocs?

Azt már látom, hogy az udev.rules-t is módosítanom kell, hogy ne csak root joggal tudjam elérni az eszközt.

Megoldás

( cadmagician | 2017. 01. 15., v – 15:47 )

Van meg pic? Dobbenet
------------------------
Jézus reset téged

Igen, es mennyenek a p....ba; atmelek is, es foleg microchipek, mert volt pofajuk megvenni oket.

+++

8 biten maradok atmeles, de 32 biten most probalok valtani stm32-re; 6 E Ft hozza a programozo. Amiota megvette a microcsip az atmelt, az atmel ice ara felmet 15-rol ~40-re, es gondolom, hogy hatar majd a csillagos es, meg jon az elsorvasztas.

Nem tudom pl., hogy mikor lesz 8-as verzio atmel sudiobol, de gondolom, hogy soha.

Vannak meg itt a listan, akik nem orultek ennek a felvasarlasnak, ill. kivancsi lennek, hogy ti hogyan latjatok az atmeles fejlesztesek jovojet.

( hzsolt94 v | 2017. 01. 15., v – 16:05 )

Az USB IF, aki ezeket az ID-ket hivatalosan kezeli, rendkívül ellenségesen áll a témához, tőlük hivatalos ID-t többezer dollár kifizetése nélkül nem fogsz kapni.

Nyílt forrású projekthez kérhetsz ID-t a pid.codes projekttől, ezeket az USB-IF is kénytelen hivatalosnak elismerni, így ha később hivatalos USB logót szeretnél, tagdíj megfizetése után kaphatsz rá azt is.
Zárt forrású projekthez az mcselec.com árul USB ID-kat, ezeket viszont az USB IF hivatalosan "betiltotta" úgyhogy sosem fogsz rá plecsnit kapni. Ennek ellenére a vásárolt PID:VID-ek egyediek, tehát praktikusan sosem lesz vele problémád.

Ezen kívül ha driver-szinten kompatibilis vagy valami elterjedttel (pl. libusb), akkor használhatsz "generikus" VID:PID párost, ezekből van jópár szabadon használható, pl. az Objective Development Software GmbH is.

Nem terméket csinálok, egyetlen darab. Tudom, hogy így a kérdésem is szinte felesleges volt, csak arra gondoltam, ha van valami szabadon használható tartomány, akkor elegánsabb lenne ennek használata, mint beletenyerelni valamelyik gyártó valamelyik termékébe.

Amúgy szánalmas, hogy itt is megöli az üzleti érdek a szabadságot.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Gondolom akkor úgysem akarsz saját kernel-szintű drivert írni, úgyhogy általános libusb-s VID:PID-el szerintem készítheted, ha elegáns akarsz lenni. Úgy rémlik egyébként vagy az Arduinonak vagy az Atmelnek van pár darab "privát prototípus" célokra fenntartott, szabadon használható PID száma, de ezeket nem találtam most meg sajnos.

Persze, libusb van a host oldalon. Kernel hekkeléshez nem értek, de ha értenék, akkor sem lenne hangulatom minden új kernel release-hez cca. 2 hetente modult fordítani. Amúgy akkor vált komolyra a kérdés, amikor az udev.rules.d-be akartam egy file-t írni, hogy legyen 0666 jog rá, mert ugye kell az azonosításhoz a vid:pid.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem röhög! :D Jártál te az utóbbi időben a kernel.org-on?

linux-4.9.1.tar.xz      06-Jan-2017 10:23   89M  
linux-4.9.2.tar.xz      09-Jan-2017 07:50   89M  
linux-4.9.3.tar.xz      12-Jan-2017 18:26   89M  
linux-4.9.4.tar.xz      15-Jan-2017 12:54   89M  

Ezek 3 naponta(!) jöttek ki, azzal a 2 héttel szokatlanul naiv álláspontot képviseltem. Fedorához egyébként le szokták fordítani a mindenkori legfrissebb kiadást. A 4.9.4-es épp most fordul a build szerveren.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Olvastad a szálat is? Az lett feszegetve, hogy amennyiben az USB kezeléshez saját drivert írnék. De egyrészt nem írok, mert nem értek hozzá, másrészt volt ez az érvem. Tehát nem arról van szó, hogy kínlódás a Linuxszal. Ha bármihez saját driver-t írnál, új release esetén újra kellene fordítanod jó eséllyel.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

azert ez mar nem urtudomany, ott a dkms vagymi ubuntun (talan redhaton is van), az ujraforgatja neked a modulod ha uj kernelt raksz fel.
az viszont macera, hogyha a linux devek egyszercsak szetb*szak a hasznalt fuggvenyek parameterezeset vagy a strukturakat, es ezt neked kovetni kell mikozben maradj kompatibilis az elozovel is...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( Nyosigomboc v | 2017. 01. 15., v – 17:56 )

Legjobban azzal jarsz, ha az OpenMoko tartomanyabol valasztasz egyet. Esetleg a VUSB-tol is lehet szerezni szampart, es nem muszaj a virtualis szarukkal implementalni.

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

( joco01 v | 2017. 01. 15., v – 20:14 )

Félig off. A sok millió fajta pendrive-nak mind külön VID:PID-je van? Mivel eltérő gyártók vannak, gondolom nem. De akkor honnan tudja minden számítógép, hogy milyen driver kell hozzá?

--

Igazából nem a pendrive, hanem a vezérlő chip számít, ami az USB-n ül. Elvileg mindegyik chipnek külön VID:PID-je van, de persze ha lekoppintanak egy chipet akkor simán lehet hogy lemásolják a VID:PID-et is. (Lásd az FTDI chip botrányt.)

Viszont hogy bonyolultabb legyen az élet, messze nem csak a VID:PID határozza meg hogy milyen drivert tölt be egy USB eszköz, hanem pl. a HID class alapján is beránthat egy megfelelőt az OS.

Az FTDI botrányban az okozta a legnagyobb problémát, hogy túl jól másoltak, de nem tökéletesen. :-)

(Az FTDI drivere meg tudta állapítani valami trükkel, hogy fake chipről van szó, és egyszerűen aktivált egy feature-t, amit amúgy az eredeti eszköz is tud, és ezt a feature-t szépen le is másolta a kínai gyártó... nem a fake IC volt működésben problémás, hanem az FTDI "gurult be" rájuk...)

Egyébként éppen ez a funkció teszi lehetővé, hogy az FTDI eszköznek többek között egyedi VID / PID-et adhass a saját azonosítójuk helyett.

( answ | 2017. 01. 15., v – 20:36 )

Vegyel egy CH340-et es sorosan kuldd az adatokat! Szinte mindenki ezt csinalja, senki nem akar driverekkel szorakozni..

A Windows (XP, 7) nem ismeri a Prolific PL2303-at se, ahhoz is drivert kell telepíteni. Újabb Windows-okon nem próbáltam.
Linux alatt a hamis FT232-vel sincs baj, gondok akkor lehetnek, ha Windows-on akarja az ember használni. Amúgy az FTDI visszavonta már azt a drivert, amelyik kinyírta a hamis chip-eket, most már csak a felhasználó által módosítható terület elérését tiltja bennük, ha jól tudom.

Igen... PL2303 már sokkal elterjedtebb, a CH340-nek is kell még egy kis idő. :)

Linux alatt a "brickesített" FTDI-k kezelését is "megoldották", meg persze vissza lehet állítani az eredeti állapotot (nem kinyírta a fake-eket sem az FTDI, csak "elállította").

Egyébként az újabb fake chipeket már a "kinyírós" FTDI driver sem "ismerte fel"... vagyis a Kínaiak is rájöttek, miként azonosította az FTDI drivere a fake IC-ket, és elkezdtek olyat gyártani, ami nem bukik le...

Te lüke, nem a probléma megkerülése a célom, hanem az, hogy tudjak USB-t közvetlenül mikrokontrollerrel kezelni! :) Akkor azt is mondhattad volna, vegyek a kínai boltban pár száz forintért egy hőmérőt, a mérési eredményeket pedig mceditben csépeljem be, aztán meg is vagyunk. Viszont akkor buta maradok. Ilyen folyadékszálas hőmérő leolvasása már most is megy. ;)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ertem, csak en megszoktam hogy nem szivatom magamat (igy is eleg keves az idom). Arduino, NodeMCU, RFID es barcode olvasok is ezt csinaljak. Olcsobb es gyorsabb a fejlesztes, de teny hogy nincs benne kihivas annyi.

Szerk:
En nehany eve kutyaolnak figyeltem a homersekletet egy telken. Openwrt-s router, USB eloszto, mobil stick, 1wire-soros atalakito es egy dallas semi homerovel. Olcsobb es gyorsabb volt mint mikrokontrollerrel szorakozni.

Ugyanigy froccsontogep hutesenek szabalyzasat es loggolasat, szinten 1wire eszkozzel, 1wire-soros atalakitoval, rele kartyaval es Linux segitsegevel oldottam meg. Mindketto altalanos soros eszkozkent latszott.

( apal v | 2017. 01. 15., v – 21:02 )

Par gondolat:
* AT90USB162 + LUFA. Ezzel mass storage-t csinaltam mar (2 megasat, de sokszor ujrairhatot), teljesen jo. Vagyis valamit valamiert: kenyelmesen lehet a lenyegre fokuszalni de az USB-specifikus reszleteket elegge elrejti es nehez kivinni a forrast standalone (lufa-fuggetlen modon). A LUFA-ban van pelda virtualis soros portra is (./Demos/Device/ClassDriver/VirtualSerial), vsz az sem nehezebb.
* A VID-et meghagytam (0x03EB), a PID az kvazi-random (0xCB01), de valahol olvastam hogy lehet igy csinalni. Pl az FTDI is megengedi ezt valamilyen szinten. A lenyeg hogy a host felismerje az eszkozt (pl mass storage class).
* Par honapja egy amator gyari mozgato elektronikat kellett lecserelnunk sajatra. A gyariban integralt USB device-kepes MCU volt (C8051F320), ez kb a AT90USB162-nak megfelelo tudasu lehet, csak mas architektura. Viszont a fejlesztes meggyorsitasa miatt (volt egy kis nyomas...) megsem AT90USB162-et tettunk bele hanem egy mezei ATmega328-ast + egy FT232RL-t... nem bantam meg. Persze ha tobb rutin lett volna AT90USB* MCU-kkal, akkor ugy csinaltam volna.
* Illeltve meg egy otlet: az 1/16-os homerot ne kerektsd 0.1-re, mert az adatsoraid felplottolva nagyon kretenul fognak kinezni ;) menjen csak ki full 4bites fixpontos felbontasban, a frontend meg 2 tizedesjegyre mentse el akarhova. Ugy jo lesz.

Meggyőztél. Az MCU-ban megcsinálom a binárisból decimális konverziót, de kerekítés nélkül. Ábrázoláshoz használom ezeket az értékeket, kijelzéshez a PC-n kerekítek. De az is lehet, hogy a kerekített értékeket is átküldöm, s csak ki kell választani igény szerint, amelyik kell majd.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ennek számtalan oka van. Igaz, hogy a PC nagyságrendekkel nagyobb teljesítményű eszköz, mint az mcu, viszont minek terheljek rá akár 0.01 %-nyi melót, ha van egy mikrokontrollerem, ami az idő nagy részében nagyon unatkozik, az USB miatt a core elég gyorsan jár - 48 MHz, 12 mips -, és assembly-ben szeretek programozni mcu-ra.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mondok egy sokkal jobb szempontot. Pl. egy hőmérőhöz készül driver/megjelenítés, akkor érdemes egységes interfészt használni, amin mindig a valódi érték közlekedik, mondjuk 0,1 fok felbontással, kerekítve, korrigálva stb. Ha a hőmérőt más típusra cseréled, akkor sem kell a szoftveres oldalt módosítanod.

Ellenben ha valamin változtatni akarsz, vagy probléma van, akkor a szoftveres oldalon egy egyszerű, netről letölthető frissítéssel megteheted. A mikrokontroller kódját frissíteni, ha a user képes egyáltalán akkor is szívás. (Jó, ferdítek, egy darabnál ez nyilván nem szempont.)
Az egységes interfész jogos, de a decimális adatátvitelt előnyét akkor sem látom. Se nem humán, se nem klasszikusan szöveges interfészről van szó, hogy indokolt lenne az ASCII/BCD,

No-no fiam, kőből talán nem lehet hidat építeni? :D Akarom mondani, egy soros porton nem lehet éppen úgy ASCII-ben áttolni a mérési eredményeket? Amúgy az miért olyan nagyon jó, ha beesik nyersen, binárisan 12 bit kettes komplemens ábrázolású fixpontos adat?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Sorosporton pont én is ASCII-ben küldeném át, mert ki tudja milyen rétegek vannak közte, és korrektül átviszik-e a bináris adatot. (Elvileg persze mennie kellene binárisan, gyakorlatilag meg sokszor találkoztam vele hogy valami belerondít, pl. automatikus sorvég konverziót csinál a bináris adatomban.)

A bináris adatban semmi jó nincs, csak személyes ellenérzésem van a BCD adatokkal, mert általában pontatlanok. Az egyik látványos eredménye ennek, amit apal említett is, hogy ronda lesz ha 0.1-es kerekítéssel felrajzolod, mert 1-1 értéked nem azonos méretű mérési tartományt fog takarni valójában. 1/16-os skálához minimum 2. tizedesjegyre szükséged van, ha nem akarsz az adatot veszíteni, de igazából 3-at illene használod, mert a legalacsonyabb jegyen nem szokás értékes adatot vinni.

(Egyszer dolgoztam egy kísérleti kutató-mérő berendezésen, ahol a hibahatárokat kellett leszorítani. Fontos volt hogy a vezérlés ne hozzon be semmilyen plusz hibát. Minden értékkel a saját skáláját és a lehetséges hibáját is együtt kezeltük. Ehhez viszonyítva ránézésre megborzongok amikor egy 1/16-os bontású adatot 1/10-re látok kerekítve.)

Az 1/16 jogos. Azt fogom csinálni, hogy átviszem 4 tizedes pontossággal, így nem lesz adatvesztés, csak számrendszer konverzió. Ezen felül átviszem 1/10-re kerekítve is, hogy ki lehessen íratni a desktopon valahova a system tray közelébe.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Inkább átviszed 2x, mint hogy a géped kerekítsen egyet? Fura szerzet vagy te :-)

Grafikont is fog tudni csinálni a hőmérőd, ami letölthető róla BMP-ben? De szigorúan CSV formátumban, az RGB értékeket 0-255 közötti decimális számként küldje fel. Mondjuk, akkor már tudjon CMYK-t is :-P

(Jójó, abbahagytam, elnézést. Sok sikert a projekthez!)

Tenyleg minden attol fugg hogy mi a feladat. Hasonlo jellegu de komplexebb vezerlesi problemaknal (pl leptetomotor-vezerles, gyoritassal-lassitassal, jerk-kel, joggingal, stb) ugy csinaltam meg ezt anno hogy a protokoll nem csak az adott allapotot kuldi el, hanem a "mertekegyseget" is. Es akkor elegge hw-fuggetlen, hordozhato, stb kommunikaciot kapunk, cserebe nincs kerekitesi pontatlansag. Ebben az esetben ez ugy nez(ne) ki hogy lejon a nyers (12 bites, 4 bitnyi fixpontos) meresi adat, meg az hogy 1/16 valamilyen formaban (pl 1 ill 16).

De ha nalad fontos hogy ASCII-ban is jol menjen, akkor persze, ez is jo megoldas.

Viszont: binaris protokoll egyik elonye hogy tetszoleges checksum-ot, error correction-t, stb be tudsz epiteni pluszban. Ha RSxxx-en megy at valami, akkor ennek is nagy szerepe lehet egy zajosabb elektromos kornyezetben (amikor siman elveszhet 1-1 byte, mert miert ne). Egy CAN vagy ethernet nyilvan megoldja ezeket alapbol de ha az nincs es/vagy nem megoldhato, akkor RSxxx-en is lehet okos dolgokat csinalni.

Na ki ne találd már nekem, hogy ASCII-re nem lehet csinálni ellenőrző összeget! :DD

Hogy most mi a feladat? Amit kitalálok. Az egész úgy kezdődött, hogy hülye vagyok az USB-hez, s elszégyelltem magam. Vettem a boltban 10 dkg párizsi mellé egy PIC16F1455-öt, meg egy MCP9808-at. Meg még néhány alkatrészt. Terveztem hardware-t, összeraktam, egy PIC-re C-ben írt USB stack-et és saját assembly programomat próbálom összeházasítani. Az elején nagyon utálták egymást, de így a beszoktatási idő elteltével egész jól kijönnek már egymással. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egy CAN vagy ethernet nyilvan megoldja ezeket alapbol

Az ethernet (ez még csak layer 2) ezt nyilván nem oldja meg. Ha egy ethernet keret megsérül, akkor az elveszett. A fölötte futó protokoll már képes lehet arra, hogy hiba esetén ismételjen, pl. TCP/IP esetén a TCP (layer 3) ezt megoldja, mert az várja a nyugtát, de az UDP (szintén layer 3) nem így működik, az sem tud önmagában hibát javítani. A TFTP UDP-t használ, és mégis képes arra, hogy hibamentes átvitelt hajtson végre (UDP fölött), mert az esetleges hibát felismeri és megismétli a szükséges csomagokat.

A firmware frissítése nem szívás, hanem lehetetlen, mert ki van öntve. Talán ezért készül assemblerben - nincs elvarratlan szál.

Az adat értékkészlettől függően 16, 24 vagy 32 bites unsigned/signed int. Természetesen kettes komplemens. Mivel az eredmény int, akkor pl. a 12V értéke 12000, a maximum 20V, azaz 4e20. Ebből látszik, hogy a 16 bit mellett marad egy bit az előjelnek is. A megjelenítés vagy használja a mV értéket, vagy elosztja ezerrel. A forrás a pic, ahol nem igazán keletkezik sem méréskor, sem számításkor float.
Az előbbi egy nagyobb sebességgel mérő műszer interfésze. De egy munin alá illesztett hőmérő szigorúan ascii, annyi jegyekt ad amennyi a felbontás. Tehát a -22,3 fok -> "-223". Ezt mindenki így csinálja.

Ha szóba került az AVR :)

Van vusb nevű érdekes lib (nincs 2kbyte), amely SW-ből oldja meg az USB-t (csak alacsony sebességű USB 1.1), vagyis pl. akármilyen atmega használható USB eszközként. Az oldalukon jópár minta projekt is van, kapcsolási rajzokkal, forráskóddal:

https://www.obdev.at/products/vusb/index.html

( oattila | 2017. 01. 15., v – 21:28 )

A conrad-nál lehet kapni VM110 vagy K8055 néven egy PIC-el szerelt USB illesztésű IO kártyát.

Ehhez készült egy linux-os driver (talán a hivatalos csak windows-os) is. Abból a szempontból érdekes lehet, hogy kezeli az USB-t linux oldalán:

http://libk8055.sourceforge.net/

Ezt használom. Most éppen azon vagyok, hogy az isr rutint assembly-ben írom, lévén, mást is tennék oda, például 10 ms-onként timer IT-t, így az most a kérdés, hogyan kell hívnom assembly-ből C-ben írt függvényt. Paramétert szerencsére nem kell átadni. Itt a fordítóval, linkerrel való küzdelem sokszor időt rablóbb, mint a szép, könnyű és légies assembly programozás. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( bucko | 2017. 01. 15., v – 23:39 )

Házi használatra a Microchip teszt vid:pid-ek teljesen jók.
Kis sorozat esetén a Microchiptől lehet ingyen igényelni vid:pid-et, de érdemes elolvasni a feltételeket.
Ötletszerűen nem érdemes felvenni, mert pl. egy régi eszközünk Windows alatt csak frissítés után működött, mert nem volt az adatbázisban.

Most eszem valamit, amúgy bosszant a fordító. Az isr rutint assembly-ben írtam, de a C-ben írt USB isr függvény az assembly betétemből lenne hívandó. Mondom is az assembly modulnak:

extern usb_service

...

movlp HIGH usb_service
call usb_service

Aztán az usb.h-ban deklarálva van, az usb.c-ben pedig implementálva ez a függvény, de nem találja a linker. Hibát ugyan nem ad, lefordul, de sokkal kisebb az eredmény, mint aminek lennie kellene. Vissza disassembláltam, s ez lett belőle:

movlp 0
call 0

Akkor is megvacsorázom! :)

Ja, igen, próbáltam alulvonallal kezdeni, az sem jött be: _usb_service

C-ben egyébként:

void usb_service(void)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

:)
Most látszik milyen öreg róka vagyok! És bocsánat az öndícséretért.
Szóval 20 év c rendszerprogramozói tapasztalat után eldöntöttem, hogy ezek a c fordítók csak annak jók, akik képtelenek assemblerben programozni. Most már ott tartok, hogy az assembler program is alig fér el, pedig - legalábbis ebben a dologban nem vagyok szószátyár. Ilyenkor meg a legfontosabb, - bár a nagy-nagy guruk által primitívnek tűnhet, hogy relokálható assemblert sem írok. Maximum Intel Isis-II rendszeren, mert az még tudott relokálni. ;)

Bár nem ezt kérdezted, de leírom hogyan tudsz eredményt elérni. Ide jönne: már ha tudsz assemblerben programozni. Már pedig tudsz, így ez a járható út.

A Mikroelektronika usb stack szinte fogyasztható asm (c->asm) forrása elérhető a pic18f2550-re. Pl. itt a siglabfw.asm. Ezt (nem pont ezt, csak hasonlót) dolgoztam át több lépesben:
- Fordítható forrás előállítása.
- Konstansok és definíciók.
- "Relokálható" forrás előállítása. Ez csak annyit jelent, hogy a hivatkozásokat is meghatároztam. Utána tetszőleges helyre elhelyezhető a kódrészlet.
- A c hívási konvenciónak megfelelő szoftveres stack kezelés eltávolítása.
- A kettős és hármas bufferelés eltávolítása, mivel nem operációs rendszerből hívogatom.
- Index regiszterek fixálása - így nem kell mentegetni feleslegesen.
- A bankselect kiirtása. (Egy programban csak egy bankot használok, mert abban+access mindig elférnek a változók. A többi memóríát, vagy ha nem férnek el a változók indexregiszterrel használom.)

Visszaellenőrzéshez ezt használtam. Majdnem teljesen megegyezik a Mikroelektronika kódjával.

Ezek után már csak át kell írnod 16-osra.

Ha meg igazán profi hőmérő szeretnél, akkor nézd meg a BME280-at! Ugyan beforrasztani nem tudod, de ebay-n megkapod beforrasztva annyiért, amibe a csip kerülne. Ráadásul olyanja is van, hogyaszongya: Gaming Mode. Ezzel a szörnyeket lehet jól levadászni! ;) Először én is arra gondoltam, hogy gyenge volt a pálinka...

+1 a BME280-ra.

Ezzel hőmérséklet mellett légnyomást és páratartalmat is lehet mérni, elég aranyos kis szenzor... de tényleg kicsi.
Van egy BMP280-as típus is, az páratartalmat nem mér, a többit igen [E = environment, P = pressure].
Ennek megfelelően a BME280-at valamivel drágábban adják.

A korábbi BMP180 / BMP080-as szenzorokat is szerettem tőlük.

Ne is fájdítsd a szívem, az egészet színtiszta assembly-ben írnám, de ez az izé C-ben van, az USB szabvány meg több, mint 600 oldal, s nem az anyanyelvemen. Szóval gondoltam egy merészet, mely szerint a C-ben írt USB stack-et házasítom a saját assembly kódommal. C-ből assembly-t már tudok hívni, most a másik irány kellene, de nagyon: assembly-ből kellene C-ben írott függvényt hívni, de nem hagyja a mocsok.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hááát, azért az USB szabványt nem kéne rögvest megvalósítani, mert úgy se fér bele 8k-ba. ;)
Legfeljebb egy 1db endpointtal rendelkező primitív hid driver c forrását átírni assemblerbe. Normális c fordítónak van assembler kimenete. A többi meg legfeljebb vi editor, esetleg awk, no meg egy kis türelem. Ráadásul ott van a kezedben a c forrás, tehát nem úgy kell kitalálnod a konstansokat.

Azért nem ártana, ha elárulnád milyen fordítókkal küzdesz.

( uid_17784 | 2017. 01. 16., h – 12:09 )

Szerintem a legolcsobb es legjobb megoldas a kovetkezo:

1. lepes
aliexpressen rendelni CH340-es USB to TTL-serial atalakitot, es kesz az illesztese barmilyen mikrokontrolleres kutyunek.

2. lepes
Varni, amig a kinaitol ideer a cucc; megoldas lehet meg megvenni mashonnan dragabbert, de csereben itt van 1-2 nap alatt.

3. lepes
Feldugom a CH340-et a szamitogepre; ha ez az elso alkalom egy CH340-bol, akkor a Windows 10 szepen kimegy az internetre, es letolti a drajvert hozza; Linuxon gondolom hasonloan egyszeru a drajver beszerzese.

4. lepes
Nem foglalkozok semmilyen vendor/produc-ID akarmivel, stb.

5. lepes
Megirom a hoszton futo programot ami kommunkalni fog a kutyummel (COM-porton keresztul), amit a CH340-nel kapcsoltam ossze a szamotogeppel.

A kommunikacio ugy fog kezdodni, hogy a hoszton futo programom egyszeruen megkeresi a kutyut a COM-portokon. Ez igy egyszeru es maximalisan felhasznalobarat.

6. lepes
Orulok, hogy ennyire egyszeru az egesz, es nem kell szopnom mindefele vendor ID:product ID biszbaszokkal.

+++

Lehet, hogy hulyesegeket irogattam, de attol meg nekem igy mukodik.

Írtam, nem kész modulokból szeretnék legózni, hanem valamelyest szeretném megtanulni az USB kommunikáció mikrokontrollerre történő implementálását. Az USB stack kész program, de már addig eljutni sem triviális, hogy egyáltalán leforduljon. Aztán ezt szeretném összeházasítani a saját assembly kódommal.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyrészt az nem PIC, másrészt nekem ez a szakmám, nem a hardware tervezés, vagy a mikrokontrollerre írt assembly programozás a kihívás számomra, hanem az USB közelebbről, meg a fordító illetve a linker, ami vagy nem azt csinálja, amit mondok neki, vagy nem azt mondom neki, amit szeretnék, csak erről én nem tudok.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem PIC valoban, de nem mindegy az USB szempontjabol?

Ha pl. I2C-n vagy SPI-n keresztul kell valamit vezerelni, akkor nem mindegy, hogy PIC vagy AVR?
Gondolom ugyanigy mindegy az USB felulet szempontjabol is; ha megtanultad AVR-en, akkor nem lehet kihivas mas mcu-n megycsinalni.

+++

Amugy ez nalad hegymaszas jellegu? Megnezed, hogy feljutsz-e a tetejere? Szerintem ha egeszseges vagy, akkor csak akaras kerese, tehat nyugodj meg, megtudod csinalni. Akkor meg biztosan van jobb elfoglaltsag is a vilagon, ezert matradok en pl. az USB-TTL serialnal. (Tudom, hogy kepes vagyok megtanulni az USB-stack implementalasat, csak eppen nincs annyi idom az eletbol, hogy implementalgassam, mert majd 100 evesen azon fogok bosszankodni, hogy de nagy barom voltam, hogy ilyenre pazaroltam azt a keves idoment, ahelyett, hogy jobb elvezeteket nyujto dolgokat csinaltam volna. Szoval csak tanulgasd az USB-t, jo idopazarlast!

Ne légy negatív! Azért van abban valami jó, amikor megcsinál az ember egy ilyet. Nyáron nem csinálnám, de most semmi problémám ezzel. Amúgy fordítva ültem a pacira: az isr keretét C-ben írtam, onnan tudom hívni az USB stack service függvényét, meg a saját, assembly-ben implementált timer rutinomat. Kevésbé tetszik, mert az isr keretét is én szerettem volna írni, de workaroundnak szódával még elmegy. Sikerült lefordítani, viszont nem működik. Most van az az érzésem, hogy „de hát ez már egyszer működött!”. :)

Szerk. 1: Nagyszerű, amikor a fordító a globálisan meghirdetett függvényem címét tudja, mert a C kódból a hívás címét konkrétan 0x3e1b-re álmodja - azon lendüljünk hirtelen túl, hogy 0x1fff-ig tart a programtár -, majd maga a kód már nincs benne, a lista file-ban többet sehol sem szerepel a 0x3e1b cím, de a 0x1e1b sem. (C-ben extern-ként deklarálva.) Pedig az assembler optimalizációját is kikapcsoltam már. Nyilván fejreállt, az első időalap megszakítás alkalmával memória szemétre adódott a vezérlés, szóval nem jutott messzire. Milyen jó is, amikor nem az értelmes részével vív az ember, de meg vagyok verve egy compilerrel is. Ezért szeretek tisztán assembly-ben programozni, ott az van és úgy, amit mondok neki.

Szerk. 2: Kezdek rossz kedvű lenni. Van a psect direktívának egy limit=max_cím flag-je a dokumentáció szerint. Erre a fordító szintaktikai hibát mond. Próbáltam decimálisan is, hexadecimálisan is, argumentum nélkül is - bár úgy semmi értelme. Bezzeg a többi flag működik, épp az nem, amellyel jobb belátásra tudnám kényszeríteni a linkert. :(

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az. Értem én, hogy relokálni akar, de ne oda, ahol már nincs programtár. És nem felejtettem el beállítani az eszköz típusát, include-olni a megfelelő file-okat, amelyben az eszközspecifikus definíciók vannak. Továbbá olvasom a fordító doksiját, s mikor felragyog az arcom, hogy akkor limit=0x1fff kikényszeríti, hogy ne a senki földjére allokálja a dolgaimat, akkor benyögi, hogy nem ismeri ezt a flag-et. Mindezt úgy, hogy a programtár közel fele üres, lenne hova tennie azt a néhány tíz, legfeljebb néhány száz programszót.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Átnyergelek ide onnan, ahol xc8 volt.
Az assembler fordítót nem mondtad meg.
Az sem látszik, hogy egyébként relokálható ojjektumokat állítasz elő, vagy csak ebben az esetben.
Én is azt mondom, hogy ez nem hegymászás. A végén diadalt fogsz aratni és legyőzöd a c fordítót. ;)

Először azt gondoltam majd segítek, de már mindent leírtem feljebb. Még egy picit tudok segíteni: http://www.microchip.com/forums/m757890.aspx
Szóval nyerd ki a forrást és tedd magadévá!

Nyilván leküzdöm, nem az a fajta ember vagyok, aki az első fejvakarós kérdőjel-kérdőjel-kérdőjel után feladja. Csináltam timer IT rutinba állapotautomatát annak érdekében, hogy két LED-et 10 ms-os felbontással egymástól függetlenül tudjak villogtatni - ez alatt persze nem azt kell érteni, hogy egy periódus alatt egyszer on, egyszer off, hiszen épp ezért állapotautomata -, ez működik is, csak épp az egyik LED-em döglött. Amúgy a LED-eket elsősorban debug célokra tettem bele. Épp most cserélem ki a LED-et.

Momentán USB-n egy adatcsomagot elküld, majd azzal a lendülettel elhasal az egész. Szép lassan megkeresem, felszámolom a hibákat, de a legnagyobb szívás továbbra is az, hogy a fordító hajlamos valami egészen mást fordítani, mint ami le van írva. De ezen is kezdek urrá lenni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az usb szempontjából c-ben biztosan mindegy. A PIC azért nem igazán keverhető össze az AVR-rel. Ne is vitatkozzunk arról, hogy melyik a jobb. Van aki az egyiket használja és van a ki a másikat.

Azért hegy(nem)mászás közben gondold végig a következőket:
- Egy termékben 705Ft a hardver költsége. Vajon mennyi lenne még egy usb-ttl modul felhasználásával?
- Az usb hid driver implementálása 5 napont vett igénybe. (Igaz kicsit több, mert írtam még bele némi javítást és gyorsítást.) Most raktam bele az ötodik termékbe. Belefér-e a 100 évbe?
- Az előbbi driver assemblerben rendelkezésre áll. Bármilyen hiba/módosítás esetén ezt könnyebb átírni, vagy az esetleg hibás libet az ostobaságokat fordító c fordítóval? És egyáltalán ezzel a felállással ki mernél bocsátani egy terméket?
- Az atmega platformon a ch340 állítólag 2.000.000b/s sebességet is tud. (Persze a tesztprogram.) Az usb hid interrupt módban meg csak 500.000b/s. Vajon a soros portot töltögetve tudsz több adatot átvinni, vagy a 0 overhead-del rendelkező usb driverrel?
- Vajon mennyi időt spóroltam meg azzal, hogy a kezemben van a driver és nem futok bele performance problémákba?

Szóval tagadás, táplálkozás, kása. ;)

Ami neked időpazarlásnak tűnik az nem biztos, hogy másnak is az. Én munkaidőm jelentős részét most USB host-ok és device-ok implementálásval töltöm (mass storage, printer, CDC ACM, CDC ECM, stb.). Mielőtt ezt csináltam volna, hobbi szinten Atmel-en VUSB-vel és TI-os TUSB3410-el foglalkoztam. Ott tanultam meg az alapokat és örülök, hogy rászántam az időt, mert most tök jó helyen dolgozom és érdekesek a feladataim.

( locsemege v | 2017. 01. 16., h – 23:05 )

Olyannal életemben nem találkoztam még, hogy egy vadi új LED rossz legyen, de most ebbe is belefutottam. Hiába nézem a kódot, ha a LED rossz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Eddig beforrasztottam már több ezer :) LED-et, de ilyennel talán csak egy alkalommal találkoztam. Viszont ezek alapján már nem egyedi az eset! :-D Sőt: egyszer volt szerencsém egy adag "lábas" (nem SMD) LED-hez, amik "fordítva" voltak összerakva. Ha belenézel egy sima LED tokozásába, az látszik, hogy az egyik láb belül egy nagyobb felület lesz, ez tartja a félvezetőt. A másik láb vége kisebb, erről meg egy vezeték van átkötve a szilíciumra. A nagyobbik, tartó láb a negatív, a kisebbik, vezetékes meg a pozitív. Általában... :-D

(Subscribe a témára...)

Igen, magas fényű LED-ek között én is találtam már olyat, amelynek az anódja volt a chipet tartó fém tölcsér. Ez amúgy elég szörnyű, a hosszabb láb az anód, de miután már lecsípted, lesheted, hogy mi van. Régen mindig a katód volt a chipet hordó fém tölcsér.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Persze jöhetne az ilyenkor szokásos megjegyzés: el kell olvasni az adatlapot. :) Csak a mai LED-eken még a legritkább esetben sincs típusjelzés (ilyen talán az ősrégi, fémtokos LED-eken lehetett utoljára...), ha nem a szépen feliratozott zacskóból veszed ki, esélyed sincs a típus beazonosítására. :\

De az SMD ledek esetében is tudnak ám érdekes jelöléseket elkövetni a gyártók; nálam alap, hogy legalább az első példányt megmérem, mielőtt forrasztom.

Meg amikor bemész a kiskereskedésbe azzal, hogy kérsz 8 db 3 mm-es nem magasfényű zöld LED-et, akkor biztos elmesélik a típusjelzését is. Úgy szokott az lenni. :) Valahogy a LED-eknél ez nem túl kritikus a legtöbb felhasználásban.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezt a lányoknak is tudniuk kell. ;)

Amúgy most ott tartok, hogy írtam szép I2C kezelést megszakításban, buffer kezeléssel, állapotautomata, ack, nack, start, repeated start, stop, minden, ami kell, szépen, hogy alap szintről valami végtelenül kényelmes legyen kezelni. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez tényleg az alap szint. ;)
A todomány az AM2320-nál kezdődik, amely i2c, smbus, modbus, spi és sokan mások. Annak ellenére, hogy az i2c szinte bármit lehetővé tesz, itt már csak külön hw timerrel sikerült megoldanom a kickinaji i2c protokollt.
1. Wake-up esetén a stop condition előtt >800us késleltetés kell. (Indulás után rögtön szunyál.)
2. Két címzés között >1600us idő kell kivárni.
3. A cím(bájt) után >30us késleltetést kell beiktatni, mert különben téveszthet. És téveszt is!

Eddig a nyafi, most jön a pikantéria. Összegugliztam githubot, fórumokat miegymást és nem találtam megoldást. Így kénytelen voltam megírni.
Azaz jaj annak, aki letölt egy (valakinek állítólag) működő libet/forrást, majd más környezetben, vagy 10%-kal gyorsabb raspályon próbálja futtatni! A fenti lista szerint az 1. pontot nem tudja az i2c, a 2. késleltetést az user programban kell megvalósítani, míg a 3. szintén nem fér össze a protokollal. Bár ez a 3. lassú futás esetén megvalósulhat egészen addig, amíg gyorsabb gépre nem kerül. Aztán egyszer csak nem működik és jön a fórum. :X

Az I2C egy szabvány. Az az eszköz, amiről írsz, nem tudja ezt, csak valami arra emlékeztető dolgot. Ezt így kell felfogni. Amennyiben IT-ből állapotautomatával csinálod meg a protokollt, úgy a 2. pontot simán bele tudod írni, s a user program semmit sem tud az egészről. Mondom én, hogy jó dolog az állapotautomata, a brw utasítás, meg az egészet IT-ből leküzdeni.

Amúgy számtalanszor azt tapasztaltam, nem szabad lustának lenni. Most is megfordult bennem, hogy emiatt az alig néhány byte miatt nem fogom szépen megírni, hanem alap szinten - értsd: nem megszakításból - csinálok valami blokkolós rutint, amelyik piszkálja a hardware-t. Az ilyen viszont mindig megbosszulja idővel magát, mert előbb-utóbb jól jönne a szép, általános megoldás, bufferelt kezelés IT-ből. Az igénytelen kivitelezés hamar korlátokat jelent majd, s elég gyorsan gányolásra, egyedi probléma megkerülésére vezeti az ember kezét. Ezzel szemben szépen megcsinálni sem sokkal nagyobb munka, sőt, még élvezetesebb is, alap szintről meg gyönyörű a kezelése: beírod a bufferbe, hogy mit szeretnél, mondod neki, hogy „csináld”, az események maguktól történnek innentől, nem kell foglalkozni vele, a végén visszajön egy flag, hogy „elkészült”. Ha olvasás is volt benne, akkor ki lehet olvasni a buffert, aztán meg is vagyunk.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ilyen bufferelősdit pár éve írtam, amikor helyi és négy kliensen távoli i2c eszközöket kellett összekötni. Ekkor a bufferben egymás után jött az lcd kiírás, nyomógomb olvasás, ram írás/olvasás, távoli kliensnek kiadott parancs, vagy helycsere és a kliens írta a master ramjába a mért adatokat, stb. De a legjobb az i2c buszban, hogy a kliens "firmware upgrade" is egy paranccsá zsugorodott: A master leküldte a flash-elendő blokkot. Az utolsó bájt után a slave megakasztotta a buszt, majd a sikeresség függvényében (n)ack-ban adta vissza az eredményt.

Hőmérő esetén nagyon ritkán kell olvasgatni, ezért felesleges bármit bufferelni. Nem említettem, de éppen egy többféle konfigurációban kiépíthető ip hőmérőt fejlesztek. ;) Tehát én így csinálom:
1. Egy device list tartalmazza az összer lehetséges i2c eszközt. Alapesetben egy szerkezetben csak egy szenzor van. Viszont bármilyen konfigurációhoz egy firmware tartozik, vagy tesztelés közben akár több(féle) szenzort is lehet csatlakoztatni.
2. Induláskor autodetect-álom a csatlakoztatott eszköz(öke)t. Aki jelen van, annak saját adattárolója is keletkezik.
3. A főprogramban nincsen i2c kezelés, mert a méréseket a timer (helyett ccp1) interruptban tatózkodó állapotgép vezérli minden mérési periódusban.
4. Az i2c protokoll lépéseit a hp interruptban tartózkodó i2c állapotgép vezérli. Így minden lépés legfeljebb 1..3us időt vesz igénybe. Az egyes lépeseket (tokeneket) egy sorba fűzve kialakul az adott eszköz kezeléséhez szükséges parancs. Pl. WrCfg_MCP9801, RdHumTemp_AM2320 vagy Kick_MCP9801. Ezeket lehetne hívni akár a főprogramból is, ha nem időzítve és automatikusan menne a mérés. Az AM2320 extra késleltetéseit a következő lépést kiváltó esemény késleltetésével oldom meg. 

	btfss	PIR1, TMR1IF, a
	bra	NTIMER1
	bcf	PIR1, TMR1IF, a
	bcf	T1CON, TMR1ON, a
	bsf	PIR1, SSPIF, a
NTIMER1

5. A főprogram kezeli a max. 4 session-t. Ha valamelyik szenzort kérdezi egy kliens, akkor a kérdezett szenzorhoz rendelt adattárolóból kiolvasott eredmény kerül a válaszba.

Szóval ezt már írtam valahol: nem operációs rendszert/libet/egyéb nyavaját kell írni. Ez a megoldás azért ennek ellenére univerzális és máshol is használható.

Mit gondolsz. Elég jó? ;)

( locsemege v | 2017. 01. 17., k – 14:32 )

Most az van, hogy a változóm címe 16 bites, de abszolút címzésnél a cím alsó 7 bitjével lehet hivatkozni a változóra, a cím többi része a bank select registerben van. Persze a linker kekeckedik, s dob egy „fixup overflow referencing psect” kezdetű dalt, amitől nem vagyok boldog. A Microchip FAQ-ban találtam. Ugye, azt nem gondolják komolyan, hogy a forráskódban minden változóra hivatkozáskor egy maszkolást is oda fogok írni, éljen az áttekinthetőség. Tehát például:

incf var1, W

helyett:

incf var1 & 0x7f, W

Nem szívesen csinálnám heterogén környezetben, de érik, hogy a linuxos gputils nevű csomag gpasm assemblerét használjam...

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezt az elfogadható gányolást alkalmazom, minden változómat kétszer definiálok:

BSRSAVE     ds  1
BSRSAVE_    equ BSRSAVE & 0x7f
STATE_R     ds  1
STATE_R_    equ STATE_R & 0x7f
TI_R        ds  1
TI_R_       equ TI_R & 0x7f
STATE_G     ds  1
STATE_G_    equ STATE_G & 0x7f
TI_G        ds  1
TI_G_       equ TI_G & 0x7f

Így már fut az IT rutinom is és az USB kommunikáció is úgy, hogy nem száll el az egész. Első visszafogott, igen szerény részeredmény. Már lehet talán valamelyest az érdemi részét kalapálni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Amikor tisztán assembly-ben írogatok, a gpasm-ot használom magam is. Az probléma mentes környezet, de most egy öszvért műtök. Nagyjából egy ló fejére egy orrszarvú szarvát műtöm, a ló lábai helyére kacsalábakt, de uszonya is lesz. :D Rakás időm arra ment, hogy nem a feladattal foglalkoztam, hanem azzal, hogy elérjem, a fordító környezet azt fordítsa, amit látni szeretnék. Idő közben kijött a 3.51-es Mplab X, felraktam, már azt használom, de nem néztem meg a kiadási megjegyzéseket.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kérem, ne tréfálkozzunk! ;)
Tegnap írtam egy "hatalmas" 12hv609 programot, meg ezt írogatom 18f14k22-re, sőt a munkámat is csinálgatom 18f24k50.
Láttam, eltűntél, majd mintha decemberben előkerültél volna. Legkésőbb a héten leírom a requesteket a blogodba. Hiba sajnos nincs. ;)

Az a nagy lelógó helyzet hogy az elmúlt hét végére nagyjából működőképessé tettem a for, forc és repeat makrók/direktívák előzetes változatait. (Mintha valaki erre vágyott volna. ;-)) Az előzetesen az értendő hogy önmagában mindhárom szépen működik. Ha két for-t egymásba ágyazok akkor azok is rendesen mennek. Ámde ha az egymásba ágyazást vegyesen próbálom (for belsejében egy forc vagy repeat) akkor meghülyül az egész. A gpasm jelenlegi felépítése egyes részeken nem alkalmas arra amit szeretnék tőle. Remélem a következő hétvégén lesz időm kitörpölni valami értelmes megoldást a hibára. Az átlag napokon esténként alig tudok foglalkozni ezzel, emiatt tart ilyen sokáig. Már hamarabb is nekifogtam néha hogy átlássam a dolgokat, aztán félre kellett tennem és kiestem az egészből. Ha aztán egy idő múlva megint belefogtam akkor kezdhettem elölről. Ez van.

Ez aztán a derült égből elefánt!
Mihamarább kipróbálom. Már csak arra lennék kíváncsi, hogy az Intel, Microsoft és Digital Research (és gondolom sokan mások) által használt direktívák miért nem tetszettek?
Ha van valami hozzáfűzésem, akkor azt átirányítom a blogodra.

Mihamarább kipróbálom.

Ne kapkodj vele. :-) Még nem tettem közzé. Majd csak akkor ha szerintem normálisan működik.

Már csak arra lennék kíváncsi, hogy az Intel, Microsoft és Digital Research (és gondolom sokan mások) által használt direktívák miért nem tetszettek?

Ezért:
IRP "See FOR."
IRPC "See FORC."
REPT "See REPEAT."

Mi a francnak erőltessem az elavult elnevezést? Egyébként még nincsenek kőbe vésve a nevek, csak nem akartam visszafelé menni az időben. Az új nevekről szerintem ránézésre jobban lehet érteni hogy mit is művelhetnek. Az irp nekem nem mond semmit, a for viszont igen.

Mérhetetlen ostobaság a cipőkefére usb csatlakozót szerelni. Hamar porosodik. Pedig meg lehet csinálni. Ugyanúgy lehetne a villanyóra leolvasása is az ipv6 protokoll része, hiszen azt is meg lehet csinálni.
Különben is milyen szenzor az, amelyik nem xml-ben nyomja az adatokat?
Kb. ennyi értelmét látok ennek az okosságnak.

( locsemege v | 2017. 01. 20., p – 02:26 )

Az első mérési eredmény -831.1754 °C. Hm... cseppet kételkedem. :DD

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Köszi, közben már utánaolvastam. Letölthető, de a Seleae nem örül annak, hogy 5 dolláros kínai klónokkal használják a saját termékéhez készített sw-t és fenntartják a jogot hogy nem fog vele működni egyszercsak.
De ott van a sigrok project is sw-nek, lehet azzal is megy.

Na mindegy, egy ilyen 5-10 dodós motyóra rápróbálok én is, tudtok ajánlani valami olyat (preferáltan ebay-ről), ami normálisan meg van építve és jól működik?

Sokan járnak így. De működik és a hw már nem fog változni. A szoftverét köszörülgetik, most éppen tökéletesnek mondható. (1.2.10) Próbáltam már máshoz opensource ezt-azt - általában csapnivaló.

Maga a hw egy db mcu néhány bementi védelmet biztosító elemmel + táp ic, szóval nem igazán lényeges a kivitel. Nekem az usb kábelt kellett cserélni. Nem árt néhány csatlakozós és apró csipeszes drótocskát is venni mellé. Ja, és a felirat is lekopott.

Igen, egy 8051-kompatibilis MCU van benne, a rajt futó szoftvert pedig a PC program tölti le minden alkalommal.
Mármint a Logic8-nál, de lehet, a Logic16-nál is.

Nyilván a meglévő hardvert már nem változtatják, bár amúgy van néhány újabb termékük is.

Mindenesetre hasznos tud lenni és jól kezelhető a program.

...hát nem tudom.

A video, amit fent linkeltem azt a verziót mutatja, amit én ismerek eredetiként.
Lehet, hogy nincs igazam és volt egy korábbi hivatalos variáns is, de szerintem ezek csak másolatai a fentinek - bár a hardver nagyon hasonló.

Ezt tényleg a Saleae küldte évekkel ezelőtt (és valóban nem az aktuális verzió).
Anyaghasználat, minőség, csipeszek, tasak mind teljesen korrektek egyébként, viszont kedvezményesen volt vagy 20k talán...

Az általad linkelt írásban lévő áramkört egyébként maga az írás is klónként említi, ráadásul rosszabb minőségűnek tűnik, mint a mostani klónok. :)

Alakul a neverending story. :)
A régi mérete kb. 5x2,7cm -> hosszúkás, csak kínai koppintás kapható. Csak digitális, 8 bemenet, 24Ms/s.
Amit linkeltél az négyzet alakú -> jelenlegi gyártmány, lásd https://www.saleae.com/. Ezeknek oszcilloszkóp funkciója is van.

Az általam linkelt cikk azt is említi, hogy hiányzik a 245-ös ic. Ez így nem igaz, mert ott van az csak a hátulján. Valójában a táp ic a fölső rész széléről átkerült hátulra és beljebb. Így nagyobb, egybefüggő hűtőfelületet kapott, ami valószínűleg csak hosszabb idejű mérés esetén számít. Valószínűleg a felső tápos a "régebbi régi" verzió, ha klón ha nem.

Nem. :)

Ez talán 2012-2013-ban lett gyártva, úgy néz ki belül, mint a videón lévő és nincs oszcilloszkóp funkciója, valamint 24MS/s mintavételezést tud maximum.
Működésben 100%-ig egyezik a kínai klónékkal, eltekintve a bemeneti védelemtől - egyszerűen rájöttek, hogy könnyen másolható és legyártották ~5x2,7cm méretben ők is.

Akkoriban ez az egyetlen termékük volt még, azóta van még egypár, de a Logic8 is újra lett tervezve - és igen, a régi verzió is négyzet alakú.

A Saleae jelenleg ezt árulja.
A korábbi alap pedig ilyen - ez volt az első termékük, igényesen csomagolva.

Érdemes megnézni az EEVBlog-os videót.

Az új verzióban van egy FPGA is és 100MS/s mintavételezésre képes (bizonyos feltételek mellett persze), és a régi verzióéhoz hasonló doboza van.

Hasonlítsd össze a két NYÁK-ot - a fenti kép a Saleae-től rendelt régi típusúról készült (ugyanezt láttam én is belül), a másik pedig a jelenlegi verzió.

Szerk.: Rákerestem, a gyártó itt ír az eredeti verzióról, amiről beszélek. :)
Itt pedig a technikai specifikációja.
Ez az oldaluk régi tartalma, az akkori adatokkal, de felül jelzik is, hogy újabb verziók váltották. A Logic4 pl. ekkor jelent meg, ahogy a Logic16 is.
Nem volt nekik ~5x2,7cm méretű NYÁK-juk soha, azok mind koppintások csak.

Jólvanna! Győztél.
Tehát van egy "Saleae Logic Analyser Clone Teardown", amelyik tartalmazza a 245-ös bemenetet. A külső ESD védő elemek helyett az ebben levő bemeneti védelmet használják, ami kevesebb túlterhelést bír el.
Az eredetiben meg van egy komprátor vagy opamp (U1), aminek a szerepe ismeretlen. Viszont világosan látszik, hogy a bemenetek egyenesen a processzor lábaira mennek.
Tehát ez a klón nem is klón, csak hasonlóan viselkedik. ;) Ráadásul valaki áttervezte az eredetit és a kínaiak ezt koppintják, mivel módosítani nem igazán szoktak.

A sigrok a 16 -bitet is viszi, akár ezzel a "klónnal" :
http://www.ebay.com/itm/CY7C68013A-56-EZ-USB-FX2LP-USB-Develope-Board-M…
Sajnos még mindig nem tanultam meg hogy lehet ezeket a hosszú linkeket eltüntetni :(
Védelem? - lehet egy kupac esd diódával jobban jársz.

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

Ezt ki tudnad fejteni jobban?
Ez egy devboard, ezek szerint erre fel lehet tolteni valamilyen programot, amitol 16 bites analizator lesz belole. Mit, es mivel?

Amugy:
[ url ] http://akarmi.lofasz.hu [ / url ]
A masik lehetoseg:
[ url = http://akarmi.lofasz.hu ] Kattints ide! [ / url ]
(space-ek nelkul persze)

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

Lényegében a "Hozzászólás:" mező alatt - amikor írod - látsz egy ilyet:
BBCode jelölők használata engedélyezett, az URL-ek automatikusan linkké alakulnak
vagy egy kicsit alább:
További információ a formázási lehetőségekről
No, ott megnyomod a linket az egérrel, és elolvasod. ;)

Az eszköz teljesen védtelen! Valójában egy minimál board.
Azonban, ami a mintavételezést és a minták "befröcskölését" a PC illeti teljesen jó, akár 16 csatornát is használhatsz.
Azt csak halkan súgom, hogy erre az alapra lehet szkópot is csinálni ha a bemenetekre ADC -t illesztesz - hangfrekis munkákhoz elégséges. Ha tovább túrod a sigrok projektben felsorolt eszközöket találsz is ilyet, de már nem látom hogy gyártanák. Ráadásul ebben az esetben azért korrekt bemeneti erősítőre is szükség van - a végeredmény, lehet drágább lesz a lé mint a hús.
DSO203
Ha csak egy csatornát használsz akkor 72M minta per sec és PC -hez sem vagy kötve - egyszerűbb szerviz feladatokhoz jó ár/érték aránynak tűnik.

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

Ilyenkor bánatos vagyok az olcsó digitális technika miatt. Jó 30 évvel ezelőtt kétsugaras talán 450MHz-es Tektronix szkópot használtam, meg olyan analizátort, amiben alaphelyzetben volt 4db 64 csatornás fiók. Az utóbbiban volt hw trigger, amit több képernyőn keresztül folyamatábra alapján lehetett beállítani. Meg disassembler és futott rajta, MP/M oprendszer. Persze bőviteni is lehetett, ha kellett...

Most meg egy DSO-1082 USB szerkezettel (8bit, 80Ms/s, két csatorna) küzdök. Sok esetben a rutinom segítségével "fejben dől el" ;), hogy amit látok ahhoz képest mi történik. :(

Nem a költséget látom problémásnak, hanem egy olyan analóg műszert, amilyened még nincs, mivel mérsz be?

Ennek ellenére figyelemre méltó ez a szerkezet, különösen a Hi speed usb. Mert azon már át is lehet vinni, amit méricskélsz! ;)

Alap szkóp? Az milyen? Jelenleg egy ck. 30 éves Iwatsu kvázi kétsugaras 100MHz sávszélességű szkópot használok - egy kiváló barátom szokta időnként helyrerakni az "agyát" - a szkóp javításhoz is szkóp kell :)
(Anno két hibásan eladott Műszertechnika XT alaplapot ezzel javítottam - teszt szoftver + ciklikus reszet technológiával - akkor tapasztaltamn meg mit jelent ha a CPU előre fetcheli az opcodót :)
Periodikus jelekre, jelszintekre de még hozzávetőleges frekvencia mérésekre tökéletes, de mit csinálsz a tranziens folyamatokkal? Mit csinálsz mondjuk a soros/párhuzamos buszokon (spi, isp, i2c). Ráadásul ma már a PCI is szép sebességgel ketyeg, hogy mondjuk a VME busz stb. Megnézheted a szinteket, esetleg nincsenek jelalak torzulások de ez minden. Kell a nagy sebességű digitális mintagyűjtő szkóp és valami jó szoftver ami legalább megmutatja (a sigrok nagyon fapados, a salea komoly munkát tett fektetett bele).
A két funkcionalitás nem igazán egyeztethető össze, mindig valami rovására megy. De igazából azt kell mondanom, hogy a fő baj az hogy nincsenek olyan munkák és megrendelések amihez ilyen komoly eszközök elengedhetetlenek és megtérül az áruk - sok milliós beruházás. Talán a kölcsönzés lenne az opció, de ez nagyon síkos talaj, a gépkocsi kölcsönzéssel szemben nincs jól kitalálva.

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

Én is egy kb. 30 éves szkópot tervezek most venni, igaz csak 50 MHz-es. A kiváló barátodhoz lehet elvinném egy átvizsgálásra, szerintem ráférne.

Amúgy meg pont arra kell, amit írtál is: jelszint, zajszint, periodikus jelek, stb., ilyen "koca" hobbifelhasználásra. Logikai cuccokhoz majd veszek egy logic klónt, amiről fentebb már megemlékeztünk.

Hmm, koca meg hobbi.
Kicsit agresszív kismalac leszek. A fórumon annyi derül csak ki, hogy az igazi hobbisták azok, akik nem értenek valamihez csak csinálják. Sőt nem is akarnak érteni hozzá.
Az az occsó logic klón a mellékelt protokoll analizátorral simán olvassa és megfejti az usb full speed buszt is. A profi felhasználáshoz csak a trigger hardver hiányzik.
Az 50MHz-es analóg szkóp nem olyan fullextrás, mint a 80MHz-es 8 bites windózos. Ennek ellenére egy usb szkóphoz képest csúcstechnika. Nem parasztvakítás csak képes mérni.
Szóval a logic klón és usb szkóp nekem elegendő a munkavégzéshez. Eddig bármilyen 8 bites mcu, ilyen környezetban használ interfész, analóg kapcsolás, kapcsolóstáp beméréséhez elegendő volt. Az 50MHz-es szkóppal jobb műszered lesz mint nekem.

Az én terminológiámban a hobbi és a profi között a legfőbb különbség az, hogy a profi abból él. Én nem ebből élek, csak szeretek ezzel foglalkozni. A tudásom eléggé hiányos sok területen, de ha van időm akkor utánaolvasok. (Itt a fórumon is tanultam néhány hozzászólásotokból.) Nyilván sose fogok annyit tudni az egészről amit ti már felejtettetek belőle, de ez nem zavar.
Az pedig más kérdés, hogy lesz-e szkópom (valszeg igen) és hogy ez lesz-e, még kiforratlan a dolog. Ebay-en amúgy rengeteg amerikai hirdetés van, eléggé olcsón jó cuccok (100% értékelésű, többezer tranzakciós eladóktól), csak a szállítás baromi drága, és utána jön a zállam és még 27%-kal lehúz, így lesz egy 20 ezres cuccból - jó esetben - 50 ezres.

Hát bizony... Na, szóval az van, hogy ha az ember IT-ben valósítja meg az I2C kezelést, feltölti a buffert, majd mondja neki, hogy azt küldje el, majd jöjjön vissza a kiolvasott eredmény, akkor azért illik megvárni a választ is. :P Ezt bírtam azzal tetézni, hogy memóriával takarékoskodva ugyanazon a területen végeztem a számkonverziót, ahova az eredmény jött. Ez normális körülmények között rendben, de úgy nem, ha a memória szemét konvertálása közepén egyszer csak beesik oda IT-ből a helyes adat. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Na, persze! :) IT-ből hardware-t szoktam kezelni, meg azzal nagyon szoros összefüggésben lévő kezelést, annak managelését, s ami nagyon rövid idő alatt fut le. Ami nem odavaló, azt alap szinten csinálom, s az IT rutin flag-eken át jelzi, hogy valamivel elkészült. Amúgy ez most is így volt, csak a saját flag-emet felejtettem el vizsgálni. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Helyesen: IT-ből eseményt szoktam kezelni.
Esemény lehet, ha megérkezett az adat az ADC-ből vagy az i2c végzett egy beolvasással. Lényegesen rövidebb - azaz gyorsabb - a program, ha nem beszélget feleslegesen saját magával és nem kell mégegyszer elővenni az adatot.
A hőmérőt úgy is ritkán kell olvasgatni, van idő bőven.
Ha pl. az ADC-t sűrűn olvasod ki, akkor sokkal fontosabb elkerülni a felesleges kódot.
Tehát egy konverziót akkor kell végrehajtani, ha megjött az adat és nem akkor amikor az IT-ben beállított flag-et pollingolva jelzi, hogy megjött az adat, és akkor az imént elrakott adatot újra elővéve...
Szerinted melyik lesz a gyorsabb?

Ráadásul a főprogramot sem csúfitja el a felesleges kód.

Ez attól is függ, mi éppen a konkrét feladat...

Általában interruptban minimalizálni célszerű az eltöltött időt, és nem konverziókat meg hosszú műveletsort elvégezni.
Már csak azért is, mert nem feltétlen egy feladatra koncentrál az egész program és jöhet más interrupt is, amit szintén le kell kezelni - és nem feltétlen magasabb interrupt szintjén.

Az interrupt alapvetően egy "kivételes" eset, amikor a program futása megszakad egy időre, de a főprogram "folyamatos" futása (pl. kezelői interfész frissítése) is lehet viszonylag fontos feladat...

Másrészt lehet olyan eset, amikor az adat lekezelése fontos, de feldolgozása nem feltétlen sürgős...

Tehát függ a feladattól, de általánosságban nem időzünk feleslegesen interruptban.

Erősen függ a dolog attól is, hogy van-e egynél több időkritikus interruptforrás. Ha nincs, akkor kb. mindegy, hogy hogyan csinálod a programot. Ha van, akkor viszont oda kell arra figyelni, hogy az egyik interrupt kezelése ne vihesse el az időt a másik interrupt elől - nyilván erre is vannak technikák, amivel mégsem kell a főprogramba rakni a feldolgozást (pl. BH).

Az időkritikus interrupt szerencsére egy PIC esetén általában kiküszöbölhető. Hiszen olyan eszközök vannak benne, hogy pont az ilyen feladatokra találták ki.
Példák:
Nem tudsz külső esemény+timer+interrupt alapon pontosan időt mérni = CCP (Capture/Compare/PWM modul)
Ne tudod pontosan elindítani az ADC-t = A Special Event Trigger órajel pontossággal índítja és aszinkron olvashatod ki az eredményt.
De van olyan példa is, amikor kábel futásidőt lehet mérni 1ns felbontással (CTMU+ADC).

Szóval az interrupt elég ritkán, csak speciális esetben használatos időkritikus események feldolgozására.
Persze ez nem azt jelenti, hogy mondjuk 12, részben összefüggő interrupt forrásnál ne kéne felkötni a gatyát. ;)

Már hogy' lenne felesleges! Hiszen az történt, hogy éppen most esett be az adat, amit konvertálni kell. Ha a konverzió elég gyors, akkor az interrupt futásideje lényegtelen mértékben megnő és ennyi.
Fordított esetben a főprogramnak jelezni kell, hogy megtörtént az esemény - az, ami az interruptot kiváltotta. A főprogramban biztosítani kell, hogy az interrupt ne módosítsa azokat a váltózókat, amelyeket a főprogram még nem dolgozott fel. (lock, mutex) Ez egészen az adatok halmozódásáig fajulhat.

Nyilvánvalóan ez a megoldás sem nélkülözheti a józan paraszti ész nyújtotta előnyöket. ;)

A konverzió logikailag nem az IT-be való. Nyilván bármit lehet, mérlegelés kérdése az egész.

Nekem most 3 dolog van IT-ben:

- 10 ms-os időalap
- USB IT kiszolgálás, ne menjünk a részletekbe, ezt többé-kevésbé készen használom fel
- I2C bufferelt kezelés, legalsó réteg

A mérés elindítása, az eredmény binárisból BCD-be konvertálása, valamint a BCD-ből ASCII-vé konvertálása alap szinten fut.

IT-ben használok bra és brw utasításokat, alap szinten nem. Mármint amióta olvastam az errata-t. :(

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az időalappal csak az időt méred. Bármilyen <10ms jitter senkit nem érdekel.
Az USB IT általában várhat, mert úgy írták meg. Ráadásul roppant ritkán fut, mert a lényegi kommunikációt a hardver végzi.
Az i2c stop condition vége meg pont az az állapot, amikor pontosan tudod, hogy nem fog következő i2c interrupt befutni. Ekkor kényelmesen konvertálhatsz.
Binárisból BCD-be és BCD-ből ASCII? Gondolom legalább háromszorosan bufferelsz. ;)
Arra nem gondoltál, hogy az adat alsó 4 bitje a tört része a hőmérsékletnek? Ez meg legfeljebb 16 féle ASCII értéket vehet fel: "0000","0625",..."9735". Ezen kívül marad egy bájtod, ami
- ha >100 - van egy egyesed és levonsz 100-at
- /10 és hozzáadsz 30-at
- a maradékhoz hozzáadsz 30-at
Szerintem ennek a sok marhaságnak a futásideje <50us, persze a bufferbe írással együtt. Akkor meg miről beszélünk? Talán arról, hogy akár <250us időalapot sem zavarná ez a megoldás.

Amit írsz, az ugyan működne, de annyira végtelenül gányolás, hogy szégyellném leírni a kódba. Teljesn általános a konverzióm. Nem szedem szét az egész és a törtrészt. Decimális alapon konvertálok. Az eddigi részeredményt kétszerezem, amelyet úgy csinálok, hogy hozzáadom a részeredményt önmagához. A binárist shiftelem balra kifelé. Ha 1-es bit pottyant ki, akkor hozzáadok a decimális részeredményhez 00000625-öt. Ha 0 pottyant ki, akkor meg nem. :)

A packed BCD összeadást pedig úgy csinálom, hogy a byte-on történő sima összeadást követően hozzáadok még 6-ot, ha digit carry volt, még 0x60-at, ha carry. Utána jön az, hogy megnézem, nem csordult-e „betűbe” a szám. Ezt úgy csinálom, hogy megint hozzáadok 6-ot, de az eredmény a W-ben keletkezik, s ha most digit carry lett, akkor nyilván betű volt, szóval akkor W-ből visszaírom az eredménybe ezt. Aztán hozzáadok 0x60-at újfent, eredmény a W-be, ha carry lett, akkor betű volt, szóval akkor mehet a W az eredménybe. Ami most keletkezett carry, azt hozzá kell OR-olni az elején lévő összeadás átviteléhez.

Az ASCII-vé konvertálásról nem írok, ott legfeljebb a '-' előjel a feladat, a bevezető nullák eldobása, persze úgy, hogy közvetlenül a tizedespont előtt maradjon egy, a tizedespont kiírása, valamint a végéről a felesleges 0-k leszedése, de az is úgy, hogy a pont után egy azért maradjon.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ám legyen, hívjad gányolásnak. Ennek ellenére az a 8-10 féle hőmérő majdnem ugyanazt az adatábrázolást használja*. Tehát ugyanennyi energiával hívhatjuk speciális konverziónak, ami kettes komplemens->ASCII. Mert hát igazad is lehetne, de hogy kerül a képbe a BCD?? ;)
Ha nem bánod, majd iderakom a kódot futásidővel együtt. Aztán szégyenkezünk.

*Az MCP9801 és az MCP9808 pl. annyban különbözik, hogy a 12 bites adatot az egyik 4 bittel eltolva küldi. Én meg ismerem a swapf utasítást. ;)

( locsemege v | 2017. 01. 23., h – 23:41 )

Kis „vidámság”:

If a BRA or BRW instruction is executed concurrently with an interrupt event, the ISR routine can restore the PC to an incorrect value.

Work around
Use the GOTO instruction rather than the BRA or BRW instruction.

Továbbá:

When powering-up the device, selecting a USB Ping-Pong Buffer configuration (PPB<1:0> = 01, 10, or 11) and then enabling the USB module (USBEN = 1), the data located within the Dual Port RAM region may be corrupted.

Work around
Avoid writing to the Dual Port RAM region until after the USB module has been initialized.

Vajon ezeket figyelembe veszi a C compiler, vagy fordít majd minduntalan el-elszálló programot?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ebben az a legszomorúbb, hogy ez nem is tizenéves processzor.

Az első probléma: Relatív ugrásnál bekövetkező IT esetén megsérülhet a stack.
A megoldás további lehetőségei:
A BRA/GOTO esetén itt a GOTO nem hosszabb tehát mindegy. Az ugrótábla előtt tiltani kell az IT-t, majd minden ágon engedélyezni. Ronda, de működik.
A BRW helyett computed jump-ot kell használni. Hosszabb, de még hordozható is.

A másodig probléma: Ping-Pong mód beállítasakor megsérülhet az USB RAM.
A megoldás oda van írva: Csak inicializálás után írjál az USB RAM-ba.

A Ping-Pong módnak egyébként sincs sok értelme. Ha egy buffer nem elég, akkor miért pont kettő igen? ;)
A megoldás egyszerű.
Az adatokat rögtön az USB RAM-ban levő bufferekbe kell írni. Ekkor elmarad az (adat buffer) -> (user buffer) -> (USB buffer) adatmozgatás. Az aktuális buffer címét a TxReport hívása előtt be kell írni a BDnADR(L,H) regiszterekbe. Ezzel kész a sokszoros Ping-Pong mód. A rossz hír: a 64kB/s sebességet ezzel sem lehet túllépni. (HID, interrupt mód, maximális 64B buffer) Persze ekkor at kell írni a fantasztikusan megkomponált drivert. ;)

A C compiler biztosan figyelembe veszi. Inkább az a baj, hogy az inicializálás sokszor a programozó feladata és nem minden eset kompatibilis a lib-ekkel. No, meg néha nem működő ostobaságokat is szokott fordítani. Éppen ezért komolyabb feladatok megoldására nem merném használni.

Jótanács: Vásárlás előtt előszor az errata-t olvasd el, ne az adatlapot! :D

Az elsőre azt csináltam, hogy IT-ben használok bra és brw utasításokat, oda úgysem csaphat be újabb IT. Tudom, meg lehetne csinálni, de ez most hagyományosan van szervezve.

Alap szinten pedig

movlp HIGH label
goto  label

Persze figyelve arra, hogy ha a goto-t egy btfs[cs] ugorja, akkor a movlp még ez elé kell.

Az USB RAM problémájával csak elnagyoltan foglalkoztam. Úgy döntöttem, az assembly betétem változóterületét fix címre, 0x620-ra allokálom, nem bízom ezt a linkerre. Ez a cím nem dual port RAM. Bár gondolom, ennek itt azért nincs jelentősége, mert vélhetően a teljes 512 byte-ot az USB stack használja.

Szerk.: Egyébként azért szeretném jobban a bra utasítást a goto-nál, mert nem kell a PCLATH-tal foglalkoznom, lévén relatív ugráskor a PCH-ba csordul az, aminek oda kell csordulnia. Hasonlóképpen a brw is a teljes PC-re képez átvitelt, szemben az addwf PCL utasítással, ahol figyelni kell arra, nehogy a PCL túlcsorduljon, azaz modulo 0x100 lapon túlra nem lehet vele ugrani.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ugrótáblára kicsit módosítottam ezt: google -> joeyd999 first PIC trick
Igaz van overhead, meg pic18 a kód, de csak megbírkózol az értlemezésével. ;)
Viszont agy nélkül lehet írni az ugrótáblát <127 elemig. Az meg bőven elég. 

			movf		Command, w, a
			call		cjump
			bra		Command0
			bra		Command1
...
cjump
			addwf		WREG, w, a
			addwf		TOSL, f, a
			skpnc
			incf		TOSH, f, a
			return

Az USB RAM csak ott nem használható ahol az UEPn-ben engedélyezett Buffer Descriptorok (BD) vannak, illetve az BD-ban kijelölt bufferek. Vélhetően a 0, 1, 2, 3 EP van használatban. Tehát a kizát tartományok lineáris címmel:
- 2000..201f
- Ez után lehet a 0, 1 endpoint-hoz tartozó bufferek, amit kb. SetupPkt változótól kezdve találsz meg.
- Néhány változó.
- A 2, 3 endpoint-hoz tartozó bufferek, a címük az initEP (vagy valami hasonló) részből kiolvasható. Mérete 2x40h.
- 21f0..21ff
Ennek alapján több mint 256 bájtod van szabadon.

Hasonlóképpen a brw is a teljes PC-re képez átvitelt...
Nem figyelsz! Hát ott írja az errata, hogy néha semmi ilyesmit nem tesz! :))))

Amit írtál, tetszik, ügyes megoldás. Különben könnyen alakítható úgy, hogy az index 0xff-ig mehessen.

Emlékszem, Z80-on csinélt még az ember ilyeneket:

PUSH BC
RET

A bra illetve brw utasítás „gyengesége” szerintem abban rejlik, hogy a CPU-n belül vélhetően előbb kerül a stackre a PC, mintsem a bra illetve brw a relatív ugrást az ALU-val kiszámíttatta volna.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2017. 01. 26., cs – 00:20 )

Javul a helyzet. Vadásztam egy bugra, egy sima elírás volt. Aztán optimalizálgattam kicsit. Minek egy legfeljebb 4 bites változóra egy egész byte-ot elpazarolni? Így lett néhány 4 bites változóm. Volt pointerem, amelyet 16 biten tároltam, de valójában egy bázis címhez képest 4 biten is elég tárolni az offsetet.

A hőmérsékletet visszaadja két decimális ASCII stringben. Az egyik teljes, 1/16 °C pontosságú, míg a másik 0.1 °C-ra kerekített. Visszaad egy harmadik stringet is, ez jelenleg üres.

Amit csináltam, most hibátlanul működik. A következő lépés az lesz, hogy USB host-ról parancsot mondjak neki, ő meg hajtsa végre, válaszoljon.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kapcsolgathatnék vele, csak minek. Van két LED-em, azokkal esetleg bohóckodom majd. Egyelőre debugolásra használtam őket.

Amúgy olvastam azt a topicot. :)

Ez a pici hobby projectem arról szól, hogy valamelyest megtanuljak USB-t kezelni mikrokontrolleren illetve Linux host-on. Nem szeretem azt a fajta kiszolgáltatottságot, amikor kész modulokból kell építkeznem. Jobban szeretek a feladatra célhardware-t tervezni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

LED-et már kapcsolgatok vele USB-n. :) A változatosság kedvéért most a mérést szúrtam el. Mivel ahhoz minden rutin megvan, s teszteltem, működött, csak az új környezetben, a picike parancsértelmezőmben lehet valami bug. Keresem. :)

Szerk.:

Bug megtalálva, felszámolva. :) Nem túl nagy baj, ha arra a memórialapra lapozunk, ahol a műveletet szeretnénk végezni...

Most már host felől fogad parancsokat, ki tud gyújtani, illetve kioltani piros valamint zöld LED-et, továbbá mér hőmérsékletet, az eredményt visszaadja ASCII-ben, valamint 0.1 °C-ra kerekítve ASCII-ben. A LED-eknél lehet 10 ms-os felbontással időt is mondani, ekkor kigyújtja a LED-et, majd a megadott idő elteltével kioltja.

Írtam egy picike „parancsértelmezőt” assembly-ben hozzá. Asszociatívan keres, így mindegy a parancsok sorrendje, illetve a hibás parancsot ignorálja. Az 'r' vagy 'R' a piros, a 'g' vagy 'G' a zöld LED-et vezérli, paraméter a világítási idő 10 ms-ban. 00-nál kikapcsolja a LED-et, ff-nél végtelen ideig be. Az 'm' vagy 'M' parancs pedig mérésre utasít.

Tehát az 'mr0a' azt jelenti, mérjen hőmérsékletet, valamint a piros LED 100 ms-ra villanjon fel.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Most eljutottam oda, hogy írtam egy picike shell daemont, hozzá systemd unit file-t, ez percenként időponttal együtt file-ba logolja a hőmérsékletet. Ezen felül a desktopom felső lécére kiírja az aktuális hőmérsékletet 0.1 °C-ra kerekítve, ez fél percenként frissül. A két folyamat aszinkron. A zöld LED felvillan 100 ms-ra, ha a desktop-ra kér mérést a gép, a piros LED pedig akkor, ha a logfile-hoz.

Továbbá élesítettem a mikrokontrollerben a watchdogot.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2017. 01. 30., h – 17:49 )

Volt még egy megoldandó probléma. A mérés nagyjából legfeljebb 340 ms-ig tart, addig nem válaszol az eszköz. Amennyiben kiadom a parancsot a mérésre a host-ról, az USB-s eszközöm ott a drót végén magába fordul, mér egy jót, majd visszaadja az eredményt. Ha ezen idő közben a host egy másik szálon szeretne kommunikálni az eszközömmel, a libusb_claim_interface() visszatér egy kövér device or resource temporarily busy üzenettel, ami érthető, hiszen egy már futó process kommunikál épp az eszközzel. Erre azt találtam ki, hogy ebben az esetben várok 400 ms-ot, majd újra megpróbálom. Legfeljebb 8-szor kísérelem ezt meg, utána már tényleg úgy tekintem, hogy busy, s visszatérek hibával.

Ezzel elértem, hogy teljesen aszinkron módon több alkalmazás is kérheti tőle a hőmérsékletet, s az sem gond, ha időben ütközés van.

Konkrétabban: egy daemon logolja percenként a hőmérsékletet, míg a desktopra egy kisalkalmazás a saját ütemezésével lekérdezi - ez most kb. 31 másodperc -, s kiírja az aktuális mért hőmérsékletet.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azt ugye érzed, hogy nem ezt hívják "megoldásnak"? Ez max. workaround.

A korrekt megoldás vagy az, hogy a készülék aszinkron módon kommunikál (kiadod a feladatot, majd lehet a státuszt kérdezgetni, ami addig "in progress", amíg meg nincs a válasz, utána viszont akárhányszor ki lehet kérdezni a végeredményt), vagy csak egy valaki használhatja a készüléket (egy daemon/kernel driver), és tőle kérdezgeti mindenki más.

Érzek igazságot abban, amit mondasz. Ugyanakkor itt nem az van, hogy a hostra kell írnom egy ismeretlen USB-s eszközhöz valamiféle programot, amely képes parancsot adni, illetve mérési eredményt átvenni az eszköztől, hanem az USB-s eszközt is magam csináltam, így pontosan ismert, mennyi idő az, amíg legfeljebb magába fordulhat. Ha több, az valóban hiba, bár már élesítettem rajta a watchdogot. Amúgy a watchdoggal nem fedek el hibát, előtte sem szállt el a mikrokontrollerben a program, csak szeretem, ha van egy ilyen védelem is.

Visszatérve a felvetésedhez. A libusb_claim_interface() nem fatális hibát mond, nem arról van szó, hogy nincs a kábel végén eszköz, csak azt mondja a host kernele, hogy valaki használja. Erre mondom én a programmal, hogy jó, akkor várjunk picit, aztán bízzunk abban, hogy az eszköz felszabadul. Lényegében ugyanez lenne az eredmény, ha az USB kábelen magától az eszköztől tudnám meg, hogy ő használatban van. Így nem járatom meg a kábelen az infót, hiszen a host kernele is tudja, hogy megszólította az eszközt, válaszra vár, de még nem érkezett az meg.

Persze nagy mértékben igaz az is, hogy a kényelmes, gyors megoldásomban az is benne volt, hogy fogalmam sincs, hogyan tudok kommunikálni egy olyan USB-s eszközzel, amely amúgy foglalt. Ezt jó is volna megértenem, mert valahol ez a projectem célja. Vélelmezem - de nem tudom -, attól, hogy a bulk transferben várakozás van, még control transferben lehet üzenetváltás. Ha ez így van, meg lehet csinálni azt, amit mondasz, s valószínűleg épp a tanulás miatt meg is fogom csinálni.

Az is érdekes, hogy lekérdezem az eszközt, az szabad, majd lehet, mire kommunikálnék vele, addigra busy. Tehát kellene olyasmi, hogy control transferben elküldi a host program például a pid-jét, az eszköz innentől kezdve csak azzal hajlandó kommunikálni, aki ezzel a pid-del azonosította magát. (Itt a pid-en process id-t értek.)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igaz, Raspberry-vel, de én a következőképpen csináltam:
Egy script folyamatosan kérdezgette le a hőmérők adatait és let RAMdiskre írkálta az eredményt egy-egy fájlba.
Amikor a programnak szüksége volt egy (vagy akár az összes) hőmérő mért értékeire, akkor kiolvasta a hőmérőnek megfelelő fájlt.
Ez innentől történhet másodpercenként több ezerszer is, a hőmérsékleti adatok max. 750 ms (millisecundum) régiek. Maximum ennyi idő lekérdezni a DS18B20-at, ha a legnagyobb pontossággal használom.

Nálad is érdemes lenne elgondolkozni, hogy ne akkor kérdezze le a hőmérőt, amikor az USB vár a válaszra, hanem adja oda neki az utolsó mért hőmérsékletet, közben folyamatosan kommunikálhat a hőmérővel.

Itt most az elv a lényeg. Mi van akkor, ha egy USB-s eszközt több program is meg akar szólítani a host-ról, s időben ütközés van?

Az egyik megoldás, hogy frissen mérek, foglaltság esetén pedig várok, majd újra próbálkozom. Ez van most. Aztán lehet az, hogy ha régi a mérés, azaz például 10 másodpercnél régebbi, akkor mérek, de ha 10 s-on belüli, akkor egész egyszerűen visszaadom a legutóbbi eredményt. Ebben az a ráció, hogy a túl gyakori mérés nagyjából 0.2 °C-kal megemelheti a hőmérő chip hőmérsékletét, így meghamisítja a mérést.

Aztán egy lehetőség az, amit írsz, tehát egy daemon mér, mindenki más onnan falatozik az adatokból. Különben file helyett megfontolandó lehet a fifo, azaz a named pipe is.

Kezdetben egyébként azt csináltam, hogy autonóm módon percenként mért egyet, s amikor a host lekérdezte, a mindenkori legutolsó eredményt adta át.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Lényegében ugyanez lenne az eredmény, ha az USB kábelen magától az eszköztől tudnám meg, hogy ő használatban van

Nem, nem ez a mondandóm lényege. Hanem az, hogy a készüléket most úgy veszed igénybe, hogy minden felhasználó (kliens) egy mérést indukál, amiből egyszerre csak egy lehet aktív, holott erre nincs szükség, ugyanazt az adatot több felhasználónak is odaadhatnád.

Ebben az esetben nem is lenne szükség huzamosabb időre rezerválni a készüléket, mert minden elemi művelet rövid és atomi (mérés indítása, státusz lekérdezése):

Mérés indítása - lehetséges válaszok: ok, most indult, ennyi ms múlva nézz vissza; ok, már amúgy is megy, ennyi ms múlva nézz vissza; hiba, nem működik a rendszer

Státusz lekérdezése - lehetséges válaszok: idle, nincs korábbi mérésadat; idle, ez volt az előző mérés eredménye, ennyi másodperccel ezelőtti; mérés folyamatban, nincs korábbi mérésadat; mérés folyamatban, ez volt az előző mérés eredménye, ennyi másodperccel ezelőtti.

Viszont egyértelműen egyszerűbb a daemonos megoldás, amikor egyetlen egy valaki olvasgatja a készüléket, és mindenki tőle kéri el az adatot.

Igen, ez az igazán szép, cserébe picit munkásabb megoldás. Többek között azért is, mert innentől kezdve a host-on futó kliens majd mazsolázhatja, mit is kezdjen a sok lehetséges válasz egyikével. :)

Valami köztesre hajlok, kész is van már, most írtam meg, csak még tesztelnem kell. Annyit csinálok, hogy ha a host-ról az egyik kliens mérést kér, akkor amennyiben a legutóbbi mérési eredmény 12 s-nál nem régebbi, visszaadja azt azonnal az USB-s eszköz, s nem mér újra. Ha már elavult az eredmény, akkor mér, de megváratja a klienst, csak a friss eredményt adja vissza.

Egyébként a kliensek akkor is ütközhetnek, ha csak valamelyik LED-et gyújtják ki, vagy azonnal ad vissza eredményt az eszköz, csak ilyenkor kicsi ennek valószínűsége, mert gyors a művelet, rövid ideig foglalt az eszköz. De ez nem baj, a libusb visszaadja, hogy az eszköz foglalt, kisvártatva a kliens újra próbálkozik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2017. 01. 31., k – 01:43 )

Kijött a Microchip xc8 compilerének újabb, v1.41-es változata. Egyetlen változás, amit tapasztaltam, hogy ugyanazt a forráskódot, amit eddig 3 másodperc alatt fordított le, most már 6 másodpercig tart lefordítani. Hiába, no, érezhető a fejlődés! :(

Ami pedig a szerkezet host oldali programját illeti, most vettem csak észre, hogy nagyvonalúan lehagyták a tesztből a libusb_close() függvény hívását. Mivel az én programom a teszt átfaragásából jött létre, abból is hiányzott, de már pótoltam.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE