Ja, då var man 15st bluetooth-moduler (class 2) rikare
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.
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.
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 ) .cyr skrev: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
/Erik
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:Informationen från hciconfig:
Kommandon för att ansluta på första serieporten:
Kod: Markera allt
hciattach /dev/ttyS0 ericsson 57600
hciconfig hci0 up
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>
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?
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?
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.cyr skrev: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).
/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);
+ }
}
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:
Och mellan MAX3232:an och datorns serieport:
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.
Kod: Markera allt
BT MAX3232
TXD(B5) - T1IN(11)
RXD(A5) - R1OUT(12)
CTS(B6) - R2OUT(9)
RTS(A6) - T2IN(10)
Kod: Markera allt
MAX3232 Serieporten
T1OUT(14) - RXD(2)
R1IN(13) - TXD(3)
R2IN(8) - RTS(7)
T2OUT(7) - CTS(8)
GND - GND(5)
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.

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....
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....
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.

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.