help moving atmeg8 to atmeg168

Go To Last Post
57 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using avrstudio and developing for an object Development usbavr project that was designed for the atmega8 ( ext osc 12mhz). I ran out of space and moved to the atmega168.

So, as far as I can tell there are no required changes to the usb header. I made the change in the make file to atmage168 and a cpu of 16000000. I also see the some timing registers are renamed and made the best effort to change them in my main. I dont think an incorrect use of a timer would cause an unknown device, but I could be wrong.

I changed

TCCR0 to TCCR0B
TCCR2 to TCCR2B
OCR20 to OCR0A
TIFR to TIFR0 ( OCF0 to OCF0A )

as far as fuse bytes go, the atmega8 project was
0xc9 high
0x9f low

The best I can find as a match is

0xf9 ext
0xdd high
0xbf low
Low is weird? for example 0xbf and 0x9f show no difference? I dont know if something else is changing but I sure dont see it in the window.

I'm not sure if lock bits are relevant but I set to 0xff

Everything compiles fine, but the device is never recognized.

I should have all of the information, should anyone helping me ask. I'm just a novice so I would not know anything else that is needed here.

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

I guess you read:

http://www.atmel.com/dyn/resourc...

while that's for the 8->88 transition most will apply equally to 168

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

yes I found that later on. Very handy.

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

The interrupt vector table jumps need to use call (long instruction)..I had some snarls over that one.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:
The interrupt vector table jumps need to use call (long instruction)..I had some snarls over that one.
-Curious, would this prevent the device from being recognized? Also what is a vector table jump? Is that ASM specific? I dont do any Interrupt jmp requests.

The only thing in my code that I think may cause a unknown device is the hardware I/O abstraction ( see below ) , but not really sure. I "think" my problem lies in the fuse setting.


static void hardwareInit(void)
{
	uchar	i, j;

	// init port C as input with pullup
	DDRC = 0x00;
	PORTC = 0xff;
	
	/* 1101 1000 bin: activate pull-ups except on USB lines 
	 *
	 * USB signals are on bit 0 and 2. 
	 *
	 * Bit 1 is connected with bit 0 (rev.C pcb error), so the pullup
	 * is not enabled.
	 * */
	PORTD = 0xf8;   

	/* Usb pin are init as outputs */
	DDRD = 0x01 | 0x04;    

	
	j = 0;
	while(--j){     /* USB Reset by device only required on Watchdog Reset */
		i = 0;
		while(--i); /* delay >10ms for USB reset */
	}
	DDRD = 0x00;    /* 0000 0000 bin: remove USB reset condition */
			/* configure timer 0 for a rate of 12M/(1024 * 256) = 45.78 Hz (~22ms) */
	TCCR0B = 5;      /* timer 0 prescaler: 1024 */

	TCCR2B = (1<<WGM21)|(1<<CS22)|(1<<CS21)|(1<<CS20);
	OCR0A = 196; // for 60 hz

}


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

Quote:

I had some snarls over that one.

If you .org to each individual vector then it should not matter whether you use CALL or RCALL (as long as the target is within range of the RCALL). This is why Atmel define the individual addresses in the def.inc so you can do something like:

  .include "m168def.inc"
  .org 0
rjmp reset

  .org OC1Aaddr
rcall OC1A_isr

  .org ADCCaddr
rcall ADCC_isr

reset:
  ; etc.

(of course the 48/88/168 may well have some vectors that the mega8 simply didn't have or named differently in the def.inc)

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

Who cares? While OP was a bit short on info--C or ASM?--one can infer GCC from "avrstudio" and "makefile". So we are in C and won't be building vector tables by hand anyway.

(Right?)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:

Who cares?

I was responding to avrcandies not the OP. Obviously the issue that caused "some snarls" was an Asm one as the same issue would have been hidden in the C runtime.

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

Yeah, I guess I was going a level too deep. When first reading the thread I thought of the vector size difference, as well as the register changes needed ('cause I've been there and done that). That's when I did my detective work to guess at the language.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

So I would guess I dont need to be concern with that issue at the moment?

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

Not if, as you have demonstrated, you are using C - that's one of the joys of C - a lot of the detail gets mopped up for you (things like initialising the stack and so on)

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

Indeed, looking at ASM code is not my cup of joe. Done enough of the in the past. Though its handy to understand a bit of it.

So any thought on my matter? Anything I could add so that one might be able to help me?

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

Dear Mr 20K+ posts, what happens when

 .org OC1Aaddr 
rcall OC1A_isr 

the RETI occurs in the ISR? :wink:
Does anyone look at the data sheets anymore? :roll:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

hey, the original poster says his device is not recognised, why are you blinding him with (irrelavent) science?

Dude my first thought is the CKDIV8 fuse, i fell for this myself.

Set ISP programming speed to 125kHz then untick the CKDIV8 fuse. You can now crank ISP speed back up to a (fosc/4).

If this doesnt help Im sorry for wasting your time :o(

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

js wrote:
Dear Mr 20K+ posts, what happens when
 .org OC1Aaddr 
rcall OC1A_isr 

the RETI occurs in the ISR? :wink:
Does anyone look at the data sheets anymore? :roll:


I guess that's why I stick to C programming these days - I did my asm apprenticeship a LONG time ago! :lol:

(but it was as true then as now that you are far better locating things absolutely using ORG rather than by "padding")

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

Special_D wrote:
hey, the original poster says his device is not recognised, why are you blinding him with (irrelavent) science?

Dude my first thought is the CKDIV8 fuse, i fell for this myself.

Set ISP programming speed to 125kHz then untick the CKDIV8 fuse. You can now crank ISP speed back up to a (fosc/4).

If this doesnt help Im sorry for wasting your time :o(

- LOL your the only one that has offered help, dont feel that way. I was wondering about the bit as well but had no thoughts towards it.

Isp speeds have always confused me. I read that it must be fosc/4, yet with the atmega8 I can set it to any speed. Currently its set to 230.4 khz. and the only options are :
921.6 khz
239.4 khz
57.6 khz
28.8 khz
4.0 khz
603 hz
I choose to have CKDIV8 unchecked so it already is unchecked. I tried burring as low as I could but there was no change.

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

Quote:

I read that it must be fosc/4

Where did you read that? What I read was that the low time and the high time of the "SCK" pulse must each be at least 2 AVR clock cycles wide. There is no practical maximum, if that is what you are getting at--you don't have to be any exact speed. This is SPI, after all.

Re "the only options": You can get more speeds by typing in a number, depending on your tool and version. Those may be the pre-calculated ones presented to you.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Hey Lee, Like I said I ran the atmega8 at the highest option. but I see "Also note that the ISP needs to be less than 1/4 whatever clock speed that the AVR is being clocked at." every where. Maybe I should not have quoted "I read that it must be fosc/4 ". I just figure the verbiage was the same. The speeds are in fact locked, so I guess avr-studio is setting them.

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

Quote:

The speeds are in fact locked, so I guess avr-studio is setting them.

What does that mean? - Studio lets you set any ISP speed you choose?

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

What I was poking at is the "less than"; you implied that it must be that fast.

I still haven't figured out what we are chasing here. Failure to ISP correctly?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I'm confused. :roll:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

clawson wrote:
Quote:

The speeds are in fact locked, so I guess avr-studio is setting them.

What does that mean? - Studio lets you set any ISP speed you choose?
- Interesting I was not able to input data in to that box before? It does in fact allow it, my mistake.

Quote:
What I was poking at is the "less than"; you implied that it must be that fast.
This is not my implication, its a quote. I see that everywhere. The reason to me is unknown. If its wrong, then you are the first to tell me that. I certainly never claimed to be a expert, hack I'm hardly a novas.

Quote:

I still haven't figured out what we are chasing here. Failure to ISP correctly?
No, the ISP thing, I think was just the fact you challenged my quote. Personally I dont think its my problem at all. I just can't for the life of my figure out why I get unrecognized device. All the relevant info was in my first post. The only thing discussed here, about the problem, was the CKDIV8 info from Special_D, that which spawned the ISP speed talk.

for me , what would be helpful, is how I could trouble shot my issue. I dont have a lot of experience with "failing". I subscribed in to the hobby of AVR witting with a known working project. Sure it took some learning as the project was dev'd with avrDude on linux. but I managed. Now I'm adding to the project and moving to a large chip. Just stumped as to why my device is showing unrecognized device ( they only form of "fail" I have). My guess would be that an unrecognized device is rather a vague error. Meaning anything wrong would cause it.

My project compiles, my mcu is set in my make file and my code works on the atmega8. I changed the registers names, and no other changes are required in my code to work on a atmega168.

So I'm hopping someone on AVR Freaks may have a thought. I find AVR Freaks has a lot of readers and sometimes takes a bit to get a solution. So far I have always found help on here, but this could just be to vague of a problem. I'm grateful people are responding so that the threads stays alive, even if its not relevant ;)

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

When you say "the device is not recognized", exactly what is telling you that? Are you talking about using AVR Studio or avrdude or something else? Also at exactly what point does the "not recognized" thing appear? Are you able to read the signature? What programming/ISP(?) hardware are we talking about here? Is the AVR on a proper PCB or in a breadboard? Can you post a schematic of the exact circuit being used?

Oh and as this is a 168 you are talking about have you ever been anywhere near a Dragon or JTAGICEmkII and is there any chance that maybe DWEN got set?

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

Quote:
The interrupt vector table jumps need to use call (long instruction)..I had some snarls over that one.

The Mega168 device group (Mega8,48,88 and Tiny48,88)does not use long instructions in the vector table. Each vector is one word in size. The Mega164, I believe, uses two word (long) vectors. Yes it is confusing.

Never use 'RCALL' or 'CALL' instructions in the vector table. Use 'RJMP' or 'JMP' and end the interrupt routine with RETI. Short unused vectors should have RETI in the vector table and long ones should have RETI NOP.

I recommend using assembler regardless of how tedious or irritating it can be. There are so many little details that can go wrong.

I believe that it is a mistake to assume that the C compiler will handle all these details. Yes,it will, MOST of the time. Yes, it will, IF you configure it correctly, ALL of the time.

Otherwise you risk going crazy trying to debug why your program isn't working. These devices are 'micro' 'controllers'. Micro because they and their programs are very small. Controllers because they change how machinery functions according to the way that the designer manipulated the symbols of the controlling program.

When your program is less than about 4K in Flash size, it is better to use assembler in order to keep close control over what it is actually doing, and exactly how the device is working.

I realize that this goes against all the training and advice given by professors and senior engineers, but I sincerely believe that it is true. Again, if your program code goes beyond twenty or printed pages, switch to C. You've entered a different type of programming, and the higher level language with increase your productivity. But don't confuse Microcontroller C with Desktop/Mac/Linux C. You are always going to be on a lower electronic level with a microcontroller than with a PC. The differences is not in writing the code, but in debugging it when it doesn't work correctly. When the code is perfect, and the application doesn't work write, debugging the assembler written by a C compiler is much more difficult than commented assembly code written by hand.

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

Quote:

The Mega168 device group (Mega8,48,88 and Tiny48,88)does not use long instructions in the vector table. Each vector is one word in size.

Simply not correct. Any AVR with more than 8KB of flash has two-word vector tables, to be able to reach anywhere in flash for ISRs.

You did not list them (and the ones you DID list do in fact have single-word vectors) but Mega168 and Mega328 are in that "group".

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:

I believe that it is a mistake to assume that the C compiler will handle all these details. Yes,it will, MOST of the time. Yes, it will, IF you configure it correctly, ALL of the time.

??? My brand will. And it has provisions for "roll your own" options if [one of the few] applications demand it.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:

When you say "the device is not recognized", exactly what is telling you that?

That was what I was getting at, with "what are we chasing"? Is it the >>USB<< device that is not recognized? Then first make certain what speed your virgin AVR is really running at.

Or is it ISP that is not recognizing it?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:

When your program is less than about 4K in Flash size, it is better to use assembler in order to keep close control over what it is actually doing, and exactly how the device is working.

LOL. Here we go again... [Remember that in a "simple" program I'll claim I can match everything in C that you claim is advantageous in ASM. And yes, the compiler will tale care of the details. Now, if you have a cutting-edge algorithm that can make great use of the carry bit or rotate or 24-bit arithmetic then the usual caveat applies: You can do that better in ASM 'cause C has no concept of that. Or you are going to make 6 million microwave ovens so if you can save US$0.05 on each one it is worth 6 person-months to squeeze the app, then you win.

But for the dash-it-off-and-be-done app in the Tiny25 to Mega48/88 class that will end up 75% full and the AVR has plenty horsepower, then I say that your claims are not warranted. And (I just gave a couple examples in another thread) if there are >>particular parts<< that could use attention, then do that.]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Ok. about the "unrecognized device". As I state this is a usb project, not sure if that was missed? When you have such device fail you will get this error. It gives me this error when I have flashed the new hex and plug in the usb device. This of course is windows displaying this. Not sure what you mean by the signature. Nor how i could tell this.

Oh and as this is a 168 you are talking about have you ever been anywhere near a Dragon or JTAGICEmkII and is there any chance that maybe DWEN got set?

Not sure, I have an avrIsp for programming. Also I dont know what or where the "DWEN " bit or value is?

I wish there was a more robust emulator so that I could see exactly what is wrong, but working with modest avr-tools, no such luck.

what I know..

the code works on an atmega8
the usb device is recognized when burned to an atmega8
I use fuse bytes 0X9C 0XCF for the atmega8

All I did to switch was the register changes and the mcu speed in the make file. I see it compiles and shows the new mcu speed but when flashed to the device, as stated, I get an unrecognized device in windows ( or any usb environment for that matter ).

Sure hope that answered the question, still learning ;)

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

So you are talking about "software USB" then? Something like the Igor Cesko solution? Obviously the key thing about that is the timing so if the mega 8 code (after porting) doesn't work in the 168 the chances are it's simply running at a different speed. One simple check of that would be to download an LED flasher program into each and see if they both flash at exactly the same rate.

As for DWEN - that is a fuse that can be changed during an ISP session which means that ISP can no longer be used with that chip (until it is reversed - but not by ISP). But that's a red-herring. Like other I mistakenly though the "unrecognized" problem was from your ISP programming software - not from a PC trying to connect to the USB application that has been successfully downloaded into the chip with ISP.

Cliff

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

Quote:
So you are talking about "software USB" then? Something like the Igor Cesko solution? Obviously the key thing about that is the timing so if the mega 8 code (after porting) doesn't work in the 168 the chances are it's simply running at a different speed. One simple check of that would be to download an LED flasher program into each and see if they both flash at exactly the same rate.
Yeah Object Dev is similar. I didnt know the timing would cause a error like that, figure timing would just mess up the function of the device during use. I'll try the led flasher and look more in to the timing. thx..

Quote:

As for DWEN - that is a fuse that can be changed during an ISP session which means that ISP can no longer be used with that chip (until it is reversed - but not by ISP). But that's a red-herring. Like other I mistakenly though the "unrecognized" problem was from your ISP programming software - not from a PC trying to connect to the USB application that has been successfully downloaded into the chip with ISP.
Haa, ok then, thx so much.

Since the only change form the atmega8 to the 168 was timing, and as you said that is a big deal, must be the culprit.

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

Just to add that software USB is such a clever software trick that it may not even be as coarse as the overall F_CPU being different. It's quite possible he's relying on actual instruction execution cycles to get the timing right and, for example, the 168 has some registers that would need STS access that might be OUT in a mega8 and this kind of thing could put the whole timing out by one machine cycle which may be enough to break the code.

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

If the OP is using Objective Development's AVR USB software, as used in the USBasp programmer, then I've had this working on a Mega88 (on a 16Mhz crystal) without needing to do anything beyond a couple of macro changes for the clockspeeds.

I'd second (or is it third now?) the 'load a simple LED flasher' to double-check it's actually running at the speed you think.

[edit: Removed a comment about running the USBasp on a M88 at 12Mhz - The 16Mhz version worked, so I didn't actually get round to trying it at 12Mhz]

Nigel Batten
www.batsocks.co.uk

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

The guys from Object Dev said the same as condemned, nothing should really be changed to make the 88's work.

As for the flasher, the only thing that confuses me is, if the device is not being recognized, how will it flash a LED?

My guess is that the hardware init will still run, so I could put the flash code in there.

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

I think we're getting several wires crossed here!

Forget all the USB code.
Let's go back to basics.
Write the very simplest program you can for the M168.
All the program should do is toggle a port pin to turn an LED on and off once per second.
Flash that very simple program onto the 168.

Does it blink at the expected speed?

Why am I asking you to do that?
I suspect that the 168 isn't running at the speed you think it is. The usual suspects would the the DIV8 fuse bit and/or using the internal clock rather than the crystal.

If the M168 isn't being clocked at the speed you expect, there is no way the carefully timed USB code would work - resulting in the PC not being able to communicate with it.

Nigel Batten
www.batsocks.co.uk

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

If I write a program that "should" flash once a second. And if it does not do so every "second" then what could I do to fix that? If there is a setting to do this, Then I I completely follow you now.

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

S_K_U_N_X wrote:
If I write a program that "should" flash once a second. ...
Have you written the program, or are you trying to waste more of our time?

Stealing Proteus doesn't make you an engineer.

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

If you write a program to flash once a second then somewhere in that program you are going to be basing your delay loops or timer values on what you believe F_CPU to be. So you can adjust that until it does flash once a second. But the obvious ones are where you think it is 8MHz but it's really 1MHz either because CKSEL have never been changed or because they have been but CKDIV8 has not. In the 8-1 case then obviously the LED will only flash once every 8 seconds rather than once a second.

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

Quote:
Have you written the program, or are you trying to waste more of our time?

If reading a forum post is a waste of your time dont read them? Funny you say that, this is your only post in this topic. Who is wasting who's time?

If I were to extract some point out of your post it would be, "if I'm working on condemned suggesting". If that is so, the answer is yes. I like to understand things, never felt a question was a crime.

clawson, thank you.

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

S_K_U_N_X wrote:
If reading a forum post is a waste of your time dont read them? Funny you say that, this is your only post in this topic. Who is wasting who's time?

If I were to extract some point out of your post it would be, "if I'm working on condemned suggesting". If that is so, the answer is yes. I like to understand things, never felt a question was a crime.

You are wasting may words just to cover up your laziness or incompetence. You are to lazy or incompetent to write five lines of code and run a LED flasher. You have already pissed off quiet some people earlier in this thread with your childish and arrogant behavior. You want to get spoon feed? Good luck with that.

Stealing Proteus doesn't make you an engineer.

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

Ok, my findings with the atmega8, I get a flash every second.

With the atmega168 and the ckdiv8 one with ckout on it stays on for 8 seconds and off for 1 second.

With the ckdiv8 off and the ckout on blinks every second.

This matches what you said. So this wouyld tell me the timing is on the money as long as the ckdiv8 is off?

For reference here is my test code.

#define F_CPU 12000000UL	
#include 
#include 

void delayms( uint16_t millis ) {
	while ( millis ) {
		_delay_ms( 1 );
		millis--;
	}
}

int main( void ) {
	DDRD |= 1 << PD1;			
	while ( 1 ) {
		PORTD &= ~( 1 << PD1 );	
		delayms( 900 );			
		PORTD |= 1 << PD1; 	
		delayms( 100 );		
	}
	return 0;
}

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

Quote:

So this wouyld tell me the timing is on the money

No, obviously it tells you it is in the neighborhood.

If you want to check timings, use a 'scope or frequency counter or both. [For example, the Skunker could be using 8MHz internal oscillator and be "close" but not "on the money".]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch, I'll look in to this, I have a scope. thx.

question? I read some advice that if I get 60 flashes per 60 seconds I would be in good shape. Is this not true?

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

Ok from what I can tell both sine waves show the same number of cycles. From my calculations the 12mhz is actually running at 24 mhz. My guess is it's clocked down (/2) for stability.. Not sure but rest assured its running at the same frequency as the atmeg8. Is there anything else I could test why I have my simple circuits (atmega 168 and 8 ) on the bench?

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

Quote:

From my calculations the 12mhz is actually running at 24 mhz.

I doubt that but remember that if you are toggling that on one "tick" the line is enabled and on the next it is disabled so the apparent "output frequency" is half the speed that the thing is actually working.

If the clocks are the same and others here have said that there are no subtle timing issues in the code then it's a bit of a mystery.

But have you said who's software-USB this is yet? Is it Igor Cesko's or the ObDev one ? Maybe one IS sensitive to small timing changes.

Cliff

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

Quote:
I doubt that but remember that if you are toggling that on one "tick" the line is enabled and on the next it is disabled so the apparent "output frequency" is half the speed that the thing is actually working.
Then that explains it.

Quote:
But have you said who's software-USB this is yet? Is it Igor Cesko's or the ObDev one ? Maybe one IS sensitive to small timing changes.
huh? I wonder why I get asked that. I must write to much info... As mentioned before it is the Object Dev software.

Quote:
If the clocks are the same and others here have said that there are no subtle timing issues in the code then it's a bit of a mystery.
I see this is going to be fun to trouble shoot. Is there any reason to expect the register changes?

I may try to blink the LED in the the hardware I/O abstraction function . Not sure this will work? I would think if that potion of the code got called it would be a start.

Last Edited: Mon. Mar 30, 2009 - 11:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you tried the original code with a 12MHz crystal on the 168 yet? With your 16MHz crystal there may need to be a few things changed and it would be easier to test if using the crystal speed that the software was written for. Then once that it is working then go and change for the faster clock.

I think in your very first post that the code you included was using a 12MHz as the speed.

edit: it was the second post

}

         /* configure timer 0 for a rate of 12M/(1024 * 256) = 45.78 Hz (~22ms) */ 
   TCCR0B = 5;      /* timer 0 prescaler: 1024 */ 

   TCCR2B = (1<<WGM21)|(1<<CS22)|(1<<CS21)|(1<<CS20); 
   OCR0A = 196; // for 60 hz 

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

Quote:

mentioned before it is the Object Dev software.

Sorry, I missed that - in that case did you see this page linked from the obdev site:

http://metalab.at/wiki/Metaboard

As that's using mega168 it should be VERY easy to port it to mega88 (or just replace the mega88 with a mega168)

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

digitool, i'm using a 12mhz crystal not 16. Another member was talking about the 16, if I did it was an error.

clawson, I did not see that page that would be a nice start if their trunk was not a dead link :(

That gives me a thought though. I will search for an 88 usb objdev hello world. If I can find that I should be able to make this work.

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

Sorry for the mistake,I just read the first bit of your post and saw this:

Quote:

So, as far as I can tell there are no required changes to the usb header. I made the change in the make file to atmage168 and a cpu of 16000000.

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

ahh, my type-O ;)

Pages