OWFS serieportsbekymmer i Linux

[oJsan]

Bakgrund:
Införskaffade för ett tag sedan en HA7S-adapter och lite andra prylar för att sätta upp ett 1wire-nätverk hemma. http://owfs.org/index.php?page=ha7e
HA7S är kopplad till min bubba server (från excito) med en USB<->TTL-kabel från FTDI (TTL-232R-5V).
Med ftdi_sio-modulen laddad dyker alltså serieport /dev/ttyUSB0 upp på servern och dit är min HA7S kopplad.
Servern kör debian lenny och arkitekturen är ARM.

Problemet:
Kör jag via minicom eller cat/echo mot /dev/ttyUSB0 så kan jag kommunicera med HA7S utan problem. Sökning av enheter på bussen fungerar och jag kan göra läsningar/skrivningar till de DS18B20 som sitter på bussen.
Men owfs vill inte... se körningen nedan:

Kod: Markera allt

bubba:/home/jonas# /opt/owfs/bin/owfs --error_level 9 --error_print 0 --ha7e=/dev/ttyUSB0 --allow_other /mnt/1wire/
CONNECT: owfs.c:main(123) fuse mount point: /mnt/1wire/
CONNECT: ow_avahi_link.c:OW_Load_avahi_library(74) No Avahi support. Library libavahi-client couldn't be loaded
CONNECT: ow_dnssd.c:OW_Load_dnssd_library(136) Zeroconf/Bonjour is disabled since dnssd library isn't found
   CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[]
  DEBUG: owlib.c:SetupTemperatureLimits(79) Globals temp limits 0C 100C (for simulated adapters)
   CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[]
DEFAULT: ow_ha7e.c:HA7E_detect(83) Error in HA7E detection: can't perform RESET
CONNECT: owlib.c:SetupSingleInboundConnection(176) Cannot detect an HA7E/HA7S on /dev/ttyUSB0
   CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[]
  DEBUG: ow_com.c:COM_close(93) COM_close: flush
  DEBUG: ow_com.c:COM_close(95) COM_close: restore
  DEBUG: ow_com.c:COM_close(99) COM_close: close
DEFAULT: owlib.c:LibStart(54) No valid 1-wire buses found
  DEBUG: owfs.c:ow_exit(31) owfs: ow_exit(1)

Kikar jag i koden så verkar RESET-sekvensen skicka 'R' på serieporten och sedan vänta på ett CR i retur. Detta misslyckas alltså.

På vilket sätt skiljer sig t.ex. /dev/ttyS0 från /dev/ttyUSB0 ?? En character device borde ju bete sig på samma sätt oavsett om den går via FTDIs adapter, eller? Då servern inte har några serieportar har jag inte kunnat testa hur den beter sig på en "vanlig" serieport. Bubba-servern har en TTL-port någonstans på kretskortet... lyckas jag inte via FTDI's kabel så är det sista utvägen.

Manuell skrivning och läsning till porten fungerar..
detta...

Kod: Markera allt

bubba:/home/jonas#  echo S > /dev/ttyUSB0
bubba:/home/jonas# echo s > /dev/ttyUSB0
bubba:/home/jonas#

resulterar i detta (vilket är förväntat resultat)...

Kod: Markera allt

bubba:/home/jonas# cat /dev/ttyUSB0
47000002BC356028



B80000027063E128

[PHermansson]

Det finns skillnader, en FTDI-kabel kan inte alltid ersätta en serieport. Det jag funderar på mest är varför du inte köpte en USB-adapter istället?

[elf98]

Vad händer om du försöker starta owfs med --ha7s=/dev/ttyUSB0, i stället för --ha7e? Det kanske finns olika switchar av en anledning?

[oJsan]

Vad är det som skiljer dessa emulerade från riktiga serieportar? Eftersom bara RX och TX används (utan flödeskontroll) så borde det fungera tycker jag. När jag gör "echo S > /dev/ttyUSB0" så skickas ett tecken ut på TX-pinnen i inställd baudrate... Vad görs annorlunda i detta mellan de två typerna av serieportar?

Motivering av val:

Visste att den frågan skulle komma, men jag ville inte bloata mitt första inlägg med massor av orelevant info. =)
Anledningen var att jag inte riktigt bestämt mig för vad jag vill koppla adaptern till och dessutom var det ett billigt alternativ att börja med.
Tre alternativ finns för host-alternativ i mitt 1W-nät:
* Koppla mot "stor" Linux-server (läs: vanlig PC)
* Koppla mot liten/embedded Linux-server (läs: bubba server eller WRT54GL)
* Koppla mot uC (mycket liten enhet där jag själv skriver all kod)

Som jag förstått så är USB-adaptern oslagbar för det rena PC-alternativet, men den fungerar mindre bra att koppla till en uC. Eftersom jag redan hade USB-TTL-kabel tillgänglig såg jag en lösning där jag kunde koppla HA7S till valfri typ av server. (till "stor" server med USB-TTL-adapter, till "liten" server med USB-TTL eller direkt via TTL på kretskortet, eller i tredje alternativet direkt till en uC).

[sodjan]

> Det finns skillnader, en FTDI-kabel kan inte alltid ersätta en serieport. Det jag funderar på mest är varför du inte köpte en USB-adapter istället?

Är inte enda skillnaden nivåerna på signalerna ? TTL istället för RS232 ?
Det han använder är ju en "USB-adapter"... (?)

[oJsan]

elf98:
Tack för att du uppmärksammade den bokstaven... lyckades blanda ihop dom någonstans i testandet. Tyvärr fungerar det inte bättre med ha7s Men eftersom ha7e är en RS232-variant så skulle det teoretiskt ha hjälpt då ha7s har färre pinnar än ha7s (inga RTS/CTS osv för flödeskontroll etc.)

Kikar man i felutskriften och i källkoden så ser det spontant inte ut som att de gör någon skillnad på e/s-versionen.

[oJsan]

sodjan: Jag är rätt så säker på att PHermansson syftar på t.ex. DS9490R när han skriver "USB-adapter". Ursäktar om det förvirrar... de som är insatt i 1Wire förstod nog (hoppas jag).

Gällande "en FTDI-kabel kan inte alltid ersätta en serieport" så antar jag att PHermansson syftar på timing-problem, svarstider, handskakning osv. (Bit-banging brukar t.ex. fungera dåligt med USB->serieadapter).
Nivåmässigt (elektriskt alltså) har jag inga problem. Kabeln har 5V logik som HA7S klarar (och den klarar även 3.3V logik om man skulle vilja använda den varianten av FTDI-kabel).

[PHermansson]

Tack för klargörandet Ojsan, det var mkt riktigt 9490:n jag syftade på.
Och det är precis det med timing och annat jag syftar på. Har du testat med en annan dator eller en annan Owfs-version? Det kan ju trots allt vara buggar och sånt också.

[oJsan]

Jag började rota lite i koden och se vilka vilkor som skulle kunna göra att det skiter sig... hitta rätt snart detta stycke i version 2.8p2:

Kod: Markera allt

        if ( BAD( gbRESET( HA7E_reset(&pn) ) ) ) {
                in->Adapter = adapter_HA7E ;
                in->adapter_name = "HA7E/S";
                return gbGOOD;
        }

Lite motsägelsefulla uttryck om man tänker efter... (närmare studie av macron gjorde det mer klart). I 2.8p6 ser koden ut såhär istället:

Kod: Markera allt

	if ( GOOD( gbRESET( HA7E_reset(&pn) ) ) ) {
		in->Adapter = adapter_HA7E ;
		in->adapter_name = "HA7E/S";
		return gbGOOD;
	}

Provade att ändra min source och bygga om den filen/biblioteket - voila! Inga felmeddelanden om HA7E längre... nu verkar det vara problem med fuse istället.. aldrig får man vara nöjd...

Ikväll blir det nerladdning och bygge av nyare source!