Bluetooth + AVR-Duino

[csabeszq]

Az UART mindig a start bitre szinkronizál, ergo terjesen mindegy, hogy 5 percenként vagy 5 ms-enként küldöd az adatot, ugyanazt kapod.

Az egész matematika:
Első bit 5%-késés, második bit 10%, a harmadik 15%, a nyolcadik 40% késés, paritás 45% késés ha van, a stop bit meg 50% késés.

A probléma az összeadódás miatt van: 5%-os késésnél már az utolsó bit 40%-kal lesz távolabb, mint kellene. Ez a fő probléma és nem az, hogy milyen gyakran küldesz adatot.

Megoldás? Ha spórolni akarsz a kristályon 100 Ft-ot, akkor használj 5 bites kommunikációt, paritás nélkül, 1.5 stop bittel.
Ebben az esetben 25%-os késés, vagy sietés a maximum, ami még mindig brutális, de a 40%-nál azért jobb.

Ha persze kemény fiú vagy és csakazértis RC oszcillátorral akarsz UART-olni, mert ugyebár senki se dumáljon bele abba ahogy az ember UART-ol...
Szóval: a kommunikációt 0xAA jellel kezded, amiből a vevő kiszámolja az egyes bitek között eltelt időt, ebből az UART tényleges frekvenciáját. Beállítod a frekvenciát, megvárod a következő start bitet és más kész is az RC oszcillátoros csevegés.

Vagy: a legelső byte fogadásánál 2400 baudon szoftverből UART-olsz kezdetben és a tényleges idő alapján állítod be a frekvenciát a hardveren.

Mindenesetre számomra a kristály a legegyszerűbb, de minden lehetséges.

[konkav]

Ha persze kemény fiú vagy és csakazértis RC oszcillátorral akarsz UART-olni, mert ugyebár senki se dumáljon bele abba ahogy az ember UART-ol...

jó poén

egyébként viszont nem két vezérlő között kommunikálok ("...amiből a vevő kiszámolja az egyes bitek között eltelt időt..." ahogyan írod), hanem egy bluetooth modullal. ha tudnék futtatni saját kódot a modulon, nem is kéne a mega88

[Robert]

A BlueTooth modul adatlapja elvileg ad toleranciát, hogy meddig mehetsz el....

baud: bit/s+sallangok.
1900 bps = ~1900 bit/s

[konkav]

A BT modul lehet, hogy még érzékenyebb a kódpontosságra. Asszinkron ide vagy oda... Sajna tapasztalat.

na, kipróbáltam két olyan kvarccal, ami 0% hibát ad 19200 baudon (18.432 mhz és 7.3728 mhz). sajna nem lett jobb. vagyis igen, de az még a kvarc előtt volt ( kellett egy 'Config Serialin = Buffered , Size = 32' ).

utána rákötöttem a kvarcot, de nem lett jobb. mindenfélét kipróbáltam, és amíg az 'ischarwaiting' parancsot használtam, nagyon összevissza csinált mindent, és még debugolni sem tudtam. és sokszori olvasás után rátaláltam a _RS_BUFCOUNTR0-ra. így már tudok jól debugolni.

most ott tartok, hogy az AT parancsra válaszol egy AT, új sor, új sor, OK-t
az ATN=valami-re válaszol egy ATN=valami, új sor, új sor, OK-t, és átnevezi a bluetooth kapcsolat nevét.
az összes többi parancsra egyszer visszaküldi, 2 új sor, majd ERROR.
ATE0 a local echo-t kapcsolná ki, de csak errort válaszol. sőt, még az ATN? is errort ad.

egy mobillal kapcsolódtam a bluetooth-hoz, és simán mennek mindkét irányban az adatok. ezért sem értem, hogy az AT és ATN=valami parancsokon kívül más miért nem működik.

[konkav]

A BlueTooth modul adatlapja elvileg ad toleranciát, hogy meddig mehetsz el....

baud: bit/s+sallangok.
1900 bps = ~1900 bit/s

akkor hogy megváltozott a baud jelentése én még olyanra emlékszem, hogy 1 baud az 1 adat átvitele tokkal vonóval (start, stop, paritás és adat bitek)

jav: nem változott meg, csak én voltam a #&@$.

[konkav]

sikerült találnom egy soros portot, így egy kicsit tovább tudtam debugolni. amikor a PC-ről küldöm a parancsokat a BT modulnak, minden működik. minden kérésre érkezik válasz, minden parancsot jól értelmezi a BT. amikor a megát kötöm rá a PC-re, és lefuttatom a progit, a terminál ablakban nem látok hibát. minden parancs, amit a megáról kiküldök, szépen megjelenik a terminálban. ám amikor a megát a BT modullal kötöm össze, a fenti hibát adja (AT és ATN=valami működik, minden más errort ad).
a mega-BT kommunikációba "belehallgatok" a PC soros portjával, és a mega által kiküldött parancsok jól jelennek meg a terminálban (AT, ATH0,ATN?). ha pedig a BT-mega irányban nézem, akkor ezt kapom vissza:

Kód: Egész kijelölése

AT

OK
ATH0

ERROR
ATN?

ERROR

úgyhogy most még kevésbé értem az egészet. ha van valakinek bármilyen ötlete, szóljon mindvégig a megában lévő program teljesen változatlan, így a hiba valahol máshol van, csak nem tudom, hol.

[Robert]

Pedig a BTM-112 ismeri...
Visszhangot kikapcsoltad Bascom alatt?

Kód: Egész kijelölése

echo off

[konkav]

Pedig a BTM-112 ismeri...
Visszhangot kikapcsoltad Bascom alatt?

Kód: Egész kijelölése

echo off

igen. de itt a progi, amivel próbálkozom, hátha segít:

Kód: Egész kijelölése

$regfile = "m88adef.dat"
$crystal = 7372800
'$crystal = 18432000
$hwstack = 64
$swstack = 64
$framesize = 64
$baud = 19200

'Dim Valasz As String * 16
Dim Ize As String * 16
Dim Sorsz As Byte
'Valasz = ""
Ize = ""
Sorsz = 1


Config Serialin = Buffered , Size = 32
Echo Off

Config Pind.0 = Input
Config Pind.1 = Output

Config Lcd = 16x2
Config Lcdpin = Pin , Db4 = Portc.3 , Db5 = Portc.2 , Db6 = Portc.1 , Db7 = Portc.0 , E = Portd.7 , Rs = Portb.0
Config Lcdmode = Port

Declare Sub Sorportolv

Enable Interrupts

Initlcd
Cls
Waitms 500
Locate 1 , 1
Lcd "Tx:"
Locate 2 , 1
Lcd "Rx:"
Clear Serialin
Waitms 1500



Locate 1 , 4
Lcd Sorsz ; "AT   ";
Print "AT" ; Chr(13)
Waitms 1500
While _rs_bufcountr0 > 1
 Call Sorportolv
Wend

Locate 1 , 4
Lcd Sorsz ; "ATH0   ";
Print "ATH0" ; Chr(13)
Waitms 1500
While _rs_bufcountr0 > 1
 Call Sorportolv
Wend

Locate 1 , 4
Lcd Sorsz ; "ATN?  ";
Print "ATN?" ; Chr(13)
Waitms 1500
While _rs_bufcountr0 > 1
 Call Sorportolv
Wend

Do
While _rs_bufcountr0 > 1
 Call Sorportolv
Wend

Loop



Sub Sorportolv

 Locate 2 , 4
 If _rs_bufcountr0 > 1 Then
  Input Ize
  Lcd Sorsz ; " " ; Ize ; "      " ; _rs_bufcountr0
  Wait 3
 End If
 Ize = ""
 Sorsz = Sorsz + 1

End Sub

[Robert]

A print után mi van, ha nem csak chr(13) van, hanem hagyományos: print "ATZ" szerepel?

A $bauddal ütközik a

Kód: Egész kijelölése

Config Pind.0 = Input
Config Pind.1 = Output

Nem kell a kódba.
A beolvasás ne input legyen, hanem inkey(), amíg 13 v 10-es kódra nem futsz. És ellenőrizd, ha a bejövő adat nem betű/szám/10/13-as kódú, akkor azt dobd el (0-s kód, >127-es kódú karakter, stb).
ATE0 utasítással az ECHO-t kapcsold ki!

[konkav]

A print után mi van, ha nem csak chr(13) van, hanem hagyományos: print "ATZ" szerepel?
A $bauddal ütközik a

Kód: Egész kijelölése

Config Pind.0 = Input
Config Pind.1 = Output

Nem kell a kódba.
A beolvasás ne input legyen, hanem inkey(), amíg 13 v 10-es kódra nem futsz. És ellenőrizd, ha a bejövő adat nem betű/szám/10/13-as kódú, akkor azt dobd el (0-s kód, >127-es kódú karakter, stb).
ATE0 utasítással az ECHO-t kapcsold ki!

a '; chr(13)' elhagyásával nem változtak meg a válaszok.
a 'config pin'-eket is kiszedtem (eredetileg sem voltak ott, csak akkor kerültek bele, amikor kifogytam az épkézláb ötletekből, és elfelejtődtek )
'ATE0' sem fut le (csak 'AT' és 'ATN=valami' parancsok futnak le, a többi csak errort ad).
felcseréltem a parancsok sorrendjét (eredetileg: AT, ATE0, ATN?, a válasz OK, ERROR, ERROR), az új sorrend ATE0, AT, ATN?. a válaszok: ERROR, OK, ERROR. vagyis nem csak az első parancs fut le rendben, hanem az AT.
következő lépésként az utolsó parancsot összesen háromszor futtattam le (ATE0, AT, ATN?, ATN?, ATN?), de semmi változás, az AT kivételével minden parancs ERROR-t ad.

a kiolvasás így jól működik, szerintem ez nem befolyásolja a kommunikációt, ezért azt nem írtam át.

már arra gondoltam, le kéne cserélni a BT firmware-ét, csak sajnos sehol sem találtam

[Robert]

A chipben az órajel a 8 MHz-ról át van állítva külső kvarcra?
A külső kvarc tényleg 7.3727-es?

[konkav]

igen, át van állítva (full-swing). két különböző kvarccal is próbáltam, elméletileg mindkettő 0%-os hibát ad 19200 baudon, és mindkettővel ugyan az a helyzet. a kvarcok sebességét egyrészt magáról a kvarcról olvastam le, másrészt egy 'wait 10' parancs segítségével teszteltem (a 18,xxx MHz kvarc esetében érezhetően nem 10s alatt futott volna le, ha nem jó a biztosítékbit, és a belső 8MHZ-ről futna, és közben pedig $crystal = 18432000 beállítással fordulna le a progi).

ami még érdekes, hogy az 'ATN=valami' simán lefut, tizen bájtnyi hosszúságú parancs, viszont az 'ATN?' a maga 4 bájtjával hibát ad. e miatt gondolom, hogy nem a clock-kal van baj. de hogy mivel, az rejtély.

egyébként kaptam ma egy logical analyzert, remélem többet tudok majd ezzel megfejteni.

[konkav]

egy kicsit körbenéztem a modulon lévő ICkkel kapcsolatban. az egyik egy flash memória, a másik pedig egy 'BlueCore4-Ext'. ezt, egyébként sok más gyártó modulján is láttam. esetleg tudnék olyat csinálni, hogy valami más gyártó firmware-ét raknám fel? vagy megpróbálok keresni 'okosított' fejlesztő környezetet. mert a vezérlő IC gyártójánál semmit sem lehet csak úgy letölteni. sőt, regisztrációnál figyelmeztetnek, hogy céges email címmel regisztráljak, mert különben kivágnak, mint macskát ......

[Robert]

Nézd meg, hogy nincs -e 00 kód a fogadott v. küldött előtt? vagy valami szemét
Esetleg nem e kerül az előző adatsorra ráindításra (azaz nem e mielőtt visszajön a korábbi kérdésre a válasz, még _közben v. előtte indítod a köv kérést....)
Tegyél közé 100-400 msec várakozást a print "ATN=?" elé. Így a előző kérdés válaszával nem adsz egyszerre.
A BT modulok nem rendelkeznek belső bufferrel! (vagy ritka). Sőt , van amelyik szoftveres sorosporttal kommunikál!

[konkav]

minden parancs küldése után van 1500 msec várakozás, majd csak ez után indul a kiolvasás, és a kiolvasás után lesz újabb küldés. próbáltam már 5sec-es várakozást is, de semmi változás. de ha mégis ez lenne a gond, akkor mindig az első parancs futna le jól, de nálam csak az AT fut le problémamentesen, függetlenül, hogy hanyadik.

'ATN=?' vagy 'ATN?' a megfelelő? én úgy emlékszem, hogy amikor terminálon teszteltem a modult, akkor az ATN? működött, és a progi is ezt használja. de ha hazaértem, kipróbálom az ATN=?-t is.