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
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.
clawson 
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?)
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]
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.
bobgardner 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.
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!
https://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
clawson
getting roughed up a bit
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.
I suggest you stop trying to run before you can walk
Agree!
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[1] 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!
EDIT
[1] or Simulator, if you are using one; eg, Proteus.
Note that Proteus is an independent 3rd-party product totally unrelated to Microchip or Atmel.
For assistance in using Proteus, see: https://www.avrfreaks.net/comment...
JohanEkdahl 
Welcome to AVRfreaks!
With all due respect, and in the most comforting of tones you can imagine:
hey i got this code from online but unable to print on LCD
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!
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
bobgardner 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.
jgmdesign 
I just suggested looking for 'lcd and avr c source' on google.
.... I have never heard of anyone ever 'interfacing' an lcd to an avr....
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
bobgardner Didn't you read the last line?
Which last line?
(there are lots of last lines in aa bookseller/a forum/both?)
bobgardner 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?
Thught I did on the last line.
bobgardner Seven messages up ^^^^
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)
JohanEkdahl
Seven messages up
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...
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
clawson 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
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...
I'm Using 16X2 LCD... I wished to see that on LCD so that i can use the values to program my robot.
JohanEkdahl
I'm Using 16X2 LCD... I wished to see that on LCD so that i can use the values to program my robot.
You already know how to write strings to the display. You claimed that yourself:
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.
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:
The value stored in these two registers is a 16-bit value in 2’s complement form, whose range is 0xF800 to 0x07FF
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)
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.
Some 'C' learning resources:
http://blog.antronics.co.uk/2011...
(includes a link to the AVRFreaks "Books, etc" thread)
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".
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.
