Sziasztok!
Linuxos környezetben kellene automatizálás-távvezérlés feladatot megoldani, esetleg mérést is. Ehhez valamilyen IO interfészre lenne szükség. Kb. 6 digitális output, 4 digit input, 1 analóg input a kezdeti igény. Már meglévő szerverhez kellene csatlakozni. Az LPT port foglalt, amugy sem perspektivikus. FT245 persze megoldás, de az analóg input nehézkes. Soros port még csak lenne, de ott is sok a munka az interfészeléssel. És a szoftverrel.
Megfelelőnek tűnne a Vellemann K8055 kártya, ehhez van linux driver
Egyszerüen lehet parancsokat küldeni, pl.
k8055 -P:1 -A1:123 -A2:234 -D:33
( For Board 1 , Set Analog output 1 to 123, the second to 234, the 8 digital to 00100001 )
Gyárlag persze Windowsos program is van hozzá, ami nem hátrány.
Sajnos, rohadt drága a cucc (40EUR+szálljtás) ahhoz képest, hogy egy 16F745 van benne, és több is kellene. Persze, a 16F745 programozva, vagy csak a program nem hozzáférhető.
Szóval, mit tudtok javasolni linuxhoz USB-s IO-nak?
Fontos lenne, hogy valamennyire kész, utánépíthető project kellene, ne kelljen alacsonyszintű programozgatással foglalkozni (amihez nem is értek).

18F*550 + HID vagy CDC firmware. Mindkettő C nyelven íródott. Mindkettő megfelelően támogatott Linux alatt. Ha kell előásom a HID kezelő alkalmazásomat. A CDC meg egyszerű sorosportként kezelendő.

A HID vagy CDC firmware mit jelent, mit nyújt?. Hogy érhetők el a HW portok programból? Van valami C library?

HID = HUMAN interface device. Ilyen protokollal mennek az USB-os patkányok, billek stb. Előnye hogy M$ alatt nem kell hozzá driver. Linux alatt sem kell term. A HID-ast anno körbejártam tudsz egyszerre 62 hasznos Bytot elküldeni egyszerre amire azonnal válaszol is. Van rá kész függvény. Kell hozzá a kernelmodul term, és ha jól emlékszem a libusb-dev csomag. De lehet ez csak a fordításhoz kell.

A CDC pedig egy sima sorosportként látszik. Nem a szokásos /dev/ttyUSB0-ként hanem azt hiszem /dev/acm0-ként.

Infóid alapján megtaláltam a How to build a USB device with a PIC 18F4550 ... webhelyet. Kicsit ez nekem túl "low level". Ha tudnál kész programot rá, nem csak ilyen C vázat, az jó lenne.

Hardver oldalról itt érdemes nézelődni. PC szoftver meg ha eldöntötted milyen FW-t használsz tudok adni.

Nem tudom, hogy melyik firmware-től mit várhatok.
A cél az ami -kb- a Vellemann modulnál.
Valami futtatható cucc, (bináris, shell, perl) aminek az outputját parse-olni lehet. Mit javasolsz?
RRDtool vagy mrtg lesz a cél.
(gépterem hőmérséklet, mozgás érzékelés,
ennek alapján beavatkozás, windowsos alaklmazás lefagyása esetén a gép ujraindítása távolról )

Szóval akkor nézzük konkrétabban. Vellemann modult még nem láttam, nem ismerem.


HID kezeléshez C függvényeim vannak. De biztos megoldható más nyelvek alól is. Soros port kezelése megint nem nagy attrakció akármilyen nyelv alól.


Mennyi szenzor, van milyen időnként kell mintát venni?

Bár szvsz. hagyjuk a HID-at. Egyszerűbb a sorosport. Arra nyomsz egy cat-et megfelelően felparaméterezve és csak simán olvasgatod az adatokat a kimenetről.

Legsűrűbben max. egypercenként akarok mintát venni.

Ha sorosport, akkor shell sciptböl a legegyszerűbb. Vagy inkább expect-ből?
Tudsz egy mintát?

Ez esetben bőven elég a sebesség.
pl: cat /dev/ttyACM0.

Nem értjük egymást.
Valami olyasmi kellene, hogy elinditok egy programot,
felparaméterezve (melyik port, input, output, stb.)
és standard output-on jön a válasz.

Tehát akkor neked nem az eszköz küldözget időnként adatot, hanem te kérdezed le az eszköz bizonyos adatait. Ez esetben mondjuk küldessz egy bájtot ki, és válaszol rá egy értékkel. Ezt leprogramozni mind hardver mind szoftveroldalról nem túl bonyolult.

Setseriallal beállítgatod a baudértéket paritást, miegymást, majd simán echo parancs_byte > /dev/ttyACM0 a byteküldés a figyelés meg simán mehet cattal felparaméterezve. Persze ennél trendibb írni rá egy pár soros C programot.

Ha a külső kütyü a ">" jellel beleírtakra mintegy válaszolva ír a soros vonalra valamit, azt megkapja a következő "cat" az adott soros vonalról? Az nem baj itt, hogy közben (valószínűleg) volt close/open a háttérben?

Az hogy mikor érkezik vissza az adat azt te írod meg a firmwareben.

Az világos, de ha ilyen módon "lemarad" a script futása a válaszról, akkor ez ezek szerint probléma lehet. Mert akkor talán mégis csak egészségesebb lenne valami programnyelven írni egy inci-finci lekérdezőt, vagy nem?

Így van.

Nem akarlak dolgoztatni, jól gondolom, hogy kell csinálni?
Tegyük fel, hogy megvan a USB-s PIC kapcsolás a fent emlitett helyről.
A Microchip-es C példát/mintát átírom úgy, hogy egy adott input hatására a nekem tetsző outputot generálja
Linux oldalon. (Brrr, azt reméltem, megmenekülök a C-ben programozástól :bummafejbe: )
MPLAB-ban lefordít, betölt.
Linuxon cdc-acm modul betölt, és a /dev/ttyACM0 device-re ráakasztok valami programot.
Van amúgy shellscript példa, úgy, ahogy én nem szeretem. (Fájlba ír és, annak a végéről kell leszedni az eredményt, brrrr. De ne igényeskedjek, ha én sem szeretek programozni.)

Asszem, ez a "lemaradás" kezelhető perl ill. expect script-tel. Expect lesz, jóval egyszerűbb, beszámolok, ha eljutok addig...

A kapcsolás adott, azt hogy hogy kötöd rá az érzékelőidet azt te tudod. A firmwaret módosítod, hogy ezek adatait mikor hogyan küldje ki. Olvasd el Gory cikkét a témában az segít. Ha az acm modul be van töltve meg minden klaffol a PC oldalon akkor a /dev/acm0 úgy kezelendő mint egy soros port. Azt meg ízlés szerint lehet sokféleképpen.

Ó, nem ismertem ezt a cikket, köszi!

Még linuxig nem jutottam a projecttel, de Windózon már működik a CDC-s USB IO. Találtam egy kész holmit, 8 digitális in, 8 digitális out, 8 analóg in. Sikerült lefordítani, Nekem igy megfelel, egyelőre, a lustaságom győzött.
Lehet, másokat is érdekel, megtalálható itt
A soros kommunikációja egyszerű, mondhatni primitív, de a célnak megfelel. A tőlem még lustábbaknak mellékelve a hex. Éredekes, a bootloaderes módon nem tudtam müködésre birni, de a "normál" módban igen. A mellékelt hex is "nem bootloaderes".
Lucifer, kösz a segítséget!

Hurrá, linux alatt is megy!
Van egy linuxos USB bootloader is, Bővebben: Link
Majd megirom, megy-e.

További linuxos infok.

A linuxos bootload betöltő müködik. De aztán rájöttem,
hogy ICD2-vel még egyszerűbb az élet.

A hétvégén hsználható eredményig jutottam linux alatt használható IO ügyben. Leirom az alábbiakban talán valaki fel tudja használni a tapasztalataimat.
Tehát a kapcsolás: http://www.sixca.com/eng/articles/usbdaq/index.html

A rajzon nyilvánvaló hibák vannak. 470p helyett 470n kell, tovbbá valami tápfesz szűrés is kellene, nálam 100n paralell 1µF van.

Az eredeti firmware: http://www.sixca.com/eng/articles/usbdaq/usbdaq.zip
Nekem nem felelt meg, a következő módosításokat csináltam:
- a digitális bemenet binárisan adja vissza az értéket, könnyebb dekódolni.
- a bináris kimenet (*Axx) parancs ad vissza értéket, mgát a parancsot "echozza" így meggyőződhetunk, hogy tenyleg kiment a parancs, és könnyebb a kezelő programot megirni, lásd lentebb.
- egyébként nem a fenti MPLAB projectet használtam, hanem a MICROCHIP CDC framework-öt, és csak a user.c-t kell kicserélni. A részletekről a cikkben:
http://pic.hobbielektronika.hu/cikkek/pic18f4550_usb_utmutato_iii.html
A módosított user.c-t mellékelve találod.

Az USB-CDC-s hardvert a linuxom (Feadora Core 5) felismeri, betöltődik a cdc_acm modul, és létrejön a /dev/ttyACM0 device.

Ennek kezelelésére expect-et használok, véleményem szerint az ilyen kérdés-válasz kommunkációra ez a legegyszerűbb.
Alant a program

Olvashatatlan volt a kód, itt komment nélkül

#!/usr/bin/expect
set port ttyACM0
set timeout 1
set argc [llength $argv]
if { $argc < 1} {
exit
}
log_user 0
if {[ file exists /dev/$port ]} {
} else { puts "tty cannot be opened"
exit 1
}

spawn -open [open /dev/$port RDWR]

set command [lindex $argv 0]
send "$command\r"

expect {
timeout {
puts "tty response timed out"
exit 1
}
"\r"
}

puts $expect_out(buffer)
close
exit
>