[Test/recenzja] [Komunikacja] Bluetooth KAmodBTM222

[nowicjusz89]

Zatem to kwestia programatora? czy jest jakiś inny program który pozwoli na zmianę fusebitów?

[Luko]

nowicjusz89, obsługa google jest zbyt skomplikowana? Głupie pytanie wystarczy zadać "usbasp program" pierwszy link i już po 10 sekundach patrzenia złapałem 2 programy. Jeszcze bardziej denne zapytanie "usbasp" na stronie pomysłodawcy programatora linki do 4 programów ...

[nowicjusz89]

No i nadal kicha :/ ustawiłem zgodnie z tym tutorialem fusebity dla atmegi8: http://mirley.firlej.org/fuse_bity_w_mikrokontrolerach_avr

Jednak teraz jest jeszcze gorzej bo po podlaczeniu przez terminal nic sie nie wyswietla, nawet krzaki :/ Ma ktoś jakiś pomysł co może być jeszcze nie tak?

[nowicjusz89]

Znowu piszę

Oczywiście zablokowałem mikro :/ W każdym bądź razie czy ktoś próbował korzystać z wewnętrznego oscylatora atmegi8 (wbudowany ma możliwość do 8MHz)? Jaką częstotliwość powinna być ustawioną żeby współpracować z BTM222?

[Armir]

Zobacz sobie EP 12/2010. Było tam o BTM 222.

[nowicjusz89]

Cały czas pod górkę: kolejny procek zablokowany, zastanawia mnie tylko dlaczego, gdyż ustawiłem fusebity na kwarc zewnętrzny 4MHz i mam do tego 2 kondensatory 33pF.

Przestawię jeszcze sytuację która mnie niepokoi, zrobiłem sobie płytkę do programowania Atmegi (podstawka do wpięcia mikro i złącze ISP), która służy do programowania mikro. Na innym forum wyczytałem że w momencie ustawienia fuse bitów mikro resetuje się. Stad moje pytanie, czy gdy ustawiłem fuse bity na kwarc zewnętrzny na swojej płytce do programowania i tam go nie było (jest na płytce do której później wpinam mikro) to czy to może być powodem że mikro się blokuje? Czy uważacie że na tej płytce do programowania powinien być kwarc?

Dziękuję wszystkim za pomoc

[Harnas]

Powinien być kwarc.

Programowanie uruchamia się w procesorze po podaniu pewnych impulsów na końcówkę reset a samo programowanie przebiega już z resetem zwartym do masy.

[MirekCz]

Jak włączysz inny tryb niż kwarc wewnętrzny to procesor także przy programowaniu używa tego trybu od tego momentu. Czyli musisz mieć podłączony kwarc/rezonator/generator -zależnie od trybu.

Dolutuj kwarc i 2 kondensatory 22pF i będzie programator działał z prockami ustawionymi zarówno na zegar wewnętrzny jak i na kwarc.

[nowicjusz89]

Jest niewielki postęp, przylutowałem kwarc 11059200, ustawiłem fusebity i atmega ruszyła

Jednak przy podłaczeniu przez terminal znaki, które wysyła atmega przez uart nie pokrywają się z tym co jest wyświetlane w terminalu.

Dodam jeszcze ze ustawione mam: UART_BAUD_RATE 115200UL oraz F_CPU = 11059200

Czy ktoś ma jeszcze jakiś pomysł co może być nie tak?

[Luko]

ustaw sobie prędkość na 9600 w uC i komputerze, będzie wtedy działać ... niestety z większymi prędkościami przesyłu danych tak jest, że te najmniejsze prędkości przeważnie działają najlepiej . A chyba nie będziesz przesyłał nic innego jak kilka znaków.

[nowicjusz89]

Rozumiem że mam zmieniać UART_BAUD_RATE na 9600, i w terminalu tak samo baud na 9600. Jednak nadal to nie działa - wychodzą różne dziwne znaki :/ Dokładnie tak, potrzebuje to do tylko kilku znaków żeby mikrokontroler coś robił z diodami jak otrzyma konkretny znak.

Nadal nie wiem co jest nie tak :/ Zauważyłem że gdy wysyłam jakiś znak do mikro przez UART aby odesłał go spowrotem to znaki te są jakby przesunięte w tablicy ASCII, np. wysyłam mu char a = '1' = kod ascii 49 (HEX= 31) to otrzymuje spowrotem znak '<' = kod ASCII 60 (HEX = 3C). Nie wiem czy ide dobrym tropem, ale może to jest jakiś problem z konwersją?

Znalazłem na internecie gotowy prosty przykład sterowania UARTEM żeby jak najbardziej zminimalizować możliwość błędu, poniżej wrzucam kod:

#include <avr/io.h> 
#define USART_BAUDRATE 115200 
#define BAUD_PRESCALE (((11059200 / (USART_BAUDRATE * 16UL))) - 1)

int main (void) 
{ 
  unsigned char ReceivedByte = '1'; 
int i;
  UCSRB |= (1 << RXEN) | (1 << TXEN);   // Turn on the transmission and reception circuitry 
  UCSRC |= (1 << URSEL) | (1 << UCSZ0) | (1 << UCSZ1); // Use 8-bit character sizes 

  UBRRL = BAUD_PRESCALE; // Load lower 8-bits of the baud rate value into the low byte of the UBRR register 
  UBRRH = (BAUD_PRESCALE >> 8); // Load upper 8-bits of the baud rate value into the high byte of the UBRR register 

  for (;;) // Loop forever 
  { 
     while ((UCSRA & (1 << RXC)) == 0) {}; // Do nothing until data have been recieved and is ready to be read from UDR 
	for(i=0;i<10;i++){
  ReceivedByte = UDR; // Fetch the recieved byte value into the variable "ByteReceived" 
	}
     while ((UCSRA & (1 << UDRE)) == 0) {}; // Do nothing until UDR is ready for more data to be written to it 
     UDR = (unsigned char)ReceivedByte; // Echo back the received byte back to the computer 
  }    
}

[ Dodano: 12-01-2011, 14:38 ]

Już działa! BAUD_RATE=19200, bo tak jest domyślnie w BTM222 i poszło bardzo dziękuję wszystkim, którzy włączyli się w rozwiązanie mojego problemu

[wsowa]

Proszę bardzo.

[grzechotek]

Ja mam takie pytanie... co oznacza ":1" w adresie Bluetooth ???

[nick]

Witam!

Mam takie pytanie - z czego może wynikać problem z połączeniem tego modułu - tzn. mój komputer w ogóle go nie wykrywa? (bluetooth w kompie w porządku - inne urządzenia są widoczne).

[nes86]

Witam!

Mam takie pytanie - z czego może wynikać problem z połączeniem tego modułu - tzn. mój komputer w ogóle go nie wykrywa? (bluetooth w kompie w porządku - inne urządzenia są widoczne).

Wystarczy podłączyć zasilanie i już moduł powinien być widoczny. Będzie miał nawę "SerialAdaptor"