Don't ad-block us - support your favorite websites. We have safe, unobstrusive, robotics related ads that you actually want to see - see here for more.
0 Members and 1 Guest are viewing this topic.
1) When I tried to program the atmega8 with AVR Studio (edit: I bought the more expensive ISP2 programmer), it failed, but the message log read something like: connecting - successful, writing flash - successful, reading flash - FAIL, disconnecting - FAIL. Should I take this to mean that it successfully programmed the microcontroller but failed to verify it? Or should I take this to mean that it failed altogether? When I plugged the servos in they did zero themselves out, but for all I know, they would have zeroed themselves out anyways if the microcontroller was "dead" (if the control pins are unset, that means they are low, which means it is telling it to go to zero? Or is that untrue?).
2) In any case, what should I look at for why the programming was busted (i.e. if just the read was failing, why would that be the case - is one of my pins not soldered correctly? But I tested the connections with the multimeter...)
3) AVR Studio can write to "Flash" or "EEPROM". I tried both, but it said there wasn't enough space on the EEPROM so I am just assuming that I was supposed to write the hex file to Flash memory. What's the difference between the two? ...or did I miss something when I RTFM
Most probably the programming failed altogether.The servos zeroing out is not a good indicator that the device programming was successful....Maybe your programming settings are incorrect. Verify that the speed is 1/4 that of the oscillator speed. Verify that you have selected the correct part (ie ATmega8 for this project) this is at the top left corner of the window.
When I tried to program it, I did get a little status bar that steadily went across the screen, after which I got "programming flash: successful. When it tried to read Flash I didn't get a status bar before "FAIL".
In any case, I started putting random numbers into the ISP speed and eventually got it to successfully write. I assume by oscillator speed you mean clock speed, which is 8Mhz for the atmega8, correct, so 2Mhz for the ISP speed should have worked? It didn't, and in fact complained about a short in the system, which I am fairly sure that I don't have. Then I tried 1Mhz and it complained about something else. I think 100Khz or 20Khz ended up working correctly through the whole thing (programming, reading, etc. all successful), but the whole thing is kind of sketching me out. I expected it to work or not work, instead of black magic BTW, the ISP speed that it was originally set to last night before I posted my question was defaulted to 1.02xx Khz (very, very slow). I don't know where it picked that number from. Is that an indication that something is wrong in my system? Why would 1Khz fail but 100Khz succeed?
Hmmn. Try to check the value of the pull up resistor in your RESET line if you have one. Check the data sheets for the allowable values of this resistor. This bit me last week.
Yup oscillator is the clock speed.AVRStudio complained about a "short in the system"? Did I read that correctly?
Check your fuse bits, is a clock divisor enabled? If it is, it divides the value of the oscillator by 8. So if you have set the oscillator at 8MHz and the clock divisor is programmed, you are in fact running at 1MHz!
BTW, were you able to verify that you are indeed using the correct part/device in AVRStudio?
I don't have one (and don't know what that is). Ok, I did some research on google, and it looks like it is there to pin a voltage high if it is otherwise unset. So in the schematic I would connect one end of a resistor to the brown pin (RESET on the microcontroller) and the other end to my 5V bus? I checked the datasheet here to find out more and am confused. Fig. 14 on page 38 seems to indicate that there is an internal pull-up resistor inside the chip already. But page 5 specifically says PB7-PB0 and PC5-PC0 have internal pull-up resistors but says nothing about PC6/RESET, which would indicate to me that it does not have an internal pull-up resistor. And then (and excuse me again for being obtuse - these datasheets are like greek to me): on page 242, the DC Characteristics table says something about the Reset Pull-up resistor having a min of 30kOhm and a max of 80kOhm, but I can't tell if they mean that I should put in a 30k-80k pull-up resistor or if they are telling me that there is one inside the chip already and that it is somewhere between 30k and 80k ohm.
Will setting the clock divisor only affect programming speed, or does it affect the speed of the chip as it is running the program?
250kHz it went right through and programmed and verified in <1 second, and immediately started driving the servos back and forth.
I looked at the code that actually sends the signals and it looks like the number I'm sending is simply the number of cycles it waits after it turns the signal high till when it turns if off again, so I'm not sure how I get finer resolution than that. i.e. how do I tell my servo to go at the speed "35.125" or whatever? How do I get finer resolution control over how long a pulse I send to the servo?
The only thing that doesn't work at all is the LED status light! I can't get it to turn on no matter what I send to port 4 (where the LED is plugged into). I got it to light up once by measuring the voltage drop between ground and VCC (I think) with my multimeter, I think, but it doesn't seem to turn on normally.
The good thing is that it works!
IServos normally have a specific speed and you can't actually tell a servo to speed up. ...The length of the pulse is decoded by in on-board servo controller and this determines the direction of the rotation of the horn/arm/hub/or whatever is connected to the servo. This is Pulse Code Modulation. For an unmodified servo, ending a pulse of 1500uS centers the servo to its neutral position....http://www.uoguelph.ca/~antoon/hobby/servo1.htm
I'm not at home so I can't check the code, but if I remember right the comments said something like "23 delay cycles is about .992 milliseconds" so it makes sense that my turning on the port and delaying for 35 cycles (about 1.51 milliseconds) before turning it off would roughly stop the servo.
Most servos expect to receive a pulse every 20ms, if it doesn't receive any it holds it's current position.
though at the bottom it says "You will notice that by telling the servo to go to a particular angle, instead it will rotate at a particular speed.", but maybe he just means directional control.