Ja, då var man 15st bluetooth-moduler (class 2) rikare

[AsmN]

Bit-banging är när man "tillverkar" t.ex. en serieport i mjukvara. Dvs. mjukvaran gör att timingen är riktig (baud rate) och sätter till start- och stopbit(ar). M.a.o. allt som en hårdvaruport vanligen gör. På utsidan ser allt lika ut, man använder fortfarande en pin som TX och en annan som RX.

Att polla är när man regelbundet läser av ett register till en serieport för att se ifall ny data kommit in. Ett bättre alternativ istället för att polla är ju att använda interrupt.

[evert2]

Oookay...

[Erik_L]

Jag har en liknande tanke, att göra en RFCOMM -> RS232. Det är synd att det inte görs små billiga uC med dubbla UART för just sånt här (vad jag vet). Det blir väl att bit-banga. Möjligen skulle man kunna göra sig en UART i en liten CPLD och sätta bredvid

En annan möjlighet är ju att använda T.ex en ATTiny2313 med USI och UART ( ~50kr på elfa ) och en MAX3100 ( SPI -> UART ) .

/Erik

[Eagle]

Mega162 har 2st UART

[mikma]

Jag har anslutit en modul till en dator med Linux nu. Tyvärr har jag inget att testa den mot för tillfället, men drivrutinen verkar fungera.

Kommandon för att ansluta på första serieporten:

Kod: Markera allt

hciattach /dev/ttyS0 ericsson 57600
hciconfig hci0 up

Informationen från hciconfig:

Kod: Markera allt

# hciconfig -a
hci0:   Type: UART
        BD Address: 00:80:37:15:96:94 ACL MTU: 672:10  SCO MTU: 64:0
        UP RUNNING PSCAN ISCAN
        RX bytes:128 acl:0 sco:0 events:15 errors:0
        TX bytes:322 acl:0 sco:0 commands:15 errors:0
        Features: 0x07 0xea 0x31 0x00 0x00 0x00 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV3
        Link policy:
        Link mode: SLAVE ACCEPT
        Name: 'skinner-0'
        Class: 0x000100
        Service Classes: Unspecified
        Device Class: Computer, Uncategorized
        HCI Ver: 1.1 (0x1) HCI Rev: 0xb LMP Ver: 1.1 (0x1) LMP Subver: 0x300
        Manufacturer: Ericsson Technology Licensing (0)

# hciconfig hci0 revision
hci0:   Type: UART
        BD Address: 00:80:37:15:96:94 ACL MTU: 672:10  SCO MTU: 64:0

 Generated: 2001-05-09 14:26
 Comment: CXC 125 244 P13B

# hciconfig hci0 features
hci0:   Type: UART
        BD Address: 00:80:37:15:96:94 ACL MTU: 672:10  SCO MTU: 64:0
        Features: 0x07 0xea 0x31 0x00 0x00 0x00 0x00 0x00
                <3-slot packets> <5-slot packets> <encryption> <RSSI>
                <SCO link> <HV3 packets> <u-law log> <A-law log> <CVSD>

[PaNiC]

Hur går det för folk? Någon som lyckas med att använda RFCOMM t.ex.?

[AndLi]

Använda RFCOMM?
Du menar "är det någon som orkat implementera SPD för att sen kunna implementera RFCOMM" så är nog svaret näää I alla fall hos mig...

[Erik_L]

Jag har lite olika sensorer jag skulle vilja kunna läsa av med hjälp av mobiltelefonen.

Skulle vara smidigt om man kunde ansluta dessa BT moduler till mobiltelefonen och sen kunna skicka data mellan dom.

Finns det möjlighet att skriva någon klient el server i Java till mobilen som kommunicerar på en sån låg nivå att man slipper implementera SPD etc?
Eller finns det endast API för att kommunicera på dom högre nivåerna?

[mikma]

Jag kommer nog inte att skriva så mycket mer på min lilla "fusk-stack" innan jag får igång min stationära dator igen (min enda dator med BT).

Så ifall det finns någon som har nytta av koden har jag lagt upp den här:
http://area26.no-ip.org/linked/toothpic.zip

Den är skriven i microchip C18...

Just nu tar den upp c:a 1K programword och 120 byte RAM (inklusive 64 byte stack).

Jag upptäckte ett problem i toothpic när jag portade den till m16c. Enligt "BLUETOOTH SPECIFICATION Version 1.0 B" sid 266 måste båda sidorna skicka L2CAP_ConfigReq och BlueZ i Linux stänger anslutningen om den inte får någon. Jag har lagt till den i samma ACL-paket. I SIG_ConfigRsp användes också fel cid.

/Mikael

Kod: Markera allt

--- toothpic.orig/l2cap.c	2005-02-02 00:53:18.000000000 +0100
+++ /mnt/mulder/var/local/l2cap.c	2005-02-15 16:47:15.000000000 +0100
@@ -1,5 +1,3 @@
-#include "proc.h"
-
 #include "util.h"
 #include "panic.h"
 #include "hci.h"
@@ -8,7 +6,7 @@
 const rom unsigned char echorsp[] = { 0x08, 0x00, 0x04, 0x00, 0x01, 0x00, SIG_EchoRsp };
 const rom unsigned char disrsp[] = { 0x0c, 0x00, 0x08, 0x00, 0x01, 0x00, SIG_DisconnectRsp };
 const rom unsigned char infrsp[] = { 0x0c, 0x00, 0x08, 0x00, 0x01, 0x00, SIG_InfoRsp };
-const rom unsigned char confrsp[] = { 0x0e, 0x00, 0x0a, 0x00, 0x01, 0x00, SIG_ConfigRsp };
+const rom unsigned char confrsp[] = { 0x16, 0x00, 0x12, 0x00, 0x01, 0x00, SIG_ConfigRsp };
 const rom unsigned char connrsp[] = { 0x10, 0x00, 0x0c, 0x00, 0x01, 0x00, SIG_ConnectRsp };
 const rom unsigned char connrsp2[] = { 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00 };
 
@@ -152,11 +150,19 @@
 				HCI_write(id);
 				HCI_write(6);
 				HCI_write(0);
-				HCI_write(HCI_read());
-				HCI_write(HCI_read());
-				len -= 2;
-				cur_size -= 2;
+		HCI_write(BYTE1(cur_scid));
+		HCI_write(BYTE2(cur_scid));
 				for(tmp=4;tmp>0;tmp--) HCI_write(0);
+
+		HCI_write(SIG_ConfigReq);
+		HCI_write(id);
+		HCI_write(4);
+		HCI_write(0);
+		HCI_write(BYTE1(cur_scid));
+		HCI_write(BYTE2(cur_scid));
+		HCI_write(0);
+		HCI_write(0);
+
 				break;
 			}
 
@@ -165,5 +171,8 @@
 
 		}
 	}
-	else HCI_discard(cur_size);	
+    else /* if(cur_cid!=CID_SIGNALLING) */
+	{
+		HCI_discard(cur_size);
+	}
 }

[cyr]

Där ser man, tackar...

Det där med configrequest kände jag iofs till, men min telefon brydde sig inte om att inte få någon.

Väntar på att itbutikken ska få tummen ur och skicka min nya datorlåda så jag kan bygga ihop burken med BT och testa/koda lite mer.

[cykze]

Hmm. Får inte modulen att fungera. Jag har kopplat VCC (C6), VCC_IO (C4), ON (C2) och RESET# (R3) till +3.3V och GND (R1 och R2) till jord. Sen har jag kopplat så här mellan BT-modulen och en MAX3232:a:

Kod: Markera allt

BT            MAX3232
TXD(B5)   -   T1IN(11)
RXD(A5)   -   R1OUT(12)
CTS(B6)   -   R2OUT(9)
RTS(A6)   -   T2IN(10)

Och mellan MAX3232:an och datorns serieport:

Kod: Markera allt

MAX3232         Serieporten
T1OUT(14)   -   RXD(2)
R1IN(13)    -   TXD(3)
R2IN(8)     -   RTS(7)
T2OUT(7)    -   CTS(8)
GND         -   GND(5)

Det tycker jag verkar vara rätt, eller?

Hur ska serieporten vara inställd i datorn?
Hastighet?
Paritetskoll? (ingen, udda, jämn)
Antal bitar?
Antal stoppbitar?
Flödeskoll? (ingen, RTS/CTS, Xon/Xoff)

Jag provar t ex att skicka 0x01, 0x03, 0x0C, 0x00 för Reset, men jag får inget tillbaka. Fipplar jag lite med RESET-pinnen till jord så kan jag framkalla att serieporten läser lite skräptecken, det är allt.

[AndLi]

orginalhastigheten är 57600 8N1
Sätt flödesreglering på hardware

På mitt kopplingsschema har jag lagt dem

CTS(B6) -> 11
TX(B5) -> 10

RTS(A6) ->12
RX(A5) ->9

Vilket verkar som att vi har olika uppfattning om vilket håll RTS/CTS går på.
Tittar du i exempelinkopplinge i databladet på chipet så kan du nog se vem som har rätt....

[mikma]

Det ser ut som du kopplat cts och rts fel. Jag tycker de är felbenämnda i databladet för bt-modulen eftersom cts är en utgång som ska gå till cts på serieporten och rts är en ingång som ska till rts på serieporten. Kopplingen finns i figur A1 i databladet (rok101008_146106r1a.pdf).

[cykze]

Jaså fanns det ett kopplingsschema lite längre ner...

Tack för hjälpen AndLi och mikma.

Nu verkar det fungera lite grann iaf. Fast det verkar fungera väldigt slumpartat. Skickar jag den där Reset-kombinationen (0x01, 0x03, 0x0C, 0x00) så får jag ibland svaret 0x04, 0x0E, 0x04, 0x01, 0x03, 0x0C, 0x00 tillbaka, fast utan den sista byten (0x00). Skickar jag en extra byte dyker dock 0x00 upp. Fungerar väldigt konstigt, minst sagt. Misstänker att det är gtkterm som ställer till det. Får prova med ett annat terminalprogram.

[AndLi]

Låter som nån rycker i flödesregleringen.. ¨Flödesregleringen behövs egentligen inte, se bara till att den in till chippet ligger hög hela tiden så borde det funka bättre.