Coding help of avr

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to make a robot with the help of avr atmega16 that goes forward for x time and takes a turn and then again goes for y times and stop there after fixed duration it moves again.

In this i require robot to go in straight path with the help of hmc5883l and uses PID for error collection.

Could u please help here is port detail.

port b mortor driver

port c HMC5883l(digital compass)

port d TX of data using RF sensor

An early reply would be very helpful

Thanks
Prateek Chuahan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can see you've researched your problem extensively, but unfortunately we don't write code on demand ( unless you offer us $$$ ). If you ask a specific question, then we can assist.

I would suggest working your Google skilz and seeing if someone has done something similar, maybe someone who has done your class previously.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clearly something like this calls for a modular approach. You can develop the support for the compass, the RF sensor and the motor driver in isolation. So can you show what you have tried so far for each? Which of the three are you "stuck" on? Have you Googled and found existing code for the devices to use as a template to get you started? (whien I Google "avr HMC5883l" it hits 51,700 threads - I couldn't try the same for your motor driver or RF as you didn't name those but I'm sure you get the idea?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hey i got this code from online but unable to print on LCD... I'm getting junk values on lcd..
anyone know how to get...
Its a HMC5883l code.. used as a digital compass

/* program to navigate robot*/

#include  // Header file for IO operations
#include //HEader file for using inbuilt delay function
#include"LCD.h" // include the LCD header file
#include 
#include 
#include 
#include "twimaster.c"
/////////MICRO DEFINITIONS///////////

#define bit(p) (1<<(p))
#define clear_bit(p,b) p&=~b  /// sends 0 to the selected bit
#define set_bit(p,b) p|=b     /// sends 1 to the selected bit
#define flip_bit(p,b) p^=b    /// toiggles selected bit
#define check_bit(p,b) p&b   //// checks the status of selected bit
#define HMC5883L_WRITE 0x3C // write address
#define HMC5883L_READ 0x3D // read address

int16_t raw_x = 0;
int16_t raw_y = 0;
int16_t raw_z = 0;

char x[10];
char y[10];
char z[10];

void init_HMC5883L(void)
{

i2c_start(HMC5883L_WRITE);
i2c_write(0x00); // set pointer to CRA
i2c_write(0x70); // write 0x70 to CRA
i2c_stop();

i2c_start(HMC5883L_WRITE);
i2c_write(0x01); // set pointer to CRB
i2c_write(0xA0);
i2c_stop();

i2c_start(HMC5883L_WRITE);
i2c_write(0x02); // set pointer to measurement mode
i2c_write(0x00); // continous measurement
i2c_stop();
}

void getHeading(void)
{

i2c_start_wait(HMC5883L_WRITE);
i2c_write(0x03); //set pointer to X-axis MSB
i2c_stop();

i2c_rep_start(HMC5883L_READ);

raw_x = ((uint8_t)i2c_readAck())<<8;
raw_x |= i2c_readAck();

raw_z = ((uint8_t)i2c_readAck())<<8;
raw_z |= i2c_readAck();

raw_y = ((uint8_t)i2c_readAck())<<8;
raw_y |= i2c_readNak();

i2c_stop();
}

void main()
{
LCD_INIT(); // Initialise the LCD
_delay_ms(1000);
LCD_CMD(LINE1); // put the cursor on LINE1
LCD_STRING("X Y Z direction "); // Print string
_delay_ms(1000);
i2c_init();
init_HMC5883L();
_delay_ms(100);

while(1)
{

getHeading();
dtostrf(raw_x, 10, 5, x);
dtostrf(raw_y, 10, 5, y);
_delay_ms(400);
 LCD_CMD(LCD_CLEAR); // Clear the LCD
 LCD_CMD(LINE1); // put the cursor on LINE1
 LCD_CHAR(x); // Print direction

 LCD_CMD(LINE2);// put the cursor on LINE 2
 LCD_CHAR(y); // Print direction
_delay_ms(100);
}


}

Thanks

[code tags added - sadly indentation still missing]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suggest you stop trying to run before you can walk. I'm not even going to bother to read your code.

You need to take this in easy steps.

1) Write some code to blink an LED connected to a pin.

2) Now change that code and/or your chip's fuses so that it runs at the correct speed.

3) Now interface an LCD display and get it to print 'Hello World'.

4) Now write some code to read your digital compass and display the result on your now working LCD.

5) Now transmit those values over your RF link.

6) Now write some code to move your robot forwards and backwards and to turn left and right.

Now, and only now, are you in a position to write some code to bring the whole thing together.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wait a minute.... your first question didn't say anything about an lcd. This adds another step to the 'robot controller by stepwise refinement' project. However, this might be the most impossible part of the project, because I have never heard of anyone ever 'interfacing' an lcd to an avr. Maybe the guy that wrote that example was trying, but as you said, he didn't succeed. Maybe I'm wrong, but you can do a couple of checks and see.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVRfreaks is a very good place for novices to get answers to AVR related questions but as you may see you are getting roughed up a bit and that is because you aren't asking your questions in a way that works on sites like this. I suggest you read:

Newbie? Start Here!
http://www.avrfreaks.net/index.p...

How to ask questions that have a better chance of getting an answer:
http://www.catb.org/~esr/faqs/sm...

Then follow Brian Fairchilds suggestions precisely.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

getting roughed up a bit

"roughed up"? Really? I agree that Bob's rather naughty post doesn't help very much but everything else here looks like serious advice. Kartman is right that no one is going to deliver complete code for free if that were the intention (it could be interpreted that way) and Brian is equally right that it's not possible to run before learning to walk and that does generally start with a flashing LED (the MCU equivalent of a long journey starting with a single step? ;-)).

My suggestion of using Google to find existing code for the devices involved is, I believe, a good one. Apart from the very Arduino like approach of simply bolting ready-made components together it serves the further dual purpose of (a) proving that any hardware involved is all wired up and working OK if some potted code can make it do something sensible and (b) it gives you a template to study so if your intention really is to reinvent the wheel as a learning exercise I don't think much helps as much as seeing how someone else already did it though I suppose this does remove some of the masochistic pain from the learning experience ;-)

@OP in case you missed it Bob's post was a joke - he's saying that you are NOT the first to attempt to use an LCD and if you look around you WILL find lots of ready made solutions/code for this bit of the puzzle.

Oh and DO approach this in a module fashion. Don't try to implement everything at once with all the code interleaved. Start by getting some kind of "debug interface" working. If you already plan for this thing to have LCD then do concentrate on getting that going first because you will then be able to use it to report on other bits of the system you then work on.

It sounds from your posted code like you are trying to use it to do just that for the compass. But you cannot move on to worrying about the compass (or anything else) until you have got the LCD stuff working faultlessly and then can rely on it as a "black box" that just works.

This is the nature of systems development - a modular approach and building up from the simple stuff to the complex stuff, getting the simply stuff to work first to the point where you can completely rely on it and you can then just use it to help with the implementation of the higher level, more complex parts of the system.

But all this DOES start with flashing an LED. There's a reason we all do it first when we start to use a new micro because it aids in the learning curve. The concept itself teaches you about the building and device programming you need to be able to just rely on. Then an LED involves IO which is key to almost all MCU designs while being a simple part of the MCU that should be easy to start with. You also learn about delays and speed of operation while trying to get the flash rate to something sensible and, if you are feeling really adventurous, it's also your "way in" to learning about timers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
I suggest you stop trying to run before you can walk

Agree!

 

Quote:
You need to take this in easy steps.

1) Write some code to blink an LED connected to a pin.

2) Now change that code and/or your chip's fuses so that it runs at the correct speed.

3) Now interface an LCD display and get it to print 'Hello World'.

 

Actually, I would say that going straight from blinking an LED to doing an LCD is a leap too far.

I would make the steps:

 

1) Write some code to blink an LED connected to a pin.

 

2) Learn how to use your debugger to step through your simple LED code, look at your variables, etc

 

3) Now change that code and/or your chip's fuses so that it runs at the correct speed.

 

4). Learn to use the UART to transmit a fixed "Hello, World" string. Again, practice using the debugger with it.

 

5) Adapt your code to be able to send a variable string. This will be invaluable for future work! Keep practicing with that debugger...

 

6) Adapt your code to be able to receive on the UART

 

7) By now, you should be well prepared not only to write your LCD code - but also to debug it!

Last Edited: Fri. Mar 6, 2015 - 10:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Welcome to AVRfreaks!

With all due respect, and in the most comforting of tones you can imagine:

Quote:
hey i got this code from online but unable to print on LCD

You can't just go out on the net, find some source code of some kind and then expect us to fix it all up so that it works for you.

The main effort must always be on your side. Then when you get into trouble you state what you have tried, tested and understood and what you have not. At that point a meaningful discussion might start. The better your question, the better the discussion. The better the preparaotory work you've done, the better the question.

No-one will just jump in and solve it all for you. We just aren't interested in doing that. Think about it for a while... Why would we be?

What we do love is seeing someone learning stuff, growing during a development process, reading the "Yay! It works!"-posts etc.

Notice how this puts the bulk of the workload, reading, experimenting, thinking etc on you rather than on us.

If you simply state "I do not understand anything" you have started out with too high ambitions. (Can you blink a LED? Can you read a switch? Can you integrate those two into a program that blinks the LED after you've pressed the switch? Trust us, there is more to that than superficially meets the eye!)

I'd start on the LCD part, since it will give you a good fault-seeking tool for the other sub-suystems: Start with wiring the LCD up and make a series of small tests. Write a single character to it. Write a string to it. Have an integer variable, convert that to a string and write that string to the LCD. These are the minimum exercises you must do before you can consider the LCD an integral part of the sysem that works as it should.

Only then can you start bothering with your hmc5883l module.

Only a fool does fault seeking in a system with more than one possible area of fault if it can be avoided. And here it can - just do the LCD tests first.

When you have the compass working then you strt wrrying about driving the motors for the wheels. Initially you will not try to combine this with something as complex as PID. You might even try the motor driving out without even having the LCD and the compass running at the same time.

Then you start to inegrate the subsystems together.

This is how every sensible engineer works for a lving, and how most every amateur gets to rewarding results.

Be impatient and try to solve several sub-problems at one and the same time and you will be frustrated for longer than necessary at best. In the worst case you will not get it working at all.

Just in case: If this is a school assignment due next week then you are in real trouble.

And please understand that we see posts like these evey week, if not every third day. What will you do to make us keep up interest in your problem,? (Hint: Be ambitious. Work hard yourself. Do not expect to be spoon-fed.)

With that - again a very warm welcome to AVRfreaks!

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I'm going to stick with 'roughed up a bit' which is in no way like the bullying we used to have. Several posts were very helpful - especially Brian's - and a few were the sort of thing that I think would put off a novice. I posted the links because I think that novices ought to read those before posting here if only to understand the less helpful comments. And I note that the last three posts are also extremely helpful.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think if I was being "Rather Naughty" you would have caught me standing in a window in Amsterdam. I just suggested looking for 'lcd and avr c source' on google.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I just suggested looking for 'lcd and avr c source' on google.
You did?

Quote:
.... I have never heard of anyone ever 'interfacing' an lcd to an avr....
I looked through that post and nowhere was there a suggestion by you to Go Googleing.

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do not know whether using a LCD on a mobile, able to turn robot as a debuging tool would be a good idea;
an USART as awnereil hinted, should be more appropriate as it uses only two wires (instead of >= 6 for a LCD and unused pins are welcome on a robot if you want to add another sensors), is busy for shorter times and the RF link can be seen as a sophisticated (RF is more complicated than wire, as noisier) half USART (but maybe you will be happy sending from your robot, if it carries a webcam, needs to acknowledge orders.... or needs further debugging).

Both USART and LCD have good tutorials in avrfrreaks+tutorials

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Didn't you read the last line?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which last line?
(there are lots of last lines in aa bookseller/a forum/both?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry. jqm said I didnt tell him to search. Thought I did on the last line. Too subtle a hint for a literal minded engineer perhaps?

Imagecraft compiler user

Last Edited: Tue. Apr 1, 2014 - 02:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Thught I did on the last line.

But which one? (I asked google and got billions of last lines; maybe tomorrow will be better)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seven messages up ^^^^

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But from which message?

and my screen is rotated pi/2....

And date is irrelevant, as it is not in UTC.... (on special days, it is important)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Seven messages up

I count seven messages up from that and get to the "I just suggested [...] google" message. The question is where you actually did suggest that?

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

guys i'm able to print messages on LCD the only problem is I'm not able to print data from HMC...
I need help in that...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One More thing...
In the beginning its
int16_t raw_x = 0;
int16_t raw_y = 0;
int16_t raw_z = 0;

How should i print these values on LCD

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

itoa()

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sprintf(buffer, "rx: % d ry: % d rz: % d \n",raw_x,raw_y,raw_z);
will store the string to print, ascii, converted, into buffer (ex : char buffer[20]) and

Quote:

i'm able to print messages on LCD

The only little problem (which would not occur with a serial line) is that it may eat more than 20 chars and you have to adapt your format :rx : eats 4 chars; raw-x value can eat up to 5 chars: -> each value will eat, in the worst case, 10 chars and your lcd is not wide enough (and I do not know how many lines it has)-> you should really try to have a serial line working (terminals are at least 80 chars wide) instead of trying to stuff info into a tiny LCD...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm Using 16X2 LCD... I wished to see that on LCD so that i can use the values to program my robot.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'm Using 16X2 LCD... I wished to see that on LCD so that i can use the values to program my robot.

And you have been given two answers..

You already know how to write strings to the display. You claimed that yourself:

Quote:
i'm able to print messages on LCD

Now all you need to do is convert your numerical variables to strings and then you know how to print those!

For the conversion from numerical to string:
- clawson suggested using itoa()
- dbrion0606 suggested using sprintf()
Any of those will do the job for you.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are lots of things which puzzle me:
* I do not know whence your program came (an adress on the lazy web would be useful, if one finds supplementary informations).

* I am very surprized by the format used to display raw values for the magnetic field compennets. They are raw values, and converted into ints . Then why does your program use dtostrf to prepare a string to be displayed?
According to http://www.nongnu.org/avr-libc/u..., dtostrf is used .. to display floats (and it might, according to me, be a great ressource eater: you must link another libray, libm(ath)). This seems absurd and ironical, as , according to http://www.adafruit.com/datashee... page 14:

Quote:
The value stored in these two registers is a 16-bit value in 2’s complement form, whose range is 0xF800 to 0x07FF

Therfore, you seem to need a way to compute easily two's complement if you want to debug.

According to the same nongnu link, atoi is ideal (but non standard : I bet non avr-gcc forget the radix argument) : you can chose the basis to display numbers: 10, but it will be uncomfortable with base 2; 16 : is short; 2 is long and easy but leads to .... 16 digits -> your LCD will become staurated (never explodes, however)... sprintf does not allow base 2 formatting (allows octal, decimal and hexa), eats more ressources but is more flexible...

* another point puzles me further : if you want/need something to debug, do you need to adjust, for each and every trial, formats to fit into a limited width (and height) display? I already told you (and just repeated awneil's idea) a serial link and a PC would be more comfortable, easier to install/program (and , with good wires, connection can be kept even if yourt robot turns sometimes -this were your specs!-), eats less pins (making evolution more comfortable)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
all you need to do is convert your numerical variables to strings and then you know how to print those!

For the conversion from numerical to string:
- clawson suggested using itoa()
- dbrion0606 suggested using sprintf()
Any of those will do the job for you.


All of which is just standard, plain vanilla 'C' - nothing specific to AVR or microcontrollers or LCD

Some 'C' learning resources:

http://blog.antronics.co.uk/2011...

(includes a link to the AVRFreaks "Books, etc" thread)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree. Especially when starting out. There is so much to learn and so many wrong turns. And it is a step above saying "huh".

Chris PE

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not going to repeat the stuff that has already been said but for getting started with AVR I would suggest reading this forum a checking out https://newbiehack.com there are some very nice beginner tutorials. There are also videos that walk you through getting an LCD to work and a lcd library that's very easy to use.