ATMega16 + Bluetooth Help

[Nicholas Smith]

Hello all,

I am trying to build a bluetooth robot tank, using an Atmega16A and Sparkfun BlueSMIRF bluetooth modem. I wrote very simple code that is supposed to just send back the character that I send to the microcontroller, to see if the communication is working. The problem is that I am getting a response, but I don't understand why its sending what it is. My thought at the moment is that it has to do with the baud rate not being right, but all my attempts to fix it have not worked.

Please let me know if you need more information. I am willing to meet up with someone at Makerspace. I have been meaning to check it out anyway.

Thank you in advance.

[David Knaack]

I haven't worked with those pieces, but if you bring the project down on a meeting night I'll bet we can figure it out.

Is your code somewhere we can see it?

--
Support Omaha Maker Group with purchases you make anyway. Shop Amazon using our Affiliates link, and OMG receives a portion of the proceeds. http://amzn.to/1f3i3ve

Leave lurking behind — come visit us at the Makery at 8410 K Street, #5, Omaha (just off 84th & L). We’re nice, we promise. http://bit.ly/1dKnTmC
---
You received this message because you are subscribed to the Google Groups "Omaha Maker Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omaha-maker-gr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nicholas Smith]

I'm willing to bring it down next time you guys have a meeting night if you let me know when that is. As for the code, I am not sure where I could go to post it.

[Dan Linder]

You could post it to "http://pastebin.com/" then send us the link that it stores it to.

Dan

On Sun, Jun 19, 2016 at 7:47 PM, Nicholas Smith <nasmi...@gmail.com> wrote:

I'm willing to bring it down next time you guys have a meeting night if you let me know when that is. As for the code, I am not sure where I could go to post it.

--
Support Omaha Maker Group with purchases you make anyway. Shop Amazon using our Affiliates link, and OMG receives a portion of the proceeds. http://amzn.to/1f3i3ve

Leave lurking behind — come visit us at the Makery at 8410 K Street, #5, Omaha (just off 84th & L). We’re nice, we promise. http://bit.ly/1dKnTmC
---
You received this message because you are subscribed to the Google Groups "Omaha Maker Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omaha-maker-gr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

***************** ************* *********** ******* ***** *** **
"If a problem has no solution, it may not be a problem,

  but a fact - not to be solved, but to be coped with

  over time." - Shimon Peres

"Quis custodiet ipsos custodes?"

    (Who can watch the watchmen?)
    -- from the Satires of Juvenal

"I do not fear computers, I fear the lack of them."
    -- Isaac Asimov (Author)
** *** ***** ******* *********** ************* *****************

[Nicholas Smith]

Sorry, I thought I could have time to get this link up sooner. But this should be the link to my code on pastebin

http://pastebin.com/27xaN8JE

[David Knaack]

Did you have a previous iteration of your hardware/software setup that was working? 

If so, back up to that point and only change one thing at a time to move forward.

If not I'd recommend simplifying until it does work, and then start adding pieces back in one at a time.

If you've got the bluetooth hardware hooked up I'd take that out and go with a known-good wired connection so you can confirm that the code works and that it is running at the data rate you expected.

You could also remove the ISR code and do the usart read and echo in the main loop.

On Mon, Jun 20, 2016 at 2:55 PM, Nicholas Smith <nasmi...@gmail.com> wrote:

Sorry, I thought I could have time to get this link up sooner. But this should be the link to my code on pastebin

http://pastebin.com/27xaN8JE

[David Knaack]

What data rate are you trying to set?

I'm not sure what UBBR=0 U2X=1 is with your clock, but it sounds maybe high. That Bluetooth module appears to require 2400-115200, so you might want to try USARTInit with a value that will select a rate in that range.

[Nicholas Smith]

I agree, and I want the baud rate to be 9600 because I do not see a reason it should be higher at the moment. Unless the device automatically selects a baud rate depending on what its being sent (which I have no clue) the sparkfun help says these devices default to 115.2k baud. Which is driving me nuts because that baud rate I get no communication.

But to take your advice this is the simplest iteration that I have that kinda works is:
http://pastebin.com/xzGa2fnS
I say kinda because if I use line 8 and comment out line 9 & 44, the count goes up no matter what data is sent (the if statement is always true). But if I leave it as it is, the if statement is never true. Which makes me believe the communication is working but I am doing something wrong with the baud rate.
I have been stuck at this point for a month or so. I have been trying several different things.

[David Knaack]

Are you testing your code with the AVR connected to a standard serial port (something like https://www.sparkfun.com/products/9718 ), or connected to the bluetooth adapter?

[Nicholas Smith]

It is connected directly to the bluetooth adapter, https://www.sparkfun.com/products/12577 that to be exact.

[David Knaack]

That sounds like you have at least two things in the system that could be doing something other than you expect, the software and the bluetooth adapter. That's a recipe for frustration.

I'd get that bluetooth adapter out of there until you have software on the AVR that you can successfully talk to via a serial terminal and USB adapter. Then, only when you know the software part is working, try talking to the bluetooth adapter.

You could probably also attach the bluetooth adapter to a USB serial adapter and try talking to it with a serial terminal to determine whether it works and has the serial parameters you expect.

[Nicholas Smith]

I see projects like this as a learning experience and your very good advice brings up some questions.

Please correct me if I am wrong, which I probably am, as I understand it the uart sees the connection as a serial connection already because it just receives and transmits data through tx and rx. So as at the software level on the AVR, would it know the difference?

The only difference I can see between the bluetooth adapter and serial terminal and usb adapter would be the baud rate could be controlled better. But if this is the case, I am hesitant to buy what you recommend because I would probably only get a few hours work out of it (Unless I am missing something else it changes).

By the way, if it makes it easier, everything I do have is portable. So if it is better to discuss in person I would be happy to find time to do so.

[David Knaack]

Yes, the AVR USART doesn't care much what is on the pins, but the AVR register-based configuration gives you a huge variety of ways to shoot yourself in the foot (that's why so few people who aren't professional embedded systems programmers use tools like Atmel Studio instead of Arduino, you end up enjoying huge amounts of time tracking down simple mistakes buried in code that is very opaque unless you read it with the chip datasheet open). 

One would think that the bluetooth adapter should just work, but when you're developing embedded systems almost nothing is that simple, and the things that are don't always work perfectly the first time (as you've discovered). Unless you've got a bench full of known-good test equipment that gives you observability at each component interface about the only thing you can do to make consistent progress is be very careful to only deal with one unknown at a time. Then when you think you are doing that and things still don't work, stop and identify your assumptions, then isolate and test each of those.

Are you able to connect to the bluetooth adapter from the bluetooth side and put it into command mode using a serial terminal? From there you could try reconfiguring the baud rate to see if you can get it to sync up with the AVR. Maybe set the AVR up with a program that just sends a short string like 'ABCD' every few seconds, get that loaded, then manually cycle through the bluetooth adapters serial settings and see if you can find the rate the AVR is using.

Several of us have ttl serial cables that you can probably use if you want to check things out that way. Also if you have an Arduino Uno with an FTDI chip you can wire the AVR reset pin to ground and then use the TX RX pins as a TTL USB cable. 

[Nicholas Smith]

That answers several things that I have been wondering for awhile, like why people like using Arduino. The reason that I use Atmel studio and the pain of it, is because that I want to be an embedded professional, more specifically robotics, so I figure I can increase my knowledge base of it.

I have tried to put it in command mode through just having the chip send the command, which was unsuccessful. I will try sending a short string to see what happens. I am confident that I know the baud rate that the AVR chip is using (by playing with the datasheet), but I do not know what the bluetooth adapter is.

[Nicholas Smith]

Okay, I changed my code so it would send a "count" value every second. I wanted something that would vary for now just in case. computer is receiving something every second like the code said it should, but it is the same exact string every time. Which is: `blnpr|~

[David Knaack]

That's a good reason to use it. Once you've learned most of the registers, what flags are where, and how they interact it's a lot easier to get basic things going. Once you get a few variants working It helps to save them as template projects that you can start from. Makes bootstrapping a new project faster and less error-prone.

When I suggest putting it in command mode, I mean doing it from the bluetooth side, not the AVR side. Connect with a computer and open a serial terminal, and put it command mode and poke at it from that side to confirm settings and try other baud rates.

[David Knaack]

Certainly sounds like a baud rate mismatch.

[Nicholas Smith]

I have a good base for a bunch of stuff from school labs and Senior Design, but we did nothing with serial communication except communicating with a LCD screen.

All my attempts to put it in command mode has failed so far. Due to that, I am lost on how to successfully do it. Which is probably my problem, cause I am uncertain what baud rate the Bluetooth is using.

[David Knaack]

You could pull up pin 4 of the RN-42 chip to force it to 9600 baud, that would remove some uncertainty.

[Nicholas Smith]

I believe I pulled pin 4 high like you suggested and I received the same results. Right now, I might have accidentally touched something else while pulling it high because I cannot seem to connect to the device anymore.

[Nicholas Smith]

I had to repair the device to get it to connect again. Could I be getting what I am getting if the usart isnt set up correctly?

[David Knaack]

Definitely, garbled messages like what you are seeing with your transmit loop is, in my experience, usually caused by a mismatch in serial settings. Not exclusively of course, but usually.

[Nicholas Smith]

Okay, I relooked at my usart settings and I believe they are all correct. I also realized that I did not pull pin 4 high, I pulled PIO4 high which is the wrong one.

I am unsure now how to pull pin 4 high. Which I believe is what I want to try next. The chip is mounted on a board and the pin connection is very small.

[David Knaack]

I'd just go with fine wire and a soldering iron :)

If you'd like help with that we can probably take care of it at the OMG meeting tonight.

[Nicholas Smith]

That would be great. I do not feel confident enough to do it. Any particular time?

> ...

[Nate]

We're here now

[Nicholas Smith]

I can be there within the hour. Unless that would be to late.

[David Knaack]

For anyone following along, we connected the AVR serial output to a USB TTL serial adapter and determined that the data rate was wrong. The register configuration for the rate selection appeared to be correct, which suggested that the clock rate was not as expected.

Reconfiguring the chip from 1MHz to 8MHz and resetting the serial config for the faster clock got the data rate almost right. However, we also found that one of the ways to get the 115200 rate had enough of an error percentage to be a problem (it was closer to 125000). Reconfiguring to the other way to get that rate worked better, and we were able to receive clean data via the Bluetooth module.

[Dan Linder]

On Wed, Jun 22, 2016 at 12:58 AM, David Knaack <david...@gmail.com> wrote:

For anyone following along, we connected the AVR serial output to a USB TTL serial adapter and determined that the data rate was wrong. The register configuration for the rate selection appeared to be correct, which suggested that the clock rate was not as expected.

Reconfiguring the chip from 1MHz to 8MHz and resetting the serial config for the faster clock got the data rate almost right. However, we also found that one of the ways to get the 115200 rate had enough of an error percentage to be a problem (it was closer to 125000). Reconfiguring to the other way to get that rate worked better, and we were able to receive clean data via the Bluetooth module.

Thanks for the recap - I was living vicariously watching the thread.

So, is the initial problem completely solved, or is there a "chapter 2" coming. :)

Dan

[Nicholas Smith]

The initial problem is solved for now. I plan on putting into my project and have something working next week, so I can bring it in and show my tank moving using the bluetooth.