A while ago I put an article in the library on using inexpensive bluetooth modules found on eBay. This thread is for questions or comments on the article.

Noter -

Got my little bluetooth module up and running. Very cool! I just used a simple code to test the connections and all went fine. I was combing through the menu driven code you posted in the library (might steal the QMASK concept and some of the "strtok" codes), but I came across something I hadn't seen before. It was the "jump_reset()". How exactly does that work? I was under the impression the Watchdog Timer (when enabled by fuses) was the way to do a software reset. I noticed the "jump_to_application()" code in the "foodloader.c" listing and it seemed similar to what you are doing. Any explanation would be much appreciated.

Thanks in advance.

P.S. - I'm hoping to write an app for the android to make interfacing the MCU even easier.

Glad you got it going! It is a fun way to interface to the nerdkit. I think I fixed a bug or two in the menu code after posting the example so beware.

void (*reset_jump)(void);

The above statement creates the variable reset_jump and then casts it as a pointer to a function. The variable reset_jump is null so when the function is called control transfers to address 0x0000 which is the reset vector. There's other ways to do it but one way or another the reset vector has to be executed.

Thanks Noter -

I keep thinking in PC mode. A jump to a null-pointing function usually screams "Page fault error" on the PC. Now that I read your explanation and went back to "foodloader.c", I can see the resemblance to this statement...

void (*jump_to_application)(void) = (void *)0x0000;

After doing some reading on the subject, I kind of like the watch dog timer concept, but it won't port to chips with fuses set differently. I guess the only downside to jumping to the reset vector is all your interrupts are still active...I can live with that.

The reset vector doesn't really reset the mcu, it just starts from the beginning of the program again. SRAM will be reinitialized from the .data section but registers remain unchanged. Usually not a problem because the first thing programs typically do is initialize devices. If you were concerned about active interrupts you could just cli() before jumping to the reset vector.

I like to use the watchdog timer for longer duration interrupts like once every few seconds. It's handy for checking voltage on a photocell to adjust a back light or something like that.

Hey Noter,

When I try to compile the code onto the nerdkit it says F_cpu undeclared and Baud Undeclared. I edited the makefile to 9600 baud but it still doesnt want to work.

Thanks for putting this all together!

-Dan

Sorry, I always setup F_CPU and BAUD in the make file. I don't know if this makefile will work for you as is but you can see where/how I set the values. It a generic makefile I copy from one project directory to another and edit the settings as needed.

# comm port & baud rate of the programmer
PGMR_COM_PORT=/dev/ttyUSB1
#PGMR_COM_BAUD=115200
PGMR_COM_BAUD=38400

# type of mcu
MCU=atmega328p
#MCU=atmega168
#MCU=attiny85

# frequency of mcu clock/crystal    
#F_CPU=20000000UL
#F_CPU=18432000UL
F_CPU=16000000UL
#F_CPU=14745600UL
#F_CPU=8000000UL

# baud rate for this program
#PGM_BAUD=115200L
PGM_BAUD=38400L

all: $(patsubst %.c,%.pgm,$(wildcard *.c))

compile: $(patsubst %.c,%.hex,$(wildcard *.c))

.SECONDARY:

%.o: %.c Makefile
    avr-gcc -g -Os -Wall -mmcu=$(MCU) -mcall-prologues \
        -Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm \
        -Wl,-Map=$@.map \
        $< -o $@ \
        -DF_CPU=$(F_CPU) -DBAUD=$(PGM_BAUD)

%.ass: %.o
    avr-objdump -S -d $< > $@

%.hex: %.o %.ass
    avr-objcopy -j .text -j .data -O ihex $< $@

%.pgm: %.hex
    avrdude -C ../libnerdkits/avrdude.rs -c AVRBOOT -p $(MCU) -b $(PGMR_COM_BAUD) -P $(PGMR_COM_PORT) -D \
        -U flash:w:$<:a

clean: 
    -rm *.o *.hex *.ass *.map *.c~ Makefile~

Ok I tried that I and it says makfile line 36 no separator. I was able to get it to compile by defining f_cpu and the baud rate in the C file but it seems like the MCU isnt transmitting or recieving anything

The missing separator error is because the tabs in the makefile get changed to spaces when it is posted. You could change the leading spaces back to tabs and it should work but I don't think that is the problem.

Leave the bluetooth module out while you are getting the program to work. You can use a terminal emulator on the PC to work the serial interface on the mcu. Are you using the nerdkits bootloader or an ISP programmer?

Ok thanks Noter. I'll try that tomorrow.

I forgot about that tab and spaces thing. I'm using the normal nerdkits bootloader right now

I fiddled with the tabs and spaces on your makefile but now it says fatal error avr interupt not found

Hmm ... I'm not sure I've seen that error before. Is it n avr-gcc error and if so what is the line number where it occurs?

I think its because I have the directory pointed in the wrong place on your makefile. I'm using linux so I have to check

Your makefile is really hard to work with because things are tabbed over half way and others are only a few spaces. I also cannot point my directory in a good location at all. How do I just define the F_cpu and the baud rate in the normal makefile.

GCCFLAGS=-g -Os -Wall -mmcu=atmega328p 
LINKFLAGS=-Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm
AVRDUDEFLAGS=-c avr109 -p m328p -b 115200 -P /dev/ttyUSB0
LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o

all:    initialload-upload

initialload.hex:    initialload.c
    make -C ../libnerdkits
    avr-gcc ${GCCFLAGS} ${LINKFLAGS} -o initialload.o initialload.c ${LINKOBJECTS}
    avr-objcopy -j .text -O ihex initialload.o initialload.hex

initialload.ass:    initialload.hex
    avr-objdump -S -d initialload.o > initialload.ass

initialload-upload: initialload.hex
    avrdude ${AVRDUDEFLAGS} -U flash:w:initialload.hex:a

You can add the definitions to the end of your GCCFLAGS -

GCCFLAGS=-g -O0 -Wall -mmcu=atmega328p -DF_CPU=14745600UL -DBAUD=115200L

Thanks Noter,

I was able to get it to upload but now when I try to use it in minicom off the nerdkits Serial to USB adapter I get the help line but its all weird.

Ok so I was able to get it to display the command list over bluetooth on my tablet running blueterm. But for some odd reason Blueterm doubles everything I type so I cant send a command. EX. when i type "help" it reads "hheellpp" or when I type"<" it reads "<<". I know its not the app or the tablet because I have typed on the emulator and seen it on minicom fine through the bluetooth dongle. So it must be the nerdkit side. What could it be I wonder?

-Dan

Glad you have it working! Sounds like there is a local echo of the characters enabled on your tablet. The nerdkit echos the character so that's one and if your tablet also displays the character it sent, that's two. My version of bluetooth has a preferences menu item and a local echo checkbox that is not checked.

oops - I meant to say my version of blueterm ...

OK thanks I'll give that a shot

I remember trying that before but it just says invalid command whenever I try to input a command and it still does it

This is what I'm getting on my nexus 7.

http://www.imgur.com/PISR6.png

Did it take and process commands ok when you used your PC and a terminal emulator? I'm on linux also and I use GtkTerm.

Let's be sure it works using the serial port with the PC because that will tell us if it is the program on the mcu or something to do with bluetooth.

Thanks noter,

Though I'm still getting the same results as I did on my tablet when using GTKterm. It must be the MCU then.

I just flashed it to another nerdkit 328p and it still does the same thing, too

-Dan

Yes, it seems there is something not working in the program. I've made a few minor changes since the original posting and to be sure we are using the same version I just posted my current version. Please get this one and compile it to your chip so we can be working from the same source. I compiled it a few minutes ago and it is working fine on my 328p nerdkit.

OK thanks Noter, I'll flash the new program tomorrow.

Bluetooth will make for some great projects!

Thanks for your assistance!

-Dan

Weird, I'm still getting the same error of invalid command with bluetooth or gtkterm

Are you getting any warnings when you compile?

The only thing I can think of is I'm using the latest toolchain by Atmel. Have you ever updated avr-gcc since installing from the nerdkit links?

Dan -

Any chance "Blueterm" and/or "GTKterm" is outputting using Unicode?

Hmm ... if it was using Uincode would it still echo the correct character to the screen? I guess the best course from here is to do some debugging. I've changed the program a little to turn on debug mode during initialization and then to print the command length, character, and hex codes. We'll be able to see if the correct characters are making it to the program.

Dan, please download and run this version so we can see all the command characters.

Noter -

It would echo the same characters, except it would send 2 bytes over the UART instead of 1. Not positive, but I think English ASCII just gets prefixed with 0x00. So instead of sending 0x55, you'd get 0x00 0x55. I don't know if this is happening or not...just something to check out I guess.

Noter,

Heres a pic of the result of your debugging code.

That confirms the correct characters are getting to the program so the problem is in parsing the command input.

I think you will need a more current version of the toolchain, in particular avr-gcc. Get it at the Atmel site - Atmel AVR Toolchain 3.4.1 for Linux. I just put it in my home directory and added it's location to the beginning of the PATH variable.

My neighbor just called and he is stuck in the snow on his farm so I'm headed that way to lend a hand, might be gone a couple of hours. There is much info about setting the PATH variable on the web if you need it.

OK I'll give the the tool chain an update. I hope you get by our neighbor out of the snow.

I'm still not able to get my toolchain updated. I've tried to find some info on the path vairable but I cant find any on the avr. Do i just make the new path to the updated toolchain in the makefile?

-Dan

I unzipped the new toolchain into my home directory into a folder named Atmel-AVR-Toolchain-3.4.1 then edited the file .bashrc to include this line at the top of the file:

export PATH=~/Atmel-AVR-Toolchain-3.4.1/avr8-gnu-toolchain-linux_x86/bin:$PATH

And in my make file I added the library path to the gcc command:

-L~/Atmel-AVR-Toolchain-3.4.1/avr8-gnu-toolchain-linux_x86/avr/lib \

so that in my makefile the gcc command looks like this although your gcc command will probably be different the main thing is to add the library path:

avr-gcc -g -Os -fno-jump-tables -Wall -mmcu=$(MCU) -mcall-prologues -std=c99 \
    -L~/Atmel-AVR-Toolchain-3.4.1/avr8-gnu-toolchain-linux_x86/avr/lib \
    -I../ \
    $< -o $@ \
    -Wl,-Map=$@.map -MMD -MP -MF $@.d \
    -DF_CPU=$(F_CPU) -DBAUD=$(BAUD) -DMCU=$(MCU)

Noter,

Thanks I was able to update the toolchain but I'm still getting the same results. weird

-Dan

I think I'll try this on windows and load up all the current drivers on there.

Is the mcu you are using with the bootloader a 328 or the nerdkit 168?

328

Noter -

Finally got my Smartphone programmed to interact with the Bluetooth Chip/MCU directly. Had to wade into Java and the quirks of the Android operating system but I learned a great deal. It's easier to go the Terminal program route, but now that I have a template for future projects, it should not be too bad to adapt the Java code. Here's a screenshot and a pic...

That is really cool! I'd like to give it a try on my phone if you wouldn't mind posting your source and a few directions. The terminal program works fine for what it is but your approach is much better for real applications.

Missle, any luck using your windows setup? I can't think of anything else so if your windows machine doesn't do the trick then possibly there is something wrong with your chip so swap it if you have another. Otherwise you'll have to step through the program and debug to figure out where it is failing.

Noter,

No luck, I just tried it on windows with the updated drivers and still no change. I wonder if it has anything to do with the fact that I'm not using a dual uart mcu like pcbolt and you are using.

PCbolt, looks cool! I hope to do something like that once I get this working!

-Dan

Noter/Dan -

I started a New Thread to discuss the topic since I didn't want to hijack this thread too much. I'd be happy to share code/directions there but right now the code isn't at all bulletproof...just functional.

Missle, I think I see the problem. In your makefile the objcopy needs to copy the data section too so the memory string containing valid commands will be initialized. Just add the "-j .data " like is shown in the line below and give it a go.

avr-objcopy -j .text -j .data -O ihex $< $@

Dan -

I'm using the dual UART 644p but I don't think Noter is.

I'm using a 328p but now I'm pretty sure the data section is missing. Seems I get bit by that more than my share of the time. I'll have to make it the first thing I look for when things don't work.

Noter,

Thanks a ton! That must have done the trick! Except now the led doesnt blink or anything. Thats enough for one night. Thanks so much

-Dan

(Bluetooth Modules)[http://www.rasmicro.com/Bluetooth/EGBT-045MS-046S%20Bluetooth%20Module%20Manual%20rev%201r0.pdf] is the best document I've see so far on the bluetooth modules we have been using.

The important information I want to alert you to is on page 2 where it says RXD input is not 5V tolerant, and can be damaged by 5V level logic going in. After reading this I put a voltage divider on the mcu TX pin so that only approximately 3.3v logic will be delivered to the bluetooth module. I used a 3.3k ohm and a 1k ohm and when the module is connected I measure 3.2v to the bluetooth module which is close enough.

I'll update the library tomorrow with this new information and a new schematic but in the mean time here is a photo showing the voltage divider on the tx pin (green wire).

Fixed the link - Bluetooth Module Documentation