Dotaz: Ovladani serioveho portu v C

[David Sedláček]

Zdravim. Cely den hledam informace o teto problematice ale stale nic, co potrebuji. K memu problemu: k dokonceni meho programu, ktery bude citat frekvenci z U/f menice na seriovem portu, potrebuji: 1. odecitat stav linky "CTS" 2. zjistit co mi to vlastne vrati za hodnotu

Predem diky.

Odpovědi

[Michal Pokorný]

Co třeba toto pdf by nepomohlo?
http://www.mhatt.aps.anl.gov/dohn/programming/serial/serial.pdf

[Michal Pokorný]

Sakra měl bych si zopakovat HTML! http://www.mhatt.aps.anl.gov/dohn/programming/serial/serial.pdf

[Hrabosh]

Já sem si z dovolením také vzal. Jen ten odkaz ukazuje na tuto diskuzi, ne na to PDFko.

Z.H.

[David Sedláček]

Podle toho jsem postupoval, ale je to horor. Delam s RS232 poprve a je to pro me spanelska vesnice. Jestli je tu nekdo znalejsi, muze zkontrolovat kod. Otestovat jsem to nemohl, prevodnik mi dorazi az za tyden.

#include < stdio.h>
#include < fcntl.h>
#include < termios.h>
#include < sys/ioctl.h>
#include < time.h>


#define SERIAK "/dev/ttyS1"
#define KALIBRACE 1.0
#define DOBA 1000.0
//#define DEBUG
#define JEDNOTKA

int ctsvalue (void);
int frekvence (double brana);


int
ctsvalue (void)
{
	int fd, status;

	fd = open (SERIAK, O_RDWR | O_NOCTTY);

	ioctl (fd, TIOCMGET, &status);

#ifdef DEBUG

	if (fd == -1)
	{
		printf (" nelze inicializovat port");
		goto end;
	}

	else
		printf (" status: %d ", ioctl (fd, TIOCMGET, &status));
#endif

	if ((status & TIOCM_CTS) != 0)
		return 1;
	else
		return 0;
      end:
	close (fd);
}

int
frekvence (double brana)
{
	unsigned long int citac = 0, stary = 0, vstup = 0;
	double elapsed, frekv = 0.0, cas = 0.0;

	do
	{
		clock_t clock ();
		vstup = ctsvalue ();
		if (vstup)
			citac++;
		cas = clock ();

	}
	while (cas < (1000.0 * brana));
#ifdef DEBUG
	printf ("cas: %lf citac: %d ", cas, citac);
#endif
	frekv = (double) citac / brana;
#ifdef DEBUG
	printf ("%d", frekv);
#endif


	return (frekv);

}

int
main (void)
{
	float napeti = 0.0;

	napeti = ((float) frekvence (DOBA)) / 10.0 * KALIBRACE;

	printf ("%d", (int) napeti);
#ifdef JEDNOTKA
	printf (" mV\n");
#endif

	return 0;
}

Jedna se mi zejmena o fci /ctsvalue()/ jestli ji mam spravne. Kdyby mel nekdo generator 1-10kHz, muze to zkusit povesit na seriak "CTS", vystup by mel byt pri 10kHz "1". Radsi bych to resil pres ICQ 319273996, fakt uz mam dost :o).

[Jan Martinek]

Myslím, že tvůj program by celkem fungovat mohl, ale jak jsem si všiml, nepoužíváš ioctl(fd, TIOCMIWAIT, TIOCM_CTS); takže při provozu to zatíží systém na 100%, což není dobrý způsob. Svůj program otestuj kouskem drátku, žádný generátor ani převodník není potřeba. Jestli ti stačí aspoň primitivní generátor, tak použij druhý sériový port na kterém nastavíš baud rate 9600 a pak do něj pošleš střídavě jedničky a nuly. Při správné konfiguraci se TxD bude chovat jako generátor o frekvenci 9600 Hz (nebo polovina?). Kdysi jsem potřeboval měřit časy u hran signálu o frekvenci cca 4kHz a ukázalo se, že je to frekvence příliš vysoká na to, abych to řešil přes sériový port. V tvém případě bych proto doporučoval to připojit spíš na zvukovou kartu a provádět fourierovu transformaci v reálném čase.

[David Sedláček]

Zvukovka by byla asi moc silne kafe :). Ted jsou zkousel kousek dratu (spojit RTS a CTS,pin 8+7). Ukazu na fci nize:

#include < stdio.h>
#include < fcntl.h>
#include < termios.h>
#include < sys/ioctl.h>
#include < time.h>

int
main ()
{
	
//for(;;) {
	int status=0,fd=0;
fd = open ("/dev/ttyS1", O_RDWR | O_NOCTTY);	
ioctl (fd, TIOCMGET, &status);
	printf ("Status: ");
	if (status & TIOCM_LE)
		printf ("DSR ");
	if (status & TIOCM_DTR)
		printf ("DTR ");
	if (status & TIOCM_RTS)
		printf ("RTS ");
	if (status & TIOCM_CTS)
		printf ("CTS ");
	if (status & TIOCM_CAR)
		printf ("DCD ");

	printf ("\n");
//}



return 0;
}

Kdyz nepouziji cyklus for, vse se vypise uplne spravne (v zavislosti na propojeni - hodnoty seriaku) a program se ukonci. Jenze pokud necham program cyklit a stridave spojuji a rozpojuji kontakty CTS a DTR, hodnoty se nemeni a program vraci stale to same, jako pri spusteni, proste nereaguje na spojeni a rozpojeni, coz je asi kamen urazu toho predchoziho programku = asi nebude fungovat :(. Jenze me uz nenapada nic, co bych poupravil, aby to fungovalo.

[Jan Martinek]

Bohužel se mi právě polámal notebook se sériovým portem, takže nemůžu dělat pokusy
Moc se mi ale nelíbí, že v té nekonečné smyčce port pořád otevíráš, a nikdy nezavíráš. Otevři ho jen jednou na začátku.

[David Sedláček]

OK. Dik za upozorneni. Trochu jsem (hlavne diky tobe) pokrocil a zitra sem postnu /snad/ fcni program. Uff

[David Sedláček]

/*	2005. written for reading voltage from optical link iface	*/
/*	Ronja by U/"f convertor AD654. Program doesn't coming under any	*/
/*	lincense or warranty. If you have any questions, let write them	*/
/*	to me sith@wifistar.net. Mny thks to J. Pribramsky for his help	*/

#include < stdio.h>
#include < fcntl.h>
#include < termios.h>
#include < sys/ioctl.h>
#include < time.h>


#define SERIAK "/dev/ttyS1"
#define KALIBRACE 1.0
#define DOBA 10.0
//#define DEBUG
//#define JEDNOTKA

int ctsvalue (int fd);
long frekvence ();

int
ctsvalue (int fd)
{
	int status;

	ioctl (fd, TIOCMGET, &status);

#ifdef DEBUG

	if (fd == -1)
	{
		printf (" nelze inicializovat port");
		goto end;
	}

#endif

	if ((status & TIOCM_CTS) != 0)
		return 1;

	else
		return 0;
      end:
}

long
frekvence ()
{
	double cas = 0.0;
	long tiku = 0;
	clock_t start, end;

	int fd = open (SERIAK, O_RDWR | O_NOCTTY);

	start = clock ();	// stav hodin pred spustenim citace

	do
	{
		if (ctsvalue (fd))	// pokud CTS Hi
		{
			tiku++;
			while (ctsvalue (fd)) ;	// cekam na CTS Low.
		}

		end = clock ();

		cas = ((double) (end - start));	// celkovy cas mereni

	}
	while (cas < CLOCKS_PER_SEC);	//... pocet tiku/sec

	close (fd);		//zavri seriak

	return tiku;		// frekvence v Hz
}


int
main (void)
{
	double napeti = 0.0;

	napeti = (frekvence ()) / DOBA * KALIBRACE;

	printf ("%lf", napeti);

#ifdef JEDNOTKA

	printf ("mV\n");

#endif

	return 0;
}

[Jan Martinek]

Principiálně to asi fungovat bude, ale dost možná, že by stálo za zvážení použít
ioctl(fd, TIOCMIWAIT, TIOCM_CTS);
což je funkce, která bude čekat, dokud se nezmění stav CTS. Již jsem o tom psal dříve, že se tímto způsobem lze vyhnout 100% zátěži procesoru.

Dále se mi moc nezdá, že tvůj program měří, kolikrát se změní CTS za určitou časovou periodu (za sekundu). Frekvenci bys změřil přesněji, kdybys logiku obrátil a raději změřil, jak dlouho trvá daný (celistvý) počet period. Ale stejně mi přijde, že je tam nějaká chyba, například cas je úplně zbytečně double.

A k čemu vlastně slouží konstanty DOBA a KALIBRACE? Pouze jsem našel, že se mezi sebou násobí, ale kód pravděpodobně ještě není hotový, že?

Také jsem si všiml, že kdybys zapnul DEBUG, tak se ve funkci ctsvalue() může stát, že nikdy nedojde k příkazu return, což je dost chyba.

Každý programujeme jinak, ale asi bych část kódu

	if ((status & TIOCM_CTS) != 0)
		return 1;

	else
		return 0;

nahradil jediným řádkem
return (status & TIOCM_CTS);
ale to je otázka vkusu.

Další drobnost jsem našel ve fci ctsvalue(): sice kontroluješ, jestli se deskriptor nerovná -1, ale příliš pozdě, protože už jsi se pokusil na něj aplikovat ioctl(). Dle mého názoru by bylo dobré tuto kontrolu napsat hned za otevření portu. Když se něco nepovede, tak bývá zvykem vracet -1, což bych doporučoval.

A když už jsme u těch chyb, tak zkus k hlášce "nelze inicializovat port" vypsat také důvod, proč se to nepovedlo. Lze to například takto:
printf("%s\n", strerror(errno));

Také jsem našel, že převodník AD654 používá daleko vyšší frekvence než 10kHz. Ty tam budeš mít nějaký dělič?

A co kdybys použil jednočipový mikropočítač, který má AD převodník a komunikuje přes sériový port běžným způsobem? Měl bys to přesnější, jednodušší, levnější a nežralo by to tolik CPU.

Ať tak či tak, držím palce!

[Petr Jelínek]

Ten jednočip by asi byl nejlepší. A měření délky přesně definovaného počtu period by asi taky bylo vhodnější - i na tom jednočipu. Ty krámy dneska stojí do stovky a programovat pro ně i v C není problém. Mám například dobré zkušenosti se SDCC.

[David Sedláček]

Jednocip neumim, ale uz mam objednan AT90S2313, diky jednomu zdejsimu clanku . Popr. k A/D prevodniku uz mam take napsany program, ale ty uz bohuzel nejsou zadarmo, proto prisel v uvahu U/f .

DOBA byla jeste v puvodnim zdroji, nejak to tam zustalo a melo to fungovat jako nastaveni rozliseni (ruzne dlouhe intervaly mereni, pro vetsi presnost) - asi to predelam, napr. zmeny na CTS detekovat xkrat, z toho vysledek.

KALIBRACE slouzila opravdu jako kalibrace mereni - prevodnik bude pracovat ve venkovnich podminkach a rozdil teplot pak pusobi na keramiky (asi i na samotny prevodnik), jestli se nepletu. Ta se ale nahradi foliovym kondenzatorem.

Chyba v ctsvalue() je mi znama byl to zbytek. AD654 kmita az na 500kHz, coz na seriaku nezmerim - piny 6,7 se da pomoci C ovlivnovat kmitocet: 10n / 10kHz / 1V.

Dekuji za TIOCMIWAIT, nikde jsem na to nenarazil, opravdu se to velmi libi .

/*	2005. written for reading voltage from optical link iface	*/
/*	Ronja by U/"f convertor AD654. Program doesn't coming under any	*/
/*	lincense or warranty. If you have any questions, let write them	*/
/*	to me sith@wifistar.net. Mny thks to J. Pribramsky for his help	*/

#include < stdio.h>
#include < fcntl.h>
#include < termios.h>
#include < sys/ioctl.h>
#include < time.h>

#define SERIAK "/dev/ttyS1"
//#define DEBUG
//#define JEDNOTKA

int ctsvalue (int fd);
long frekvence (int fd);

int
ctsvalue (int fd)
{
	int status;

	ioctl (fd, TIOCMGET, &status);

	return (status & TIOCM_CTS);
}

long
frekvence (int fd)
{
	int tiku = 0, cas = 0;
	clock_t start, end;

	ioctl (fd, TIOCMIWAIT, TIOCM_CTS);	//az Hi

	start = clock ();	// stav hodin pred spustenim citace

	do
	{
		if (ctsvalue (fd))	// pokud CTS Hi
		{
			tiku++;
			while (ctsvalue (fd)) ;	// cekam na CTS Low.
		}

		end = clock ();

		cas = (end - start);	// celkovy cas mereni

	}
	while (cas < CLOCKS_PER_SEC);	//... pocet tiku/sec



#ifdef DEBUG

	printf ("Pocet tiku:%d ", tiku);

#endif

	return tiku;		// frekvence v Hz
}


int
main (void)
{
	int napeti = 0;

	int fd = open (SERIAK, O_RDWR | O_NOCTTY);

	if (fd < 0)
	{
		printf ("Port \"%s\" nelze zinicializovat.", SERIAK);
		return 0;
	}

	napeti = (frekvence (fd)) / 10;

	printf ("%d", napeti);

#ifdef JEDNOTKA

	printf ("mV\n");

#endif

	close (fd);		//zavri seriak

	return 0;
}

[David Sedláček]

Prikladam kod pro A/D prevodnik. V praxi to funguje, kritika je vitana. Zejmena k fci wait() - lze to udelat lepe?

//      radsi to zatim nigdo nezkousejte naostro, pac chybi:
//      -dopsat delay v mereni()
//      -dodelam jak budu mit chut, sith @ wifistar . net

#include < stdio.h>
#include < fcntl.h>
#include < termios.h>
#include < sys/ioctl.h>
#include < time.h>

#define SERIAK "/dev/ttyS1"

void power (unsigned short level);
int openserial ();
void closeserial ();
void RTS (unsigned short level);
void DTR (unsigned short level);
int CTS ();
float mereni ();

int fd;

void
power (unsigned short level)	//napajeni pro prevodnik
{
	int status;

	ioctl (fd, TIOCMGET, &status);
	if (level == 0)
		ioctl (fd, TIOCSBRK, &status);
	else
		(fd, TIOCCBRK, &status);

	ioctl (fd, TIOCMSET, &status);

}

int
openserial ()			//otevrit seriak
{
	if ((fd = open (SERIAK, O_RDWR)) == -1)
	{
		return 0;
	}
	return 1;
}

void
closeserial ()			//zavrit seriak
{
	close (fd);
}

void
RTS (unsigned short level)	//nastav stav RTS
{
	int status;

	ioctl (fd, TIOCMGET, &status);

	if (level)
	{
		status |= TIOCM_RTS;
	}
	else
	{
		status &= ~TIOCM_RTS;
	}

	ioctl (fd, TIOCMSET, &status);
}

void
DTR (unsigned short level)	//nastav stav DTR
{
	int status;

	ioctl (fd, TIOCMGET, &status);
	if (level)
	{
		status |= TIOCM_DTR;
	}
	else
	{
		status &= ~TIOCM_DTR;
	}

	ioctl (fd, TIOCMSET, &status);
}

int
CTS ()				//stav CTS
{
	int status;

	ioctl (fd, TIOCMGET, &status);
	//ioctl (fd, TIOCMIWAIT, TIOCM_CTS);

	return (status & TIOCM_CTS);
}

void
wait (int wait)			//cekej x ms
{
	int cas;
	clock_t start, end;

	wait *= 0.001;

	start = clock ();

	do
	{
		end = clock ();

		cas = end - start;
	}
	while (cas < (CLOCKS_PER_SEC * wait));
}

float
mereni ()			//hlavni fce, mereni napeti
{
	RTS (1);		//CS

	int status, bity = 128, cas = 0, hodnota = 0, i;	//bity tzn jake rozliseni ma prevodnik 2^x
	float mereni = 0.0;

	wait (20);		//x msec

	RTS (0);		//CS

	for (i = 0; i < 8; i++)	//konecne hot stuff ;)
	{
		if (CTS ())
			hodnota += bity;

		DTR (0);	//clock

		DTR (1);	//clock

		bity /= 2;

		wait (20);
	}

	return (mereni = (float) hodnota / 50.0);
}

int
main ()
{
	float napeti = 0.0;
	short unsigned i;

	if (!openserial ())
	{
		printf ("Nelze inicializovat port \"s\".", SERIAK);
		return 0;
	}
	power (0);		//txd break on

	wait (10);

	DTR (0);		//clock

	RTS (0);		//CS

	wait (10);

	for (i = 0; i < 40; i++)
	{
		napeti += mereni ();
	}

	wait (10);

	napeti = (napeti * 1000) / i;

	printf ("\r%d mV", (int) napeti);

	power (1);		//txd break off

	closeserial ();

	return 0;
}

[Jan Martinek]

Ahoj, jestli ti to nevadí, tak se zase pokusím tvůj kód trochu okomentovat. Především jsi se ptal na funkci wait(). Ta má asi počkat daný počet milisekund. Mohl jsi si ušetřit práci, protože již existuje funkce usleep(), která to umí (údaj požaduje v mikrosekundách). Její výhodou je, že zbytečně nezatěžuje systém.

Také vidím, že v kódu používáš "unsigned short". Pravděpodobně chceš datový typ o osmi bytech (bajt). Nejsem si jistý, jestli je vždy zárukou, že "unsigned short" bude mít vždy 8 bitů. Co třeba na 64bitové platformě? Doporučoval bych raději buď "unsigned char" nebo "uint8_t" (je definován v hlavičkovém souboru stdint.h).

Co se týče tvých funkcí RTS() a DTR() - není nutné v nich zjišťovat stav bitů. Pro tento účel je vhodnější použít volání TIOCMBIS/TIOCMBIC, které nastaví/nuluje příslušné bity. Například
ioctl(fd, TIOCMBIS, &TIOCM_DTR); /* nastaví DTR */
ioctl(fd, TIOCMBIC, &TIOCM_DTR); /* nuluje DTR */

Při selhání vypisuješ málo informací, ale to jsem psal už v předchozím příspěvku. Asi to tak chceš mít, co se dá dělat.

K čemu je ve funkci main() dobré to druhé volání wait(10) ? Zbytečně to zdržuje, no ne?

Mohl bys vysvětlit funkci power()? Odkud vlastně bereš napájení? Někde tam vypadlo "ioctl". K čemu je tam to TIOCSBRK?

Pak mě napadá ještě pár dalších prkotin, například že dělení ve funkci mereni() lze nahradit bitovým posunem, a v téže funkci by ses mohl úplně obejít bez proměnné i. O návratových hodnotách jsem psal už minule - teď opravdu skřípu zuby, když vidím, že funkce openserial() vrací nulu, když se něco pokazilo a jedničku, když je vše v pořádku. Proč to neudělat jak je zvykem? Ve funkci main() přetypováváš na int - to ale vždy zaokrouhlí směrem dolů, což se v této situaci nehodí.

Napiš prosím, jaký AD převodník používáš. Díky.

[Semo]

Dobry den,

Prave programujem nieco, co komunikuje s AD prevodnikom, ktory je pomocou cipu USB-serial konvertoru FTDI FT245BM prijeny na USB na pocitaci.

Problem je, ze ked citam z /dev/ttyUSB0, tak to PRISERNE zatazuje system. Load po minute nastupa nad 10. Programom to nie je, podobne destruktinve ucinky ma aj "cat /dev/ttyUSB0".

Skusil som nastavit ioctl(fd, TIOCMIWAIT, TIOCM_CTS), trocha sa to zlepsilo, ale nestaci to. Prevodnik sype data az 100kB/s.

Nemali by ste v zalohe nejaky tip, ktorym smerom mam hladat, alebo co by som asi mal nastavit? Okrem spominaneho ioctl nenastavujem nic. Pomohlo by nastavit nejaky baudrate? Ak ano, aky? Najblizsi vyssi standartny?

Mozno ain driver nie je idealny, ak za behu vytiahnem AD prevodnik z usb portu (po tom, co som z neho nieco precital), tak sa mi hryzne pocitac, rovnako sa prejavi pokus o odstranenie modulu.

Navyse mojmu programu sa podari zavolat open() iba raz, dalsie spustenie programu nekonecne vytuhne na spominanom ioctl. Ak ho odstranim, tak neprejde cez fread (Illegal seek).

Dik

[David Sedláček]

Samozrejme mi to nevadi, jsem rad. Protoze tohle jsou jedine kloudne a ucelene informace, co jsem na internetu o teto problematice nasel.

K čemu je ve funkci main() dobré to druhé volání wait(10) ? Zbytečně to zdržuje, no ne?

Puvodne to mela byt jakasi doba zotaveni ad prevodniku, ale funguje to i tak, bez toho.

Co se týče tvých funkcí RTS() a DTR() - není nutné v nich zjišťovat stav bitů. Pro tento účel je vhodnější použít volání TIOCMBIS/TIOCMBIC, které nastaví/nuluje příslušné bity. Například
ioctl(fd, TIOCMBIS, &TIOCM_DTR); /* nastaví DTR */
ioctl(fd, TIOCMBIC, &TIOCM_DTR); /* nuluje DTR */

Supr, zase dalsi zrychleni prace..

Mohl bys vysvětlit funkci power()? Odkud vlastně bereš napájení? Někde tam vypadlo "ioctl". K čemu je tam to TIOCSBRK?

Zkousel jsem to z TxD pinu, ale nestacilo to, napeti bylo male a ad prevodnik nefungoval korektne - jediny volny vystupni pin. A zapojovat shift registr se mi nechtelo . TIOCSBRK nahodi txd na log 0, TIOCCBRK na log 1 - BREAK.

0k, pro priste uz to bude podle obvyklych pravidel :o). S RS232 delam tyden, takze to skalopevne vryto do pameti zatim nemam. Prevodnik ma oznaceni TLC549 a je 8bit, v GM asi 60Kc. Je to moc draha sranda a oproti attiny, co jsem vcera konecne koupil, fakt nepomer.

[Smisek]

Ahoj, oživuji téma jelikož řeším stejný problém, tento céčkový prográmek jsem si zkompiloval, ale i když spojím v rs232 kontakt např. mezi CTS a DTR tak se nestane nic. Hodnoty jsou stále stejné, tedy jsou to tyto: LE 1, DTR 2, RTS 4, CTS 32, CAR 64

Používám Ubuntu 12.10 Linux 3.5.0-29-generic, ale rs232 port je v pořádku, jelikož jej jinak používám s home-brew ir receivrem pro dálkové ovládání.

ls -lart /dev/ttyS0
crw-rw-rw- 1 root dialout 4, 64 May  9 00:53 /dev/ttyS0

Můžete mě nakopnout kupředu? :D Plácám se v tom.

[Tom]

Nejpraktictejsi mi prislo Serial Programming Guide for POSIX Operating Systems, viz kapitola 4, odstavec "Getting the Control Signals". Pak jsem jeste narazil na linuxove Serial Programming HOWTO, ale to mi tak dobre neprislo.

Tomas

[Jiří Daněk]

Já nyní řeším podobný problém: chtěl bych si blikat laserovou diodou, eventuelně vyrobit i přijímač a přenášet data. Jen by mě zajímalo, jestli je možné nějak systému vnutit svoje zařízení jako síťový adaptér (další eth zařízení, nebo tak). Zatím jsem studoval jenom diody, mohli byste mi poradit nějakou dokumentaci k tomu síťování.

PS: možná by šlo použít SLIP...

Díky za každou pomoc, Jirka.

[trekker.dk]

Pro sériový port najdeš na netu spoustu návodů: Serial HOWTO, tady na abclinuxu vyšel článek Sériová komunikace pod Linuxem (link).

Na blikání diodou by se dal použít i paralelní port, v nějaké diskuzi tady je odkaz na prográmek, ale když jsem ho hledal, tak jsem ho nenašel. Aspoň něco je k nalezení tady.

Nevím, co máš na mysli tím přijímačem, ale pokud by to mělo být zařízení s mikroprocesorem, tak bych nadhodil třeba tohle - má sériový port přímo integrovaný a o práci s ním tady taky vyšel článek (link)

S tím síťovým adaptérem ti bohužel neporadím - zatím jsem to nepotřeboval řešit

P.S.: Místo oživování staré diskuze jsi klidně mohl založit novou

[Jan Martinek]

Blikání diodou (přes DTR a RTS) se tu řešilo včera v tomto vláknu: http://www.abclinuxu.cz/forum/show/125546

Ale tam byla řeč o stavových linkách. Přenos dat je něco trochu jiného - na to se používá RxD a TxD a jestli tam dáš dráty nebo diody, je čistě hardwarová věc. Jako síťové zařízení SLIP (nebo cSLIP) samozřejmě funguje, ale v poslední době se dává spíš přednost PPP, protože toho umí víc.

[Jiří Daněk]

Jak diodu rožnout vím už dávno, mě by spíš zajímalo, jak počítač přesvědčit, aby přes seriový port vytvořil spojení s druhým compem. PPP se podle mého používá na komunikaci s modemem, ale já žádný modem nemám. Navíc asi potřebuje víc drátků kabelu, než jeden na odesílání a jeden na příjem...

Na každé straně bych chtěl mít na jednom výstupním pinu neustále 0 jako referenci, dalším budu přenášet data a pro třetí zatím žádné využití nemám. V případě vstupu chci na jednom data přijímat (spojovat výstupní s nastavenou 0 s tímto). To stejné u druhého počítače.

[trekker.dk]

Na každé straně bych chtěl mít na jednom výstupním pinu neustále 0 jako referenci

Ta už tam je na pinu 5, viz http://rs232.hw.cz

Jinak chápu to dobře, že chceš mít vstup i výstup na stejném pinu? Z těch obrázků bych totiž řekl, že obyčejný sériák nemá žádný obousměrný pin.

[Jan Martinek]

Jak to uděláš hardwarově už záleží na tobě, hlavně se musí křížově spojit RxD a TxD.

Ale PPP bych rozhodně nedegradoval na něco, co jen komunikuje s modemem. Modem je ve skutečnosti pouhý MODulátor/DEModulátor a pro komunikaci přes PPP ho vůbec nemusíš mít. PPP (Point to Point Prokocol, RFC 1661) je prostě linkový protokol, nad kterým může fungovat přenos IP paketů.

SLIP pro běžné účely stačí, ale dnes už je to trochu exotika.

[Jiří Daněk]

Mohu se zaptat, jestli PPP používá jenom RxD a TxD? Pokud ano, nemusím už řešti skoro nic dalšího.

"Jinak chápu to dobře, že chceš mít vstup i výstup na stejném pinu? Z těch obrázků bych totiž řekl, že obyčejný sériák nemá žádný obousměrný pin."

Nechci, a ani já nevěřím v existenci obousměrných pinů. Ty výstupní piny jsou tři, vstupních je 5 (počítám i stavové), pinů mám víc než dost.

Na každé straně bych chtěl mít na jednom výstupním pinu neustále 0 jako referenci

Ta už tam je na pinu 5, viz http://rs232.hw.cz

To chcete říct, že na 5. pinu je 12V a když ho spojím s RxD, bude to bráno jako příchod signálu?

[trekker.dk]

To chcete říct, že na 5. pinu je 12V a když ho spojím s RxD, bude to bráno jako příchod signálu?

Já jsem pochopil 0 jako 0V, moje chyba. Takže připojení pinu 5 na RxD samozřejmě jako příchod signálu bráno nebude.

Nicméně nechápu, na co tu referenci? AFAIK se signál vyhodnocuje proti nule/zemi. Pokud budeš navrhovat své vlastní zařízení, tak to teda můžeš udělat, jak chceš, ale na straně počítače ti ta reference IMHO nebude k ničemu.

[Jiří Daněk]

Nicméně nechápu, na co tu referenci? AFAIK se signál vyhodnocuje proti nule/zemi. Pokud budeš navrhovat své vlastní zařízení, tak to teda můžeš udělat, jak chceš, ale na straně počítače ti ta reference IMHO nebude k ničemu.

Já budu používat laserové diody a dioda potřebuje napájení 2,5V (zhruba) z povolenou odchylkou 0.25V v obou směrech. Seriový port používá 12V (u notebooku 6V). Ve svém obvodu prostě nebudu mít zdroj 12V. Jde to vyřešit nějakým MAXem (takto jsem to už viděl na jakýchsi anglických stránkách), nebo na jednom výstupním pinu mít neustále 12V a v případě příchodu signálu na fotodiodu tento pin propojit (pomocí tranzistoru) s RxD.

A dále: myslíte si, že by bylo výhodné použít TUN? Na počítači bych nechal běžet proces, který vyčítá seriový port a data chrlí do /dev/tun (a naopak).

A jak se liší jaderný modul od obyčejného programu (komunikujícího se seriovým portem a tun zařízením)? Pokud by rozdíly nebyly příliš velké, nevidím jedniný důvod, proč si nevytvořit modul.

[trekker.dk]

Jo takhle, ty chceš udělat přijímač/vysílač, který by propojil dva sériové porty opticky.

Jestli jo, tak bych udělal zapojení z této stránky, obrázek vlevo. Mám na mysli propojit 7 a 8, z 3 ovládat vysílací diodu a na 2 napojit přijímací obvod. Takhle zapojené by to dokonce mohlo chodit ve full-duplex.

Problém bude s tím napájením - standardní chování je, že na RTS i DTR je log.1, pokud je port otevřený pro čtení. Podle mě by tady bylo nejjednodušší zkusit kladné napětí vytáhnout odněkud z počítače nebo z druhého portu, pokud ho tvoje deska má.

Tím by nebylo potřeba měnit nic na standardním chování toho portu a stačilo by použít PPP. Vyčítat data z portu a posílat na /dev/tun by asi šlo, ale přijde mi to jako škrábání se levou rukou za pravým uchem.

Jaderný modul, pokud bys ho uměl udělat, by vyřešil problém s napájením. Místo standardního chování by sis mohl nastavit třeba log.0 na RTS a log.1 na DTR bez ohledu na to, jestli port vysílá, přijímá, nebo obojí.

[Jiří Daněk]

PPP použít nemůžu (dva procesy namohou mít zároveň otevřený /dev/ttyS0), protože musím mít na jednom pinu neustále 12V kvůli nahrazení MAXu, který rozhodně použít nechci. A na druhý port nejspíš mít nebudu. Co máš proti přeposílání na /dev/tun? Můžu použít vlastní kompresi, kontrolu integrity... Navíc mě se toto řešení líbí. A jakou rychlostí se dá maximálně komunikovat se seriovým portem? Jo a jednou jsem viděl tento kód, mohli byste mi, porsím, odpovědět na nějaké otázky v komentářích?

   int f1,f2,l,fm;

   f1 = open(buf, O_RDWR);

   f2 = open(buf2, O_RDWR);

   fm = max(f1, f2) + 1;  //max vrátí vyšší číslo z předaných


    while(1){

	FD_ZERO(&fds);  // Nestačilo by tento blok volat jen jednou, mimo while? 

        FD_SET(f1, &fds);

        FD_SET(f2, &fds);


	select(fm, &fds, NULL, NULL, NULL);  // Jaký význam zde má to fm?


       // a čtení ...


}

A jak je možné čekat na možnost čtení ze seriového portu? Stačí si třeba jako f1 otevřít /dev/ttyS0? A co pokud si chci hlídat nejen RxD, ale i další stavové piny?

[trekker.dk]

Co máš proti přeposílání na /dev/tun?

Přijde mi to jako pitomost - posuď sám:

1) kernel obslouží událost přijatého byte ze sériového portu a ten byte vybere. Následně oživí tvůj program ze spánku signálem SIGIO

2) program si vybere přijatý byte (nebo víc bytů, pokud kernel bude bufferovat a počká, až toho přijde víc), nějak je zpracuje a pošle na /dev/tun

3) kernel si data přebere a něco s nimi udělá - např. probudí jiný (nebo i stejný) program ze spánku s tím, že přišla data ze sítě; bude přijatá data routovat, apod.

Když použiješ PPP:

1) kernel přijme byte, pak další atd. než z toho seskládá nějaká platná data. Potom udělá to samé, co v bodě 3) v předchozím případě.

Směrováním na /dev/tun přehazuješ data zbytečně tam a zpátky. Navíc ten tvůj program poběží v userspace, takže mu kernel nemusí vždy přidělit systémový čas a objeví se ti tam latence.

Přiznávám, že to nevím jistě, ale mám ten dojem, že při použití PPP bys k tomu zařízení z programu přistupoval jako k síťovému interface ppp0, nikoliv jako k /dev/ttySn.

K tomu kódu: k popisu otevřeného souboru se používá tzv. file descriptor, což je 32bitové celé číslo. To fm je číslo, které odpovídá nejvyššímu file descriptoru předávanému funkci select(), +1

[Jiří Daněk]

A PPP používá jenom piny RxD a TxD?

PPP opravdu vytvoří síťové rozhraní ppp0 - ppp1 atd. ale pak bych nemusel psát žádný program, PPP udělá všechno za mě. Když je seriový port otevřený nějakým programem (nyní ppp), je na pinu 7 log 1, tedy kladné napětí, a proto nepotřebuju vytvářet ani tu svoji referenci - ta už tam bude.

Přeposílání na /dev/tun X PPP:

V případě PPP přece ta část jádra, která kontroluje ttyS0 nemůže běžet neusále, protože by vytěžovala procesor. Takže vyzvednutí bitu se provede až po příchodu přerušení z portu (imho), což je podobné tvému bodu 1. Navíc pppd je proces, který musí jádro probudit a bity mu předat.

PPPd vlastně obshluhuje svá síťová rozhraní, takže musí nějak zapsat do nich a zpracovat je.

Síťové rozhraní je ovládáno kernelem, takže pppd musí předat data jemu

Toto mi přijde velmi podobné k přeposílání. A navíc při použití PPP nebudu ke svému zařízení moci přistupovat vůbec (ne že bych to potřeboval)

[trekker.dk]

A PPP používá jenom piny RxD a TxD?

Předpokládám, že pro PPP se dá použít RTS/CTS řízení toku. To znamená, že když spojíš piny 7,8 na portu podle toho obrázku, na který jsem dával odkaz výš, tak jediné, co budeš muset propojit mezi počítači jsou piny RxD a TxD.

Vyhledej si někde (třeba tady, jak funguje IrDA, z toho pravděpodobně pochopíš víc, než z mýho zmatenýho vysvětlování

...ale pak bych nemusel psát žádný program, PPP udělá všechno za mě.

Jo. Pokud to chceš k něčemu použít, tak si ušetříš práci. Pokud si chceš zkusit, jestli se ti to podaří naprogramovat, tak ti samozřejmě nic nebrání.

To vlastně odpovídá i na to přeposílání - pokud to chceš vyřešit po svém, tak je na tobě, jak to uděláš.

[Zdeněk Štěpánek]

Zdravim

Software pouzij bud PPP nebo mozna trochu jednodussi SLIP, zadnej vtun do toho netahej, leda ze by jsi chtel data jeste komprimovat, ale na to by jednak bylo lepsi reseni nez vtun/openvpn a zadruhe to stejnak pod sebou potrebuje PPP nebo SLIP.

Rozhodne to neres nejakym blaznivym programem v userspace, na tohle jsou uz davno hotove a overene veci.

Co se tyce hardwaru tak se podivej na prvni verzi ronji pro IrDA rozhrani, pred to vraz MAX232, ten ti udela z +-12 peknych 0/5 co ma irda a jedes.

Ale bacha na ruseni, vzduch ti naseka hodne chyb a je docel hloupe to vysilat tak jak to vytece ze seriaku. Tam te parita asi nezachrani

Nebo si rovnou postav ronju, vyjde to mozna lip. BTW ta ma Linkovou frekvenci 10Mhz a jeste je tam modulovaci 1Mhz.

Zdenek

[Jiří Daněk]

Ty moje ledky dokážou blikat frekvencí bízkou k 1000MHh (rožne se za 0,00000001 s a 0.5 - 1ns její jas výrazně kolísá), takže kdybych si sehnal dost rychlý výstup z počítače, mohl bych dosáhnou docela použitelnou rychlost přenosu.

[trekker.dk]

Dost rychlý výstup z počítače je v tomto případě třeba síťová karta, ale rozhodně ne sériový port. V nabídce nastavení u Win98 jsem kdysi sice viděl možnost nastavit něco málo pod megabit, ale když jsem to zkoušel, tak to nefungovalo. V Linuxu mi stty sežere maximálně 115200bps, což stačí tak na hraní her, ale to je tak všechno.

No a pokud bys to dělal přes síťovou kartu, tak si můžeš rovnou postavit nějaký ekvivalent Ronji (protože laserovou diodu ti zákon zakazuje použít venku, i když si přesně nepamatuju, jak to tam přesně bylo formulovaný)

Btw. Pokud se rozsvěcuje za 0,00000001s, tak nemůže stíhat 1000MHz, protože jenom během rozsvěcování by uteklo 10 period.

[Jiří Daněk]

Upřímně: dioda se podle http://www.elektrorevue.cz/clanky/02059/ vyznačuje schopností generace periodické či neperiodické série krátkých impulsů s délkou v rozmezí 10 na -9 až 10 na -10 s, takže i na tu síťovku bych mohl pomýšlet . Akorát já asi nebudu mít tak kvalitní diodu.

A v zákonech na netu jsem nic o laserových diodách nenašel (jan něco o omezení vývozu) a ani tomu moc nevěřím - laserová dioda je součástí laserového ukazovátka a to venku používat můžu.

[trekker.dk]

Ten zákon jsem nadhodil v podstatě jenom jako poznámku - dokud si na tebe někdo nebude stěžovat, tak na tebe těžko někdo naběhne s měřákem. A pokud to budeš provozovat doma, tak už vůbec nemáš co řešit.

Tady jsem něco našel. Laserové záření je v některých zákonech označováno jako neionizující záření.

[Jiří Daněk]

To mě tedy opravdu netrápí.

[Warez]

Toho, kteremu vypalite ocicko to ale trapit bude...

[Antonín Maňák]

A jak to všecho bude implementováno,když potřebujeme ovládat seriový port pod operačním systémem Windows. Máte někdo nějaký zajímavý odkaz na ovládání ser.portu pod WIN?

[Pavel Stárek]

No, to jde o to v čem to chceš programovat. Jde to ve Visual Basicu, v Pythonu, v C/C++, Delphi i v Javě. Hezký popis jak to dělat přímo pomocí Win32 API je třeba zde. A když budeš správně googlit tak si takových popisů a návodu nagooglíš hromadu