Svenska ElektronikForumet

Har kopplat ihop min BlueTooth (Ezurio Blu2i) modul med min PIC och skickar kommandosekvensen:

ATZ (För att starta om modulen)
AST0=1 (För att få den att connecta efter 1 ring)
AT+BTP (För att vara synlig och kan ta emot connections)

...men jag får inget svar från modulen förutom 'A', 'S', 'T'...sedan tar det slut. Efter ATZ borde ett OK meddelande komma till baka, samma gäller de andra kommandona. Om någon försöker connecta till modulen skall ett meddelande med CONNECT och apparatens nummer komma. Men Icke!

Jag kanske gjort något klantigt i min kod eller? undrar också varför det kommer ett "eko" med halva AST kommandot? har mätt med oscilloskopet och kan se att det händer mer än så...t.ex då jag försöker ansluta mig med mobilen efter att jag hittat modulen så ser jag att data skickas från TX på modulen...skumt

Hur hanterar du USART modulen ?
Interrupt styrt med FIFO buffers ?
Får du "overrun" ?
PIC modell ?
Programspråk ?
Är det beprövade USART rutiner från gamla projekt ?

> Jag kanske gjort något klantigt i min kod eller?

Självklart ! Vad skull det annars vara...

Haha precis, misstänker att det är mitt fel någonstans

Skriver mina rutiner i asm (pic18f4320) och det är första gången jag skriver uart rutiner. Använder polling när jag skickar och interrupts när jag tar emot. Kom att tänka på att jag kanske behöver ställa in baudraten på modulen efter omstarten. Men jag använder 9600kbps på picen och vad jag läst så är det den samma på modulen (factory settings).

Antar att det är fifo buffers.

Efter jag sänt mina kommandon stannar jag på ställen (bra $) och inväntar svar från interruptsen)...och det är väl uart och inte usart jag skall köra???

Enklaste sättet är ju att låta PICen skicka AT-kommandona till datorns serieport och se vad som kommer ut.

Att tänka på är att BT-modulen kan ta rejäl tid på sig att svara, särskilt när man söker efter endra BT-enheter...

> Antar att det är fifo buffers.

Är och är. Det beror på om du har implementerat det i din kod. Men
det spelar mindre roll tillsvidare...

> Efter jag sänt mina kommandon...

Alla 3 i ditt exemepl ?

> stannar jag på ställen (bra $) och inväntar svar från interruptsen.

OK, men har du inte kopplat på interrupt innan dess ?
Hur *vet* du att du får A, S, T och inget mer ?
Vart tar de mottagna tecknen vägen ?

Notera också att du börjar få tillbaka tecken direkt när det första "A"
har skickats (om "echo" är påslaget på B-T modulen).

> och det är väl uart och inte usart jag skall köra???

Kärt barn har många namn...
Vi menar samma sak.

Eko är tydligen på per default enligt datasheeten...och har konstaterat att jag får overrun som du säger. Vad gör man åt saken? (OERR flaggan i RCSTA) har prövat mig fram ett antalg gånger och får alltså inte fler än 3 tecken max...är det så att buffern i picen har någon pipeline av något slag som gör att man måste tömma något register innan man kan ta emot mer?

> är det så att buffern i picen

Vilken buffer ? Finns ingen...
Du måste alltid läsa *varje* tecken innan *nästa*
tecken är helt mottaget....

Endast ett shiftregister då? ...är intresserad av hur man undviker en overrun

Det blev lite rörigt med mitt tillägg ovan, så jag tar om det...

Du måste alltid läsa *varje* tecken innan *nästa* tecken är helt mottaget....
Vilket är väldigt enkelt om man som i ditt fall läser receive registret
i en interrupt rutin...

Kan man använda cts och rst signalerna för att kontrollera flödet på något sätt?

Vad jag gör nu är att jag sätter CREN till 1 i RCSTA i början av programmet och sätter att jag vill ta emot interrupts. När en interrupt kommer så läser jag av RCREG och inväntar nästa interrupt...kör en liten paus i interrupten (för att hinna med att läsa) också för att plotta ut det mottagna tecknet på min LCD. Inte så bra att göra detta i interrupten jag vet. Men man skall väl ändå kunna hantera mottagandet på ett smidigt sätt?

> Kan man använda cts och rst signalerna för att kontrollera flödet på något sätt?

Ingen aning. Kanske...
Det beror väl helt på om B-T modulen stöder flödeskontroll...

> När en interrupt kommer så läser jag av RCREG och inväntar nästa interrupt...

Perfekt. Alltså en snabb interruptrutin, RETFIE och sen vänta igen.
(Eller "vänta" förresten, du kan naturligstvis göra vad som helst under tiden...)

> kör en liten paus i interrupten (för att hinna med att läsa)

Absolut inga pauser i en interrupt rutin !

> (för att hinna med att läsa)

Vem, du ? Eller vadå "läsa" ?

> också för att plotta ut det mottagna tecknet på min LCD.
> Inte så bra att göra detta i interrupten jag vet.

Exakt. Receive-interrupt rutinen ska *enbart* läsa RCREG registret, spara tecknet,
sätta en flagga att "ett nytt tecken finns" och sedan göra RETFIE.
Allt annat görs i main, skriva till LCD o.s.v.

Goran skrev:Har kopplat ihop min BlueTooth (Ezurio Blu2i) modul med min PIC och skickar kommandosekvensen:

ATZ (För att starta om modulen)
AST0=1 (För att få den att connecta efter 1 ring)
AT+BTP (För att vara synlig och kan ta emot connections)

...men jag får inget svar från modulen förutom 'A', 'S', 'T'...sedan tar det slut.
... halva AST kommandot? ...

En sidnot, kanske; Man sätter första S-registret (nr 0) till värde 1 för att modemet ska svara på första ringsignalen.
Det gör man på det här sättet:
ATS0=1
Skrev du fel ovan, i så fall är det fel på så många ställen, och även Sodjan upprepade det.
Om de två första tecknena inte är AT i ett kommando man skriver till ett Hayes-kompatibelt modem, så tror jag att den ignorerar det som skräptecken på serieporten.
Eller är AST verkligen ett korrekt kommando för det här modemet?
Jag gissar att det inte är så, för de övriga kommandona är Hayes.

Testa förresten att byta ut ATZ mot AT&F, som ställer om modemet till factory default.
Vad som kan vara inställt på modemet är att den inte ekar OK-svar, vilket kan styras via register.
ATZ läser bara in första mjukvaruprofilen, och om den inte uttryckligen ställer om registret för eko till korrekt värde, så får du fotfarande inga svar.
Det här är något jag fick göra ofta när jag sysslade med installation och support av butiksdatasystem där modem eller ISDN TA ingick, för ett antal år sedan.

Om jag minns helt rätt; Man kanske inte får OK efter AT&F om ekot var av, det är aktivt först på nästa kommando.
Skicka AT&F, vänta 250 msec, skicka därefter AT, då bör du få OK, annars har du andra problem.
Dessutom skulle jag börja med att skicka AT ett par gånger, för att ge modemet en chans att synka till port-hastigheten, innan jag skickar AT&F, om det är ett auto-sensing modem.

Ett tips på en sak du kan testa när det väl fungerar, är att en efter en skicka kommandona:
ATI1
ATI2
...
AT9
ATI0

Svaret från vissa av kommandona kan vara flera rader långt.
Det ger dig status-information om interna inställningar i modemet, version på firmware, samt lite annat jox som pnp id, om det är ett plug'n'pray modem.
Vissa av kommandona kanske inte har information i din modell, och då kan den svara ERROR, men det kan du strunta i, det här är bara informativa kommandon.

Dom flesta enkla UART:ar funkar så att dom har ett shiftregister och ett buffertregister i mottagaren. Så troligen även PIC18.

När ett tecken mottages så shiftas det in bit för bit i shiftregiret för att sedan överföras till buffertregisret när det är komplett mottaget. Då sätts flaggan att det finns data mottaget och nästa tecken kan börja shiftas in i shiftregistret. Nu gäller det att reagera på flaggan, antingen via pollning eller avbrott, och läsa ut tecknet från buffertregistret innan nästa tecken är färdigmottaget och skall överföras till buffertregistret.

Har man inte läst ut förra tecknet från buffertregistret innan det inkommande tecknet är färdigmottaget, så blir det överskrivet och man får overrun.

Detta är det vanligaste förfarandet vid mottagning. Sedan finns det mer avancerade UART:ar som har pipelines med plats för många tecken mellan mottagning och utläsning.

vfr, helt rätt. Ett shiftreg (som man inte kan läsa direkt) och *ett*
buffert-register (RCREG).

Allt bör göras klart för mottaganing *innan* första tecknet skickas
till modemet. D.v.s interrupthantering m.m.

Och man måste se till att applikationen kan ta imot data med den
hastighet som man kör med. D.v.s om man kör 9600 baud ca varje ms.
Men att läsa RCREG, spara under värdet, sätta någon flagga och
göra RETFIE tar bara 5-10 us, så det ska inte vara något problem...

Tack boysen nu fungerar det!

Satte in lite checkar för overrun och frame error samt satte upp en buffer som laddas och avläses etc. så nu kan jag se vettiga meddelanden från modulen. Nu fattas bara kod för att hantera meddelandena samt skicka handshake för connections så borde jag kunna skicka data till min mobil =)